myhdl-list

Re: [myhdl-list] How to make MyHDL Object-Oriented

[Jan D. <ja...@ja...>]

On 05/04/2012 02:18 PM, Christopher Lozinski wrote:
> On 5/4/12 5:04 AM, Jan Decaluwe wrote:
>> On 05/04/2012 01:45 AM, Christopher Lozinski wrote:
>>> Thanks enormously to Andy Stone for pointing out that MyHDL,
>>> while in Python is not object-oriented.  There is no hardware
>>> module class, just a generator, and decorator which are
>>> functional approaches.
>> How can you even say this,
>
> Actually the wiki says it.
>
> http://www.myhdl.org/doc/0.6/manual/intro.html In MyHDL, classic
> functions are used to model hardware modules. In particular, the
> parameter list is used to define the interface.

Point taken. However, I am not sure how to change that for full
generality in an introductory chapter, without being overly confusing
to new users.

However: it is true that I think that the approach based on functions
is the best choice for a first step. It is correct that I wanted to make
things as simple as possible for hardware designers, especially Verilog
designers, with no exposure to object-orientation in their HDLs.
It is also true that conversion was written with this choice in mind
in the first place.

> I would rather see objects being used to model hardware modules. In
> particular the instance variables should be used to model the
> interface. (and internal signals).

You can do that today.

> Here is another one.
> http://www.myhdl.org/doc/current/manual/modeling.html
>
> In MyHDL, an instance is recursively defined as being either a
> sequence of instances, or a generator. Hierarchy is modeled by
> defining instances in a higher-level function, and returning them.
>
> That does sound to me like a functional approach. I would rather see
> hardware modules defined "in a higher level object" a module with
> parent and child nodes. I would expect a hierarchy of chip modules,
> each of which points to its children and parents.
>
> Then let me quote others: Andrew Stone said this is what he
> expected:
>
> 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.
>
> And yes, Dillon wrote that he does this, but I think we will find the
> details of how he does it are different than at least what I would
> expect. In particular MyHDL does not pass variables into the object
> constructor, it passes them into the generator. There are no parent
> or child links.
>
>
>> when the manual has a section about object-oriented modeling, which
>> has a Queue class, which you have just been struggling with?
>
> If I recall correctly, the Queue class is not inside a @always,
> @instance, or @always_comb, so it is not synthesizable. While MyHDL
> is quite general, it is only the synthesizable stuff I am interested
> in.

Then you should clearly say so in your communication. Otherwise your
statements are totally confusing to people, including myself, who
are equally interested, or even more so, in other aspects of MyHDL.

> Jan Decaluwe wrote:
>
>> Perhaps this stuff really is too hard for the "general python
>> developer", though I
>
>> still don't understand why.
>
> Because it does not fit the way we see the world. Different people
> have different world views. I am doing my best to explain my world
> view. In particular one of my concepts is that every real world thing
> should be represented by a class. So flip flops, adders, multipliers
> should each be represented by a class. And then I mostly want the
> documentation to be a listing of the classes, representing physical
> objects, available to me to work with. And yes the existing MyHDL
> documentation would also be useful.

But that is a low-level view that I'm not interested in at all!
I don't care about models for flip-flops, adders, multipliers etc -
I have synthesis tools that infer them efficiently and by the dozen
from the behavior of my code, without requiring my attention.
(Of course, I know about them very well, to judge the quality
of the synthesis result in the back end).

But if you insist - you can do that today, and then work at
the net list level in MyHDL connecting them. Just add some print method
to each class that prints out the instance representation in some
technology in Verilog and you are done - you have a netlist
generator. No conversion needed, and no synthesis for that matter.

> I now understand it is a hugely different view from the prevailing
> view on this mailing list. And that is why we keep clashing. It is
> why I am just not able to 'get' MyHDL. Because we are operating under
> two different world views.

And I don't buy that. More important than the software
technique is the abstraction level at which
you are working. Your object-oriented approach is just a low-level
approach in disguise - not interested.

You don't get MyHDL because you don't yet get the basics of
HDL-based design. Unfortunately, I don't see an alternative
of getting your hands dirty and building up experience
yourself, painstakingly.

Trying out Verilog, as you announced, may actually be a wise
step. If you are happy with it, all the better. But if you
are not, I trust the discussion will become much easier.

Look at it this way. Synopsys has become very rich by selling
great synthesis tools. But after all these years, I am still
not aware of a reference work that I can recommend to really
learn what synthesis can do.

Don't expect some poor open-source guys to fill in that gap.

>
> -- Regards Christopher Lozinski
>
> Check out my iPhone apps TextFaster and EmailFaster
> http://textfaster.com
>
> Expect a paradigm shift. http://MyHDL.org
>
>
>
> ------------------------------------------------------------------------------
>
>
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


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] How to make MyHDL Object-Oriented

[Christopher L. <loz...@fr...>]

Jan Decaluwe wrote:

    Coupling a sensitivity list to a module makes no sense.

Understood.  Here is the source of my confusion.

The manual says:

    Hardware descriptions need to support the concepts of module
    instantiation and hierarchy. In MyHDL, an instance (of a hardware
    module) is recursively defined as being either a sequence of
    instances, or a generator.

There are really two concepts here.   One is a high level module which
is recursively represented by a sequence of submodules.  And the other
is a leaf module which is represented by a generator.  Ports can be
associated with both high and low level modules   The logic,  generator 
and sensitivity lists are only associated with the leaf module.  Or we
could call them atomic and compound hardware modules.

Did I get that correct?   If so, thanks Jan for clearing that up for me. 

Accordingly I have updated split the Hardware Module class definition in
two here:

wiki.myhdlclass.com:8080/OOHDL

But that still does not solve all my problems for these classes. Back to
the Manual.

    The clock driver function ClkDriver() has a clock signal as its
    parameter. This is how a /port/ is modeled in MyHDL.


In the page on Atomic and Compound Hardware modules, I model ports as
public instance variables.  And internal signals as private instance
variables.    It is how experienced python developers expect to see
things.  It is natural for us to think of ports as instance variables. 
Then you can get inheritance of ports for  free as Hardware Modules are
subclassed.  The port methods automatically remove Children and Parents
from the instance variable list.  With this design, one would not have
to list all the ports repeatedly in the generator function for each
subclass.  They just get inherited.  Brings us a step closer towards
rich libraries of hardware modules that can be subclassed.  Cool! 

But there is a problem, as that is not how MyHDL models ports.  It is
not just an implementation problem.  It is a conflict between how
experienced Python developers see the world, and the functional approach
favored by experienced hardware engineers. 

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

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

[Jan D. <ja...@ja...>]

On 05/03/2012 10:23 PM, G. Andrew Stone wrote:
> Hi Jan,
>
> Let me try to say it in another way.  Please forgive any
> inaccuracies; its been a few years! :-)
>
> If my synthesizable hardware description was put in a simulation
> black box (call it "hdl") with some simple API that could be used
> like:
>
> hdl.start() for time in range(1,whatever): output_signals =
> hdl.next(list_of_input_signals)
>
> then as a software engineer I'd completely understand how to write a
> complex simulation and testbench around it.  For example, if my "hdl"
> object defined a PCI bus card I could pretty easily write Python code
> that jams in a bunch of fake PCI requests and make sure the right
> stuff comes out.  I could easily make up code that runs a bunch of
> these black boxes simultaneously and use unsynthesizable python to
> "glue" them together to make a larger system -- thereby simulating a
> subset of some larger system.  I could even have each black box
> "running" at different clock speeds.  Or I could even hook the
> simulation black box up to the actual code that will run on a CPU and
> talk to my FPGA.
>
> So I (as a software professional) don't need myHDL to help me do
> that.  What I need is it to help me with is what's inside that black
> box.  But the docs (but please remember my heavy use was several
> years ago) keep trying to teach me how to do the testbench part.
> This confused me because I kept thinking I was writing synthesizable
> code.

I don't want to start a discussion about the merits of your point
of view, but again I point out that heavy MyHDL users, myself included,
see things entirely differently.

I developed MyHDL because I wanted to do modeling and verification
in python, and stock python didn't give me the fine-grained threading
and event-driven paradigm needed. At that time, it was not clear if
it was desirable or even possible to do conversion as a path to synthesis.

If synthesizable code would be all it did, I wouldn't see the point.
I always assumed that would be obvious to other MyHDL users but
I recognize this is an assumption that may have been too implicit.

Anyway, it explains why I'm not interested in discussions when MyHDL
is limited to that aspect: it is not my world. And there are further
reasons. The continuous identification of MyHDL "limitations" with
conversion or even synthesis limitations is tiresome. And it is
demotivating. I hardly hear any talk about the HDL limitations
that MyHDL actually lifted in comparision to $$$ synthesis, e.g.
by the way conversion works after elaboration, and how it does
integers.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

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

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

On 5/3/2012 3:23 PM, G. Andrew Stone wrote:
> Hi Jan,
>
> Let me try to say it in another way.  Please forgive any inaccuracies; its
> been a few years! :-)
>
> If my synthesizable hardware description was put in a simulation black box
> (call it "hdl") with some simple API that could be used like:
>
> hdl.start()
> for time in range(1,whatever):
>    output_signals = hdl.next(list_of_input_signals)
>
> then as a software engineer I'd completely understand how to write a
> complex simulation and testbench around it.  For example, if my "hdl"
> object defined a PCI bus card I could pretty easily write Python code that
> jams in a bunch of fake PCI requests and make sure the right stuff comes
> out.  I could easily make up code that runs a bunch of these black boxes
> simultaneously and use unsynthesizable python to "glue" them together to
> make a larger system -- thereby simulating a subset of some larger system.
> I could even have each black box "running" at different clock speeds.  Or I
> could even hook the simulation black box up to the actual code that will
> run on a CPU and talk to my FPGA.
>
> So I (as a software professional) don't need myHDL to help me do that.
> What I need is it to help me with is what's inside that black box.  But the
> docs (but please remember my heavy use was several years ago) keep trying
> to teach me how to do the testbench part.  This confused me because I kept
> thinking I was writing synthesizable code.
>

I don't understand where the confusion comes from?  Both Python and 
MyHDL are tools -languages/tools- that help us build *things* as you 
suggest.

Example, I have a verification framework that I use for building and 
verifying DSP modules.  This has a mix of non-HDL blocks and HDL blocks. 
  Here is a brief preview.

     from myhdl import Simulation
     import blocks
     from filters import MyFilter
     sine1 = blocks.sources.Sine(frequency=40e3, sample_rate=1e6)
     sine2 = blocks.sources.Sine(frequency=30e3, sample_rate=1e6)
     a1 = sine1 + sine2
     flt = MyFilter(a1)
     plot1 = blocks.sinks.Plotter(sine1, sine2, a1, flt)
     v1 = blocks.sinks.VerifySequence(flt, exact=False, vfunc=vfunc)
     Simulation(blocks.GetAllGenerators()).run()

This simple example verifies the expected output of the HDL filter.  OO 
design was used heavily in this framework.  MyHDL and Python are at the 
core, the technologies that enabled me to build such an environment. 
Without MyHDL's objects, functions, and *quality* I would have had to do 
a ton more work (which would have made it non-feasible).  MyHDL enables 
me to have a competitive advantage!

I have had to build, what feels like thousands of simulation models over 
the years, everything from C/C++/SystemC, HDLs, Matlab, etc.  Some of 
these were non-HDL models, others mixed, and others pure HDL.  But 
nothing has been more efficient to develop than Python/MyHDL!  And now 
with the performance improvements I get to watch colleagues never meet a 
schedule and the one weak argument they had ... is irrelevant.

Here is another example:

     @instance
     def tb_stimulus():
        # Write Wishbone memory mapped device
        yield fx2Model.WriteAddress(0x0101, 1)
        yield fx2Model.WriteAddress(0x0103, 0xAA)
        yield fx2Model.ReadAddress(0x0103, rbuf)
        [fx2Model.Write(data, fx2Model.EP4 for dat in test_data1]
        # Wait for the data to transfer
        yield fx2Model.IsEmpty(fx2Model.EP4)
        ...
        raise StopSimulation

In this example I have a model with "transactors".  The transactors 
bridge my event driven model world to the HDL world.

I guess from my point of view you can build frameworks with the 
interfaces you might want.  And these interfaces might be different for 
each problem to solve.

Regards,
Chris

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Uri N. <ur...@gm...>]

At the time it took me a while to wrap my mind around the Queue example,
since it introduces a different aspect of using MyHDL, which is more of a
system architecture tool.

IMO this merits a separate chapter, since one can drop the RTL/Synthesis
requirements in favour of a different style of programming. I'd be happy to
prepare some concrete examples for further discussion.

On 2 May 2012 23:58, Christopher Felton <chr...@gm...> wrote:

> On 5/2/2012 1:52 PM, Uri Nix wrote:
> > IMHO it /is/ confusing, since the previous topics in the chapter are
> > synthesis oriented.
>
> The manual under "Modeling techniques" currently progresses; structural,
> RTL, High-level.  Do you think a top-down versus bottom-up order would
> be better?  Someone *without* a HW design background may find;
> High-level, RTL, structural order less confusing?  Or, in your opinion,
> do you think it needs to be a completely separate chapter?
>
> Regards,
> Chris
>
> >
> > I have had very good experience with MyHDL for system modelling, which
> uses
> > a different mindset than the FPGA direction. It is amazingly powerful,
> > follows similar idioms as in SystemC with the ease of Python, and might
> use
> > some more mention.
> >
> > Cheers,
> > Uri
> >
> >
> > On 2 May 2012 18:55, Tom Dillon<td...@di...>  wrote:
> >
> >>   I think the manual is clear and it makes pretty good sense what can be
> >> converted.
> >>
> >> One of the great things about MyHDL/Python is that as long as your code
> at
> >> the lowest level is RTL, then it will convert.
> >>
> >> You can use all the power of Python of top of that to make very high
> level
> >> structures.
> >>
> >>
> >>
> >> On 05/02/2012 10:30 AM, Jan Decaluwe wrote:
> >>
> >> On 04/27/2012 02:52 AM, Christopher Lozinski wrote:
> >>
> >>
> >>   The higher level approach is to model things as objects. There is a
> >> queue example in the docs.  This stuff blows my mind.  How that can be
> >> synthesized, what it means in terms of hardware functions, I really do
> >> not yet understand.   Sure the queue example is easily understandable to
> >> a software engineer, but what does that look like when converted?
> >>
> >>   I went back to the manual, to understand where so much confusion can
> >> come from.
> >>
> >> But really, I don't see it. I think the manual is crystal clear. In the
> >> chapter you refer to, it describes a number of modeling options that
> >> MyHDL supports. When it talks about RTL, it explicitly makes the
> connection
> >> with synthesis. Then it moves on to high-level modeling - I think
> >> it's obvious that there is no direct link with synthesis.
> >>
> >> To understand the link between conversion and synthesis, move to the
> >> chapter about conversion. It explicitly states that the first goal
> >> of conversion is synthesis, but also that the convertible subset
> >> is more general than the synthesizable subset. And it describes
> >> the convertible *subset*.
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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
> >>
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Christopher L. <loz...@fr...>]

Jan Decaluwe wrote:

    Coupling a sensitivity list to a module makes no sense.

Understood.  Here is the source of my confusion.

The manual says:

    Hardware descriptions need to support the concepts of module
    instantiation and hierarchy. In MyHDL, an instance (of a hardware
    module) is recursively defined as being either a sequence of
    instances, or a generator.

There are really two concepts here.   One is a high level module which
is recursively represented by a sequence of submodules.  And the other
is a leaf module which is represented by a generator.  Ports can be
associated with both high and low level modules   The logic,  generator 
and sensitivity lists are only associated with the leaf module.  Or we
could call them atomic and compound hardware modules.

Did I get that correct?   If so, thanks Jan for clearing that up for me. 

Accordingly I have updated split the Hardware Module class definition in
two here:

wiki.myhdlclass.com:8080/OOHDL

But that still does not solve all my problems for these classes. Back to
the Manual.

    The clock driver function ClkDriver() has a clock signal as its
    parameter. This is how a /port/ is modeled in MyHDL.


In the page on Atomic and Compound Hardware modules, I model ports as
public instance variables.  And internal signals as private instance
variables.    It is how experienced python developers expect to see
things.  It is natural for us to think of ports as instance variables. 
Then you can get inheritance of ports for  free as Hardware Modules are
subclassed.  The port methods automatically remove Children and Parents
from the instance variable list.  With this design, one would not have
to list all the ports repeatedly in the generator function for each
subclass.  They just get inherited.  Brings us a step closer towards
rich libraries of hardware modules that can be subclassed.  Cool! 

But there is a problem, as that is not how MyHDL models ports.  It is
not just an implementation problem.  It is a conflict between how
experienced Python developers see the world, and the functional approach
favored by experienced hardware engineers. 

-- Regards Christopher Lozinski Check out my iPhone apps TextFaster and
EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Tom D. <td...@di...>]

On 05/05/2012 02:59 PM, Christopher Lozinski wrote:
> In the page on Atomic and Compound Hardware modules, I model ports as
> public instance variables.  And internal signals as private instance
> variables.    It is how experienced python developers expect to see
> things.  It is natural for us to think of ports as instance variables.
> Then you can get inheritance of ports for  free as Hardware Modules are
> subclassed.  The port methods automatically remove Children and Parents
> from the instance variable list.  With this design, one would not have
> to list all the ports repeatedly in the generator function for each
> subclass.  They just get inherited.  Brings us a step closer towards
> rich libraries of hardware modules that can be subclassed.  Cool!
"Experienced python developer", what is that? I am not sure what that 
has to do with anything.

There is nothing unnatural about MyHDL. Again, trying to draw somebody 
into a meaningless discussion.
>
> But there is a problem, as that is not how MyHDL models ports.  It is
> not just an implementation problem.  It is a conflict between how
> experienced Python developers see the world, and the functional approach
> favored by experienced hardware engineers.

MyHDL works fine. I fail to see a conflict at all.

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Jan C. <jan...@mu...>]

On 06/05/12 06:35, Tom Dillon wrote:

> "Experienced python developer", what is that? I am not sure what
> that has to do with anything.
True. An "Experienced python developer" is most likely someone who 
has gained some control over a machine at a very high level of 
abstraction. They may know little or nothing about the 
progressively differing layers of software beneath, supporting 
their code.  Likely, the further layers of hardware concepts 
expressed below are completely out of sight.

> There is nothing unnatural about MyHDL. Again, trying to draw
> somebody into a meaningless discussion.
I think he's angling to get a fish, a big one.  A person wanting to 
learn to fish would need to be interested in understanding and 
clearly distinguishing the names of the tools, behaviour of fish, 
affects of tides, etc.  Asking why angling is not an iPhone app 
that can be run, sat on a bench in the park while watching bowls is 
pointless.

> MyHDL works fine. I fail to see a conflict at all.
I'm struggling, but much too inexperienced with Python to suggest 
changing any of MyHDL.

My hardware experience started with borrowing my mums breadboard 
and dressmaking pins, and using surplus germanium diodes and 
transistors.  I still like to know the details of the fabric I'm 
using.

Today I still have questions, for example: Do clockless gate arrays 
use standard SRAM blocks in an async wrapper, or are they async to 
a much lower level than this.  It may seem pointless to ask, but it 
would help me to estimate the reliability of tools which translate 
RTL designs to use a clockless fabric. [1]

But this extremely low-level interest might hinder my progress in 
using MyHDL in a similar way to having an insufficiently deep 
understanding of electronics.  I'll need to work to get the balance 
right.

It has been a hard struggle for me to get started with MyHDL, 
hopefully we can work out why, and make it easier for others in the 
future.

Jan Coombs
-- 
[1] www.achronix.com

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Christopher L. <loz...@fr...>]

On 5/6/12 12:35 AM, Tom Dillon wrote:
> MyHDL works fine. I fail to see a conflict at all. 

There is a huge difference between representing signals are arguments to
a function, and as instance variables on an object.   The later supports
inheritance, and quickly leads to rich libraries of Atomic and Compound
Hardware Module libraries.  I am sincerely sorry you do not see the
difference.  If there is any way I can help you understand the issues,
please let me know.  Wait for the punchline.
.
.
.
.
.
.
.
.
.

You just need more experience with Object-Oriented Modelling.
.
.


-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Tom D. <td...@di...>]

Now I get it, you need us all to know that you are an experienced python 
programmer (more experienced than the audience here) and also witty.

On 05/06/2012 06:17 AM, Christopher Lozinski wrote:
> On 5/6/12 12:35 AM, Tom Dillon wrote:
>> MyHDL works fine. I fail to see a conflict at all.
> There is a huge difference between representing signals are arguments to
> a function, and as instance variables on an object.   The later supports
> inheritance, and quickly leads to rich libraries of Atomic and Compound
> Hardware Module libraries.  I am sincerely sorry you do not see the
> difference.  If there is any way I can help you understand the issues,
> please let me know.  Wait for the punchline.
> .
> .
> .
> .
> .
> .
> .
> .
> .
>
> You just need more experience with Object-Oriented Modelling.
> .
> .
>
>

Re: [myhdl-list] When to use @always, @instance and @always_comb

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

On 5/6/2012 3:23 AM, Jan Coombs wrote:
> On 06/05/12 06:35, Tom Dillon wrote:
>
>> "Experienced python developer", what is that? I am not sure what
>> that has to do with anything.
> True. An "Experienced python developer" is most likely someone who
> has gained some control over a machine at a very high level of
> abstraction. They may know little or nothing about the
> progressively differing layers of software beneath, supporting
> their code.  Likely, the further layers of hardware concepts
> expressed below are completely out of sight.
>
>> There is nothing unnatural about MyHDL. Again, trying to draw
>> somebody into a meaningless discussion.
> I think he's angling to get a fish, a big one.  A person wanting to
> learn to fish would need to be interested in understanding and
> clearly distinguishing the names of the tools, behaviour of fish,
> affects of tides, etc.  Asking why angling is not an iPhone app
> that can be run, sat on a bench in the park while watching bowls is
> pointless.
>
>> MyHDL works fine. I fail to see a conflict at all.
> I'm struggling, but much too inexperienced with Python to suggest
> changing any of MyHDL.

As you mentioned others are trying to give strong opinions on how to 
fish without understanding much about fishing (or why we are fishing). 
Thanks for being one of the sane members of the community.

>
> My hardware experience started with borrowing my mums breadboard
> and dressmaking pins, and using surplus germanium diodes and
> transistors.  I still like to know the details of the fabric I'm
> using.
>
> Today I still have questions, for example: Do clockless gate arrays
> use standard SRAM blocks in an async wrapper, or are they async to
> a much lower level than this.  It may seem pointless to ask, but it
> would help me to estimate the reliability of tools which translate
> RTL designs to use a clockless fabric. [1]
>
> But this extremely low-level interest might hinder my progress in
> using MyHDL in a similar way to having an insufficiently deep
> understanding of electronics.  I'll need to work to get the balance
> right.
>

By hinder progress, you simply mean your attention is diverted to a 
lower-level non-related topic?  In general the claim to fame by [1] is 
that it takes the known, successful, design techniques and does the 
translation to async itself.  MyHDL should be as useful as any other 
tool for [1].

> It has been a hard struggle for me to get started with MyHDL,
> hopefully we can work out why, and make it easier for others in the
> future.
>
> Jan Coombs

Feedback is always welcome, it might be challenged but I believe you and 
most have found that the group here is fair.  And the group is much more 
tolerable to trolls than other groups.

Don't be afraid to ping questions you have asked in the past if you 
still have questions.  It looks like you have been successful with 
MyHDL.  You have posted your UART code (comp.arch.fpga), mentioned your 
forth processor, and a couple other projects.

Regards,
Chris

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Jan C. <jan...@mu...>]

On 08/05/12 13:19, Christopher Felton wrote:
> As you mentioned others are trying to give strong opinions on how to
> fish without understanding much about fishing (or why we are fishing).

Whether putting up a TV broadcast aerial, or just building a small 
house we have two principal choices: Understand all the engineering 
implications down to bedrock, or accept a ready made platform.

If the platform is as high as a TV tower, it might be good to know 
something of it's behaviour in wind before climbing up to install 
an aerial, just in case some extra pills are needed!  However, 
looking up at the waving top, and suggesting design modifications 
is likely to lessen the chance of anyone's aerial becoming installed.

> By hinder progress, you simply mean your attention is diverted to a
> lower-level non-related topic?

No, worse than that!  I get very interested in lower levels of the 
design in progress, the stuff that I can't control, and should 
happily entrust to synthesis tools.

> In general the claim to fame by [1] is
> that it takes the known, successful, design techniques and does the
> translation to async itself.

We might never need anything better!:)  Since RTL balances delays 
between latches (to a first approximation), then replacing buffers 
with 'signal re-synchronisation' logic should just work.

However, I dislike black boxes, so shall insist that I need to know 
the details, so that I can predict any odd cases where simple 
translation is not the best option.

> MyHDL should be as useful as any other tool for [1].
Yes, I'm just starting to appreciate it's power.  I struggle to 
read verilog in places where it is very terse, but also soon tired 
of using VHDL where so many things have to be written in triplicate.

> Feedback is always welcome, it might be challenged but I believe you and
> most have found that the group here is fair.

Yes, it's been a largely pleasant experience, and I feel 
sufficiently supported.

> It looks like you have been successful with MyHDL.  ...
The UART was the first sign of reasonable productivity. 
Translating the processor designs from verilog to MyHDL was an 
up-hill struggle - two unfamiliar languages, and no obvious means 
of testing anything less that a working whole.

Thanks for the encouragement, Jan Coombs.
-- 
[1] www.achronix.com

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

