Re: [myhdl-list] MEP : Signal Containers

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

My brain needs some examples to get engaged.

On 06/02/2012 04:57 PM, G. Andrew Stone wrote:
> 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... <mailto: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...
>     <mailto:myh...@li...>
>     https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
> 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