[myhdl-list] Re: (no subject)

[Jan D. <ja...@ja...>]

George Pantazopoulos wrote:

> Hi Jan,
> 
>    I added the definition of verilogCompileIcarus to util.py and set
> "verilogCompile = verilogCompileIcarus" and re-ran test_all.py in
> myhdl/test/toVerilog. Now almost all the test pass, except for the ones
> you mentioned (I've pasted just the four error messages below. So I
> guess this means myHDL 0.5a1 and Icarus 0.8.2 do work on WindowsXP with
> cygwin :)

Yes. Good news. I guess I should add an FAQ entry about MyHDL usage
on windows.

> Would you recommend that I transistion to cver? Which has the more
> active development and community?

If you need signed support, you should use cver for now.

Some weeks ago, it seemed that Icarus development was not very active.
However, I just checked this and it is clearly ongoing. I have discussed
my issues with signed support on comp.lang.verilog, without reaction
from the developer. However, there is a new bug tracker on SourceForge
and I should/will add the bug report there.

It seems there are quite some Icarus users, on the other hand cver
is a free version of a commercial tool. I will keep using both
for development purposes.

> Also, I got my own myHDL/cosim unit tests to pass by inserting yield
> delay(10) statements between a signal changing and the time I do a
> assertEqual() on it. Also, adding delay(10) to the very beginning of
> each test function seemed to help some cases. It seems like somewhat of
> a kludge, though. Is that the right thing to do? What are the guidelines
> for this sort of thing? You did mention not to compare at time 0. Did
> you mean time 0 from the start of the entire simulation? Or did you mean
> time 0 from the start of each signal changing?

Time 0 (for the entire simulation) is special. For various reasons, it
is not straightforward to initialize signals in different languages
to a compatible value. E.g. everything in Verilog starts from 'x' by
default, but MyHDL higher level types start from some defined initial
value.

So, just make sure that signals have gotten their first "true" value
before starting to look at them. Also, don't sample at the same time
of a change - this is fundamentally problematic in hardware design.
Sample at a time when a signal should be stable. E.g. when a clock
posedge triggers changes, sample a small delay after the posedge,
or at the negedge.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com