myhdl-list

[myhdl-list] toVerilog dynamic top level name

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

I was trying to develop a class to handle the details of synthesizing a 
MyHDL function. This was all fine except for one thing that I am stuck on.

To use toVerilog, you do:

topName = toVerilog(func,*args,**kwargs)

I could not get this to work with a dynamic topName. I tried the 
following and some other attempts as well.

exec('%s = toVerilog(func,*args,**kwargs)'%(name)

func, is the name of the MyHDL function to use, *args, **kwargs are the 
signal and parameter connections  to that function. name is a string 
representation of what the top level name should be.

I don't think this is a python limitation, either my error or  because 
of how toVerilog figures out the top level name.

Any ideas?

Thanks, Tom

[myhdl-list] Re: toVerilog dynamic top level name

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

Tom Dillon wrote:
> I was trying to develop a class to handle the details of synthesizing a 
> MyHDL function. This was all fine except for one thing that I am stuck on.
> 
> To use toVerilog, you do:
> 
> topName = toVerilog(func,*args,**kwargs)
> 
> I could not get this to work with a dynamic topName. I tried the 
> following and some other attempts as well.
> 
> exec('%s = toVerilog(func,*args,**kwargs)'%(name)
> 
> func, is the name of the MyHDL function to use, *args, **kwargs are the 
> signal and parameter connections  to that function. name is a string 
> representation of what the top level name should be.
> 
> I don't think this is a python limitation, either my error or  because 
> of how toVerilog figures out the top level name.
> 
> Any ideas?

Yes - it's ugly and it is caused by my exagerated attempts
to make things "easier" for a user :-)

My goal was to encourage the user to simulate the converted
design (because good simulation catches more errors
than the convertor does.) That's why toVerilog returns
an instance, and why I wanted to use the instance name
when naming the converted Verilog files.

So, in:

    topName = toVerilog(func,*args,**kwargs)

I need to find the string "topName". If you think about
it, you'll understand why this gets ugly. toVerilog
does crazy things: it gets its own frame info, finds
the source file, gets to the line of its own call,
and parses that to get the instance name ...
And of course, this all fails when the scheme above is not
followed (e.g. when not using the returned instance value,
or with dynamic naming).

So I apologize :-) and propose to change this to something
less "clever". Now, an issue to consider is that this would
introduce some backward incompability. So, to all those
interested: please review the following proposal carefully and
provide feedback.

I propose to drop the current instance name inference mechanism.
Instead, I would use func.func_name as the default name.
(This is the name that appears in the def statement).
Technically, this is more correct, as the Verilog file
doesn't contain an instance, but a module.

Additionally, a named parameter "name" would be introduced
in toVerilog, that can be used to override the default name
in any desired way.

For consistency, a similar thing should be done with
traceSignals.

This solution would be more general with much simpler
code. However, as I said, existing code would need to
be modified as the Verilog files will have different
names than before (by default).

[For completeness: the current implementation also infers
the name if it is subscripted, e.g. inst[0]. But this
is probably an exotic feature that nobody uses and
therefore would not be missed.]

Feedback welcome.

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: toVerilog dynamic top level name

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

Jan Decaluwe wrote:

>
> I propose to drop the current instance name inference mechanism.
> Instead, I would use func.func_name as the default name.
> (This is the name that appears in the def statement).
> Technically, this is more correct, as the Verilog file
> doesn't contain an instance, but a module.
>
> Additionally, a named parameter "name" would be introduced
> in toVerilog, that can be used to override the default name
> in any desired way.

That would work great, if you don't like the default name you can 
substitute in what you want.

Can you do this in python? 

def toVerilog(func,name=None, *args,**kwargs)

It seems like

toVerilog(add,"addTopName",x,a,b,clk)

Could get name and *args confused? Maybe I'm confused...

>
> [For completeness: the current implementation also infers
> the name if it is subscripted, e.g. inst[0]. But this
> is probably an exotic feature that nobody uses and
> therefore would not be missed.]

You could still use name="inst[%s]"%i or something like that to take 
care of that.

BTW, I never did figure out in Python how to make a dynamic variable 
name. I gave up and hacked my local copy of MyHDL to pass a sting to 
toVerilog with the name.

Tom

[myhdl-list] Re: toVerilog dynamic top level name

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

Tom Dillon wrote:
> Jan Decaluwe wrote:
> 
>>
>> I propose to drop the current instance name inference mechanism.
>> Instead, I would use func.func_name as the default name.
>> (This is the name that appears in the def statement).
>> Technically, this is more correct, as the Verilog file
>> doesn't contain an instance, but a module.
>>
>> Additionally, a named parameter "name" would be introduced
>> in toVerilog, that can be used to override the default name
>> in any desired way.
> 
> 
> That would work great, if you don't like the default name you can 
> substitute in what you want.
> 
> Can you do this in python?
> def toVerilog(func,name=None, *args,**kwargs)
> 
> It seems like
> 
> toVerilog(add,"addTopName",x,a,b,clk)
> 
> Could get name and *args confused? Maybe I'm confused...

No, you're right, it can't work like that. I thought of using
a keyword argument "name" but that would end up in **kwargs,
and we want to use that for named association with ports.

Ok - so we need another way to parametrize toVerilog's behavior.
Note that until now I have been able to avoid "options" to
the convertor, but at some point that may become unavoidable.
So we need a general way support options, and "name" would
be the first supported option.

One could think of using function attributes, e.g.
     toVerilog.name = "topname"
However, with normal functions, this has a similar problem,
as they have non-hidden attributes that we don't want to
touch, e.g. func_name.

What we would do is to create a ToVerilogConvertor class,
that defines the supported option names as attributes.
It would have a __call__ interface and toVerilog would
become an instance of that class, so that its behavior
would remain as it is now (except for the difference in
instance name inference, as discussed earlier.)

An advantage would be that the supported attributes
can be managed attributes (properties) so that we can
do any type of checking on them. Another advantage
(in the future) is that a user could create other
convertor instances with the options set to other
values, e.g. toVerilogForXilinx.

Back to our original issue: if as user wants set
the instance name to another value than the default,
the usage model would be:

    toVerilog.name = "myInstanceName"
    inst = toVerilog(func, *args, **kwargs)

I'm inclined to implement it like that - so hurry
with feedback if you want to stop me :-)

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: toVerilog dynamic top level name

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

Jan Decaluwe wrote:

> Ok - so we need another way to parametrize toVerilog's behavior.
> Note that until now I have been able to avoid "options" to
> the convertor, but at some point that may become unavoidable.
> So we need a general way support options, and "name" would
> be the first supported option.
>
> One could think of using function attributes, e.g.
>     toVerilog.name = "topname"
> However, with normal functions, this has a similar problem,
> as they have non-hidden attributes that we don't want to
> touch, e.g. func_name.
>
> What we would do is to create a ToVerilogConvertor class,
> that defines the supported option names as attributes.
> It would have a __call__ interface and toVerilog would
> become an instance of that class, so that its behavior
> would remain as it is now (except for the difference in
> instance name inference, as discussed earlier.)
>
> An advantage would be that the supported attributes
> can be managed attributes (properties) so that we can
> do any type of checking on them. Another advantage
> (in the future) is that a user could create other
> convertor instances with the options set to other
> values, e.g. toVerilogForXilinx.
>
> Back to our original issue: if as user wants set
> the instance name to another value than the default,
> the usage model would be:
>
>    toVerilog.name = "myInstanceName"
>    inst = toVerilog(func, *args, **kwargs)
>
> I'm inclined to implement it like that - so hurry
> with feedback if you want to stop me :-)


This would work, although it seems like logically a class is better for 
that. I wouldn't think to set an attribute to a function, even though 
python supports it. I am OK with it though, would get used to it, and 
probably learn and use that feature of python in other circumstances.

Let me throw in a couple more ideas:

a 2nd function,

inst = toVerilogNamed(func,name,*args,**kwargs)

or just changing toVerilog to that format, throwing backward 
compatibility to the wind. You could allow "" or None to use the default 
as it is now.

Tom

[myhdl-list] Re: toVerilog dynamic top level name

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

Tom Dillon wrote:

> Jan Decaluwe wrote:
>>
>> Back to our original issue: if as user wants set
>> the instance name to another value than the default,
>> the usage model would be:
>>
>>    toVerilog.name = "myInstanceName"
>>    inst = toVerilog(func, *args, **kwargs)
>>
>> I'm inclined to implement it like that - so hurry
>> with feedback if you want to stop me :-)

> This would work, although it seems like logically a class is better for 
> that. I wouldn't think to set an attribute to a function, even though 
> python supports it. I am OK with it though, would get used to it, and 
> probably learn and use that feature of python in other circumstances.

Perhaps we have a misunderstanding?

In the code above, toVerilog actually is an instance of a
ToVerilogConvertor class. So you do get all the goodies
of classes, instances, and attributes. However, the class
would support the special __call__ attribute, which
means you can call toVerilog as if it were a function.

When I think of it further, I think this way to do it
provides the right balance between backward compatibility
and additional power required to customize toVerilog's
behavior.

> Let me throw in a couple more ideas:
> 
> a 2nd function,
> 
> inst = toVerilogNamed(func,name,*args,**kwargs)
> 
> or just changing toVerilog to that format, throwing backward 
> compatibility to the wind. You could allow "" or None to use the default 
> as it is now.

If find neither proposal attractive. It is very well possible
that we will want to support additonal options than "name"
in the future. The proposals above don't address that.
Moreover, I believe that default usage should really be
as simple as going from:

    inst = func(*args, **kwargs)

to:

    inst = toVerilog(func, *args, **kwargs)

without having to explain about additional capabilities. For
many users and in many cases, this usage will be enough.
It is appropriate that the more sophisticated user needs
to learn a little more (e.g. that toVerilog is actually
in instance).

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