iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] Syntax question, is !&x valid?

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

On 30/03/2023 10:37, Niels Möller wrote:
> Martin Whitaker <ic...@ma...> writes:
> 
>> IEEE 1364-2005 appendix A says
>>
>> expression ::=
>>      primary
>>    | unary_operator { attribute_instance } primary
>>    | expression binary_operator { attribute_instance } expression
>>    | conditional_expression
>>
>> primary ::=
>    [...]
> 
> Thanks for explaining. I would have expected the grammar to include a
> production like
> 
>   | unary_operator expression
> 
> but I guess there's some reason (historical or technical) why that's not
> in the specified grammar.

Possibly it's just due to the existence of the ~&, ~|, and ~^ operators.

Re: [Iverilog-devel] Syntax question, is !&x valid?

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

Martin Whitaker <ic...@ma...> writes:

> IEEE 1364-2005 appendix A says
>
> expression ::=
>     primary
>   | unary_operator { attribute_instance } primary
>   | expression binary_operator { attribute_instance } expression
>   | conditional_expression
>
> primary ::= 
  [...]

Thanks for explaining. I would have expected the grammar to include a
production like

 | unary_operator expression

but I guess there's some reason (historical or technical) why that's not
in the specified grammar.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.

Re: [Iverilog-devel] Syntax question, is !&x valid?

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

On 30/03/2023 06:51, Niels Möller wrote:
> Hi,
> 
> I've noticed that icarus verilog doesn't like this piece of code:
> 
>    module foo(input [7:0] x, output y);
>       assign y = !&x;
>    endmodule
> 
> I'm running Icarus Verilog version 13.0 (devel)
> (s20141205-283-g437dc10), and it complains
> 
>    error: Operand of unary ! is not a primary expression.
> 
> Other tools, in particular yosys, seems to accept this syntax, and in
> general, I had expected that any stacking of unary operators is
> syntactically ok. Adding a pair of parentheses makes iverilog accept it,
> like
> 
>    module foo(input [7:0] x, output y);
>       assign y = !(&x);
>    endmodule
> 
> So my question is, what does the spec for verilog syntax say?

IEEE 1364-2005 appendix A says

expression ::=
     primary
   | unary_operator { attribute_instance } primary
   | expression binary_operator { attribute_instance } expression
   | conditional_expression

primary ::=
     number
   | hierarchical_identifier [ { [ expression ] } [ range_expression ] ]
   | concatenation
   | multiple_concatenation
   | function_call
   | system_function_call
   | ( mintypmax_expression )
   | string

so !&x is not valid syntax.

IEEE 1800-2017 adds more options, but does not change this.

[Iverilog-devel] Syntax question, is !&x valid?

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

Hi, 

I've noticed that icarus verilog doesn't like this piece of code:

  module foo(input [7:0] x, output y);
     assign y = !&x;
  endmodule

I'm running Icarus Verilog version 13.0 (devel)
(s20141205-283-g437dc10), and it complains

  error: Operand of unary ! is not a primary expression.

Other tools, in particular yosys, seems to accept this syntax, and in
general, I had expected that any stacking of unary operators is
syntactically ok. Adding a pair of parentheses makes iverilog accept it,
like

  module foo(input [7:0] x, output y);
     assign y = !(&x);
  endmodule

So my question is, what does the spec for verilog syntax say?

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.

[Iverilog-devel] GitHub actions vs. python and docopt

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

I need Windows help with running a python3 script in github Actions
(CI). I'm working on a new regiression test script written in python,
and it uses docopt. That works perfectly fine in Linux and MacOS on
GitHub actions, but I can't figure out how to get it to work on the
Windows targets:

I put a "pip3 install docopt" before the tests, and the action is reporting:

```
Run pip3 install docopt
Collecting docopt
Downloading docopt-0.6.2.tar.gz (25 kB)
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Preparing metadata (pyproject.toml): started
Preparing metadata (pyproject.toml): finished with status 'done'
Building wheels for collected packages: docopt
Building wheel for docopt (pyproject.toml): started
Building wheel for docopt (pyproject.toml): finished with status 'done'
Created wheel for docopt: filename=docopt-0.6.2-py2.py3-none-any.whl
size=13705 sha256=6ae8825ae30a321602abfc073c1887bc5378e05ebd0af0ba7e345154a372c216
Stored in directory:
/home/runneradmin/.cache/pip/wheels/7c/d7/8d/2156234738063e3d4a39ba77dc677046100e62766b53807189
Successfully built docopt
Installing collected packages: docopt
Successfully installed docopt-0.6.2
```

