iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] VHDL compile errors

[David F. <da...@ch...>]

Hi Orson,

Ok. I discussed with my coworker.
He says ghdl can be used by iverilog.
He installed it and we were able to run through the regressions which showed vhdl support.

However, when I compile the type_utils.vhd which uses 

std_ulogic_vector

the compiler complains that this type name cannot be found.
To me it means not supported.
When I grep the ivtest/ivltests/*.vhd there are no tests for std_ulogic_vector.

Please confirm that std_ulogic, std_ulogic_vector is NOT supported.

Thanks,

David


-----Original Message-----
From: Maciej Sumiński <mac...@ce...> 
Sent: Tuesday, July 3, 2018 11:56 PM
To: ive...@li...
Subject: Re: [Iverilog-devel] VHDL compile errors

Hi David,

VHDL support in Icarus is very limited and currently is done by compiling VHDL files to SystemVerilog. We have learnt that even though a significant part of the VHDL standard could be covered, most likely we will not be able to implement a complete VHDL simulator this way. Due to that, the concept has been abandoned and IIRC nobody works on VHDL frontend in Icarus right now.

It would be much better to join a dedicated (System)Verilog simulator (e.g. Icarus) and a dedicated VHDL simulator (e.g. ghdl) and exchange data between them, but I think nobody volunteered to do that either.

Regards,
Orson

On 07/02/2018 08:34 PM, David Fong wrote:
> Hi,
> 
> I'm trying to compile a VHDL package file and I'm getting these errors
> 
> ../commonlib/types_common.vhd:63: syntax error
> ../commonlib/types_common.vhd:63: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:64: syntax error
> ../commonlib/types_common.vhd:64: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:67: syntax error
> ../commonlib/types_common.vhd:67: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:67: syntax error
> ../commonlib/types_common.vhd:67: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:68: syntax error
> ../commonlib/types_common.vhd:68: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:69: syntax error
> ../commonlib/types_common.vhd:69: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:69: syntax error
> ../commonlib/types_common.vhd:69: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:70: syntax error
> ../commonlib/types_common.vhd:70: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:71: syntax error
> ../commonlib/types_common.vhd:71: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:71: syntax error
> ../commonlib/types_common.vhd:71: error: Syntax error in package declarative item.
> 
> 63 function "-"
> 64 (i : integer; d : std_logic_vector)
> 65 return std_logic_vector;
> 66
>  67 function "-" (d : std_logic_vector; i : integer) return 
> std_logic_vector;
> 68 function "-" (a, b : std_logic_vector) return std_logic_vector;
> 69 function "+" (d : std_logic_vector; i : integer) return 
> std_logic_vector;
> 70 function "+" (a, b : std_logic_vector) return std_logic_vector;
> 71 function "+" (d : std_logic_vector; i : std_logic) return 
> std_logic_vector;
> 
> Looks like iverilog cannot handle overloaded functions or the string named function "-"  or "+"
> 
> David
> 
> 
> 
> 
> ----------------------------------------------------------------------
> -------- 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
> 

Re: [Iverilog-devel] VHDL compile errors

[Maciej S. <mac...@ce...>]

Hi David,

VHDL support in Icarus is very limited and currently is done by
compiling VHDL files to SystemVerilog. We have learnt that even though a
significant part of the VHDL standard could be covered, most likely we
will not be able to implement a complete VHDL simulator this way. Due to
that, the concept has been abandoned and IIRC nobody works on VHDL
frontend in Icarus right now.

It would be much better to join a dedicated (System)Verilog simulator
(e.g. Icarus) and a dedicated VHDL simulator (e.g. ghdl) and exchange
data between them, but I think nobody volunteered to do that either.

Regards,
Orson

On 07/02/2018 08:34 PM, David Fong wrote:
> Hi,
> 
> I'm trying to compile a VHDL package file and I'm getting these errors
> 
> ../commonlib/types_common.vhd:63: syntax error
> ../commonlib/types_common.vhd:63: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:64: syntax error
> ../commonlib/types_common.vhd:64: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:67: syntax error
> ../commonlib/types_common.vhd:67: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:67: syntax error
> ../commonlib/types_common.vhd:67: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:68: syntax error
> ../commonlib/types_common.vhd:68: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:69: syntax error
> ../commonlib/types_common.vhd:69: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:69: syntax error
> ../commonlib/types_common.vhd:69: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:70: syntax error
> ../commonlib/types_common.vhd:70: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:71: syntax error
> ../commonlib/types_common.vhd:71: error: Syntax error in package declarative item.
> ../commonlib/types_common.vhd:71: syntax error
> ../commonlib/types_common.vhd:71: error: Syntax error in package declarative item.
> 
> 63 function "-"
> 64 (i : integer; d : std_logic_vector)
> 65 return std_logic_vector;
> 66
>  67 function "-" (d : std_logic_vector; i : integer) return std_logic_vector;
> 68 function "-" (a, b : std_logic_vector) return std_logic_vector;
> 69 function "+" (d : std_logic_vector; i : integer) return std_logic_vector;
> 70 function "+" (a, b : std_logic_vector) return std_logic_vector;
> 71 function "+" (d : std_logic_vector; i : std_logic) return std_logic_vector;
> 
> Looks like iverilog cannot handle overloaded functions or the string named function "-"  or "+"
> 
> David
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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
> 

[Iverilog-devel] VHDL compilation error due to "length" attribute, "line" type and "unary" and "loop"

[David F. <da...@ch...>]

Hi,

I got some more VHDL compilation errors when I comment out lines in types_util.vhd

Please confirm if these are not able to compile with current iverilog

Thanks,

David

./types_util.vhd:124: syntax error

./types_util.vhd:152: error: Can't find type name `line'
./types_util.vhd:157: sorry: Unary expression +- not supported.
./types_util.vhd:162: syntax error
./types_util.vhd:162: error: Syntax error in sequential statement.
./types_util.vhd:157: sorry: Loop statements are not supported.

123   function tost(v:std_logic_vector) return string is
124     constant vlen : natural := v'length;


151   function tost(i : integer) return string is
152     variable L : line;
153     variable s, x : string(1 to 128);
154     variable n, tmp : integer := 0;
155   begin
156     tmp := i;
157     if i < 0 then tmp := -i; end if;
158     loop
159       s(128-n) := todec(tmp mod 10);
160       tmp := tmp / 10;
161       n := n+1;
162       if tmp = 0 then exit; end if;
163     end loop;
164     x(1 to n) := s(129-n to 128);
165     if i < 0 then return "-" & x(1 to n); end if;
166     return(x(1 to n));
167   end;
168

[Iverilog-devel] VHDL compile errors

[David F. <da...@ch...>]

Hi,

I'm trying to compile a VHDL package file and I'm getting these errors

../commonlib/types_common.vhd:63: syntax error
../commonlib/types_common.vhd:63: error: Syntax error in package declarative item.
../commonlib/types_common.vhd:64: syntax error
../commonlib/types_common.vhd:64: error: Syntax error in package declarative item.
../commonlib/types_common.vhd:67: syntax error
../commonlib/types_common.vhd:67: error: Syntax error in package declarative item.
../commonlib/types_common.vhd:67: syntax error
../commonlib/types_common.vhd:67: error: Syntax error in package declarative item.
../commonlib/types_common.vhd:68: syntax error
../commonlib/types_common.vhd:68: error: Syntax error in package declarative item.
../commonlib/types_common.vhd:69: syntax error
../commonlib/types_common.vhd:69: error: Syntax error in package declarative item.
../commonlib/types_common.vhd:69: syntax error
../commonlib/types_common.vhd:69: error: Syntax error in package declarative item.
../commonlib/types_common.vhd:70: syntax error
../commonlib/types_common.vhd:70: error: Syntax error in package declarative item.
../commonlib/types_common.vhd:71: syntax error
../commonlib/types_common.vhd:71: error: Syntax error in package declarative item.
../commonlib/types_common.vhd:71: syntax error
../commonlib/types_common.vhd:71: error: Syntax error in package declarative item.

63 function "-"
64 (i : integer; d : std_logic_vector)
65 return std_logic_vector;
66
 67 function "-" (d : std_logic_vector; i : integer) return std_logic_vector;
68 function "-" (a, b : std_logic_vector) return std_logic_vector;
69 function "+" (d : std_logic_vector; i : integer) return std_logic_vector;
70 function "+" (a, b : std_logic_vector) return std_logic_vector;
71 function "+" (d : std_logic_vector; i : std_logic) return std_logic_vector;

Looks like iverilog cannot handle overloaded functions or the string named function "-"  or "+"

David

[Iverilog-devel] VHDL function overloading

[David F. <da...@ch...>]

Hi,

Does iverilog support VHDL function overloading such as this simple type conversion ?

For example, below there are three same named functions but with different inputs.

function tost(v:std_logic_vector) return string is
. . .

function tost(v:std_logic) return string is
. . .

function tost(i: integer) return string is
. . .

Thanks,

David

Re: [Iverilog-devel] Scheduling issue

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

On 02/07/18 16:18, Evan Lavelle wrote:
> On 02/07/2018 13:14, Martin Whitaker wrote:
> 
>> Using 1364-2005 as a reference, section 11.6.3 states:
>>
>> "A blocking assignment statement (see 9.2.1) with a delay computes the
>> right-hand side value using the current values, then causes the
>> executing process to be suspended and scheduled as a future event. If
>> the delay is 0, the process is scheduled as an inactive event for the
>> current time.
>>
>> When the process is returned (or if it returns immediately if no delay
>> is specified), the process performs the assignment to the left-hand side
>> and enables any events based upon the update of the left-hand side. The
>> values at the time the process resumes are used to determine the
>> target(s). Execution may then continue with the next sequential
>> statement or with other active events."
> 
> So your reading of 11.6.3 is that everything is statement-based, and the blocking assignment must be 
> executed before the next statement, which is the event control (@(...)). Since the event control 
> hasn't been executed yet, the process isn't sensitive to the update, so clk stops toggling. That 
> makes sense, of course.

Not everything, no. But statements in the same sequential block must be executed in order - that's 
11.4.1(a). And I think it is reasonable to assume that includes the case of looping from the end to 
the beginning of the block.

> But, at the same time, the actual algorithm in 11.4 isn't statement-based, and the algorithm 
> couldn't run after every statement, or the scheduler wouldn't work - it can only run after suspend 
> points such as delay or event controls (as is the case with VHDL and SystemC). I remember Steven 
> Sharp confirming this in c.l.v, but I don't have a record. In this sense, it seems to me that 11.4 
> conflicts with 11.6.3.

Look at 11.4.2. It states that "statements without time-control constructs in behavioral
blocks do not have to be executed as one event". That implies the converse, that statements with 
time-control constructs (# and @) do have to be executed as one event. But in general, the scheduler 
is free to switch between processes at any time - not just at statement boundaries or at event controls.

> So, if you only ran the algorithm at the next event control, at the *same* simulation time, you'd 
> discover an update event on clk at the *current* sim time, and you might be tempted to re-enable the 
> process (in this case, 'clk' would start toggling), but no simulators I've tried actually do this.  
> Maybe the fix is that processes are only sensitive to future events, and not events in the current 
> time slot?

No, the update event for a blocking assignment is part of that statement and must be executed before 
that statement is considered complete. Evaluation events for any sensitive processes are added to 
the active queue immediately after performing the update (as per the pseudo-code in 11.4). So if the 
process is still executing the last statement, it can't have reached the time control for the next 
statement, so can't be sensitive.

> I think my basic confusion is that 11.4 must be wrong. Some of the algorithm must run between 
> statements, or blocking assignments wouldn't work. Some of it can't run between statements, such as 
> enabling other processes which are sensitive to blocking assignments - this has to wait until a 
> suspend point.

No, I think this is where you are going wrong. The sensitive processes are enabled (by adding them 
to the active queue) at the time the update event is executed. At a suspend point, the scheduler 
just picks an event that's already in the active queue.

Re: [Iverilog-devel] Scheduling issue

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

On 02/07/2018 13:14, Martin Whitaker wrote:

> Using 1364-2005 as a reference, section 11.6.3 states:
>
> "A blocking assignment statement (see 9.2.1) with a delay computes the
> right-hand side value using the current values, then causes the
> executing process to be suspended and scheduled as a future event. If
> the delay is 0, the process is scheduled as an inactive event for the
> current time.
>
> When the process is returned (or if it returns immediately if no delay
> is specified), the process performs the assignment to the left-hand side
> and enables any events based upon the update of the left-hand side. The
> values at the time the process resumes are used to determine the
> target(s). Execution may then continue with the next sequential
> statement or with other active events."

So your reading of 11.6.3 is that everything is statement-based, and the 
blocking assignment must be executed before the next statement, which is 
the event control (@(...)). Since the event control hasn't been executed 
yet, the process isn't sensitive to the update, so clk stops toggling. 
That makes sense, of course.

But, at the same time, the actual algorithm in 11.4 isn't 
statement-based, and the algorithm couldn't run after every statement, 
or the scheduler wouldn't work - it can only run after suspend points 
such as delay or event controls (as is the case with VHDL and SystemC). 
I remember Steven Sharp confirming this in c.l.v, but I don't have a 
record. In this sense, it seems to me that 11.4 conflicts with 11.6.3.

So, if you only ran the algorithm at the next event control, at the 
*same* simulation time, you'd discover an update event on clk at the 
*current* sim time, and you might be tempted to re-enable the process 
(in this case, 'clk' would start toggling), but no simulators I've tried 
actually do this.  Maybe the fix is that processes are only sensitive to 
future events, and not events in the current time slot?

I think my basic confusion is that 11.4 must be wrong. Some of the 
algorithm must run between statements, or blocking assignments wouldn't 
work. Some of it can't run between statements, such as enabling other 
processes which are sensitive to blocking assignments - this has to wait 
until a suspend point.

Re: [Iverilog-devel] Supporting SystemVerilog interfaces in module ports

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

Andrew Clark wrote:
> I'm attempting to append to port_declaration as follows:
> 
> /* FL4SHK code:  attempt to support interfaces as module ports */
>   | attribute_list_opt IDENTIFIER gate_instance
> 	{
> 		perm_string type_name = lex_strings.make($2);
> 		// Need more stuff here
> 		delete[]$2;
> 	}
> 
> 
> The "Need more stuff here" part is what I think I need help with. What kind
> of stuff do you need to do to handle the gate_instance part, and how do you
> use the IDENTIFIER portion as an interface type name?

