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

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

My GTKWave is not able to load, when I try open it through terminal window
with this command

$ open gtkwave -a full_adder.vcd

It shows an error showing

"/Desktop/tutorial1/gtkwave does not exist"

 From a bug report, I learn there is now a verilog-10.2 tarball available. 
Is this intended to be an official release?

I notice the latest version on SourceForge is still 10.0.

I am simulating full adder using a half adder. Files are as half_adder.v
and full_adder.v . I compile these files using half_adder.v as root file
using command
 $ iverilog -s half_adder.v -o sim_full_adder full_adder.v full_adder_tb.v

This gives an error
   error: unable to find the root module "half_adder" in verilog source.
        : Perhaps ''-s half_adder'' is incorrect?

Ah, OK.  I suspected it might be correct behavior once I tracked it down,
but since it was different, I thought I might bring it up.  I'll have to
adjust my tests...

--Jim

On Fri, Apr 21, 2017, 3:26 PM Martin Whitaker <ic...@ma...>
wrote:

> Jim Peterson wrote:
> ...
> > Devs,
> >
> > Commit 54feb8... has altered the expected behavior of my simulations.
> > In particular, outputs at the beginning are now unknown (x) rather than
> > the expected value.  Test code is at the end of this email (most of it
> > is copyright Xilinx).
>
> It's probably easier to explain with a simpler example:
>
>    module test();
>
>    reg a = 0;
>    reg b;
>
>    always @* begin
>      b = a;
>    end
>
>    initial begin
>      a = 0;
>      #1 $display(a,,b);
>      a = 1;
>      #1 $display(a,,b);
>    end
>
>    endmodule
>
> This example contains three separate processes:
>
> 1. The process that sets the initial value of a.
> 2. The process that executes the 'always' statement.
> 3. The process that executes the 'initial' statement.
>
> Standard Verilog does not specify which order these three processes are
> run. If either (1) or (3) run before (2), 'a' is already set to '0' when
> the 'always' statement is first run and the '@*' event doesn't trigger
> until 'a' is changed to '1' at time 1. So for standard Verilog, either
>
>    0 x
>    1 1
>
> or
>
>    0 0
>    1 1
>
> are valid outputs from this example, depending on the order the processes
> are executed.
>
> When compiling standard Verilog, Icarus tries to protect you from
> inadvertent races like this by scheduling the processes that execute
> 'always' statements first. But this is not required by the IEEE standard,
> and other simulators may behave differently.
>
> SystemVerilog, however, adds a rule for variable initialisation:
>
> "Setting the initial value of a static variable as part of the variable
> declaration (including static class members) shall occur before any initial
> or always procedures are started (also see 6.21 and 10.5 on variable
> initialization with static and automatic lifetimes)."
>
> so the only legal output from the above example is
>
>    0 x
>    1 1
>
> Before commit 54feb8..., Icarus wasn't following this rule. Now it does,
> but only if you specify a SystemVerilog language generation. If you compile
> with -g2005 or earlier, you get the old behaviour.
>
> To fix this ordering problem, SystemVerilog provides the 'always_comb'
> statement, which is guaranteed to run once at time 0, after all the
> 'initial' statements and variable initialisations have run. But I'm afraid
> Icarus doesn't yet support 'always_comb'.
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Jim Peterson wrote:
...
> Devs,
>
> Commit 54feb8... has altered the expected behavior of my simulations.
> In particular, outputs at the beginning are now unknown (x) rather than
> the expected value.  Test code is at the end of this email (most of it
> is copyright Xilinx).

It's probably easier to explain with a simpler example:

   module test();

   reg a = 0;
   reg b;

   always @* begin
     b = a;
   end

   initial begin
     a = 0;
     #1 $display(a,,b);
     a = 1;
     #1 $display(a,,b);
   end

   endmodule

This example contains three separate processes:

1. The process that sets the initial value of a.
2. The process that executes the 'always' statement.
3. The process that executes the 'initial' statement.

Standard Verilog does not specify which order these three processes are 
run. If either (1) or (3) run before (2), 'a' is already set to '0' when 
the 'always' statement is first run and the '@*' event doesn't trigger 
until 'a' is changed to '1' at time 1. So for standard Verilog, either

   0 x
   1 1

or

   0 0
   1 1

are valid outputs from this example, depending on the order the processes 
are executed.

When compiling standard Verilog, Icarus tries to protect you from 
inadvertent races like this by scheduling the processes that execute 
'always' statements first. But this is not required by the IEEE standard, 
and other simulators may behave differently.

SystemVerilog, however, adds a rule for variable initialisation:

"Setting the initial value of a static variable as part of the variable 
declaration (including static class members) shall occur before any initial 
or always procedures are started (also see 6.21 and 10.5 on variable 
initialization with static and automatic lifetimes)."

so the only legal output from the above example is

   0 x
   1 1

Before commit 54feb8..., Icarus wasn't following this rule. Now it does, 
but only if you specify a SystemVerilog language generation. If you compile 
with -g2005 or earlier, you get the old behaviour.

To fix this ordering problem, SystemVerilog provides the 'always_comb' 
statement, which is guaranteed to run once at time 0, after all the 
'initial' statements and variable initialisations have run. But I'm afraid 
Icarus doesn't yet support 'always_comb'.

Martin

Sorry if the below is a duplicate.  I was having trouble posting to the
list and I can't tell from the archives whether or not this post got
through:

---------- Forwarded message ----------
From: Jim Peterson <js...@ji...>
To: ive...@li...
Cc:
Bcc:
Date: Thu, 20 Apr 2017 14:51:20 -0400
Subject: commit 54feb8 *may* be a regression

Devs,

  Commit 54feb8... has altered the expected behavior of my simulations.  In
particular, outputs at the beginning are now unknown (x) rather than the
expected value.  Test code is at the end of this email (most of it is
copyright Xilinx).  The results from compiling successive commits to git
are as follows:

0[sparkle:~/personal/src/github/iverilog]676: *git checkout
635adfc01eb3844deeefcf86d1a9a9b7c284369f*
Previous HEAD position was 28b446ca... Use correct type when printing
supply pull message
HEAD is now at 635adfc0... Fully support variable initialization in
tasks/functions/named blocks.
0[sparkle:~/personal/src/github/iverilog]677: *(make distclean;
./configure; make -j 4) >& /dev/null*
0[sparkle:~/personal/src/github/iverilog]678: *(sudo make install) >&
/dev/null*
[sudo] password for jspeter:
0[sparkle:~/personal/src/github/iverilog]679: *driver/iverilog -g2005-sv -o
tb.vvp -s tb ~/tb.v -Ttyp && ./tb.vvp *
VCD info: dumpfile test.vcd opened for output.
num: 000000, out: 0
num: x00000, out: 0
num: xx0000, out: 0
num: xxx000, out: 0
num: xxxx00, out: 0
num: xxxxx0, out: 0
num: xxxxxx, out: x
0[sparkle:~/personal/src/github/iverilog]680: *git checkout
54feb89bf540fb75abc31ede03cc9be444015e94*
Previous HEAD position was 635adfc0... Fully support variable
initialization in tasks/functions/named blocks.
HEAD is now at 54feb89b... For SystemVerilog, run variable initialization
before main simulation starts.
0[sparkle:~/personal/src/github/iverilog]681: *(make distclean;
./configure; make -j 4) >& /dev/null*
0[sparkle:~/personal/src/github/iverilog]682: *(sudo make install) >&
/dev/null*
[sudo] password for jspeter:
0[sparkle:~/personal/src/github/iverilog]683: *driver/iverilog -g2005-sv -o
tb.vvp -s tb ~/tb.v -Ttyp && ./tb.vvp *
VCD info: dumpfile test.vcd opened for output.

num: 000000, out: x    * ****** first output is now x! *******

num: x00000, out: 0
num: xx0000, out: 0
num: xxx000, out: 0
num: xxxx00, out: 0
num: xxxxx0, out: 0
num: xxxxxx, out: x
0[sparkle:~/personal/src/github/iverilog]684:

  I'm not sure if this is how SystemVerilog is supposed to work (i.e.,
whether this is a regression or an improvement... or, more particularly,
whether or not the 'always' statement in the LUT6 module should run once at
startup even if its inputs were initialized before simulation), but it
certainly throws a wrench in to some of my simulation tests.  If this is
how it is supposed to work, I'm happy to fix my tests, but I thought you
ought to know.

--Jim

// $Header: /devl/xcs/repo/env/Databases/CAEInterfaces/verunilibs/data/rainier/LUT6.v,v
1.6 2007/06/01 00:22:57 yanx Exp $
////////////////////////////////////////////////////////////
///////////////////
// Copyright (c) 1995/2004 Xilinx, Inc.
// All Right Reserved.
////////////////////////////////////////////////////////////
///////////////////
//   ____  ____
//  /   /\/   /
// /___/  \  /    Vendor : Xilinx
// \   \   \/     Version : 10.1
//  \   \         Description : Xilinx Functional Simulation Library
Component
//  /   /                  6-input Look-Up-Table with General Output
// /___/   /\     Filename : LUT6.v
// \   \  /  \    Timestamp : Thu Mar 25 16:42:54 PST 2004
//  \___\/\___\
//
// Revision:
//    03/23/04 - Initial version.
//    02/04/05 - Replace premitive with function; Remove buf.
//    05/30/07 - Change timescale to 1 ps / 1ps.
// End Revision

