iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] Specify block support?

[Evan L. <sa2...@cy...>]

Thanks, missed that page.

On 02/01/2021 17:53, Martin Whitaker wrote:
> On 02/01/2021 17:16, Evan Lavelle wrote:
>> What's the status of specify block support? Are timing checks meant to
>> work?
>>
> No, timing checks are ignored.
> 
> Missing features are listed here:
> 
> https://iverilog.fandom.com/wiki/Release_Notes_Icarus_Verilog_11#Things_That_Still_Don.27t_Work
> 
> 
> although I don't promise that list is complete.
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] Specify block support?

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

On 02/01/2021 17:16, Evan Lavelle wrote:
> What's the status of specify block support? Are timing checks meant to work?
> 
No, timing checks are ignored.

Missing features are listed here:

https://iverilog.fandom.com/wiki/Release_Notes_Icarus_Verilog_11#Things_That_Still_Don.27t_Work

although I don't promise that list is complete.

[Iverilog-devel] Specify block support?

[Evan L. <sa2...@cy...>]

What's the status of specify block support? Are timing checks meant to work?

https://www.edaplayground.com/x/ex57
<https://www.edaplayground.com/x/ex57> is a simple hard-wired test of
$setuphold. This drives the data input of a F/F with a valid setup, but
with a hold failure. The test passes if the simulator reports a hold
violation, and the testbench reports  "**FAIL** setup or hold failure: q
is x". Questa, for example, correctly reports:

# ** Error: $hold( posedge clock:15 ns, data:16 ns, 2 ns );
# Time: 16 ns Iteration: 1 Process: /top/dff/#Setuphold# File:
testbench.sv Line: 47
# **FAIL** setup or hold failure: q is x

This test passes on Veriwell, Riviera PRO, VCS, Xcelium, Questa, and
ModelSim. It partially passes on GPL Cver - Cver reports a hold failure,
but the notifier mechanism appears to be broken, and the testbench
reports a pass, instead of a fail. Icarus 11.0 appears to ignore the
specify block and the testbench (incorrectly) reports that the test passed.

Thanks.

Re: [Iverilog-devel] Test to run: string parameters

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

Thanks!

On Sun, Dec 27, 2020 at 4:39 PM Srinivasan Venkataramanan
<sv...@gm...> wrote:
>
> As per LRM, string size method is named "len()". With that, it works for your test.
>
>
>
> On Mon, Dec 28, 2020 at 4:14 AM Stephen Williams <st...@ic...> wrote:
>>
>> I'm implementing support for string parameters, and would like it if
>> some of you out there can cross check my work. Specifically, does the
>> attached program do what I think it does? It should be pretty straight
>> forward, but it would be useful to get confirmation from Big-3 tools.
>>
>> Thanks,
>>
>> --
>> 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...              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] Test to run: string parameters

[Srinivasan V. <sv...@gm...>]

As per LRM, string size method is named "len()". With that, it works for
your test.



On Mon, Dec 28, 2020 at 4:14 AM Stephen Williams <st...@ic...> wrote:

> I'm implementing support for string parameters, and would like it if
> some of you out there can cross check my work. Specifically, does the
> attached program do what I think it does? It should be pretty straight
> forward, but it would be useful to get confirmation from Big-3 tools.
>
> Thanks,
>
> --
> 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] Test to run: string parameters

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

I'm implementing support for string parameters, and would like it if
some of you out there can cross check my work. Specifically, does the
attached program do what I think it does? It should be pretty straight
forward, but it would be useful to get confirmation from Big-3 tools.

Thanks,

-- 
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] IVL_UVM: UVM support - incremental additions

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

It's usually possible to reduce a failure to a single file. Sometimes,
that means concatenating a bunch of files together, or running them
through the preprocessor. Make an effort. If you are stumped on how to
reduce the problem, you can at least post the error message you are
getting to this mailing list, and perhaps we can give you a hand
reducing it to a manageable bug report.

