Re: [myhdl-list] MEP : Signal Containers

[G. A. S. <g.a...@gm...>]

ok great!  I would have no intention to drop all the work on someone else's
lap :-) and I agree that OO additions should not be done quickly.  This
actually fits my own schedule anyway as I might be freeing up a bit in a
month or so.  But at the same time, I have no intention to evangelize these
ideas -- I mean if there's no spark of interest in the community I do not
have the time to create the "mind-share" (as VCs say).  Or I was thinking
that maybe someone has already shown that the current conversion code is
somehow inimical to OO...

You said:
"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)."

I think that you are correct and that is not the point.  I think that you
just said something like, "I think it is a stretch to say you can pry the
lid off this paint can in the same manner as you drive screws".  You can't
do it in the same manner, but the question is can we use the same tools?

Perhaps I used the term "OO" too generically; I was not only referring to
the classic OO concepts but also the post-OO design patterns which OO
enables.  For example, it sounds from your motor example like you would
benefit from the mixin pattern:  http://www.linuxjournal.com/node/4540/print.
Wouldn't it be cool if a SOC could be created by mixin of different classes
that represented SPI, I2c, flash, ram and other resources?  Or, to avoid
Jan's comment about how myHdl is not schematic capture, this design
paradigm could be used to pull in groups of instructions (logic,
arithmetic, flow control, fp) to build a soft uP with an instruction set
optimized for a particular application.

WRT inheritance, perhaps a simple but valuable use would be to extend IP
while maintaining backwards compatibility.  For example you have the
wishbone bus as an example in the MEP.  What about using inheritance to
define a Wishbone16 that is clearly (because it inherits from the prev gen)
100% backwards compatible with the standard Wishbone but offers 16bit data
transfers.  If you instantiate Wishbone16, you can give it to old IP blocks
that take a "Wishbone" bus without having to modify that old code.  But
this example still uses the "classic" formulation of a class essentially as
a concrete entity as typified by your car example... but there are more
advanced uses of classes that may have hardware analogues...

This is just a quick taster; is going to take me a couple days to formulate
something with actual examples, etc.

Cheers!
Andrew


On Sat, Jun 2, 2012 at 8:01 AM, Christopher Felton
<chr...@gm...>wrote:

> 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
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>