iverilog-devel Mailing List for Icarus Verilog (Page 7)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

>
> Thanks,
>
>

Martin,

Thank you for your reply. I'll try to create some simple example of the 
fails I've seen.

Regards,
Doug

On 01/20/20 14:34, Martin Whitaker wrote:
> Sorry you haven't had a reply sooner - your message appears to have 
> got stuck on the SourceForge server for two weeks.
>
> enum types are mostly supported, so if you find problems, please open 
> bug reports, giving a simple example, and mentioning what version of 
> iverilog you are using. These days, most bugs are reported as issues 
> on GitHub.
>
> I don't think there's any way to work around unsupported behaviour 
> like you suggest.
>
> Douglas Sojourner wrote:
>> I realize that iverilog does not claim to fully support system 
>> verilog, so this is a request for help, not a complaint.
>>
>> There are a number of enum types delcared in the files for this 
>> model, and they are causing problems in several ways:
>> 1) In a package, a number of parameters are delcared as enum types. 
>> The compile fails with a "syntax error" message pointing to the 
>> appropriate line.
>> 2) Some functions have parameters or return values that are enum 
>> types. In this case iverilog silently hangs while elaborating.
>>
>> In all cases, changing the type to int works. Is there a 
>> straightforward way to cause iverilog to treat enums as ints in 
>> contexts where it does not explicitly recognize them?
>>
>> Thanks for your help,
>>
>> Doug Sojourner
>>
>>
>> _______________________________________________
>> 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
>
>

Sorry you haven't had a reply sooner - your message appears to have got 
stuck on the SourceForge server for two weeks.

enum types are mostly supported, so if you find problems, please open bug 
reports, giving a simple example, and mentioning what version of iverilog 
you are using. These days, most bugs are reported as issues on GitHub.

I don't think there's any way to work around unsupported behaviour like you 
suggest.

Douglas Sojourner wrote:
> I realize that iverilog does not claim to fully support system verilog, so 
> this is a request for help, not a complaint.
> 
> There are a number of enum types delcared in the files for this model, and 
> they are causing problems in several ways:
> 1) In a package, a number of parameters are delcared as enum types. The 
> compile fails with a "syntax error" message pointing to the appropriate line.
> 2) Some functions have parameters or return values that are enum types. In 
> this case iverilog silently hangs while elaborating.
> 
> In all cases, changing the type to int works. Is there a straightforward 
> way to cause iverilog to treat enums as ints in contexts where it does not 
> explicitly recognize them?
> 
> Thanks for your help,
> 
> Doug Sojourner
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

I realize that iverilog does not claim to fully support system verilog, 
so this is a request for help, not a complaint.

There are a number of enum types delcared in the files for this model, 
and they are causing problems in several ways:
1) In a package, a number of parameters are delcared as enum types. The 
compile fails with a "syntax error" message pointing to the appropriate 
line.
2) Some functions have parameters or return values that are enum types. 
In this case iverilog silently hangs while elaborating.

In all cases, changing the type to int works. Is there a straightforward 
way to cause iverilog to treat enums as ints in contexts where it does 
not explicitly recognize them?

Thanks for your help,

Doug Sojourner

Yes, this is https://sourceforge.net/p/iverilog/bugs/916/.

If you try the same thing with $monitor, you get the following message:

SORRY: test.v:6: currently only simple signals or constant expressions may 
be passed to $monitor.
NOTE: You can work around this by assigning the desired expression to an
       intermediate net (using a continuous assignment) and passing that net
       to $monitor.

and you can use the same workaround.

Ideally we'd output a similar message in your case, but we don't know what 
a user-defined system function is going to do with its arguments.

