myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] MEP : Signal Containers

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

On 6/2/2012 4:57 PM, G. Andrew Stone wrote:
> ok great!  I would have no intention to drop all the work on someone else's
> lap :-) and I agree that OO additions should not be done quickly.  This
> actually fits my own schedule anyway as I might be freeing up a bit in a
> month or so.  But at the same time, I have no intention to evangelize these
> ideas -- I mean if there's no spark of interest in the community I do not
> have the time to create the "mind-share" (as VCs say).  Or I was thinking
> that maybe someone has already shown that the current conversion code is
> somehow inimical to OO...
>
> You said:
> "I think it is a stretch to say you can describe synthesizable hardware in
> the same manner as you write OO software (yet to be proven)."
>
> I think that you are correct and that is not the point.  I think that you
> just said something like, "I think it is a stretch to say you can pry the
> lid off this paint can in the same manner as you drive screws".  You can't
> do it in the same manner, but the question is can we use the same tools?

No, we have made the point that the tool, "OO", is used.  The issues 
being discussed are the "how".

>
<snip>
>
> WRT inheritance, perhaps a simple but valuable use would be to extend IP
> while maintaining backwards compatibility.  For example you have the
> wishbone bus as an example in the MEP.  What about using inheritance to
> define a Wishbone16 that is clearly (because it inherits from the prev gen)
> 100% backwards compatible with the standard Wishbone but offers 16bit data
> transfers.  If you instantiate Wishbone16, you can give it to old IP blocks
> that take a "Wishbone" bus without having to modify that old code.  But
> this example still uses the "classic" formulation of a class essentially as
> a concrete entity as typified by your car example... but there are more
> advanced uses of classes that may have hardware analogues...
>

I don't think this is a good example for HW or SW.  I don't believe a 
simple attribute change justifies a new class.  In this case, it is more 
eloquently handled by simply passing the correct Signal object during 
instantiation (and people say MyHDL isn't OO).

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

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

On 6/4/2012 7:00 AM, Tom Dillon wrote:
> I've been sucked in before and it is frustrating.
>

I think Mr. Issues has a unique talent at being a vacuum.

But ignoring Mr. Issues, it seems to be a common topic by many new users 
to inquire: "what are the OO capabilities".  Many seem to error on the 
"MyHDL needs ..." instead of understanding what currently exists and is 
supported or a valid example.

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

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

I've been sucked in before and it is frustrating.

On 06/04/2012 02:23 AM, Jan Decaluwe wrote:
> On 06/04/2012 06:21 AM, Tom Dillon wrote:
>> Thanks for taking the time to pick this nonsense apart.
> Thanks, though I am very frustrated to realize that I
> wasted so much time and effort on someone who cannot
> get a single line of Python right.
>
>> I am still waiting for an example before I am willing to pay attention.
> I'll try to be smarter in the future by doing the same.
>

Re: [myhdl-list] 0.8 Type mismatch in enum item comparison

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

On 6/4/2012 6:01 AM, Jan Coombs wrote:
> On 01/06/12 02:55, Christopher Felton wrote:
>      . . .
>>
>> I sometimes like my testbenches to have three sim
>> modes selectable
>>
>>      if simType == 'trace':
>>         dut = traceSignals(ModuleToTest, ...)
>>      elif simType == 'cosim':
>>         dut = CoSimulation(ModuleToTest, ...)
>>      else
>>        dut = ModuleToTest(..., )
>>
> Thanks, looks neat, however, after a couple of hours I still
> couldn't see how to integrate this with my cutrent test code.
>
> I also have similar problems with some of the material on
> myhdl.org.  As expert to expert communication it is very good, but
> often lacks enough repetitive or common code for me to be able to
> spot the design patterns.
>
> In order to use your code above I would either need to have a full
> understanding of what is happening, which would allow me to work
> out how to integrate this code fragment, or have you provide a full
> test harness code sample which I could modify to suit myself.
>
> Jan Coombs.

This might help as an example, select traceSignal vs. no traceSignal,
http://www.myhdl.org/doku.php/users:cfelton:projects:recursivefft

Regards,
Chris

Re: [myhdl-list] 0.8 Type mismatch in enum item comparison

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

On 01/06/12 02:55, Christopher Felton wrote:
    . . .
>
> I sometimes like my testbenches to have three sim
> modes selectable
>
>     if simType == 'trace':
>        dut = traceSignals(ModuleToTest, ...)
>     elif simType == 'cosim':
>        dut = CoSimulation(ModuleToTest, ...)
>     else
>       dut = ModuleToTest(..., )
>
Thanks, looks neat, however, after a couple of hours I still 
couldn't see how to integrate this with my cutrent test code.

I also have similar problems with some of the material on 
myhdl.org.  As expert to expert communication it is very good, but 
often lacks enough repetitive or common code for me to be able to 
spot the design patterns.

In order to use your code above I would either need to have a full 
understanding of what is happening, which would allow me to work 
out how to integrate this code fragment, or have you provide a full 
test harness code sample which I could modify to suit myself.

Jan Coombs.
-- 

Re: [myhdl-list] MEP : Signal Containers

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

On 06/04/2012 06:21 AM, Tom Dillon wrote:
> Thanks for taking the time to pick this nonsense apart.

Thanks, though I am very frustrated to realize that I
wasted so much time and effort on someone who cannot
get a single line of Python right.

> I am still waiting for an example before I am willing to pay attention.

I'll try to be smarter in the future by doing the same.

-- 
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] MEP : Signal Containers

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

Thanks for taking the time to pick this nonsense apart.

I am still waiting for an example before I am willing to pay attention.



On 06/03/2012 07:14 AM, Jan Decaluwe wrote:
> On 06/03/2012 03:01 AM, Christopher Lozinski wrote:
>> On 6/2/12 4:57 PM, G. Andrew Stone wrote:
>>> I mean if there's no spark of interest in the community I do not
>>> have the time to create the "mind-share"
>> Everything you say totally resonates with me.  Every time I see your
>> name, I read the posting carefully.  I cannot say that for all of the
>> posters.
> You certainly don't read mine. I have tried painstakingly to
> point out all the errors and misconceptions in your mind, but you
> keep repeating the same nonsense.
>
>> There really are different world views in this world.  No
>> point arguing them.
> You don't seem to listen, that's the real problem.
>
>> I also have little interest in evangelizing this stuff.   I just get too
>> much crap for speaking my mind.
> That's because it's mostly nonsense, and you appear unwilling to
> do anything about it.
>
>>   Actually I think it is really good to
>> have different points of view.  And one needs not only software
>> developers on a project but also marketing people who try to figure out
>> how to simplify the technologies, not make them more complex.
>> But others disagree.
> No, no one will disagree with that. We will probably disagree
> violently on who's the right person to do so however.
> (BTW I know it's not me.)
>
> Furthermore: things should me made as simple as possible,
> but not simpler. (Einstein.)
>
>> I am just grateful I have not been kicked off the mailing list.  I am
>> pleased if I have stirred some discussion.
>>
>> Anyhow I have spoken my mind at
>>
>> http://wiki.myhdlclass.com:8080/
> Just when one thinks one has seen the worst, it gets worse.
>
> All the nonsense about MyHDL is still there - mostly completely
> wrong and I explained it several times.
>
> Now let's move to what you try to tell us I think - how to use
> object-orientation in hardware design.
>
> I think you are totally confused. Apparently you think a class
> hierarchy can be mapped to hardware hierarchy, just because both
> use the word "hierarchy". Apparently you think that connectivity
> can be magically implemented by subclassing. And apparently you still
> don't understand why MyHDL uses generators.
>
> Of course, you could have found this out yourself by simply
> creating one small working example. But apparently it was
> even too much to fire up a Python interpreter to run some
> minimal checks on your code.
>
> This what I find unbelievable: at about 1 error per line
> (sometimes 2) this code seems to be written by a total newbie
> in Python and object-orientation. You don't know how to
> create a class in Python. You don't know how to use the
> "self" argument at all. And above all, it seems you don't understand
> the Python scoping rules, see the Clock example. Try to get this
> to work, and you may understand what I mean with "connectivity".
>
> Really, what were you thinking? That we are complete idiots
> here and that you would get away with this? And where does
> this arrogance come from that you think you should teach us
> lessons in object-orientation and writing quality code?
>
>> I think you have a lot of good ideas to add.  I would love to see you
>> edit that wiki.   Some day I may read through all your  email postings.
>> May I copy them, at least this one, to the wiki under creative commons
>> license?
>>
>> I will come back to implementing the code one day.  My belief is that if
>> you get the right abstractions implementing the code is quite easy.  In
>> fact complex code, is a sign of bad abstractions,
> I suggest to fix your code now, or get it off the web immediately.
> Your reputation of "experienced Python programmer" is at stake.
>
>

Re: [myhdl-list] MEP : Signal Containers

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

On 06/03/2012 03:01 AM, Christopher Lozinski wrote:
> On 6/2/12 4:57 PM, G. Andrew Stone wrote:
>> I mean if there's no spark of interest in the community I do not
>> have the time to create the "mind-share"

> Everything you say totally resonates with me.  Every time I see your
> name, I read the posting carefully.  I cannot say that for all of the
> posters.

You certainly don't read mine. I have tried painstakingly to
point out all the errors and misconceptions in your mind, but you
keep repeating the same nonsense.

> There really are different world views in this world.  No
> point arguing them.

You don't seem to listen, that's the real problem.

> I also have little interest in evangelizing this stuff.   I just get too
> much crap for speaking my mind.

That's because it's mostly nonsense, and you appear unwilling to
do anything about it.

>  Actually I think it is really good to
> have different points of view.  And one needs not only software
> developers on a project but also marketing people who try to figure out
> how to simplify the technologies, not make them more complex.
> But others disagree.

No, no one will disagree with that. We will probably disagree
violently on who's the right person to do so however.
(BTW I know it's not me.)

Furthermore: things should me made as simple as possible,
but not simpler. (Einstein.)

> I am just grateful I have not been kicked off the mailing list.  I am
> pleased if I have stirred some discussion.
>
> Anyhow I have spoken my mind at
>
> http://wiki.myhdlclass.com:8080/

Just when one thinks one has seen the worst, it gets worse.

All the nonsense about MyHDL is still there - mostly completely
wrong and I explained it several times.

Now let's move to what you try to tell us I think - how to use
object-orientation in hardware design.

I think you are totally confused. Apparently you think a class
hierarchy can be mapped to hardware hierarchy, just because both
use the word "hierarchy". Apparently you think that connectivity
can be magically implemented by subclassing. And apparently you still
don't understand why MyHDL uses generators.

Of course, you could have found this out yourself by simply
creating one small working example. But apparently it was
even too much to fire up a Python interpreter to run some
minimal checks on your code.

This what I find unbelievable: at about 1 error per line
(sometimes 2) this code seems to be written by a total newbie
in Python and object-orientation. You don't know how to
create a class in Python. You don't know how to use the
"self" argument at all. And above all, it seems you don't understand
the Python scoping rules, see the Clock example. Try to get this
to work, and you may understand what I mean with "connectivity".

Really, what were you thinking? That we are complete idiots
here and that you would get away with this? And where does
this arrogance come from that you think you should teach us
lessons in object-orientation and writing quality code?

> I think you have a lot of good ideas to add.  I would love to see you
> edit that wiki.   Some day I may read through all your  email postings.
> May I copy them, at least this one, to the wiki under creative commons
> license?
>
> I will come back to implementing the code one day.  My belief is that if
> you get the right abstractions implementing the code is quite easy.  In
> fact complex code, is a sign of bad abstractions,

I suggest to fix your code now, or get it off the web immediately.
Your reputation of "experienced Python programmer" is at stake.


-- 
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] MEP : Signal Containers

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

On 06/03/2012 03:57 AM, G. Andrew Stone wrote:
> I resonate with you because we both come from SW backgrounds.  Try to
> twist your brain into resonance with the HW guys here, then from THAT
> perspective you can effectively argue your points.

I think this SW - HW distinction is artificial and unproductive.

I am pretty sure many people here are experienced Python programmers
who understand techniques such as object-orientiation very
well. In particular, I suspect that the most experienced MyHDL
users use object-oriented techniques quite heavily in their
work.

The real difference is in the level of experience with digital
design, HDL-based design, synthesis and MyHDL.

I can only help with the last part - the nature of MyHDL.
In particular, let me try again to explain the relation between
MyHDL and object-orientation.

MyHDL - the modeling language - is as object-oriented as Python
itself. Nothing prevents you from using it, nothing forces you
to do so either. If we like that for Python, we should like it
for MyHDL also.

The conversion story is a different matter: it is
very restrictive and of course that is also related to the
capabilities of the target HDLs. Gradually, the convertor
tries to support more things that you cannot easily do in
the target HDLs. That is not trivial. Let us not confuse
such technical difficulties with unawareness or even
unwillingness to support useful techniques.

-- 
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] MEP : Signal Containers

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

My brain needs some examples to get engaged.

On 06/02/2012 04:57 PM, G. Andrew Stone wrote:
> ok great!  I would have no intention to drop all the work on someone 
> else's lap :-) and I agree that OO additions should not be done 
> quickly.  This actually fits my own schedule anyway as I might be 
> freeing up a bit in a month or so.  But at the same time, I have no 
> intention to evangelize these ideas -- I mean if there's no spark of 
> interest in the community I do not have the time to create the 
> "mind-share" (as VCs say).  Or I was thinking that maybe someone has 
> already shown that the current conversion code is somehow inimical to 
> OO...
>
> You said:
> "I think it is a stretch to say you can describe synthesizable 
> hardware in the same manner as you write OO software (yet to be proven)."
>
> I think that you are correct and that is not the point.  I think that 
> you just said something like, "I think it is a stretch to say you can 
> pry the lid off this paint can in the same manner as you drive 
> screws".  You can't do it in the same manner, but the question is can 
> we use the same tools?
>
> Perhaps I used the term "OO" too generically; I was not only referring 
> to the classic OO concepts but also the post-OO design patterns which 
> OO enables.  For example, it sounds from your motor example like you 
> would benefit from the mixin pattern: 
> http://www.linuxjournal.com/node/4540/print.  Wouldn't it be cool if a 
> SOC could be created by mixin of different classes that represented 
> SPI, I2c, flash, ram and other resources?  Or, to avoid Jan's comment 
> about how myHdl is not schematic capture, this design paradigm could 
> be used to pull in groups of instructions (logic, arithmetic, flow 
> control, fp) to build a soft uP with an instruction set optimized for 
> a particular application.
>
> WRT inheritance, perhaps a simple but valuable use would be to extend 
> IP while maintaining backwards compatibility.  For example you have 
> the wishbone bus as an example in the MEP.  What about using 
> inheritance to define a Wishbone16 that is clearly (because it 
> inherits from the prev gen) 100% backwards compatible with the 
> standard Wishbone but offers 16bit data transfers.  If you instantiate 
> Wishbone16, you can give it to old IP blocks that take a "Wishbone" 
> bus without having to modify that old code.  But this example still 
> uses the "classic" formulation of a class essentially as a concrete 
> entity as typified by your car example... but there are more advanced 
> uses of classes that may have hardware analogues...
>
> This is just a quick taster; is going to take me a couple days to 
> formulate something with actual examples, etc.
>
> Cheers!
> Andrew
>
>
> On Sat, Jun 2, 2012 at 8:01 AM, Christopher Felton 
> <chr...@gm... <mailto:chr...@gm...>> wrote:
>
>     On 6/1/12 4:50 PM, G. Andrew Stone wrote:
>     > I've managed to read maybe 3/4 of the mail on this very long
>     thread (and
>     > think I understand the MEP since I did find an error in the
>     example).
>
>     I would call it a typo not an error since it wasn't a consistent
>     throughout the MEP :)
>
>     > Somehow I got the idea that people aren't sure what value typical OO
>     > features would have in a hardware environment, so are considering
>     > leaving classes just a container for signals. Is that a correct
>     > assessment?
>
>     No, I don't think that is the correct assessment.  There hasn't been
>     enough reasonable discussion on this topic to make a conclusion.
>      Also,
>     the waters are murky.  For example, you mention "typical OO features".
>     Two typical OO features are instantiation and inheritance.  HDLs by
>     virtue support instantiation, including MyHDL.  That is a typical OO
>     feature supported by HDLs.  So I don't think it is a clear-cut OO
>     support yeah or neah.
>
>     I am not sure if I see how inheritance is useful.  I think it is a
>     stretch to say you can describe synthesizable hardware in the same
>     manner as you write OO software (yet to be proven).  There is a
>     difference in representing a physical thing with OO inheritance (order
>     and classification) and building a physical thing.  I will try and
>     explain my thoughts with an example.
>
>     Take the common OO example, a vehicle.  You might have a base
>     class that
>     represents an abstract model like a vehicle [1].  Then from there you
>     might define a truck, sports car, and limousine. You create the later
>     models by inheriting a set of classes derived from the base vehicle
>     class.  Now when you are creating the model for these different motor
>     vehicles if you need to define the different engine powers you simply
>     need to change a couple numbers.  And that is sufficient for the
>     model.
>
>     But in real life, when building a motor you don't grab a base
>     motor and
>     change a couple attributes to get a more powerful motor.  But what you
>     do do, is reuse components to build the different motors.  I think
>     creating synthesiable descriptions are closer (not exact) to the
>     real-world building of things than the abstract modeling.
>
>     [1]
>     http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtpd1%2Foocon.html
>
>     I am aware of some HDL tools that take an somewhat software OO
>     model and
>     try to generate hardware.  But best of my knowledge these tools first
>     compile the OO down to simple instructions to be executed (byte code)
>     and then rebuild a hardware description from the byte code.  I don't
>     think a tool like this fits the domain of MyHDL.  It might be a tool
>     that uses MyHDL but I don't think it would be explicitly part of
>     MyHDL.
>
>     OO for hardware design, as I currently see it, is useful for modeling.
>     And useful for organizing, parameterizing, and modularizing the
>     synthesizble hardware descriptions.  But the synthesizable
>     (convertible
>     subset that can be synthesized) is in a form similar to what exists.
>
>     > Or is the problem that we don't know how to translate OO
>     > into verilog/vhdl?  If its the former, I'd like to propose a
>     couple of
>     > examples that would use OO features and then you guys can pick them
>     > apart and tell me how its all possible with myHdl today :-).
>     >
>
>     My rational for this MEP is that it fits the current structure and
>     it is
>     useful on its own (it is more than just class/object signal
>     container).
>      More importantly OO support as some people may envision it will take
>     quite a bit of hashing through (conversation).
>
>     In addition, the yet to be define OO representation, more than likely,
>     will require substantial conversion code modifications.  Making
>     near-term inclusion unlikely.  The conversion code is quite complex.
>     You need an strong understanding of the MyHDL design, the Python AST,
>     and detailed knowledge of Verilog/VHDL.
>
>     I think your examples in a separate thread would be worth some
>     discussions and debate.  Just be prepared.  I think it is
>     reasonable to
>     expected some onus by the proposer.  The idea person also needs to be
>     the person that can provide details to some extent.  I don't think
>     it is
>     reasonable for someone to only have the "idea" and expect others
>     to come
>     up with all the details.  It makes the conversations difficult and
>     more
>     than likely won't go too far because the detail creators are yet to
>     share the vision.
>
>     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...
>     <mailto: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] MEP : Signal Containers

[G. A. S. <g.a...@gm...>]

I resonate with you because we both come from SW backgrounds.  Try to twist
your brain into resonance with the HW guys here, then from THAT perspective
you can effectively argue your points.

I feel that your posts present as seeming to think OO is the one true way;
and you're trying to jam it down their throats -- but without the
accomplishments to back it up.

I respect the methods of these guys who are really building large and
extremely complex designs -- and hope to start a discussion with them about
the value of OO techniques.  If they don't want to delve into these
techniques or if my ideas fall flat then I'm going to conclude that there
is something wrong with the approach... I may not reject the fundamental
OO->HW ideas but I'll realize I need to better understand the problems
before proceeding.


Cheers!
Andrew


On Sat, Jun 2, 2012 at 9:01 PM, Christopher Lozinski <
loz...@fr...> wrote:

> On 6/2/12 4:57 PM, G. Andrew Stone wrote:
> > I mean if there's no spark of interest in the community I do not
> > have the time to create the "mind-share"
> Everything you say totally resonates with me.  Every time I see your
> name, I read the posting carefully.  I cannot say that for all of the
> posters.   There really are different world views in this world.  No
> point arguing them.
>
> I also have little interest in evangelizing this stuff.   I just get too
> much crap for speaking my mind.  Actually I think it is really good to
> have different points of view.  And one needs not only software
> developers on a project but also marketing people who try to figure out
> how to simplify the technologies, not make them more complex.
> But others disagree.
>
> I am just grateful I have not been kicked off the mailing list.  I am
> pleased if I have stirred some discussion.
>
> Anyhow I have spoken my mind at
>
> http://wiki.myhdlclass.com:8080/
>
> I think you have a lot of good ideas to add.  I would love to see you
> edit that wiki.   Some day I may read through all your  email postings.
> May I copy them, at least this one, to the wiki under creative commons
> license?
>
> I will come back to implementing the code one day.  My belief is that if
> you get the right abstractions implementing the code is quite easy.  In
> fact complex code, is a sign of bad abstractions,
>
> FLAME SHIELD ON.
>
> never mind, not worth saying what I was about to say.
>
> We get so many transistors nowadays.  Let us use them to simplify the
> engineering cycle.
>
> --
> Regards
> Christopher Lozinski
>
> Check out my iPhone apps TextFaster and EmailFaster
> http://textfaster.com
>
> Expect a paradigm shift.
> http://MyHDLClass.com:8080
>
>

Re: [myhdl-list] MEP : Signal Containers

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

On 6/2/12 4:57 PM, G. Andrew Stone wrote:
> I mean if there's no spark of interest in the community I do not
> have the time to create the "mind-share"
Everything you say totally resonates with me.  Every time I see your
name, I read the posting carefully.  I cannot say that for all of the
posters.   There really are different world views in this world.  No
point arguing them. 

I also have little interest in evangelizing this stuff.   I just get too
much crap for speaking my mind.  Actually I think it is really good to
have different points of view.  And one needs not only software
developers on a project but also marketing people who try to figure out
how to simplify the technologies, not make them more complex.
But others disagree. 

I am just grateful I have not been kicked off the mailing list.  I am
pleased if I have stirred some discussion. 

Anyhow I have spoken my mind at

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

I think you have a lot of good ideas to add.  I would love to see you
edit that wiki.   Some day I may read through all your  email postings. 
May I copy them, at least this one, to the wiki under creative commons
license?

I will come back to implementing the code one day.  My belief is that if
you get the right abstractions implementing the code is quite easy.  In
fact complex code, is a sign of bad abstractions,

FLAME SHIELD ON.

never mind, not worth saying what I was about to say.

We get so many transistors nowadays.  Let us use them to simplify the
engineering cycle.

-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] MEP : Signal Containers

[G. A. S. <g.a...@gm...>]

ok great!  I would have no intention to drop all the work on someone else's
lap :-) and I agree that OO additions should not be done quickly.  This
actually fits my own schedule anyway as I might be freeing up a bit in a
month or so.  But at the same time, I have no intention to evangelize these
ideas -- I mean if there's no spark of interest in the community I do not
have the time to create the "mind-share" (as VCs say).  Or I was thinking
that maybe someone has already shown that the current conversion code is
somehow inimical to OO...

You said:
"I think it is a stretch to say you can describe synthesizable hardware in
the same manner as you write OO software (yet to be proven)."

I think that you are correct and that is not the point.  I think that you
just said something like, "I think it is a stretch to say you can pry the
lid off this paint can in the same manner as you drive screws".  You can't
do it in the same manner, but the question is can we use the same tools?

Perhaps I used the term "OO" too generically; I was not only referring to
the classic OO concepts but also the post-OO design patterns which OO
enables.  For example, it sounds from your motor example like you would
benefit from the mixin pattern:  http://www.linuxjournal.com/node/4540/print.
Wouldn't it be cool if a SOC could be created by mixin of different classes
that represented SPI, I2c, flash, ram and other resources?  Or, to avoid
Jan's comment about how myHdl is not schematic capture, this design
paradigm could be used to pull in groups of instructions (logic,
arithmetic, flow control, fp) to build a soft uP with an instruction set
optimized for a particular application.

WRT inheritance, perhaps a simple but valuable use would be to extend IP
while maintaining backwards compatibility.  For example you have the
wishbone bus as an example in the MEP.  What about using inheritance to
define a Wishbone16 that is clearly (because it inherits from the prev gen)
100% backwards compatible with the standard Wishbone but offers 16bit data
transfers.  If you instantiate Wishbone16, you can give it to old IP blocks
that take a "Wishbone" bus without having to modify that old code.  But
this example still uses the "classic" formulation of a class essentially as
a concrete entity as typified by your car example... but there are more
advanced uses of classes that may have hardware analogues...

This is just a quick taster; is going to take me a couple days to formulate
something with actual examples, etc.

Cheers!
Andrew


On Sat, Jun 2, 2012 at 8:01 AM, Christopher Felton
<chr...@gm...>wrote:

> On 6/1/12 4:50 PM, G. Andrew Stone wrote:
> > I've managed to read maybe 3/4 of the mail on this very long thread (and
> > think I understand the MEP since I did find an error in the example).
>
> I would call it a typo not an error since it wasn't a consistent
> throughout the MEP :)
>
> > Somehow I got the idea that people aren't sure what value typical OO
> > features would have in a hardware environment, so are considering
> > leaving classes just a container for signals. Is that a correct
> > assessment?
>
> No, I don't think that is the correct assessment.  There hasn't been
> enough reasonable discussion on this topic to make a conclusion.  Also,
> the waters are murky.  For example, you mention "typical OO features".
> Two typical OO features are instantiation and inheritance.  HDLs by
> virtue support instantiation, including MyHDL.  That is a typical OO
> feature supported by HDLs.  So I don't think it is a clear-cut OO
> support yeah or neah.
>
> I am not sure if I see how inheritance is useful.  I think it is a
> stretch to say you can describe synthesizable hardware in the same
> manner as you write OO software (yet to be proven).  There is a
> difference in representing a physical thing with OO inheritance (order
> and classification) and building a physical thing.  I will try and
> explain my thoughts with an example.
>
> Take the common OO example, a vehicle.  You might have a base class that
> represents an abstract model like a vehicle [1].  Then from there you
> might define a truck, sports car, and limousine. You create the later
> models by inheriting a set of classes derived from the base vehicle
> class.  Now when you are creating the model for these different motor
> vehicles if you need to define the different engine powers you simply
> need to change a couple numbers.  And that is sufficient for the model.
>
> But in real life, when building a motor you don't grab a base motor and
> change a couple attributes to get a more powerful motor.  But what you
> do do, is reuse components to build the different motors.  I think
> creating synthesiable descriptions are closer (not exact) to the
> real-world building of things than the abstract modeling.
>
> [1]
>
> http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtpd1%2Foocon.html
>
> I am aware of some HDL tools that take an somewhat software OO model and
> try to generate hardware.  But best of my knowledge these tools first
> compile the OO down to simple instructions to be executed (byte code)
> and then rebuild a hardware description from the byte code.  I don't
> think a tool like this fits the domain of MyHDL.  It might be a tool
> that uses MyHDL but I don't think it would be explicitly part of MyHDL.
>
> OO for hardware design, as I currently see it, is useful for modeling.
> And useful for organizing, parameterizing, and modularizing the
> synthesizble hardware descriptions.  But the synthesizable (convertible
> subset that can be synthesized) is in a form similar to what exists.
>
> > Or is the problem that we don't know how to translate OO
> > into verilog/vhdl?  If its the former, I'd like to propose a couple of
> > examples that would use OO features and then you guys can pick them
> > apart and tell me how its all possible with myHdl today :-).
> >
>
> My rational for this MEP is that it fits the current structure and it is
> useful on its own (it is more than just class/object signal container).
>  More importantly OO support as some people may envision it will take
> quite a bit of hashing through (conversation).
>
> In addition, the yet to be define OO representation, more than likely,
> will require substantial conversion code modifications.  Making
> near-term inclusion unlikely.  The conversion code is quite complex.
> You need an strong understanding of the MyHDL design, the Python AST,
> and detailed knowledge of Verilog/VHDL.
>
> I think your examples in a separate thread would be worth some
> discussions and debate.  Just be prepared.  I think it is reasonable to
> expected some onus by the proposer.  The idea person also needs to be
> the person that can provide details to some extent.  I don't think it is
> reasonable for someone to only have the "idea" and expect others to come
> up with all the details.  It makes the conversations difficult and more
> than likely won't go too far because the detail creators are yet to
> share the vision.
>
> 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
>

Re: [myhdl-list] MEP-108 Bundle

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

On 6/1/12 4:37 PM, Jan Decaluwe wrote:
> On 06/01/2012 09:43 PM, Christopher Felton wrote:
>>>>
>>>> I think we should have a go at MEP 108 to remove the
>>>> confusing "class attribute" terminology. Perhaps the
>>>> explanations make it less clear than just stating what
>>>> this MEP is about. Perhaps we should just
>>>> talk about a method at the top level - I understand
>>>> methods at lower levels already worked without this MEP.
>>>>
>>>
>>> Sounds good, I should have some time tomorrow to work
>>> through the modifications you suggested.
>>>
>>
>> Ok, I was updating MEP-108 and saved and now I can't
>> access myhdl.org?
>
> ? didn't notice any issues
>

Good, it looks like it was some weird ISP problem here.
Half the websites were accessible and email worked
fine, hmmm.

ISP is behaving now, I updated MEP-108.

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

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

On 6/1/12 4:50 PM, G. Andrew Stone wrote:
> I've managed to read maybe 3/4 of the mail on this very long thread (and
> think I understand the MEP since I did find an error in the example).

I would call it a typo not an error since it wasn't a consistent 
throughout the MEP :)

> Somehow I got the idea that people aren't sure what value typical OO
> features would have in a hardware environment, so are considering
> leaving classes just a container for signals. Is that a correct
> assessment?

No, I don't think that is the correct assessment.  There hasn't been 
enough reasonable discussion on this topic to make a conclusion.  Also, 
the waters are murky.  For example, you mention "typical OO features". 
Two typical OO features are instantiation and inheritance.  HDLs by 
virtue support instantiation, including MyHDL.  That is a typical OO 
feature supported by HDLs.  So I don't think it is a clear-cut OO 
support yeah or neah.

I am not sure if I see how inheritance is useful.  I think it is a 
stretch to say you can describe synthesizable hardware in the same 
manner as you write OO software (yet to be proven).  There is a 
difference in representing a physical thing with OO inheritance (order 
and classification) and building a physical thing.  I will try and 
explain my thoughts with an example.

Take the common OO example, a vehicle.  You might have a base class that 
represents an abstract model like a vehicle [1].  Then from there you 
might define a truck, sports car, and limousine. You create the later 
models by inheriting a set of classes derived from the base vehicle 
class.  Now when you are creating the model for these different motor 
vehicles if you need to define the different engine powers you simply 
need to change a couple numbers.  And that is sufficient for the model.

But in real life, when building a motor you don't grab a base motor and 
change a couple attributes to get a more powerful motor.  But what you 
do do, is reuse components to build the different motors.  I think 
creating synthesiable descriptions are closer (not exact) to the 
real-world building of things than the abstract modeling.

[1] 
http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtpd1%2Foocon.html

I am aware of some HDL tools that take an somewhat software OO model and 
try to generate hardware.  But best of my knowledge these tools first 
compile the OO down to simple instructions to be executed (byte code) 
and then rebuild a hardware description from the byte code.  I don't 
think a tool like this fits the domain of MyHDL.  It might be a tool 
that uses MyHDL but I don't think it would be explicitly part of MyHDL.

OO for hardware design, as I currently see it, is useful for modeling. 
And useful for organizing, parameterizing, and modularizing the 
synthesizble hardware descriptions.  But the synthesizable (convertible 
subset that can be synthesized) is in a form similar to what exists.