On Sun, Nov 29, 2020 at 9:36 AM Srinivasan Venkataramanan
<sv...@gm...> wrote:
>
> Hello,
>
> I would like to add UVM support to Icarus. I have been working with few interns to add simple features with Icarus. Will soon add code to a GitHub repo and send a link.
>
> One challenge we see is that unit tests work, larger UVM code base (not really full UVM, but just many classes/objects) tend to break the tool. I wonder how to submit such testcases when they are spread across files, has a Makefile etc. I am sure this is possible, just want to understand how you folks do it here.
>
> Please share your thoughts on this.
>
> Looking forward to update, maintain and contribute to IVL_UVM!
>
> Regards
> Srini
>
>
> _______________________________________________
> 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] IVL_UVM: UVM support - incremental additions

[Srinivasan V. <sv...@gm...>]

Hello,

I would like to add UVM support to Icarus. I have been working with few
interns to add simple features with Icarus. Will soon add code to a GitHub
repo and send a link.

One challenge we see is that unit tests work, larger UVM code base (not
really full UVM, but just many classes/objects) tend to break the tool. I
wonder how to submit such testcases when they are spread across files, has
a Makefile etc. I am sure this is possible, just want to understand how you
folks do it here.

Please share your thoughts on this.

Looking forward to update, maintain and contribute to IVL_UVM!

Regards
Srini

Re: [Iverilog-devel] Updating tests to use `begin_keywords

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

I've pushed a couple of fixes to this.

On 23/11/2020 07:06, Cary R. via Iverilog-devel wrote:
>   I have pushed support for this. The normal tests should still be clean. The forced to SystemVerilog tests still have a few (18) failures, but most are because of differences in the compiler when it is parsing Verilog versus SystemVerilog (e.g. error messages, actual functionality supported, etc.). There are four tests that I need to look at in a bit more detail when I have some time. I will probably add a new regression list that overrides some of the tests based on being parsed as SystemVerilog versus Verilog to cleanup the error message differences. The functionality differences may require a bit more creativity.
> Cary
> 
>      On Sunday, November 22, 2020, 1:35:17 AM PST, Martin Whitaker <ic...@ma...> wrote:
>   
>   I can't think of any reason not to do this.
> 
> On 21/11/2020 06:45, Cary R. via Iverilog-devel wrote:
>> The test suite is being used as part of a larger SystemVerilog testsuite located here: SymbiFlow/sv-tests
>>
>> |
>> |
>> |
>> |  |  |
>>
>>    |
>>
>>    |
>> |
>> |  |
>> SymbiFlow/sv-tests
>>
>> Test suite designed to check compliance with the SystemVerilog standard. - SymbiFlow/sv-tests
>>    |
>>
>>    |
>>
>>    |
>>
>>
>> Is there any concerns with adding the appropriate `begin_keyword directive to allow some of the older code to be parsed correctly? The plan would be to only add directives to files that cannot be parsed as SystemVerilog without this. I assume we would continue to use the appropriate generation flag in our testsuite since the SymbiFlow test suite will check Icarus with only the -g2012 flag. Probably need to add the appropriate flags, etc to make this -g2017, but that can wait for now.
>>
>> Cary
>>
>>
>>
>> _______________________________________________
>> 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] Updating tests to use `begin_keywords

[Cary R. <cy...@ya...>]

 I have pushed support for this. The normal tests should still be clean. The forced to SystemVerilog tests still have a few (18) failures, but most are because of differences in the compiler when it is parsing Verilog versus SystemVerilog (e.g. error messages, actual functionality supported, etc.). There are four tests that I need to look at in a bit more detail when I have some time. I will probably add a new regression list that overrides some of the tests based on being parsed as SystemVerilog versus Verilog to cleanup the error message differences. The functionality differences may require a bit more creativity.
Cary

    On Sunday, November 22, 2020, 1:35:17 AM PST, Martin Whitaker <ic...@ma...> wrote:  
 
 I can't think of any reason not to do this.

On 21/11/2020 06:45, Cary R. via Iverilog-devel wrote:
> The test suite is being used as part of a larger SystemVerilog testsuite located here: SymbiFlow/sv-tests
> 
> |
> |
> |
> |  |  |
> 
>  |
> 
>  |
> |
> |  |
> SymbiFlow/sv-tests
> 
> Test suite designed to check compliance with the SystemVerilog standard. - SymbiFlow/sv-tests
>  |
> 
>  |
> 
>  |
> 
> 
> Is there any concerns with adding the appropriate `begin_keyword directive to allow some of the older code to be parsed correctly? The plan would be to only add directives to files that cannot be parsed as SystemVerilog without this. I assume we would continue to use the appropriate generation flag in our testsuite since the SymbiFlow test suite will check Icarus with only the -g2012 flag. Probably need to add the appropriate flags, etc to make this -g2017, but that can wait for now.
> 
> Cary
> 
> 
> 
> _______________________________________________
> 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] Updating tests to use `begin_keywords

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

I can't think of any reason not to do this.

On 21/11/2020 06:45, Cary R. via Iverilog-devel wrote:
> The test suite is being used as part of a larger SystemVerilog testsuite located here: SymbiFlow/sv-tests
> 
> |
> |
> |
> |  |  |
> 
>   |
> 
>   |
> |
> |  |
> SymbiFlow/sv-tests
> 
> Test suite designed to check compliance with the SystemVerilog standard. - SymbiFlow/sv-tests
>   |
> 
>   |
> 
>   |
> 
> 
> Is there any concerns with adding the appropriate `begin_keyword directive to allow some of the older code to be parsed correctly? The plan would be to only add directives to files that cannot be parsed as SystemVerilog without this. I assume we would continue to use the appropriate generation flag in our testsuite since the SymbiFlow test suite will check Icarus with only the -g2012 flag. Probably need to add the appropriate flags, etc to make this -g2017, but that can wait for now.
> 
> Cary
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

