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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi all,

This patch fixes blif_reg to continue running after error is detected.
Also errors are now dumped to logfile (not screen) as for other
testsuites.

-Yura

Hi all,

This patch adds short description of BLIF testsuite in ivtest's README.

-Yura

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

>> The expression is
>>
>> 	   rf[write_idx] <= write_data;
>>
>> inside an always @(posedge clk) block. I imagine this is non-trivial to
>> fix, but I'd be very happy to be wrong.
>
> Handling this relatively simple case might not be too hard, but making the tool robust (handling all 
> the possible ways a user might use array words on the LHS of an assignment) would be a lot of work. 

For the case of -t sizer, I'd be happy if the memory was reported as an
atomic unit with no synthesis of internals. So count the circuit size
for generation of the LHS index, the RHS value, and any mux and enable
logic needed to get the right value assigned at the right time.

> For example, someone might quite reasonably write multiple assignments targeting different words or 
> ranges of words in an array.

You're talking of ranges of addresses of words, not ranges of bits
within a word, I hope? Writing multiple words at the same time requires
multiple write ports to the memory (which I guess one would generally
want to avoid). For -t sizer, output like

  MEM 64-bit words, size 16, 3 read-ports, 1 write-port

would be nice.

> There are a couple of other ways you could eliminate this warning:
>
> 1) Move the register file read outside the always @* block, e.g.
>
>    assign stored_a_data = rf[a_idx];
>
>    always @* begin
>      if (a_idx == 15)
>        a_data = 64'b0;
>      else if (write_enable && a_idx == write_idx)
>        a_data = write_data;
>      else
>        a_data = stored_a_data;
>    end

[...]

> I would always go for option 1, as it protects against accidentally
> missing a sensitivity.

Thanks a lot for the advice!

I admit I also don't quite understand the fine distinction between

  assign stored_a_data = rf[a_idx];

and

  always @* 
    stored_a_data = rf[a_idx];

But I take it the former is a more primitive thing, as far as the
simulator is concerned?

Regards,
/Niels

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

Niels Möller wrote:
> Hi,
>
> I tried to use the nice -t sizer target on my cpu
> (https://git.lysator.liu.se/nisse/instr16), but it failed on the
> register file (attached). There are a couple of errors
>
>    $ iverilog -t sizer reg-file.vl -o reg-file.txt
>    ...
>    reg-file.vl:57: sorry: Assignment to variable location in memory is not currently supported in synthesis.
>    reg-file.vl:62: sorry: Assignment to variable location in memory is not currently supported in synthesis.
>
> The expression is
>
> 	   rf[write_idx] <= write_data;
>
> inside an always @(posedge clk) block. I imagine this is non-trivial to
> fix, but I'd be very happy to be wrong.

Handling this relatively simple case might not be too hard, but making the tool robust (handling all 
the possible ways a user might use array words on the LHS of an assignment) would be a lot of work. 
For example, someone might quite reasonably write multiple assignments targeting different words or 
ranges of words in an array.

> BTW, iverlog -Wall also complains
>
>    reg-file.vl:37: warning: @* is sensitive to all 15 words in array 'rf'.
>
> on the combinatorial output block. Any explanation (or pointer thereto)
> on how to get this right is also appreciated. As far as I understand,
> I'd need to explicitly list the relevant signals (all the module inputs
> except clk and reset, I think) in the sensitivity list, and then
> convince myself that I still get the desired behavior in all cases.

The first thing to say is that this warning doesn't mean there's necessarily anything wrong with 
your code. If the code in your always block has no side effects, all it means is that your 
simulation may run more slowly than it otherwise might. So if your simulations are running fast 
enough, you can just disable this particular warning by

   -Wall -Wno-sensitivity-entire-array

There are a couple of other ways you could eliminate this warning:

1) Move the register file read outside the always @* block, e.g.

   assign stored_a_data = rf[a_idx];

   always @* begin
     if (a_idx == 15)
       a_data = 64'b0;
     else if (write_enable && a_idx == write_idx)
       a_data = write_data;
     else
       a_data = stored_a_data;
   end

2) Create an explicit sensitivity list, e.g.

   always @(write_enable or write_idx or write_data or a_idx or rf[a_idx]) begin
     if (a_idx == 15)
       a_data = 64'b0;
     else if (write_enable && a_idx == write_idx)
       a_data = write_data;
     else
       a_data = rf[a_idx];
   end