... and that's great, but later, when the action runs the python script, I get:
```
Traceback (most recent call last):
File "D:\a\iverilog\iverilog\ivtest\vvp_reg.py", line 14, in <module>
from docopt import docopt
ModuleNotFoundError: No module named 'docopt'
```

Github actions are using msys2 here. The PR that I'm working on is here:
https://github.com/steveicarus/iverilog/pull/847

Any ideas?
-- 
Steve Williams
st...@ic...

Re: [Iverilog-devel] bad_alloc

[Jeff O. <jmo...@ya...>]

Hi...When running Icarus-verilog on my Windows PC, I get the following error:
    terminate called after throwing in instance of 'std::bad_alloc'    what(): std: :bad_alloc
I didn't see this in any of the bug reports so I suspect it may just be me. I have no issues running small simulations but the error occurs when running an 8-bit microprocessor. I get about 400 ticks into the simulation then it dies. What I do get it is correct - several instructions of microcode.
My laptop is not new but is running Windows 10. 

Thanks,
Jeff
  

[Iverilog-devel] New Home for Icarus Verilog Documentation

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

TL;DR, here it is:
https://steveicarus.github.io/iverilog/

The iverilog.fandom.com site has been auto-ported by the hosting
service several times now, and is both out of date and even corrupted
in parts. I figure it's high time to put it in a place that tracks the
source code itself. The new location is, in fact, on github.com, where
the source code is kept.

In fact, the source for the documentation is part of the source tree
itself. It follows some of the conventions of the Linux kernel, so
there are people familiar with the formatting, and even those who are
not familiar with the formatting can read the raw text, if need be.
But I use a github action to automatically deploy the documentation in
the "master" branch in html form, so now I can encourage people
submitting features to also include documentation for their feature
and have that show up in the same pull request. Much cleaner!

There is still content in the now old documentation locations that
should be either ported over or recreated. Anyone who wants to submit
pull requests is welcome.

-- 
Steve Williams
st...@ic...

[Iverilog-devel] New documentation for Icarus Verilog

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

Icarus Verilog users:

The documentation for Icarus Verilog at iverilog.fandom.com is
becoming increasingly out of date, and also apparently the service has
been corrupting files. So it's in pretty bad shape. So time marches on
and I've decided to follow the "Linux" example and include the
documentation along with the source in the "Documentation" directory,
using the Sphinx tool to process it. So I'd like to declare the
fandom.com site obsolete, and let's instead work on getting the
bundled documentation up to snuff.

If there are experts in reStructuredText and sphinx out there who can
help with things like cleaning up formatting, and maybe tricks like
getting github pages to serve the most current documentation, that
would be great!
-- 
Steve Williams
st...@ic...

Re: [Iverilog-devel] Merging iverilog and ivtest github repositories

[Michael S. <mic...@gm...>]

I agree. Extra functionality overweights the extra size.

Best regards,
Michael Strelnikov


On Sun, 16 Jan 2022 at 07:59, Bryan Murdock <bmu...@gm...> wrote:

> 18 MB is nothing these days.  Go for it!
>
> Bryan
>
> On Sat, Jan 15, 2022, 11:59 AM Stephen Williams <st...@ic...> wrote:
>
>> Well, I have some time on my hands, and I've had enough with trying to
>> keep the iverilog and ivtest repositories updated in lock-step. I
>> think it is high time to merge the entire ivtest repository into the
>> iverilog repository. This way, a PR for a new feature, and the
>> regression tests for that feature, can be merged together as a single
>> PR.
>>
>> The obvious problem with that is that it makes the source about 18M
>> bigger.
>>
>> The advantage is that github actions (automated regression tests) will
>> be easier to manage,
>> and also it should be easier to get patches and regression tests
>> merged together.
>>
>> Convince me that I'm wrong.
>>
>> --
>> Steve Williams
>> st...@ic...
>>
>>
>> _______________________________________________
>> 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] Merging iverilog and ivtest github repositories

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