`timescale  1 ps / 1 ps

module LUT6 (O, I0, I1, I2, I3, I4, I5);

  parameter INIT = 64'h0000000000000000;

  input I0, I1, I2, I3, I4, I5;

  output O;

  reg O;
  reg tmp;

  always @( I5 or I4 or I3 or  I2 or  I1 or  I0 )  begin

    tmp =  I0 ^ I1  ^ I2 ^ I3 ^ I4 ^ I5;

    if ( tmp == 0 || tmp == 1)

        O = INIT[{I5, I4, I3, I2, I1, I0}];

    else

      O =  lut6_mux8 ( {lut6_mux8 ( INIT[63:56], {I2, I1, I0}),
                          lut6_mux8 ( INIT[55:48], {I2, I1, I0}),
                          lut6_mux8 ( INIT[47:40], {I2, I1, I0}),
                          lut6_mux8 ( INIT[39:32], {I2, I1, I0}),
                          lut6_mux8 ( INIT[31:24], {I2, I1, I0}),
                          lut6_mux8 ( INIT[23:16], {I2, I1, I0}),
                          lut6_mux8 ( INIT[15:8], {I2, I1, I0}),
                          lut6_mux8 ( INIT[7:0], {I2, I1, I0}) }, {I5, I4,
I3});
  end

  function lut6_mux8;
  input [7:0] d;
  input [2:0] s;

  begin

   if ((s[2]^s[1]^s[0] ==1) || (s[2]^s[1]^s[0] ==0))

       lut6_mux8 = d[s];

     else
       if ( ~(|d))
             lut6_mux8 = 1'b0;
       else if ((&d))
             lut6_mux8 = 1'b1;
       else if (((s[1]^s[0] ==1'b1) || (s[1]^s[0] ==1'b0)) &&
(d[{1'b0,s[1:0]}]==d[{1'b1,s[1:0]}]))
             lut6_mux8 = d[{1'b0,s[1:0]}];
       else if (((s[2]^s[0] ==1) || (s[2]^s[0] ==0)) &&
(d[{s[2],1'b0,s[0]}]==d[{s[2],1'b1,s[0]}]))
             lut6_mux8 = d[{s[2],1'b0,s[0]}];
       else if (((s[2]^s[1] ==1) || (s[2]^s[1] ==0)) &&
(d[{s[2],s[1],1'b0}]==d[{s[2],s[1],1'b1}]))
             lut6_mux8 = d[{s[2],s[1],1'b0}];
       else if (((s[0] ==1) || (s[0] ==0)) &&
(d[{1'b0,1'b0,s[0]}]==d[{1'b0,1'b1,s[0]}])
&&
          (d[{1'b0,1'b0,s[0]}]==d[{1'b1,1'b0,s[0]}]) &&
(d[{1'b0,1'b0,s[0]}]==d[{1'b1,1'b1,s[0]}]))
             lut6_mux8 = d[{1'b0,1'b0,s[0]}];
       else if (((s[1] ==1) || (s[1] ==0)) &&
(d[{1'b0,s[1],1'b0}]==d[{1'b0,s[1],1'b1}])
&&
          (d[{1'b0,s[1],1'b0}]==d[{1'b1,s[1],1'b0}]) &&
(d[{1'b0,s[1],1'b0}]==d[{1'b1,s[1],1'b1}]))
             lut6_mux8 = d[{1'b0,s[1],1'b0}];
       else if (((s[2] ==1) || (s[2] ==0)) &&
(d[{s[2],1'b0,1'b0}]==d[{s[2],1'b0,1'b1}])
&&
          (d[{s[2],1'b0,1'b0}]==d[{s[2],1'b1,1'b0}]) &&
(d[{s[2],1'b0,1'b0}]==d[{s[2],1'b1,1'b1}]))
             lut6_mux8 = d[{s[2],1'b0,1'b0}];
       else
             lut6_mux8 = 1'bx;
   end
  endfunction

endmodule

module tb;

    reg [5:0] num = 0;
    reg res;

    integer i;

    initial begin
        $dumpfile("test.vcd");
        $dumpvars(0,tb);

        num = 6'b000000;
        # 1;
        $display("num: %b, out: %h",num,res);

        num = 6'bx00000;
        # 1;
        $display("num: %b, out: %h",num,res);

        num = 6'bxx0000;
        # 1;
        $display("num: %b, out: %h",num,res);

        num = 6'bxxx000;
        # 1;
        $display("num: %b, out: %h",num,res);

        num = 6'bxxxx00;
        # 1;
        $display("num: %b, out: %h",num,res);

        num = 6'bxxxxx0;
        # 1;
        $display("num: %b, out: %h",num,res);

        num = 6'bxxxxxx;
        # 1;
        $display("num: %b, out: %h",num,res);

        # 2 $finish;
    end

    LUT6 dut(
        .O(res),
        .I0(num[0]),
        .I1(num[1]),
        .I2(num[2]),
        .I3(num[3]),
        .I4(num[4]),
        .I5(num[5])
    );
    defparam dut.INIT = 64'h8000000000000000;

endmodule

Icarus supports this as stated in the following comment which seems wrong:

"The "//" style comments go to the end of the line and terminate the definition"

The standard states that a single line comment "//...." should be ignored in a macro definition.
>From 1800-2012  page 640 "If a one-line comment (that is, a comment specified with the characters //) is included in the text, then the comment shall not become part of the substituted text."
Given how single line comments work it seems like any line continuation character would become part of the comment so it would seem prudent to assume that a single line comment in a macro definition would effectively be replaced in its entirety by "\" to continue the macro. The only place doing this that could create confusion is if the comment was on the last line of the macro where you could get an extra unexpected line, but most people would put a empty line after a macro definition so this may often go unnoticed.
I would expect the following code to compile correctly:
module top;

logic [1:0] out;
logic in, clk, rst;

`define macro_with_comment(q,d,clk,rst)  \
// Make the internal stage the same size as the output.
logic [$bits(q)-1:0] \q``_staged ; \
// logic [$bits(d)-1:0] \q``_staged ; \
  // Does a space before work?
always @(posedge clk or posedge rst) begin  \
  if (rst) \q``_staged <= '0;  // Reset the first stage. \
  else \q``_staged <= d;  \
end  \
always @(posedge clk or posedge rst) begin  \
  if (rst) q <= '0;  \
  else q <= \q``_staged ;  \
end  // The next line is part of the macro!

`macro_with_comment(out[0], in, clk, rst)

initial $display("PASSED");
endmodule
And more specifically I would expect a single line comment to be ignored no matter the space before it or even if there are actual Verilog commands before it, but not terminate the macro otherwise what is the use of the comment? I agree the standard should state explicitly if the single line comment terminates or continues the macro, but I could not find it if it does.

Could this get tested on various simulators to see what they do and I will try to update Icarus to match the consensus of the simulators or what we agree is best.
Cary

As I remember the issues are in the vlog95 code generator and more specifically each generate scope needs to be emitted as a new module to preserve the scope aspects of the generate block (probably not too hard) and then the instantiation and interface needs to be done in a sane manner (a bit harder). At the moment most of the generate code just gets dropped into the parent scope since the emitting code doesn't understand generate scopes. As I remember it also has similar issues with certain instantiations of actual modules, though it often produces code that works it just doesn't pass arguments exactly as you would expect.
I don't think there are fundamental issues preventing this from being implemented and doing so may actually improve the converter in other aspects. If/when I get some free time I will try to look at this again.
Cary

    On Monday, March 20, 2017 4:51 PM, Stephen Williams <st...@ic...> wrote:

 Generate elaborate DOES happen in the target-independent elaboration
phase, so the only thing about generate that the target sees is the
fully elaborate generate scope. For example, a generate-loop may
create N scopes. But the target does not have to understand anything
about generate, only that there is a named scope there.

On Sun, Mar 19, 2017 at 11:17 PM, Niels Möller <ni...@ly...> wrote:

"Cary R." <cy...@ya...> writes:

> The vlog95 target is currently the only mostly functional Verilog
> target and as the author of it I had intended to support the generate
> constructs. The problem is life, a new job etc. got in the way and I
> never have gotten around to finishing it.

Thanks for the info, and for your work on iverilog. I fully understand
that priorities change.

About generate, I was a bit surprised, I would (naively?) have expected
generate to be implemented in some target-independent elaboration phase.
But I guess there may be some target-specific processing too, like
producing valid and unique names for variables defined inside a generate
block.

Best regards,
/Niels

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

------------------------------ ------------------------------ ------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
______________________________ _________________
Iverilog-devel mailing list
Iverilog-devel@lists. sourceforge.net
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."------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Generate elaborate DOES happen in the target-independent elaboration
phase, so the only thing about generate that the target sees is the
fully elaborate generate scope. For example, a generate-loop may
create N scopes. But the target does not have to understand anything
about generate, only that there is a named scope there.

On Sun, Mar 19, 2017 at 11:17 PM, Niels Möller <ni...@ly...> wrote:

> "Cary R." <cy...@ya...> writes:
>
> > The vlog95 target is currently the only mostly functional Verilog
> > target and as the author of it I had intended to support the generate
> > constructs. The problem is life, a new job etc. got in the way and I
> > never have gotten around to finishing it.
>
> Thanks for the info, and for your work on iverilog. I fully understand
> that priorities change.
>
> About generate, I was a bit surprised, I would (naively?) have expected
> generate to be implemented in some target-independent elaboration phase.
> But I guess there may be some target-specific processing too, like
> producing valid and unique names for variables defined inside a generate
> block.
>
> Best regards,
> /Niels
>
> --
> Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
> Internet email is subject to wholesale government surveillance.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic... <ste...@gm...>              But I have promises
to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

"Cary R." <cy...@ya...> writes:

> The vlog95 target is currently the only mostly functional Verilog
> target and as the author of it I had intended to support the generate
> constructs. The problem is life, a new job etc. got in the way and I
> never have gotten around to finishing it.

Thanks for the info, and for your work on iverilog. I fully understand
that priorities change.

About generate, I was a bit surprised, I would (naively?) have expected
generate to be implemented in some target-independent elaboration phase.
But I guess there may be some target-specific processing too, like
producing valid and unique names for variables defined inside a generate
block.

Best regards,
/Niels

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

Hi Cary,

Thank you very much for getting back to me on this question. I really
appreciate it.

Best regards,
Patrick

On Mar 15, 2017 07:11, "Cary R." <cy...@ya...> wrote:

> I did a lot of work on the SDF support a number of years ago. I added what
> I could and then tried to make it ignore anything Icarus couldn't support.
>
> Interconnect delays are not supported by the run time and there is no
> other construct we can use to support them.
>
> It has been a while so I don't remember exactly what part of the COND was
> not supported (I think it was matching the condition expression in the SDF
> to the internal expression), but if it was not a major effort I'm sure I
> would have added support for it instead of dropping it with a warning.
>
> Icarus is a good RTL simulator, but not a very good gate level simulator.
> If you need to run gate level simulations with a SDF file then you are
> going to need something else. Also realize that most gate level simulations
> need to have the timing checks working correctly and these are also
> currently not supported by Icarus.
>
> Cary
>
>
> On Wednesday, February 1, 2017 1:17 PM, Patrick <pat...@gm...>
> wrote:
>
>
>
> Hi developers,
>
> First of all thank you for your great efforts in developing icarus verilog!
>
> I would like to use icarus verilog to run a back annotated simulation
> (using an SDF file).
>
> At first I had some problems getting the simulation to run and I got the
> following errors:
> SDF ERROR: Too many errors: syntax error
> 1:SDF ERROR: Invalid DELAYFILE format
> This was caused by the file-format of the SDF file. Running the dos2unix
> command on the SDF file solved this problem.
>
> The simulation is now running, but I am getting a lot of warnings (~42k).
> Most notably of the form:
> - SDF WARNING: INTERCONNECT not supported.
> - SDF WARNING: COND not supported.
>
> My questions are:
> 1) Are there any plans for supporting these SDF constructs in the future?
> 2) Would it be possible to use a work-around (for instance by replacing
> INTERCONNECT with something else that is supported)?
>
> Thanks and best regards,
> Patrick
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>

I did a lot of work on the SDF support a number of years ago. I added what I could and then tried to make it ignore anything Icarus couldn't support.
Interconnect delays are not supported by the run time and there is no other construct we can use to support them.
It has been a while so I don't remember exactly what part of the COND was not supported (I think it was matching the condition expression in the SDF to the internal expression), but if it was not a major effort I'm sure I would have added support for it instead of dropping it with a warning.
Icarus is a good RTL simulator, but not a very good gate level simulator. If you need to run gate level simulations with a SDF file then you are going to need something else. Also realize that most gate level simulations need to have the timing checks working correctly and these are also currently not supported by Icarus.

Cary

    On Wednesday, February 1, 2017 1:17 PM, Patrick <pat...@gm...> wrote:

Hi developers,

First of all thank you for your great efforts in developing icarus verilog!

I would like to use icarus verilog to run a back annotated simulation (using an SDF file).

At first I had some problems getting the simulation to run and I got the following errors:
SDF ERROR: Too many errors: syntax error
1:SDF ERROR: Invalid DELAYFILE format
This was caused by the file-format of the SDF file. Running the dos2unix command on the SDF file solved this problem.

The simulation is now running, but I am getting a lot of warnings (~42k). Most notably of the form:
- SDF WARNING: INTERCONNECT not supported.
- SDF WARNING: COND not supported.

My questions are:
1) Are there any plans for supporting these SDF constructs in the future?
2) Would it be possible to use a work-around (for instance by replacing INTERCONNECT with something else that is supported)?

Thanks and best regards,
Patrick

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

The vlog95 target is currently the only mostly functional Verilog target and as the author of it I had intended to support the generate constructs. The problem is life, a new job etc. got in the way and I never have gotten around to finishing it. What you likely want is a Verilog target that can support different versions. I used 95 with the option to support signed because that was the base that many other tools would support. I also had a bit of a business need for it when I first started working on it. Making a target that supports different Verilog version is currently left as an exercise for the user. Much of the hard work has been done in the vlog95 target, though there are still a few places where the Icarus compiler mangles the original information too much to adequately decipher what was originally provided.
The VHDL target has not been touched or enhanced in a long time.

Cary 

    On Wednesday, February 22, 2017 1:41 PM, Niels Möller <ni...@ly...> wrote:

 Hi,

following advice on this list, I'm using yosys when I want to experiment
with synthesis. However, some of the modules in my design use system
verilog features, in particular, typedef struct packed { ... }, which
aren't supported by yosys.

I thought that was no problem, because I've read somewhere that icarus
verilog does have a verilog target which can be used as a system verilog
to verilog translator. But I'm having some trouble using it. The
"verilog" target seems to be disabled unless I edit the Makefile (it's
listed in NOTUSED rather than SUBDIRS), and I imagine there's some good
reason for that.

I then tried the vlog95 target, which is built by default. But that
doesn't support generate, which is a show stopper for me.

Finally I tried the vhdl output target (I think yosys supports vhdl
input, but I haven't tried it), but it seems to either be very slow or
not terminating. When I attach gdb after a few minutes, it's in the function
draw_all_signals and apparently never returning,

  1017          while (ivl_scope_type(parent) == IVL_SCT_GENERATE)
  Value returned is $1 = (ivl_scope_s *) 0x7f7299ee1df0
  (gdb) fin
  Run till exit from #0  draw_all_signals (scope=0x7f7299eddb00) at scope.cc:1017

and there it hangs.

I've just updated my iverilog checkout and recompiled, and it seems to
behave the same way with the latest version.

So is it possible to use Icarus Verilog as a translator from its
supported System Verilog subset to plain Verilog? Or is there some other
free software tool that can do that?

If not, I'll just have to reorganize my code a bit to avoid any System
Verilog features which aren't supported by *both* Icarus and yosys.

Best regards,
/Niels

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Hi,

following advice on this list, I'm using yosys when I want to experiment
with synthesis. However, some of the modules in my design use system
verilog features, in particular, typedef struct packed { ... }, which
aren't supported by yosys.

I thought that was no problem, because I've read somewhere that icarus
verilog does have a verilog target which can be used as a system verilog
to verilog translator. But I'm having some trouble using it. The
"verilog" target seems to be disabled unless I edit the Makefile (it's
listed in NOTUSED rather than SUBDIRS), and I imagine there's some good
reason for that.

I then tried the vlog95 target, which is built by default. But that
doesn't support generate, which is a show stopper for me.

Finally I tried the vhdl output target (I think yosys supports vhdl
input, but I haven't tried it), but it seems to either be very slow or
not terminating. When I attach gdb after a few minutes, it's in the function
draw_all_signals and apparently never returning,

  1017          while (ivl_scope_type(parent) == IVL_SCT_GENERATE)
  Value returned is $1 = (ivl_scope_s *) 0x7f7299ee1df0
  (gdb) fin
  Run till exit from #0  draw_all_signals (scope=0x7f7299eddb00) at scope.cc:1017

and there it hangs.

I've just updated my iverilog checkout and recompiled, and it seems to
behave the same way with the latest version.

So is it possible to use Icarus Verilog as a translator from its
supported System Verilog subset to plain Verilog? Or is there some other
free software tool that can do that?

If not, I'll just have to reorganize my code a bit to avoid any System
Verilog features which aren't supported by *both* Icarus and yosys.

Best regards,
/Niels

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

Using both the latest stable version of iverilog (v10.1) and the version in development (v11), both 
w0 and w1 are driven to 1'bx, which is the correct result.

thec wrote:
> `timescale 1ns/1ns
>
> // in case you did receive two copies with the same content,
> // just delete one.
> // 6/66
>
> module test;
>
>         // Outputs
>         wire w0,w1;
>
>         initial
>         begin
>                 $dumpfile("andx_gate.vcd");
>                 $dumpvars(0,test);
>         end
>
>         initial
>         begin
>                 #100 $finish(2);
>         end
>
> 	//
> 	//6/66 w0 and w1 should have the same results
> 	//
>         assign #1 w0 = 1'b 0 * (1'b 1 - 1'b x);
>         andx    andx0(.x0(1'b 0),.x1(1'b x),.y0(w1));
>
> endmodule
>
>
> module andx(x0,x1,y0);
>
> input x0,x1;
> output y0;
>
>         assign #1 y0 = x0 * (1'b 1 - x1);
>
> endmodule
>
> // have fun
> // 6/66
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