fuyong wrote:
> um,, the same code actually can work with commercial simulator. Any
> suggestion on how to change the coding?
> 
> On Mon, Dec 23, 2019 at 4:05 AM Martin Whitaker <
> ic...@ma...> wrote:
> 
>> You are getting a vpiHandle to a temporary value (the evaluation of the
>> expression {src1,dst2}) in the call to $put_flag and using it in your
>> EndOfSimTime callback. That can't work - the temporary value only exists
>> for the lifetime of the call to $put_flag.
>>
>> Yong Fu wrote:
>>> Hi,
>>>
>>> Have put a test case in git:
>>>
>>> https://github.com/tangeraise/iv_debug
>>>
>>> Thanks,
>>>
>>>> On Dec 21, 2019, at 1:15 PM, Martin Whitaker <
>> ic...@ma...> wrote:
>>>>
>>>> fuyong wrote:
>>>>> Hi,
>>>>> We are compiling the new version from git to check mainly the new VPI
>>>>> feature of EndOfSimTime. And we have met the runtime error:
>>>>> vvp -M . -m vpi1 a.out
>>>>> vvp: vthread.cc:138: const vvp_vector4_t& vthread:s:peek_vec4(unsigned
>>>>> int): Assertion `depth < size' failed.
>>>>> Any chance to tell what is wrong?
>>>>
>>>> Not without a test case that allows us to reproduce the error.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
> 

um,, the same code actually can work with commercial simulator. Any
suggestion on how to change the coding?

On Mon, Dec 23, 2019 at 4:05 AM Martin Whitaker <
ic...@ma...> wrote:

> You are getting a vpiHandle to a temporary value (the evaluation of the
> expression {src1,dst2}) in the call to $put_flag and using it in your
> EndOfSimTime callback. That can't work - the temporary value only exists
> for the lifetime of the call to $put_flag.
>
> Yong Fu wrote:
> > Hi,
> >
> > Have put a test case in git:
> >
> > https://github.com/tangeraise/iv_debug
> >
> > Thanks,
> >
> >> On Dec 21, 2019, at 1:15 PM, Martin Whitaker <
> ic...@ma...> wrote:
> >>
> >> fuyong wrote:
> >>> Hi,
> >>> We are compiling the new version from git to check mainly the new VPI
> >>> feature of EndOfSimTime. And we have met the runtime error:
> >>> vvp -M . -m vpi1 a.out
> >>> vvp: vthread.cc:138: const vvp_vector4_t& vthread:s:peek_vec4(unsigned
> >>> int): Assertion `depth < size' failed.
> >>> Any chance to tell what is wrong?
> >>
> >> Not without a test case that allows us to reproduce the error.
> >>
> >>
> >> _______________________________________________
> >> 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
>

You are getting a vpiHandle to a temporary value (the evaluation of the 
expression {src1,dst2}) in the call to $put_flag and using it in your 
EndOfSimTime callback. That can't work - the temporary value only exists 
for the lifetime of the call to $put_flag.

Yong Fu wrote:
> Hi,
> 
> Have put a test case in git:
> 
> https://github.com/tangeraise/iv_debug
> 
> Thanks,
> 
>> On Dec 21, 2019, at 1:15 PM, Martin Whitaker <ic...@ma...> wrote:
>>
>> fuyong wrote:
>>> Hi,
>>> We are compiling the new version from git to check mainly the new VPI
>>> feature of EndOfSimTime. And we have met the runtime error:
>>> vvp -M . -m vpi1 a.out
>>> vvp: vthread.cc:138: const vvp_vector4_t& vthread:s:peek_vec4(unsigned
>>> int): Assertion `depth < size' failed.
>>> Any chance to tell what is wrong?
>>
>> Not without a test case that allows us to reproduce the error.
>>
>>
>> _______________________________________________
>> 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
> 

As this was blocking my fix for issue #289, I've pushed a fix to the master 
branch. If there is some restriction on class access to enclosing scopes 
that I've missed, it can be fixed up later.

Martin Whitaker wrote:
> Consider this example:
> 
>    module test;
> 
>      integer i;
> 
>      class myclass;
>        integer j;
>        function void init();
>          j = i;
>        endfunction
>      endclass
> 
>    endmodule
> 
> This example example compiles without error on EDA playground. But iverilog 
> outputs the following error message:
> 
>    test.v:8: error: Unable to bind wire/reg/memory `i' in `myclass.init'
> 
> In elab_scope.cc there is this comment:
> 
>    // Class scopes have no parent scope, because references are
>    // not allowed to escape a class method. But they are allowed
>    // to reference the compilation unit scope.
> 
> but I can find no justification for this in the IEEE standard. So where did 
> this come from?

Hi,

Have put a test case in git:

https://github.com/tangeraise/iv_debug

Thanks,