[Iverilog-devel] Updating tests to use `begin_keywords

[Cary R. <cy...@ya...>]

The test suite is being used as part of a larger SystemVerilog testsuite located here: SymbiFlow/sv-tests

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
SymbiFlow/sv-tests

Test suite designed to check compliance with the SystemVerilog standard. - SymbiFlow/sv-tests
 |

 |

 |


Is there any concerns with adding the appropriate `begin_keyword directive to allow some of the older code to be parsed correctly? The plan would be to only add directives to files that cannot be parsed as SystemVerilog without this. I assume we would continue to use the appropriate generation flag in our testsuite since the SymbiFlow test suite will check Icarus with only the -g2012 flag. Probably need to add the appropriate flags, etc to make this -g2017, but that can wait for now.

Cary

Re: [Iverilog-devel] Icarus Verilog Release 11.0

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

It's been a while since I fiddled with sourceforge. Anyhow, done.

On Thu, Oct 15, 2020 at 5:25 AM Martin Whitaker
<ic...@ma...> wrote:
>
> I see you've uploaded v11 to SourceForge, but you need to mark it as the
> default version, as the Download Latest Version button still links to 10.3.
>
> I've added some release notes on the Wiki, and also updated the
> documentation there where necessary.
>
> On 11/10/2020 23:31, Stephen Williams wrote:
> > I think we want to redirect people away from sourceforge and towards github.
> >
> > I also think it would be ideal if package managers for the various
> > distributions took on packaging releases, because these days there are
> > too many package repository formats for us to realistically take that
> > on.
> >
> > On Sun, Oct 11, 2020 at 1:24 PM Martin Whitaker
> > <ic...@ma...> wrote:
> >>
> >> OK, in that case we should publicise it more:
> >>
> >>     - create a release on GitHub
> >>     - upload the files to SourceForge (or put up a redirect notice
> >>       if you would rather steer people towards GitHub)
> >>     - announce on iverilog-announce (in case anyone still reads that)
> >>     - add some release notes on the Wiki
> >>
> >> On 11/10/2020 20:28, Stephen Williams wrote:
> >>> My intent is that 11.0 is a "release", and not a draft, but I'm OK
> >>> with having an 11.1 release sooner rather than later. Releases may
> >>> have versions. Note that v10 had 4 (10.0 - 10.3) and probably could
> >>> have done with more. But within releases, vvp and the language must be
> >>> substantially compatible, with no surprises.
> >>>
> >>>
> >>> On Fri, Oct 9, 2020 at 4:22 AM Martin Whitaker
> >>> <ic...@ma...> wrote:
> >>>>
> >>>> On 26/09/2020 21:59, Stephen Williams wrote:
> >>>>> I've made an 11.0 release, and the release source files are here:
> >>>>>
> >>>>> <ftp://ftp.icarus.com/pub/eda/verilog/v11/>
> >>>>>
> >>>>> Try it out, and let's see how it goes. Feedback in this mailing list,
> >>>>> especially with packaging issues.
> >>>>>
> >>>> Did you intend this to be a trial run or the final release? If the
> >>>> former, I think it would be worth updating to pick up the fix for
> >>>> https://github.com/steveicarus/iverilog/issues/374, which was a
> >>>> regression w.r.t. v10.
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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] Icarus Verilog Release 11.0

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

