Re: [myhdl-list] MEP : Signal Containers

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

On 05/19/2012 02:42 PM, Christopher Lozinski wrote:
> On 5/19/12 4:02 AM, Jan Decaluwe wrote:
>> There should be some feature
>> that many people find useful and that cannot reasonably done in
>> a different way. Conversion is complex enough as it is!

> I think if you only did classes, conversion would be so much easier.

I don't see why.

> Right now you have to mess with the AST tree.

That's the Migen rationale, isn't it?

Well, everyone can see where that leads to: ridiculous restrictions
and awkward syntax. In short, HDL design for amateurs.

No thanks, I settle for the AST. I need python's expressiveness
and syntax to describe hardware behavior.

>  If everything were a
> class, it would be easier to query them for signals public and private.

Signal handling is currently a minor task in conversion.

> You would only have to touch the AST tree for the code that is inside a
> python method, not for its arguments.

That's how it works currently, except at the top level. Elaboration
takes care of the other arguments.

> You could have two representations of signals, the short list, and the
> expanded list.  Two methods, one for short list, one for expanded list.
> Then just convert the expanded list.   That would give you hierarchical
> signals much more easily.  Verilog would just see a longer list of signals.

As I said, a minor task.

> And if everything were a class, they could all multiply inherit from a
> graphics drag and drop class, and you would get a great GUI.

That is called schematics entry, an intelligent form of it at best.
Not for me, thanks.

> But those are all details.  There are work arounds to each item.  The
> real issue is at a much higher level.
>
> But the real feature would be in making MyHDL understandable to newbies,
> and in doing so growing the community.
>
> An even big feature is that it would give the MyHDL users a different
> mental model of MyHDL.   I want to do some very very complex things, not
> very performance intensive things, but to even be able to think at this
> level of abstraction, to reduce the complexity of what I am doing,  I
> need a simpler mental model of what I am building on top of.    OOHDL
> hardware classes give me that simple conceptual model to build on top of.
>
> Ignoring licensing issues, If Jan C's microprocessor were a bunch of
> OOHDL hardware modules, it would be so easy to grab and use them.  Right
> now I would have to edit them to fit my world view.   They do not
> provide the right debugging functionality.

I have zero interest to compare the benefits of some virtual super
system with MyHDL, a proven system that works today.

I you think you are on to something, it is your job to show it. With
code and a manual I mean, not with vague visions and world views.

> Looking at waveforms is just not the right way to be debugging this
> stuff.

Agreed.

>  For example I might want to  keep the history of each signal,
> then print out a tree of  hardware modules and their signal values to
> figure out what is going wrong.

But that is exactly what a waveform viewer (and the associated
input file) does!

> The current approach, A function
> returning a list, first calls the top level function, then returns me me
> a list of modules, not a tree of modules.  Not what I need to debug this
> thing.

Wrong, it is a tree, represented as a nested list.

http://www.myhdl.org/doc/current/manual/intro.html#parameters-and-hierarchy

> The promise of MyHDL is in debugging, what you call verification, but it
> does not provide me with a tree of hardware modules that I need to
> iterate over in order to write my required debugging harnesses.
>
> Anyhow there is no one critical point.  There are work arounds to each
> piece.  It is just that the big picture would be so much simpler for
> newbies to get, and so much simpler to build complex systems on top of.
>
> While this is a signal mep,  this point is not about a better signal, it
> is about a better overall system.   Jan is asking show me the critical
> feature.  I am responding we need a different elephant.

It is clear that you still don't understand what beast we currently have,
so I don't think you are in pole position to specify a different one.

The problem is that I see zero progress, despite all the energy invested.
I think the issue is that your learning methodology is broken. You keep
on posting, but it seems you don't listen to the good advice you get from
the experts here: start with learning the basics of digital design,
including synthesis, use the manual as a close reference, use the cookbook
examples to go through the process yourself in small steps. Actually your
own suggestion to start simple with Verilog may be a good one, but now it
seems you're even ignoring your own good advice.

I hope that you understand how irritating it is to hear about visions
and world views all the time, and even get programming lessons, from
someone in that position.

> But those are just my thoughts.  My vision.   I could be wrong.  Thank
> you for helping me to clear these issues up in my mind.

Visions are for those who know where they are. The others
should not lose time with them, and work hard to get there.

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