Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

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

On 5/17/12 5:22 AM, Oscar Diaz wrote:
> 2012/5/16 Christopher Lozinski<loz...@fr...>:
>> First thank you for the comments on my hardware module proposal.  I
>> learned a lot.  I always learn a lot from this group.
>>
>> On 5/16/12 6:58 AM, Oscar Diaz wrote:
>>> And following with the previous discussion, Christopher has proposed a
>>> particular abstraction through his Hardware Module Class. Although I
>>> think it's a correct proposal, maybe it's not suitable in other cases.
>>> Let me give you an example:
>>
>> So first I will admit I am extreme.  There is always a spectrum between
>> the functional approaches, and the object-oriented approaches.  I
>> strongly lean one way.  The lesson from python is that to gain broad
>> market adoption, both approaches must be supported.  But there are
>> reasons why I am extreme.
>>
>> One of my core beliefs is that software components should map directly
>> to hardware components.   It is just so much easier to understand.  Then
>> as the world changes, as the design evolves, the software component is
>> more likely to evolve easily.
>
> Well, keep in mind that developing software comes with a price in
> terms of performance, if you compare it with a pure hardware
> implementation; I mean a processor, as a general-purpose hardware, is
> slower, bigger and more power hungry that a custom hardware. On the
> other hand, designing hardware is more complex than writing software.
> Here you need to find a compromise between performance and complexity.
> I'm telling you this because, for some applications you just need to
> design for top performance (and of course, you have to deal with the
> added complexity).

I agree, you don't want to comprises the generality of MyHDL (the 
ability do explicitly describe the low-levels) in exchange for a 
different abstraction layer.  That is why I believe this VHLD 
(very-high-level-description) will be a separate package that uses MyHDL 
but not incorporated into MyHDL.

>
>> So if you do not want to initially model
>> ports, that is fine.  But do still have a class that models your high
>> level hardware module.  Of course if you are working at even higher
>> levels, no worries.
>>
>> Sure people can say this is just a software library.  Let us call it
>> OOHDL.   For Object-Oriented HDL.  But it is much more than that.  It is
>> a world view.   You get some benefit from reusing libraries.  You get a
>> lot more benefit from having a certain world view.   There are many
>> benefits from this world view, but the primary one is for new users.
>> Imagine the sales pitch.
>>
>> OOHDL is a library of objects for modeling, designing and simulating
>> digital designs.  Each class represents a real world hardware module
>> like clocks, multiplexers, memory, and other devices.   You use a
>> graphical tool to assemble your design from software components, or even
>> to design new components.  You can click into each hardware module to
>> see the hardware hierarchy. When you need to, you can even create new
>> hardware modules in python, optionally reusing existing hardware modules.
>>
>> By retaining the MyHDL functional approach, you greatly loose the
>> benefits of a pure OO approach, particularly the ability for new users
>> to understand, learn and use the system.   Let there be no doubt that I
>> had and still do have huge difficulty understanding MyHDL.  A class
>> library matching to hardware modules and signal types would have been so
>> much easier for me to understand, subclass and assemble.
>
> I understand your motivation, and I think is a valid idea. But, as I
> said it comes with a price: when you develop a digital design with
> OOHDL, you're imposing a particular way to model its modules, i.e. the
> way you declare ports, or how the relationships between modules are
> made.

Unfortunately, I don't understand his motives and not sure if it is a 
valid idea.  It would take much more conversation than I committed to 
right now.  But I don't know if I see the use (doesn't mean I can't be 
convinced) of a object inheritance building scheme for designing 
hardware behavior that is actually synthesized to hardware.

What I mean by this is that current HDLs use instantiation largely. 
They aren't considered OO languages but HDLs had instantiation from the 
get go.  You can build something out of other things, kinda like you do 
in real life.  But what you don't do is *inherit*.  A shift register 
does not inherit from a flip-flop but you could described a 
shift-register by instantiating a gaggle of ff.  I don't know if I see a 
use for hardware description which uses inheritance.

As we said, not much interest in this low-level building only useful for 
discussion.  For a more complex example, how would you propose building 
different Ethernet controllers and Ethernet tcp/ip offload engines off 
*inheritance* vs. instantiation.  I can visualize where component reuse 
is utilized (same as current instantiations and parameterization) but 
not via OO inheritance.

Regards,
Chris Felton