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

[Oscar D. <osc...@gm...>]

2012/5/12 Christopher Felton <chr...@gm...>:
> On 5/3/2012 10:03 AM, G. Andrew Stone wrote:
>> In fact, what I thought myHDL was going to let me do is create classes that
>> define blocks of logic at the RTL level (synthesizable), perhaps with
>> inputs and output "Signals" as variables passed in the constructor and then
>> by instantiating those classes I'd be in effect plunking down copies of
>> that logic in the FPGA (or within larger logic blocks by instantiating
>> these within the constructor of another class).  4 years ago I did not ever
>> figure out how to do this... I don't think anything wrapped in a class was
>> synthesizable back then.  But maybe that has changed now; I haven't tried
>> using classes since.
>
> These are some good points and similar topics pop up here and there. And
> based on these threads Jan D. has made some good changes to the
> documentation; -splitting the sections- and the "What MyHDL is not"
> page.  Hopefully, these help set the expectations and clear up some of
> the confusion?

Sorry for joining the thread so late, but I want to tell my opinions
about OO paradigm for hardware development.

I agree everyone has different objectives and needs when using MyHDL;
in my case I want to use it mostly for synthesis (I mean replace VHDL
in my daily work, letting MyHDL to generate the code to pass the
synthesizer), but also I did some simulation stuff. IMHO the direction
this project is following is the correct one: a generic paradigm where
you have concurrent objects with "signal" objects that communicate
them, and a event-driven simulation support (Jan: correct me if I
misunderstood something ;) ). And based on this paradigm you build
your models or even frameworks for your modelling (and implementation)
needs.

OO paradigm is implicit in HDL development, a synthesized design is
described by primitive objects and connections between them. The
interesting part is to make the correct abstractions in order to make
your design efforts easier and/or error-proof...

>
>  From my point of view; your class use case is only partially usable. If
> you pass the ports to the instantiation that object is literally "tied"
> in a particular use.  If I follow your description, in the following
> example I have a hypothetical python class and python function
> implementations, which is which.
>
>    a,b,c,d,w,x,y,z = [Signal(False) for ii in range(8)]
>    iFoo = Foo(a,b,w,x)
>    iBar = Bar(c,d,y,z)
>    toVerilog(iFoo, a,b,w,x)
>    toVerilog(iBar, c,d,y,z)
>
> If I added more code (use code not implementation) it might become
> clearer which is which.
>
> In my case, I actually do not want to pass the "ports" to my
> instantiation but rather the parameters of the design.  If we are
> talking about using classes to model and describe complex pieces of
> hardware the "IP" usually includes much more than the hardware description.
>
> If you get a complex piece of IP today is has a ton of stuff that comes
> with it.  It has the hardware description (Verilog/VHDL), scripts galore
> (tcl or worse perl), and models in C/C++/SystemC, Matlab, or whatever
> else HLL.  In my mind, Python/MyHDL objects are a great tool for
> simplifying complex IP organization.

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:

I want to design a module that has some I/O ports, that are part of a
bigger system compound by some of those modules interconnected between
them. First part of the design process is to check the communication
scheme used at a system level, so I want to build a model at high
level, just taking account of the flow of the information, but
ignoring low level details like ports. My model will consist of a
class that has an interface for message passing, and make the
simulation model by instantiate several objects and make its
connections for that message passing. Of course, I want to go further
until its implementation, but this first verification step is needed
in my design, and therefore I propose my own set of classes and
methods.

What I wanted to say is that Christopher's proposal maybe is not
suitable for all cases, and IMHO one of the strengths of MyHDL is that
it doesn't tie you to a particular way to describe your objects at
high level, the only condition is that you provide a list of
generators and signals that link them, but you can use whatever you
want to create them.

The Hardware Module Class can be the base class of a particular set of
IP cores, but it shouldn't be part of core MyHDL. In this case, making
an analogy to software development, you could think this class as a
"library" that "programs" (IP cores) can use.

>
> Software to sea of gates (SoG) isn't a MyHDL thing.  This is an industry
> trend / problem to solve.  If you happen to be the person to correctly
> solve, you probably would have you billions and sitting on a beach some
> where :)  That assumes it is solvable with a generic high-level
> description or translation from existing program languages.
>
> <snip>
> On 5/3/2012 10:03 AM, G. Andrew Stone wrote:
>> The fact of the matter is that Jan seems to have written myHDL to solve
>> issues in complex hardware design and hardware simulation that only experts
>> in the field can understand (either that or they are such totally obvious
>> mistakes in doing a simulation that any software person would think OMG!!
>> so we think that that CAN'T be the real issue:-)  ) and a lot of us are
>> trying to twist the project to: 1. make it really easy to do quick and
>> dirty FPGA hackups 2. learn how to program these "seas of gates".
>
> To get to the quick and dirty FPGA, as Jan D. eluded we probably need a
> large open-source IP collection.  Then someone can tie together a bunch
> of components and implement something.
>
> 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

Best regards
-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument