[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