[Christopher F. <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?

 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.

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

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

[Christopher L. <loz...@fr...>]

On 5/11/12 5:13 PM, Christopher Felton wrote:
>     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)
>
>
>
> In my case, I actually do not want to pass the "ports" to my 
> instantiation but rather the parameters of the design.

Good point.  Let me see if I understood you.  You do have to tell your
hardware modules what signals they are getting.  But passing signals is
not enough. I think when you instantiate a hardware module class you
would want to pass both the ports, and some parameters, such as if you
want a very fast or space efficient implementation of that hardware
module.   Is that a correct understanding?

To do this, all that is needed is that the ports method for the hardware
module class iterates through the instance variables, and only returns
those that are actually a subclass of signals.

I have modified the documentation for the proposed hardware module class
accordingly.

http://wiki.myhdlclass.com:8080/HardwareModuleClass

Existing Class

The other interesting use case is when you are defining a python
HardwareModule class for something that already exists, such as the
embedded multiplier blocks on a FPGA.  There is a need for a python
model of an existing hardware class, one already defined in Verilog.   
Such a class needs to exist in the python model, but does not convert,
because it already exists predefined in Verilog. The instances created
in python, just need to be created in Verilog.   This uses multiple
inheritance, so it can either be used with either a Atomic or Compound
Hardware module. 

Regards
Chris


 

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

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

[Jan C. <jan...@mu...>]

On 16/05/12 12:58, Oscar Diaz wrote:
    . . . [big snip]
>
> 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.

If Chris L. wants a higher level of abstraction, this will likely 
still depend on tools to describe RTL, for example MyHDL. 
Suggesting that this might be an extension, or revised expression 
method for MyHDL is incorrect, because it, like IP modules, is not 
expressed at the same level of abstraction.

> 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.

Agreed, perhaps "Hardware Module Class" is misnamed?  RTLs like 
MyHDL express designs at an abstraction level significantly above 
hardware.

Or maybe there is confusion; When showing interest in whether block 
RAMs in async logic chips are conventional RAMs in an async 
wrapper, or truly constructed from async logic, Chris L. suggested:

"What is needed is a class called ClocklessGateArray, which you 
could just use, or read the code to see how it is modelled."

This answer might/might-not be right, because, to write this class 
a person might/might-not choose to incorporate the information 
derived by answering my original question about RAMs in async gate 
array fabric.

Jan Coombs.

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

[Christopher L. <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.  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. 

That would make this into a much more vibrant community.

Regards
Chris L.

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

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

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).

> 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.

However, don't be discouraged, IMHO for an OO approach it is necessary
to define a class hierarchy and some sort of an API for
interoperability between its objects. The really hard part is to come
with such library that satisfy most of the design needs. The "price" I
mentioned before is unavoidable, but at least we should find a way to
"lower that price" as much as possible.

>
> That would make this into a much more vibrant community.
>
> Regards
> Chris L.
>
> ------------------------------------------------------------------------------
> 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



-- 
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

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

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

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

>
> I agree, you don't want to comprises the generality of MyHDL

Fat finger that, should have been "compromise".

.chris

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

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

On 5/16/12 7:54 AM, Jan Coombs wrote:
> On 16/05/12 12:58, Oscar Diaz wrote:
>      . . . [big snip]
>>
>> 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.
>
> If Chris L. wants a higher level of abstraction, this will likely
> still depend on tools to describe RTL, for example MyHDL.
> Suggesting that this might be an extension, or revised expression
> method for MyHDL is incorrect, because it, like IP modules, is not
> expressed at the same level of abstraction.

I think this is a point often missed.  If you look at it as a tool stack 
there probably will be multiple packages for this magical VHL 
(very-high-level) hardware description/conversion package and MyHDL will 
be an important package in the stack.  But something outside the MyHDL 
goals would probably be required.  I say outside the MyHDL goals because 
I think the VHL-DH will have many constraints where MyHDL like the other 
HDLs at similar abstractions levels are more general.

If you look at the other attempts this is what was being done.  Some 
projects provide means to connect things via streams (similar to the 
streams-C hdl).  And then created state-machines a certain way 
(sometimes using a cpu?), module connections, etc.  You traded possibly 
a simplified description for loss of implementation control.

>
>> 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.
>
> Agreed, perhaps "Hardware Module Class" is misnamed?  RTLs like
> MyHDL express designs at an abstraction level significantly above
> hardware.

I lack the ability to see how the Hardware class thing is useful at all.

>
> Or maybe there is confusion; When showing interest in whether block
> RAMs in async logic chips are conventional RAMs in an async
> wrapper, or truly constructed from async logic, Chris L. suggested:
>
> "What is needed is a class called ClocklessGateArray, which you
> could just use, or read the code to see how it is modelled."

This whole tangent on async FPGA hasn't been that useful.  I missed what 
was trying to be achieved.  To use MyHDL on an Achronix FPGA, in that 
case nothing needs to be done just code away.  Or the interest to 
describe at a higher-level async logic.  If that latter see an older 
thread where this was discussed (a couple years ago).

Regards,
Chris

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

[Jan C. <jan...@mu...>]

On 18/05/12 22:32, Christopher Felton wrote:
    . . .
> This whole tangent on async FPGA hasn't been that useful.

No, sorry.  It was intended to be an empathetic illustration to 
show that there is an optimum depth of hardware appreciation for 
effective RTL design.

Jan Coombs.

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

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

On 5/18/12 6:57 PM, Jan Coombs wrote:
> On 18/05/12 22:32, Christopher Felton wrote:
>      . . .
>> This whole tangent on async FPGA hasn't been that useful.
>
> No, sorry.  It was intended to be an empathetic illustration to
> show that there is an optimum depth of hardware appreciation for
> effective RTL design.
>
> Jan Coombs.
>

Jan C.

I didn't mean any offensive by this.  I thought the "async" comments 
were a reference to an off-topic conversation about Achronix FPGAs in 
this thread?  But it wasn't, the async FPGA was brought up in a separate 
thread and was more applicable in the other context.  I had simply 
merged these two threads in my mind making them non-coherent, which was 
*not* the case.

I think your description on how flexible MyHDL can be was useful.  My 
comment was out of context, sorry about that.

Regards,
Chris Felton

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

[Christopher L. <loz...@fr...>]

On 5/18/12 6:57 PM, Jan Coombs wrote:
> On 18/05/12 22:32, Christopher Felton wrote:
>     . . .
>> This whole tangent on async FPGA hasn't been that useful.
> No, sorry.  It was intended to be an empathetic illustration to 
> show that there is an optimum depth of hardware appreciation for 
> effective RTL design.
>
> Jan Coombs.
>
I loved Jan C's question.   I learned a lot from it.  He is also buiding
great stuff, if I get it correctly, minimal space adders and other
components.  That is an important set of ideas to include in this
group.  He is one of only two or three guys working on cpu's.  And the
whole idea of getting away from a central clock, to everything running
at its own speed, I believe can lead to vast speed improvements.   In
particular it helped me really understand that there can be different
high level models of the same digital component, based on how it is used. 

Let us lighten up a little bit.  And embrace all the wonderful ideas
that this group of people have.  Let us face it, we are not mainstream
digital circuit designers.  There are some very interesting ideas
floating around.  I love Dillon's examples of  Hierarchical signals,
complex numbers.  I love the idea of building a python processor. 

You are all a very smart bunch of people.  As one person said, we post
ideas to stimulate others thinking.  Hopefully this is not just about
existing MyHDL, but about the dreams of where digital circuit design can
go. I am hugely stimulated by this group.  I have certainly done my
share of stimulating the conversation.    Please keep it up Jan C. . 

Chris L.

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

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

On 5/18/12 8:13 PM, Christopher Lozinski wrote:
> On 5/18/12 6:57 PM, Jan Coombs wrote:
>> On 18/05/12 22:32, Christopher Felton wrote:
>>      . . .
>>> This whole tangent on async FPGA hasn't been that useful.
>> No, sorry.  It was intended to be an empathetic illustration to
>> show that there is an optimum depth of hardware appreciation for
>> effective RTL design.
>>
>> Jan Coombs.
>>
> I loved Jan C's question.   I learned a lot from it.  He is also buiding
> great stuff, if I get it correctly, minimal space adders and other
> components.  That is an important set of ideas to include in this
> group.  He is one of only two or three guys working on cpu's.  And the
> whole idea of getting away from a central clock, to everything running
> at its own speed, I believe can lead to vast speed improvements.   In
> particular it helped me really understand that there can be different
> high level models of the same digital component, based on how it is used.

I might be getting confused here, this was a long thread.  But what was 
the question Jan C. asked?  Maybe you, Christopher L,  can refresh my 
memory for me and remind what the question Jan C. asked was?

Regards,
Chris Felton