I see you've uploaded v11 to SourceForge, but you need to mark it as the 
default version, as the Download Latest Version button still links to 10.3.

I've added some release notes on the Wiki, and also updated the 
documentation there where necessary.

On 11/10/2020 23:31, Stephen Williams wrote:
> I think we want to redirect people away from sourceforge and towards github.
> 
> I also think it would be ideal if package managers for the various
> distributions took on packaging releases, because these days there are
> too many package repository formats for us to realistically take that
> on.
> 
> On Sun, Oct 11, 2020 at 1:24 PM Martin Whitaker
> <ic...@ma...> wrote:
>>
>> OK, in that case we should publicise it more:
>>
>>     - create a release on GitHub
>>     - upload the files to SourceForge (or put up a redirect notice
>>       if you would rather steer people towards GitHub)
>>     - announce on iverilog-announce (in case anyone still reads that)
>>     - add some release notes on the Wiki
>>
>> On 11/10/2020 20:28, Stephen Williams wrote:
>>> My intent is that 11.0 is a "release", and not a draft, but I'm OK
>>> with having an 11.1 release sooner rather than later. Releases may
>>> have versions. Note that v10 had 4 (10.0 - 10.3) and probably could
>>> have done with more. But within releases, vvp and the language must be
>>> substantially compatible, with no surprises.
>>>
>>>
>>> On Fri, Oct 9, 2020 at 4:22 AM Martin Whitaker
>>> <ic...@ma...> wrote:
>>>>
>>>> On 26/09/2020 21:59, Stephen Williams wrote:
>>>>> I've made an 11.0 release, and the release source files are here:
>>>>>
>>>>> <ftp://ftp.icarus.com/pub/eda/verilog/v11/>
>>>>>
>>>>> Try it out, and let's see how it goes. Feedback in this mailing list,
>>>>> especially with packaging issues.
>>>>>
>>>> Did you intend this to be a trial run or the final release? If the
>>>> former, I think it would be worth updating to pick up the fix for
>>>> https://github.com/steveicarus/iverilog/issues/374, which was a
>>>> regression w.r.t. v10.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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] Icarus Verilog Release 11.0

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

I think we want to redirect people away from sourceforge and towards github.

I also think it would be ideal if package managers for the various
distributions took on packaging releases, because these days there are
too many package repository formats for us to realistically take that
on.

On Sun, Oct 11, 2020 at 1:24 PM Martin Whitaker
<ic...@ma...> wrote:
>
> OK, in that case we should publicise it more:
>
>    - create a release on GitHub
>    - upload the files to SourceForge (or put up a redirect notice
>      if you would rather steer people towards GitHub)
>    - announce on iverilog-announce (in case anyone still reads that)
>    - add some release notes on the Wiki
>
> On 11/10/2020 20:28, Stephen Williams wrote:
> > My intent is that 11.0 is a "release", and not a draft, but I'm OK
> > with having an 11.1 release sooner rather than later. Releases may
> > have versions. Note that v10 had 4 (10.0 - 10.3) and probably could
> > have done with more. But within releases, vvp and the language must be
> > substantially compatible, with no surprises.
> >
> >
> > On Fri, Oct 9, 2020 at 4:22 AM Martin Whitaker
> > <ic...@ma...> wrote:
> >>
> >> On 26/09/2020 21:59, Stephen Williams wrote:
> >>> I've made an 11.0 release, and the release source files are here:
> >>>
> >>> <ftp://ftp.icarus.com/pub/eda/verilog/v11/>
> >>>
> >>> Try it out, and let's see how it goes. Feedback in this mailing list,
> >>> especially with packaging issues.
> >>>
> >> Did you intend this to be a trial run or the final release? If the
> >> former, I think it would be worth updating to pick up the fix for
> >> https://github.com/steveicarus/iverilog/issues/374, which was a
> >> regression w.r.t. v10.
> >>
> >>
> >> _______________________________________________
> >> 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] Icarus Verilog Release 11.0

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

OK, in that case we should publicise it more:

   - create a release on GitHub
   - upload the files to SourceForge (or put up a redirect notice
     if you would rather steer people towards GitHub)
   - announce on iverilog-announce (in case anyone still reads that)
   - add some release notes on the Wiki

On 11/10/2020 20:28, Stephen Williams wrote:
> My intent is that 11.0 is a "release", and not a draft, but I'm OK
> with having an 11.1 release sooner rather than later. Releases may
> have versions. Note that v10 had 4 (10.0 - 10.3) and probably could
> have done with more. But within releases, vvp and the language must be
> substantially compatible, with no surprises.
> 
> 
> On Fri, Oct 9, 2020 at 4:22 AM Martin Whitaker
> <ic...@ma...> wrote:
>>
>> On 26/09/2020 21:59, Stephen Williams wrote:
>>> I've made an 11.0 release, and the release source files are here:
>>>
>>> <ftp://ftp.icarus.com/pub/eda/verilog/v11/>
>>>
>>> Try it out, and let's see how it goes. Feedback in this mailing list,
>>> especially with packaging issues.
>>>
>> Did you intend this to be a trial run or the final release? If the
>> former, I think it would be worth updating to pick up the fix for
>> https://github.com/steveicarus/iverilog/issues/374, which was a
>> regression w.r.t. v10.
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 

Re: [Iverilog-devel] Icarus Verilog Release 11.0

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

My intent is that 11.0 is a "release", and not a draft, but I'm OK
with having an 11.1 release sooner rather than later. Releases may
have versions. Note that v10 had 4 (10.0 - 10.3) and probably could
have done with more. But within releases, vvp and the language must be
substantially compatible, with no surprises.


On Fri, Oct 9, 2020 at 4:22 AM Martin Whitaker
<ic...@ma...> wrote:
>
> On 26/09/2020 21:59, Stephen Williams wrote:
> > I've made an 11.0 release, and the release source files are here:
> >
> > <ftp://ftp.icarus.com/pub/eda/verilog/v11/>
> >
> > Try it out, and let's see how it goes. Feedback in this mailing list,
> > especially with packaging issues.
> >
> Did you intend this to be a trial run or the final release? If the
> former, I think it would be worth updating to pick up the fix for
> https://github.com/steveicarus/iverilog/issues/374, which was a
> regression w.r.t. v10.
>
>
> _______________________________________________
> 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] Icarus Verilog Release 11.0

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

On 26/09/2020 21:59, Stephen Williams wrote:
> I've made an 11.0 release, and the release source files are here:
> 
> <ftp://ftp.icarus.com/pub/eda/verilog/v11/>
> 
> Try it out, and let's see how it goes. Feedback in this mailing list,
> especially with packaging issues.
> 
Did you intend this to be a trial run or the final release? If the 
former, I think it would be worth updating to pick up the fix for 
https://github.com/steveicarus/iverilog/issues/374, which was a 
regression w.r.t. v10.

Re: [Iverilog-devel] Small stuff

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

On 08/10/2020 13:30, Martin Whitaker wrote:
> On 08/10/2020 12:27, Evan Lavelle wrote:
>> Here's another one:
>>
>> `define \A foo
>>
>> module `\A;
>>    initial
>>      $display("%m: Ok");
>> endmodule
>> this code doesn't work on any of the simulators on EDA Playground
>> (https://www.edaplayground.com/x/6yZJ). However, the LRM seems pretty
>> clear that it should:
>>
>> text_macro_definition ::= `define text_macro_name macro_text
>> text_macro_name ::= text_macro_identifier [( list_of_formal_arguments )]
>> text_macro_identifier ::= identifier
>> identifier ::= simple_identifier | escaped_identifier
>>
>> In other words, a text macro name can be an escaped identifier, but
>> no-one seems to support this. Xcelium, at least, just creates a macro
>> named 'A'.
> 
> I don't think we could fix that without breaking recognition of the SV 
> `\`" escape sequence.

I figured out how to implement this, and it is now fixed in both the 
master and v11 branches.

Note that for your example to work, you need to terminate the escaped 
name with white space, i.e.

   module `\A ;

It's interesting to see that most other simulators fail on this more 
extensive test:

`define simple      "simple name"
`define \escaped    "escaped name"
`define \`name      "backtick name"
`define \`          "backtick"
`define \quote (x)  `"`\`"x`\`"`"
`define \`\`"       "escaped quote"

module test();

initial begin
   $display(`simple);
   $display(`\simple );
   $display(`escaped);
   $display(`\escaped );
   $display(`\`name );
   $display(`\` );
   $display(`quote(text));
   $display(`\quote (text));
   $display(`\`\`" );
end

endmodule

Re: [Iverilog-devel] Small stuff

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

On 08/10/2020 12:27, Evan Lavelle wrote:
> Here's another one:
> 
> `define \A foo
> 
> module `\A;
>    initial
>      $display("%m: Ok");
> endmodule
> this code doesn't work on any of the simulators on EDA Playground
> (https://www.edaplayground.com/x/6yZJ). However, the LRM seems pretty
> clear that it should:
> 
> text_macro_definition ::= `define text_macro_name macro_text
> text_macro_name ::= text_macro_identifier [( list_of_formal_arguments )]
> text_macro_identifier ::= identifier
> identifier ::= simple_identifier | escaped_identifier
> 
> In other words, a text macro name can be an escaped identifier, but
> no-one seems to support this. Xcelium, at least, just creates a macro
> named 'A'.

I don't think we could fix that without breaking recognition of the SV 
`\`" escape sequence.

Re: [Iverilog-devel] Small stuff

[Evan L. <sa2...@cy...>]

Here's another one:

`define \A foo

module `\A;
  initial
    $display("%m: Ok");
endmodule
this code doesn't work on any of the simulators on EDA Playground
(https://www.edaplayground.com/x/6yZJ). However, the LRM seems pretty
clear that it should:

text_macro_definition ::= `define text_macro_name macro_text
text_macro_name ::= text_macro_identifier [( list_of_formal_arguments )]
text_macro_identifier ::= identifier
identifier ::= simple_identifier | escaped_identifier

In other words, a text macro name can be an escaped identifier, but
no-one seems to support this. Xcelium, at least, just creates a macro
named 'A'.

Re: [Iverilog-devel] Avoiding a race condition: options?

[Evan L. <sa2...@cy...>]

So... a handshaked wait completely avoids the issue of lost events,
which makes it a much better solution. That hadn't occurred to me.  It
has got my head spinning, though - it appears to make events completely
redundant.

It also runs Ok on VCS, Xcelium, Questa, and CVer (you do know that you
can use the 'Tools and Simulators' pulldown to select any of these
simulators? That's why EDA playground is so useful).

Thanks -

E

On 04/10/2020 09:32, Martin Whitaker wrote:
> On 03/10/2020 11:17, Evan Lavelle wrote:
>> Ok, there was a minor error in the second file
>> (https://www.edaplayground.com/x/Xfeh), which is why the simulators were
>> reporting one race, fixed now.
>>
>> 6 simulators are now reporting no races detected in this version, so
>> this may (or may not?) be a valid solution...
> 
> Here is my solution:
> 
> https://www.edaplayground.com/x/ZgA2
> 
> Works in Icarus and Aldec Riviera Pro. I don't have access to the other
> commercial simulators.
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] Avoiding a race condition: options?

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

On 03/10/2020 11:17, Evan Lavelle wrote:
> Ok, there was a minor error in the second file
> (https://www.edaplayground.com/x/Xfeh), which is why the simulators were
> reporting one race, fixed now.
> 
> 6 simulators are now reporting no races detected in this version, so
> this may (or may not?) be a valid solution...

Here is my solution:

https://www.edaplayground.com/x/ZgA2

Works in Icarus and Aldec Riviera Pro. I don't have access to the other 
commercial simulators.

Re: [Iverilog-devel] Avoiding a race condition: options?

[Evan L. <sa2...@cy...>]

Ok, there was a minor error in the second file
(https://www.edaplayground.com/x/Xfeh), which is why the simulators were
reporting one race, fixed now.

6 simulators are now reporting no races detected in this version, so
this may (or may not?) be a valid solution...

[Iverilog-devel] Avoiding a race condition: options?

[Evan L. <sa2...@cy...>]

Apologies for asking a Verilog question here, but the rest of the
Verilog world seems to have dumbed down so much that it can't be asked
anywhere else...

I have a difficult problem where I need to work around a race condition.

Assume a tick of 1ns. Module A needs to make a decision every 8ns (for
the sake of argument) on whether to initiate an 8ns sequence of events
in module B.

Most of the time, module A will regularly kick off the 8ns sequence, so
it just happens continuously. Module A *must* complete the initiation in
zero simulation time, so it calls a task in module B which just raises
an event in module B, and an always block in module B responds to the
event and calls the task which takes 8ns to complete. So, module A
completes in zero time by raising the event, and module B completes in
8ns after responding to the event. The (very simple) code is at
https://www.edaplayground.com/x/vGp9.

Here's the problem: module B always schedules an event at the end of the
sequence, at (($time % 8) == 0). However, module A always kicks off the
next sequence at exactly the same time, so there's a race. In the
relevant delta, the scheduler sometimes runs the module A code first,
before the event at the end of the sequence, in which case the next
sequence is lost, and the test code shows this.

This is expected, and isn't surprising. Problem: is there some way to
'decouple' the event trigger from module A from the last event in module
B to avoid this? Note that the sequence in module B doesn't have to be
started at exactly the 8ns boundary, but can be started 1ns later.
However, it must end at the 8ns boundary, at exactly the same time that
module A needs to start the sequence.

https://www.edaplayground.com/x/Xfeh is an attempt to do this. There are
now two events. Module A triggers a simple task in module B, which waits
1n, and then raises a second event, which starts the sequence in another
task. The reasoning here is that module A is now actually only
triggering a 1ns sequence, and so there is no race with the final event
7ns later.

However, this doesn't work - various simulators still report a race.
Somehow, the initial trigger from module A is still 'locked out' for the
complete 8ns. The scheduler still sees the the first trigger from module
A and the end of the sequence at the same time, of course, but it has
somehow effectively locks out the trigger for the complete 8ns, and not 1ns.

Any thoughts on how to work around this? I have successfully used #0
elsewhere, but I don't want to make a habit of it...

Thanks.