> On Dec 21, 2019, at 1:15 PM, Martin Whitaker <ic...@ma...> wrote:
> 
> fuyong wrote:
>> Hi,
>> We are compiling the new version from git to check mainly the new VPI
>> feature of EndOfSimTime. And we have met the runtime error:
>> vvp -M . -m vpi1 a.out
>> vvp: vthread.cc:138: const vvp_vector4_t& vthread:s:peek_vec4(unsigned
>> int): Assertion `depth < size' failed.
>> Any chance to tell what is wrong?
> 
> Not without a test case that allows us to reproduce the error.
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

fuyong wrote:
> Hi,
> 
> We are compiling the new version from git to check mainly the new VPI
> feature of EndOfSimTime. And we have met the runtime error:
> 
> vvp -M . -m vpi1 a.out
> vvp: vthread.cc:138: const vvp_vector4_t& vthread:s:peek_vec4(unsigned
> int): Assertion `depth < size' failed.
> 
> Any chance to tell what is wrong?

Not without a test case that allows us to reproduce the error.

Consider this example:

   module test;

     integer i;

     class myclass;
       integer j;
       function void init();
         j = i;
       endfunction
     endclass

   endmodule

This example example compiles without error on EDA playground. But iverilog 
outputs the following error message:

   test.v:8: error: Unable to bind wire/reg/memory `i' in `myclass.init'

In elab_scope.cc there is this comment:

   // Class scopes have no parent scope, because references are
   // not allowed to escape a class method. But they are allowed
   // to reference the compilation unit scope.

but I can find no justification for this in the IEEE standard. So where did 
this come from?

Hi,

We are compiling the new version from git to check mainly the new VPI
feature of EndOfSimTime. And we have met the runtime error:

vvp -M . -m vpi1 a.out
vvp: vthread.cc:138: const vvp_vector4_t& vthread:s:peek_vec4(unsigned
int): Assertion `depth < size' failed.

Any chance to tell what is wrong?

Thanks

Given that nobody has asked for anything more, it's fair to assume that the 
existing support for attributes in the target API is adequate. Providing we 
correctly parse and discard other attributes, it doesn't matter what use 
other tools make of them.

Stephen Williams wrote:
> Attributes that I run into in i.e. the Xilinx context tend to be
> either simple booleans, or strings. For example, INIT values tend to
> be strings, not large numeric values. Parameters seem to be how people
> pass around complex numeric values, which makes sense.
> 
> I might put some effort into attributes, but currently they are not at
> all available at run time, and they probably don't make much sense
> there.
> 
> On Tue, Nov 19, 2019 at 10:18 AM Martin Whitaker
> <ic...@ma...> wrote:
>>
>> Indeed, the standard allows an attribute value to be any constant
>> expression. So real values would be allowed too. But nobody has complained
>> that they aren't accepted, so I guess they aren't widely used.
>>
>> Stephen Williams wrote:
>>> Recently I noticed that there may be a problem with numeric attributes
>>> at the ivl_target.h API. Specifically, the API is converting numeric
>>> attributes to host integers. This winds up truncating values to 64
>>> (63) bits, and drops x and z bit values. My reading of the standard is
>>> that numeric attributes have no such limitations, so it appears that
>>> the API is wrong.
>>>
>>> So, my questions are:
>>>
>>> 1) Anybody out there using attributes? They are accessible at the
>>> ivl_target.h API level, so if you are writing code generators, you
>>> might be using attributes. I don't think they are available through
>>> PLI.
>>>
>>> 2) Anybody have an opinion on whether numeric attributes are treated
>>> as 4-value logic in other tools? Or am I fooling myself and numeric
>>> attributes really do evaluate down to host integers?
>>>
>>> 3) What do other tools do?
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 

You might want to take a look to see how simbus handles this. Simbus
is on github, look for it there.

On Wed, Nov 20, 2019 at 3:09 PM Stephen Williams <st...@ic...> wrote:
>
> I think that you already have what you need. cbAtStartOfSimTime is
> already implemented, and cbReadOnlySync can then be scheduled to be
> called at the end of the simulation time.
>
> On Wed, Nov 20, 2019 at 12:00 AM fuyong <fuy...@gm...> wrote:
> >
> > Hi,
> >
> > At first, I think cbAtEndOfSimTime and cbAtBeginOfSimTime could be used similarly, as the data at the end of one Sim Time is the beginning of the next Sim Time. We have a project , to partition a big design into several pieces. Each piece will run in one simulator. VPI put/get_value are used to communicate in between the several iverilog processes.  So the question is, if we use AtStartofSimTime, the data passed from partition #1 to partition #2 will be the data of the previous simulation time slot, then the waveform will show like one cycle delayed. to pass data use AtEndOfSimTime will not have this issue in commercial simulator.
> >
> > Any plan to implement AtStarOfSimTime?
> >
> >
> > _______________________________________________
> > 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."

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

I think that you already have what you need. cbAtStartOfSimTime is
already implemented, and cbReadOnlySync can then be scheduled to be
called at the end of the simulation time.

On Wed, Nov 20, 2019 at 12:00 AM fuyong <fuy...@gm...> wrote:
>
> Hi,
>
> At first, I think cbAtEndOfSimTime and cbAtBeginOfSimTime could be used similarly, as the data at the end of one Sim Time is the beginning of the next Sim Time. We have a project , to partition a big design into several pieces. Each piece will run in one simulator. VPI put/get_value are used to communicate in between the several iverilog processes.  So the question is, if we use AtStartofSimTime, the data passed from partition #1 to partition #2 will be the data of the previous simulation time slot, then the waveform will show like one cycle delayed. to pass data use AtEndOfSimTime will not have this issue in commercial simulator.
>
> Any plan to implement AtStarOfSimTime?
>
>
> _______________________________________________
> 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."

Hi,

At first, I think cbAtEndOfSimTime and cbAtBeginOfSimTime could be used
similarly, as the data at the end of one Sim Time is the beginning of the
next Sim Time. We have a project , to partition a big design into several
pieces. Each piece will run in one simulator. VPI put/get_value are used to
communicate in between the several iverilog processes.  So the question is,
if we use AtStartofSimTime, the data passed from partition #1 to partition
#2 will be the data of the previous simulation time slot, then the waveform
will show like one cycle delayed. to pass data use AtEndOfSimTime will not
have this issue in commercial simulator.

Any plan to implement AtStarOfSimTime?

Attributes that I run into in i.e. the Xilinx context tend to be
either simple booleans, or strings. For example, INIT values tend to
be strings, not large numeric values. Parameters seem to be how people
pass around complex numeric values, which makes sense.

I might put some effort into attributes, but currently they are not at
all available at run time, and they probably don't make much sense
there.

On Tue, Nov 19, 2019 at 10:18 AM Martin Whitaker
<ic...@ma...> wrote:
>
> Indeed, the standard allows an attribute value to be any constant
> expression. So real values would be allowed too. But nobody has complained
> that they aren't accepted, so I guess they aren't widely used.
>
> Stephen Williams wrote:
> > Recently I noticed that there may be a problem with numeric attributes
> > at the ivl_target.h API. Specifically, the API is converting numeric
> > attributes to host integers. This winds up truncating values to 64
> > (63) bits, and drops x and z bit values. My reading of the standard is
> > that numeric attributes have no such limitations, so it appears that
> > the API is wrong.
> >
> > So, my questions are:
> >
> > 1) Anybody out there using attributes? They are accessible at the
> > ivl_target.h API level, so if you are writing code generators, you
> > might be using attributes. I don't think they are available through
> > PLI.
> >
> > 2) Anybody have an opinion on whether numeric attributes are treated
> > as 4-value logic in other tools? Or am I fooling myself and numeric
> > attributes really do evaluate down to host integers?
> >
> > 3) What do other tools do?
> >
> >
>
>
>
> _______________________________________________
> 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."

Indeed, the standard allows an attribute value to be any constant 
expression. So real values would be allowed too. But nobody has complained 
that they aren't accepted, so I guess they aren't widely used.

Stephen Williams wrote:
> Recently I noticed that there may be a problem with numeric attributes
> at the ivl_target.h API. Specifically, the API is converting numeric
> attributes to host integers. This winds up truncating values to 64
> (63) bits, and drops x and z bit values. My reading of the standard is
> that numeric attributes have no such limitations, so it appears that
> the API is wrong.
> 
> So, my questions are:
> 
> 1) Anybody out there using attributes? They are accessible at the
> ivl_target.h API level, so if you are writing code generators, you
> might be using attributes. I don't think they are available through
> PLI.
> 
> 2) Anybody have an opinion on whether numeric attributes are treated
> as 4-value logic in other tools? Or am I fooling myself and numeric
> attributes really do evaluate down to host integers?
> 
> 3) What do other tools do?
> 
> 

Recently I noticed that there may be a problem with numeric attributes
at the ivl_target.h API. Specifically, the API is converting numeric
attributes to host integers. This winds up truncating values to 64
(63) bits, and drops x and z bit values. My reading of the standard is
that numeric attributes have no such limitations, so it appears that
the API is wrong.

So, my questions are:

1) Anybody out there using attributes? They are accessible at the
ivl_target.h API level, so if you are writing code generators, you
might be using attributes. I don't think they are available through
PLI.

2) Anybody have an opinion on whether numeric attributes are treated
as 4-value logic in other tools? Or am I fooling myself and numeric
attributes really do evaluate down to host integers?

3) What do other tools do?

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

Thanks for reporting this. I've pushed a fix to git master. Because it is a 
change to the API (albeit a correction), I don't think we can backport this 
to v10.

Pablo Bleyer wrote:
> 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.
> 
> 
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

This sort of situation is addressed with the simbus project. The exact
intent of simbus is to detach the test bench and dut into separate
processes, and even different languages.

On Tue, Nov 5, 2019 at 2:33 PM fuyong <fuy...@gm...> wrote:
>
> A brainstorming for parallel simulation.
>
> Assuming the following design:
>
> module TB;
>      ...
>     always #5 clk = ~clk;   // generate original clock
>      // a gated clock that will be used in subinstance M1
>     assign gated_clock = clk & a_net_generated_in_this_module;
>
>     always @(posedge clk)   Q <= something;  // non blocking, output to M1
>
>      M1 M1_inst (gated_clk, Q, ...);
> endmodule
> module M(clk, din, dout...);
>
> We want TB run in one iverilog program, and M1 run in another. The real TB and M1 could be large, doing so might give some perf improvement. Interface between TB and M1 is not too complicated, so manual partition is OK.
>
> Question is, what is the good time region at a simulation time slot should gated_clock and Q send from tb to M1? I assume Q at ArEndOfSimTime (postponed) , and gated_clock at NBASynch(pre-NBA) might be the most safe one. But this means at one time slot two VPI calls ( or even more consider the iteratinos?) should be used so runtiem performance impacted. And another thing is iVerilog does not have pre-NBA implemented in the current version.
>
> Or any other suggestions?
>
> _______________________________________________
> 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."

A brainstorming for parallel simulation.

Assuming the following design:

module TB;
     ...
    always #5 clk = ~clk;   // generate original clock
     // a gated clock that will be used in subinstance M1
    assign gated_clock = clk & a_net_generated_in_this_module;

    always @(posedge clk)   Q <= something;  // non blocking, output to M1

     M1 M1_inst (gated_clk, Q, ...);
endmodule
module M(clk, din, dout...);

We want TB run in one iverilog program, and M1 run in another. The real TB
and M1 could be large, doing so might give some perf improvement. Interface
between TB and M1 is not too complicated, so manual partition is OK.

Question is, what is the good time region at a simulation time slot should
gated_clock and Q send from tb to M1? I assume Q at ArEndOfSimTime
(postponed) , and gated_clock at NBASynch(pre-NBA) might be the most safe
one. But this means at one time slot two VPI calls ( or even more consider
the iteratinos?) should be used so runtiem performance impacted. And
another thing is iVerilog does not have pre-NBA implemented in the current
version.

Or any other suggestions?

I started by creating a separate utility for automatically generating SFT 
files, but it was so trivial that it seemed less work to just integrate it 
into the compiler proper.

I've done the merge. Let me know if there are any problems. I'll retest the 
Windows build now.

Stephen Williams wrote:
> Interesting idea from Niels, but I feel comfortable with Martin's
> description of things, so go ahead and merge it. I can run regression
> tests on my Mac to verify it doesn't break anything Mac.
> 
> On Mon, Nov 4, 2019 at 12:32 PM Martin Whitaker
> <ic...@ma...> wrote:
>>
>> I've verified on Linux and Windows. I can't verify on Mac OS - I don't own
>> any Apple hardware. But I can see no special handling of DLLs and VPI
>> modules for Mac OS in the make files, so I expect it to work. Note that the
>> new callback table for making things work in Windows is only included when
>> building for Windows - VPI modules are unchanged for Linux and Mac OS,
>> apart from a few bug fixes.
>>
>> I have left the code for reading SFT files in the compiler, so users'
>> existing test scripts won't break if they pass those files on the command line.
>>
>> I was not intending to backport this to v10.
>>
>> Stephen Williams wrote:
>>> 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
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 

Interesting idea from Niels, but I feel comfortable with Martin's
description of things, so go ahead and merge it. I can run regression
tests on my Mac to verify it doesn't break anything Mac.

On Mon, Nov 4, 2019 at 12:32 PM Martin Whitaker
<ic...@ma...> wrote:
>
> I've verified on Linux and Windows. I can't verify on Mac OS - I don't own
> any Apple hardware. But I can see no special handling of DLLs and VPI
> modules for Mac OS in the make files, so I expect it to work. Note that the
> new callback table for making things work in Windows is only included when
> building for Windows - VPI modules are unchanged for Linux and Mac OS,
> apart from a few bug fixes.
>
> I have left the code for reading SFT files in the compiler, so users'
> existing test scripts won't break if they pass those files on the command line.
>
> I was not intending to backport this to v10.
>
> Stephen Williams wrote:
> > 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
> >
> >
> >
>
>
>
> _______________________________________________
> 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."

I've verified on Linux and Windows. I can't verify on Mac OS - I don't own 
any Apple hardware. But I can see no special handling of DLLs and VPI 
modules for Mac OS in the make files, so I expect it to work. Note that the 
new callback table for making things work in Windows is only included when 
building for Windows - VPI modules are unchanged for Linux and Mac OS, 
apart from a few bug fixes.

I have left the code for reading SFT files in the compiler, so users' 
existing test scripts won't break if they pass those files on the command line.

I was not intending to backport this to v10.

Stephen Williams wrote:
> 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
> 
> 
> 

2008	Jan (98)	Feb (33)	Mar (60)	Apr (126)	May (186)	Jun (65)	Jul (19)	Aug (95)	Sep (86)	Oct (81)	Nov (46)	Dec (87)
2009	Jan (47)	Feb (79)	Mar (138)	Apr (44)	May (113)	Jun (133)	Jul (59)	Aug (84)	Sep (87)	Oct (65)	Nov (51)	Dec (141)
2010	Jan (63)	Feb (22)	Mar (28)	Apr (41)	May (59)	Jun (18)	Jul (7)	Aug (11)	Sep (85)	Oct (28)	Nov (51)	Dec (16)
2011	Jan (29)	Feb (35)	Mar (65)	Apr (106)	May (58)	Jun (8)	Jul (34)	Aug (52)	Sep (15)	Oct (32)	Nov (81)	Dec (69)
2012	Jan (50)	Feb (18)	Mar (47)	Apr (21)	May (12)	Jun (27)	Jul (4)	Aug (31)	Sep (15)	Oct (31)	Nov (2)	Dec (13)
2013	Jan (6)	Feb (1)	Mar (4)	Apr (7)	May (30)	Jun (7)	Jul (53)	Aug (60)	Sep (30)	Oct (38)	Nov (20)	Dec (12)
2014	Jan (8)	Feb (21)	Mar (15)	Apr (13)	May (1)	Jun (5)	Jul (23)	Aug (57)	Sep (7)	Oct (9)	Nov (32)	Dec (45)
2015	Jan (35)	Feb (16)	Mar (29)	Apr (20)	May (55)	Jun (37)	Jul (5)	Aug (25)	Sep (2)	Oct (3)	Nov (6)	Dec (8)
2016	Jan (23)	Feb (15)	Mar (39)	Apr (9)	May (4)	Jun (11)	Jul (5)	Aug (1)	Sep (1)	Oct (3)	Nov (12)	Dec (1)
2017	Jan (1)	Feb (4)	Mar (7)	Apr (3)	May	Jun	Jul	Aug	Sep (4)	Oct (13)	Nov (6)	Dec (4)
2018	Jan (26)	Feb (4)	Mar (5)	Apr (6)	May (1)	Jun (2)	Jul (9)	Aug	Sep (1)	Oct (5)	Nov	Dec (1)
2019	Jan (8)	Feb	Mar (6)	Apr	May	Jun (6)	Jul	Aug (40)	Sep (7)	Oct (23)	Nov (16)	Dec (8)
2020	Jan (3)	Feb (15)	Mar	Apr	May (27)	Jun (7)	Jul (2)	Aug (9)	Sep (32)	Oct (23)	Nov (6)	Dec (3)
2021	Jan (10)	Feb (1)	Mar (4)	Apr	May	Jun (2)	Jul	Aug	Sep	Oct	Nov	Dec
2022	Jan (3)	Feb	Mar	Apr (2)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2023	Jan (2)	Feb	Mar (4)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

iverilog-devel Mailing List for Icarus Verilog (Page 7)

iverilog-devel — Conversations on matters of Icarus Verilog development