myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Documentation for 0.6

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

I've completed a full pass on the manual for 0.6:

     http://www.myhdl.org/doc/dev/0.6/

The chapter on Conversion has been completely rewritten
to accomodate for VHDL. I've put the examples in a
separate chapter. I've also used another stylesheet
that I like more.

Feedback is very welcome, now is your chance to improve
the manual! All changes have been pushed to the repository.
To build it, you will need the brand new Sphinx 0.5.
We're bleeding edge as always :-)

I'll use the coming 2 weeks to proofread, spell-check,
finetune, and handle possible feedback. After that,
we're ready for a release.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] fpgaz nm

[Christopher L. F. <cf...@uc...>]

Newell Jensen wrote:
> I think I have it figured out.  It looks like the default time scale 
> is in nanoseconds.  I may be wrong but I just replaced the 10*t10NS 
> with 10.
>
Here is the original contents of the timebase

----------------------------
#
# Definitions for MyHDL simulation time steps.
#
# These are useful to help relate the simulation back to
# actual time.  Example delay(tNS).  Note this does have some
# issues that the max value delay() excepts is ??
#

tPS       = 0
tNS       = 0
t10NS     = 1
tUS       = 100 * tNS
tMS       = 1000 * tUS
tSec      = 1000 * tMS
tUnitTime = t10NS

# Initialize a "time" step counter
ttime     = 0
--------------------------------

You had the basic idea.  This is what I did way back then, when I was
first playing with MyHDL.  I haven't thought about it for awhile but I
bet there is away to get the simulation timestamp (current step)?

Re: [myhdl-list] fpgaz nm

[Christopher L. F. <cf...@uc...>]

Newell Jensen wrote:
> I think I have it figured out.  It looks like the default time scale 
> is in nanoseconds.  I may be wrong but I just replaced the 10*t10NS 
> with 10.
>
Here is the original contents of the timebase

----------------------------
#
# Definitions for MyHDL simulation time steps.
#
# These are useful to help relate the simulation back to
# actual time.  Example delay(tNS).  Note this does have some
# issues that the max value delay() excepts is ??
#

tPS       = 0
tNS       = 0
t10NS     = 1
tUS       = 100 * tNS
tMS       = 1000 * tUS
tSec      = 1000 * tMS
tUnitTime = t10NS

# Initialize a "time" step counter
ttime     = 0
--------------------------------

You had the basic idea.  This is what I did way back then, when I was
first playing with MyHDL.  I haven't thought about it for awhile but I
bet there is away to get the simulation timestamp (current step)?

[myhdl-list] fpgaz nm

[Newell J. <pil...@gm...>]

I think I have it figured out.  It looks like the default time scale is in
nanoseconds.  I may be wrong but I just replaced the 10*t10NS with 10.

-- 
Newell

http://www.gempillar.com
Before enlightenment: chop wood, carry water
After enlightenment: code, build circuits

[myhdl-list] timebase module from fpgaz demo

[Newell J. <pil...@gm...>]

Hello,

I am new to MyHDL for the most part.
I was messing around with MyHDL and was going through the tutorial on fpgaz.
Does anyone know where to get the timebase module (in the testbench) from:

http://fpgaz.com/wiki/doku.php?id=fpgaz:usbp:mhdl_example

Or did someone create this on their own?

I need the definition for the t10NS that is being passed to delay.
I am assuming this is 10 nanoseconds and if this is right, if anyone knows
how to get 10 nanoseconds in Python please tell because I am unsure.

Thanks,

-- 
Newell

http://www.gempillar.com
Before enlightenment: chop wood, carry water
After enlightenment: code, build circuits

Re: [myhdl-list] Name generation RTL components

[Jos H. <jos...@gm...>]

Hi Jan,


On Wed, Oct 15, 2008 at 8:54 PM, Jan Decaluwe <ja...@ja...> wrote:

> The purpose is *not* to develop a source code to "equivalent"
> source code conversion tool. (Good luck with that, btw!)
>

Actually, that's exactly what I would have liked: another HDL generator
allowing better parameterized HDL design. But I'll try without hierarchy for
now.

Best regards,
Jos

Re: [myhdl-list] Small failing example

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

Jan Decaluwe wrote:
> Jos Huisken wrote:
>> Attached is a small, hierarchical example failing with an xor in a 
>> full-adder.
>> The sensitivity list of the xor (using the ports) within the full-adder 
>> is inconsistent with the used (internal) signals.
>> So both simulation fails and the verilog/VHDL conversion is wrong.
>> Maybe the example is somewhat artificial... maybe I do something wrong. 
>> These is my first small example.
> 
> I have looked into your example. The problem is with the usage
> of ports inside lists. There's good news and bad news :-):
> The good news is that with internal signals (for example, in larger,
> more realistic examples), similar code should work as expected.
> The bad news is that I don't see a way to get this to work with
> ports. This means that I propose to detect this situation and
> flag it as a conversion error.

I have just pushed a number of patches to the repo, including
checks on the use of list of signals:

* ports are not allowed to be part of a list
* a signals is not allowed to be part of more than one list

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Re: [myhdl-list] ImpulseC generated VHDL files being tested by MyHDL

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

David Blubaugh wrote:
> To All,
>  
>  
> I was wondering if it is feasible to utilize MyHDL and Python to develop 
> a simulation environment for VHDL files being generated by ImpulseC?  
> Such as if I develop, lets say an FIR filter is developed by ImpulseC 
> generated VHDL files.  Can I then develop a python program with MyHDL 
> to develop a simulated environment, where that particular FIR filter is 
> being utilized within lets say as a component within a wireless modem 
> operating within a Humvee in arid desert conditions?  This type of 
> simulation is known as developing a test vector.  I was wondering if 
> this is possible with Python and MyHDL? 

You cannot use MyHDL to co-simulate with VHDL, but you can use it
to develop VHDL test benches if you obey the constraints imposed by
the convertor. Read more about it here:

http://www.myhdl.org/doc/dev/0.6/whatsnew/0.6.html#conversion-of-test-benches

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

[myhdl-list] ImpulseC generated VHDL files being tested by MyHDL

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

To All,
 
 
I was wondering if it is feasible to utilize MyHDL and Python to develop a simulation environment for VHDL files being generated by ImpulseC?  Such as if I develop, lets say an FIR filter is developed by ImpulseC generated VHDL files.  Can I then develop a python program with MyHDL to develop a simulated environment, where that particular FIR filter is being utilized within lets say as a component within a wireless modem operating within a Humvee in arid desert conditions?  This type of simulation is known as developing a test vector.  I was wondering if this is possible with Python and MyHDL?  
 
 
Thanks,
 
 
David Blubaugh
 
 
 


      

Re: [myhdl-list] Name generation RTL components

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

Jos Huisken wrote:
> 
> 
> On Sun, Oct 5, 2008 at 8:20 PM, Jan Decaluwe wrote:
> 
>     I assume that you know that the converted netlist is non-hierarchical,
>     and that, therefore, the signals names are in a flat namespace -
>     so I guess your concern is how to avoid name collision.
> 
> 
> I actually did not realize it is non-hierarchical... but it's easy to see.
> Why did you make it non-hierarchical?

Short answer
-------------
Because that was the easiest thing to do.

Long answer
-----------
The purpose of MyHDL conversion is to give designers an easy
path into their existing HDL environment.
The purpose is *not* to develop a source code to "equivalent"
source code conversion tool. (Good luck with that, btw!)

Therefore, the easiest path to conversion was chosen. The
convertor does not start from the MyHDL source code; instead,
it uses the Python interpreter as much as possible to elaborate
the design first. So it starts from the same data structure
as the simulator, and this happens to be non-hierarchical.
A flat list of generators, basically.

It is true however that some aspects of the hierarchy are tracked
anyway, in particular to give names to instances and signals.
This is done by (mis)using the Python profiler to track function
calls. The code that does this minimal task is quite hairy already;
yet this is much simpler than maintaining the original hierarchy
in the converted output.

A final note: hierarchy is very useful to humans, but no so much
to tools. Up to a few 100,000 gates, I don't think you'll have
a problem with a back-end tool. (And above that, you surely
must have enough money to hire me and improve the solution :-))

 > I would expect keeping the
 > hierarchy as specified is easy.

Not necessarily, see above.

> On the other hand I would like to control toVerilog/toVHDL w.r.t. 
> hierarchy manipulation, maybe.

Yes, a valid concern. I do this for example to keep test benches
separate from a design under test. The workaround for this is
user-defined code (using __toVerilog__ and __toVHDL__) that
defines an instantiation. When the convertor encounters this,
it stops converting and inserts the user-defined code instead.
By using conversion at various levels, you can maintain the
hierarchy as you wish.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Re: [myhdl-list] Small failing example

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

Jos Huisken wrote:
> Attached is a small, hierarchical example failing with an xor in a 
> full-adder.
> The sensitivity list of the xor (using the ports) within the full-adder 
> is inconsistent with the used (internal) signals.
> So both simulation fails and the verilog/VHDL conversion is wrong.
> Maybe the example is somewhat artificial... maybe I do something wrong. 
> These is my first small example.

I have looked into your example. The problem is with the usage
of ports inside lists. There's good news and bad news :-):
The good news is that with internal signals (for example, in larger,
more realistic examples), similar code should work as expected.
The bad news is that I don't see a way to get this to work with
ports. This means that I propose to detect this situation and
flag it as a conversion error.

Why are ports different? 2 reasons:
- in Verilog, you can't use memories as ports
- for both VHDL and Verilog, it is probably wise to support only
the most basic, scalar, standard types for ports, to avoid issues
with subsequent back-end tools.

Note that the restrictions only apply to the very top-level ports
of the design, because only those become ports in the non-hierarchical
converted output. (BTW, this demonstrates an advantage of the
conversion approach).

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Re: [myhdl-list] Small failing example

[Christopher L. F. <cf...@uc...>]

>> The sensitivity list of FA_BXOR_BXOR contains in_a and in_b. Both
>> signals
>> (well... ports) are not used in the process. Instead the -not
>> initialized-
>> signal bxor_in_input is used.
>> I expect this fails in VHDL simulation.
>> The same I see in the generated verilog.

I retract some of my early posts.  From your description (or my  
failure to read to the end of the post) I thought you were eluding to  
an issue with the hierarchy.  As you mentioned the generated Verilog /  
VHDL is incorrect.

The following MyHDL:

<c> bxor = BXor([in_a, in_b], wire_a_xor_b);
<c> ...
<c> def BXor(in_input, out_output):
<c>
<c>    @always_comb
<c>    def bxor():
<c>        var_val = 0
<c>        for i in range(len(in_input)):
<c>            var_val = var_val ^ in_input[i]
<c>        out_output.next = var_val;
<c>
<c>    return bxor

is converted to

<c> always @(in_a, in_b) begin: FA_BXOR_BXOR
<c>    integer i;
<c>    reg var_val;
<c>    var_val = 0;
<c>    for (i=0; i<2; i=i+1) begin
<c>        var_val = (var_val ^ bxor_in_input[i]);
<c>    end
<c>    wire_a_xor_b <= var_val;
<c>
<c> end

This is a relatively new feature in MyHDL (list of signals in a  
generator statement).  This will have to be looked at to see if it is  
simply a bug in the original implementation or if the approach has to  
be modified.

There are multiple ways to achieve your goals in MyHDL.  If you are  
simply looking for something to work you can use the array of  
instances instead of the list of signals.

Re: [myhdl-list] Small failing example

[Christopher L. F. <cf...@uc...>]

>> The sensitivity list of FA_BXOR_BXOR contains in_a and in_b. Both
>> signals
>> (well... ports) are not used in the process. Instead the -not
>> initialized-
>> signal bxor_in_input is used.
>> I expect this fails in VHDL simulation.
>> The same I see in the generated verilog.

I retract some of my early posts.  From your description (or my  
failure to read to the end of the post) I thought you were eluding to  
an issue with the hierarchy.  As you mentioned the generated Verilog /  
VHDL is incorrect.

The following MyHDL:

<c> bxor = BXor([in_a, in_b], wire_a_xor_b);
<c> ...
<c> def BXor(in_input, out_output):
<c>
<c>    @always_comb
<c>    def bxor():
<c>        var_val = 0
<c>        for i in range(len(in_input)):
<c>            var_val = var_val ^ in_input[i]
<c>        out_output.next = var_val;
<c>
<c>    return bxor

is converted to

<c> always @(in_a, in_b) begin: FA_BXOR_BXOR
<c>    integer i;
<c>    reg var_val;
<c>    var_val = 0;
<c>    for (i=0; i<2; i=i+1) begin
<c>        var_val = (var_val ^ bxor_in_input[i]);
<c>    end
<c>    wire_a_xor_b <= var_val;
<c>
<c> end

This is a relatively new feature in MyHDL (list of signals in a  
generator statement).  This will have to be looked at to see if it is  
simply a bug in the original implementation or if the approach has to  
be modified.

There are multiple ways to achieve your goals in MyHDL.  If you are  
simply looking for something to work you can use the array of  
instances instead of the list of signals.

Re: [myhdl-list] Small failing example

[Christopher F. <cf...@uc...>]

If you look at the files I sent last night I added the cosimulation. 
 The generated verilog files (from your example) compile with cver 
(Verilog simulator).  The cosimulation run but gets an exception at 
some point in the simulation (believe it is unrelated to the hierarchy 
you are concerned about).  I didn't have time to debug the cosim 
error.  I can try it with iverilog as well.

Maybe I missed it in a previous post.  What specifically in the 
generated code do you think is incorrect?  Remember, as Jan mentioned 
it creates a flat hierarchy, so when you run the toVerilog on your 
fa.py the fa.v file is all you need, that Verilog file includes 
everything, don't have to include the bxor.v file, it is in the fa.v 
file.

On Tue, 7 Oct 2008 23:02:11 +0200
  "Jos Huisken" <jos...@gm...> wrote:
> Thanks for the suggestion, indeed a typo (well, actually some lack 
>of
> understanding...)
> 
> But still, while looking at the verilog and VHDL I'm not convinced 
>the
> generated VHDL/Verilog is correct:
> 
> ----
> architecture MyHDL of fa is
> 
> signal wire_a_xor_b: std_logic;
> type t_array_bxor_in_input is array(0 to 2-1) of std_logic;
> signal bxor_in_input: t_array_bxor_in_input;
> 
> begin
> 
> 
>FA_BXOR_BXOR: process (in_a, in_b) is
>    variable var_val: std_logic;
> begin
>    var_val := '0';
>    for i in 0 to 2-1 loop
>        var_val := (var_val xor bxor_in_input(i));
>    end loop;
>    wire_a_xor_b <= var_val;
> 
> end process FA_BXOR_BXOR;
> 
> out_sum <= to_std_logic((to_boolean(wire_a_xor_b) and (not
> to_boolean(in_carry))) or ((not to_boolean(wire_a_xor_b)) and
> to_boolean(in_carry)));
> out_carry <= to_std_logic((to_boolean(in_a) and to_boolean(in_b)) or
> (to_boolean(wire_a_xor_b) and to_boolean(in_carry)));
> 
> end architecture MyHDL;
> ----
> 
> The sensitivity list of FA_BXOR_BXOR contains in_a and in_b. Both 
>signals
> (well... ports) are not used in the process. Instead the -not 
>initialized-
> signal bxor_in_input is used.
> I expect this fails in VHDL simulation.
> The same I see in the generated verilog.
> 
> 
> On Tue, Oct 7, 2008 at 2:35 AM, Christopher L. Felton 
><cf...@uc...>wrote:
> 
>> Think you had a typo in the FA testbench, it seems to work ok and 
>>the
>> verilog seems alright.
>>
>>
>>

Re: [myhdl-list] Small failing example

[Jos H. <jos...@gm...>]

Thanks for the suggestion, indeed a typo (well, actually some lack of
understanding...)

But still, while looking at the verilog and VHDL I'm not convinced the
generated VHDL/Verilog is correct:

----
architecture MyHDL of fa is

signal wire_a_xor_b: std_logic;
type t_array_bxor_in_input is array(0 to 2-1) of std_logic;
signal bxor_in_input: t_array_bxor_in_input;

begin


FA_BXOR_BXOR: process (in_a, in_b) is
    variable var_val: std_logic;
begin
    var_val := '0';
    for i in 0 to 2-1 loop
        var_val := (var_val xor bxor_in_input(i));
    end loop;
    wire_a_xor_b <= var_val;

end process FA_BXOR_BXOR;

out_sum <= to_std_logic((to_boolean(wire_a_xor_b) and (not
to_boolean(in_carry))) or ((not to_boolean(wire_a_xor_b)) and
to_boolean(in_carry)));
out_carry <= to_std_logic((to_boolean(in_a) and to_boolean(in_b)) or
(to_boolean(wire_a_xor_b) and to_boolean(in_carry)));

end architecture MyHDL;
----

The sensitivity list of FA_BXOR_BXOR contains in_a and in_b. Both signals
(well... ports) are not used in the process. Instead the -not initialized-
signal bxor_in_input is used.
I expect this fails in VHDL simulation.
The same I see in the generated verilog.


On Tue, Oct 7, 2008 at 2:35 AM, Christopher L. Felton <cf...@uc...>wrote:

> Think you had a typo in the FA testbench, it seems to work ok and the
> verilog seems alright.
>
>
>

Re: [myhdl-list] Small failing example

[Christopher L. F. <cf...@uc...>]

Think you had a typo in the FA testbench, it seems to work ok and the  
verilog seems alright.

Re: [myhdl-list] Name generation RTL components

[Jos H. <jos...@gm...>]

On Sun, Oct 5, 2008 at 8:20 PM, Jan Decaluwe wrote:

> I assume that you know that the converted netlist is non-hierarchical,
> and that, therefore, the signals names are in a flat namespace -
> so I guess your concern is how to avoid name collision.
>

I actually did not realize it is non-hierarchical... but it's easy to see.
Why did you make it non-hierarchical? I would expect keeping the hierarchy
as specified is easy.
On the other hand I would like to control toVerilog/toVHDL w.r.t. hierarchy
manipulation, maybe.

-- Jos

Re: [myhdl-list] Name generation RTL components

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

Jos Huisken wrote:
> I agree keeping such options out of the design code.
> Question now is how to keep the hierarchical naming correct... I do not 
> see yet how to achieve easily, being a newbie.

I assume that you know that the converted netlist is non-hierarchical,
and that, therefore, the signals names are in a flat namespace -
so I guess your concern is how to avoid name collision.

Currently, the hierarchical instance name is prepended to the original
signal name. This avoids collisions in practice, but it is of course
no hard guarantee.

What could be done is make signal naming more sophisticated by checking
for a collision during the naming procedure, and adding a unique suffix
if one is found. In practice, other issues should be tackled also, e.g.
other areas of name generation such as labels, and collisions with Verilog
and VHDL keywords.

Currently, this is all brittle although a workaround is probably easy
if there's an issue.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Re: [myhdl-list] Q: should I activate myhdl.org now?

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

Tom Dillon wrote:
> Jan,
> 
> That sounds fine. 
> 
> I have been out of touch with this issue. If you remember, I offered to host 
> the myhdl site on our servers, and I just wanted to let you know I would still 
> do that if that helps you in any way.

Thanks, Tom. In the mean time what has happened is that I realized
the following:

- in the future I'd like to administrate more websites, personal and professional,
   alongside myhdl.org
- I needed shell access and easy control of new web technologies to experiment with.

These goals are broader than myhdl.org only, and to implement them
I have switched to webfaction as as host provider. I've had problems with them,
but one thing which they make really easy is to map and remap applications to
domains, and to install a number of (python-based) web applications I'm interested in.

With all this set up, it's also a straightforward way for me to set up and
administrate myhdl.org (and it saves you some overhead :-))

Thanks again for your help offering!

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Re: [myhdl-list] Name generation RTL components

[Jos H. <jos...@gm...>]

I agree keeping such options out of the design code.
Question now is how to keep the hierarchical naming correct... I do not see
yet how to achieve easily, being a newbie.


> In general I think I prefer to keep HDL conversion configuration
> options as much as possible out of the design code itself, and
> this mechanism achieves that.

> BTW, if you wanted to generate a series of components,
> you'd probably write a for loop that sets up the desired
> name in a parametrized way in the loop, so this can be
> done in a quite compact way also.

[myhdl-list] Domain moved to www.myhdl.org

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

I have moved the web site to www.myhdl.org using a permanent
redirect from myhdl.jandecaluwe.com.

Please check that it works for you.

I'll keep the redirect active for some time, but please do
use the new url from now on and update possible links.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Re: [myhdl-list] Q: should I activate myhdl.org now?

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
...
> However, why shouldn't we make the move now already with
> what we have, before releasing 0.6?
...
> 
> What do you think?

Sounds good to me to use the new domain already now.

Re: [myhdl-list] Q: should I activate myhdl.org now?

[Christopher F. <cf...@uc...>]

> 
> What do you think?
> 
> 

Sounds good to me as well!

Re: [myhdl-list] Q: should I activate myhdl.org now?

[Newell J. <pil...@gm...>]

Sounds good to me.

-- 
Newell

http://www.gempillar.com
Before enlightenment: chop wood, carry water
After enlightenment: code, build circuits

Re: [myhdl-list] Q: should I activate myhdl.org now?

[Tom D. <TD...@di...>]

Jan,

That sounds fine. 

I have been out of touch with this issue. If you remember, I offered to host 
the myhdl site on our servers, and I just wanted to let you know I would still 
do that if that helps you in any way.

Tom


 On Wednesday 01 October 2008 6:50:33 am Jan Decaluwe wrote:
> With webfaction, my current host, I can very easily map
> and remap applications to domain names.
>
> Also, I own the myhdl.org domain. The idea was to have it
> available once we find the "ultimate" cms for our needs.
>
> However, why shouldn't we make the move now already with
> what we have, before releasing 0.6?
>
> I think that decoupling the project from my name would help
> its credibility by stressing its openness, and its
> cooperative nature.
>
> I would remain site owner and admin as before.
>
> If we do find a better system than dokuwiki at one point,
> it would be easy to prepare a new site at some temporary
> domain and make the switch when appropriate.
>
> Tecnhically, I would move myhdl.jandecaluwe.com with a
> 'redirect 301' to www.myhdl.org - meaning a permanent move.
> Accessing the old domain would transparently move you to the
> new domain. This also seems to be search-engine friendly.
>
> Basically, everything would continue to work as before,
> including passwords to access the site, with only one
> inconvenience: if you rely on the stored password in your
> browser, you may have to enter it again.
>
> What do you think?