myhdl-list

[myhdl-list] Name generation RTL components

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

Suppose you have an n-input xor gate described like:

def xor(a, z, width):
    ....

in which 'width' specifies the number of input (length of 'a').
Suppose you want to generate both a 3-input and 4-input xor.
How to generate unique names? Now you can execute:
    toVerilog,name = 'xor_3'
    toVerilog(xor, a, z, 3)
    toVerilog,name = 'xor_4'
    toVerilog(xor, a, z, 4)

Maybe it is a suggestion (as opposed to toVerilog.name = 'myName') with
verilog and/or VHDL generation to insert a name giving function in the
definition of 'xor' itself:

def xor(a, z, width):
    set_my_name("xor_%d" % width) # or whatever...
    ....

This would make the name attribute superflous, I think.

-- Jos

Re: [myhdl-list] Name generation RTL components

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

Jos Huisken wrote:
> Suppose you have an n-input xor gate described like:
> 
> def xor(a, z, width):
>     ....
> 
> in which 'width' specifies the number of input (length of 'a').
> Suppose you want to generate both a 3-input and 4-input xor.
> How to generate unique names? Now you can execute:
>     toVerilog,name = 'xor_3'
>     toVerilog(xor, a, z, 3)
>     toVerilog,name = 'xor_4'
>     toVerilog(xor, a, z, 4)
> 
> Maybe it is a suggestion (as opposed to toVerilog.name = 'myName') with
> verilog and/or VHDL generation to insert a name giving function in the
> definition of 'xor' itself:
> 
> def xor(a, z, width):
>     set_my_name("xor_%d" % width) # or whatever...
>     ....
> 
> This would make the name attribute superflous, I think.

A couple of comments:

As the parameter list of toVerilog/toVHDL is used for ports and
parameters, we can't use it for HDL conversion configuration.
The idea to use function attributes such as 'name' is to have
a "second level" of parametrization for this purpose. I see
this as a general, extensible mechanism, and I expect more
attributes may be added in the future. BTW, for toVHDL I
have already added another one called 'configuration_declarations'.
(See the recent what's new document for 0.6).

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.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

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.

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