Re: [myhdl-list] MEP : Signal Containers

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

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.

Right now you have to mess with the AST tree.  If everything were a
class, it would be easier to query them for signals public and private. 
You would only have to touch the AST tree for the code that is inside a
python method, not for its 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.

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. 

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.

Looking at waveforms is just not the right way to be debugging this
stuff.   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.   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.

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. 

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.

-- 
Regards
Christopher Lozinski

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

Expect a paradigm shift.
http://MyHDLClass.com:8080