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

[Martin W. <ic...@ma...>]

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
> 
> 
>