iverilog-devel — Conversations on matters of Icarus Verilog development

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

[<ni...@ly...>]

Stephen Williams <st...@ic...> writes:

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

If you want to keep the complexity out of the compiler proper, you could
consider having a separate utility to create a corresponding sft file
for a vpi module, and let the compiler run that utility to generate sft
files when needed.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

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

[Stephen W. <st...@ic...>]

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

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

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

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

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

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

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

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

[Stephen W. <st...@ic...>]

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



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

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

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

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

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

[Stephen W. <st...@ic...>]

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



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

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

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

[Stephen W. <st...@ic...>]

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



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

[Iverilog-devel] Why use SFT files?

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

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?

Re: [Iverilog-devel] vpi_put_value

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

Agreed. What I have in mind is to add an extra flag in the sys_func_table 
to indicate whether the function has been overridden. If the function is 
then called in a constant expression, we could either issue a warning or an 
error and carry on using the built-in implementation (I don't fancy trying 
to implement VPI calls in the compiler's constant evaluation - even though 
the standard seems to suggest that is what you are supposed to do).

Stephen Williams wrote:
> Great, but we don't want to lose the capability to inline functions
> like $pow() in the compiler. Some people use this sort of thing to
> calculate such compile-time constants as, for example, array vector
> sizes.
> 
> In general, it is considered poor form to directly replace such basic
> system functions, especially if that replacement leads to a different
> prototype.
> 
> On Mon, Oct 14, 2019 at 7:03 AM Martin Whitaker
> <ic...@ma...> wrote:
>>
>> Hi Yong,
>>
>> My apologies. I looked in the test suite for something to adapt to reproduce the problem, found
>> that, and didn't read it carefully enough!
>>
>> If the compiler detects that a system function has constant arguments, it will try to evaluate it at
>> compile time, using a built-in implementation. That is why your first call works. We should fix that.
>>
>> The second call fails because the compiler is using the return type for the built-in implementation
>> (real) rather than the return type of the replacement (32 bits). There is supposed to be a method of
>> fixing that, by suppling the compiler with a ".sft" file that provides the return types of
>> user-defined system functions, but that also appears to be broken in this case. I'll look into that.
>>
>> Martin
>>
>>
>> On 14/10/19 08:23, fuyong wrote:
>>> Hi, Martin,
>>>
>>> Finally figure out the reason. In the original example, the 1999 version I
>>> have, intention of the test is to override the system defined function,
>>> such as $pow. In your example, you used $my_pow() instead. Guess that in
>>> Iverilog, system defined function calls could not be overwritten yet.
>>> Actually I did noticed in my test with $pow(), the first $pow() called the
>>> system pre-defined function, the second one goes to user defined function.
>>> This is why the first $pow() passed, and the second one get error.
>>>
>>> The version I have is:
>>> version 11.0 (devel) (s20150603-641-ga8318db2)
>>>
>>> Many thanks for the help!
>>>
>>> Yong
>>>
>>>
>>>
>>> On Sun, Oct 13, 2019 at 2:29 AM Martin Whitaker <
>>> ic...@ma...> wrote:
>>>
>>>> I can't reproduce the failure. We have that example in the test suite
>>>> already - see
>>>>
>>>>      https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.c
>>>>      https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.v
>>>>
>>>> Please tell us what version of iverilog you are using, and what changes
>>>> you
>>>> have made to the example. Just changing the type of 'result' to 'int' made
>>>> no difference for me.
>>>>
>>>> fuyong wrote:
>>>>> Hi,
>>>>>
>>>>> This is a test in Stuart Sutherland's PLI handbook, and it works well
>>>> with
>>>>> commercial tools. In Iverilog, we can have compile done, but run time
>>>> show:
>>>>>
>>>>> $pow(2, 3) returns 8
>>>>> Unsupported format 6.
>>>>> vvp: vpi_tasks.cc:179:virtual __vpiHandle*
>>>>> sysfunc_real::vpi_put_value(p_vpi_value, int): Assertion `0` failed.
>>>>>
>>>>> There are two $pow() calls .First one returns correct result, second one
>>>>> failed. with vpi_print, we find seems like the first pow() did not even
>>>>> called  our defined function (might be using the $pow in build-in
>>>> $pow()?).
>>>>> Any way, "result" is defined as int, not sure why the assertion is
>>>> trigger
>>>>> in run time.
>>>>>
>>>>>
>>>>>
>>>>> === Verilog side:
>>>>>      initial
>>>>>        begin
>>>>>          a = 1;
>>>>>          b = 0;
>>>>>          #1 $display("$pow(2,3) returns %d", $pow(2,3));
>>>>>          #1 result = $pow(a,b);
>>>>>          #1 $display("$pow(a,b) returns %d (a=%d b=%d)", result, a, b);
>>>>>
>>>>> === C side:
>>>>>
>>>>>      tf_data.type        = vpiSysFunc;
>>>>>      tf_data.sysfunctype = vpiSysFuncSized;
>>>>>      tf_data.tfname      = "$pow";
>>>>>      tf_data.calltf      = PLIbook_PowCalltf;
>>>>>      tf_data.compiletf   = PLIbook_PowCompiletf;
>>>>>      tf_data.sizetf      = PLIbook_PowSizetf;
>>>>>      vpi_register_systf(&tf_data);
>>>>>
>>>>>
>>>>> int PLIbook_PowCalltf(char *user_data)
>>>>> {
>>>>>      s_vpi_value value_s;
>>>>>      vpiHandle   systf_handle, arg_itr, arg_handle;
>>>>>      int         base, exp, result;
>>>>>
>>>>>      systf_handle = vpi_handle(vpiSysTfCall, NULL);
>>>>>      arg_itr = vpi_iterate(vpiArgument, systf_handle);
>>>>>      if (arg_itr == NULL) {
>>>>>        vpi_printf("ERROR: $pow failed to obtain systf arg handles\n");
>>>>>        return(0);
>>>>>      }
>>>>>
>>>>>      /* read base from systf arg 1 (compiletf has already verified) */
>>>>>      arg_handle = vpi_scan(arg_itr);
>>>>>      value_s.format = vpiIntVal;
>>>>>      vpi_get_value(arg_handle, &value_s);
>>>>>      base = value_s.value.integer;
>>>>>
>>>>>      /* read exponent from systf arg 2 (compiletf has already verified) */
>>>>>      arg_handle = vpi_scan(arg_itr);
>>>>>      vpi_free_object(arg_itr); /* not calling scan until returns null */
>>>>>      vpi_get_value(arg_handle, &value_s);
>>>>>      exp = value_s.value.integer;
>>>>>
>>>>>      /* calculate result of base to power of exponent */
>>>>>      result = (int)pow( (double)base, (double)exp );
>>>>>
>>>>>      /* write result to simulation as return value $pow */
>>>>>      value_s.value.integer = result;
>>>>>      vpi_put_value(systf_handle, &value_s, NULL, vpiNoDelay);
>>>>>      return(0);
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
> 
> 
> 

Re: [Iverilog-devel] Looking for a $fatal opinion

[Stephen W. <st...@ic...>]

The $fatal() task prints a standard message, and allows the user to
include other data. The standard does say that the simulator should
return an error, and with this patch I have in mind, it would wind up
replacing $finish_and_return(1) for you. I just want to make sure
nobody gets caught off guard in a bad way if I apply this patch.

On Mon, Oct 14, 2019 at 1:48 PM Niels Möller <ni...@ly...> wrote:
>
> Stephen Williams <st...@ic...> writes:
>
> > I have a bug report for Icarus Verilog requesting that $fatal cause
> > the vvp program to return EXIT_FAILURE or some-such, instead of
> > EXIT_SUCCESS like all other variants of $finish.
>
> In my verilog test programs, I currently use $finish_and_return(1) to
> indicate failure to the test driver script. If that can be replaced with
> $fatal (which I take is more standard?), that would be nice.
>
> How do other simulators implement $fatal? If Icarus departs from
> conventions by returning EXIT_FAILURE, then I would better stay with
> $finish_and_return(1) which will fail in a more obvious way if not using
> Icarus.
>
> Regards,
> /Niels
>
> --
> Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
> Internet email is subject to wholesale government surveillance.



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

Re: [Iverilog-devel] Looking for a $fatal opinion

[<ni...@ly...>]

Stephen Williams <st...@ic...> writes:

> I have a bug report for Icarus Verilog requesting that $fatal cause
> the vvp program to return EXIT_FAILURE or some-such, instead of
> EXIT_SUCCESS like all other variants of $finish.

In my verilog test programs, I currently use $finish_and_return(1) to
indicate failure to the test driver script. If that can be replaced with
$fatal (which I take is more standard?), that would be nice.

How do other simulators implement $fatal? If Icarus departs from
conventions by returning EXIT_FAILURE, then I would better stay with
$finish_and_return(1) which will fail in a more obvious way if not using
Icarus.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Re: [Iverilog-devel] vpi_put_value

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

I have pushed a fix for the second part of this. Note that you need to 
create a SFT file to inform the compiler about the different return value 
and provide the compiler with the path to the VPI module and associated SFT 
file, e.g.

% cat br_ml20191013.sft
$pow vpiSysFuncSized 32 signed
% iverilog-vpi br_ml20191013.c
Compiling br_ml20191013.c...
Making br_ml20191013.vpi from  br_ml20191013.o...
% iverilog -m ./br_ml20191013 br_ml20191013.v
% a.out

$pow PLI compiletf function.


$pow StartOfSim callback.

Start simulation pow_test.v
$pow(2,3) returns 8

$pow PLI calltf function.

$pow(a,b) returns          1 (a=1 b=0)

If you don't provide an explicit path, the compiler only searches for VPI 
modules and their associated SFT files in the iverilog base directory. This 
is now documented in the iverilog man page.

Martin Whitaker wrote:
> Hi Yong,
> 
> My apologies. I looked in the test suite for something to adapt to 
> reproduce the problem, found that, and didn't read it carefully enough!
> 
> If the compiler detects that a system function has constant arguments, it 
> will try to evaluate it at compile time, using a built-in implementation. 
> That is why your first call works. We should fix that.
> 
> The second call fails because the compiler is using the return type for the 
> built-in implementation (real) rather than the return type of the 
> replacement (32 bits). There is supposed to be a method of fixing that, by 
> suppling the compiler with a ".sft" file that provides the return types of 
> user-defined system functions, but that also appears to be broken in this 
> case. I'll look into that.
> 
> Martin
> 
> 
> On 14/10/19 08:23, fuyong wrote:
>> Hi, Martin,
>>
>> Finally figure out the reason. In the original example, the 1999 version I
>> have, intention of the test is to override the system defined function,
>> such as $pow. In your example, you used $my_pow() instead. Guess that in
>> Iverilog, system defined function calls could not be overwritten yet.
>> Actually I did noticed in my test with $pow(), the first $pow() called the
>> system pre-defined function, the second one goes to user defined function.
>> This is why the first $pow() passed, and the second one get error.
>>
>> The version I have is:
>> version 11.0 (devel) (s20150603-641-ga8318db2)
>>
>> Many thanks for the help!
>>
>> Yong
>>
>>
>>
>> On Sun, Oct 13, 2019 at 2:29 AM Martin Whitaker <
>> ic...@ma...> wrote:
>>
>>> I can't reproduce the failure. We have that example in the test suite
>>> already - see
>>>
>>>     https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.c
>>>     https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.v
>>>
>>> Please tell us what version of iverilog you are using, and what changes
>>> you
>>> have made to the example. Just changing the type of 'result' to 'int' made
>>> no difference for me.
>>>
>>> fuyong wrote:
>>>> Hi,
>>>>
>>>> This is a test in Stuart Sutherland's PLI handbook, and it works well
>>> with
>>>> commercial tools. In Iverilog, we can have compile done, but run time
>>> show:
>>>>
>>>> $pow(2, 3) returns 8
>>>> Unsupported format 6.
>>>> vvp: vpi_tasks.cc:179:virtual __vpiHandle*
>>>> sysfunc_real::vpi_put_value(p_vpi_value, int): Assertion `0` failed.
>>>>
>>>> There are two $pow() calls .First one returns correct result, second one
>>>> failed. with vpi_print, we find seems like the first pow() did not even
>>>> called  our defined function (might be using the $pow in build-in
>>> $pow()?).
>>>> Any way, "result" is defined as int, not sure why the assertion is
>>> trigger
>>>> in run time.
>>>>
>>>>
>>>>
>>>> === Verilog side:
>>>>     initial
>>>>       begin
>>>>         a = 1;
>>>>         b = 0;
>>>>         #1 $display("$pow(2,3) returns %d", $pow(2,3));
>>>>         #1 result = $pow(a,b);
>>>>         #1 $display("$pow(a,b) returns %d (a=%d b=%d)", result, a, b);
>>>>
>>>> === C side:
>>>>
>>>>     tf_data.type        = vpiSysFunc;
>>>>     tf_data.sysfunctype = vpiSysFuncSized;
>>>>     tf_data.tfname      = "$pow";
>>>>     tf_data.calltf      = PLIbook_PowCalltf;
>>>>     tf_data.compiletf   = PLIbook_PowCompiletf;
>>>>     tf_data.sizetf      = PLIbook_PowSizetf;
>>>>     vpi_register_systf(&tf_data);
>>>>
>>>>
>>>> int PLIbook_PowCalltf(char *user_data)
>>>> {
>>>>     s_vpi_value value_s;
>>>>     vpiHandle   systf_handle, arg_itr, arg_handle;
>>>>     int         base, exp, result;
>>>>
>>>>     systf_handle = vpi_handle(vpiSysTfCall, NULL);
>>>>     arg_itr = vpi_iterate(vpiArgument, systf_handle);
>>>>     if (arg_itr == NULL) {
>>>>       vpi_printf("ERROR: $pow failed to obtain systf arg handles\n");
>>>>       return(0);
>>>>     }
>>>>
>>>>     /* read base from systf arg 1 (compiletf has already verified) */
>>>>     arg_handle = vpi_scan(arg_itr);
>>>>     value_s.format = vpiIntVal;
>>>>     vpi_get_value(arg_handle, &value_s);
>>>>     base = value_s.value.integer;
>>>>
>>>>     /* read exponent from systf arg 2 (compiletf has already verified) */
>>>>     arg_handle = vpi_scan(arg_itr);
>>>>     vpi_free_object(arg_itr); /* not calling scan until returns null */
>>>>     vpi_get_value(arg_handle, &value_s);
>>>>     exp = value_s.value.integer;
>>>>
>>>>     /* calculate result of base to power of exponent */
>>>>     result = (int)pow( (double)base, (double)exp );
>>>>
>>>>     /* write result to simulation as return value $pow */
>>>>     value_s.value.integer = result;
>>>>     vpi_put_value(systf_handle, &value_s, NULL, vpiNoDelay);
>>>>     return(0);
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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

Re: [Iverilog-devel] vpi_put_value

[Stephen W. <st...@ic...>]

Great, but we don't want to lose the capability to inline functions
like $pow() in the compiler. Some people use this sort of thing to
calculate such compile-time constants as, for example, array vector
sizes.

In general, it is considered poor form to directly replace such basic
system functions, especially if that replacement leads to a different
prototype.

On Mon, Oct 14, 2019 at 7:03 AM Martin Whitaker
<ic...@ma...> wrote:
>
> Hi Yong,
>
> My apologies. I looked in the test suite for something to adapt to reproduce the problem, found
> that, and didn't read it carefully enough!
>
> If the compiler detects that a system function has constant arguments, it will try to evaluate it at
> compile time, using a built-in implementation. That is why your first call works. We should fix that.
>
> The second call fails because the compiler is using the return type for the built-in implementation
> (real) rather than the return type of the replacement (32 bits). There is supposed to be a method of
> fixing that, by suppling the compiler with a ".sft" file that provides the return types of
> user-defined system functions, but that also appears to be broken in this case. I'll look into that.
>
> Martin
>
>
> On 14/10/19 08:23, fuyong wrote:
> > Hi, Martin,
> >
> > Finally figure out the reason. In the original example, the 1999 version I
> > have, intention of the test is to override the system defined function,
> > such as $pow. In your example, you used $my_pow() instead. Guess that in
> > Iverilog, system defined function calls could not be overwritten yet.
> > Actually I did noticed in my test with $pow(), the first $pow() called the
> > system pre-defined function, the second one goes to user defined function.
> > This is why the first $pow() passed, and the second one get error.
> >
> > The version I have is:
> > version 11.0 (devel) (s20150603-641-ga8318db2)
> >
> > Many thanks for the help!
> >
> > Yong
> >
> >
> >
> > On Sun, Oct 13, 2019 at 2:29 AM Martin Whitaker <
> > ic...@ma...> wrote:
> >
> >> I can't reproduce the failure. We have that example in the test suite
> >> already - see
> >>
> >>     https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.c
> >>     https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.v
> >>
> >> Please tell us what version of iverilog you are using, and what changes
> >> you
> >> have made to the example. Just changing the type of 'result' to 'int' made
> >> no difference for me.
> >>
> >> fuyong wrote:
> >>> Hi,
> >>>
> >>> This is a test in Stuart Sutherland's PLI handbook, and it works well
> >> with
> >>> commercial tools. In Iverilog, we can have compile done, but run time
> >> show:
> >>>
> >>> $pow(2, 3) returns 8
> >>> Unsupported format 6.
> >>> vvp: vpi_tasks.cc:179:virtual __vpiHandle*
> >>> sysfunc_real::vpi_put_value(p_vpi_value, int): Assertion `0` failed.
> >>>
> >>> There are two $pow() calls .First one returns correct result, second one
> >>> failed. with vpi_print, we find seems like the first pow() did not even
> >>> called  our defined function (might be using the $pow in build-in
> >> $pow()?).
> >>> Any way, "result" is defined as int, not sure why the assertion is
> >> trigger
> >>> in run time.
> >>>
> >>>
> >>>
> >>> === Verilog side:
> >>>     initial
> >>>       begin
> >>>         a = 1;
> >>>         b = 0;
> >>>         #1 $display("$pow(2,3) returns %d", $pow(2,3));
> >>>         #1 result = $pow(a,b);
> >>>         #1 $display("$pow(a,b) returns %d (a=%d b=%d)", result, a, b);
> >>>
> >>> === C side:
> >>>
> >>>     tf_data.type        = vpiSysFunc;
> >>>     tf_data.sysfunctype = vpiSysFuncSized;
> >>>     tf_data.tfname      = "$pow";
> >>>     tf_data.calltf      = PLIbook_PowCalltf;
> >>>     tf_data.compiletf   = PLIbook_PowCompiletf;
> >>>     tf_data.sizetf      = PLIbook_PowSizetf;
> >>>     vpi_register_systf(&tf_data);
> >>>
> >>>
> >>> int PLIbook_PowCalltf(char *user_data)
> >>> {
> >>>     s_vpi_value value_s;
> >>>     vpiHandle   systf_handle, arg_itr, arg_handle;
> >>>     int         base, exp, result;
> >>>
> >>>     systf_handle = vpi_handle(vpiSysTfCall, NULL);
> >>>     arg_itr = vpi_iterate(vpiArgument, systf_handle);
> >>>     if (arg_itr == NULL) {
> >>>       vpi_printf("ERROR: $pow failed to obtain systf arg handles\n");
> >>>       return(0);
> >>>     }
> >>>
> >>>     /* read base from systf arg 1 (compiletf has already verified) */
> >>>     arg_handle = vpi_scan(arg_itr);
> >>>     value_s.format = vpiIntVal;
> >>>     vpi_get_value(arg_handle, &value_s);
> >>>     base = value_s.value.integer;
> >>>
> >>>     /* read exponent from systf arg 2 (compiletf has already verified) */
> >>>     arg_handle = vpi_scan(arg_itr);
> >>>     vpi_free_object(arg_itr); /* not calling scan until returns null */
> >>>     vpi_get_value(arg_handle, &value_s);
> >>>     exp = value_s.value.integer;
> >>>
> >>>     /* calculate result of base to power of exponent */
> >>>     result = (int)pow( (double)base, (double)exp );
> >>>
> >>>     /* write result to simulation as return value $pow */
> >>>     value_s.value.integer = result;
> >>>     vpi_put_value(systf_handle, &value_s, NULL, vpiNoDelay);
> >>>     return(0);
> >>> }
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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."

Re: [Iverilog-devel] Looking for a $fatal opinion

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

The IEEE standard seems quite clear on this (for once!) - it should return 
an error code.

Stephen Williams wrote:
> I have a bug report for Icarus Verilog requesting that $fatal cause
> the vvp program to return EXIT_FAILURE or some-such, instead of
> EXIT_SUCCESS like all other variants of $finish. It's easy enough to
> implement that, and I have done so, but that has led to at least one
> test in ivtest to "fail to run" even though it ran fine and is just
> returning a failure status.
> 
> So I guess my question is, will we be asking for trouble if $fatal()
> causes vvp to "fail" in the eyes of the command line or shell script
> that executes it? It is after all a success in the sense that it
> successfully ran the simulation program.
> 
> Humm...

[Iverilog-devel] Looking for a $fatal opinion

[Stephen W. <st...@ic...>]

I have a bug report for Icarus Verilog requesting that $fatal cause
the vvp program to return EXIT_FAILURE or some-such, instead of
EXIT_SUCCESS like all other variants of $finish. It's easy enough to
implement that, and I have done so, but that has led to at least one
test in ivtest to "fail to run" even though it ran fine and is just
returning a failure status.

So I guess my question is, will we be asking for trouble if $fatal()
causes vvp to "fail" in the eyes of the command line or shell script
that executes it? It is after all a success in the sense that it
successfully ran the simulation program.

Humm...


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

Re: [Iverilog-devel] vpi_put_value

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

Hi Yong,

My apologies. I looked in the test suite for something to adapt to reproduce the problem, found 
that, and didn't read it carefully enough!

If the compiler detects that a system function has constant arguments, it will try to evaluate it at 
compile time, using a built-in implementation. That is why your first call works. We should fix that.

The second call fails because the compiler is using the return type for the built-in implementation 
(real) rather than the return type of the replacement (32 bits). There is supposed to be a method of 
fixing that, by suppling the compiler with a ".sft" file that provides the return types of 
user-defined system functions, but that also appears to be broken in this case. I'll look into that.

Martin


On 14/10/19 08:23, fuyong wrote:
> Hi, Martin,
> 
> Finally figure out the reason. In the original example, the 1999 version I
> have, intention of the test is to override the system defined function,
> such as $pow. In your example, you used $my_pow() instead. Guess that in
> Iverilog, system defined function calls could not be overwritten yet.
> Actually I did noticed in my test with $pow(), the first $pow() called the
> system pre-defined function, the second one goes to user defined function.
> This is why the first $pow() passed, and the second one get error.
> 
> The version I have is:
> version 11.0 (devel) (s20150603-641-ga8318db2)
> 
> Many thanks for the help!
> 
> Yong
> 
> 
> 
> On Sun, Oct 13, 2019 at 2:29 AM Martin Whitaker <
> ic...@ma...> wrote:
> 
>> I can't reproduce the failure. We have that example in the test suite
>> already - see
>>
>>     https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.c
>>     https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.v
>>
>> Please tell us what version of iverilog you are using, and what changes
>> you
>> have made to the example. Just changing the type of 'result' to 'int' made
>> no difference for me.
>>
>> fuyong wrote:
>>> Hi,
>>>
>>> This is a test in Stuart Sutherland's PLI handbook, and it works well
>> with
>>> commercial tools. In Iverilog, we can have compile done, but run time
>> show:
>>>
>>> $pow(2, 3) returns 8
>>> Unsupported format 6.
>>> vvp: vpi_tasks.cc:179:virtual __vpiHandle*
>>> sysfunc_real::vpi_put_value(p_vpi_value, int): Assertion `0` failed.
>>>
>>> There are two $pow() calls .First one returns correct result, second one
>>> failed. with vpi_print, we find seems like the first pow() did not even
>>> called  our defined function (might be using the $pow in build-in
>> $pow()?).
>>> Any way, "result" is defined as int, not sure why the assertion is
>> trigger
>>> in run time.
>>>
>>>
>>>
>>> === Verilog side:
>>>     initial
>>>       begin
>>>         a = 1;
>>>         b = 0;
>>>         #1 $display("$pow(2,3) returns %d", $pow(2,3));
>>>         #1 result = $pow(a,b);
>>>         #1 $display("$pow(a,b) returns %d (a=%d b=%d)", result, a, b);
>>>
>>> === C side:
>>>
>>>     tf_data.type        = vpiSysFunc;
>>>     tf_data.sysfunctype = vpiSysFuncSized;
>>>     tf_data.tfname      = "$pow";
>>>     tf_data.calltf      = PLIbook_PowCalltf;
>>>     tf_data.compiletf   = PLIbook_PowCompiletf;
>>>     tf_data.sizetf      = PLIbook_PowSizetf;
>>>     vpi_register_systf(&tf_data);
>>>
>>>
>>> int PLIbook_PowCalltf(char *user_data)
>>> {
>>>     s_vpi_value value_s;
>>>     vpiHandle   systf_handle, arg_itr, arg_handle;
>>>     int         base, exp, result;
>>>
>>>     systf_handle = vpi_handle(vpiSysTfCall, NULL);
>>>     arg_itr = vpi_iterate(vpiArgument, systf_handle);
>>>     if (arg_itr == NULL) {
>>>       vpi_printf("ERROR: $pow failed to obtain systf arg handles\n");
>>>       return(0);
>>>     }
>>>
>>>     /* read base from systf arg 1 (compiletf has already verified) */
>>>     arg_handle = vpi_scan(arg_itr);
>>>     value_s.format = vpiIntVal;
>>>     vpi_get_value(arg_handle, &value_s);
>>>     base = value_s.value.integer;
>>>
>>>     /* read exponent from systf arg 2 (compiletf has already verified) */
>>>     arg_handle = vpi_scan(arg_itr);
>>>     vpi_free_object(arg_itr); /* not calling scan until returns null */
>>>     vpi_get_value(arg_handle, &value_s);
>>>     exp = value_s.value.integer;
>>>
>>>     /* calculate result of base to power of exponent */
>>>     result = (int)pow( (double)base, (double)exp );
>>>
>>>     /* write result to simulation as return value $pow */
>>>     value_s.value.integer = result;
>>>     vpi_put_value(systf_handle, &value_s, NULL, vpiNoDelay);
>>>     return(0);
>>> }
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> 

Re: [Iverilog-devel] vpi_put_value

[fuyong <fuy...@gm...>]

Hi, Martin,

Finally figure out the reason. In the original example, the 1999 version I
have, intention of the test is to override the system defined function,
such as $pow. In your example, you used $my_pow() instead. Guess that in
Iverilog, system defined function calls could not be overwritten yet.
Actually I did noticed in my test with $pow(), the first $pow() called the
system pre-defined function, the second one goes to user defined function.
This is why the first $pow() passed, and the second one get error.

The version I have is:
version 11.0 (devel) (s20150603-641-ga8318db2)

Many thanks for the help!

Yong



On Sun, Oct 13, 2019 at 2:29 AM Martin Whitaker <
ic...@ma...> wrote:

> I can't reproduce the failure. We have that example in the test suite
> already - see
>
>    https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.c
>    https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.v
>
> Please tell us what version of iverilog you are using, and what changes
> you
> have made to the example. Just changing the type of 'result' to 'int' made
> no difference for me.
>
> fuyong wrote:
> > Hi,
> >
> > This is a test in Stuart Sutherland's PLI handbook, and it works well
> with
> > commercial tools. In Iverilog, we can have compile done, but run time
> show:
> >
> > $pow(2, 3) returns 8
> > Unsupported format 6.
> > vvp: vpi_tasks.cc:179:virtual __vpiHandle*
> > sysfunc_real::vpi_put_value(p_vpi_value, int): Assertion `0` failed.
> >
> > There are two $pow() calls .First one returns correct result, second one
> > failed. with vpi_print, we find seems like the first pow() did not even
> > called  our defined function (might be using the $pow in build-in
> $pow()?).
> > Any way, "result" is defined as int, not sure why the assertion is
> trigger
> > in run time.
> >
> >
> >
> > === Verilog side:
> >    initial
> >      begin
> >        a = 1;
> >        b = 0;
> >        #1 $display("$pow(2,3) returns %d", $pow(2,3));
> >        #1 result = $pow(a,b);
> >        #1 $display("$pow(a,b) returns %d (a=%d b=%d)", result, a, b);
> >
> > === C side:
> >
> >    tf_data.type        = vpiSysFunc;
> >    tf_data.sysfunctype = vpiSysFuncSized;
> >    tf_data.tfname      = "$pow";
> >    tf_data.calltf      = PLIbook_PowCalltf;
> >    tf_data.compiletf   = PLIbook_PowCompiletf;
> >    tf_data.sizetf      = PLIbook_PowSizetf;
> >    vpi_register_systf(&tf_data);
> >
> >
> > int PLIbook_PowCalltf(char *user_data)
> > {
> >    s_vpi_value value_s;
> >    vpiHandle   systf_handle, arg_itr, arg_handle;
> >    int         base, exp, result;
> >
> >    systf_handle = vpi_handle(vpiSysTfCall, NULL);
> >    arg_itr = vpi_iterate(vpiArgument, systf_handle);
> >    if (arg_itr == NULL) {
> >      vpi_printf("ERROR: $pow failed to obtain systf arg handles\n");
> >      return(0);
> >    }
> >
> >    /* read base from systf arg 1 (compiletf has already verified) */
> >    arg_handle = vpi_scan(arg_itr);
> >    value_s.format = vpiIntVal;
> >    vpi_get_value(arg_handle, &value_s);
> >    base = value_s.value.integer;
> >
> >    /* read exponent from systf arg 2 (compiletf has already verified) */
> >    arg_handle = vpi_scan(arg_itr);
> >    vpi_free_object(arg_itr); /* not calling scan until returns null */
> >    vpi_get_value(arg_handle, &value_s);
> >    exp = value_s.value.integer;
> >
> >    /* calculate result of base to power of exponent */
> >    result = (int)pow( (double)base, (double)exp );
> >
> >    /* write result to simulation as return value $pow */
> >    value_s.value.integer = result;
> >    vpi_put_value(systf_handle, &value_s, NULL, vpiNoDelay);
> >    return(0);
> > }
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
>

Re: [Iverilog-devel] vpi_put_value

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

I can't reproduce the failure. We have that example in the test suite 
already - see

   https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.c
   https://github.com/steveicarus/ivtest/blob/master/vpi/pr1693971.v

Please tell us what version of iverilog you are using, and what changes you 
have made to the example. Just changing the type of 'result' to 'int' made 
no difference for me.

fuyong wrote:
> Hi,
> 
> This is a test in Stuart Sutherland's PLI handbook, and it works well with
> commercial tools. In Iverilog, we can have compile done, but run time show:
> 
> $pow(2, 3) returns 8
> Unsupported format 6.
> vvp: vpi_tasks.cc:179:virtual __vpiHandle*
> sysfunc_real::vpi_put_value(p_vpi_value, int): Assertion `0` failed.
> 
> There are two $pow() calls .First one returns correct result, second one
> failed. with vpi_print, we find seems like the first pow() did not even
> called  our defined function (might be using the $pow in build-in $pow()?).
> Any way, "result" is defined as int, not sure why the assertion is trigger
> in run time.
> 
> 
> 
> === Verilog side:
>    initial
>      begin
>        a = 1;
>        b = 0;
>        #1 $display("$pow(2,3) returns %d", $pow(2,3));
>        #1 result = $pow(a,b);
>        #1 $display("$pow(a,b) returns %d (a=%d b=%d)", result, a, b);
> 
> === C side:
> 
>    tf_data.type        = vpiSysFunc;
>    tf_data.sysfunctype = vpiSysFuncSized;
>    tf_data.tfname      = "$pow";
>    tf_data.calltf      = PLIbook_PowCalltf;
>    tf_data.compiletf   = PLIbook_PowCompiletf;
>    tf_data.sizetf      = PLIbook_PowSizetf;
>    vpi_register_systf(&tf_data);
> 
> 
> int PLIbook_PowCalltf(char *user_data)
> {
>    s_vpi_value value_s;
>    vpiHandle   systf_handle, arg_itr, arg_handle;
>    int         base, exp, result;
> 
>    systf_handle = vpi_handle(vpiSysTfCall, NULL);
>    arg_itr = vpi_iterate(vpiArgument, systf_handle);
>    if (arg_itr == NULL) {
>      vpi_printf("ERROR: $pow failed to obtain systf arg handles\n");
>      return(0);
>    }
> 
>    /* read base from systf arg 1 (compiletf has already verified) */
>    arg_handle = vpi_scan(arg_itr);
>    value_s.format = vpiIntVal;
>    vpi_get_value(arg_handle, &value_s);
>    base = value_s.value.integer;
> 
>    /* read exponent from systf arg 2 (compiletf has already verified) */
>    arg_handle = vpi_scan(arg_itr);
>    vpi_free_object(arg_itr); /* not calling scan until returns null */
>    vpi_get_value(arg_handle, &value_s);
>    exp = value_s.value.integer;
> 
>    /* calculate result of base to power of exponent */
>    result = (int)pow( (double)base, (double)exp );
> 
>    /* write result to simulation as return value $pow */
>    value_s.value.integer = result;
>    vpi_put_value(systf_handle, &value_s, NULL, vpiNoDelay);
>    return(0);
> }
> 
> 
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

[Iverilog-devel] vpi_put_value

[fuyong <fuy...@gm...>]

Hi,

This is a test in Stuart Sutherland's PLI handbook, and it works well with
commercial tools. In Iverilog, we can have compile done, but run time show:

$pow(2, 3) returns 8
Unsupported format 6.
vvp: vpi_tasks.cc:179:virtual __vpiHandle*
sysfunc_real::vpi_put_value(p_vpi_value, int): Assertion `0` failed.

There are two $pow() calls .First one returns correct result, second one
failed. with vpi_print, we find seems like the first pow() did not even
called  our defined function (might be using the $pow in build-in $pow()?).
Any way, "result" is defined as int, not sure why the assertion is trigger
in run time.



=== Verilog side:
  initial
    begin
      a = 1;
      b = 0;
      #1 $display("$pow(2,3) returns %d", $pow(2,3));
      #1 result = $pow(a,b);
      #1 $display("$pow(a,b) returns %d (a=%d b=%d)", result, a, b);

=== C side:

  tf_data.type        = vpiSysFunc;
  tf_data.sysfunctype = vpiSysFuncSized;
  tf_data.tfname      = "$pow";
  tf_data.calltf      = PLIbook_PowCalltf;
  tf_data.compiletf   = PLIbook_PowCompiletf;
  tf_data.sizetf      = PLIbook_PowSizetf;
  vpi_register_systf(&tf_data);


int PLIbook_PowCalltf(char *user_data)
{
  s_vpi_value value_s;
  vpiHandle   systf_handle, arg_itr, arg_handle;
  int         base, exp, result;

  systf_handle = vpi_handle(vpiSysTfCall, NULL);
  arg_itr = vpi_iterate(vpiArgument, systf_handle);
  if (arg_itr == NULL) {
    vpi_printf("ERROR: $pow failed to obtain systf arg handles\n");
    return(0);
  }

  /* read base from systf arg 1 (compiletf has already verified) */
  arg_handle = vpi_scan(arg_itr);
  value_s.format = vpiIntVal;
  vpi_get_value(arg_handle, &value_s);
  base = value_s.value.integer;

  /* read exponent from systf arg 2 (compiletf has already verified) */
  arg_handle = vpi_scan(arg_itr);
  vpi_free_object(arg_itr); /* not calling scan until returns null */
  vpi_get_value(arg_handle, &value_s);
  exp = value_s.value.integer;

  /* calculate result of base to power of exponent */
  result = (int)pow( (double)base, (double)exp );

  /* write result to simulation as return value $pow */
  value_s.value.integer = result;
  vpi_put_value(systf_handle, &value_s, NULL, vpiNoDelay);
  return(0);
}

[Iverilog-devel] plusere -> pulsere

[Pablo B. <pb...@li...>]

Hi.

Just to let you know that, while trying to instrumentate the IV tools, I found that the t_vpi_delay type member 'pulsere_flag' is mispelled as 'plusere_flag':

https://github.com/steveicarus/iverilog/search?q=plusere&unscoped_q=plusere

Regards.

Re: [Iverilog-devel] Priority case and default case items.

[Bryan M. <bmu...@gm...>]

The paper I linked to explains that the synthesis tools don't necessarily
evaluate the various cases in the given order, *unless* you use the
priority modifier.  This can matter if foo (in your example) is able to
match multiple cases.

The paper also says that the simulator should issue a runtime warning if in
your Example #4 foo evaluates to something other than 1 or 2.  Personally,
making this only a warning is...stupid (yet strangely consistent with other
less helpful parts of SV :-/).  It really should just be an error.

Bryan

On Wed, Oct 9, 2019 at 8:14 PM Stephen Williams <st...@ic...> wrote:

> Fair point, although the "default:" also has meaning to the synthesizer
> and may render the priority keyword moot in synthesis too. For example:
>
> // Example #1
> case (foo)
> 1: bar = a;
> 2: bar = b;
> default: bar = x;
> endcase
>
> and
>
> // Example #2
> priority case (foo)
> 1: bar = a;
> 2: bar = b;
> default: bar = x;
> endcase
>
> are indistinguishable to a simulator AND to a synthesizer, but:
>
> // Example #3
> case (foo)
> 1: bar = a;
> 2: bar = b;
> endcase
>
> is very different (it is a latch) from:
>
> // Example #4
> priority case (foo)
> 1: bar = a;
> 2: bar = b;
> endcase
>
> which is a combinational mux. Furthermore, #4 is not necessarily the same
> as #1 or #2. If #4 is what is desired, then #2 is probably not a way to
> achieve it, although #1 is the best approximation available without the
> priority keyword. Thus, I suggest that #2 may deserve a gentle warning at
> compile time (but not at run time.)
>
> On Wed, Oct 9, 2019 at 5:54 PM Bryan Murdock <bmu...@gm...> wrote:
>
>> This paper has a lot of explanation about priority (and unique):
>>
>>
>> http://www.sutherland-hdl.com/papers/2005-SNUG-paper_SystemVerilog_unique_and_priority.pdf
>>
>> My quick summary is that they are directives meant mostly for synthesis
>> tools.  If someone provides a default case in their priority case, yes,
>> they are making the priority statement redundant in the simulation, but it
>> might still be a very important directive for synthesis.  So don't nag them
>> about it with a warning 🙂
>>
>> Bryan
>>
>>
>> On Wed, Oct 9, 2019, 10:39 AM Stephen Williams <st...@ic...> wrote:
>>
>>> Here's a question. There is this:
>>>
>>> priority case (foo)
>>>  1: stmt1;
>>>  2: stmt2;
>>>  default: stmt_default;
>>> endcase
>>>
>>> The priority case "shall issue a violation report if no case_item
>>> matches."
>>>
>>> The default: statement makes it so that every possible value of foo
>>> has a case item, if the "default" case is considered a case item, and
>>> by the BNF, it is indeed a case_item. But the "default:" makes the
>>> "priority" moot. So should this print a violation message or not?
>>>
>>> (I'm thinking, it should not, but a compile time warning may make
>>> sense. But I can see logic for the other course too.)
>>>
>>> --
>>> 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."
>>>
>>>
>>> _______________________________________________
>>> 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... <ste...@gm...>              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."
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] Priority case and default case items.

[Stephen W. <st...@ic...>]

Fair point, although the "default:" also has meaning to the synthesizer and
may render the priority keyword moot in synthesis too. For example:

// Example #1
case (foo)
1: bar = a;
2: bar = b;
default: bar = x;
endcase

and

// Example #2
priority case (foo)
1: bar = a;
2: bar = b;
default: bar = x;
endcase

are indistinguishable to a simulator AND to a synthesizer, but:

// Example #3
case (foo)
1: bar = a;
2: bar = b;
endcase

is very different (it is a latch) from:

// Example #4
priority case (foo)
1: bar = a;
2: bar = b;
endcase

which is a combinational mux. Furthermore, #4 is not necessarily the same
as #1 or #2. If #4 is what is desired, then #2 is probably not a way to
achieve it, although #1 is the best approximation available without the
priority keyword. Thus, I suggest that #2 may deserve a gentle warning at
compile time (but not at run time.)

On Wed, Oct 9, 2019 at 5:54 PM Bryan Murdock <bmu...@gm...> wrote:

> This paper has a lot of explanation about priority (and unique):
>
>
> http://www.sutherland-hdl.com/papers/2005-SNUG-paper_SystemVerilog_unique_and_priority.pdf
>
> My quick summary is that they are directives meant mostly for synthesis
> tools.  If someone provides a default case in their priority case, yes,
> they are making the priority statement redundant in the simulation, but it
> might still be a very important directive for synthesis.  So don't nag them
> about it with a warning 🙂
>
> Bryan
>
>
> On Wed, Oct 9, 2019, 10:39 AM Stephen Williams <st...@ic...> wrote:
>
>> Here's a question. There is this:
>>
>> priority case (foo)
>>  1: stmt1;
>>  2: stmt2;
>>  default: stmt_default;
>> endcase
>>
>> The priority case "shall issue a violation report if no case_item
>> matches."
>>
>> The default: statement makes it so that every possible value of foo
>> has a case item, if the "default" case is considered a case item, and
>> by the BNF, it is indeed a case_item. But the "default:" makes the
>> "priority" moot. So should this print a violation message or not?
>>
>> (I'm thinking, it should not, but a compile time warning may make
>> sense. But I can see logic for the other course too.)
>>
>> --
>> 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."
>>
>>
>> _______________________________________________
>> 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... <ste...@gm...>              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."

Re: [Iverilog-devel] Priority case and default case items.

[Bryan M. <bmu...@gm...>]

This paper has a lot of explanation about priority (and unique):

http://www.sutherland-hdl.com/papers/2005-SNUG-paper_SystemVerilog_unique_and_priority.pdf

My quick summary is that they are directives meant mostly for synthesis
tools.  If someone provides a default case in their priority case, yes,
they are making the priority statement redundant in the simulation, but it
might still be a very important directive for synthesis.  So don't nag them
about it with a warning 🙂

Bryan


On Wed, Oct 9, 2019, 10:39 AM Stephen Williams <st...@ic...> wrote:

> Here's a question. There is this:
>
> priority case (foo)
>  1: stmt1;
>  2: stmt2;
>  default: stmt_default;
> endcase
>
> The priority case "shall issue a violation report if no case_item matches."
>
> The default: statement makes it so that every possible value of foo
> has a case item, if the "default" case is considered a case item, and
> by the BNF, it is indeed a case_item. But the "default:" makes the
> "priority" moot. So should this print a violation message or not?
>
> (I'm thinking, it should not, but a compile time warning may make
> sense. But I can see logic for the other course too.)
>
> --
> 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."
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>