> Or is the problem that we don't know how to translate OO
> into verilog/vhdl?  If its the former, I'd like to propose a couple of
> examples that would use OO features and then you guys can pick them
> apart and tell me how its all possible with myHdl today :-).
>

My rational for this MEP is that it fits the current structure and it is 
useful on its own (it is more than just class/object signal container). 
  More importantly OO support as some people may envision it will take 
quite a bit of hashing through (conversation).

In addition, the yet to be define OO representation, more than likely, 
will require substantial conversion code modifications.  Making 
near-term inclusion unlikely.  The conversion code is quite complex. 
You need an strong understanding of the MyHDL design, the Python AST, 
and detailed knowledge of Verilog/VHDL.

I think your examples in a separate thread would be worth some 
discussions and debate.  Just be prepared.  I think it is reasonable to 
expected some onus by the proposer.  The idea person also needs to be 
the person that can provide details to some extent.  I don't think it is 
reasonable for someone to only have the "idea" and expect others to come 
up with all the details.  It makes the conversations difficult and more 
than likely won't go too far because the detail creators are yet to 
share the vision.

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

[G. A. S. <g.a...@gm...>]

I've managed to read maybe 3/4 of the mail on this very long thread (and
think I understand the MEP since I did find an error in the example).
Somehow I got the idea that people aren't sure what value typical OO
features would have in a hardware environment, so are considering leaving
classes just a container for signals. Is that a correct assessment?  Or is
the problem that we don't know how to translate OO into verilog/vhdl?  If
its the former, I'd like to propose a couple of examples that would use OO
features and then you guys can pick them apart and tell me how its all
possible with myHdl today :-).

Cheers!
Andrew

On Fri, Jun 1, 2012 at 12:58 PM, Christopher Felton
<chr...@gm...>wrote:

> On 5/31/12 11:46 PM, G. Andrew Stone wrote:
> > Chris,
> >
> > In Example 1 of the MEP it says:
> >
> >   class  MyObj(object):
> >       def  __init__(self):
> >          x = Signal(intbv(0)[8:])
> >          y = Signal(intbv(0)[4:])
> >          z = Signal(intbv(0)[9:])
> >
> >
> > But I hope you mean:
> >
> >   class  MyObj(object):
> >       def  __init__(self):
> >          self.x = Signal(intbv(0)[8:])
> >          self.y = Signal(intbv(0)[4:])
> >          self.z = Signal(intbv(0)[9:])
> >
> > (addition of "self." to the variables)
> >
> > Or I will be VERY confused! :-)
> >
> > Cheers!
> > Andrew
> >
> >
>
> Yes, thanks for pointing out the error.  I have updated the MEP.
>
> 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
>

Re: [myhdl-list] MEP-108 Bundle

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

On 06/01/2012 09:43 PM, Christopher Felton wrote:
>>>
>>> I think we should have a go at MEP 108 to remove the
>>> confusing "class attribute" terminology. Perhaps the
>>> explanations make it less clear than just stating what
>>> this MEP is about. Perhaps we should just
>>> talk about a method at the top level - I understand
>>> methods at lower levels already worked without this MEP.
>>>
>>
>> Sounds good, I should have some time tomorrow to work
>> through the modifications you suggested.
>>
>
> Ok, I was updating MEP-108 and saved and now I can't
> access myhdl.org?

? didn't notice any issues

-- 
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] MEP-108 Bundle

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

>>
>> I think we should have a go at MEP 108 to remove the
>> confusing "class attribute" terminology. Perhaps the
>> explanations make it less clear than just stating what
>> this MEP is about. Perhaps we should just
>> talk about a method at the top level - I understand
>> methods at lower levels already worked without this MEP.
>>
>
> Sounds good, I should have some time tomorrow to work
> through the modifications you suggested.
>

Ok, I was updating MEP-108 and saved and now I can't
access myhdl.org?

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

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

On 5/31/12 11:46 PM, G. Andrew Stone wrote:
> Chris,
>
> In Example 1 of the MEP it says:
>
>   class  MyObj(object):
>       def  __init__(self):
>          x = Signal(intbv(0)[8:])
>          y = Signal(intbv(0)[4:])
>          z = Signal(intbv(0)[9:])
>
>
> But I hope you mean:
>
>   class  MyObj(object):
>       def  __init__(self):
>          self.x = Signal(intbv(0)[8:])
>          self.y = Signal(intbv(0)[4:])
>          self.z = Signal(intbv(0)[9:])
>
> (addition of "self." to the variables)
>
> Or I will be VERY confused! :-)
>
> Cheers!
> Andrew
>
>

Yes, thanks for pointing out the error.  I have updated the MEP.

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

[G. A. S. <g.a...@gm...>]

Chris,

In Example 1 of the MEP it says:

 class MyObj(object):
     def __init__(self):
        x = Signal(intbv(0)[8:])
        y = Signal(intbv(0)[4:])
        z = Signal(intbv(0)[9:])


But I hope you mean:

 class MyObj(object):
     def __init__(self):
        self.x = Signal(intbv(0)[8:])
        self.y = Signal(intbv(0)[4:])
        self.z = Signal(intbv(0)[9:])

(addition of "self." to the variables)

Or I will be VERY confused! :-)

Cheers!
Andrew

Re: [myhdl-list] 0.8 Type mismatch in enum item comparison

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