(in both cases, having separate always blocks for your three read ports may be slightly more 
efficient from a simulation point of view).

I would always go for option 1, as it protects against accidentally missing a sensitivity.

Martin

Hi,

I tried to use the nice -t sizer target on my cpu
(https://git.lysator.liu.se/nisse/instr16), but it failed on the
register file (attached). There are a couple of errors

  $ iverilog -t sizer reg-file.vl -o reg-file.txt
  ...
  reg-file.vl:57: sorry: Assignment to variable location in memory is not currently supported in synthesis.
  reg-file.vl:62: sorry: Assignment to variable location in memory is not currently supported in synthesis.

The expression is

	   rf[write_idx] <= write_data;

inside an always @(posedge clk) block. I imagine this is non-trivial to
fix, but I'd be very happy to be wrong.

BTW, iverlog -Wall also complains

  reg-file.vl:37: warning: @* is sensitive to all 15 words in array 'rf'.

on the combinatorial output block. Any explanation (or pointer thereto)
on how to get this right is also appreciated. As far as I understand,
I'd need to explicitly list the relevant signals (all the module inputs
except clk and reset, I think) in the sensitivity list, and then
convince myself that I still get the desired behavior in all cases.

Regards,
/Niels

Hi,

Just a gentle reminder, so the issue does not get completely lost. Any
comment is welcome. I may rebase the pull request if necessary.

Regards,
Orson

On 03/29/2016 06:46 PM, Maciej Sumiński wrote:
> Hi,
> 
> I have just created a pull request for the mentioned patches [1]. The
> branch is rebased on the current master.
> 
> I have also found a minor bug, that must have been hard to trigger and
> observe. During net resolution (compile_cleanup()@vvp/compile.cc), nets
> are assigned the last observed scope (aka current_scope), which is not
> always the real parent scope.
> 
> The bug can be triggered by running the attached example:
> ----------------
> vpi error: cannot place value change callback on automatically allocated
> variable 'clk'
> ----------------
> even though clk should belong to 'auto_scope' module, which is a static
> scope. Upon closer inspection it has 'strange_label' scope assigned, as
> it was the last .scope directive in the a.out file. It is enough to
> comment out the scope label to make it run properly.
> 
> I have fixed it by simply correcting the scope after a net is created. I
> am not sure if that is the most elegant way of solving the problem, but
> I hope it helps to demonstrate the issue. The patch is not included in
> the pull request.
> 
> Regards,
> Orson
> 
> 1. https://github.com/steveicarus/iverilog/pull/95
> 
> On 03/22/2016 09:22 PM, Stephen Williams wrote:
>>
>> Sounds good, send me a pull request when you feel ready.
>>
>> On 03/22/2016 12:58 PM, Maciej Sumi?ski wrote:
>>> Hi Martin,
>>
>>> I see your point, I had overlooked the always block. I agree it has
>>> to be changed, and patches in the automatic_rebased branch should
>>> fix the problem.
>>
>>> Regards, Orson
>>
>>> On 03/22/2016 08:30 PM, Martin Whitaker wrote:
>>>> Hi Orson,
>>>>
>>>> Maciej Sumi?ski wrote:
>>>>> I presume you talk about vhdl_string & vhdl_image_attr tests.
>>>>> The variables causing warnings are initialized inside a module
>>>>> scope. If I understand the standard correctly (6.21 @
>>>>> 1800-2012), it is not required to explicitly declare such
>>>>> variables as static, because it is illegal for them to be
>>>>> automatic (see an example on p.91 @ 1800-2012).
>>>>
>>>> Yes, those are the tests I was talking about. Taking
>>>> vhdl_image_attr as an example, the relevant part of the vhdlpp
>>>> output is:
>>>>
>>>> always begin : __scope_1 bit[32'd7:32'd0] var_char   = "o"; int
>>>> var_int   = 32'd10; real var_real   = 12.34; time var_time   =
>>>> 10ns; ...
>>>>
>>>> These variables are declared inside a begin/end block, so
>>>> SystemVerilog permits them to be declared as static or automatic,
>>>> hence the rule about having an explicit static keyword applies.
>>>> The equivalent example on page 91 of 1800-2012 is
>>>>
>>>> initial begin int svar2 = 2; // static/automatic needed to show
>>>> intent ...
>>>>
>>>> To be sure I'm reading the standard correctly, I tried this
>>>> example
>>>>
>>>> module test();
>>>>
>>>> integer legal = 1;
>>>>
>>>> initial begin: named_block integer illegal = 1; end
>>>>
>>>> endmodule
>>>>
>>>> on another simulator. It accepted the declaration of 'legal' and
>>>> warned that the declaration of 'illegal' required an explicit
>>>> 'static' keyword.
>>>>
>>>>> Anyway, if you would rather vhdlpp emit lifetime for each
>>>>> variable, I pushed a fix to automatic_rebased branch [1] on
>>>>> github. It also contains patches to make Larry's use_func test
>>>>> case work and passes all the tests, so feel free to merge it.
>>>>
>>>> I'll leave this for Steve.
>>>>
>>>> Regards,
>>>>
>>>> Martin

I think you are missing the point. Icarus Verilog synthesis will
never be up to what you can get for free from Xilinx (for Xilinx
parts) so you are better off using Xilinx tools for synthesis.
We recommend that you follow that path. Use Icarus Verilog for
simulation, but use xst (or Vivado) for synthesis.

On 04/12/2016 11:02 PM, Ravi Selvaraj wrote:
> Thank You very much for that valuable suggestion of using Icarus Verilog
> V10 for synthesis.
> As per your guidelines given with the tool I will try with that.
> 
> One point I got a doubt is that in Iverilog 0.8.6, there are commands like:
> 
> iverilog -parch=virtex -ppart=v50-pq240-6 -tfpga foo.vl
> 
> Are there any such commands for BLIF file generation with Icarus. If so
> please convey the
> suitable version of Xilinx ISE that supports BLIF. I mean, how to get it
> synthesized to measure the hardware area
> and power consumption of the design?
> 
> 
> On Tue, Apr 12, 2016 at 11:34 PM, Stephen Williams <st...@ic...
> <mailto:st...@ic...>> wrote:
> 
> 
>     Strictly speaking, no version synthesizes directly to any FPGA,
>     and all versions support simulation for any target. Let me
>     explain:
> 
>     Synthesis all the way down to a specific technology is not
>     directly supported by Icarus Verilog. We made the conscious
>     choice that the vendors are never going to make it easy and
>     will generally provide free tools to target their devices
>     anyhow, so it is better to let the vendor provide the synthesizers.
>     In your case, xst from WebPack should work fine for you.
> 
>     Simulation is a different story, and Icarus Verilog tries to
>     support as wide a field as possible, and many people do indeed
>     use it to simulate designs intended for Xilinx and other FPGA
>     devices. I recommend v10 for that.
> 
>     The synthesis support that Icarus Verilog does have is for
>     more generic targets, i.e. BLIF and sizer, or as a foundation
>     for a 3rd party to provide their own code generator to target
>     odd devices. In this case, the 0.8 synthesis has since been
>     outrun by v10 synthesis support.
> 
>     On 04/12/2016 10:45 AM, Ravi Selvaraj wrote:
>     > I am using Icarus Verilog 0.8.6, the one which supports synthesis.
>     > When I tried to synthesis a Verilog file targeting Virtex -4 FPGA, I
>     > have got a command that there is no such target.
>     >
>     > Can you please suggest me the Icarus tool version that supports
>     Virtex -
>     > 4 FPGA based synthesis.
>     > --
>     > Ravi. S
> 
> 
>     --
>     Steve Williams                "The woods are lovely, dark and deep.
>     steve at icarus.com <http://icarus.com>           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."
> 
>     ------------------------------------------------------------------------------
>     Find and fix application performance issues faster with Applications
>     Manager
>     Applications Manager provides deep performance insights into
>     multiple tiers of
>     your business applications. It resolves application problems quickly and
>     reduces your MTTR. Get your free trial!
>     https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>     _______________________________________________
>     Iverilog-devel mailing list
>     Ive...@li...
>     <mailto:Ive...@li...>
>     https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 
> 
> -- 
> Ravi. S
> Assistant Professor
> ECE Dept
> 
> 
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           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."

Ravi -

On Wed, Apr 13, 2016 at 11:32:37AM +0530, Ravi Selvaraj wrote:
> Are there any such commands for BLIF file generation with Icarus.

It sounds like you might be happier with Yosys
http://www.clifford.at/yosys/about.html

  - Larry

Thank You very much for that valuable suggestion of using Icarus Verilog
V10 for synthesis.
As per your guidelines given with the tool I will try with that.

One point I got a doubt is that in Iverilog 0.8.6, there are commands like:

iverilog -parch=virtex -ppart=v50-pq240-6 -tfpga foo.vl

Are there any such commands for BLIF file generation with Icarus. If so
please convey the
suitable version of Xilinx ISE that supports BLIF. I mean, how to get it
synthesized to measure the hardware area
and power consumption of the design?

On Tue, Apr 12, 2016 at 11:34 PM, Stephen Williams <st...@ic...> wrote:

>
> Strictly speaking, no version synthesizes directly to any FPGA,
> and all versions support simulation for any target. Let me
> explain:
>
> Synthesis all the way down to a specific technology is not
> directly supported by Icarus Verilog. We made the conscious
> choice that the vendors are never going to make it easy and
> will generally provide free tools to target their devices
> anyhow, so it is better to let the vendor provide the synthesizers.
> In your case, xst from WebPack should work fine for you.
>
> Simulation is a different story, and Icarus Verilog tries to
> support as wide a field as possible, and many people do indeed
> use it to simulate designs intended for Xilinx and other FPGA
> devices. I recommend v10 for that.
>
> The synthesis support that Icarus Verilog does have is for
> more generic targets, i.e. BLIF and sizer, or as a foundation
> for a 3rd party to provide their own code generator to target
> odd devices. In this case, the 0.8 synthesis has since been
> outrun by v10 synthesis support.
>
> On 04/12/2016 10:45 AM, Ravi Selvaraj wrote:
> > I am using Icarus Verilog 0.8.6, the one which supports synthesis.
> > When I tried to synthesis a Verilog file targeting Virtex -4 FPGA, I
> > have got a command that there is no such target.
> >
> > Can you please suggest me the Icarus tool version that supports Virtex -
> > 4 FPGA based synthesis.
> > --
> > Ravi. S
>
>
> --
> Steve Williams                "The woods are lovely, dark and deep.
> steve at icarus.com           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."
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

-- 
Ravi. S
Assistant Professor
ECE Dept

Strictly speaking, no version synthesizes directly to any FPGA,
and all versions support simulation for any target. Let me
explain:

Synthesis all the way down to a specific technology is not
directly supported by Icarus Verilog. We made the conscious
choice that the vendors are never going to make it easy and
will generally provide free tools to target their devices
anyhow, so it is better to let the vendor provide the synthesizers.
In your case, xst from WebPack should work fine for you.

Simulation is a different story, and Icarus Verilog tries to
support as wide a field as possible, and many people do indeed
use it to simulate designs intended for Xilinx and other FPGA
devices. I recommend v10 for that.

The synthesis support that Icarus Verilog does have is for
more generic targets, i.e. BLIF and sizer, or as a foundation
for a 3rd party to provide their own code generator to target
odd devices. In this case, the 0.8 synthesis has since been
outrun by v10 synthesis support.

On 04/12/2016 10:45 AM, Ravi Selvaraj wrote:
> I am using Icarus Verilog 0.8.6, the one which supports synthesis.
> When I tried to synthesis a Verilog file targeting Virtex -4 FPGA, I
> have got a command that there is no such target.
> 
> Can you please suggest me the Icarus tool version that supports Virtex -
> 4 FPGA based synthesis.
> -- 
> Ravi. S

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           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 am using Icarus Verilog 0.8.6, the one which supports synthesis.
When I tried to synthesis a Verilog file targeting Virtex -4 FPGA, I have
got a command that there is no such target.

Can you please suggest me the Icarus tool version that supports Virtex - 4
FPGA based synthesis.
-- 
Ravi. S

For the scheduling part, there is an internal attribute that elaboration
can attach to the process (the NetProc instance?) to adjust scheduling
at startup. That would probably be the best way to handle it.

On 4/8/16 1:09 AM, Martin Whitaker wrote:
> Alan Manuel Gloria wrote:
>> In particular, always_comb is not precisely the same as always@*;
>> always_comb executes its contents at startup immediately, then blocks on
>> sensitivity list.  So instead of always@* begin foo; bar; end, it's more
>> like always begin foo; bar; @*; end  This hack is because constant wires
>> and parameters might not trigger @*, leading to an RTL-vs-gate mismatch
>> during simulation startup if you use always@*.
>
> That's not too hard to implement. What will take more work will be the differences in the implied
> sensitivity list - in particular the sensitivity to the contents of called functions. Then there's
> the additional checks for delays and multiple assignments...
>
> Martin
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           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."

