Re: [Iverilog-devel] Why use SFT files?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I don't object.

My only remaining concern is that running the compiler might be
slightly more complicated when VPI modules are involved, but I believe
the costs on that front can be minimized.

Have you verified your work on Linux, Windows, and Mac OS?

I would keep this out of the v10 branch.

On Mon, Nov 4, 2019 at 12:32 AM Martin Whitaker
<ic...@ma...> wrote:
>
> So, any objections to merging this?
>
> Martin Whitaker wrote:
> > It's a user experience thing. The information is all available via the
> > standard VPI API - why should we expect users to provide it again in a
> > different format. No other Verilog compiler I know of requires that, and
> > apart from the Windows ugliness, it's easy to fix.
> >
> > My current solution doesn't require the user to do anything special, other
> > than to build against our vpi_user.h and libvpi.a. And they need to do that
> > with the existing solution too.
> >
> > I will replace the macros though. The more I think about it, the more I
> > dislike it.
> >
> > Stephen Williams wrote:
> >> Ugh! I forgot about that.
> >>
> >> Yeah, this is getting increasingly awkward. Might it be better compile
> >> into the VPI a data structure that the environment can extract without
> >> callbacks? In a sense we already have that in the form of the
> >> s_vpi_systf_data struct. Pile all of that into a section in the .vpi
> >> and the loader binary may be able to get at it without callbacks. That
> >> would require a coding standard for the vpi modules to make those
> >> tables static const tables.
> >>
> >> Is that any better then having .sft files?
> >>
> >> What's the problem we're trying to solve, again?
> >>
> >> On Sat, Oct 26, 2019 at 12:29 PM Martin Whitaker
> >> <ic...@ma...> wrote:
> >>>
> >>> I'm already reusing the vvp/ivl_dlfcn.h header. Dynamically loading the
> >>> modules is not the problem; allowing the modules to call back to the VPI
> >>> routines implemented in the main program (e.g. vpi_register_systf) is.
> >>>
> >>> In Linux (and I guess in MacOS), those routines are left as undefined
> >>> references in the VPI module:
> >>>
> >>> % objdump -t v2005_math.vpi | grep vpi_register_systf
> >>> 0000000000000000         *UND*  0000000000000000
> >>> vpi_register_systf
> >>>
> >>> When the module is dynamically loaded, these references get resolved by
> >>> name, using whatever is provided by the loading program (or other libraries
> >>> it has dynamically loaded). So any program can load and use the module,
> >>> providing it implements the necessary functions.
> >>>
> >>> In Windows, the VPI modules are linked to vvp/libvpi.a, which is created by
> >>> dlltool from vvp.exe. This contains the relocation information for all the
> >>> symbols exported by vvp, and that information gets hardwired into the VPI
> >>> modules. So if a VPI module is dynamically loaded by a different program,
> >>> the addresses are all wrong, calls to the VPI routines jump to some random
> >>> place in the loading program, and chaos ensues.
> >>>
> >>> I searched for a way to make Windows resolve references at load time, but
> >>> couldn't find anything, hence I did it manually.
> >>>
> >>> If you don't like the use of macros to translate the calls, we could
> >>> provide wrapper functions in the new libvpi. It would be a little less
> >>> efficient, but most likely insignificant in the overall cost of making VPI
> >>> calls.
> >>>
> >>> Stephen Williams wrote:
> >>>> VPI modules can be dynamically loaded by vvp in Windows and Mac, so
> >>>> shouldn't that same functionality work with ivl on Windows? The
> >>>> vvp/ivl_dlfcn.h header file encapsulates this. Perhaps that header can
> >>>> be moved to libmisc.
> >>>>
> >>>> On Wed, Oct 23, 2019 at 8:18 AM Martin Whitaker
> >>>> <ic...@ma...> wrote:
> >>>>>
> >>>>> This was triggered by my writing a regression test for the recently
> >>>>> reported bug, and finding that vpi_reg.pl didn't really support tests
> >>>>> with
> >>>>> SFT files...
> >>>>>
> >>>>> I've implemented the compiler change to read VPI modules directly in the
> >>>>> sft-rework branch. Apart from exposing another issue in the vlog95
> >>>>> target,
> >>>>> all the existing tests still pass.
> >>>>>
> >>>>> Implementing this for Linux was pretty easy. Fixing the problems in
> >>>>> Windows
> >>>>> took a bit longer. As far as I can tell, there's no way for a DLL to
> >>>>> automatically link to functions provided by the client application. The
> >>>>> existing approach of linking the VPI module to vvp meant it couldn't then
> >>>>> be used by the compiler. I solved that by passing a jump table down to
> >>>>> the
> >>>>> VPI module when it was loaded.
> >>>>>
> >>>>> See what you think. There's a sft_rework branch in the test suite which
> >>>>> makes vpi_reg.pl use the new functionality.
> >>>>>
> >>>>> Stephen Williams wrote:
> >>>>>> Because the .sft has some specificity that the .vpi does not have?
> >>>>>> Also, to read the .vpi file, you need to dynamically link it in so
> >>>>>> that you can read the tables. The ivl program currently does not need
> >>>>>> to load .vpi files, it can use the .sft files instead.
> >>>>>>
> >>>>>> That may be obsolete thinking, though...
> >>>>>>
> >>>>>> On Sun, Oct 20, 2019 at 12:19 PM Martin Whitaker
> >>>>>> <ic...@ma...> wrote:
> >>>>>>>
> >>>>>>> It is easy enough to extract the information from the .vpi file. I've
> >>>>>>> written a small standalone utility that does just that and writes out a
> >>>>>>> .sft file. But why not get the compiler to do it on the fly, rather
> >>>>>>> than go
> >>>>>>> though an intermediate step?
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Iverilog-devel mailing list
> >>>>>>> Ive...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Iverilog-devel mailing list
> >>>>> Ive...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Iverilog-devel mailing list
> >>> Ive...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> >>
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Iverilog-devel mailing list
> > Ive...@li...
> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic...              But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."