Re: [myhdl-list] MEP 107 assessment

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

On 6/8/12 10:28 AM, Tom Dillon wrote:
> First let me say, I don't know much about the code that does the
> conversion but let me throw something out here.
>
> What if we limited ourselves to using a class to define the
> containers? Once in a class, could we not push off some of the
> conversion complexity to methods in the class. Basically, have some
> hooks in conversion that would allow the class to be queried about the
> conversion details.
>
> I know it is not done that way now and we are trying to make
> conversion sort of invisible to the user but this might allow more
> complex signal containers without adding to the complexity of conversion.

First forgive me for not reading all of this thread, but I had to jump
on this one.  

Duh, obviously that is the way to do things. But that is just my
instinct.   It would be very interesting to see the class documentation
to see exactly what the design would be. Which is why I started drafting
class documents for floating point signals, a long while ago, even
though it has errors, it is a step in the right direction. 

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

And I fixed the code on this page.

wiki.myhdlclass.com:8080/SignalClass

Thank you Jan D,  for pointing out the problem.  It even has a tiny test
harness.

It is not just about ease of implementation, you really have to look at
this from the marketing point of view. 

If you are a python developer, then the obvious thing is to have signal
containers, and be able to convert them.  That is just how python
developers think.  But that has nothing to do with the marketing
perspective.

>From the marketing perspective we want to have a bunch of signal types
that make sense to new users.  There are two sets of users.  Hardware
developers, and software developers, and some overlap.  I obviously
speak for the latter group.  Although some would say I do not speak for
them. 

As a software guy IntBV just leaves me cold.   Why would I ever want an
integer that runs from -23 to +19.  Give me a break.  A billion
transistors, how many do I need to save?  Our limitation is on the
complexity we can manage.   At least for me.

Software engineers like ints, floats real, complex.  I like characters,
and strings, strings sent down a line serially. I would love to see a
signal type called Object ID.   I am sorry I missed the conversation on
this discusson list, Let me ask an obvious marketing question.  Would
everyone please post what kinds of signal types they are looking for.  
How many people want floats?  How many people want complex numbers?  How
about audio, video, long long, short ints, and all that weird stuff? 
What am I missing??  What signal types does this market of users want?  
It would be great to see a list of signal types, and the number of users
who want to see each type.

Maybe if we just had a float,  all of us but one person would be happy. 
And my apologies if this question has already been answered. 

Me I wanted floats, and I wanted the hardware modules to process them. 
It took me quite a while to figure out how to do all of that in the
appropriate way.  Still have not implemented it.  That will come.  But
the point is that the absence of floats was a huge barrier to my
actually starting to use MyHDL.  Instead I went off and studied hardware
floating point design.   Then I started documenting all kinds of things,
including the float documentation.   It is an interesting way to
implement floats without having to write the floating point operations
in MyHDL. 

And of course the new users will want to see a list of different types
that MyHDL supports.  Not things like IntBV, but things that they
recognize, floats, complex, strings, things that smooth the mental
transition to MyHDL from wherever they come from.

Statements like

    Signals are objects, or hierarchies of objects.  Since Verilog and
    VHDL do not natively support signal hierarchies,  MyHDL does all the
    conversion and mapping for you, giving significant development
    advantages over using lower level tools. 


are very attractive to customers like me. 

Conversion of containers just does not resonate with my needs. 

And yes eventually they may find out that a signal cannot be a
dictionary or a list, or it can be but does not convert, but frankly who
cares.  Particularly since VHDL and Verilog cannot iterate over
dictionairies.  And yes, I know that there are people who care, who did
post to this thread with why they care, but seriously, from a marketing
point of view it is not important.

Then again the marketing point of view is not the only point of view,
but it is an important one.   It is not really about marketing.  It is
about what is the set of abstractions that we publish to the world.   A
rich list of signal types that MyHDL supports would be a huge
improvement over the current abstractions that MyHDL publishes to the
world. 

I hope that helps.  And do feel free to attack my point of view, I learn
a lot from it.  But attacking me personally really does not accomplish
anything.

"Be hard on issues soft on people"

-- 
Regards
Christopher Lozinski

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

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