myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Re: Library of components in seperate folders

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

George Pantazopoulos wrote:
> Hi all,
> 
> I'd like to have a directory structure similar to the diagram below. I'd 
> like to build a component library where each component and its unit test 
> reside in its own directory.  From outside the library directory I'd 
> like to be able to import components into projects that integrate the 
> various library components. (eg. computer.py would use the fifo, ram, 
> and uart primitives).
> 
> Can this be done with python? If so, what is a good, clean, and flexible 
> way to accomplish this? I'd like to avoid specifying any kind of path 
> name in the .py files, if possible.

You can use the library as a hierarchical Python package structure,
by adding __init__.py files to the (sub)directories, and adding the
top directory path to the PYTHONPATH environment variable.

Jan

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

[myhdl-list] Library of components in seperate folders

[George P. <ge...@ga...>]

Hi all,

 I'd like to have a directory structure similar to the diagram below. 
I'd like to build a component library where each component and its unit 
test reside in its own directory.  From outside the library directory 
I'd like to be able to import components into projects that integrate 
the various library components. (eg. computer.py would use the fifo, 
ram, and uart primitives).

Can this be done with python? If so, what is a good, clean, and flexible 
way to accomplish this? I'd like to avoid specifying any kind of path 
name in the .py files, if possible.

myhdl_work/
    component_library/
            fifo/
                fifo.py
                fifo_ut.py
                readme.txt

            ram/
                ram.py
                ram_ut.py
                readme.txt

            uart/
                uart.py
                uart_ut.py
                readme.txt

    projects/
            computer/
                 computer.py
                 readme.txt


Thanks,
George

[myhdl-list] Re: signed arithmetic in Icarus

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

Jan Decaluwe wrote:
> Guenter Dannoritzer wrote:

>> There was a post I believe in October in the gEda mailing list, where he
>> (Stephen Williams) announced that he would be gone for a longer period
>> of time. In that time frame the Icarus server must have crashed, as the
>> website was down for a long time afterwards. I think it was end of
>> November that it came up again.
>>
>> If your discussion fell in that time, he might just have missed it.
> 
> 
> Make sense. Anyway, just today I have posted my test case
> demonstrating the issues to the new Icarus bug tracker on
> SourceForge. Currently, 0.9 development is ongoing, so
> let's hope this will be fixed.

In the mean time, Steve Williams has already acknowledged
the issue. Those interested can follow the status here:

https://sourceforge.net/tracker/?func=detail&atid=775997&aid=1380261&group_id=149850


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

Re: [myhdl-list] Re: (no subject)

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

Guenter Dannoritzer wrote:
> Jan Decaluwe wrote:
> 
> 
>>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.
> 
> 
> There was a post I believe in October in the gEda mailing list, where he
> (Stephen Williams) announced that he would be gone for a longer period
> of time. In that time frame the Icarus server must have crashed, as the
> website was down for a long time afterwards. I think it was end of
> November that it came up again.
> 
> If your discussion fell in that time, he might just have missed it.

Make sense. Anyway, just today I have posted my test case
demonstrating the issues to the new Icarus bug tracker on
SourceForge. Currently, 0.9 development is ongoing, so
let's hope this will be fixed.

Thanks,

Jan

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

[myhdl-list] Re: (no subject)

[Guenter D. <dan...@we...>]

Jan Decaluwe wrote:

> 
> 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.

There was a post I believe in October in the gEda mailing list, where he
(Stephen Williams) announced that he would be gone for a longer period
of time. In that time frame the Icarus server must have crashed, as the
website was down for a long time afterwards. I think it was end of
November that it came up again.

If your discussion fell in that time, he might just have missed it.


Cheers,

Guenter

[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

Re: [myhdl-list] Re: co-simulation: vpi file

[<dan...@we...>]

George Pantazopoulos wrote:

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

I was able to install cver under cygwin just fine, however, when trying
to run the PLI examples, ran into some problems. It basically has to do
that you have to run a certain (older) version of cygwin in order to get
it going.

On this page:

http://www.pragmatic-c.com/gpl-cver/windows.htm

I found this link to a file, that has the details about it:

 	"To use the PLI on Cygwin please read the README in 	
	tests_and_examples/examples.vpi."

> 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?

I ran into that too. Actually a delay(1) is already sufficient.

I believe this has to do with the nature of simulating a flip-flop
behavior and you will find that in every HDL simulator.

Consider the following statement in HDL simulation.


	yield clk.posedge

	a.next = input
	b.next = a

In software programming a and b would have the same value. In HDL b will
get the result of a one clock cycle later. In the simulation the
decision is made at the positive edge of the clock. Consider this as the
point when time stands still in the simulator. Now the simulator needs
to make a decision about the assignments. For the assignments it takes
the values it last knew, which is one timestep before the positive edge.
It does the assignments and turns time on again. Now you are one
timestep after the positive edge and the values would be available for
assignment. As you want to look at the values, this is the time you want
to be at to get the correct values.

I hope I explained that correct. Anyone please correct me if I am wrong.

There is actually a book, I found good in explaining writing
testbenches, co-simulation, etc. It also talks about different types of
simulators.

Writing Testbenches, 2nd edition
by Janick Bergeron
Kluwer Academic Publishers


Cheers,

Guenter

Re: [myhdl-list] Re: co-simulation: vpi file

[George P. <ge...@ga...>]

Please disregard the other message with no subject line. My apologies.


> I reviewed the toVerilog tests with Icarus. I have 2
> groups of failures:
>
> - test_bugreports fails because of the missing verilogCompile
> - test_inc has a failing test because of a bug in the test suite
>
> I have solved these issues in my development code.
>
> - test_dec has failing tests because of Icarus bugs with signed
> - test_signed has failing tests because of Icarus bugs with signed
>
>
> If you see the same, you can ignore the failures for now and it
> basically means that you got it to work on Windows. That is
> good news - thanks for the efforts.

Hi Jan,

   I added the definition of verilogCompileIcarus to util.py and set
"verilogCompile =3D 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
:)

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

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 fo=
r
this sort of thing? You did mention not to compare at time 0. Did you mea=
n
time 0 from the start of the entire simulation? Or did you mean time 0
from the start of each signal changing?

Thanks,
George

errors from test_all.py:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: testDecFunc (test_dec.TestDec)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_dec.py", line 196, in
testDecFunc
    sim =3D self.bench(decFunc)
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_dec.py", line 179, in
bench
    dec_inst_v =3D dec_v(dec.func_name, count_v, enable, clock, reset)
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_dec.py", line 126, in
dec_v
    return setupCosimulation(**locals())
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 15, in
setupCosimulationIcarus
    return Cosimulation(simulate_cmd, **kwargs)
  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line
91, in __init__
    raise CosimulationError(_error.SimulationEnd)
CosimulationError: Premature simulation end

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: Check increment operation
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_inc.py", line 176, in
testInc2
    sim.run(quiet=3D1)
  File "/usr/lib/python2.4/site-packages/myhdl/_Simulation.py", line
132, in run
    waiter.next(waiters, actives, exc)
  File "/usr/lib/python2.4/site-packages/myhdl/_Waiter.py", line 70, in n=
ext
    clause =3D self.generator.next()
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_inc.py", line 140, in
check
    self.assertEqual(count, count_v)
AssertionError: Signal(intbv(1L)) !=3D Signal(intbv(0L))

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: testAugmOps (test_signed.TestAugmOps)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_signed.py", line 482,
in testAugmOps
    Simulation(sim).run()
  File "/usr/lib/python2.4/site-packages/myhdl/_Simulation.py", line
132, in run
    waiter.next(waiters, actives, exc)
  File "/usr/lib/python2.4/site-packages/myhdl/_Waiter.py", line 70, in n=
ext
    clause =3D self.generator.next()
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_signed.py", line 465,
in check
    self.assertEqual(Mul, Mul_v)
AssertionError: Signal(intbv(4056L)) !=3D Signal(intbv(-9256))

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: testBinaryOps (test_signed.TestBinaryOps)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_signed.py", line 236,
in testBinaryOps
    Simulation(sim).run()
  File "/usr/lib/python2.4/site-packages/myhdl/_Simulation.py", line
132, in run
    waiter.next(waiters, actives, exc)
  File "/usr/lib/python2.4/site-packages/myhdl/_Waiter.py", line 70, in n=
ext
    clause =3D self.generator.next()
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_signed.py", line 207,
in check
    self.assertEqual(Mul, Mul_v)
AssertionError: Signal(intbv(-9700)) !=3D Signal(intbv(55836))

---------------------------------------------------------------------- Ra=
n
129 tests in 251.108s

FAILED (failures=3D3, errors=3D1)



--=20
George Pantazopoulos
http://www.gammaburst.net

[myhdl-list] (no subject)

[George P. <ge...@ga...>]

> I reviewed the toVerilog tests with Icarus. I have 2
> groups of failures:
>
> - test_bugreports fails because of the missing verilogCompile
> - test_inc has a failing test because of a bug in the test suite
>
> I have solved these issues in my development code.
>
> - test_dec has failing tests because of Icarus bugs with signed
> - test_signed has failing tests because of Icarus bugs with signed
>
>
> If you see the same, you can ignore the failures for now and it
> basically means that you got it to work on Windows. That is
> good news - thanks for the efforts.

Hi Jan,

   I added the definition of verilogCompileIcarus to util.py and set
"verilogCompile =3D 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 :)

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

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?

Thanks,
George

errors from test_all.py:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: testDecFunc (test_dec.TestDec)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_dec.py", line 196, in
testDecFunc
    sim =3D self.bench(decFunc)
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_dec.py", line 179, in
bench
    dec_inst_v =3D dec_v(dec.func_name, count_v, enable, clock, reset)
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_dec.py", line 126, in
dec_v
    return setupCosimulation(**locals())
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 15, in
setupCosimulationIcarus
    return Cosimulation(simulate_cmd, **kwargs)
  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line
91, in __init__
    raise CosimulationError(_error.SimulationEnd)
CosimulationError: Premature simulation end

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: Check increment operation
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_inc.py", line 176, in
testInc2
    sim.run(quiet=3D1)
  File "/usr/lib/python2.4/site-packages/myhdl/_Simulation.py", line
132, in run
    waiter.next(waiters, actives, exc)
  File "/usr/lib/python2.4/site-packages/myhdl/_Waiter.py", line 70, in n=
ext
    clause =3D self.generator.next()
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_inc.py", line 140, in
check
    self.assertEqual(count, count_v)
AssertionError: Signal(intbv(1L)) !=3D Signal(intbv(0L))

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: testAugmOps (test_signed.TestAugmOps)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_signed.py", line 482,
in testAugmOps
    Simulation(sim).run()
  File "/usr/lib/python2.4/site-packages/myhdl/_Simulation.py", line
132, in run
    waiter.next(waiters, actives, exc)
  File "/usr/lib/python2.4/site-packages/myhdl/_Waiter.py", line 70, in n=
ext
    clause =3D self.generator.next()
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_signed.py", line 465,
in check
    self.assertEqual(Mul, Mul_v)
AssertionError: Signal(intbv(4056L)) !=3D Signal(intbv(-9256))

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: testBinaryOps (test_signed.TestBinaryOps)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_signed.py", line 236,
in testBinaryOps
    Simulation(sim).run()
  File "/usr/lib/python2.4/site-packages/myhdl/_Simulation.py", line
132, in run
    waiter.next(waiters, actives, exc)
  File "/usr/lib/python2.4/site-packages/myhdl/_Waiter.py", line 70, in n=
ext
    clause =3D self.generator.next()
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/test_signed.py", line 207,
in check
    self.assertEqual(Mul, Mul_v)
AssertionError: Signal(intbv(-9700)) !=3D Signal(intbv(55836))

----------------------------------------------------------------------
Ran 129 tests in 251.108s

FAILED (failures=3D3, errors=3D1)

[myhdl-list] Re: co-simulation: vpi file

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

George Pantazopoulos wrote:
> Hi Jan, in the util.py file pasted below, what should be assigned to
> verilogCompile if I want to use Icarus and not cver?
> 
> By the way, by commenting out the last two lines of util.py,
> test_always_comb.py and test_fsm.py both passed all tests. However, I
> got an error regarding verilogCompile when I tried to run test_all.py.
> So I need the correct value for it, commenting it out wont do.
> 
> All the test files I mentioned are in myhdl/test/toVerilog.

George:

I reviewed the toVerilog tests with Icarus. I have 2
groups of failures:

- test_bugreports fails because of the missing verilogCompile
- test_inc has a failing test because of a bug in the test suite

I have solved these issues in my development code.

- test_dec has failing tests because of Icarus bugs with signed
- test_signed has failing tests because of Icarus bugs with signed

There's no solution for these ones. Please note that Icarus is
unreliable for signed arithmetic.

I will add notes in the README.txt file in the test/toVerilog
directory to explain the issues.

If you see the same, you can ignore the failures for now and it
basically means that you got it to work on Windows. That is
good news - thanks for the efforts.

For completeness: the verilogCompile only does a compile step
of Verilog code, no cosimulation. The Icarus version is:

def verilogCompileIcarus(name):
     objfile = "%s.o" % name
     if path.exists(objfile):
         os.remove(objfile)
     analyze_cmd = "iverilog -o %s %s.v tb_%s.v" % (objfile, name, name)
     os.system(analyze_cmd)


Regards,

Jan

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

Re: [myhdl-list] Re: co-simulation: vpi file

[George P. <ge...@ga...>]

Hi Jan, in the util.py file pasted below, what should be assigned to
verilogCompile if I want to use Icarus and not cver?

 By the way, by commenting out the last two lines of util.py,
test_always_comb.py and test_fsm.py both passed all tests. However, I
got an error regarding verilogCompile when I tried to run test_all.py.
So I need the correct value for it, commenting it out wont do.

All the test files I mentioned are in myhdl/test/toVerilog.

Thanks,
George




import os
path = os.path

from myhdl import *

# Icarus
def setupCosimulationIcarus(**kwargs):
    name = kwargs['name']
    objfile = "%s.o" % name
    if path.exists(objfile):
        os.remove(objfile)
    analyze_cmd = "iverilog -o %s %s.v tb_%s.v" % (objfile, name, name)
    os.system(analyze_cmd)
    simulate_cmd = "vvp -m ../../../cosimulation/icarus/myhdl.vpi %s" %
objfile
    return Cosimulation(simulate_cmd, **kwargs)

# cver
def setupCosimulationCver(**kwargs):
    name = kwargs['name']
    cmd = "cver -q
+loadvpi=../../../cosimulation/cver/myhdl_vpi:vpi_compat_bootstrap " + \
          "%s.v tb_%s.v " % (name, name)
    return Cosimulation(cmd, **kwargs)

def verilogCompileCver(name):
    cmd = "cver -c %s.v" % name
    os.system(cmd)


setupCosimulation = setupCosimulationIcarus
setupCosimulation = setupCosimulationCver

verilogCompile = verilogCompileCver

 >
 >

[myhdl-list] Re: co-simulation: vpi file

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

George Pantazopoulos wrote:
> Hi Jan,
> 
>> - does co-simulation work at all ??? If it does work, the error messages
>> you get should come from unittest assertion statements, not from
>> the Cosimulation module. 
>>
>> Note that the toVerilog tests (myhdl/test/toVerilog) have plenty of
>> unit test modules that use co-simulation. All those tests have been
>> run with cver and icarus. (Exception: test_signed fails with Icarus
>> because it has bugs with signed arithmetic.)
>>
> In myhdl0.5a1/myhdl/test/
> test_Cosimulation.py and test_all.py both pass all their tests.

This only tests the MyHDL side - there's no other HDL simulator
involved.

> However, in myhdl0.5a1/myhdl/test/toVerilog/
> running test_always_comb.py (or any of the other ones I've tried) 
> resulted in massive amounts of errors.

Ok. In toVerilog/util.py I have added setup functions
so that I can easily switch between Icarus and Cver.

I prefer Cver these days, as it seems more reliable. So
in the snapshot, the setup is apparently Cver by default.

You'll have to go in the source code of util.py and
make sure Icarus setup is used instead.

I would be surprized if this alone would solve the
issue. There may be other path/filenaming issues.
You'll have to make sure that the icarus call from
the setup functions is valid for your system.

Good luck,

Jan

> 
> Below I pasted an excerpt from running test_always_comb.py:
> 
> My system configuration is:
> 
> Windows XP Professional SP2
> cygwin (cygwin dll version 1.5.18)
> myHDL 0.5a1
> Icarus Verilog 0.8.2 (compiled on cygwin)
> 
> HTH,
> George
> 
> Begin paste
> -----------
> 
> test1 (__main__.AlwaysCombSimulationTest) ... ERROR
> test2 (__main__.AlwaysCombSimulationTest) ... ERROR
> test3 (__main__.AlwaysCombSimulationTest) ... ERROR
> test4 (__main__.AlwaysCombSimulationTest) ... ERROR
> test5 (__main__.AlwaysCombSimulationTest) ... ERROR
> 
> ======================================================================
> ERROR: test1 (__main__.AlwaysCombSimulationTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "test_always_comb.py", line 130, in test1
>    Simulation(self.bench(design1)).run(quiet=QUIET)
>  File "test_always_comb.py", line 103, in bench
>    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
>  File "test_always_comb.py", line 80, in design_v
>    return setupCosimulation(**locals())
>  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
> setupCosimulationCver
>    return Cosimulation(cmd, **kwargs)
>  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
> 84, in __init__
>    raise CosimulationError(_error.OSError, str(e))
> CosimulationError: OSError: [Errno 2] No such file or directory
> 
> ======================================================================
> ERROR: test2 (__main__.AlwaysCombSimulationTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "test_always_comb.py", line 133, in test2
>    Simulation(self.bench(design2)).run(quiet=QUIET)
>  File "test_always_comb.py", line 103, in bench
>    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
>  File "test_always_comb.py", line 80, in design_v
>    return setupCosimulation(**locals())
>  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
> setupCosimulationCver
>    return Cosimulation(cmd, **kwargs)
>  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
> 84, in __init__
>    raise CosimulationError(_error.OSError, str(e))
> CosimulationError: OSError: [Errno 2] No such file or directory
> 
> ======================================================================
> ERROR: test3 (__main__.AlwaysCombSimulationTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "test_always_comb.py", line 136, in test3
>    Simulation(self.bench(design3)).run(quiet=QUIET)
>  File "test_always_comb.py", line 103, in bench
>    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
>  File "test_always_comb.py", line 80, in design_v
>    return setupCosimulation(**locals())
>  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
> setupCosimulationCver
>    return Cosimulation(cmd, **kwargs)
>  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
> 84, in __init__
>    raise CosimulationError(_error.OSError, str(e))
> CosimulationError: OSError: [Errno 2] No such file or directory
> 
> ======================================================================
> ERROR: test4 (__main__.AlwaysCombSimulationTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "test_always_comb.py", line 139, in test4
>    Simulation(self.bench(design4)).run(quiet=QUIET)
>  File "test_always_comb.py", line 103, in bench
>    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
>  File "test_always_comb.py", line 80, in design_v
>    return setupCosimulation(**locals())
>  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
> setupCosimulationCver
>    return Cosimulation(cmd, **kwargs)
>  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
> 84, in __init__
>    raise CosimulationError(_error.OSError, str(e))
> CosimulationError: OSError: [Errno 2] No such file or directory
> 
> ======================================================================
> ERROR: test5 (__main__.AlwaysCombSimulationTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "test_always_comb.py", line 142, in test5
>    Simulation(self.bench(design5)).run(quiet=QUIET)
>  File "test_always_comb.py", line 103, in bench
>    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
>  File "test_always_comb.py", line 80, in design_v
>    return setupCosimulation(**locals())
>  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
> setupCosimulationCver
>    return Cosimulation(cmd, **kwargs)
>  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
> 84, in __init__
>    raise CosimulationError(_error.OSError, str(e))
> CosimulationError: OSError: [Errno 2] No such file or directory
> 
> ----------------------------------------------------------------------
> Ran 5 tests in 1.079s
> 
> FAILED (errors=5)
> ERROR
> 
> 
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click


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

Re: [myhdl-list] Re: co-simulation: vpi file

[George P. <ge...@ga...>]

Hi Jan,

> - does co-simulation work at all ??? If it does work, the error messages
> you get should come from unittest assertion statements, not from
> the Cosimulation module.  
>
>
> Note that the toVerilog tests (myhdl/test/toVerilog) have plenty of
> unit test modules that use co-simulation. All those tests have been
> run with cver and icarus. (Exception: test_signed fails with Icarus
> because it has bugs with signed arithmetic.)
>
In myhdl0.5a1/myhdl/test/
test_Cosimulation.py and test_all.py both pass all their tests.

However, in myhdl0.5a1/myhdl/test/toVerilog/
running test_always_comb.py (or any of the other ones I've tried) 
resulted in massive amounts of errors.

Below I pasted an excerpt from running test_always_comb.py:

My system configuration is:

Windows XP Professional SP2
cygwin (cygwin dll version 1.5.18)
myHDL 0.5a1
Icarus Verilog 0.8.2 (compiled on cygwin)

HTH,
George

Begin paste
-----------

test1 (__main__.AlwaysCombSimulationTest) ... ERROR
test2 (__main__.AlwaysCombSimulationTest) ... ERROR
test3 (__main__.AlwaysCombSimulationTest) ... ERROR
test4 (__main__.AlwaysCombSimulationTest) ... ERROR
test5 (__main__.AlwaysCombSimulationTest) ... ERROR

======================================================================
ERROR: test1 (__main__.AlwaysCombSimulationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_always_comb.py", line 130, in test1
    Simulation(self.bench(design1)).run(quiet=QUIET)
  File "test_always_comb.py", line 103, in bench
    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
  File "test_always_comb.py", line 80, in design_v
    return setupCosimulation(**locals())
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
setupCosimulationCver
    return Cosimulation(cmd, **kwargs)
  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
84, in __init__
    raise CosimulationError(_error.OSError, str(e))
CosimulationError: OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test2 (__main__.AlwaysCombSimulationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_always_comb.py", line 133, in test2
    Simulation(self.bench(design2)).run(quiet=QUIET)
  File "test_always_comb.py", line 103, in bench
    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
  File "test_always_comb.py", line 80, in design_v
    return setupCosimulation(**locals())
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
setupCosimulationCver
    return Cosimulation(cmd, **kwargs)
  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
84, in __init__
    raise CosimulationError(_error.OSError, str(e))
CosimulationError: OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test3 (__main__.AlwaysCombSimulationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_always_comb.py", line 136, in test3
    Simulation(self.bench(design3)).run(quiet=QUIET)
  File "test_always_comb.py", line 103, in bench
    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
  File "test_always_comb.py", line 80, in design_v
    return setupCosimulation(**locals())
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
setupCosimulationCver
    return Cosimulation(cmd, **kwargs)
  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
84, in __init__
    raise CosimulationError(_error.OSError, str(e))
CosimulationError: OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test4 (__main__.AlwaysCombSimulationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_always_comb.py", line 139, in test4
    Simulation(self.bench(design4)).run(quiet=QUIET)
  File "test_always_comb.py", line 103, in bench
    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
  File "test_always_comb.py", line 80, in design_v
    return setupCosimulation(**locals())
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
setupCosimulationCver
    return Cosimulation(cmd, **kwargs)
  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
84, in __init__
    raise CosimulationError(_error.OSError, str(e))
CosimulationError: OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test5 (__main__.AlwaysCombSimulationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_always_comb.py", line 142, in test5
    Simulation(self.bench(design5)).run(quiet=QUIET)
  File "test_always_comb.py", line 103, in bench
    design_v_inst = design_v(design.func_name, a, b, c, d, p_v, q_v, r_v)
  File "test_always_comb.py", line 80, in design_v
    return setupCosimulation(**locals())
  File "/tmp/myhdl-0.5a1/myhdl/test/toVerilog/util.py", line 22, in 
setupCosimulationCver
    return Cosimulation(cmd, **kwargs)
  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line 
84, in __init__
    raise CosimulationError(_error.OSError, str(e))
CosimulationError: OSError: [Errno 2] No such file or directory

----------------------------------------------------------------------
Ran 5 tests in 1.079s

FAILED (errors=5)
ERROR


>

[myhdl-list] Re: possible improvement for error message?

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

Günter Dannoritzer wrote:
> Jan,
> 
> When feeding test data from a csv file to a myhdl testbench I got the
> following error message:
> 
> 
> File "/usr/lib/python2.4/site-packages/myhdl/_Signal.py", line 172, in
> _set_next
>     self._setNextVal(val)
>   File "/usr/lib/python2.4/site-packages/myhdl/_Signal.py", line 206, in
> _setNextBool
>     raise ValueError("Expected value 0 or 1, got %s" % val)
> ValueError: Expected value 0 or 1, got 1
> 
> 
> What happened is that I did not think about converting the data from the
> python csv reader, which delivers the data as str type, into int type.
>
> I think the following change could improve the error message:
> 
> 
> Index: _Signal.py
> ===================================================================
> --- _Signal.py  (revision 1.29)
> +++ _Signal.py  (work copy)
> @@ -202,6 +202,8 @@
> 
>      # set next methods
>      def _setNextBool(self, val):
> +        if not isinstance(val, (bool, int, long, intbv)):
> +            raise TypeError("Expected bool, int, long, or intbv, got
> %s"%type(val))
>          if not val in (0, 1):
>              raise ValueError("Expected value 0 or 1, got %s" % val)
>          self._next = val


Thanks. To avoid the additional test, I have integrated the type
info in the ValueError message and I use repr(val) to have a string
represention with quotes.

Jan

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

[myhdl-list] Re: possible improvement for error message?

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

Günter Dannoritzer wrote:
> Jan,
> 
> When feeding test data from a csv file to a myhdl testbench I got the
> following error message:
> 
> 
> File "/usr/lib/python2.4/site-packages/myhdl/_Signal.py", line 172, in
> _set_next
>     self._setNextVal(val)
>   File "/usr/lib/python2.4/site-packages/myhdl/_Signal.py", line 206, in
> _setNextBool
>     raise ValueError("Expected value 0 or 1, got %s" % val)
> ValueError: Expected value 0 or 1, got 1
> 
> 
> What happened is that I did not think about converting the data from the
> python csv reader, which delivers the data as str type, into int type.
>
> I think the following change could improve the error message:
> 
> 
> Index: _Signal.py
> ===================================================================
> --- _Signal.py  (revision 1.29)
> +++ _Signal.py  (work copy)
> @@ -202,6 +202,8 @@
> 
>      # set next methods
>      def _setNextBool(self, val):
> +        if not isinstance(val, (bool, int, long, intbv)):
> +            raise TypeError("Expected bool, int, long, or intbv, got
> %s"%type(val))
>          if not val in (0, 1):
>              raise ValueError("Expected value 0 or 1, got %s" % val)
>          self._next = val


Thanks. To avoid the additional test, I have integrated the type
info in the ValueError message and I use repr(val) to have a string
represention with quotes.

Jan

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

[myhdl-list] possible improvement for error message?

[<dan...@we...>]

Jan,

When feeding test data from a csv file to a myhdl testbench I got the
following error message:


File "/usr/lib/python2.4/site-packages/myhdl/_Signal.py", line 172, in
_set_next
    self._setNextVal(val)
  File "/usr/lib/python2.4/site-packages/myhdl/_Signal.py", line 206, in
_setNextBool
    raise ValueError("Expected value 0 or 1, got %s" % val)
ValueError: Expected value 0 or 1, got 1


What happened is that I did not think about converting the data from the
python csv reader, which delivers the data as str type, into int type.

I think the following change could improve the error message:


Index: _Signal.py
===================================================================
--- _Signal.py  (revision 1.29)
+++ _Signal.py  (work copy)
@@ -202,6 +202,8 @@

     # set next methods
     def _setNextBool(self, val):
+        if not isinstance(val, (bool, int, long, intbv)):
+            raise TypeError("Expected bool, int, long, or intbv, got
%s"%type(val))
         if not val in (0, 1):
             raise ValueError("Expected value 0 or 1, got %s" % val)
         self._next = val




Cheers,

Guenter

Re: [myhdl-list] co-simulation: vpi file

[<dan...@we...>]

George Pantazopoulos wrote:
> Hi,
> 
> Right now I'm using cygwin-compiled python2.4 with cygwin-compiled icarus
> 0.82. Will things improve if I use a Windows native version of python?
> 

I was able to run the cosimulation examples in the
cosimulation/icarus/test folder of the myhdl source with icarus 0.8.1
compiled under cygwin with python 2.4.

Guenter

[myhdl-list] Re: co-simulation: vpi file

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

Günter Dannoritzer wrote:
> George Pantazopoulos wrote:
>  >
> 
>>It seems to ok for me (I compiled icarus 0.82 under cygwin). However, unit
>>tests that pass in the myHDL domain are failing when I run them with
>>co-simulation. Have you had that happen to you before?

Like always, it would help to give details on how it fails on a small
example.

> 
> Only if my myhdl logic would not generate the verilog that I expected it
> to be.

A bug in the Verilog conversion is one possibility.

Other possibilities that should be checked before:

- initialization. What happens at time 0 may be different for Verilog
and MyHDL, e.g. because of X-handling. Make sure all signals should have
a defined value before you start comparing them. Don't compare at
time 0, but after certain events (e.g. clock) or delay have occurred.

- does co-simulation work at all ??? If it does work, the error messages
you get should come from unittest assertion statements, not from
the Cosimulation module.

> 
> Though I did not use co-simulation under cygwin.
> 
> Did you try it with a simple example which allows you to follow it by
> hand to verify the output?

Note that the toVerilog tests (myhdl/test/toVerilog) have plenty of
unit test modules that use co-simulation. All those tests have been
run with cver and icarus. (Exception: test_signed fails with Icarus
because it has bugs with signed arithmetic.)

So for a small example that should work, you may want to look there.

Jan

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

Re: [myhdl-list] co-simulation: vpi file

[<dan...@we...>]

George Pantazopoulos wrote:
> Hi,
> 
> Right now I'm using cygwin-compiled python2.4 with cygwin-compiled icarus
> 0.82. Will things improve if I use a Windows native version of python?

No, the native windows version of python has no os.fork functionality,
which at this time is required by _cosimulation.py.

Have a look at this old post:

http://article.gmane.org/gmane.comp.python.myhdl/119/match=cosimulation+cygwin


Guenter

Re: [myhdl-list] co-simulation: vpi file

[George P. <ge...@ga...>]

Hi,

Right now I'm using cygwin-compiled python2.4 with cygwin-compiled icarus
0.82. Will things improve if I use a Windows native version of python?

Thanks,
George


> co-sim can't be run on cygwin, as on windows platform, python core does=
n't
> support the feature needed for co-sim.
>
> 2005/12/6, George Pantazopoulos <ge...@ga...>:
>>
>>
>> Hi Guenter,
>>
>> > George Pantazopoulos wrote:
>> >> Hi all, in the example taken from the docs below, where is the
>> myhdl.vpi
>> >> file supposed to come from?
>> >>
>> if you download the 0.4 code and unpack
>> > it, there is a cosimulation directory with an Icarus folder.
>>
>> Thanks, that did the trick!
>>
>> > I saw you are using cygwin. I had trouble getting cosimulation going
>> > under it, but that might be because of my strange setup with python.=
 I
>> I probably would need to compile it from
>> > scratch under cygwin too to get it working.
>> >
>>
>> It seems to ok for me (I compiled icarus 0.82 under cygwin). However,
>> unit
>> tests that pass in the myHDL domain are failing when I run them with
>> co-simulation. Have you had that happen to you before?
>>
>> Thanks,
>> George
>>
>>
>> > Hope that helps.
>> > Cheers,
>> > Guenter
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>> files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK=
!
>> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>


--=20
George Pantazopoulos
http://www.gammaburst.net

Re: [myhdl-list] co-simulation: vpi file

[<dan...@we...>]

nicran wrote:
> co-sim can't be run on cygwin, as on windows platform, python core doesn't
> support the feature needed for co-sim.
> 
Has that to do with the missing os.fork under native windows or what
other limitations does the python core have to not being able to run it
under windows?

Guenter

Re: [myhdl-list] co-simulation: vpi file

[<dan...@we...>]

George Pantazopoulos wrote:
 >
> It seems to ok for me (I compiled icarus 0.82 under cygwin). However, unit
> tests that pass in the myHDL domain are failing when I run them with
> co-simulation. Have you had that happen to you before?

Only if my myhdl logic would not generate the verilog that I expected it
to be.

Though I did not use co-simulation under cygwin.

Did you try it with a simple example which allows you to follow it by
hand to verify the output?

Guenter

Re: [myhdl-list] Documentation doubts

[<dan...@we...>]

Jan Decaluwe wrote:
> Hi all:
> 
> I am currently updating the documentation for release 0.5.
> With the 0.5 release, I hope to attract new users.
> 
> However, I'm not sure the current set of docs is adequate
> for new users. Pointing to the whatsnew document and the
> manual may be overwhelming.

I think it always depends on the background of the new user. Basically
there are two components to that, one is the Python knowledge and the
other the HDL knowledge.

Having someone with strong HDL background, but a new MyHDL user the
current manual might be just sufficient. Speaking for myself I find it
now sufficient and I like that it is so concise. From my background I
would say I have more experience with software development and Python
than with HDL development. However, Python generators were something new
to me and getting used to. I am still not used to using them in software
development. Concerning HDL development I am pretty much a beginner.

I had to read the manual several times in order to understand it, every
time finding something new that I overlooked the first time.

I was always reading it, in my mind looking for a way to use MyHDL as a
tool to develop synthesizable HDL. It was only later that I recognized
that most of the examples given are more towards verification and only a
small part was for generating synthesizable HDL. When I look now at the
manual I would say it is clearly said so. But also it is pretty
interwoven. I wonder whether a separation of the manual in terms of
verification and synthesizable HDL would help to clarify that?

> 
> I'm not asking for addition work :-) but shouldn't there
> be some kind of Getting Started document? E.g. taking
> a simple example all the way to Verilog.

I think that is almost there with the rs232 example. For now it covers
just verification. To emphasize the synthesizable HDL part this could be
extended to that, at least in parts.

> 
> As you have all been new users at one point, perhaps you
> have some ideas on what was missing (if anything) to get
> you on track asap.

As I said earlier, it is nice now to have the manual being concise. At
the beginning I had hoped to have some additional information. I often
thought about it would be nice to have something like a  'tips and
tricks' area on the wiki where users would add their 'aha'-experience.
To some new users they might be useful information, but too much for the
manual.

[...]

Just my two cents.

Guenter

Re: [myhdl-list] co-simulation: vpi file

[nicran <ni...@gm...>]

co-sim can't be run on cygwin, as on windows platform, python core doesn't
support the feature needed for co-sim.

2005/12/6, George Pantazopoulos <ge...@ga...>:
>
>
> Hi Guenter,
>
> > George Pantazopoulos wrote:
> >> Hi all, in the example taken from the docs below, where is the
> myhdl.vpi
> >> file supposed to come from?
> >>
> if you download the 0.4 code and unpack
> > it, there is a cosimulation directory with an Icarus folder.
>
> Thanks, that did the trick!
>
> > I saw you are using cygwin. I had trouble getting cosimulation going
> > under it, but that might be because of my strange setup with python. I
> I probably would need to compile it from
> > scratch under cygwin too to get it working.
> >
>
> It seems to ok for me (I compiled icarus 0.82 under cygwin). However, uni=
t
> tests that pass in the myHDL domain are failing when I run them with
> co-simulation. Have you had that happen to you before?
>
> Thanks,
> George
>
>
> > Hope that helps.
> > Cheers,
> > Guenter
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] co-simulation: vpi file

[George P. <ge...@ga...>]

Hi Guenter,

> George Pantazopoulos wrote:
>> Hi all, in the example taken from the docs below, where is the myhdl.v=
pi
>> file supposed to come from?
>>
 if you download the 0.4 code and unpack
> it, there is a cosimulation directory with an Icarus folder.

Thanks, that did the trick!

> I saw you are using cygwin. I had trouble getting cosimulation going
> under it, but that might be because of my strange setup with python. I
I probably would need to compile it from
> scratch under cygwin too to get it working.
>

It seems to ok for me (I compiled icarus 0.82 under cygwin). However, uni=
t
tests that pass in the myHDL domain are failing when I run them with
co-simulation. Have you had that happen to you before?

Thanks,
George


> Hope that helps.
> Cheers,
> Guenter