`timescale 1ns/1ns

// in case you did receive two copies with the same content,
// just delete one.
// 6/66

module test;

        // Outputs
        wire w0,w1;

        initial
        begin
                $dumpfile("andx_gate.vcd");
                $dumpvars(0,test);
        end

        initial
        begin
                #100 $finish(2);
        end

	//
	//6/66 w0 and w1 should have the same results
	//
        assign #1 w0 = 1'b 0 * (1'b 1 - 1'b x);
        andx    andx0(.x0(1'b 0),.x1(1'b x),.y0(w1));

endmodule

module andx(x0,x1,y0);

input x0,x1;
output y0;

        assign #1 y0 = x0 * (1'b 1 - x1);

endmodule

// have fun
// 6/66

Hi developers,

First of all thank you for your great efforts in developing icarus verilog!

I would like to use icarus verilog to run a back annotated simulation
(using an SDF file).

At first I had some problems getting the simulation to run and I got the
following errors:
SDF ERROR: Too many errors: syntax error
1:SDF ERROR: Invalid DELAYFILE format
This was caused by the file-format of the SDF file. Running the dos2unix
command on the SDF file solved this problem.

The simulation is now running, but I am getting a lot of warnings (~42k).
Most notably of the form:
- SDF WARNING: INTERCONNECT not supported.
- SDF WARNING: COND not supported.

My questions are:
1) Are there any plans for supporting these SDF constructs in the future?
2) Would it be possible to use a work-around (for instance by replacing
INTERCONNECT with something else that is supported)?

Thanks and best regards,
Patrick

Compiling iverilog using gcc-6.2 produces lots of warnings about
auto_ptr being deprecated. It's used in three files, and the following
command replaces them all by unique_ptr.

  git grep -l auto_ptr |xargs sed -i 's/auto_ptr/unique_ptr/'

I just wanted to test if it's this easy, and I think it is. I've
verified that compilation succeeds (with lot less warnings) and make
check succeeds as well. I haven't tried the external testsuite, though.

I'm no real C++ guru, but my understanding is that auto_ptr has a copy
constructor and an assignment operator destroying the source operand,
which is a bit dangerous an counter-intuitive. While unique_ptr only has
a move constructor (a relatively new C++ feature) and no copy
constructor or assignment. Instead, attempts to copy result in compile time
errors, except when the compiler can infer a move, e.g., when returning
a unique_ptr.

That simple substitution seemed to work means that iverilog doesn't do
any dangerous copying of its auto_ptrs.

Regards,
/Niels

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

Hi,
I have been trying to build OpenSPARCT1 project using icarus verilog. I am having a challenge using the PLI libraries that come with it. I am calling these libraries using " -mcadpli"  and '-cadpli=libveriuser_nc.so:my_boot" where libveriuser_nc.so implements the my_boot routine that returns a p_tfcell object.The vvp run fails and gives the following error messages:
status.log:Diag: sushmak1a:bypass_win:model_core1:core1_mini:0:5185   FAIL (Monitor)Tue Dec 20 16:47:55 IST 2016sim.log: veriusertfs: $l2_error_enjection, forcing forwref = truesim.log: veriusertfs: $bw_fail, forcing forwref = truesim.log: veriusertfs: $error, forcing forwref = truesim.log: veriusertfs: $monErrorDisable, forcing forwref = truesim.log: veriusertfs: $monErrorEnable, forcing forwref = truesim.log: vvp: symbol lookup error: /home/sushmak1a/OpenSPARC/tools/Linux/x86_64/lib/libmem_pli_ncv.so: undefined symbol: tf_propagatep

sim.log:    make_value_change: sorry: I cannot callback values on type code=56

 veriuser.h provided by icarus verilog does not define tf_propagatep (and some other routines). 
1) Do I assume that icarus verilog currently does not implement a subset of the PLI 1.0 interface ?
2) Hence, would it be possible for me to compile and run OpenSPARCT1 using icarus verilog ?
3) If not, has anybody successfully compiled OpenSPARCT1 with a open source verilog simulator (non-vcs/non-nc verilog); any pointers in that direction will be appreciated.
Thanks,Sushma.
Dear all,

The call for participation in the FOSDEM 2017 EDA devroom is open:

http://www.ohwr.org/projects/ohr-meta/wiki/FOSDEM2017

Feel free to submit proposals for a talk, tutorial or demo, and to pass
this on to anybody you think could be interested.

Cheers,

Javier

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

> As Yuri has suggested, take a look at Yosys - it's a much better tool
> for what you are trying to do.

I've now installed yosys, and done some initial tests with the example
synthesis script in the README.

Do you know if there's an easy way to get a summary of gate count from
yosys, similar to iverilog -t sizer? Or would I have to write out the
net list (in one of the several supported formats) and postprocess that?

Hmm, maybe it could work to let yosys do the synthesis, write out the
resulting net list in verilog format, and then feed that to iverilog -t
sizer?

Ideally, I'd like to get a break down by module, like iverilog -t sizer
does (even if I understand there are no sharp boundaries between modules
after synthesis). And it would also be nice to get the maximum gate
delay between flip flops.

Best regards,
/Niels

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

Also note that iverilog comes up with the correct answer if all the
assignments are in the same always block:

module test

  (input [3:0] in,

   output reg [1:0] out);

  always @*

    begin

      out = { in[0]^in[2], in[1]^in[3] };

    end

endmodule

**** module/scope: test

     Flip-Flops   : 0

     Logic Gates  : 2

**** TOTALS

     Flip-Flops   : 0

     Logic Gates  : 2

On Wed, Nov 9, 2016 at 12:53 AM, Martin Whitaker <
mai...@ma...> wrote:

> Yuri Gribov wrote:
> > On Wed, Nov 9, 2016 at 8:35 AM, Niels Möller <ni...@ly...>
> wrote:
> >> Yuri Gribov <tet...@gm...> writes:
> >>
> >>> Also keep in mind that BLIF backend has been long abandoned so if you
> >>> are really interested in synthesis you may want to try other OSS
> >>> toolchains (namely Yosys).
> >>
> >> I don't plan to do real synthesis with iverilog, but I'd like to use the
> >> sizer target to get approximate gate count for my circuits and
> >> their parts.
> >
> > Be sure to run BLIF through ABC as Icarus generates suboptimal netlists.
>
> I was just about to say the same thing. iverilog does *no* optimisation of
> synthesised netlists, so
> the sizer output will grossly exaggerate the gate count.
>
> As Yuri has suggested, take a look at Yosys - it's a much better tool for
> what you are trying to do.
>
> Martin
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Yuri Gribov wrote:
> On Wed, Nov 9, 2016 at 8:35 AM, Niels Möller <ni...@ly...> wrote:
>> Yuri Gribov <tet...@gm...> writes:
>>
>>> Also keep in mind that BLIF backend has been long abandoned so if you
>>> are really interested in synthesis you may want to try other OSS
>>> toolchains (namely Yosys).
>>
>> I don't plan to do real synthesis with iverilog, but I'd like to use the
>> sizer target to get approximate gate count for my circuits and
>> their parts.
>
> Be sure to run BLIF through ABC as Icarus generates suboptimal netlists.

I was just about to say the same thing. iverilog does *no* optimisation of synthesised netlists, so 
the sizer output will grossly exaggerate the gate count.

As Yuri has suggested, take a look at Yosys - it's a much better tool for what you are trying to do.

Martin

Niels Möller wrote:
> Hi,
>
> here's a case where I'm not sure if I'm confused, or if iverilog is...
> Consider the following input (it could easily be simplified to avoid the
> problem, but it exhibits a problem present in my real, more complicated,
> code, which uses generate to produce code where each instance assigns to
> one piece of a variable):
>
>   module with_assign (input [3:0] in, output [1:0] out);
>      assign out[0] = in[0] ^ in[2];
>      assign out[1] = in[1] ^ in[3];
>   endmodule
>
>   // Note must use "reg" output, or assignments are invalid.
>   module with_always (input [3:0] in, output reg [1:0] out);
>      always @(*)
>        out[0] = in[0] ^ in[2];
>      always @(*)
>        out[1] = in[1] ^ in[3];
>   endmodule
>
> Until yesterday, I thought these were equivalent. The code passes
> iverilog -Wall without complaints. But when I try synthesize using
> iverilog -t sizer, the second module fails, with errors and warnings:
>
>   test.vl:10: warning: A latch has been inferred for some bits of 'out'.
>   test.vl:10: sorry: Bit-level latch gate enables are not currently
>   supported in synthesis.
>   test.vl:10: error: Unable to synthesize asynchronous process.
>   test.vl:8: warning: A latch has been inferred for some bits of 'out'.
>   test.vl:8: sorry: Bit-level latch gate enables are not currently
>   supported in synthesis.
>   test.vl:8: error: Unable to synthesize asynchronous process.
>   4 error(s) in post-elaboration processing.
>
> My interpretation of that is that if I want an always block to be
> combinatorial, and I assign one bit in a variable (above, "out"), I have
> to assign all bits of the variable. Is it supposed to work that way?

Yes, your two pieces of code are equivalent. The problem is twofold:

1) For each 'always' process, iverilog calculates an output sensitivity list, i.e. a list of 
variables that are written to by that process. The granularity of this list is nets/variables,
not bits. This is all that is needed for simulation, which just needs to determine the update events 
for the statement.

2) The synthesis option in iverilog is very primitive. It considers each 'always' process in 
isolation. It uses the output sensitivity list to find variables that are written to, then checks if 
all bits of the variable are written by all branches within the process. If not, it infers a latch.

For this case, the solution is to put your two assignments in the same always statement, i.e.

module with_always (input [3:0] in, output reg [1:0] out);
always @(*) begin
   out[0] = in[0] ^ in[2];
   out[1] = in[1] ^ in[3];
end
endmodule

Currently there are no plans to improve synthesis support in iverilog. I fix bugs when they are 
reported, but if it either generates correctly behaving code or tells you it can't, that's where I 
stop. Turning it into a useful synthesis tool would be a major piece of work, and we still have a 
lot to do on the simulation side.

Martin

On Wed, Nov 9, 2016 at 8:35 AM, Niels Möller <ni...@ly...> wrote:
> Yuri Gribov <tet...@gm...> writes:
>
>> Also keep in mind that BLIF backend has been long abandoned so if you
>> are really interested in synthesis you may want to try other OSS
>> toolchains (namely Yosys).
>
> I don't plan to do real synthesis with iverilog, but I'd like to use the
> sizer target to get approximate gate count for my circuits and
> their parts.

Be sure to run BLIF through ABC as Icarus generates suboptimal netlists.

> I'm aware of Yosys, but I haven't tried it yet.
>
> Regards,
> /Niels
>
> --
> Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
> Internet email is subject to wholesale government surveillance.

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

iverilog-devel — Conversations on matters of Icarus Verilog development