myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] VCD viewer ?

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

Hi Jean,

Jean DEMARTINI wrote:
> Hi all,
> 
> For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
> Python and MyHDL works perfectly. But has anyone knowledge of a working 
> free VCD viewer onto Windows. Despite many effort, I've not succeded to 
> use GTKwave and Wavevcd from ISS (beta downloadable at www.iss-us.com) 
> does not recognize the VCD format generated by MyHDL (its is a drawback 
> of the ISS viewer as the VCD format generated by MyDHL is quite correct) .
> 
> Jean
> 
> 

Have you looked into GTKWave?

	http://www.cs.man.ac.uk/apt/tools/gtkwave/

I have not used it with MyHDL, so I cannot commend on that.

Here is a page that has a windows version available:

http://www.geocities.com/SiliconValley/Campus/3216/GTKWave/gtkwave-win32.html

The windows version is an older version, but still works fine. Actually 
I had recently a .vcd file that would work with the older version and 
not with one of the new 2.0 pre releases.

Hope that helps.

Guenter

[myhdl-list] VCD viewer ?

[Jean D. <jea...@wa...>]

Hi all,

For many reasons I've to use MyHDL on a Windows platform (XP SP2). 
Python and MyHDL works perfectly. But has anyone knowledge of a working 
free VCD viewer onto Windows. Despite many effort, I've not succeded to 
use GTKwave and Wavevcd from ISS (beta downloadable at www.iss-us.com) 
does not recognize the VCD format generated by MyHDL (its is a drawback 
of the ISS viewer as the VCD format generated by MyDHL is quite correct) .

Jean


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.6.0 - Release Date: 02/03/2005

[myhdl-list] Status + holiday

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

Hi all:

A quick note to let you know that you wont' hear from me
until March 14, because I'm on a skiing holiday.

The past weeks I worked on wiki stuff. I'm not satisfied
with the current solution (on python.org) but fascinated
by the idea. As I'm also not satisified with my current
web site, I plan to put everything on a freshly installed
wiki of my own. It cannot be a Python one (my web site
is on yahoo). After some searching, I selected
DokuWiki (in PHP). It's nice, small and clean, and has
some very nice features such as section edits. I did some
customization work, e.g. to support a sidebar.

The new site is not finished yet, but you can get an
idea by viewing the current status at:

    www.jandecaluwe.com/wiki

There may be issues - Feedback welcome. E.g. the
stylesheet works perfectly with Mozilla, but I'm not
sure about IE.

The idea would be that the MyHDL part would be
editable by any registered user.

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

Re: [myhdl-list] Re: range object

[Haitao Z. <ha...@gm...>]

On Thu, 03 Mar 2005 11:49:08 +0100, Jan Decaluwe <ja...@ja...> wrote:
> Haitao Zhang wrote:
> > Another nice to have :)
> >
> > In VHDL one could define a range type and define a constant with it,
> > so that one can associate a symbolic name say CTRL_FIELD with  7
> > DOWNTO 3, and then one can refer to register(CTRL_FIELD). In Verilog
> > one can probably get by with macro defines. However in Python the
> > native slicing is limited to integer arguments (?), so one has to
> > define two named constants instead of passing an indexing object.
> 
> This is not correct. Consider:
> 
> >>> from myhdl import intbv
> >>> a = intbv(0xffff)
> >>> CTRL_FIELD = slice(4, 2)
> >>> type(CTRL_FIELD)
> <type 'slice'>
> >>> a[CTRL_FIELD]
> intbv(3L)
> >>> a[CTRL_FIELD] = 0
> >>> hex(a)
> '0xFFF3L'
> 
> The slice object is not often used explicitly in Python code but
> probably deserves more attention. (Warning: toVerilog doesn't
> support his - as always, patches are welcome!).
> 

Thanks for the tip! This is exactly what I want for now. (Matlab
behaviour is probably an over kill unless one has no-contigous field,
which for hardware designer only happens under special circumstances).
I will see what I can do about toVerilog when I get that far.

Haitao

> > This feature is handy when one needs to define control register
> > fields. It allows one to define the named constants in one place.
> >
> > In Matlab one can index any vector with another vector. I don't see
> > why this shouldn't be doable in Python as well. Maybe just no need for
> > it, until the hardware designers come along? Is the simplest way to
> > overload __getslice__ to accept a tuple (defining range)?
> 
> (__getslice__ is deprecated, use __getitem__ instead. Look in
> the 0.4.1 code for intbv to see how slicing is implemented.)
> More than you probably need has been done by lots of people doing
> lots of work. Check out the Numeric Python extension for a Python
> with MatLab-like functionality. Also check SciPy. (Warning:
> there is a LOT of material to study.)
> 
> 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
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Re: range object

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

Haitao Zhang wrote:
> Another nice to have :)
> 
> In VHDL one could define a range type and define a constant with it,
> so that one can associate a symbolic name say CTRL_FIELD with  7
> DOWNTO 3, and then one can refer to register(CTRL_FIELD). In Verilog
> one can probably get by with macro defines. However in Python the
> native slicing is limited to integer arguments (?), so one has to
> define two named constants instead of passing an indexing object.

This is not correct. Consider:

>>> from myhdl import intbv
>>> a = intbv(0xffff)
>>> CTRL_FIELD = slice(4, 2)
>>> type(CTRL_FIELD)
<type 'slice'>
>>> a[CTRL_FIELD]
intbv(3L)
>>> a[CTRL_FIELD] = 0
>>> hex(a)
'0xFFF3L'

The slice object is not often used explicitly in Python code but
probably deserves more attention. (Warning: toVerilog doesn't
support his - as always, patches are welcome!).

> This feature is handy when one needs to define control register
> fields. It allows one to define the named constants in one place.
> 
> In Matlab one can index any vector with another vector. I don't see
> why this shouldn't be doable in Python as well. Maybe just no need for
> it, until the hardware designers come along? Is the simplest way to
> overload __getslice__ to accept a tuple (defining range)?

(__getslice__ is deprecated, use __getitem__ instead. Look in
the 0.4.1 code for intbv to see how slicing is implemented.)
More than you probably need has been done by lots of people doing
lots of work. Check out the Numeric Python extension for a Python
with MatLab-like functionality. Also check SciPy. (Warning:
there is a LOT of material to study.)

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] range object

[Haitao Z. <ha...@gm...>]

Another nice to have :)

In VHDL one could define a range type and define a constant with it,
so that one can associate a symbolic name say CTRL_FIELD with  7
DOWNTO 3, and then one can refer to register(CTRL_FIELD). In Verilog
one can probably get by with macro defines. However in Python the
native slicing is limited to integer arguments (?), so one has to
define two named constants instead of passing an indexing object.

This feature is handy when one needs to define control register
fields. It allows one to define the named constants in one place.

In Matlab one can index any vector with another vector. I don't see
why this shouldn't be doable in Python as well. Maybe just no need for
it, until the hardware designers come along? Is the simplest way to
overload __getslice__ to accept a tuple (defining range)?

I am not a Python expert so I will be happy to know if there is a way
to do it now in Python.

Haitao

[myhdl-list] Re: inference problem?

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

Haitao Zhang wrote:
> Thanks for the explaination. There seems to be a little more to it:
> toVerilog does not always flag different  port name and signal name as
> a problem (e.g. the q signal for the q3 port was fine). It actually
> seemed content to let most pass but somehow caught on to the
> particular example I gave. 

Haitao:

Nice debugging work! To explain what happens, consider the following:

>>> from myhdl import *
>>> q = Signal(0)
>>> def f(q3):
...     return q is q3
...
>>> f(q)
True

The point is that inside f, q and q3 can now be used interchangeably.
This is of course utterly confusing, but if you did write code
like that, MyHDL can still generate correct Verilog code! (ain't it great?)
It will choose one of the 2 names (q or q3) and use it consistently.
However, if it chooses the one different from the port name, toVerilog
will fail for the reason described in an earlier mail.

Currently, the name choice is arbitrary, based on the occurence of
the names/Signals in a dictionary. (Warning: seemingly unrelated
statements can influence this - However: when the conversion
works, it should be correct :-)) What it should do is always use
the port name (as per the feedback I received, and I agree.)

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] A question of philosophy?

[Haitao Z. <ha...@gm...>]

It seems to me there are three different demands put on HDLs: hardware
description itself is mostly declarative (in the sense they describe
structural relationship that can not directly execute on a sequential
program semantics); but it also has a time axis to it (even though
hardware can only be structural some times it is more convenient to be
able to pretend that we can specify it by defining what we want along
the time axis); AND at times we want to add a imperative component to
it: think of parameter evaluation, conditional generation, or even
like myhdl that natively supports simulation. There is tension in
language design if one wants to do all three well. The "normal" HDLs
lack a strong support for the last aspect, while Python is a
inherently sequential language and makes the first (structural) aspect
harder to carry out (?) without some contortion along the way (the
tension between declaration, partial eval, and evaluation). I don't
know if there is a good solution, but I wonder if Jan or anyone else
has given this question some thoughts.

(I am not a CAD or software engineer so pardon me if I butchered the
terminologies here.)

Haitao

[myhdl-list] syntax sugar?

[Haitao Z. <ha...@gm...>]

One thing I miss in the MyHDL idiom is the simple concurrent statement:
a <= expr 
or
assign a = expr

In myhdl one has to do
def assign_blk():
    while 1:
        yield signals in expr
        a.next = expr

or:
def assign_blk():
    def blk():
        a.next = expr
    return always_comb(blk)

AND one needs to keep track of all the generators:
assign_blk_list.append(assign_blk())

Now of course the regular HDL statement and the myhdl are semantically
equivalent, so you may call the regular concurrent assignment simple
syntax sugar. But it does hide the details from the user and it is a
very good abstraction that can be consistently understood. In a real
design when one does a fair amount of concurrent assignment the tedium
of using the myhdl syntax could quickly add up.

I understand since myhdl is embedded in pure python it has to use all
the defs to control the evaluation and the partial evaluation. One
possibility is to add syntax sugar like the following:
assign("a", "expr")

And then hide the details in the assign function. One can try to
dynamically generate the necessary code in the assign function and
call exec, however this does not work with the inspect function used
by toVerilog and always_comb. I am not up to the task of adding this
capability natively to the myhdl codebase.  Another way to get around
it may be to use code generation tools to transform the short hand.
However with the tools I looked up on the web (Cog, Cheetah etc) the
solution seems to be worse than the problem.

Another nice to have (syntax sugar) is to be able to simply say:
clocked(
<code block>
)

instead of
def clocked_blk():
    while 1:
        yield posedge(clk)
        <code block>

clocked_blk_list.append(clocked_blk())

Comes in handy for all synchronous designs, but does not make as much
difference as the cocurrent assignment. This one is no longer python
semantics unless we put all <code block> in a '''string''', but that
would mess up the code highlighting in my editor :(

Haitao

Re: [myhdl-list] Re: inference problem?

[Haitao Z. <ha...@gm...>]

Thanks for the explaination. There seems to be a little more to it:
toVerilog does not always flag different  port name and signal name as
a problem (e.g. the q signal for the q3 port was fine). It actually
seemed content to let most pass but somehow caught on to the
particular example I gave. Even though the signals are defined in a
single statement (therefore positional wise identical). Moving the
function def around also does not make a difference.

I agree with Dave in the subsequent email that one should use port
names (as it currently seems to do correctly most of the times) for 
Verilog generation.

Haitao

On Wed, 02 Mar 2005 11:48:44 +0100, Jan Decaluwe <ja...@ja...> wrote:
> Haitao Zhang wrote:
> > More challenge if you are still there:). This time I did simulate (but
> > I haven't stepped throuigh toVerilog failure yet). The code simulates
> > (here q2 has been defined globally):
> >
> > def reg_dq3(clk,d0,q3):
> >     reg1=reg_dq2(clk,d0,q2)
> >     reg2=reg_dq(clk,q2,q3)
> >     return reg1,reg2
> >
> > If I do toVerilog like this:
> > my_delay2=toVerilog(reg_dq3, clk, d0, q)
> >
> > it works. But if I change it to:
> > my_delay2=toVerilog(reg_dq3, clk, cntr_out, q)
> >
> > toVerilog complains about shadowing. What is shadowing?
> 
> Shadowing refers to the following situation:
> 
> def top(a, b, c, ...):
>    a = Signal(...)
>    ...
> 
> In other words, an internal Signal "shadows" a port with the
> a same name. This is perfectly valid (though meaningless) in
> Python, but cannot be converted into meaningful Verilog. MyHDL
> attempts to detect this, and raises a error.
> 
> What you describe is something else:
> 
> a1 = Signal(a, b, c, ...):
> 
> def top(a, b, c):
>     ...
> 
> instance = toVerilog(top, a1, b, c, ...)
> 
> In other words, you use a different name for the Signal
> than for the port at instantiation time. This is perfectly
> valid Python and MyHDL, and could be converted into
> meaningful Verilog. However, the current port name test
> is too severe and detects this situation also, apart
> from the real "shadowing" case.
> 
> Conclusion: in any case, the current error is misleading
> for the situation you encounter. This has to be solved.
> There are 3 options, and I ask for feedback:
> 
> - top level signal names should be the same as their
> corresponding top level port names (as currently), and
> a clear error should be raised in the other case.
> - in the generated Verilog, the MyHDL port names should be
> used.
> - in the generated Verilog, the actual MyHDL signal names
> should be used. In this case, the Verilog module interface
> will use different port names than the MyHDL function.
> 
> 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
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Re: inference problem?

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

> Conclusion: in any case, the current error is misleading
> for the situation you encounter. This has to be solved.
> There are 3 options, and I ask for feedback:
>
> - top level signal names should be the same as their
> corresponding top level port names (as currently), and
> a clear error should be raised in the other case.

It means we need to change the Python code from a pure simulation use to =
a
Verilog generation use if top level signal names and top level port names=
 were
different. It would be nice not to have to do this.

> - in the generated Verilog, the MyHDL port names should be
> used.

I think it is what we expect it to do.

> - in the generated Verilog, the actual MyHDL signal names
> should be used. In this case, the Verilog module interface
> will use different port names than the MyHDL function.

I think this would lead to confusion between the MyHDL description and th=
e
Verilog description.



Regards,

David.

[myhdl-list] Re: inference problem?

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

Haitao Zhang wrote:
> More challenge if you are still there:). This time I did simulate (but
> I haven't stepped throuigh toVerilog failure yet). The code simulates
> (here q2 has been defined globally):
> 
> def reg_dq3(clk,d0,q3):
>     reg1=reg_dq2(clk,d0,q2)
>     reg2=reg_dq(clk,q2,q3)
>     return reg1,reg2
> 
> If I do toVerilog like this:
> my_delay2=toVerilog(reg_dq3, clk, d0, q)
> 
> it works. But if I change it to:
> my_delay2=toVerilog(reg_dq3, clk, cntr_out, q)
> 
> toVerilog complains about shadowing. What is shadowing?

Shadowing refers to the following situation:

def top(a, b, c, ...):
   a = Signal(...)
   ...

In other words, an internal Signal "shadows" a port with the
a same name. This is perfectly valid (though meaningless) in
Python, but cannot be converted into meaningful Verilog. MyHDL
attempts to detect this, and raises a error.

What you describe is something else:

a1 = Signal(a, b, c, ...):

def top(a, b, c):
    ...

instance = toVerilog(top, a1, b, c, ...)

In other words, you use a different name for the Signal
than for the port at instantiation time. This is perfectly
valid Python and MyHDL, and could be converted into
meaningful Verilog. However, the current port name test
is too severe and detects this situation also, apart
from the real "shadowing" case.

Conclusion: in any case, the current error is misleading
for the situation you encounter. This has to be solved.
There are 3 options, and I ask for feedback:

- top level signal names should be the same as their
corresponding top level port names (as currently), and
a clear error should be raised in the other case.
- in the generated Verilog, the MyHDL port names should be
used.
- in the generated Verilog, the actual MyHDL signal names
should be used. In this case, the Verilog module interface
will use different port names than the MyHDL function.

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

Re: [myhdl-list] Re: inference problem?

[Haitao Z. <ha...@gm...>]

More challenge if you are still there:). This time I did simulate (but
I haven't stepped throuigh toVerilog failure yet). The code simulates
(here q2 has been defined globally):

def reg_dq3(clk,d0,q3):
    reg1=reg_dq2(clk,d0,q2)
    reg2=reg_dq(clk,q2,q3)
    return reg1,reg2

If I do toVerilog like this:
my_delay2=toVerilog(reg_dq3, clk, d0, q)

it works. But if I change it to:
my_delay2=toVerilog(reg_dq3, clk, cntr_out, q)

toVerilog complains about shadowing. What is shadowing? Here is the trace:

cntr_out
d0
Traceback (most recent call last):
  File "./myhdl_test.py", line 20, in ?
    my_delay2=toVerilog(reg_dq3, clk, cntr_out, q)
  File "/usr/local/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py",
line 92, in toVerilog
    _writeModuleHeader(vfile, intf)
  File "/usr/local/lib/python2.4/site-packages/myhdl/_toVerilog/_convert.py",
line 122, in _writeModuleHeader
    raise ToVerilogError(_error.ShadowingSignal, portname)
myhdl.ToVerilogError: Port is shadowed by internal signal: d0


On Sat, 26 Feb 2005 14:13:52 -0800, Haitao Zhang <ha...@gm...> wrote:
> Jan,
> Thanks! You spotted the problem!
> 
> > Yes, I infer that you didn't simulate this :-)
> 
> Right I didn't on this one. I want to build a model of my project in
> myhdl and before doing it I  wanted to be sure that it can be
> converted so I am experimenting a bit to see how things go. I did try
> some other sims just not thought of doing it here. As you can tell I
> am new to myhdl, and also pretty new to Python. Thanks for all the
> good advice.
> 
> Haitao

Re: [myhdl-list] Re: inference problem?

[Haitao Z. <ha...@gm...>]

Jan,
Thanks! You spotted the problem!

> Yes, I infer that you didn't simulate this :-)

Right I didn't on this one. I want to build a model of my project in
myhdl and before doing it I  wanted to be sure that it can be
converted so I am experimenting a bit to see how things go. I did try
some other sims just not thought of doing it here. As you can tell I
am new to myhdl, and also pretty new to Python. Thanks for all the
good advice.

Haitao

> 
> Here's the problem: your intention is that q1 is a Signal, but it isn't.
> In fact, in MyHDL:
> 
>    q1 = Signal(intbv(0))[n:]
> 
> is equivalent to:
> 
>    q1 = Signal(intbv(0)).val[n:]
> 
> that is, you get a slice of the current underlying value, which is an
> intbv and not a signal.
> 
> What you want is:
> 
>    q1 = Signal(intbv(0)[n:])
> 
> In this case, you get a signal with an intbv (with a defined bit width)
> as its underlying value.
> 
> The reason why conversion currently behaves like it does has to do
> with namespace lookups. Perhaps more could be done to detect flaws,
> BUT in a Python context this is an upfront battle. You really should
> use the run-time (= simulation) to detect errors. I have written
> about this before:
> 
> (from the manual, section 6.5.1)
> """
> In the Python philosophy, the run-time rules. The Python compiler
> doesn't attempt to detect a lot of errors beyond syntax errors, which
> given Python's ultra-dynamic nature would be an almost impossible task
> anyway. To verify a Python program, one should run it, preferably
> using unit testing to verify each feature.
> 
> The same philosophy should be used when converting a MyHDL description
> to Verilog: make sure the simulation runs fine first. Although the
> converter checks many things and attempts to issue clear error
> messages, there is no guarantee that it does a meaningful job unless
> the simulation runs fine.
> """
> 
> In other words, if the simulation works fine, my goal is to guarantee
> that the conversion (if it succeeds) is correct. Otherwise, all bets
> are off (even if conversion succeeds).
> 
> Note that in this case, a trivial test bench would detect the error,
> as q1 in your code cannot have a next attribute.
> 
> Miscellaneous remark: please don't use "private" attributes such as
> _nrbits. An intbv supports the 'len' function (which returns 0 for
> undefined bit widths.)
> 
> 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
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Re: toVerilog fails interactively

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

Haitao Zhang wrote:
> This may be common knowledge but I may as well post it in case someone
> else run into similiar problem:
> 
> toVerilog tries to find the instance name of what it is assigned to,
> i.e. the lname in the following expression:
>            lname = toVerilog(...)
> It does this by inspecting the source file. When run interactively
> some of the functions it calls fails because it can't get the info
> from stdin. When running from a file (either a standalone script or
> through execfile) it works fine.
> 
> Haitao

Exactly right!

This issue had been reported before, but in a private e-mail
exchange. (Thanks for using the newsgroup to report issues -
I encourage everyone to do the same.)

The error message currently comes from the inspect method -
MyHDL doesn't check anything so this this could be improved.
Patches welcome!

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: inference problem?

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

Haitao Zhang wrote:
> I could not figure out why the following code could not generate
> correct Verilog code (the intermediate q1 is missing):
> 
> def reg_dq(clk,d,q):
>     def proc():
>         while 1:
>             yield posedge(clk)
>             q.next=d
>     return proc()
>     
> def reg_dq2(clk,d,q):
>     if d._nrbits:
>         q1=Signal(intbv(0))[d._nrbits:]
>     else:
>         q1=Signal(intbv(0))
>     def proc():
>         while 1:
>             yield posedge(clk)
>             q.next=q1
>             q1.next=d
>     return proc()        
> #    reg1=reg_dq(clk,d,q1)
> #    reg2=reg_dq(clk,q1,q)
> #    return reg1, reg2
> 
> I fail to see the difference between this and the provided examples.
> This is just a simple try to generate a delay of 2. The commented out
> code didn't work either. I get two assignments to q instead.
> 
> Thanks for any help. 

Yes, I infer that you didn't simulate this :-)

Here's the problem: your intention is that q1 is a Signal, but it isn't.
In fact, in MyHDL:

   q1 = Signal(intbv(0))[n:]

is equivalent to:

   q1 = Signal(intbv(0)).val[n:]

that is, you get a slice of the current underlying value, which is an
intbv and not a signal.

What you want is:

   q1 = Signal(intbv(0)[n:])

In this case, you get a signal with an intbv (with a defined bit width)
as its underlying value.

The reason why conversion currently behaves like it does has to do
with namespace lookups. Perhaps more could be done to detect flaws,
BUT in a Python context this is an upfront battle. You really should
use the run-time (= simulation) to detect errors. I have written
about this before:

(from the manual, section 6.5.1)
"""
In the Python philosophy, the run-time rules. The Python compiler
doesn't attempt to detect a lot of errors beyond syntax errors, which
given Python's ultra-dynamic nature would be an almost impossible task
anyway. To verify a Python program, one should run it, preferably
using unit testing to verify each feature.

The same philosophy should be used when converting a MyHDL description
to Verilog: make sure the simulation runs fine first. Although the
converter checks many things and attempts to issue clear error
messages, there is no guarantee that it does a meaningful job unless
the simulation runs fine.
"""

In other words, if the simulation works fine, my goal is to guarantee
that the conversion (if it succeeds) is correct. Otherwise, all bets
are off (even if conversion succeeds).

Note that in this case, a trivial test bench would detect the error,
as q1 in your code cannot have a next attribute.

Miscellaneous remark: please don't use "private" attributes such as
_nrbits. An intbv supports the 'len' function (which returns 0 for
undefined bit widths.)

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] toVerilog fails interactively

[Haitao Z. <ha...@gm...>]

This may be common knowledge but I may as well post it in case someone
else run into similiar problem:

toVerilog tries to find the instance name of what it is assigned to,
i.e. the lname in the following expression:
           lname = toVerilog(...)
It does this by inspecting the source file. When run interactively
some of the functions it calls fails because it can't get the info
from stdin. When running from a file (either a standalone script or
through execfile) it works fine.

Haitao

[myhdl-list] inference problem?

[Haitao Z. <ha...@gm...>]

I could not figure out why the following code could not generate
correct Verilog code (the intermediate q1 is missing):

def reg_dq(clk,d,q):
    def proc():
        while 1:
            yield posedge(clk)
            q.next=d
    return proc()
    
def reg_dq2(clk,d,q):
    if d._nrbits:
        q1=Signal(intbv(0))[d._nrbits:]
    else:
        q1=Signal(intbv(0))
    def proc():
        while 1:
            yield posedge(clk)
            q.next=q1
            q1.next=d
    return proc()        
#    reg1=reg_dq(clk,d,q1)
#    reg2=reg_dq(clk,q1,q)
#    return reg1, reg2

I fail to see the difference between this and the provided examples.
This is just a simple try to generate a delay of 2. The commented out
code didn't work either. I get two assignments to q instead.

Thanks for any help. 

Haitao

[myhdl-list] ANNOUNCE: MyHDL Wiki

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

Hi:

There is now a MyHDL Wiki. Thanks to David MacQuigg for the suggestion.

A Wiki is a web site to which you can contribute directly, with no other
tools than your browser. The idea is to lower the threshold for adding
valuable documentation and information. You can find it here:

    http://www.python.org/moin/MyHDL

Currently, there are two subpages:

* /QuestionsAndAnswers
Did you ever resolve a MyHDL issue and thought that it might be
useful info for others? Consider adding it here.

* /Projects
A list of projects using MyHDL. If you use MyHDL, consider
adding a line on what you are doing here (ideally with
a link to a project page, but that's not required.)

Of course, if you prefer suggesting edits instead of doing
them yourself, that is perfectly fine too.

Note: access, especially edits, seems quite slow at this moment.
Hopefully this is a temporary problem.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium

[myhdl-list] Re: Opencores project

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

David Brochart wrote:
> All,
> 
> I have posted a project on Opencores. It is a MyHDL model of a turbo decoder,
> still at an early stage of development. You might want to check it out at:
> http://www.opencores.org/projects/turbocodes/

Thanks for your efforts - I will definitely check this out further!

I believe that real, relevant projects such as this one are the ideal way
to increase awareness and usefulness of MyHDL. I would encourage everybody
to suggest potential projects, ideally in a "hot" domain with
commercial relevance. At some point I would like to do such a project
myself also.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium

[myhdl-list] Opencores project

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

All,

I have posted a project on Opencores. It is a MyHDL model of a turbo deco=
der,
still at an early stage of development. You might want to check it out at=
:
http://www.opencores.org/projects/turbocodes/

Regards,

David.

[myhdl-list] Re: article in the Linux Journal

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

Jan Decaluwe wrote:
> 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).

An update on this.

The article is available on-line but access used
to be restricted. Apparently the restrictions have
been removed, and you can read it here:

    http://www.linuxjournal.com/article/7542

I have also added the link on my web site.

Greetings,

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: Interfaces to Proprietary Tools

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

David MacQuigg wrote:
> 
> On Dec 10th you wrote:
> 
> 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.
> 
> 
> At 05:59 PM 1/11/2005 +0100, you wrote:
> 
>> ... I believe demonstrated links with
>> commercial simulators are required to raise the awareness about MyHDL
>> as a viable commercial application.
> 
> 
> I was disappointed to see no response.  I believe this is due to the 
> tight restrictions vendors put on their proprietary tools.  For example, 
> I had difficulty getting access to the Cadence tools just to teach a 
> course at U of A.  Big companies are the most difficult.  Not only are 
> they more bureaucratic, but they may also consider use of their tools in 
> an open-source environment ( even with a fully paid license ) to be a 
> threat to their proprietary environments.  They have to weigh what they 
> gain by forcing customers to purchase their environments along with 
> their simulators, against what they lose by not allowing their 
> simulators to be used in competitive environments.
> 
> Have you tried contacting any of the simulator vendors directly?  I 
> would think that any but the biggest would see a net benefit in allowing 
> their simulator to be used with MyHDL.  I would think Cadence would see 
> a net gain in encouraging the use of NCSIM with other environments.

I haven't contacted them, because I am very sceptical, for the reasons you
list and from my own experience. The only really productive collaboration I
had with an EDA vendor in my previous design services company, was in
the early 90s with Synopsys, when they were still a small company. That
changed quickly as soon as they became wildly successful :-(

At one time we had a simple question for modelsim, which is still
relevant today (e.g. for MyHDL): whether it was permitted to open-source
a c module written using their proprietary procedural interface to their
VHDL simulator. We were a small company, but we did have 10+ modelsim
licenses. However, they simply never bothered to answer, no matter how
many times we insisted. (If anyone knows the answer, please tell me.
Note that I assume that there is no similar issue with the Verilog VPI,
as that is a standard. A similar standard for VHDL was once in the
making, but I don't know its status.)

> An alternative to working directly with the simulator vendor might be to 
> go to a big customer of that vendor, and show them they will benefit 
> from using MyHDL with the licensed simulators they already have.  They 
> will have the clout with the vendor to insist on cooperation.

Note that we wouldn't even need any technical cooperation, possibly
only on legal matters (see above, in the case of proprietary interfaces.)
This is the way I can see it happen. In fact, I'm making some progress
and there is a chance that I will get access to modelsim Verilog and
VHDL through an enlightened customer.

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] Interfaces to Proprietary Tools

[David M. <dm...@ga...>]

On Dec 10th you wrote:
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.

At 05:59 PM 1/11/2005 +0100, you wrote:
>... I believe demonstrated links with
>commercial simulators are required to raise the awareness about MyHDL
>as a viable commercial application.

I was disappointed to see no response.  I believe this is due to the tight 
restrictions vendors put on their proprietary tools.  For example, I had 
difficulty getting access to the Cadence tools just to teach a course at U 
of A.  Big companies are the most difficult.  Not only are they more 
bureaucratic, but they may also consider use of their tools in an 
open-source environment ( even with a fully paid license ) to be a threat 
to their proprietary environments.  They have to weigh what they gain by 
forcing customers to purchase their environments along with their 
simulators, against what they lose by not allowing their simulators to be 
used in competitive environments.

Have you tried contacting any of the simulator vendors directly?  I would 
think that any but the biggest would see a net benefit in allowing their 
simulator to be used with MyHDL.  I would think Cadence would see a net 
gain in encouraging the use of NCSIM with other environments.

An alternative to working directly with the simulator vendor might be to go 
to a big customer of that vendor, and show them they will benefit from 
using MyHDL with the licensed simulators they already have.  They will have 
the clout with the vendor to insist on cooperation.  Big companies spend a 
lot developing in-house scripts and even their own environments.  Then they 
realize that maintaining these environments is a never-ending and 
ever-growing expense.  At that point, it may be possible to convince them 
that supporting an open-source environment is advantageous.

This is the way email was finally freed from the clutches of 
CompuServe.  The demands from their own customers finally overwhelmed their 
desire ( fantasy ) to monopolize email, and suddenly all the "technical 
problems" disappeared.

-- Dave

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

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

Chun Lin Zhang wrote:
> Jan,
> 
> Thank you very much for your kindly help. I resolved the problem finally by
> upgrading my simulator from Cadence ldv4.1 to ldv5.1. The problem is gone.

So apparently you got it to work with a Cadence simulator - good news.

It would be nice and very useful to share some more details, such as:

- which simulator
- did you have to make changes to the vpi c module code?
- a Makefile perhaps?
- example simulator call
- whether you or your employer agree to publish this info, e.g.
  on comp.lang.verilog and in a future version of the MyHDL manual

The last point is there because I believe demonstrated links with
commercial simulators are required to raise the awareness about MyHDL
as a viable commercial application.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium