Re: [myhdl-list] MEP : Signal Containers

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

On 6/1/12 4:50 PM, G. Andrew Stone wrote:
> I've managed to read maybe 3/4 of the mail on this very long thread (and
> think I understand the MEP since I did find an error in the example).

I would call it a typo not an error since it wasn't a consistent 
throughout the MEP :)

> Somehow I got the idea that people aren't sure what value typical OO
> features would have in a hardware environment, so are considering
> leaving classes just a container for signals. Is that a correct
> assessment?

No, I don't think that is the correct assessment.  There hasn't been 
enough reasonable discussion on this topic to make a conclusion.  Also, 
the waters are murky.  For example, you mention "typical OO features". 
Two typical OO features are instantiation and inheritance.  HDLs by 
virtue support instantiation, including MyHDL.  That is a typical OO 
feature supported by HDLs.  So I don't think it is a clear-cut OO 
support yeah or neah.

I am not sure if I see how inheritance is useful.  I think it is a 
stretch to say you can describe synthesizable hardware in the same 
manner as you write OO software (yet to be proven).  There is a 
difference in representing a physical thing with OO inheritance (order 
and classification) and building a physical thing.  I will try and 
explain my thoughts with an example.

Take the common OO example, a vehicle.  You might have a base class that 
represents an abstract model like a vehicle [1].  Then from there you 
might define a truck, sports car, and limousine. You create the later 
models by inheriting a set of classes derived from the base vehicle 
class.  Now when you are creating the model for these different motor 
vehicles if you need to define the different engine powers you simply 
need to change a couple numbers.  And that is sufficient for the model.

But in real life, when building a motor you don't grab a base motor and 
change a couple attributes to get a more powerful motor.  But what you 
do do, is reuse components to build the different motors.  I think 
creating synthesiable descriptions are closer (not exact) to the 
real-world building of things than the abstract modeling.

[1] 
http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtpd1%2Foocon.html

I am aware of some HDL tools that take an somewhat software OO model and 
try to generate hardware.  But best of my knowledge these tools first 
compile the OO down to simple instructions to be executed (byte code) 
and then rebuild a hardware description from the byte code.  I don't 
think a tool like this fits the domain of MyHDL.  It might be a tool 
that uses MyHDL but I don't think it would be explicitly part of MyHDL.

OO for hardware design, as I currently see it, is useful for modeling. 
And useful for organizing, parameterizing, and modularizing the 
synthesizble hardware descriptions.  But the synthesizable (convertible 
subset that can be synthesized) is in a form similar to what exists.

> Or is the problem that we don't know how to translate OO
> into verilog/vhdl?  If its the former, I'd like to propose a couple of
> examples that would use OO features and then you guys can pick them
> apart and tell me how its all possible with myHdl today :-).
>

My rational for this MEP is that it fits the current structure and it is 
useful on its own (it is more than just class/object signal container). 
  More importantly OO support as some people may envision it will take 
quite a bit of hashing through (conversation).

In addition, the yet to be define OO representation, more than likely, 
will require substantial conversion code modifications.  Making 
near-term inclusion unlikely.  The conversion code is quite complex. 
You need an strong understanding of the MyHDL design, the Python AST, 
and detailed knowledge of Verilog/VHDL.

I think your examples in a separate thread would be worth some 
discussions and debate.  Just be prepared.  I think it is reasonable to 
expected some onus by the proposer.  The idea person also needs to be 
the person that can provide details to some extent.  I don't think it is 
reasonable for someone to only have the "idea" and expect others to come 
up with all the details.  It makes the conversations difficult and more 
than likely won't go too far because the detail creators are yet to 
share the vision.

Regards,
Chris