Alan Manuel Gloria wrote:
> In particular, always_comb is not precisely the same as always@*;
> always_comb executes its contents at startup immediately, then blocks on
> sensitivity list.  So instead of always@* begin foo; bar; end, it's more
> like always begin foo; bar; @*; end  This hack is because constant wires
> and parameters might not trigger @*, leading to an RTL-vs-gate mismatch
> during simulation startup if you use always@*.

That's not too hard to implement. What will take more work will be the differences in the implied 
sensitivity list - in particular the sensitivity to the contents of called functions. Then there's 
the additional checks for delays and multiple assignments...

Martin

On Thu, Mar 24, 2016 at 5:44 AM, Larry Doolittle <ldo...@re...>
wrote:

> Friends -
>
> On Wed, Mar 23, 2016 at 09:23:41PM +0000, Jonathan David wrote:
> > I would expect that the module level  features (ie RTL features like
> these ) would be farther along than the class and package related
> features. But I haven't installed icarus for a while, so can't really
> comment on the present state.
>
> I looked up what the state of always_ff, always_latch, and always_comb
> are in Icarus git master.
>
> They are present and accounted for as language-level-specific keywords
> in lexor_keyword.gperf and parse.y.  But parse.y never uses them in
> in the grammar.
>
> Adding them to the grammar would be easy -- even I could do that.
> But then Icarus would need new enum values for ivl_process_type_e,
> and handle their semantics correctly.  This has to be done without
> breaking the old "always" semantics.
>

In particular, always_comb is not precisely the same as always@*;
always_comb executes its contents at startup immediately, then blocks on
sensitivity list.  So instead of always@* begin foo; bar; end, it's more
like always begin foo; bar; @*; end  This hack is because constant wires
and parameters might not trigger @*, leading to an RTL-vs-gate mismatch
during simulation startup if you use always@*.

As I understand it, always_ff and always_latch behave exactly the same as
always, but an implementation is supposed to warn if it will not be
inferred as a ff or latch.  Whether actual tools actually warn, and whether
those warnings will get glossed over in practice when you're synthesizing a
100k gate product with not the best coding style, is a separate question.
Personally,  I'd prefer a flag somewhere that indicates that an
always_ff/always_latch not being inferrable to ff/latch should be thrown as
an error rather than a warning.

>
> Good thing we have ivtest!
>
>   - Larry
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

[Just FYI]

The "net-type" extension in SV is very similar to what VHDL has always done (since the 80s), and falls somewhat short of what you want. Verilog-AMS does a lot better with voltages and currents, but for some reason that's viewed as analog-only by the EDA vendors/developers.

It's somewhat unlikely the situation will improve if left to the SV committees to fix (there's a general dislike of things that look analog there), so there is an opportunity to fix how it works in the open source simulators, e.g.:

  * A wire should be neutral interconnect
  * Drivers and receivers have types (not the wires)
  * Wires should support potential and flow in digital (not potential or flow)

Noting that a packed struct type on a port is an array of wires, rather than a single wire with a composite value.

My current plan for the next SV LRM is (unlikely to happen):

  * Make "logic" a user defined type - i.e. move it to headers in user space (as done in VHDL)
  * Implement "logic" as a template type with orthogonal value, strength and certainty components
  * Implement the built-in primitives in user space (transistor models) based on the logic template type

That lets you create an alternative logic type that is voltage based, but you don't have to rewrite module code to get it to work (polymorphism). Resolving drivers & receivers across different types is a fairly simple process, but isn't implemented in either SV or VHDL -

  * Convert all drivers to a common resolvable type (with lossless conversions)
  * Resolve converted drivers
  * Convert result to receivers (can be lossy conversions, e.g. voltage to logic 1/0)

If you can get that working you can add RF modeling by making the value component of a net-type a spectrum with a location and polarisation etc. and add being able to do the resolution on a per receiver basis (drivers & receivers being antennas).

Kev.

On 03/25/2016 01:22 PM, Martin Whitaker wrote:
> Krishnaraj Bhat wrote:
>> Hi All,
>>
>> Could any one please let me know whether Icarus supports passing Structure
>> types as module ports? We have to pass voltage/current values across the
>> module ports. For this we are thinking of using a structure with voltage
>> and current values as members of structure with real data type. And using
>> this struct as module port. Could any one please let me know whether this
>> is supported in Icarus?
> Icarus doesn't support unpacked structs. Packed struct types can be used for module ports, but 
> packed structs can't contain real values.
>
> Martin
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Hi,