On 5/31/12 10:07 AM, Jan Coombs wrote:
> On 31/05/12 14:26, Christopher Felton wrote:
>> On 5/31/2012 8:10 AM, Jan Coombs wrote:
>>> $ ./testSdp3o4.py
>>> Traceback (most recent call last):
>>>       File "./testSdp3o4.py", line 41, in<module>
>>>         simulate(240)
>>>       File "./testSdp3o4.py", line 37, in simulate
>>>         tb = traceSignals(testSdp3o4)
>>>       File
>>> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
>>> 89, in __call__
>>>         _writeVcdSigs(vcdfile, h.hierarchy)
>>>       File
>>> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
>>> 146, in _writeVcdSigs
>>>         if s._val == None:
>>>       File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_enum.py", line
>>> 117, in __eq__
>>>         raise TypeError("Type mismatch in enum item comparison")
>>> TypeError: Type mismatch in enum item comparison
>>>
>>> No problem with 0.7. Should I try to track it down?
>>>
>>> Jan Coombs
>>
>> No might be important for you design!  Jan D. added
>> some nice features to help debug the use of enums
>> (could be your case).  Hopefully, 0.8 is flagging
>> (throwing an exception) for incorrect use of an e
>> num, where 0.7 will not.
>>
>> You might want to try and run the test without
>> traceSignals and you may get more information.
>
> It has taken me a long time to change the test code, but am now
> running without and with traceSignals.  Surprisingly I did not get
> more information; without traceSignals there is no error.
>
> So the error only appears with latest 0.8 when producing trace.
>
> Jan Coombs.

I sometimes like my testbenches to have three sim
modes selectable

   if simType == 'trace':
      dut = traceSignals(ModuleToTest, ...)
   elif simType == 'cosim':
      dut = CoSimulation(ModuleToTest, ...)
   else
     dut = ModuleToTest(..., )


Regards,
Chris

Re: [myhdl-list] MEP-108 Bundle

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

On 5/31/12 3:16 PM, Jan Decaluwe wrote:
> On 05/31/2012 03:07 AM, Christopher Felton wrote:
>
>>
>> It should have the correct parent now. Clone a fresh from the public and reviewed in hg in. Should work this time.
>
> Ok, published.
>
> I think we should have a go at MEP 108 to remove the
> confusing "class attribute" terminology. Perhaps the
> explanations make it less clear than just stating what
> this MEP is about. Perhaps we should just
> talk about a method at the top level - I understand
> methods at lower levels already worked without this MEP.
>

Sounds good, I should have some time tomorrow to work
through the modifications you suggested.

Regards,
Chris

Re: [myhdl-list] 0.8 Type mismatch in enum item comparison

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

On 05/31/2012 05:13 PM, Jan Coombs wrote:
> On 31/05/12 15:55, Jan Decaluwe wrote:
>> On 05/31/2012 03:10 PM, Jan Coombs wrote:
>>> $ ./testSdp3o4.py
>>> Traceback (most recent call last):
>>>       File "./testSdp3o4.py", line 41, in<module>
>>>         simulate(240)
>>>       File "./testSdp3o4.py", line 37, in simulate
>>>         tb = traceSignals(testSdp3o4)
>>>       File
>>> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
>>> 89, in __call__
>>>         _writeVcdSigs(vcdfile, h.hierarchy)
>>>       File
>>> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
>>> 146, in _writeVcdSigs
>>>         if s._val == None:
>>>       File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_enum.py", line
>>> 117, in __eq__
>>>         raise TypeError("Type mismatch in enum item comparison")
>>> TypeError: Type mismatch in enum item comparison
>>>
>>> No problem with 0.7. Should I try to track it down?
>>
>> Mm, this is due to the more restrictive comparisons on EnumItemType.
>>
>> Now, that 's._val == None' test is wrong also, the idiomatic test
>> is 'if s._val is None'. Could you check whether things work
>> when you make that change? (line 146 in _traceSignals.py).
>
> That fixed it, thanks.

Ok, I have made this change in 0.8-dev.

-- 
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] MEP-108 Bundle

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

On 05/31/2012 03:07 AM, Christopher Felton wrote:

>
> It should have the correct parent now. Clone a fresh from the public and reviewed in hg in. Should work this time.

Ok, published.

I think we should have a go at MEP 108 to remove the
confusing "class attribute" terminology. Perhaps the
explanations make it less clear than just stating what
this MEP is about. Perhaps we should just
talk about a method at the top level - I understand
methods at lower levels already worked without this MEP.

-- 
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] 0.8 Type mismatch in enum item comparison

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

On 31/05/12 15:55, Jan Decaluwe wrote:
> On 05/31/2012 03:10 PM, Jan Coombs wrote:
>> $ ./testSdp3o4.py
>> Traceback (most recent call last):
>>      File "./testSdp3o4.py", line 41, in<module>
>>        simulate(240)
>>      File "./testSdp3o4.py", line 37, in simulate
>>        tb = traceSignals(testSdp3o4)
>>      File
>> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
>> 89, in __call__
>>        _writeVcdSigs(vcdfile, h.hierarchy)
>>      File
>> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
>> 146, in _writeVcdSigs
>>        if s._val == None:
>>      File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_enum.py", line
>> 117, in __eq__
>>        raise TypeError("Type mismatch in enum item comparison")
>> TypeError: Type mismatch in enum item comparison
>>
>> No problem with 0.7. Should I try to track it down?
>
> Mm, this is due to the more restrictive comparisons on EnumItemType.
>
> Now, that 's._val == None' test is wrong also, the idiomatic test
> is 'if s._val is None'. Could you check whether things work
> when you make that change? (line 146 in _traceSignals.py).

That fixed it, thanks.