myhdl-list — Mailing list for discussions on MyHDL

[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

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

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

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.

Rgds

-Arnold

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


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


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


> # could add to CFLAGS to turn on warnings if you are using gcc
> WARNS=-Wall
>
> # change this path to point to the pli include files directory for cver
> INCS=-I$(HOME)/gplcver-1.10f.src/pli_incs
> # maybe want -O<something> and/or -g
> CFLAGS= -fPIC -Wall -g $(INCS)
> LFLAGS= -G -shared -export-dynamic
>
> # change to your compiler
> CC=gcc
>
> all: myhdl_vpi.so
>
> myhdl_vpi.o: myhdl_vpi.c
> $(CC) $(CFLAGS) -c myhdl_vpi.c
>
> # make rules for dynamic libaries
> myhdl_vpi.so: myhdl_vpi.o
> $(LD) $(LFLAGS) myhdl_vpi.o -o myhdl_vpi.so
>
>

[myhdl-list] Re: Verilog Generation issue - fixed signals

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

Jan Decaluwe wrote:
> Frank Palazzolo wrote:
> 
>> So - is it possible to define constant signals within the heirarchy in 
>> general?  I haven't been able to figure out how.  This is actually 
>> pretty ugly, considering that I'd like generic modules at the bottom, 
>> and I'd like to "hardcode" certain parameters on chip, with no 
>> external signals for them outside the chip.
> 

> Another way would be to use assign statements - all synthesis tools
> should understand those.

Follow-up:

In MyHDL 0.4.1, constant signals are implemented using assign
statements. Also, such "undriven" signals now generate a
warning, but no longer an error.

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

Follow-up:

In MyHDL 0.4.1, this has been implemented.

Both for always_comb and for verilog conversion, code that is embedded in
a single 'if __debug__' statement is ignored.

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?

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

Chun Lin Zhang wrote:
> 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.

Thanks for your efforts.

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

It may mean that we are almost there. I am prepared to debug it further,
but as I will describe below, I will need your help. I will leave it to
you to decide whether you want to continue the debug process.

In the chapter on co-simulation of the manual, you will find the
following section:

"""
\subsubsection{Interrupted system calls \label{cosim-impl-syscalls}}

The PLI module uses \code{read} and \code{write} system calls to
communicate between the co-simulators. The implementation assumes that
these calls are restarted automatically by the operating system when
interrupted. This is apparently what happens on my Linux box and on
other operating systems I have used before.

I know how to handle non-restarted interrupted system calls, but I
cannot test the code! Also, I don't know whether this is still a
relevant issue with modern operating systems. So I left it
at that for the moment, and added assertions that should trigger
when this situation occurs.

Whenever an assertion fires in the PLI module, let me
know. The same holds for Python exceptions that you cannot
easily explain.
"""

This seems to correspond exactly with what you are describing.
Solving it would essentially mean that I need to adapt the C code
and probably also the Python code at the other side, so that
system calls (read and write) are restarted when they have been
interrupted. Again, I know how to do this (I think) but the
problem is that I can not test this because it doesn't happen
on my platform. So here's where I would need your help in
debugging.

Before proceeding, the best would be to verify whether this is
really the problem. In the C code, you can add code like the
following immediately after n has been set by a write or a read
(and before the assert statements) (untested code):

#include <errno.h> /* to access the errno variable */
....

....
n = read(....) /* or n = write(.....) */
....
if (n<0) {
    fprintf(stderr, "Error num %d: %s", errno, strerror(errno));
}

This should print detailed error information.

Regards,

Jan

>  
> 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
> # Loading c:\Modeltech_6.0a\win32/novas.dll
> # Loading h:\mti\myhdl.dll
> # //  ModelSim SE 6.0a Sep 24 2004
> # //
> # //  Copyright Mentor Graphics Corporation 2004
> # //              All Rights Reserved.
> # //
> # //  THIS WORK CONTAINS TRADE SECRET AND
> # //  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
> 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 = Cosimulation("vsim -pli h:\mti\myhdl.dll -c tb -do sim.do", 
> a=a, b=b
> , c=c)
>   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... 
> <mailto:chu...@ho...>> wrote in message news:...
>  > 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... <mailto: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/
>  >
>  >


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