I have just created a pull request for the mentioned patches [1]. The
branch is rebased on the current master.

I have also found a minor bug, that must have been hard to trigger and
observe. During net resolution (compile_cleanup()@vvp/compile.cc), nets
are assigned the last observed scope (aka current_scope), which is not
always the real parent scope.

The bug can be triggered by running the attached example:
----------------
vpi error: cannot place value change callback on automatically allocated
variable 'clk'
----------------
even though clk should belong to 'auto_scope' module, which is a static
scope. Upon closer inspection it has 'strange_label' scope assigned, as
it was the last .scope directive in the a.out file. It is enough to
comment out the scope label to make it run properly.

I have fixed it by simply correcting the scope after a net is created. I
am not sure if that is the most elegant way of solving the problem, but
I hope it helps to demonstrate the issue. The patch is not included in
the pull request.

Regards,
Orson

1. https://github.com/steveicarus/iverilog/pull/95

On 03/22/2016 09:22 PM, Stephen Williams wrote:
> 
> Sounds good, send me a pull request when you feel ready.
> 
> On 03/22/2016 12:58 PM, Maciej Sumi?ski wrote:
>> Hi Martin,
> 
>> I see your point, I had overlooked the always block. I agree it has
>> to be changed, and patches in the automatic_rebased branch should
>> fix the problem.
> 
>> Regards, Orson
> 
>> On 03/22/2016 08:30 PM, Martin Whitaker wrote:
>>> Hi Orson,
>>>
>>> Maciej Sumi?ski wrote:
>>>> I presume you talk about vhdl_string & vhdl_image_attr tests.
>>>> The variables causing warnings are initialized inside a module
>>>> scope. If I understand the standard correctly (6.21 @
>>>> 1800-2012), it is not required to explicitly declare such
>>>> variables as static, because it is illegal for them to be
>>>> automatic (see an example on p.91 @ 1800-2012).
>>>
>>> Yes, those are the tests I was talking about. Taking
>>> vhdl_image_attr as an example, the relevant part of the vhdlpp
>>> output is:
>>>
>>> always begin : __scope_1 bit[32'd7:32'd0] var_char   = "o"; int
>>> var_int   = 32'd10; real var_real   = 12.34; time var_time   =
>>> 10ns; ...
>>>
>>> These variables are declared inside a begin/end block, so
>>> SystemVerilog permits them to be declared as static or automatic,
>>> hence the rule about having an explicit static keyword applies.
>>> The equivalent example on page 91 of 1800-2012 is
>>>
>>> initial begin int svar2 = 2; // static/automatic needed to show
>>> intent ...
>>>
>>> To be sure I'm reading the standard correctly, I tried this
>>> example
>>>
>>> module test();
>>>
>>> integer legal = 1;
>>>
>>> initial begin: named_block integer illegal = 1; end
>>>
>>> endmodule
>>>
>>> on another simulator. It accepted the declaration of 'legal' and
>>> warned that the declaration of 'illegal' required an explicit
>>> 'static' keyword.
>>>
>>>> Anyway, if you would rather vhdlpp emit lifetime for each
>>>> variable, I pushed a fix to automatic_rebased branch [1] on
>>>> github. It also contains patches to make Larry's use_func test
>>>> case work and passes all the tests, so feel free to merge it.
>>>
>>> I'll leave this for Steve.
>>>
>>> Regards,
>>>
>>> Martin
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
> Transform Data into Opportunity.
>>> Accelerate data analysis in your applications with Intel Data
>>> Analytics Acceleration Library. Click to learn more. 
>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 
>>> _______________________________________________ Iverilog-devel
>>> mailing list Ive...@li... 
>>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>>
> 
> 
> 
>> ------------------------------------------------------------------------------
> 
> 
> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with Intel Data
>> Analytics Acceleration Library. Click to learn more. 
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> 
> 
> 
>> _______________________________________________ Iverilog-devel
>> mailing list Ive...@li... 
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Krishnaraj Bhat wrote:
> Hi All,
>
> Could any one please let me know whether Icarus supports passing Structure
> types as module ports? We have to pass voltage/current values across the
> module ports. For this we are thinking of using a structure with voltage
> and current values as members of structure with real data type. And using
> this struct as module port. Could any one please let me know whether this
> is supported in Icarus?

Icarus doesn't support unpacked structs. Packed struct types can be used for module ports, but 
packed structs can't contain real values.

Martin

The user defined types are a recent addition (2012) to systemverilog. You may find they are not implented yet.

Sent from Yahoo Mail on Android 

  On Fri, Mar 25, 2016 at 12:57 AM, Krishnaraj Bhat<kri...@gm...> wrote:   Hi All,

Could any one please let me know whether Icarus supports passing Structure types as module ports? We have to pass voltage/current values across the module ports. For this we are thinking of using a structure with voltage and current values as members of structure with real data type. And using this struct as module port. Could any one please let me know whether this is supported in Icarus?

Thanks in advance,
Krishnaraj------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Hi All,

Could any one please let me know whether Icarus supports passing Structure
types as module ports? We have to pass voltage/current values across the
module ports. For this we are thinking of using a structure with voltage
and current values as members of structure with real data type. And using
this struct as module port. Could any one please let me know whether this
is supported in Icarus?

Thanks in advance,
Krishnaraj

Friends -

On Wed, Mar 23, 2016 at 09:23:41PM +0000, Jonathan David wrote:
> I would expect that the module level  features (ie RTL features like these ) would be farther along than the class and package related features. But I haven't installed icarus for a while, so can't really comment on the present state.

I looked up what the state of always_ff, always_latch, and always_comb
are in Icarus git master.

They are present and accounted for as language-level-specific keywords
in lexor_keyword.gperf and parse.y.  But parse.y never uses them in
in the grammar.

Adding them to the grammar would be easy -- even I could do that.
But then Icarus would need new enum values for ivl_process_type_e,
and handle their semantics correctly.  This has to be done without
breaking the old "always" semantics.

Good thing we have ivtest!

  - Larry

A few comments regarding the provided source.
1. I usually use logic for all signals in RTL code, I use wire only for
tristate signals
2. for coding registers always_ff is great, but the 'out' signal should not
be a wire, it should be logic/reg (this two are the same in SystemVerilog)
3. the out++ syntax is not appropriate for RTL, since it is not clear if
the assignment is blocking or not. I usually use ++ in bench code, inside
initial statements or for loops

Icarus has only a partial SystemVerilog support, not even all RTL features
are supported. In case somebody would like to create a table of supported
features, I am wiling to help with code examples, unit tests, with the
focus on RTL features.

Regards,
Iztok Jeras

On Wed, Mar 23, 2016 at 8:37 PM, Corey Olson <cor...@gm...> wrote:

> Correct me if I'm wrong, but I believe the 'out ++' portion is not
> standard Verilog.  Therefore it sounds like some SystemVerilog constructs
> are supported by Icarus and some are not.  Is there a list anywhere of the
> things that are supported?
>
> -Corey
>
> On Wed, Mar 23, 2016 at 1:34 PM, Larry Doolittle <ldo...@re...
> > wrote:
>
>> Krishnaraj -
>>
>> On Wed, Mar 23, 2016 at 01:56:02PM +0530, Krishnaraj Bhat wrote:
>> > Tried to compile a simple up-counter system Verilog module.
>> > But compilation fails.
>> > Could you please let me
>> > know whether the latest version (10.1) supports system verilog?
>>
>> I'm not a SystemVerilog language laywer.  I suspect the literal answer
>> is "no", there are odd corners of the language that don't work in
>> iverilog.  Practically, it's supposed to be usable now.
>>
>> I don't know why you think you can use non-blocking assignment to
>> a wire, or what "always_ff" is supposed to mean.  But the following
>> module compiles just fine under Icarus.  There are no SystemVerilog
>> language features used here, just ordinary Verilog.
>>
>> module up_counter (
>>   output reg [7:0] out,
>>   input  wire      enable,
>>   input  wire      clk,
>>   input  wire      reset
>> );
>> always @(posedge clk)
>>   if (reset) begin
>>     out <= 8'b0;
>>   end else if (enable) begin
>>     out ++;
>>   end
>> endmodule
>>
>>    - Larry
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>

I'm not sure about what features are and are not supported, but I believe that the 1800-2012 standard is available for free through the ieee, thanks to an Accelera program. For those of you who are not aware what always_ff or always_comb etc are supposed to do.I would expect that the module level  features (ie RTL features like these ) would be farther along than the class and package related features. But I haven't installed icarus for a while, so can't really comment on the present state.Jonathan 

Sent from Yahoo Mail on Android 

  On Wed, Mar 23, 2016 at 12:37 PM, Corey Olson<cor...@gm...> wrote:   Correct me if I'm wrong, but I believe the 'out ++' portion is not standard Verilog.  Therefore it sounds like some SystemVerilog constructs are supported by Icarus and some are not.  Is there a list anywhere of the things that are supported?

-Corey
On Wed, Mar 23, 2016 at 1:34 PM, Larry Doolittle <ldo...@re...> wrote:

Krishnaraj -

On Wed, Mar 23, 2016 at 01:56:02PM +0530, Krishnaraj Bhat wrote:
> Tried to compile a simple up-counter system Verilog module.
> But compilation fails.
> Could you please let me
> know whether the latest version (10.1) supports system verilog?

I'm not a SystemVerilog language laywer.  I suspect the literal answer
is "no", there are odd corners of the language that don't work in
iverilog.  Practically, it's supposed to be usable now.

I don't know why you think you can use non-blocking assignment to
a wire, or what "always_ff" is supposed to mean.  But the following
module compiles just fine under Icarus.  There are no SystemVerilog
language features used here, just ordinary Verilog.

module up_counter (
  output reg [7:0] out,
  input  wire      enable,
  input  wire      clk,
  input  wire      reset
);
always @(posedge clk)
  if (reset) begin
    out <= 8'b0;
  end else if (enable) begin
    out ++;
  end
endmodule

   - Larry

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Correct me if I'm wrong, but I believe the 'out ++' portion is not standard
Verilog.  Therefore it sounds like some SystemVerilog constructs are
supported by Icarus and some are not.  Is there a list anywhere of the
things that are supported?

-Corey

On Wed, Mar 23, 2016 at 1:34 PM, Larry Doolittle <ldo...@re...>
wrote:

> Krishnaraj -
>
> On Wed, Mar 23, 2016 at 01:56:02PM +0530, Krishnaraj Bhat wrote:
> > Tried to compile a simple up-counter system Verilog module.
> > But compilation fails.
> > Could you please let me
> > know whether the latest version (10.1) supports system verilog?
>
> I'm not a SystemVerilog language laywer.  I suspect the literal answer
> is "no", there are odd corners of the language that don't work in
> iverilog.  Practically, it's supposed to be usable now.
>
> I don't know why you think you can use non-blocking assignment to
> a wire, or what "always_ff" is supposed to mean.  But the following
> module compiles just fine under Icarus.  There are no SystemVerilog
> language features used here, just ordinary Verilog.
>
> module up_counter (
>   output reg [7:0] out,
>   input  wire      enable,
>   input  wire      clk,
>   input  wire      reset
> );
> always @(posedge clk)
>   if (reset) begin
>     out <= 8'b0;
>   end else if (enable) begin
>     out ++;
>   end
> endmodule
>
>    - Larry
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Krishnaraj -

On Wed, Mar 23, 2016 at 01:56:02PM +0530, Krishnaraj Bhat wrote:
> Tried to compile a simple up-counter system Verilog module.
> But compilation fails.
> Could you please let me
> know whether the latest version (10.1) supports system verilog?

I'm not a SystemVerilog language laywer.  I suspect the literal answer
is "no", there are odd corners of the language that don't work in
iverilog.  Practically, it's supposed to be usable now.

I don't know why you think you can use non-blocking assignment to
a wire, or what "always_ff" is supposed to mean.  But the following
module compiles just fine under Icarus.  There are no SystemVerilog
language features used here, just ordinary Verilog.

module up_counter (
  output reg [7:0] out,
  input  wire      enable,
  input  wire      clk,
  input  wire      reset    
);
always @(posedge clk)
  if (reset) begin 
    out <= 8'b0;
  end else if (enable) begin
    out ++;
  end
endmodule

   - Larry

Hello,

I am using Icarus tool for  simulating the verilog models.

I have a question regarding Icarus tool. Now I am working on System verilog
and want to simulate the system verilog models. I have
 downloaded latest version v.10.1 of Icarus tool. Built it and installed it
in my system. Tried to compile a simple up-counter system Verilog module.
But compilation fails. Below is the command I have used to compile the
module.

iverilog -g2005-sv xxxx.sv.

I have even tried with the -g2012 flag. But the result is same. As per my
limited knowledge (based on google search) Icarus supports system verilog.
But I want to confirm about this in this forum. Could you please let me
know whether the latest version (10.1) supports system verilog? If so, what
might be the  reason for compilation error of the attached system verilog
module.

Thank you in advance,
Krishnaraj Bhat

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

iverilog-devel — Conversations on matters of Icarus Verilog development