18 MB is nothing these days.  Go for it!

Bryan

On Sat, Jan 15, 2022, 11:59 AM Stephen Williams <st...@ic...> wrote:

> Well, I have some time on my hands, and I've had enough with trying to
> keep the iverilog and ivtest repositories updated in lock-step. I
> think it is high time to merge the entire ivtest repository into the
> iverilog repository. This way, a PR for a new feature, and the
> regression tests for that feature, can be merged together as a single
> PR.
>
> The obvious problem with that is that it makes the source about 18M bigger.
>
> The advantage is that github actions (automated regression tests) will
> be easier to manage,
> and also it should be easier to get patches and regression tests
> merged together.
>
> Convince me that I'm wrong.
>
> --
> Steve Williams
> st...@ic...
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

[Iverilog-devel] Merging iverilog and ivtest github repositories

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

Well, I have some time on my hands, and I've had enough with trying to
keep the iverilog and ivtest repositories updated in lock-step. I
think it is high time to merge the entire ivtest repository into the
iverilog repository. This way, a PR for a new feature, and the
regression tests for that feature, can be merged together as a single
PR.

The obvious problem with that is that it makes the source about 18M bigger.

The advantage is that github actions (automated regression tests) will
be easier to manage,
and also it should be easier to get patches and regression tests
merged together.

Convince me that I'm wrong.

-- 
Steve Williams
st...@ic...

Re: [Iverilog-devel] A question about the VVP file in iverilog

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

The netlist functors in vvp, such as .concat and others, are nodes,
like gates, that take inputs and produce outputs. The .concat is
exactly that: the input is a set of vectors, and the output is a
single concatenated vector. For example:

    concat(2'b01, 2'b11) --> 4'b0111

It's a little bit more complicated than that, but that's the basic principle.

On Sun, Jun 13, 2021 at 7:55 AM slive1024 <sli...@ho...> wrote:
>
> I have doubts about a certain keyword in the VVP file, and the problem is a little more complicated. I wrote my question in my attachment, thank you for taking the time to answer it for me
> _______________________________________________
> 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] A question about the VVP file in iverilog

[slive1024 <sli...@ho...>]

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<style>
    font{
        line-height: 1.6;
    }
    ul,ol{
        padding-left: 20px;
        list-style-position: inside;
    }
</style>
<div style="font-family:微软雅黑,Verdana,&quot;Microsoft Yahei&quot;,SimSun,sans-serif;font-size:14px; line-height:1.6;">
    <div></div>
<style>
    font{
        line-height: 1.6;
    }
    ul,ol{
        padding-left: 20px;
        list-style-position: inside;
    }
</style>
<div style="font-family:微软雅黑,Verdana,&quot;Microsoft Yahei&quot;,SimSun,sans-serif;font-size:14px; line-height:1.6;">
    I have doubts about a certain keyword in the VVP file, and the problem is a little more complicated. I wrote my question in my attachment, thank you for taking the time to answer it for me<!--😀-->
</div><!--😀-->
</div>
</body>
</html>

Re: [Iverilog-devel] bit/part-select of function return value

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

 I doubt this is super hard to implement, but I have no free time right now to look at what is involved. Please file a report on github. As Udi pointed out the correct syntax is wrapping the operand(s) in a concatenation.
Cary

    On Wednesday, March 10, 2021, 6:33:06 AM PST, Evan Lavelle <sa2...@cy...> wrote:  
 
 Xcelium 20.09, with -sysv:  No
VCS 2020.03, with -sverilog: Yes
Questa 2020.1:              Yes
Riviera-PRO 2020.04:        Yes

VCS allows this even without '-sverilog'. Weird. Unfortunately, I can't
personally use this, because the code has to run on Icarus as well.

On 10/03/2021 14:04, Udi Finkelstein wrote:
> Please take a look:
> https://github.com/verilator/verilator/issues/2619#issuecomment-781024235 <https://github.com/verilator/verilator/issues/2619#issuecomment-781024235>
> 
> Can you try putting it in a concatenation?
> 
> b= {f1(0)}[3:0]
> 
> Udi
> 
> 
> On Wed, Mar 10, 2021 at 3:04 PM Evan Lavelle <sa2...@cy...
> <mailto:sa212%2Bi...@cy...>> wrote:
> 
>    Icarus and VCS don't allow this, but Xcelium, Questa, and
>    Riviera-PRO do.
> 
>    The LRM does appear to agree with Icarus - the BNF only allows selects
>    of identifiers, and the explanatory text seems to agree ("Bit-selects
>    and part-selects of vector regs, integer variables, and time variables
>    shall be allowed").
> 
>    However, this is really pretty dumb: either a function returns an rvalue
>    that can be used in an expression, or it doesn't, in which case it's
>    something special and unusual. A function can return "Bit-selects and
>    part-selects of vector regs, etc", which indicates (to me, anyway) that
>    you should be able to apply a select to it.
> 
>    Might be worth going with Xcelium on this one?? OTOH, all the simulators
>    agree that you can't apply a select to a primary in general (8'ha5[3:0]
>    is illegal for all sims, for example), so maybe this is a step too far.
> 
>    Test code at https://www.edaplayground.com/x/9jLz
>    <https://www.edaplayground.com/x/9jLz>, and below:
> 
>    module test;
>      reg [7:0] a;
>      reg [3:0] b;
> 
>      initial begin
>        a = 8'ha5;
>        b = f1(0)[3:0];
>        $display("a is %b; b is %b", a, b);
>      end
> 
>      function [7:0] f1(input dummy);
>        f1 = a;
>      endfunction
>    endmodule
> 
> 
>    _______________________________________________
>    Iverilog-devel mailing list
>    Ive...@li...
>    <mailto:Ive...@li...>
>    https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>    <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] bit/part-select of function return value

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

Xcelium 20.09, with -sysv:   No
VCS 2020.03, with -sverilog: Yes
Questa 2020.1:               Yes
Riviera-PRO 2020.04:         Yes

VCS allows this even without '-sverilog'. Weird. Unfortunately, I can't
personally use this, because the code has to run on Icarus as well.

On 10/03/2021 14:04, Udi Finkelstein wrote:
> Please take a look:
> https://github.com/verilator/verilator/issues/2619#issuecomment-781024235 <https://github.com/verilator/verilator/issues/2619#issuecomment-781024235>
> 
> Can you try putting it in a concatenation?
> 
> b= {f1(0)}[3:0]
> 
> Udi
> 
> 
> On Wed, Mar 10, 2021 at 3:04 PM Evan Lavelle <sa2...@cy...
> <mailto:sa212%2Bi...@cy...>> wrote:
> 
>     Icarus and VCS don't allow this, but Xcelium, Questa, and
>     Riviera-PRO do.
> 
>     The LRM does appear to agree with Icarus - the BNF only allows selects
>     of identifiers, and the explanatory text seems to agree ("Bit-selects
>     and part-selects of vector regs, integer variables, and time variables
>     shall be allowed").
> 
>     However, this is really pretty dumb: either a function returns an rvalue
>     that can be used in an expression, or it doesn't, in which case it's
>     something special and unusual. A function can return "Bit-selects and
>     part-selects of vector regs, etc", which indicates (to me, anyway) that
>     you should be able to apply a select to it.
> 
>     Might be worth going with Xcelium on this one?? OTOH, all the simulators
>     agree that you can't apply a select to a primary in general (8'ha5[3:0]
>     is illegal for all sims, for example), so maybe this is a step too far.
> 
>     Test code at https://www.edaplayground.com/x/9jLz
>     <https://www.edaplayground.com/x/9jLz>, and below:
> 
>     module test;
>       reg [7:0] a;
>       reg [3:0] b;
> 
>       initial begin
>         a = 8'ha5;
>         b = f1(0)[3:0];
>         $display("a is %b; b is %b", a, b);
>       end
> 
>       function [7:0] f1(input dummy);
>         f1 = a;
>       endfunction
>     endmodule
> 
> 
>     _______________________________________________
>     Iverilog-devel mailing list
>     Ive...@li...
>     <mailto:Ive...@li...>
>     https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>     <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] bit/part-select of function return value

[Udi F. <ic...@ud...>]

Please take a look:
https://github.com/verilator/verilator/issues/2619#issuecomment-781024235

Can you try putting it in a concatenation?

b= {f1(0)}[3:0]

Udi


On Wed, Mar 10, 2021 at 3:04 PM Evan Lavelle <sa2...@cy...>
wrote:

> Icarus and VCS don't allow this, but Xcelium, Questa, and Riviera-PRO do.
>
> The LRM does appear to agree with Icarus - the BNF only allows selects
> of identifiers, and the explanatory text seems to agree ("Bit-selects
> and part-selects of vector regs, integer variables, and time variables
> shall be allowed").
>
> However, this is really pretty dumb: either a function returns an rvalue
> that can be used in an expression, or it doesn't, in which case it's
> something special and unusual. A function can return "Bit-selects and
> part-selects of vector regs, etc", which indicates (to me, anyway) that
> you should be able to apply a select to it.
>
> Might be worth going with Xcelium on this one?? OTOH, all the simulators
> agree that you can't apply a select to a primary in general (8'ha5[3:0]
> is illegal for all sims, for example), so maybe this is a step too far.
>
> Test code at https://www.edaplayground.com/x/9jLz, and below:
>
> module test;
>   reg [7:0] a;
>   reg [3:0] b;
>
>   initial begin
>     a = 8'ha5;
>     b = f1(0)[3:0];
>     $display("a is %b; b is %b", a, b);
>   end
>
>   function [7:0] f1(input dummy);
>     f1 = a;
>   endfunction
> endmodule
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

[Iverilog-devel] bit/part-select of function return value

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

Icarus and VCS don't allow this, but Xcelium, Questa, and Riviera-PRO do.

The LRM does appear to agree with Icarus - the BNF only allows selects
of identifiers, and the explanatory text seems to agree ("Bit-selects
and part-selects of vector regs, integer variables, and time variables
shall be allowed").

However, this is really pretty dumb: either a function returns an rvalue
that can be used in an expression, or it doesn't, in which case it's
something special and unusual. A function can return "Bit-selects and
part-selects of vector regs, etc", which indicates (to me, anyway) that
you should be able to apply a select to it.

Might be worth going with Xcelium on this one?? OTOH, all the simulators
agree that you can't apply a select to a primary in general (8'ha5[3:0]
is illegal for all sims, for example), so maybe this is a step too far.

Test code at https://www.edaplayground.com/x/9jLz, and below:

module test;
  reg [7:0] a;
  reg [3:0] b;

  initial begin
    a = 8'ha5;
    b = f1(0)[3:0];
    $display("a is %b; b is %b", a, b);
  end

  function [7:0] f1(input dummy);
    f1 = a;
  endfunction
endmodule

Re: [Iverilog-devel] -Wtimescale issue

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

Hi Evan,
I believe all the odd command line behavior you are experiencing is related to the getopt() in windows and likely has nothing to do with Icarus. I have no idea why it is providing different results. Maybe it is an older version.
Regarding the timescale. For the cases I tried this worked as expected and the messages were correctly suppressed. Can you provide more details so we can figure this out.
Cary
    On Sunday, January 31, 2021, 5:42:59 PM PST, Cary R. <cy...@ya...> wrote:  
 
  Hi Evan,
I believe all the odd command line behavior you are experiencing is related to the getopt() in windows and likely has nothing to do with Icarus. I have no idea why it is providing different results. Maybe it is an older version.
Regarding the timescale. For the cases I tried this worked as expected and the messages were correctly suppressed. Can you provide more details so we can figure this out.
Cary

    On Thursday, January 28, 2021, 1:26:28 PM PST, Cary R. via Iverilog-devel <ive...@li...> wrote:  
 
  FYI The no-<warning> options were added because most of the warnings are added with -Wall. It's odd regarding the space issue. I'll have to take a look. I'll look at this later and see if things match my expectation. For example: I believe having modules with the default timescale and some with a user defined timescale is potentially a huge error, where inheriting a timescale from a previous file is possibly intended (your example), but could be risky if you do not know what you are doing.

--timescale is one of our oldest enhancement requests. On the surface it is straight forward, but there is subtlety that is easy to miss. I will also point out some of the commercial tool overrides are broken and dangerous and we will not be implementing things that way! I'll also point out moving the definition of time away from the module always has risk regarding what the writer of the module assumed versus what they actually have. Now for delays just to show sequence I understand those may want to track a global/TB definition, but for anything using the delay to model specific behavior you run a risk of creating broken simulations. For these I always use the new SystemVerilog constructs to define the time unit/precision inside the module and leave the global timescale for this TB/sequence use.
Cary

    On Thursday, January 28, 2021, 12:30:26 PM PST, Evan Lavelle <sa2...@cy...> wrote:  
 
 On 28/01/2021 18:54, Cary R. via Iverilog-devel wrote:

> For your case where you know what you are doing and
> it has been thought out I would just disable the warning.
>

An excellent idea, but...

The wiki says warnings should be prefixed with 'no-' to disable them.
After some experimentation it turns out that you need to put a space
after the 'W', and the 'no-' before the 'timescale' (ie. '-W
no-timescale'). This works for the case I described, but then the case I
described only generates a warning if you compile with '-Wtimescale'
anyway, so this just restores the default behaviour.

If you have a more serious case in which some earlier modules have no
explicit timescale, and a later one does, '-W no-timescale' *doesn't*
turn off the warning. You could argue that, in this case, the user
should get a warning and shouldn't be able to turn it off. So maybe it's
not a problem, and just needs some documentation that this warning can't
in general be disabled.

Actually, a good option might be to implement a '-timescale'
command-line option for a default timescale (I think everyone else does
this), and then just remove the warning completely.


_______________________________________________
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] -Wtimescale issue

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

 FYI The no-<warning> options were added because most of the warnings are added with -Wall. It's odd regarding the space issue. I'll have to take a look. I'll look at this later and see if things match my expectation. For example: I believe having modules with the default timescale and some with a user defined timescale is potentially a huge error, where inheriting a timescale from a previous file is possibly intended (your example), but could be risky if you do not know what you are doing.

--timescale is one of our oldest enhancement requests. On the surface it is straight forward, but there is subtlety that is easy to miss. I will also point out some of the commercial tool overrides are broken and dangerous and we will not be implementing things that way! I'll also point out moving the definition of time away from the module always has risk regarding what the writer of the module assumed versus what they actually have. Now for delays just to show sequence I understand those may want to track a global/TB definition, but for anything using the delay to model specific behavior you run a risk of creating broken simulations. For these I always use the new SystemVerilog constructs to define the time unit/precision inside the module and leave the global timescale for this TB/sequence use.
Cary

    On Thursday, January 28, 2021, 12:30:26 PM PST, Evan Lavelle <sa2...@cy...> wrote:  
 
 On 28/01/2021 18:54, Cary R. via Iverilog-devel wrote:

> For your case where you know what you are doing and
> it has been thought out I would just disable the warning.
>

An excellent idea, but...

The wiki says warnings should be prefixed with 'no-' to disable them.
After some experimentation it turns out that you need to put a space
after the 'W', and the 'no-' before the 'timescale' (ie. '-W
no-timescale'). This works for the case I described, but then the case I
described only generates a warning if you compile with '-Wtimescale'
anyway, so this just restores the default behaviour.

If you have a more serious case in which some earlier modules have no
explicit timescale, and a later one does, '-W no-timescale' *doesn't*
turn off the warning. You could argue that, in this case, the user
should get a warning and shouldn't be able to turn it off. So maybe it's
not a problem, and just needs some documentation that this warning can't
in general be disabled.

Actually, a good option might be to implement a '-timescale'
command-line option for a default timescale (I think everyone else does
this), and then just remove the warning completely.


_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

Re: [Iverilog-devel] -Wtimescale issue

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

On 28/01/2021 18:54, Cary R. via Iverilog-devel wrote:

> For your case where you know what you are doing and
> it has been thought out I would just disable the warning.
>

An excellent idea, but...

The wiki says warnings should be prefixed with 'no-' to disable them.
After some experimentation it turns out that you need to put a space
after the 'W', and the 'no-' before the 'timescale' (ie. '-W
no-timescale'). This works for the case I described, but then the case I
described only generates a warning if you compile with '-Wtimescale'
anyway, so this just restores the default behaviour.

If you have a more serious case in which some earlier modules have no
explicit timescale, and a later one does, '-W no-timescale' *doesn't*
turn off the warning. You could argue that, in this case, the user
should get a warning and shouldn't be able to turn it off. So maybe it's
not a problem, and just needs some documentation that this warning can't
in general be disabled.

Actually, a good option might be to implement a '-timescale'
command-line option for a default timescale (I think everyone else does
this), and then just remove the warning completely.

Re: [Iverilog-devel] -Wtimescale issue

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

 Hi Even,
The compiler has no idea the inherited time scale is intended so warns about that. I believe you can turn the warning off. The commercial tools I have used do the same except Icarus is smart enough to not warn about modules that do not use any delays. This is not the case for the commercial tool I use the most. It warns for every module.

The intent of the warning is to inform the user that the timescale being used in the module is not defined in the file so the timescale needs to be verified. This gets very confusing when some, but not all files define a timescale. For your case where you know what you are doing and it has been thought out I would just disable the warning.
Cary

    On Thursday, January 28, 2021, 9:12:48 AM PST, Evan Lavelle <sa2...@cy...> wrote:  
 
 In an environment where you have one testbench file and multiple RTL
files, it is common to have a single timescale in the TB file, and no
timescale directives in the RTL code.

However, if you compile this as 'iverilog -Wtimescale tb.v rtl1.v ..
rtln.v', you get a timescale warning ('warning:timescale for rtl1.v
inherited from another file').

This inheritance is exactly what you want in this case, and is valid (of
course, if the timescale is not in the first file compiled, there's an
issue).

I can see that the warning would make sense if Icarus compiled each file
independently and linked the results, but it doesn't. Thoughts?


_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

Re: [Iverilog-devel] Windows command line processing...

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

I'll need to look at the code to confirm, but I'm going to guess this is an artifact of the OS/library and not something Icarus is doing.
Cary
   On Thursday, January 28, 2021, 9:48:00 AM PST, Evan Lavelle <sa2...@cy...> wrote:  
 
 ...is very different from Linux command line processing. The Linux
iverilog allows defines at the end of the command, for example, but the
Windows version seems to require all switches before the first source
file. This can be tedious when you're writing scripts on Linux, and then
have to work out why it's not working on Windows, and then find
something that works on both versions. Would it make sense to
rationalise this?


_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

[Iverilog-devel] Windows command line processing...

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

...is very different from Linux command line processing. The Linux
iverilog allows defines at the end of the command, for example, but the
Windows version seems to require all switches before the first source
file. This can be tedious when you're writing scripts on Linux, and then
have to work out why it's not working on Windows, and then find
something that works on both versions. Would it make sense to
rationalise this?

[Iverilog-devel] -Wtimescale issue

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

In an environment where you have one testbench file and multiple RTL
files, it is common to have a single timescale in the TB file, and no
timescale directives in the RTL code.

However, if you compile this as 'iverilog -Wtimescale tb.v rtl1.v ..
rtln.v', you get a timescale warning ('warning:timescale for rtl1.v
inherited from another file').

This inheritance is exactly what you want in this case, and is valid (of
course, if the timescale is not in the first file compiled, there's an
issue).

I can see that the warning would make sense if Icarus compiled each file
independently and linked the results, but it doesn't. Thoughts?

Re: [Iverilog-devel] Specify block support?

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

 Also what is supported needs to be enabled otherwise they are completely ignored. There are some known limitation/bug in what is implemented. SDF back annotation is also partially supported. As I remember the last big thing added was state-dependent path delays, but SDF support for that is not possible given the information that is passed to the runtime since we need to match delays based on equations.
I used to work on specify/SDF from time to time, but once we started working on SystemVerilog that is where all my time has gone. One thing that is blocking most of the specify bugs and the implementation of the timing checks is the ability to calculate expressions as pull items (at the consumers request) not as push items (the changing variables propagate through the expression network). This broken behavior creates races and zero time glitches. I started a rework for the base expressions as standalone code, but it has been almost a decade since I touched it :(. When I get back to it I will be changing the code to support move semantics and other thing available in C++11 or later.

Cary

    On Saturday, January 2, 2021, 10:14:45 AM PST, Evan Lavelle <sa2...@cy...> wrote:  
 
 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



_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel