myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] How to give signals custom names in toVHDL

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

Sigve Tjora wrote:
> Hi,
> 
> I have a problem where different signals get the same name in VHDL
> when using toVHDL, caused when using two instances with identical
> names according to _makeName.

How can 2 different instances have the same name?
(except in another part of the hierarchy, where the hierarchical
name is different). 

> 
> I see that in _analyze.py there is this construction:
>     for n, s in sigdict.items():
>         if s._name is not None:
>             continue
> 
> Setting the s._name on a signal causes the signal to use the assigned
> name, but the "continue" above stops generation of the signal
> declaration. I guess that the this construction is used for something
> else.

._name is a private attribute, not intended for user manipulation.

> What is the appropriate method to give a signal a specific name?
> Setting only a part of a signal name (prefix or postfix) would also be
> ok.

Not supported at the moment. Supporting this would probably make
it even more difficult to avoid name clashes.

> The autogenerated signal names are not always very informative.

It's supposed to the hierarchical name. What is not clear about it?

 but
> the worst problem is the signal name collision resulting in defective
> VHDL.

There is definitely a problem with name clashes. Hierarchical signals
names clashes are not checked, and you can certainly construct names
so that clashes occur.

I know this needs to be fixed, but there are some issues. The best
I can come up with is a brute-force method of assigning
a unique suffix to all signals. But even this doesn't solve
everything, as we want to keep the port names unchanged.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] How to give signals custom names in toVHDL

[Sigve T. <pu...@tj...>]

Hi,

I have a problem where different signals get the same name in VHDL
when using toVHDL, caused when using two instances with identical
names according to _makeName.

I see that in _analyze.py there is this construction:
    for n, s in sigdict.items():
        if s._name is not None:
            continue

Setting the s._name on a signal causes the signal to use the assigned
name, but the "continue" above stops generation of the signal
declaration. I guess that the this construction is used for something
else.

What is the appropriate method to give a signal a specific name?
Setting only a part of a signal name (prefix or postfix) would also be
ok.

The autogenerated signal names are not always very informative, but
the worst problem is the signal name collision resulting in defective
VHDL.

Sigve

Re: [myhdl-list] myhdl array signals initialization not initialized in vhdl array.

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

Sverre Hamre wrote:
> Hello.
> 
> I have an issue where initialized signals in myhdl arrays is not 
> initialized in the vhdl code.
> 
> I added a simple example code and the generated vhdl output files.
> 
> In the vhdl outputfile the signal using the array is not initialized, 
> since the signals in the myhdl array is initialized I would expect the 
> vhdl array to be initialized also. Is this a bug? or am I missing 
> something her.

This currently doesn't work for plain signals either.

The proper way would be include initializations with the
signal or array declarations.

I had once done that, but removed it again because some synthesis
tools didn't support is. If we are sure that it's no problem for
synthesis tools (including Xilinx and Altera), we can consider
to put it in again. 

> I am using myhdl-0.7.1134
> 
> Thank you and please cc me as I am not subscribing the list.

Note that you can follow and post to the list as a newsgroup
without subscribing.

http://www.myhdl.org/doku.php/mailing_list

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] myhdl array signals initialization not initialized in vhdl array.

[Sverre H. <sv...@3d...>]

Hello.

I have an issue where initialized signals in myhdl arrays is not 
initialized in the vhdl code.

I added a simple example code and the generated vhdl output files.

In the vhdl outputfile the signal using the array is not initialized, 
since the signals in the myhdl array is initialized I would expect the 
vhdl array to be initialized also. Is this a bug? or am I missing 
something her.

I am using myhdl-0.7.1134

Thank you and please cc me as I am not subscribing the list.

Sverre Hamre.

[myhdl-list] FW: Two slightly awkward things about the MyHDL syntax

[Vanheesbeke S. <Ste...@va...>]

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

Re: [myhdl-list] Would MyHDL work ok with math libraries & science librariess to make verilog modules that could be schematic symbols in xilinx scematic designer?

[Christopher F. <chr...@gm...>]

You cannot do what you are asking with MyHDL.  MyHDL is still an RTL.  You
can not take arbitrary python and turn it into hardware.  All the tools and
libs can be used for simulation but not for synthesizing hardware.

.chris

On Aug 11, 2010 3:34 PM, "joshua wojnas" <jo...@gm...> wrote:
> Would MyHDL work ok with math libraries & science librariess to make
> verilog modules that could be schematic symbols in xilinx scematic
> designer?
>
> In other words I create a block of code simple as possible in the
> sence of copy the library example
>
> this is c I am new to python
>
> int y=0;
> int x=0;
> x=cos(y);
>
> or some other math function ...
>
> x=pi*2 *y
>
> so then they could be used in parrellel in the schematic design
> documenting and creating larger systems.
>
> I seen their was a example that calculated cos some other way... but
> why not use libraries allready created. I am bringing this up because
> I am not as good with math as some libraries that are allready their
> in python.
>
> A tutorial taking a simple python program calculator and turning it
> into hardware would be great.
>
> --
> thanks for your time,
> Joshua Wojnas
> 315 5071070
> My webpages on electronics
> ... comming soon
>
>
------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] Would MyHDL work ok with math libraries & science librariess to make verilog modules that could be schematic symbols in xilinx scematic designer?

[joshua w. <jo...@gm...>]

Would MyHDL work ok with math libraries & science librariess to make
verilog modules that could be schematic symbols in xilinx scematic
designer?

In other words I create  a block of code simple as possible in the
sence of copy the library example

this is c I am new to python

int y=0;
int x=0;
x=cos(y);

or some other math function ...

x=pi*2 *y

so then they could be used in parrellel in the schematic design
documenting and creating larger systems.

I seen their was a example that calculated cos some other way... but
why not use libraries allready created. I am bringing this up because
I am not as good with math as some libraries that are allready their
in python.

A tutorial taking a simple python program calculator and turning it
into hardware would be great.

-- 
thanks for your time,
Joshua Wojnas
315 5071070
My webpages on electronics
... comming soon

Re: [myhdl-list] Model a PFD

[Thomas H. <th...@ct...>]

Christopher L. Felton schrieb:
> On 7/25/2010 5:43 AM, Thomas Heller wrote:
>> I'm trying to model a phase frequency detector like the one
>> in Figure 1 of this article:
>>
>> http://www.analog.com/library/analogDialogue/archives/33-07/phase3/
>>
>> IMO the VHDL code would be something like this:
>>
>> process(in_a, in_b, up, down)
>> begin
>>    if up = '1' and down = '1' then
>>      up<= '0';
>>      down<= '0';
>>    else
>>      if rising_edge(in_a) then
>>        up<= '1';
>>      end if;
>>      if rising_edge(in_b) then
>>        down<= '1';
>>      end if;
>>    end if;
>> end process;
>>
>> How would I code this in myhdl?
>>
>>    
> In your VHDL process you specify 3 signals in the sensitivity list.   
> Two of the signals are qualified to be rising edge sensitive.  In MyHDL 
> you can do the similar thing.
> 
> @always(in_a.posedge, in_b.posedge, up, down)
> def rtl_pfd():
>      if up and down:
>          up.next = False
>          down.next = False
>      if in_a:
>          up.next = True
>      if in_b:
>          down.next = True
> 
> 
> I didn't test the above, I need to double check the the level sensitive 
> syntax is @always(sig, sig, ...).

I don't think this will work.  Here is a quote from the MyHDL manual:

"""
... this is MyHDL code for a D flip-flop with asynchronous set,
asynchronous reset, and preference of set over reset:

@always(clk.posedge, set.negedge, rst.negedge)
def logic():
    if set == 0:
        q.next = 1
    elif rst == 0:
        q.next = 0
    else:
        q.next = d
"""

As you can see, there is NO edge-test inside the 'logic' function.  If I understand
the working of the above DFF correctly, it goes like this:

The 'logic()' function is called when clk goes HIGH, or when SET or RESET goes low.
The values of the SET and RESET signals are examined, if the are LOW then the corresponding
action is taken.  If both are HIGH then the last else clause is executed which must now
be the positive edge of the clk signal.

So, maybe the question boils down to this:
If I have more than one edge sensitive signal in the always decorator, how do I test
in the function block which of these edges have occurred?

-- 
Thanks,
Thomas

Re: [myhdl-list] Model a PFD

[Christopher L. F. <chr...@gm...>]

On 7/25/2010 5:43 AM, Thomas Heller wrote:
> I'm trying to model a phase frequency detector like the one
> in Figure 1 of this article:
>
> http://www.analog.com/library/analogDialogue/archives/33-07/phase3/
>
> IMO the VHDL code would be something like this:
>
> process(in_a, in_b, up, down)
> begin
>    if up = '1' and down = '1' then
>      up<= '0';
>      down<= '0';
>    else
>      if rising_edge(in_a) then
>        up<= '1';
>      end if;
>      if rising_edge(in_b) then
>        down<= '1';
>      end if;
>    end if;
> end process;
>
> How would I code this in myhdl?
>
>    
In your VHDL process you specify 3 signals in the sensitivity list.   
Two of the signals are qualified to be rising edge sensitive.  In MyHDL 
you can do the similar thing.

@always(in_a.posedge, in_b.posedge, up, down)
def rtl_pfd():
     if up and down:
         up.next = False
         down.next = False
     if in_a:
         up.next = True
     if in_b:
         down.next = True


I didn't test the above, I need to double check the the level sensitive 
syntax is @always(sig, sig, ...).

> Looking at the what's new in myhdl 0.6 document, section 1.3.4,
> I see no possibility to distinguish the rising edge of in_a from
> the rising edge of in_b...
>
>    

[myhdl-list] Model a PFD

[Thomas H. <th...@ct...>]

I'm trying to model a phase frequency detector like the one
in Figure 1 of this article:

http://www.analog.com/library/analogDialogue/archives/33-07/phase3/

IMO the VHDL code would be something like this:

process(in_a, in_b, up, down)
begin
  if up = '1' and down = '1' then
    up <= '0';
    down <= '0';
  else
    if rising_edge(in_a) then
      up <= '1';
    end if;
    if rising_edge(in_b) then
      down <= '1';
    end if;
  end if;
end process;

How would I code this in myhdl?

Looking at the what's new in myhdl 0.6 document, section 1.3.4,
I see no possibility to distinguish the rising edge of in_a from
the rising edge of in_b...

-- 
Thanks,
Thomas

[myhdl-list] unsubscribe

[Cao Q. <qh...@ci...>]

Re: [myhdl-list] Deterministic output of toVHDL

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

Jan Decaluwe wrote:
> Jan Decaluwe wrote:
>> Knut Eldhuset wrote:
>>> Hi all,
>>>
>>> I would like the output of toVHDL to be deterministic, meaning the 
>>> generated .vhd files should be identical when nothing has changed 
>>> between runs. At least two things are non-deterministic in default branch:
>>>
>>> 1) The timestamp is included in output files.
>>> 2) The order of enum typedefs in package declarations is random.
>>>
>>> 1) is easily fixed by monkey-patching datetime, but this is not an ideal 
>>> solution.
>> I have recently pushed a changeset to the development repo that lets
>> you define your own header (brand new - undocumented, see the source.)
>>
>> With toVHDL.suppress_myhdl_header = False, you can suppress the default header.
>                                     ^^^^^^^
>                                     = True
> 
> obviously. Mm, may this should be more simply called toVHDL.no_myhdl_header

Beware: in development, I have called this toVHDL.no_myhdl_header now.

Jan



-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] hg rev 1105 : better support for mapping to case statements

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

Christopher Felton wrote:
> I apologize for the lack of information up front.  I updated to the 
> latest tip to check out some of the changes.  I ran into an issue.
> 
> I believe it is related to the changes checked into revision 1105 
> (better support for mapping to case statements).  I reverted back to 
> 1104 and the issue didn't occur.
> 
> The issue/error was an invalid casez statement (?).  At least Icarus 
> determined it invalid "error: Unable to bind wire/reg/memory `False' in".

I have found and fixed bug related to this.

The background is that I'm trying to infer Verilog case statements
more often, not only when using enums but also when testing
an intbv against a number of integer values.

Jan


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Two slightly awkward things about the MyHDL syntax

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

Angel Ezquerra wrote:
> Hi Jan,

> 
> I feel that this is awkward for two reasons:
>    - It is weird that the port type specifications are done outside of 
> the block declaration.

This is just how Python works. MyHDL is Python. Interfaces
are parametrizable by default.

>    - If you change the block declaration you must also change the code 
> that calls the conversion function.

Conversion is the last step in the process. It's very important to
integrate in design flows, but it shouldn't dictate how MyHDL itself
works. 

Moreover, you have the full Python mechanisms available to make it
more convenient. Looking up names in namespaces for example.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Two slightly awkward things about the MyHDL syntax

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

Angel Ezquerra wrote:
> 
> On Wed, Jul 14, 2010 at 5:44 PM, Christopher Felton <cf...@uc... 
> <mailto:cf...@uc...>> wrote:

> 
> 
>     This is currently support use the function instances().  Example
>     return instances().  It will return all generators in the module.
>      Adding new generators will not require updating the return list.
>      
> 
> That is awesome! I did not know that! Thank you for this tip! It 
> basically removes one of my may complaints about MyHDL! :-D
> 
> I think that I have not seen this used in the examples that I've 
> studied, although perhaps I missed it. It is certainly not used in many 
> of the examples. Since this is a very convenient way to work I think 
> that this should be used in the examples so that it becomes the default 
> way to return the instances defined in a block.

To implement instances(), you need a fair amount of "magic".
Therefore, it has both the advantages of magic (convenience) and
its disadvantages:
- it may make things less generic, potentially creating problems down the road
- it may make it more difficult for newbies to understand what's going on

A very common use case is to just return a single tuple of instances
as the last line. In such cases, using instances() is probably just fine.
However, sooner or later you'll need more complex cases, and MyHDL's
mechanism makes it straigthforward to do so. For example, setting up a list
of instances dynamically. Or returning a different list of instances
depending on conditions, like here:

    http://www.myhdl.org/doku.php/cookbook:bitonic

In such cases, I think it's much clearer to return the instances
explicitly. Just the other day, someone was confused by instances()
and I recommended him to throw it out to understand what was going on.

Therefore: I consider instances() very advanced usage, only to be
used when one understands very clearly how MyHDL works. Therefore,
not for newbies, and not the first thing documented in the manual.

Personally, I tend not to use it. I regard the return statement
as an "export declaraton" or a summary of the module.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Two slightly awkward things about the MyHDL syntax

[Jian L. <jia...@go...>]

I usually use assert to check ports before any instance declaration in the
function body,
and think that's good enough for me.

Cheers,

Jian


On Sat, Jul 17, 2010 at 5:01 PM, Angel Ezquerra <ang...@gm...>wrote:

>
> On Wed, Jul 14, 2010 at 5:44 PM, Christopher Felton <cf...@uc...>wrote:
>
>
>> On Wed, Jul 14, 2010 at 10:22 AM, Angel Ezquerra <
>> ang...@gm...> wrote:
>>
>>> Hi Jan,
>>>
>>> I am little by little learning how to use MyHDL. In general I've found
>>> that using python to model hardware is very nice and that the resulting code
>>> is very clear and easy to understand. However there are two things in the
>>> way that MyHDL works that feel a bit awkward to me. I'd like to give you the
>>> perspective of a new user so that perhaps you can try to improve MyHDL in
>>> this regard if you feel that these suggestion are valid :-)
>>>
>>> - Having to return the list of declared generators is odd:
>>>
>>> This is the first thing that tripped me when trying to create my first
>>> myhdl design from scratch. I was expecting MyHDL to infer the list of
>>> generators automatically. Instead you must manually return the list of
>>> generators that you use on each block.
>>>
>>> This is a bit annoying because it means that if you ever add new
>>> generators to a block or if you change their names you must remember to
>>> modify the function return statement to keep it synchronized with the
>>> generators that you are using.
>>>
>>> Note that I am not saying that the MyHDL documentation does not tell you
>>> about this (because it does). I am just saying that it would be much nicer
>>> if myhdl could track this automatically for you.
>>>
>>> Perhaps the @instance, @always and @always_comb decorators could somehow
>>> add a reference to the generator that is being declared into a list of local
>>> instances. This "instance list" could have a known name that the user could
>>> then return (e.g. the user could always do "return local_instances()" or
>>> something of the sort). The nice thing of this approach is that it could be
>>> 100% backwards compatible, since the user could chose to manually create the
>>> return list (as is done today).
>>>
>>>
>> This is currently support use the function instances().  Example return
>> instances().  It will return all generators in the module.  Adding new
>> generators will not require updating the return list.
>>
>>
>
> That is awesome! I did not know that! Thank you for this tip! It basically
> removes one of my may complaints about MyHDL! :-D
>
> I think that I have not seen this used in the examples that I've studied,
> although perhaps I missed it. It is certainly not used in many of the
> examples. Since this is a very convenient way to work I think that this
> should be used in the examples so that it becomes the default way to return
> the instances defined in a block.
>
>
>> - Declaring the list of interface signals (and their types) outside of the
>>> block definition function is prone to errors:
>>>
>>> In MyHDL, when you define a block you put the names of the interface
>>> signals in the argument list of the corresponding function. However, when
>>> you call the conversion functions you must first declare the corresponding
>>> signals (and their types) and then pass that list to the conversion
>>> function.
>>>
>>> I feel that this is awkward for two reasons:
>>>    - It is weird that the port type specifications are done outside of
>>> the block declaration.
>>>    - If you change the block declaration you must also change the code
>>> that calls the conversion function.
>>>
>>> I imagine that the main reason for this second "awkward" syntax is that
>>> Python is not a strongly typed language. Yet it seems that a more elegant
>>> solution could be found. For example, perhaps a "port" decorator could be
>>> added to the "hardware block functions" in which the list of port types
>>> could be declared. This would put the port type declaration close to the
>>> actual block definition and would let you call the pass the block
>>> declaration function alone (without the list of port signals) to the convert
>>> functions (e.g. you could call "toVHDL(myBlock)" rather than
>>> "toVHDL(myBlock, myPort1, myPort2, myPort3)").
>>>
>>> I think that this enhancement could also be done in a backward compatible
>>> way, since the user could still pass the list of port signals to the convert
>>> function.
>>>
>>> An extra benefit of this approach is that this "port" annotation could be
>>> used to ensure that the signals that are passed to the block function are of
>>> the right type (and throw an exception if that were not the case).
>>>
>>>
>> Would the port decorator be able to handle parameters?  The HDL modules
>> need to be modular, such that I can define bit widths etc when instantiating
>> the module.
>>
>
> Ideally you should be able to set default types (including sizes) for the
> ports but you should also be able to tell myhdl whether you want it to
> generate an exception when a user uses a different type (or Signal width)
> for those parameters. Perhaps that could be done by using parameters (with
> default values) but I don't really know how could that be done withing the
> confines of python syntax. Any ideas?
>
> Angel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

Re: [myhdl-list] Two slightly awkward things about the MyHDL syntax

[Angel E. <ang...@gm...>]

On Wed, Jul 14, 2010 at 5:44 PM, Christopher Felton <cf...@uc...>wrote:

>
> On Wed, Jul 14, 2010 at 10:22 AM, Angel Ezquerra <ang...@gm...
> > wrote:
>
>> Hi Jan,
>>
>> I am little by little learning how to use MyHDL. In general I've found
>> that using python to model hardware is very nice and that the resulting code
>> is very clear and easy to understand. However there are two things in the
>> way that MyHDL works that feel a bit awkward to me. I'd like to give you the
>> perspective of a new user so that perhaps you can try to improve MyHDL in
>> this regard if you feel that these suggestion are valid :-)
>>
>> - Having to return the list of declared generators is odd:
>>
>> This is the first thing that tripped me when trying to create my first
>> myhdl design from scratch. I was expecting MyHDL to infer the list of
>> generators automatically. Instead you must manually return the list of
>> generators that you use on each block.
>>
>> This is a bit annoying because it means that if you ever add new
>> generators to a block or if you change their names you must remember to
>> modify the function return statement to keep it synchronized with the
>> generators that you are using.
>>
>> Note that I am not saying that the MyHDL documentation does not tell you
>> about this (because it does). I am just saying that it would be much nicer
>> if myhdl could track this automatically for you.
>>
>> Perhaps the @instance, @always and @always_comb decorators could somehow
>> add a reference to the generator that is being declared into a list of local
>> instances. This "instance list" could have a known name that the user could
>> then return (e.g. the user could always do "return local_instances()" or
>> something of the sort). The nice thing of this approach is that it could be
>> 100% backwards compatible, since the user could chose to manually create the
>> return list (as is done today).
>>
>>
> This is currently support use the function instances().  Example return
> instances().  It will return all generators in the module.  Adding new
> generators will not require updating the return list.
>
>

That is awesome! I did not know that! Thank you for this tip! It basically
removes one of my may complaints about MyHDL! :-D

I think that I have not seen this used in the examples that I've studied,
although perhaps I missed it. It is certainly not used in many of the
examples. Since this is a very convenient way to work I think that this
should be used in the examples so that it becomes the default way to return
the instances defined in a block.


> - Declaring the list of interface signals (and their types) outside of the
>> block definition function is prone to errors:
>>
>> In MyHDL, when you define a block you put the names of the interface
>> signals in the argument list of the corresponding function. However, when
>> you call the conversion functions you must first declare the corresponding
>> signals (and their types) and then pass that list to the conversion
>> function.
>>
>> I feel that this is awkward for two reasons:
>>    - It is weird that the port type specifications are done outside of the
>> block declaration.
>>    - If you change the block declaration you must also change the code
>> that calls the conversion function.
>>
>> I imagine that the main reason for this second "awkward" syntax is that
>> Python is not a strongly typed language. Yet it seems that a more elegant
>> solution could be found. For example, perhaps a "port" decorator could be
>> added to the "hardware block functions" in which the list of port types
>> could be declared. This would put the port type declaration close to the
>> actual block definition and would let you call the pass the block
>> declaration function alone (without the list of port signals) to the convert
>> functions (e.g. you could call "toVHDL(myBlock)" rather than
>> "toVHDL(myBlock, myPort1, myPort2, myPort3)").
>>
>> I think that this enhancement could also be done in a backward compatible
>> way, since the user could still pass the list of port signals to the convert
>> function.
>>
>> An extra benefit of this approach is that this "port" annotation could be
>> used to ensure that the signals that are passed to the block function are of
>> the right type (and throw an exception if that were not the case).
>>
>>
> Would the port decorator be able to handle parameters?  The HDL modules
> need to be modular, such that I can define bit widths etc when instantiating
> the module.
>

Ideally you should be able to set default types (including sizes) for the
ports but you should also be able to tell myhdl whether you want it to
generate an exception when a user uses a different type (or Signal width)
for those parameters. Perhaps that could be done by using parameters (with
default values) but I don't really know how could that be done withing the
confines of python syntax. Any ideas?

Angel

Re: [myhdl-list] Two slightly awkward things about the MyHDL syntax

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

On Wed, Jul 14, 2010 at 10:22 AM, Angel Ezquerra <ezq...@gm...> wrote:

> Hi Jan,
>
> I am little by little learning how to use MyHDL. In general I've found that
> using python to model hardware is very nice and that the resulting code is
> very clear and easy to understand. However there are two things in the way
> that MyHDL works that feel a bit awkward to me. I'd like to give you the
> perspective of a new user so that perhaps you can try to improve MyHDL in
> this regard if you feel that these suggestion are valid :-)
>
> - Having to return the list of declared generators is odd:
>
> This is the first thing that tripped me when trying to create my first
> myhdl design from scratch. I was expecting MyHDL to infer the list of
> generators automatically. Instead you must manually return the list of
> generators that you use on each block.
>
> This is a bit annoying because it means that if you ever add new generators
> to a block or if you change their names you must remember to modify the
> function return statement to keep it synchronized with the generators that
> you are using.
>
> Note that I am not saying that the MyHDL documentation does not tell you
> about this (because it does). I am just saying that it would be much nicer
> if myhdl could track this automatically for you.
>
> Perhaps the @instance, @always and @always_comb decorators could somehow
> add a reference to the generator that is being declared into a list of local
> instances. This "instance list" could have a known name that the user could
> then return (e.g. the user could always do "return local_instances()" or
> something of the sort). The nice thing of this approach is that it could be
> 100% backwards compatible, since the user could chose to manually create the
> return list (as is done today).
>
>
This is currently support use the function instances().  Example return
instances().  It will return all generators in the module.  Adding new
generators will not require updating the return list.


>
> - Declaring the list of interface signals (and their types) outside of the
> block definition function is prone to errors:
>
> In MyHDL, when you define a block you put the names of the interface
> signals in the argument list of the corresponding function. However, when
> you call the conversion functions you must first declare the corresponding
> signals (and their types) and then pass that list to the conversion
> function.
>
> I feel that this is awkward for two reasons:
>    - It is weird that the port type specifications are done outside of the
> block declaration.
>    - If you change the block declaration you must also change the code that
> calls the conversion function.
>
> I imagine that the main reason for this second "awkward" syntax is that
> Python is not a strongly typed language. Yet it seems that a more elegant
> solution could be found. For example, perhaps a "port" decorator could be
> added to the "hardware block functions" in which the list of port types
> could be declared. This would put the port type declaration close to the
> actual block definition and would let you call the pass the block
> declaration function alone (without the list of port signals) to the convert
> functions (e.g. you could call "toVHDL(myBlock)" rather than
> "toVHDL(myBlock, myPort1, myPort2, myPort3)").
>
> I think that this enhancement could also be done in a backward compatible
> way, since the user could still pass the list of port signals to the convert
> function.
>
> An extra benefit of this approach is that this "port" annotation could be
> used to ensure that the signals that are passed to the block function are of
> the right type (and throw an exception if that were not the case).
>
>
Would the port decorator be able to handle parameters?  The HDL modules need
to be modular, such that I can define bit widths etc when instantiating the
module.

.chris

[myhdl-list] Two slightly awkward things about the MyHDL syntax

[Angel E. <ang...@gm...>]

Hi Jan,

I am little by little learning how to use MyHDL. In general I've found that
using python to model hardware is very nice and that the resulting code is
very clear and easy to understand. However there are two things in the way
that MyHDL works that feel a bit awkward to me. I'd like to give you the
perspective of a new user so that perhaps you can try to improve MyHDL in
this regard if you feel that these suggestion are valid :-)

- Having to return the list of declared generators is odd:

This is the first thing that tripped me when trying to create my first myhdl
design from scratch. I was expecting MyHDL to infer the list of generators
automatically. Instead you must manually return the list of generators that
you use on each block.

This is a bit annoying because it means that if you ever add new generators
to a block or if you change their names you must remember to modify the
function return statement to keep it synchronized with the generators that
you are using.

Note that I am not saying that the MyHDL documentation does not tell you
about this (because it does). I am just saying that it would be much nicer
if myhdl could track this automatically for you.

Perhaps the @instance, @always and @always_comb decorators could somehow add
a reference to the generator that is being declared into a list of local
instances. This "instance list" could have a known name that the user could
then return (e.g. the user could always do "return local_instances()" or
something of the sort). The nice thing of this approach is that it could be
100% backwards compatible, since the user could chose to manually create the
return list (as is done today).


- Declaring the list of interface signals (and their types) outside of the
block definition function is prone to errors:

In MyHDL, when you define a block you put the names of the interface signals
in the argument list of the corresponding function. However, when you call
the conversion functions you must first declare the corresponding signals
(and their types) and then pass that list to the conversion function.

I feel that this is awkward for two reasons:
   - It is weird that the port type specifications are done outside of the
block declaration.
   - If you change the block declaration you must also change the code that
calls the conversion function.

I imagine that the main reason for this second "awkward" syntax is that
Python is not a strongly typed language. Yet it seems that a more elegant
solution could be found. For example, perhaps a "port" decorator could be
added to the "hardware block functions" in which the list of port types
could be declared. This would put the port type declaration close to the
actual block definition and would let you call the pass the block
declaration function alone (without the list of port signals) to the convert
functions (e.g. you could call "toVHDL(myBlock)" rather than
"toVHDL(myBlock, myPort1, myPort2, myPort3)").

I think that this enhancement could also be done in a backward compatible
way, since the user could still pass the list of port signals to the convert
function.

An extra benefit of this approach is that this "port" annotation could be
used to ensure that the signals that are passed to the block function are of
the right type (and throw an exception if that were not the case).


Cheers,

Angel

[myhdl-list] Two slightly awkward things about the MyHDL syntax

[Angel E. <ezq...@gm...>]

Hi Jan,

I am little by little learning how to use MyHDL. In general I've found that
using python to model hardware is very nice and that the resulting code is
very clear and easy to understand. However there are two things in the way
that MyHDL works that feel a bit awkward to me. I'd like to give you the
perspective of a new user so that perhaps you can try to improve MyHDL in
this regard if you feel that these suggestion are valid :-)

- Having to return the list of declared generators is odd:

This is the first thing that tripped me when trying to create my first myhdl
design from scratch. I was expecting MyHDL to infer the list of generators
automatically. Instead you must manually return the list of generators that
you use on each block.

This is a bit annoying because it means that if you ever add new generators
to a block or if you change their names you must remember to modify the
function return statement to keep it synchronized with the generators that
you are using.

Note that I am not saying that the MyHDL documentation does not tell you
about this (because it does). I am just saying that it would be much nicer
if myhdl could track this automatically for you.

Perhaps the @instance, @always and @always_comb decorators could somehow add
a reference to the generator that is being declared into a list of local
instances. This "instance list" could have a known name that the user could
then return (e.g. the user could always do "return local_instances()" or
something of the sort). The nice thing of this approach is that it could be
100% backwards compatible, since the user could chose to manually create the
return list (as is done today).


- Declaring the list of interface signals (and their types) outside of the
block definition function is prone to errors:

In MyHDL, when you define a block you put the names of the interface signals
in the argument list of the corresponding function. However, when you call
the conversion functions you must first declare the corresponding signals
(and their types) and then pass that list to the conversion function.

I feel that this is awkward for two reasons:
   - It is weird that the port type specifications are done outside of the
block declaration.
   - If you change the block declaration you must also change the code that
calls the conversion function.

I imagine that the main reason for this second "awkward" syntax is that
Python is not a strongly typed language. Yet it seems that a more elegant
solution could be found. For example, perhaps a "port" decorator could be
added to the "hardware block functions" in which the list of port types
could be declared. This would put the port type declaration close to the
actual block definition and would let you call the pass the block
declaration function alone (without the list of port signals) to the convert
functions (e.g. you could call "toVHDL(myBlock)" rather than
"toVHDL(myBlock, myPort1, myPort2, myPort3)").

I think that this enhancement could also be done in a backward compatible
way, since the user could still pass the list of port signals to the convert
function.

An extra benefit of this approach is that this "port" annotation could be
used to ensure that the signals that are passed to the block function are of
the right type (and throw an exception if that were not the case).


Cheers,

Angel

[myhdl-list] "Johnson Counter" example - Using function attributes to define persistent variables

[Angel E. <ang...@gm...>]

Hi,

I am going through the MyHDL examples on the "MyHDL by example" section of
the MyHDL web page. In particular, I have just read the "Johnson Counter"
section (http://www.myhdl.org/doku.php/cookbook:jc2). I copy the
corresonding MyHDL code here for reference:

    from myhdl import *

    ACTIVE = 0
    DirType = enum('RIGHT', 'LEFT')

    def jc2(goLeft, goRight, stop, clk, q):

        """ A bi-directional 4-bit Johnson counter with stop control.

        I/O pins:
        --------
        clk      : input free-running slow clock
        goLeft   : input signal to shift left (active-low switch)
        goRight    : input signal to shift right (active-low switch)
        stop     : input signal to stop counting (active-low switch)
        q        : 4-bit counter output (active-low LEDs; q[0] is
right-most)

        """

        dir = Signal(DirType.LEFT)
        run = Signal(False)

        @always(clk.posedge)
        def logic():
            # direction
            if goRight == ACTIVE:
                dir.next = DirType.RIGHT
                run.next = True
            elif goLeft == ACTIVE:
                dir.next = DirType.LEFT
                run.next = True
            # stop
            if stop == ACTIVE:
                run.next = False
            # counter action
            if run:
                if dir == DirType.LEFT:
                    q.next[4:1] = q[3:]
                    q.next[0] = not q[3]
                else:
                    q.next[3:] = q[4:1]
                    q.next[3] = not q[0]

        return logic


In the example commentary there is an interesting discussion about using
variables instead of signals for the "dir" and "run" states. The commentary
ends with an alternative implementation of the counter which uses variables.
This alternative implementation does not use an "@always" decorator anymore.
Instead it relies in using an @instance decorator combined with a "while
True" loop and several yield statements. Again, I copy the MyHDL code here
for reference:

    def jc2_alt(goLeft, goRight, stop, clk, q):

        """ A bi-directional 4-bit Johnson counter with stop control.

        I/O pins:
        --------

        clk      : input free-running clock
        goLeft   : input signal to shift left (active-low switch)
        goRight  : input signal to shift right (active-low switch)
        stop     : input signal to stop counting (active-low switch)
        q        : 4-bit counter output (active-low LEDs; q[0] is
right-most)

        """

        @instance
        def logic():
            dir = DirType.LEFT
            run = False
            while True:
                yield clk.posedge
                # direction
                if goRight == ACTIVE:
                    dir = DirType.RIGHT
                    run = True
                elif goLeft == ACTIVE:
                    dir = DirType.LEFT
                    run = True
                # stop
                if stop == ACTIVE:
                    run = False
                # counter action
                if run:
                    if dir == DirType.LEFT:
                        q.next[4:1] = q[3:]
                        q.next[0] = not q[3]
                    else:
                        q.next[3:] = q[4:1]
                        q.next[3] = not q[0]

        return logic

Despite the benefits of this appreach (i.e. a reduction of the time that it
takes to update the state of the block) I think that the corresponding MyHDL
code is much more complex and harder to understand than the original code.
In the tutorial you explain why you must use this different approach.
Basically it is because in Python local variables lose do not keep their
value between different runs of the function they are declared in. That is,
local variables are not persistent in Python.

While this is true, a very simple solution is to instead use "persistent"
variables by declaring a attributes for the "logic()" function. That is, for
each variable that we want to use in the design, we can declare a
corresponding logic function attribute. These function attributes can be
given their initial values by setting them outside of the logic() funcion
(i.e. on the body of the "jc2()" function, after the "logic()" function has
been defined).

Using this approach I came up with the following alternative code:

    def jc2_attribute_based(goLeft, goRight, stop, clk, q):

        """ A bi-directional 4-bit Johnson counter with stop control.

        I/O pins:
        --------

        clk      : input free-running clock
        goLeft   : input signal to shift left (active-low switch)
        goRight  : input signal to shift right (active-low switch)
        stop     : input signal to stop counting (active-low switch)
        q        : 4-bit counter output (active-low LEDs; q[0] is
right-most)

        """

        @always(clk.posedge)
        def logic():
            #try:
            #    dir = logic.dir
            #    run = logic.run
            #except:
            #    logic.dir = DirType.LEFT
            #    logic.run = False

            # direction
            if goRight == ACTIVE:
                logic.dir = DirType.RIGHT
                logic.run = True
            elif goLeft == ACTIVE:
                logic.dir = DirType.LEFT
                logic.run = True
            # stop
            if stop == ACTIVE:
                logic.run = False
            # counter action
            if logic.run:
                if logic.dir == DirType.LEFT:
                    q.next[4:1] = q[3:]
                    q.next[0] = not q[3]
                else:
                    q.next[3:] = q[4:1]
                    q.next[3] = not q[0]

        logic.dir = DirType.LEFT
        logic.run = False

        return logic

As you can see this attribute-based version is pretty much identical to the
original implementation. I tested it and it works great simulation wise,
giving exactly the same result as your proposed "jc2_alt" implementation.

The problem is that MyHDL does not currently support function attributes
(calling toVHDL on my proposed design generates a very clear "¨Not
supported: attribute assignment").

I think that the attribute-based approach is very generic (i.e. it could be
applied whenever variables should be used) and it yields (pun intended :-)
much simpler and easier to understand code than the "@instance/yield"based
approach that is currently needed.

Thus, as you can imagine from this long post, I'd like to suggest that MyHDL
should get support for function attributes :-)

Cheers,

Angel

Re: [myhdl-list] Deterministic output of toVHDL

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

Jan Decaluwe wrote:
> Knut Eldhuset wrote:
>> Hi all,
>>
>> I would like the output of toVHDL to be deterministic, meaning the 
>> generated .vhd files should be identical when nothing has changed 
>> between runs. At least two things are non-deterministic in default branch:
>>
>> 1) The timestamp is included in output files.
>> 2) The order of enum typedefs in package declarations is random.
>>
>> 1) is easily fixed by monkey-patching datetime, but this is not an ideal 
>> solution.
> 
> I have recently pushed a changeset to the development repo that lets
> you define your own header (brand new - undocumented, see the source.)
> 
> With toVHDL.suppress_myhdl_header = False, you can suppress the default header.
                                    ^^^^^^^
                                    = True

obviously. Mm, may this should be more simply called toVHDL.no_myhdl_header


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] model a delay line?

[Christopher F. <chr...@gm...>]

When you declare a signal you can give it a delay, like the following.

Sig = Signal(intbv(0), delay=100)

** sent from mobile device **

On Jul 7, 2010 2:45 PM, "Thomas Heller" <th...@ct...> wrote:
I want to simulate such a triggerable oscillator (hope you can read my ascii
art;
it is a nor-gate with a delay line connecting the inverting output with an
input):

          -------
       --( delay )----
      |   -------     |
      |               |
      |   \---        |
       ----\   \O-----
            )   )
input >-----/   /----------------->  output
          /---

Does someone have an idea about how I can simulate the delay line?

--
Thanks,
Thomas


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] model a delay line?

[Thomas H. <th...@ct...>]

I want to simulate such a triggerable oscillator (hope you can read my ascii art;
it is a nor-gate with a delay line connecting the inverting output with an input):

           -------
        --( delay )---- 
       |   -------     |
       |               |
       |   \---        |
        ----\   \O----- 
             )   )
input >-----/   /----------------->  output
           /---

Does someone have an idea about how I can simulate the delay line?

-- 
Thanks,
Thomas

Re: [myhdl-list] Deterministic output of toVHDL

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

Knut Eldhuset wrote:
> Hi all,
> 
> I would like the output of toVHDL to be deterministic, meaning the 
> generated .vhd files should be identical when nothing has changed 
> between runs. At least two things are non-deterministic in default branch:
> 
> 1) The timestamp is included in output files.
> 2) The order of enum typedefs in package declarations is random.
> 
> 1) is easily fixed by monkey-patching datetime, but this is not an ideal 
> solution.

I have recently pushed a changeset to the development repo that lets
you define your own header (brand new - undocumented, see the source.)

With toVHDL.suppress_myhdl_header = False, you can suppress the default header.

With toVHDL.header = <string.Template argument> you can set your own header.

The default header is defined as follows:

myhdl_header = """\
-- File: $filename
-- Generated by MyHDL $version
-- Date: $date
"""

and you can use the same keys in your own header, it is processed by string.Template.
Same for toVerilog.


> 
> 2) can be fixed by sorting the enum typedefs by name before emitting 
> them. (I have a patch if interested)

Yes, provided it is a mercurial bundle or patch.

Thanks,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com