Re: [myhdl-list] classes as interfaces

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

Tom Dillon wrote:
> I agree this that having something along this line would be useful.
> 
> Some time ago, I tried to create a class that would represent a complex 
> number, basically a real and imaginary signal that I could just pass around 
> as a single signal. 
> 
> It worked fine, till I tried to use toVerilog, then ran into troubles that I 
> couldn't get around. 
> 
> toVerilog would need to accept an object of a class as I/O and look inside the 
> object for any signals, each one of them becoming a port.

Yes, this is a very good idea. It's the way I would like to have support for
"signal bundling". Here are some early remarks and thoughts.

First, note that there's no problem in using "interfaces" for MyHDL modeling.
It may seem obvious, but I don't think it is: MyHDL "minimalistic" approach
makes it possible to use it in "unforeseen" ways.

Unfortunately, the minimalistic approach falls down with conversion, because
there you have to take into account another language also :-) In that case
anything not explicitly foreseen won't work. So don't get frustrated in trying
to do signal lookups in objects with toVerilog: it's not currently implemented,
and it won't work. (As always, this is only for code within generators.)

To implement this, we'll need to do some hard thinking about some details.
I would like to play the old trick to support it without requiring that
the target language supports it. In other words, you would be able to
use MyHDL interfaces even if you only have "simple" Verilog (not SystemVerilog)
or VHDL in the backend. That would be a nice bonus for MyHDL.

To do this, interfaces would have to become part of the "hierarchy" in some
way so they can get "flattened out" by the conversion. These are some
issues and implications:

- hierachy traversal is too complicated to my taste at this moment, I'd
like to simplify it before making it more complex. More specifically,
I'd like to support decorated function and generators *only*. (Currently
the convertors support all kind of generators.)

- one issue to resolve is whether interfaces should be viewed as
a "super-signal" or a "kind of module". In the first case they would
register themselves automatically (as signals do), in the second case
the designer would have to return them somewhere (as with instances).

Another issue is that sooner or later people may want to add behavior
to interfaces (this should work with modeling currently) and expect
to convert this to Verilog. Probably not required for a first version,
but something to keep in mind.

Jan

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