Use the pform_modules map (in pform.cc) to convert type_name to a Module*. 
Module::is_interface will tell you if it really is an interface (see Module.h).

I don't think you want gate_instance in the module port declaration. It 
should be another IDENTIFIER that is the formal name for the module port. 
You need to add that name, along with the interface reference (Module*), to 
the enclosing module's list of ports (Module::ports). You are going to need 
to make some changes to the compiler's internal classes to let you do that.

[Iverilog-devel] Supporting SystemVerilog interfaces in module ports

[Andrew C. <lav...@gm...>]

For reference, here is a link to the original Github issue issue:
https://github.com/steveicarus/iverilog/issues/200

I'll go ahead and repeat the last code-related message I sent to it here.


I'm attempting to append to port_declaration as follows:

/* FL4SHK code:  attempt to support interfaces as module ports */
 | attribute_list_opt IDENTIFIER gate_instance
	{
		perm_string type_name = lex_strings.make($2);
		// Need more stuff here
		delete[]$2;
	}


The "Need more stuff here" part is what I think I need help with. What kind
of stuff do you need to do to handle the gate_instance part, and how do you
use the IDENTIFIER portion as an interface type name?

[Iverilog-devel] Support for "var" keyword?

[Robert B. <rob...@gm...>]

It appears to be in parse.y, but not referenced.

Here's my input, transparent_latch.sv:

module transparent_latch(
output var q);
endmodule : transparent_latch

And the output:

$ iverilog -g2012 -v -o thing transparent_latch.sv

Icarus Verilog version 11.0 (devel) (s20150603-553-g6c39348)

(snipped copyright message)

translate: /usr/local/lib/ivl/ivlpp  -v -L -F"/tmp/ivrlg2288d4707"
-f"/tmp/ivrlg288d4707" -p"/tmp/ivrli288d4707" | /usr/local/lib/ivl/ivl -v
-C"/tmp/ivrlh288d4707" -C"/usr/local/lib/ivl/vvp.conf" -- -
Icarus Verilog Preprocessor version 11.0 (devel) (s20150603-553-g6c39348)

(snipped copyright message)

/usr/local/lib/ivl/system.sft: Processing System Function Table file.
/usr/local/lib/ivl/vhdl_sys.sft: Processing System Function Table file.
/usr/local/lib/ivl/vhdl_textio.sft: Processing System Function Table file.
/usr/local/lib/ivl/v2005_math.sft: Processing System Function Table file.
/usr/local/lib/ivl/va_math.sft: Processing System Function Table file.
/usr/local/lib/ivl/v2009.sft: Processing System Function Table file.
Using language generation: IEEE1800-2012,no-specify,xtypes,icarus-misc
PARSING INPUT
transparent_latch.sv:2: syntax error
transparent_latch.sv:1: Errors in port declarations.

Replacing "var" with "reg" works. But really, I'd like to use the "new"
syntax.

--Rob

Re: [Iverilog-devel] Simulation in iverilog producing different values when compared to Xilinx simulator

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

$dumpvars is the way to dump changes, but that only shows the final values 
at the end of each time step. I always recommend adding a small delay to 
non-blocking assignments, e.g.

`ifdef DEBUG
`define DLY #0.1
`else
`define DLY
`endif

mem_0[addr_block]<= `DLY mem_write_data[2*`PIXEL_WIDTH-1:0]

which, when DEBUG is defined, moves the changes resulting from a clock edge 
into a different time step, making it easier to see cause and effect in the 
waveform viewer.

You may be able to get more details by single-stepping. Compile your code 
with the -pfileline=1 option, and add a $stop system call to create a 
breakpoint. When vvp executes the $stop, it will drop out to a command 
prompt. Type help to show the available commands.

Sab VS wrote:
> Hi Martin,
> 
> Apprciate the response. I will check the write enable and get back. Is
> there anyway to see what exactly is happening at the timestep level in
> iverilog? Is there some file that I can produce to see how the simulator is
> doing the write?
> 
> On Mon, Apr 23, 2018 at 2:31 PM, Martin Whitaker <
> ic...@ma...> wrote:
> 
>> Sab VS wrote:
>>
>>> Hi,
>>>
>>> I am currently trying to debug a piece of code which is not working
>>> correctly in the iverilog simulator.
>>>
>>> The code shows that the mem_write_data changes every clock cycle.
>>>
>>> However, the mem_0 is not changing. I am writing into mem_0 using the
>>> following
>>>
>>> mem_0[addr_block]<=mem_write_data[2*`PIXEL_WIDTH-1:0]
>>>
>>> In Xilinx I see the expected value. Is this an iverilog problem or am I
>>> doing something wrong?
>>>
>>> I have created a short gist
>>> https://gist.github.com/raiderark/9a857fc48d5ce9bac9bfa5b54acc3e9c .
>>> Please
>>> comment out the unused modules in order to compile.
>>>
>>> Could someone please help me out?
>>>
>>
>> Not easily, no. Your test case fails to compile, due to a missing include
>> file.
>>
>> The chances are that there is a race in your code, leading to different
>> results with different simulators. Check the timing of your memory write
>> enable signal - is it guaranteed to be stable before the clock edge?
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
> 

Re: [Iverilog-devel] Simulation in iverilog producing different values when compared to Xilinx simulator

[Sab VS <sab...@gm...>]

Hi Martin,

Apprciate the response. I will check the write enable and get back. Is
there anyway to see what exactly is happening at the timestep level in
iverilog? Is there some file that I can produce to see how the simulator is
doing the write?

On Mon, Apr 23, 2018 at 2:31 PM, Martin Whitaker <
ic...@ma...> wrote:

> Sab VS wrote:
>
>> Hi,
>>
>> I am currently trying to debug a piece of code which is not working
>> correctly in the iverilog simulator.
>>
>> The code shows that the mem_write_data changes every clock cycle.
>>
>> However, the mem_0 is not changing. I am writing into mem_0 using the
>> following
>>
>> mem_0[addr_block]<=mem_write_data[2*`PIXEL_WIDTH-1:0]
>>
>> In Xilinx I see the expected value. Is this an iverilog problem or am I
>> doing something wrong?
>>
>> I have created a short gist
>> https://gist.github.com/raiderark/9a857fc48d5ce9bac9bfa5b54acc3e9c .
>> Please
>> comment out the unused modules in order to compile.
>>
>> Could someone please help me out?
>>
>
> Not easily, no. Your test case fails to compile, due to a missing include
> file.
>
> The chances are that there is a race in your code, leading to different
> results with different simulators. Check the timing of your memory write
> enable signal - is it guaranteed to be stable before the clock edge?
>
> ------------------------------------------------------------
> ------------------
> 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
>

Re: [Iverilog-devel] Simulation in iverilog producing different values when compared to Xilinx simulator

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

Sab VS wrote:
> Hi,
> 
> I am currently trying to debug a piece of code which is not working
> correctly in the iverilog simulator.
> 
> The code shows that the mem_write_data changes every clock cycle.
> 
> However, the mem_0 is not changing. I am writing into mem_0 using the
> following
> 
> mem_0[addr_block]<=mem_write_data[2*`PIXEL_WIDTH-1:0]
> 
> In Xilinx I see the expected value. Is this an iverilog problem or am I
> doing something wrong?
> 
> I have created a short gist
> https://gist.github.com/raiderark/9a857fc48d5ce9bac9bfa5b54acc3e9c . Please
> comment out the unused modules in order to compile.
> 
> Could someone please help me out?

Not easily, no. Your test case fails to compile, due to a missing include file.

The chances are that there is a race in your code, leading to different 
results with different simulators. Check the timing of your memory write 
enable signal - is it guaranteed to be stable before the clock edge?

[Iverilog-devel] Simulation in iverilog producing different values when compared to Xilinx simulator

[Sab VS <sab...@gm...>]

Hi,

I am currently trying to debug a piece of code which is not working
correctly in the iverilog simulator.

The code shows that the mem_write_data changes every clock cycle.

However, the mem_0 is not changing. I am writing into mem_0 using the
following

mem_0[addr_block]<=mem_write_data[2*`PIXEL_WIDTH-1:0]

In Xilinx I see the expected value. Is this an iverilog problem or am I
doing something wrong?

I have created a short gist
https://gist.github.com/raiderark/9a857fc48d5ce9bac9bfa5b54acc3e9c . Please
comment out the unused modules in order to compile.

Could someone please help me out?

Re: [Iverilog-devel] Problem with always_comb

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

 The real issue is I just reused the routines for @* which as Martin mentioned are word based (per the standard they do not consider a constant select in the sensitivity calculation; even for an array). I don't think it will be too hard to update things to give both the word based behavior for @* and the longest static prefix behavior needed for always_comb/latch. I looked at that some time ago while working on @* fixes before realizing the standard said otherwise.

I am very busy with work right now so it may be a while before I can take a look at fixing this.
Cary

    On Friday, April 6, 2018, 12:07:35 AM PDT, Niels Möller <ni...@ly...> wrote:  
 
 Martin Whitaker <ic...@ma...> writes:

> I think the problem is that you are writing to b0 both inside and
> outside the always_comb statement.

I see. If I move out the assignment to b0[7] (and eliminate the
redundant copy via a0[21]) to a separate always @(*) block, tests pass.

> Icarus's sensitivity calculation
> only operates at the word level, not the bit level, so it doesn't
> detect that you are writing to different bits inside and outside.

Bit select expressions must be compile-time constants, right? So it
shouldn't be too hard to detect this case, when Cary or someone else
gets the time to work on it.

> This is of course a bug, but it's not going to be an easy fix. This is
> why I never tackled implementing always_comb.

Detection should be the first step. But to really fix it, could we split
words automatically? Say we have a register [7:0] x, and an always_comb
block which assigns x[7:4]. Then replace x by two registers x_0 [7:4]
and x_1 [3:0] representing subwords. Then each subword should be assigned
in at most one always_comb, and one could also warn for subwords which
are never assigned.

Might make sense to do this splitting also for other types of processes,
for warning purposes. I'm not sure what's actually valid, but I would
expect that one generally should avoid having multiple processes
assigning the same bit (with exceptions for processes that are triggered
by disjoint events, e.g., one proces running on rising clock edge and
another running on falling clock edge).

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
  

Re: [Iverilog-devel] Problem with always_comb

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

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

> I think the problem is that you are writing to b0 both inside and
> outside the always_comb statement.

I see. If I move out the assignment to b0[7] (and eliminate the
redundant copy via a0[21]) to a separate always @(*) block, tests pass.

> Icarus's sensitivity calculation
> only operates at the word level, not the bit level, so it doesn't
> detect that you are writing to different bits inside and outside.

Bit select expressions must be compile-time constants, right? So it
shouldn't be too hard to detect this case, when Cary or someone else
gets the time to work on it.

> This is of course a bug, but it's not going to be an easy fix. This is
> why I never tackled implementing always_comb.

Detection should be the first step. But to really fix it, could we split
words automatically? Say we have a register [7:0] x, and an always_comb
block which assigns x[7:4]. Then replace x by two registers x_0 [7:4]
and x_1 [3:0] representing subwords. Then each subword should be assigned
in at most one always_comb, and one could also warn for subwords which
are never assigned.

Might make sense to do this splitting also for other types of processes,
for warning purposes. I'm not sure what's actually valid, but I would
expect that one generally should avoid having multiple processes
assigning the same bit (with exceptions for processes that are triggered
by disjoint events, e.g., one proces running on rising clock edge and
another running on falling clock edge).

Regards,
/Niels

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

Re: [Iverilog-devel] Problem with always_comb

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

I think the problem is that you are writing to b0 both inside and outside 
the always_comb statement. Icarus's sensitivity calculation only operates 
at the word level, not the bit level, so it doesn't detect that you are 
writing to different bits inside and outside. It just sees you are writing 
to b0, so removes it from the sensitivity list. It should then have issued 
an error message, but I think that's one of the things Cary said he hadn't 
implemented yet.

This is of course a bug, but it's not going to be an easy fix. This is why 
I never tackled implementing always_comb.

Niels Möller wrote:
> Hi,
> 
> I've tried to use always_comb and always_ff consistently in my code, in
> the hope that it would detect some bugs in my code.
> 
> However, I've found one unexpected change in behavior when replacing an
> "always @(*)" by "always_comb". Consider below program popc-bug.vl
> (population count of a 64-bit value), and note the `ifdef ALWAYS_COMB.
> 
> I compile and run it as follows:
> 
> $ iverilog -g2005-sv -Wall popc-bug.vl && ./a.out
> $ iverilog -g2005-sv -Wall -DALWAYS_COMB popc-bug.vl && ./a.out
> popc fail: in: 0000000000000001, out: 0000000, ref: 0000001
> $
> 
> So when always_comb is used in the last process (the others don't
> matter, it seems), popc(1) produces 0, not 1 like it should. As usual,
> it could well be my code which is incorrect, but as you see, I got no
> warnings or errors from the iverilog compiler.
> 
> Regards,
> /Niels

[Iverilog-devel] Problem with always_comb

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

Hi,

I've tried to use always_comb and always_ff consistently in my code, in
the hope that it would detect some bugs in my code.

However, I've found one unexpected change in behavior when replacing an
"always @(*)" by "always_comb". Consider below program popc-bug.vl
(population count of a 64-bit value), and note the `ifdef ALWAYS_COMB.

I compile and run it as follows:

$ iverilog -g2005-sv -Wall popc-bug.vl && ./a.out 
$ iverilog -g2005-sv -Wall -DALWAYS_COMB popc-bug.vl && ./a.out 
popc fail: in: 0000000000000001, out: 0000000, ref: 0000001
$

So when always_comb is used in the last process (the others don't
matter, it seems), popc(1) produces 0, not 1 like it should. As usual,
it could well be my code which is incorrect, but as you see, I got no
warnings or errors from the iverilog compiler.

Regards,
/Niels

----------------8<---------

/* Copyright (C) 2016  Niels Möller

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

module popc (input [63:0] x, output [6:0] cnt);
   /* Dadda tree, weights:
    *
    *                          64     64
    *                          21F+1
    *                     21   22     43 A
    *                     7F   7F+1
    *                7    14    8     29 B
    *               2F+1  4F+2 2F+H
    *            2   7     9    3     21 C
    *               2F+1  3F    F
    *            4   6     4    1     15 D
    *           F+1 2F    F+1
    *         1  4   3     2    1     11 E
    *           F+1  F     H
    *         2  3   2     1    1      9 F
    *         H  F   H
    *       1 2  2   1     1    1      8 G
    */

   function [1:0] ha (input [1:0] x);
      ha = x[0] + x[1];
   endfunction // ha

   function [1:0] fa (input [2:0] x);
      fa = x[0] + x[1] + x[2];
   endfunction // fa

   reg [21:0] a0;
   reg [20:0] a1;

   reg [7:0]  b0;
   reg [13:0] b1;
   reg [6:0]  b2;

   reg [2:0]  c0;
   reg [8:0]  c1;
   reg [6:0]  c2;
   reg [1:0]  c3;

   reg	      d0;
   reg [3:0]  d1;
   reg [5:0]  d2;
   reg [3:0]  d3;

   reg [1:0]  e1;
   reg [2:0]  e2;
   reg [3:0]  e3;
   reg	      e4;

   reg	      f1;
   reg [1:0]  f2;
   reg [2:0]  f3;
   reg [1:0]  f4;

   reg	      g2;
   reg [1:0]  g3;
   reg [1:0]  g4;
   reg	      g5;

   genvar    i;

   assign cnt[2:0] = {g2, f1, d0};
   assign cnt[6:3] = {g4[0],g3[0]} + {g5, g4[1], g3[1]};

   generate
      for (i = 0; i < 21; i = i + 1)
	always @(*)
	  {a1[i], a0[i]} = fa(x[3*i+2:3*i]);
   endgenerate

   generate
      for (i = 0; i < 7; i = i + 1) always @(*) begin
	 {b1[i], b0[i]} = fa(a0[3*i+2:3*i]);
	 {b2[i], b1[7+i]} = fa(a1[3*i+2:3*i]);
      end
   endgenerate
`ifdef ALWAYS_COMB
   always_comb
`else
   always @(*)
`endif
   begin
      a0[21] = x[63];

      b0[7] = a0[21];

      {c1[0], c0[0]} = fa(b0[2:0]);
      {c1[1], c0[1]} = fa(b0[5:3]);
      {c1[2], c0[2]} = ha(b0[7:6]);

      {c2[0], c1[3]} = fa(b1[2:0]);
      {c2[1], c1[4]} = fa(b1[5:3]);
      {c2[2], c1[5]} = fa(b1[8:6]);
      {c2[3], c1[6]} = fa(b1[11:9]);
      c1[8:7] = b1[13:12];

      {c3[0], c2[4]} = fa(b2[2:0]);
      {c3[1], c2[5]} = fa(b2[5:3]);
      c2[6] = b2[6];

      {d1[0], d0} = fa(c0);

      {d2[0], d1[1]} = fa(c1[2:0]);
      {d2[1], d1[2]} = fa(c1[5:3]);
      {d2[2], d1[3]} = fa(c1[8:6]);

      {d3[0], d2[3]} = fa(c2[2:0]);
      {d3[1], d2[4]} = fa(c2[5:3]);
      d2[5] = c2[6];

      d3[3:2] = c3;

      {e2[0],e1[0]} = fa(d1[2:0]);
      e1[1] = d1[3];

      {e3[0],e2[1]} = fa(d2[2:0]);
      {e3[1],e2[2]} = fa(d2[5:3]);

      {e4, e3[2]} = fa(d3[2:0]);
      e3[3] = d3[3];

      {f2[0], f1} = ha(e1);
      {f3[0], f2[1]} = fa(e2);
      {f4[0], f3[1]} = fa(e3[2:0]);
      f3[2] = e3[3];
      f4[1] = e4;

      {g3[0],g2} = ha(f2);
      {g4[0],g3[1]} = fa(f3);
      {g5,g4[1]} = ha(f4);
   end
endmodule // popc

module main;
   reg [63:0] x;
   wire [6:0] cnt;
   integer    i, j;
   reg [6:0] ref_popc;

   initial
     begin
	for (i = 0; i <= 64; i = i + 1)
	  for (j = i; j <= 64; j = j + 1) begin
	     #((i | j) ? 10 : 0) begin
		if (i == j && i > 0) begin
		   x = {64{1'b1}};
		   ref_popc = 7'd64;
		end
		else begin
		   x = (64'b1 << j) - (64'b1 << i);
		   ref_popc = j - i;
		end
	     end
	     #10 begin
		if (ref_popc !== cnt) begin
		   $display ("popc fail: in: %x, out: %b, ref: %b",
			     x, cnt, ref_popc);
		   $finish_and_return(1);
		end
	     end
	  end // for (j = i; j <= 64; j = j + 1)
     end
   popc test_popc(x, cnt);
endmodule

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

Re: [Iverilog-devel] iverilog crash during vvp

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

Don Haire wrote:
> Test program "test5.v" crashes in "vvp".  Probably from something that I 
> have done, but I have no idea how to debug it.  These are the console 
> messages:
> 
>     $ iverilog -g2005-sv -o compileout test5.v
> 
>     $ vvp compileout -fst
> 
>     unresolved vpi name lookup: v0x9f1ee80_0
>     unresolved vpi name lookup: v0x9f1ebc0_0
>     compile_cleanup: 2 unresolved items
>     vpi error: bad global property: 1
>     vvp: vpi_priv.cc:281: int vpip_get_global(int): Assertion `0' failed.
>     Aborted (core dumped)
> 
> The program is attached.

The fault is triggered by casting a string to a vector and assigning it to 
an array word. You should be able to work round this bug by assigning the 
cast value to a temporary varaible and then assigning the temporary 
variable to the array word.

[Iverilog-devel] iverilog crash during vvp

[Don H. <don...@be...>]

Test program "test5.v" crashes in "vvp".  Probably from something that I 
have done, but I have no idea how to debug it.  These are the console 
messages:

    $ iverilog -g2005-sv -o compileout test5.v

    $ vvp compileout -fst

    unresolved vpi name lookup: v0x9f1ee80_0
    unresolved vpi name lookup: v0x9f1ebc0_0
    compile_cleanup: 2 unresolved items
    vpi error: bad global property: 1
    vvp: vpi_priv.cc:281: int vpip_get_global(int): Assertion `0' failed.
    Aborted (core dumped)

The program is attached.

Don

Re: [Iverilog-devel] Icarus compiler crash

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

Don Haire wrote:
> This was originally sent 2/24/2018 while SourceForge was down:

If SourceForge is down, you can instead submit bug reports on GitHub. 
Whilst it would be better if all the bug reports were in one place, many 
users are submitting reports on GitHub, so one more won't hurt...

...
> -------------------------------------------
> 
> On 2/27/2018, I found the code which incited the crash, lines 48, 74, and 
> 187.  Each of these lines contains an implicit type conversion at an 
> assignment.  Making the conversion explicit removes the crash.  For example,
> 
>     names[i] = temp_str;  // implicit, compiler crashes
> 
>     names[i] = reg  [NAME_MAX_LENGTH*8:1] '(temp_str);  // explicit, 
> compiler does not crash
> 
> Fixing the code is my problem, of course, but I believe that the compiler 
> should not crash when it encounters this.

Quite right!

The IEEE standard isn't particularly clear, but as I read it, an explicit 
cast is required here, so the compiler should output an error message. I've 
patched it locally to do this, both for this case and for other cases where 
an explicit cast is required. Unfortunately this has exposed a case where 
the VHDL preprocessor is generating illegal SystemVerilog. This occurs with 
the br986 test case in the test suite. The generated code is

   module \ibufds #(parameter \diff_term = \false) (
     input wire logic \i[],
     input wire logic \ib,
     output wire logic \o);
     // ivltests/br986.vhd:51
     assign \o  = \i ;
   endmodule

which is assigning a dynamic array to a single bit. The VHDL code that 
produces this is

   entity ibufds is
     generic (
       DIFF_TERM : boolean := FALSE
     );
     port (
       i     : in  std_logic_vector;
       ib    : in  std_logic;
       o     : out std_logic
     );
   end ibufds;

   architecture ibufds_sim of ibufds is
   begin
     o <= i;
   end ibufds_sim;

I'm surprised assigning a std_logic_vector variable to a std_logic variable 
is legal in VHDL. Can someone who knows VHDL confirm this is allowed?

Martin

[Iverilog-devel] Icarus verilog bug report, SourceForge tracker was offline

[Don H. <don...@be...>]

During compile, I get a crash:

    ivl: t-dll-api.cc:669: ivl_signal_s* ivl_expr_signal(ivl_expr_t): Assertion `0' failed.
    Aborted (core dumped)

Command line was:

    iverilog -g2005-sv -o compileout test4.v

The following was extracted from iverilog -V:

    Icarus Verilog version 10.1 (stable) ()

    Icarus Verilog Preprocessor version 10.1 (stable) ()

    Icarus Verilog Parser/Elaborator version 10.1 (stable) ()

    vvp.tgt: Icarus Verilog VVP Code Generator 10.1 (stable) ()

I stripped my original program down to something smaller which still 
crashed.  "test4.v" is the result and it is attached.

This was run on Ubuntu 17.10 on an old laptop, 2G RAM, CPU is:

    AMD Turion(tm) 64 X2 Mobile Technology TL-56

Don

[Iverilog-devel] Icarus compiler crash

[Don H. <don...@be...>]

This was originally sent 2/24/2018 while SourceForge was down:

During compile, I get a compiler crash:

    ivl: t-dll-api.cc:669: ivl_signal_s* ivl_expr_signal(ivl_expr_t): Assertion `0' failed.
    Aborted (core dumped)

Command line was:

    iverilog -g2005-sv -o compileout test4.v

The following was extracted from iverilog -V:

    Icarus Verilog version 10.1 (stable) ()

    Icarus Verilog Preprocessor version 10.1 (stable) ()

    Icarus Verilog Parser/Elaborator version 10.1 (stable) ()

    vvp.tgt: Icarus Verilog VVP Code Generator 10.1 (stable) ()

I stripped my original program down to something smaller which still 
crashed.  "test4.v" is the result and it is attached.

This was run on Ubuntu 17.10 on an old laptop, 2G RAM, CPU is:

    AMD Turion(tm) 64 X2 Mobile Technology TL-56

Don

-------------------------------------------

On 2/27/2018, I found the code which incited the crash, lines 48, 74, 
and 187.  Each of these lines contains an implicit type conversion at an 
assignment.  Making the conversion explicit removes the crash.  For example,

    names[i] = temp_str;  // implicit, compiler crashes

    names[i] = reg  [NAME_MAX_LENGTH*8:1] '(temp_str);  // explicit, compiler does not crash

Fixing the code is my problem, of course, but I believe that the 
compiler should not crash when it encounters this.

Don

Re: [Iverilog-devel] Support for resistive verilog primitives

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

I've added support for rtran switches in development. I've also implemented 
the supply->strong strength reduction for non-resistive switches (including 
nmos/pmos/cmos devices) and backported that fix to v10.

Dan Moore wrote:
> Forwarding an email reply from Cary about this.
> 
> It doesn't appear that the verilog primitive rtran is supported in the
> compiler.  The following is with the latest code available on github:
> 
> 
>> iverilog -V 2> /dev/null | head -n 1
> Icarus Verilog version 11.0 (devel) (s20150603-538-ge7a9662)
> 
> 
>> iverilog rtran_tb.v
> rtran_tb.v:14: tgt-vvp sorry: resistive switch modeling is not currently
> supported.
> error: Code generation had 1 error(s).
> 
> 
> Dan
> 
> 
> 
> 
> 
> ---------- Forwarded message ----------
> From: Cary R. <cy...@ya...>
> Date: Sun, Feb 11, 2018 at 6:24 PM
> Subject: Re: admin authorization to submit feature request
> To: ca...@us..., "moo...@us..." <
> moo...@us...>
> 
> 
> Hi Dan,
> 
> []
> 
> I looked at this quickly and noted a couple things. It looks like the
> resistive MOS devices are already implemented though I did not check their
> functionality. The compiler already supports resistive tran statements, but
> the simulation runtime (vvp) does not. I created a quick test case and
> noticed that there is actually a bug in the non-resistive tran devices
> related to the strength reduction of a supply value to strong. It looks
> like this would be easy to fix when adding resistive support. I believe the
> basics are that when resolving what value to push the resolution functions
> need to know if the resolution is a normal resolution (no strength
> modification), resolving a tran (supply -> strong) or resolving a resistive
> tran (decrement the strength by one) so that it can update the resolved
> strength appropriately. I believe it then needs to resolve this with the
> individual tran ports. It looks like it currently finds a single value and
> pushes it to both tran ports. Something like the following:
> 
> find tran resolved value using correct tran/rtran rules.
> use normal resolution to resolve the above value with the individual port
> value and push that to the port if it is different than the current value.
> 
> Post to the iverilog-devel mailing list if you need any help or would like
> input from the other developers.
> 
> Here is a simple example that can easily be switched to a rtran statement
> so see how the strength is reduced. If you run this as is you will notices
> that all the values on the switch outputs are also supply which is wrong.
> They should be strong except for the first value which is set by the assign
> statement.
> 
> module top;
>     wire sp_pin;
>     wire st_pin;
>     wire pl_pin;
>     wire lc_pin;
>     wire wk_pin;
>     wire mc_pin;
>     wire sc_pin;
>     wire sc_out;
> 
>     reg ctl;
>     reg in;
> 
>     assign (supply1, supply0) sp_pin = in;
> 
>     tranif1 (sp_pin, st_pin, ctl);
>     tranif1 (st_pin, pl_pin, ctl);
>     tranif1 (pl_pin, lc_pin, ctl);
>     tranif1 (lc_pin, wk_pin, ctl);
>     tranif1 (wk_pin, mc_pin, ctl);
>     tranif1 (mc_pin, sc_pin, ctl);
>     tranif1 (sc_pin, sc_out, ctl);
> 
>     initial begin
>        ctl = 1'b0;
>        in = 1'b0;
> 
>        #1;
>        $display("SPI: %v, SP: %v, ST: %v, PL: %v, LC: %v, WK: %v, MC: %v,
> SC: %v",
>                 sp_pin, st_pin, pl_pin, lc_pin, wk_pin, mc_pin, sc_pin,
> sc_out);
> 
>        ctl = 1'b1;
> 
>        #1;
>        $display("SPI: %v, SP: %v, ST: %v, PL: %v, LC: %v, WK: %v, MC: %v,
> SC: %v",
>                 sp_pin, st_pin, pl_pin, lc_pin, wk_pin, mc_pin, sc_pin,
> sc_out);
> 
>        in = 1'b1;
> 
>        #1;
>        $display("SPI: %v, SP: %v, ST: %v, PL: %v, LC: %v, WK: %v, MC: %v,
> SC: %v",
>                 sp_pin, st_pin, pl_pin, lc_pin, wk_pin, mc_pin, sc_pin,
> sc_out);
> 
>     end
> 
> endmodule
> 
> I would expect a version of this for rtranif1, rtranif0 (swap the control
> state) and rtran (remove the control).
> 
> Let me know of you have any questions.
> 
> Cary
> 
> On Friday, February 9, 2018, 10:31:22 AM PST, moo...@us...
> <moo...@us...> wrote:
> 
> 
> Hello, I would like to submit a feature request, specifically support for
> resistive verilog primitives. I may even investigate helping to provide
> code to implement this.
> 
> Thank you,
> 
> Dan Moore
> https://www.linkedin.com/in/danlmoore/
> ------------------------------
> 
> This message was sent to you via the SourceForge web mail form.
> You may reply to this message directly, or at https://sourceforge.net/u/moor
> edan/profile/send_message
> 
> 
> 
> ------------------------------------------------------------------------------
> 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
> 

[Iverilog-devel] Support for resistive verilog primitives

[Dan M. <moo...@su...>]

Forwarding an email reply from Cary about this.

It doesn't appear that the verilog primitive rtran is supported in the
compiler.  The following is with the latest code available on github:


> iverilog -V 2> /dev/null | head -n 1
Icarus Verilog version 11.0 (devel) (s20150603-538-ge7a9662)


> iverilog rtran_tb.v
rtran_tb.v:14: tgt-vvp sorry: resistive switch modeling is not currently
supported.
error: Code generation had 1 error(s).


Dan





---------- Forwarded message ----------
From: Cary R. <cy...@ya...>
Date: Sun, Feb 11, 2018 at 6:24 PM
Subject: Re: admin authorization to submit feature request
To: ca...@us..., "moo...@us..." <
moo...@us...>


Hi Dan,

[]

I looked at this quickly and noted a couple things. It looks like the
resistive MOS devices are already implemented though I did not check their
functionality. The compiler already supports resistive tran statements, but
the simulation runtime (vvp) does not. I created a quick test case and
noticed that there is actually a bug in the non-resistive tran devices
related to the strength reduction of a supply value to strong. It looks
like this would be easy to fix when adding resistive support. I believe the
basics are that when resolving what value to push the resolution functions
need to know if the resolution is a normal resolution (no strength
modification), resolving a tran (supply -> strong) or resolving a resistive
tran (decrement the strength by one) so that it can update the resolved
strength appropriately. I believe it then needs to resolve this with the
individual tran ports. It looks like it currently finds a single value and
pushes it to both tran ports. Something like the following:

find tran resolved value using correct tran/rtran rules.
use normal resolution to resolve the above value with the individual port
value and push that to the port if it is different than the current value.

Post to the iverilog-devel mailing list if you need any help or would like
input from the other developers.

Here is a simple example that can easily be switched to a rtran statement
so see how the strength is reduced. If you run this as is you will notices
that all the values on the switch outputs are also supply which is wrong.
They should be strong except for the first value which is set by the assign
statement.

module top;
   wire sp_pin;
   wire st_pin;
   wire pl_pin;
   wire lc_pin;
   wire wk_pin;
   wire mc_pin;
   wire sc_pin;
   wire sc_out;

   reg ctl;
   reg in;

   assign (supply1, supply0) sp_pin = in;

   tranif1 (sp_pin, st_pin, ctl);
   tranif1 (st_pin, pl_pin, ctl);
   tranif1 (pl_pin, lc_pin, ctl);
   tranif1 (lc_pin, wk_pin, ctl);
   tranif1 (wk_pin, mc_pin, ctl);
   tranif1 (mc_pin, sc_pin, ctl);
   tranif1 (sc_pin, sc_out, ctl);

   initial begin
      ctl = 1'b0;
      in = 1'b0;

      #1;
      $display("SPI: %v, SP: %v, ST: %v, PL: %v, LC: %v, WK: %v, MC: %v,
SC: %v",
               sp_pin, st_pin, pl_pin, lc_pin, wk_pin, mc_pin, sc_pin,
sc_out);

      ctl = 1'b1;

      #1;
      $display("SPI: %v, SP: %v, ST: %v, PL: %v, LC: %v, WK: %v, MC: %v,
SC: %v",
               sp_pin, st_pin, pl_pin, lc_pin, wk_pin, mc_pin, sc_pin,
sc_out);

      in = 1'b1;

      #1;
      $display("SPI: %v, SP: %v, ST: %v, PL: %v, LC: %v, WK: %v, MC: %v,
SC: %v",
               sp_pin, st_pin, pl_pin, lc_pin, wk_pin, mc_pin, sc_pin,
sc_out);

   end

endmodule

I would expect a version of this for rtranif1, rtranif0 (swap the control
state) and rtran (remove the control).

Let me know of you have any questions.

Cary

On Friday, February 9, 2018, 10:31:22 AM PST, moo...@us...
<moo...@us...> wrote:


Hello, I would like to submit a feature request, specifically support for
resistive verilog primitives. I may even investigate helping to provide
code to implement this.

Thank you,

Dan Moore
https://www.linkedin.com/in/danlmoore/
------------------------------

This message was sent to you via the SourceForge web mail form.
You may reply to this message directly, or at https://sourceforge.net/u/moor
edan/profile/send_message