myhdl-list

Re: [myhdl-list] MEP : Signal Containers

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

2012/5/17 Tom Dillon <td...@di...>:
>
>
> On 05/17/2012 04:03 AM, Oscar Diaz wrote:
>> 2012/5/14 Christopher Felton<chr...@gm...>:
>>
>>> <snip>
>>>
>>> I have made some minor changes to the proposed MEP, the modifications
>>> can be found here, http://www.myhdl.org/doku.php/meps:mep-107
>>>
>>> I have been *waffling* if the class attributes should be part of this
>>> MEP or a separate MEP.  I am leaning more towards inclusion, if a class
>>> attribute is a convertible type then it can be viewed as a "Signal
>>> Container".  But it might warrant it separate MEP/thread simply because
>>> the conversation around class support might be lengthy, e.g. subset of
>>> class support (the current MEP107 and MEP108) or something different.
>> I agree: class attributes should be covered in this MEP (as we
>> discussed in this thread). However, I think this MEP should address
>> first the easy containers: lists and dictionaries, and after that
>> experience we can move to support -the more general- class attributes.
>>
> I am more interested in using classes. I am not sure what class
> attributes would do. Can someone provide an example?

My first attempt was to provide a wishbone interface:

class wishbone_iface():
    def __init__(self, data_bw = 8, addr_bw = 8)
        ....

And, use it as a container signal but also to hold other information
and/or useful functions.

>
> My use for this is really to group related signals, so that you can pass
> them as a group. Secondary use would be to provide some useful class
> functions to do redundant tasks that I would prefer to hide in the class.
>
> My simple example would be for complex numbers.  The object would simply
> store two values, real and imaginary. It would have some member
> functions like next(cplxNum), which would do the complex assignment to
> the two signals stored in the object. It would have other member
> functions as well, but you get the idea.

Let me propose a workaround: subclass dict() and add any functions you
need. That way you can access your signals like any other dict and
provide your desired functions. In fact, my previous example really
looks like this:

class wishbone_iface(dict):
    def __init__(self, data_bw = 8, addr_bw = 8, **kwargs)
        ....

If we start with lists and dicts, we already cover subclassing of
these objects, and have customized containers as if you make your own
class.

Implementation of this functionality requires the conversor to extract
a complete list of convertible objects (signals and constants),
something easy for lists and dicts, but not that easy for a generic
class.

Of course you can argue: "use dir() to get a list of class
attributes", but what about classes that implements __getattr__() to
custom access class attributes? I'd like to have support for class
attributes, but it's still unclear to me how complex this can be, and
also if there's a real need to support it.

>
> Now, this all works now, other than you can't use the class object as a
> top level port of your MyHDL module.  For now, I have to make a top
> level wrapper that breaks out the complex object into its real and
> imaginary signals and creates twice as many ports. Not horrible, but it
> is tedious and prone to errors.

I know what you mean, I did suffer a lot doing the same thing :)

>
> What I think would be useful, is for the class to have some hooks for
> conversion. For instance you may want to tell it to break out the object
> into two separate signals. Or you may want to concatenate them together
> into one long vector.

I think the default behavior should be break into separate signals.
Its easier to support long names for signals that deal with complex
structures in VHDL and Verilog. By the way even for distributable IP
cores, you can find that interfaces are just a plain list of signals.
In fact I never have seen VHDL "records" in the projects I've been
working.

The issue here is that the conversor must create unique identifiers
for its signals, this MEP deals with this naming scheme and its
implementation.

Concatenation is another thing, I think it's supported already by
shadow signals.

>
> I am very unfamiliar with conversion so have no idea the best way to
> achieve something like this.
>
> I guess I need to understand other issues to know what everybody else
> wants out of this.
>
> Tom
>
>

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

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

On 5/17/12 9:52 AM, Oscar Diaz wrote:
> 2012/5/17 Tom Dillon<td...@di...>:
>>
>>
>> On 05/17/2012 04:03 AM, Oscar Diaz wrote:
>>> 2012/5/14 Christopher Felton<chr...@gm...>:
>>>
>>>> <snip>
>>>>
>>>> I have made some minor changes to the proposed MEP, the modifications
>>>> can be found here, http://www.myhdl.org/doku.php/meps:mep-107
>>>>
>>>> I have been *waffling* if the class attributes should be part of this
>>>> MEP or a separate MEP.  I am leaning more towards inclusion, if a class
>>>> attribute is a convertible type then it can be viewed as a "Signal
>>>> Container".  But it might warrant it separate MEP/thread simply because
>>>> the conversation around class support might be lengthy, e.g. subset of
>>>> class support (the current MEP107 and MEP108) or something different.
>>> I agree: class attributes should be covered in this MEP (as we
>>> discussed in this thread). However, I think this MEP should address
>>> first the easy containers: lists and dictionaries, and after that
>>> experience we can move to support -the more general- class attributes.
>>>
>> I am more interested in using classes. I am not sure what class
>> attributes would do. Can someone provide an example?
>
> My first attempt was to provide a wishbone interface:
>
> class wishbone_iface():
>      def __init__(self, data_bw = 8, addr_bw = 8)
>          ....
>
> And, use it as a container signal but also to hold other information
> and/or useful functions.
>
>>
>> My use for this is really to group related signals, so that you can pass
>> them as a group. Secondary use would be to provide some useful class
>> functions to do redundant tasks that I would prefer to hide in the class.
>>
>> My simple example would be for complex numbers.  The object would simply
>> store two values, real and imaginary. It would have some member
>> functions like next(cplxNum), which would do the complex assignment to
>> the two signals stored in the object. It would have other member
>> functions as well, but you get the idea.
>
> Let me propose a workaround: subclass dict() and add any functions you
> need. That way you can access your signals like any other dict and
> provide your desired functions. In fact, my previous example really
> looks like this:
>
> class wishbone_iface(dict):
>      def __init__(self, data_bw = 8, addr_bw = 8, **kwargs)
>          ....
>
> If we start with lists and dicts, we already cover subclassing of
> these objects, and have customized containers as if you make your own
> class.
>
> Implementation of this functionality requires the conversor to extract
> a complete list of convertible objects (signals and constants),
> something easy for lists and dicts, but not that easy for a generic
> class.
>

I guess I am not following where this conversation went.  Tom asked if 
the complex signal example could be used to *contain* the multiple 
signal related with a complex type and add some methods that work on the 
signals (which would be attributes to the complex object).  The first 
would be supported by the MEP the later would not in the traditional OO 
sense.  But you could write the HDL that describes the assignment in the 
same class.

I don't follow what Oscar means by "starting with lists and dicts, we 
already cover subclassing of these objects ...".  You lost me there.

I don't see that starting with heterogeneous lists (homogenous list of 
signals already supported) and dictionaries is easier or a more 
straight-forward path.  Other than the philosophical confusion using 
classes as Signal Containers I believe they all have the same difficulty 
implementing (my guess, the class attributes might actually be simpler 
to parse the hierarchy).

Back to the complex example, if you wanted to write the method that 
would do the assignment it would have to be a current MyHDL description, 
tried to capture in the example below.

     class Complex(object):
         def __init__(self, max=8, min=8):
             self.real = Signal(intbv(0, min=min, max=max))
             self.imag = Signal(intbv(0, min=min, max=max))

         def assign(self, clk, val):
             @always(clk.posedge)
             def hdl_assign():
                 self.real.next = val.real
                 self.imag.next = val.imag

             return hdl_assign


Now the question is how could this be used.  You would have to create 
instantiations of the types and the /assign/ HDL.

     def SomeOtherHdl(clk)
         c1 = Complex()
         c2 = Complex()
         iAssign1 = c1.assign(clk, c2)
         iAssign2 = c2.assign(clk, c1)

         return iAssign1, iAssign2

The above does absolutely nothing, just an example to illustrate some of 
the above conversations/questions (could do an add and multiply example 
if we wanted something that actually could be usable).

But what might be more desirable, would be:

     def SomeOtherHdl(clk)
         c1 = Complex()
         c2 = Complex()

         @always(clk.posedge)
         def hdl():
             c1.assign(c2)
             c2.assign(c1)

         return hdl

In this second example the /assign/ would probably have to look 
different than what was written in the above Complex description. 
/assign/ would need to be more like a VHDL or Verilog function that 
would be reducible to a combinatorial expression.  I don't think the 
second example is feasible to implement without considerable 
consideration and thought (at least not by me).  In short, class methods 
would not be usable as Tom described.

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

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

<lots of snips>
> Where I inlined my responses might have made it confusing.  First, the
> reference to MEP-108 was simply to respond to your overall comment (or
> at least my interpretation) that /class methods/ be convertible.  If you
> meant /class method/ conversion would be of interest then MEP-108 is
> relevant, if not I misunderstood.

Any misunderstanding is from my end, I am a little rusty and being a 
little lazy and just asking questions to get back into the flow here.
>
> The advantage of a class method over a function ... no advantage per se.
>    They both achieve the same thing in the similar manner.  But it gives
> the ability to use a method versus a function if someone wanted.
>
> We have had this conversation a couple times in the past.  The current
> solution is to have a method that returns the generators from the
> function, essentially wrapping a function in a /class method/.  By
> allowing the /class method/ to be directly convertible would remove the
> need to wrap a function.

yes, that is how I have been using classes thus far. I get the object 
setup the way I want it then call a function to return the logic 
(generators).


>
> MEP-108 is simple, its only intention is to enable a /class method/ the
> same as a function.  My best example of why you might want to do this is
> the following example, http://bit.ly/w95kOd.
>
> The /class method/ conversion and the /class attribute/ can be viewed as
> separate.  They can be used together but nothing says they have to be
> and the reason for the separate MEPs.  The idea of the /class
> attribute/, when it is a Signal (a.k.a  Signal container), basically
> helps manage namespace and organize collection of Signals.  The MEP-107
> for the attributes simply proposes to create a unique name for /class
> attribute/ when it is a Signal.
>
> If the example in the previous post (the wishbone) didn't illustrate how
> /class attributes/ could be used, either I am poorly explaining or we
> might have a misunderstanding what a /class attribute/ is.  I guess, I
> would refer you back to the internal bus examples I and Oscar provided.

I saw the term class attribute and thought it might be something more 
that converting signals in a class. I thought I was missing a feature 
that was being talked about.


>
> Or maybe there is confusion because it is a basic enhancement proposal
> and you are thinking it might be something more.  The use of classes to
> "contain" Signals doesn't mean a new type is created (this deeply
> depends on ones definition of *type*).  As mentioned, the class is used
> as a VHDL record or SystemVerilog struct and nothing more.  You can't
> build new types, then inherit to create yet another new type and define
> operations and behaviors on the new types.  But as a Signal container it
> still has a lot of benefit and usage in my opinion.  Hope that makes sense?

Yes, I see now.

Thanks.

Re: [myhdl-list] MEP : Signal Containers

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

On 5/18/12 3:17 PM, Tom Dillon wrote:
> <lots of snips>

>
> I saw the term class attribute and thought it might be something more
> that converting signals in a class. I thought I was missing a feature
> that was being talked about.
>

Yes, it took me a while to understand what a Python /class attribute/ 
was referring to as well.

 From the Python tutorial (documentation)

"""
By the way, I use the word attribute for any name following a dot — for 
example, in the expression z.real, real is an attribute of the object z. 
Strictly speaking, references to names in modules are attribute 
references: in the expression modname.funcname, modname is a module 
object and funcname is an attribute of it. In this case there happens to 
be a straightforward mapping between the module’s attributes and the 
global names defined in the module: they share the same namespace! [1]
"""

I also used the above link as a reference/link in the MEP-107.

And in these discussions the proposal is to convert class attributes of 
the type(SignalType) and constants (the later not mentioned in the 
current version of the MEP, because what is a constant?).

Thanks for the questions, it is worthwhile working through explaining 
exactly what is supported.  My guess is there could be a lot of 
confusion.  It adds some good features but might cause additional 
confusion what is convertible if one is most familiar with OO software 
development.

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

[Norbo <Nor...@gm...>]

My idea is to bring it together:

So one proposal is to add conversion support for functions inside a class  
like this:
-------------------------------
class Adder():
    def __init__(self):
       pass
    def hdl(self, x, y, z):
       @always_comb
       def _hdl():
          z.next = x + y
       return _hdl
...
...
toVerilog(adder, x, y, z)
toVHDL(adder, x, y, z)
-------------------------------
to do this the self argument needs to be ignored in the conversion


The other proposal seems to be, using classes as signal container.
like previously posted:
-----------------------------------------
      class WishboneBus(object):
          def __init__(self, DataWidth=16, AddressWidth=8):
              self.clk = Signal(False)
              self.rst = Signal(False)
              self.cyc = Signal(False)
              self.stb = Signal(False)
              self.adr = Signal(intbv(0)[AddressWeidth:])
              self.dat_i = Signal(intbv(0)[DataWidth:])
              self.dat_o = Signal(intbv(0)[DataWidth:])
              self.we = Signal(False)
              self.sel = Signal(intbv(0)[int(DataWidth/8)"])
              self.ack = Signal(False)

      def WbGpio(wb_bus, outs, ints):
	...

      wb_bus = WishboneBus()
      outs = Signal(intbv(0)[8:])
      ints = Signal(intbv(0)[8:])
      iGpio = WbGpio(wb_bus, outs, ins)

And for conversion:
      toVHDL(WbGpio, wb_bus, outs, ins)  ### here the class signals are  
added to the port in the conversion
-----------------------------------------------------
there all the class internal signals are added to the port in the  
conversion.
What if the "self" is accepted as a class instance and every signal of it  
is written in the conversion as a port signal also
Becaus then it is probably posible to write Whisbone pheriperials like  
this:

      class WishboneBus(object):
          def __init__(self, DataWidth=16, AddressWidth=8):
              self.clk = Signal(False)
              self.rst = Signal(False)
              self.cyc = Signal(False)
              self.stb = Signal(False)
              self.adr = Signal(intbv(0)[AddressWeidth:])
              self.dat_i = Signal(intbv(0)[DataWidth:])
              self.dat_o = Signal(intbv(0)[DataWidth:])
              self.we = Signal(False)
              self.sel = Signal(intbv(0)[int(DataWidth/8)"])
              self.ack = Signal(False)

      class WbPheripherialClass(WishboneBus)  ### inherits all signals from  
WishbonBus
	 def WbGpio(self,outs, ints):   ### the self stand for all the WishbonBus  
signals
              @always_comb
	     def .......

	 def WbRS232(self,iRX, oTX):
		.....	

	

     Wbobj=WbPheripherialClass()
     toVHDL(Wbobj.WbGpio, outs, ins)  ### all signals in the "self" are  
also inserted into the port in the conversion.

or that if you instanciate them:

     outs = Signal(intbv(0)[8:])
     ints = Signal(intbv(0)[8:])
     iRX = Signal(bool(0))
     oTX = Signal(bool(0))
     Wbobj=WbPheripherialClass()
     Gpio_inst=Wbobj.WbGpio(outs,ints)
     RS232_inst=Wbobj.WbRS232(iRX,oTX)

so that all the shared signals are magically connected and writing to the  
signals maybe could be done by:
     Wbobj.clk.next=1


No this is not really thought through or confusing.
anyway:

greetings
Norbo

Re: [myhdl-list] MEP : Signal Containers

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

On 5/19/12 9:20 AM, Norbo wrote:
>
> My idea is to bring it together:

At one point I did have them in the same MEP.  But at this time I think 
it would be best to keep them separate.  But I do think they can be used 
in conjunction and future MEPs might add some additional features to 
combine.  At this point I think the current enhancement is work enough.

<snip>
> What if the "self" is accepted as a class instance and every signal of it
> is written in the conversion as a port signal also
> Becaus then it is probably posible to write Whisbone pheriperials like
> this:
>
>        class WishboneBus(object):
>            def __init__(self, DataWidth=16, AddressWidth=8):
>                self.clk = Signal(False)
>                self.rst = Signal(False)
>                self.cyc = Signal(False)
>                self.stb = Signal(False)
>                self.adr = Signal(intbv(0)[AddressWeidth:])
>                self.dat_i = Signal(intbv(0)[DataWidth:])
>                self.dat_o = Signal(intbv(0)[DataWidth:])
>                self.we = Signal(False)
>                self.sel = Signal(intbv(0)[int(DataWidth/8)"])
>                self.ack = Signal(False)
>
>        class WbPheripherialClass(WishboneBus)  ### inherits all signals from
> WishbonBus
> 	 def WbGpio(self,outs, ints):   ### the self stand for all the WishbonBus
> signals
>                @always_comb
> 	     def .......
>
> 	 def WbRS232(self,iRX, oTX):
> 		.....	

My concern with this is that attributes would be limited to ports and 
not also available as non-ports.  I think there are cases where you 
might just want to use attributes internally or maybe a mix, e.g. only 
pass a subset of the signals to a separate module.

Regards,
Chris Felton

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

[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

[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/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...>]

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

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

[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

[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

[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