myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] ANNOUNCE: MyHDL 0.4.1 with cver support

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

MyHDL is a Python package for using Python as a hardware description
and verification language. MyHDL 0.4.1 is now available at:

   http://sourceforge.net/project/showfiles.php?group_id=91207

MyHDL 0.4.1 release notes:

* Maintenance release that solves most outstanding issues
  and implements some feature requests.
  See the SourceForge Bug and RFE Trackers for details.
  More info can also be found on the mailing list.

* Added cosimulation support for the cver Verilog simulator.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Using Python as a hardware description language:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: myhdl on windows platform?

[Chun L. Z. <chu...@ho...>]

Jan,

I tried the method you proposed for me. I made some necessary changes of =
file cosimulation/icarus/test/test.py, use the python in cygwin to =
co-sim (python test.py), and got the following kind of errors.

I don't know what is this assertion means. Could you help me out, or if =
these is a definite message that myhdl can't be used with any windows =
version simulator, I can abort my effort in this.

Thank you very much.

Btw: You've done a great job. Till now it works fine on linux platform =
for me as a very good HVL.

-Arnold

# vsim -do sim.do -c -pli {h:\mti\myhdl.dll} tb=20
# Loading c:\Modeltech_6.0a\win32/novas.dll
# Loading h:\mti\myhdl.dll
# //  ModelSim SE 6.0a Sep 24 2004=20
# //
# //  Copyright Mentor Graphics Corporation 2004
# //              All Rights Reserved.
# //
# //  THIS WORK CONTAINS TRADE SECRET AND=20
# //  PROPRIETARY INFORMATION WHICH IS THE PROPERTY
# //  OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS
# //  AND IS SUBJECT TO LICENSE TERMS.
# //
# Loading work.tb
# do sim.do=20
Assertion failed: n > 0, file myhdl.c, line 216

abnormal program termination
** Fatal: Signal 22 caught. Closing vsimk kernel.
** Fatal: Signal Caught in kernel.
** Fatal: vsimk is exiting with code 222.
(Exit codes are defined in the ModelSim messages appendix
of the ModelSim User's Manual.)
Traceback (most recent call last):
  File "test.py", line 17, in ?
    cosim =3D Cosimulation("vsim -pli h:\mti\myhdl.dll -c tb -do =
sim.do", a=3Da, b=3Db
, c=3Dc)
  File "/usr/lib/python2.4/site-packages/myhdl/_Cosimulation.py", line =
91, in __
init__
    raise CosimulationError(_error.SimulationEnd)
myhdl.CosimulationError: Premature simulation end


"Arnold" <chu...@ho...> wrote in message news:...
> Jan,
>=20
> Thank you for your quick reply.
>=20
> Another question is about using cygwin to compile python on windows: =
can I
> use mingw32 to compile python instead of cygwin? If yes how can I =
achieve
> that.
>=20
> Thanks
>=20
>=20
> "Jan Decaluwe" <ja...@ja...> wrote in message
> news:41C...@ja......
> > Chun Lin Zhang wrote:
> > > Hi, all,
> > >
> > > I tried to use myhdl to co-simulate with verilog on windows =
platform
> > > today. I got the following error messages.
> > >
> > > Traceback (most recent call last):
> > >   File
> > >
> =
"C:\Python23\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",=

> > > line 310, in RunScript
> > >     exec codeObject in __main__.__dict__
> > >   File "D:\proj\myhdl-0.4\cosimulation\mti\test\test.py", line 17, =
in ?
> > >     def stimulus(a, b):
> > >   File "C:\Python23\Lib\site-packages\myhdl\_Cosimulation.py", =
line 71,
> > > in __init__
> > >     child_pid =3D self._child_pid =3D os.fork()
> > > AttributeError: 'module' object has no attribute 'fork'
> > >
> > > I queried the library reference of python, it DO mentioned that =
os.fork
> > > is only available in UNIX.
> > >
> > > So I guess MyHDL doesn't have the ability to co-sim with Verilog =
on
> > > windows currently. However, do you have any plan to support this =
on
> > > windows recently?
> >
> > Hi:
> >
> > In general, I would like MyHDL run on any Python platform.
> > I try to take advantage of Python's portability.
> > However, I only use Linux as a development platform myself,
> > and I don't have the possibility to test/maintain multiple
> > platforms. This is one area where I have to rely on outside
> > help.
> >
> > The closer one gets to the operating system, the more likely
> > it is that problems will appear. The way co-simulation is
> > currently set up, using fork to create new processes, is
> > one example. Note that "native" MyHDL shouldn't pose any
> > problem, and if it does, it should be possible to solve
> > it easily.
> >
> > For this concrete problem: I wasn't fully aware of the
> > fork issue, but I have done some investigations. It seems
> > indeed that this is not available on Windows, and cannot
> > even be emulated easily. From what I read it may be
> > availabe on NT, but even then it's not certain that Python
> > will support it.
> >
> > Your best bet, I think, is to compile Python under Cygwin
> > on Windows, instead of using the native Python. This should
> > give you fork as I understand it.
> >
> > This may be a reasonable solution, because I wonder what
> > Verilog simulator you are using? If it is Icarus, I believe
> > that the way it works on Windows is by using Cygwin anyway.
> >
> > Note: I never used Cygwin myself, but it seems to get good
> > press.
> >
> > Another solution, perhaps, would be one for me: using another
> > approach for co-simulation. It might be possible to use
> > threads instead of processes, and this should work on all
> > platforms (using Python's threading module).
> > I will need to investigate this further, and I have no idea
> > what problems I will encounter, so don't count on this
> > one anytime soon.
> >
> > Hope this helps,
> >
> > Jan
> >
> > --=20
> > Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> > Losbergenlaan 16, B-3010 Leuven, Belgium
> >     Python is fun, and now you can design hardware with it:
> >     http://jandecaluwe.com/Tools/MyHDL/Overview.html
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real =
users.
> > Discover which products truly live up to the hype. Start reading =
now.
> > http://productguide.itmanagersjournal.com/
>=20
> 

[myhdl-list] Re: error message of vpi_control, need help

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

Chun Lin Zhang wrote:

> Any other sugguestions?

Apparently something goes wrong with dynamic linking.
Below I will do some more guesses, but if it doesn't help,
please tar up all files you use in the process and add
an exact description of the operating system you are
using - all to minimize the guess work.

Are you sure that you use the correct compile/linking
procedure for shared libraries with ncsim?

One thing I could think of is that you need to use
the flag -export-dynamic with the linker when working
with dynamic libraries. 

The only example you have in the distribution is Icarus,
and Icarus and this may not help you much as Icarus
hides the details of the compile/link process for you.
Therefore, I have attached the makefile for linux that has
been used succesfully to cosimulate with the open
source Verilog simulator cver. That has more
raw details and may help you with compile flags.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: error message of vpi_control, need help

[Chun L. Z. <chu...@ho...>]

Jan/All,

I found the following part from the vpi_user.h of nc-sim,

/************* vpi_control() constants (added with 1364-2000) *************/
#define vpiStop                66  /* execute simulator's $stop */
#define vpiFinish              67  /* execute simulator's $finish */
#define vpiReset               68  /* execute simulator's $reset */
#define vpiSetInteractiveScope 69  /* set simulator's interactive scope */



XXTERN PLI_INT32  vpi_control         PROTO_PARAMS((PLI_INT32 operation,
                                                    ...));

And I didn't find any function with a name of vpi_sim_control from the
vpi_user.h,

Any other sugguestions?

Thanks

-Arnold

----- Original Message ----- 
From: "Jan Decaluwe" <ja...@ja...>
To: <myh...@li...>
Sent: Monday, December 20, 2004 9:02 PM
Subject: [myhdl-list] Re: error message of vpi_control, need help


> Arnold wrote:
> > Hi, all
> >
> > I was able to use myhdl as HVL to co-sim with verilog with nc-vlog
> > simulator.
> >
> > I got the following error message at the end of each simulation.
> >
> > _*/StopSimulation: No more events
> > ncsim: relocation error: ../etc/myhdl.so: undefined symbol:
vpi_control/*_
> >
> > Anybody can give me a clue how to fix it?
>
> Does it work correctly before the end of the simuation :-) ?
>
> Could you take a look in the vpi_user.h file that ncsim is using.
> The icarus version mentions that there is an alternative name,
> called vpi_sim_control for this function. Perhaps ncsim is
> using that name and not vpi_control?
>
> If you get it to work, it would be nice if you could
> comment on what you had to do and what changes you had
> to make.
>
> Thanks, Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>     Python is fun, and now you can design hardware with it:
>     http://jandecaluwe.com/Tools/MyHDL/Overview.html
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Re: error message of vpi_control, need help

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

Arnold wrote:
> Hi, all
>  
> I was able to use myhdl as HVL to co-sim with verilog with nc-vlog 
> simulator.
>  
> I got the following error message at the end of each simulation.
>  
> _*/StopSimulation: No more events
> ncsim: relocation error: ../etc/myhdl.so: undefined symbol: vpi_control/*_
>  
> Anybody can give me a clue how to fix it?

Does it work correctly before the end of the simuation :-) ?

Could you take a look in the vpi_user.h file that ncsim is using.
The icarus version mentions that there is an alternative name,
called vpi_sim_control for this function. Perhaps ncsim is
using that name and not vpi_control?

If you get it to work, it would be nice if you could
comment on what you had to do and what changes you had
to make.

Thanks, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] error message of vpi_control, need help

[Arnold <chu...@ho...>]

Hi, all

I was able to use myhdl as HVL to co-sim with verilog with nc-vlog =
simulator.

I got the following error message at the end of each simulation.=20

StopSimulation: No more events
ncsim: relocation error: ../etc/myhdl.so: undefined symbol: vpi_control

Anybody can give me a clue how to fix it?

Thanks

[myhdl-list] Re: myhdl on windows platform?

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

Arnold wrote:
> Jan,
> 
> Thank you for your quick reply.
> 
> Another question is about using cygwin to compile python on windows: can I
> use mingw32 to compile python instead of cygwin? If yes how can I achieve
> that.

I have no personal experience with either - so below
is just my impression from some Internet searches.

When you mention mingw, is that because Icarus Verilog
on windows seems to move in that direction and deprecate
the cygwin port?

From what I found it seems that building Python itself
with mingw is quite hard. I found an explanation, but it
seems so complex that you may want to avoid it when possible.
On the other hand, it seems that building Python with cygwin
shouldn't be harder than on a typical Unix box (on Linux,
my experience has been that it is trivial).

So it seems that your best bet is to use a cygwin Python.
As the simulator is a separate program, it should be
perfectly possible to use mingw for the simulator and
the VPI stuff provided by MyHDL, and co-simulate
in that way.

Hope this helps (and let us know if you get it to work, too!),

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: myhdl on windows platform?

[Arnold <chu...@ho...>]

Jan,

Thank you for your quick reply.

Another question is about using cygwin to compile python on windows: can I
use mingw32 to compile python instead of cygwin? If yes how can I achieve
that.

Thanks


"Jan Decaluwe" <ja...@ja...> wrote in message
news:41C...@ja......
> Chun Lin Zhang wrote:
> > Hi, all,
> >
> > I tried to use myhdl to co-simulate with verilog on windows platform
> > today. I got the following error messages.
> >
> > Traceback (most recent call last):
> >   File
> >
"C:\Python23\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",
> > line 310, in RunScript
> >     exec codeObject in __main__.__dict__
> >   File "D:\proj\myhdl-0.4\cosimulation\mti\test\test.py", line 17, in ?
> >     def stimulus(a, b):
> >   File "C:\Python23\Lib\site-packages\myhdl\_Cosimulation.py", line 71,
> > in __init__
> >     child_pid = self._child_pid = os.fork()
> > AttributeError: 'module' object has no attribute 'fork'
> >
> > I queried the library reference of python, it DO mentioned that os.fork
> > is only available in UNIX.
> >
> > So I guess MyHDL doesn't have the ability to co-sim with Verilog on
> > windows currently. However, do you have any plan to support this on
> > windows recently?
>
> Hi:
>
> In general, I would like MyHDL run on any Python platform.
> I try to take advantage of Python's portability.
> However, I only use Linux as a development platform myself,
> and I don't have the possibility to test/maintain multiple
> platforms. This is one area where I have to rely on outside
> help.
>
> The closer one gets to the operating system, the more likely
> it is that problems will appear. The way co-simulation is
> currently set up, using fork to create new processes, is
> one example. Note that "native" MyHDL shouldn't pose any
> problem, and if it does, it should be possible to solve
> it easily.
>
> For this concrete problem: I wasn't fully aware of the
> fork issue, but I have done some investigations. It seems
> indeed that this is not available on Windows, and cannot
> even be emulated easily. From what I read it may be
> availabe on NT, but even then it's not certain that Python
> will support it.
>
> Your best bet, I think, is to compile Python under Cygwin
> on Windows, instead of using the native Python. This should
> give you fork as I understand it.
>
> This may be a reasonable solution, because I wonder what
> Verilog simulator you are using? If it is Icarus, I believe
> that the way it works on Windows is by using Cygwin anyway.
>
> Note: I never used Cygwin myself, but it seems to get good
> press.
>
> Another solution, perhaps, would be one for me: using another
> approach for co-simulation. It might be possible to use
> threads instead of processes, and this should work on all
> platforms (using Python's threading module).
> I will need to investigate this further, and I have no idea
> what problems I will encounter, so don't count on this
> one anytime soon.
>
> Hope this helps,
>
> Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>     Python is fun, and now you can design hardware with it:
>     http://jandecaluwe.com/Tools/MyHDL/Overview.html
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/

[myhdl-list] Re: myhdl on windows platform?

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

Chun Lin Zhang wrote:
> Hi, all,
>  
> I tried to use myhdl to co-simulate with verilog on windows platform 
> today. I got the following error messages.
>  
> Traceback (most recent call last):
>   File 
> "C:\Python23\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", 
> line 310, in RunScript
>     exec codeObject in __main__.__dict__
>   File "D:\proj\myhdl-0.4\cosimulation\mti\test\test.py", line 17, in ?
>     def stimulus(a, b):
>   File "C:\Python23\Lib\site-packages\myhdl\_Cosimulation.py", line 71, 
> in __init__
>     child_pid = self._child_pid = os.fork()
> AttributeError: 'module' object has no attribute 'fork'
>  
> I queried the library reference of python, it DO mentioned that os.fork 
> is only available in UNIX.
>  
> So I guess MyHDL doesn't have the ability to co-sim with Verilog on 
> windows currently. However, do you have any plan to support this on 
> windows recently?

Hi:

In general, I would like MyHDL run on any Python platform.
I try to take advantage of Python's portability.
However, I only use Linux as a development platform myself,
and I don't have the possibility to test/maintain multiple
platforms. This is one area where I have to rely on outside
help.

The closer one gets to the operating system, the more likely
it is that problems will appear. The way co-simulation is
currently set up, using fork to create new processes, is
one example. Note that "native" MyHDL shouldn't pose any
problem, and if it does, it should be possible to solve
it easily.

For this concrete problem: I wasn't fully aware of the
fork issue, but I have done some investigations. It seems
indeed that this is not available on Windows, and cannot
even be emulated easily. From what I read it may be
availabe on NT, but even then it's not certain that Python
will support it.

Your best bet, I think, is to compile Python under Cygwin
on Windows, instead of using the native Python. This should
give you fork as I understand it.

This may be a reasonable solution, because I wonder what
Verilog simulator you are using? If it is Icarus, I believe
that the way it works on Windows is by using Cygwin anyway.

Note: I never used Cygwin myself, but it seems to get good
press.

Another solution, perhaps, would be one for me: using another
approach for co-simulation. It might be possible to use
threads instead of processes, and this should work on all
platforms (using Python's threading module).
I will need to investigate this further, and I have no idea
what problems I will encounter, so don't count on this
one anytime soon.

Hope this helps,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] myhdl on windows platform?

[Chun L. Z. <chu...@ho...>]

Hi, all,

I tried to use myhdl to co-simulate with verilog on windows platform =
today. I got the following error messages.

Traceback (most recent call last):
  File =
"C:\Python23\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",=
 line 310, in RunScript
    exec codeObject in __main__.__dict__
  File "D:\proj\myhdl-0.4\cosimulation\mti\test\test.py", line 17, in ?
    def stimulus(a, b):
  File "C:\Python23\Lib\site-packages\myhdl\_Cosimulation.py", line 71, =
in __init__
    child_pid =3D self._child_pid =3D os.fork()
AttributeError: 'module' object has no attribute 'fork'

I queried the library reference of python, it DO mentioned that os.fork =
is only available in UNIX.

So I guess MyHDL doesn't have the ability to co-sim with Verilog on =
windows currently. However, do you have any plan to support this on =
windows recently?

Thank you very much.

-ChunLin

[myhdl-list] MyHDL plans update

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

Hi all:

As I have just completed a full-time consultancy assignment,
I will have some more time to work on MyHDL in the near term.

One thing I'm working on is a maintenance release (0.4.1) which
should address all points that have been raised in the past months,
and fix the known bugs.

In terms of new features: I've come to the conclusion that a
link to modelsim Verilog and VHDL would be the best way to
increase the awareness and usefulness of MyHDL.

I ordered many modelsim licenses in a previous life :-( but
currently I have no access to modelsim. So I wonder if anyone
out there can help. In the ideal case, I would have ssh access
to a language neutral modelsim at the command line (GUI not
needed), with Verilog VPI and VHDL PLI support, and to the
VPI and PLI documentation, on a Linux (or Unix) platform.

Note that the free versions in a Xilinx webpack don't include
VPI and PLI support, so they are not helpful.

Obviously, the only thing I would do with the tool is
to develop an open sourced link to MyHDL, so the usage time
would be extremely limited.

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: always_comb / signal array

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

David Brochart wrote:
> Selon David Brochart <dav...@fr...>:
> 
> 
>>It seems that "always_comb" doesn"t work when an input is an array of
>>signals,
>>while it works fine with the "while 1 / yield" structure.
>>
>>David.

Sure.

MyHDL defines a number of "event" objects that you can "wait" on using
a yield statement, such as a delay, edges and also signals. (Waiting on
a signal is defined as waiting on a signal value change.) A list of
signals is *not* such an event object.

To specify the sensitivity "list", the syntax with the least amount
of overhead is convenient:

    yield a, b, c

As per the Python definition, this is equivalent to:

    yield (a, b, c)

that is, yielding a tuple.

Often, when a tuple is supported, it is trivial to support a list also,
and that is what MyHDL does. So it is in this indirect way that you
can use a list of signals (or other event objects) as a sensitivity list.

Remaining question: does this have applications? Well, I added list support
when I needed it during a real modelling project. Actually, the concept of
a "dynamic sensitivity list" is, I believe, a unique feature of MyHDL. You
can build lists (and tuples) dynamically, based on dynamic control info,
and use them as a sensitivity list that will work as expected.

I haven't document of advertized this feature though, because I don't yet
know how significant it is.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: always_comb / signal array

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

David Brochart wrote:
> Selon David Brochart <dav...@fr...>:
> 
> 
>>It seems that "always_comb" doesn"t work when an input is an array of
>>signals,
>>while it works fine with the "while 1 / yield" structure.
>>
>>David.
>>
> 
> 
> 
> Actually, according to previous threads I read, I am not sure if it should even
> work with the "while 1 / yield" structure, because generators only deal with
> signals, not lists of signals.
> Jan, could you clarify this point?

Sure.

MyHDL has a number of objects on which you can "wait" using a yield
statements, such as a delay, edges and also signals. (Waiting on
as signal is defined as waiting on a signal value change.)
A list of signals is *not* one of these objects.

To specify the sensitivity "list" in the yield clause, the syntax
with the smallest overhead is convenient:

    yield a, b, c, d

As per the Python definition, this is equivalent to:

    yield (a, b, c, d)

that is, yielding a tuple.

As often, when a tuple is supported, it is trivial to support a list
also, and that's what MyHDL does. So it is in this indirect way that
you can use a list of signals (or any other "event" object) as a
sensitivity list in the yield clause.

Remaining question: does all this have applications? Well, I added
list support for a real modelling project. In fact, the concept of
a "dynamic sensitivity list" is, I believe, a unique feature of
MyHDL. You can build your sensitivitly lists (and tuples) dynamically,
depending on dynamic control info, and it will all work as expected.
I haven't explicitly documented or advertized this feature though,
because I don't yet know how significant it actually is.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] co-sim with vcs or modelsim

[David B. <dav...@fr...>]

I don't know if there is a lot of documentation about it, but the code is
open-source (in myhdl-0.4/cosimulation/icarus)...

David.



Selon Chun Lin Zhang <chu...@ho...>:

> What is Selon? Where can I find the document for it?
> ----- Original Message -----
> From: "David Brochart" <dav...@fr...>
> To: <myh...@li...>
> Sent: Tuesday, November 23, 2004 8:33 PM
> Subject: Re: [myhdl-list] co-sim with vcs or modelsim
>
>
> Selon
>
> Chun Lin Zhang <chu...@ho...>:
>
> > Hi,
> >
> > Anybody can give me an example of co-sim myhdl with synopsys vcs or m=
entor
> > modelsim?
> >
> > Thanks
> >
> > -ChunLin
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real use=
rs.
> > Discover which products truly live up to the hype. Start reading now.
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
> ChunLin,
>
> I think only Icarus Verilog is supported for now.
>
> Regards,
>
> David.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users=
.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users=
.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] co-sim with vcs or modelsim

[Chun L. Z. <chu...@ho...>]

What is Selon? Where can I find the document for it?
----- Original Message ----- 
From: "David Brochart" <dav...@fr...>
To: <myh...@li...>
Sent: Tuesday, November 23, 2004 8:33 PM
Subject: Re: [myhdl-list] co-sim with vcs or modelsim


Selon

Chun Lin Zhang <chu...@ho...>:

> Hi,
>
> Anybody can give me an example of co-sim myhdl with synopsys vcs or mentor
> modelsim?
>
> Thanks
>
> -ChunLin
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


ChunLin,

I think only Icarus Verilog is supported for now.

Regards,

David.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] co-sim with vcs or modelsim

[David B. <dav...@fr...>]

Selon Chun Lin Zhang <chu...@ho...>:

> Hi,
>
> Anybody can give me an example of co-sim myhdl with synopsys vcs or men=
tor
> modelsim?
>
> Thanks
>
> -ChunLin
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users=
.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


ChunLin,

I think only Icarus Verilog is supported for now.

Regards,

David.

[myhdl-list] co-sim with vcs or modelsim

[Chun L. Z. <chu...@ho...>]

Hi,

Anybody can give me an example of co-sim myhdl with synopsys vcs or mentor
modelsim?

Thanks

-ChunLin

[myhdl-list] Re: always_comb / signal array

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

David Brochart wrote:

> It seems that "always_comb" doesn't work when an input is an array of signals,

Yep, always_comb is intended to emulate a similar "low level" facility
in SystemVerilog. It has to inspect the source to find out with signals are
used as inputs and which as outputs, and infer the sensitivity list
automagically. It does this by inspecting how a certain signal name
is used in the code.

To support more complex things likes arrays of signals, all kinds of
new complexities would have to be taken into account - inspecting indices
and slices to see which parts of the array are used as input. In the
general case (variable indices) this cannot even be decided.

So I think it will remain a low-level facility to describe combinatorial
logic based on input signals, as in Verilog.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: always_comb / signal array

[David B. <dav...@fr...>]

Selon David Brochart <dav...@fr...>:

> It seems that "always_comb" doesn"t work when an input is an array of
> signals,
> while it works fine with the "while 1 / yield" structure.
>
> David.
>


Actually, according to previous threads I read, I am not sure if it shoul=
d even
work with the "while 1 / yield" structure, because generators only deal w=
ith
signals, not lists of signals.
Jan, could you clarify this point?

David.

[myhdl-list] Re: VCD generation bug

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

David Brochart wrote:

> 

> Here is the relevant part we get in the VCD file:
> 
> $scope module test $end
> $var real 1 ! a $end
> $scope module dummy_i0 $end
> $var real 1 ! a $end
> $var real 1 " b $end
> $scope module b_i0 $end
> $var real 1 " a $end
> $upscope $end
> $upscope $end
> $upscope $end
> 
> The thing is that we have the same identifier for "a" in "test" and "a" in
> "dummy_i0", and also for "b" in "dummy_i0" and "a" in "b_i0", which is right
> because they are really the same signals. But somehow the version of GTKWAVE I
> run on Linux doesn't like it and doesn't display the waves properly. Which is
> strange because with another version of GTKWAVE on Solaris it works fine.

Right - my gtkwave 1.3.24 on my Linux (RH9)  has the same problem. As the evidence is
that the VCD file is OK, there must be some bug on at least some flavors of Linuxes.

I vaguely remember trying a 2.0 gtkwave version. I'm pretty sure it was OK with
that, so I stopped worrying about the issue and planned to upgrade asap to a
future stable release. Unfortunately, gtkwave 2.0 seems stuck in pre-releases :-(

> Maybe we should give a unique identifier for every signal even if some of the signals
> are actually the same?

Mm, and duplicating all tracing info for every hierarchical level in which the signal is
present? That seems a lot of work and overhead for a workaround for a bug
in another tool. (If required, the solution could be simply to use some older or
newer version for a particular platform.) 

Jan


-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: VCD generation bug

[David B. <dav...@fr...>]

Selon Jan Decaluwe <ja...@ja...>:

> David Brochart wrote:
> > There is a bug in the generation of the VCD file. In the following ex=
ample:
> >
> > ---------------------------------------------------------------------=
------
> >
> > from myhdl import intbv, Signal, Simulation, delay, traceSignals
> >
> > def gen(a):
> >     while 1:
> >         a.next =3D 0
> >         yield delay(10)
> >         a.next =3D 1
> >         yield delay(10)
> >
> > def dummy(a):
> >     b =3D Signal(intbv(0))
> >     b_i0 =3D gen(b)
> >     return b_i0
> >
> > def test():
> >     a =3D Signal(intbv(0))
> >     a_i0 =3D gen(a)
> >     dummy_i0 =3D dummy(a)
> >     return a_i0, dummy_i0
> >
> > test =3D traceSignals(test)
> > sim =3D Simulation(test)
> > sim.run(100)
> >
> > ---------------------------------------------------------------------=
------
> >
> > You can see in the generated VCD file that several signals have the s=
ame
> > identifier.
>
> There are 2 signals, so there should be two different identifiers,
> right? That's also what I see in the VCD definition area, so I'm not su=
re
> there's a problem here.
>
> > Also, signals in "a_i0" are not traced.
>
> Yes, there was a bug in _extractHierarchy.py. Attached the current vers=
ion
> that probably solves it. (As I had solved this already some time ago, I
> think it's about time I'll do a maintenance release...)
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>     Python is fun, and now you can design hardware with it:
>     http://jandecaluwe.com/Tools/MyHDL/Overview.html
>


Here is the relevant part we get in the VCD file:

$scope module test $end
$var real 1 ! a $end
$scope module dummy_i0 $end
$var real 1 ! a $end
$var real 1 " b $end
$scope module b_i0 $end
$var real 1 " a $end
$upscope $end
$upscope $end
$upscope $end

The thing is that we have the same identifier for "a" in "test" and "a" i=
n
"dummy_i0", and also for "b" in "dummy_i0" and "a" in "b_i0", which is ri=
ght
because they are really the same signals. But somehow the version of GTKW=
AVE I
run on Linux doesn't like it and doesn't display the waves properly. Whic=
h is
strange because with another version of GTKWAVE on Solaris it works fine.=
 Maybe
we should give a unique identifier for every signal even if some of the s=
ignals
are actually the same?

David.

[myhdl-list] Re: VCD generation bug

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

David Brochart wrote:
> There is a bug in the generation of the VCD file. In the following example:
> 
> ---------------------------------------------------------------------------
> 
> from myhdl import intbv, Signal, Simulation, delay, traceSignals
> 
> def gen(a):
>     while 1:
>         a.next = 0
>         yield delay(10)
>         a.next = 1
>         yield delay(10)
> 
> def dummy(a):
>     b = Signal(intbv(0))
>     b_i0 = gen(b)
>     return b_i0
> 
> def test():
>     a = Signal(intbv(0))
>     a_i0 = gen(a)
>     dummy_i0 = dummy(a)
>     return a_i0, dummy_i0
> 
> test = traceSignals(test)
> sim = Simulation(test)
> sim.run(100)
> 
> ---------------------------------------------------------------------------
> 
> You can see in the generated VCD file that several signals have the same
> identifier. 

There are 2 signals, so there should be two different identifiers,
right? That's also what I see in the VCD definition area, so I'm not sure 
there's a problem here.

> Also, signals in "a_i0" are not traced.

Yes, there was a bug in _extractHierarchy.py. Attached the current version
that probably solves it. (As I had solved this already some time ago, I
think it's about time I'll do a maintenance release...)

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] always_comb / signal array

[David B. <dav...@fr...>]

It seems that "always_comb" doesn't work when an input is an array of sig=
nals,
while it works fine with the "while 1 / yield" structure.

David.

[myhdl-list] Re: always_comb problem

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

David Brochart wrote:
> I think this is a good solution indeed, it would work for "always_comb" and
> "toVerilog".
> 
> Thanks,
> 
> David.
> 

The following code in the _SigNameVisitor class in the _always_comb.py file
detecs an 'if __debug__' template, and skips it:

    def visitIf(self, node):
        if len(node.tests) == 1 and not node.else_:
            test = node.tests[0][0]
            if isinstance(test, compiler.ast.Name) and \
               test.name == '__debug__':
                return # skip
        for n in node.getChildNodes():
            self.visit(n)

The complete patched file is attached. It's in my development tree,
but not yet in the Verilog conversion code.

Remarks:

- only a simple template with a single 'if __debug__' test is detected.
More complicated expressions, or if statements with elsifs or else's
are not considered. This might be confusing, but on the other hand
I don't see the usefulness of using the __debug__ variable in more
complex ways than in a single test.

- a more sophisticated method would be possible: check the value of
an arbitrary name (not just __debug__) to see if it is False. This
would permit to turn this variable on or off by user-controlled code.
This is possible but requires a name lookup in the scope of the
function. I'm thinking to implement this as a general solution.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] article in the Linux Journal

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

Dear all:

The november issue of the Linux Journal has an article
on MyHDL. In it, I have tried to explain the essence of
MyHDL (in somewhat less than 2800 words).

This has been a nice experience for me and I'd like to
thank Michael Baxter (technical editor of LJ) for inviting
me to write such an article.

You may want to check it out!

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html