myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

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

On 5/16/12 7:54 AM, Jan Coombs wrote:
> On 16/05/12 12:58, Oscar Diaz wrote:
>      . . . [big snip]
>>
>> What I wanted to say is that Christopher's proposal maybe is not
>> suitable for all cases, and IMHO one of the strengths of MyHDL is that
>> it doesn't tie you to a particular way to describe your objects at
>> high level, the only condition is that you provide a list of
>> generators and signals that link them, but you can use whatever you
>> want to create them.
>
> If Chris L. wants a higher level of abstraction, this will likely
> still depend on tools to describe RTL, for example MyHDL.
> Suggesting that this might be an extension, or revised expression
> method for MyHDL is incorrect, because it, like IP modules, is not
> expressed at the same level of abstraction.

I think this is a point often missed.  If you look at it as a tool stack 
there probably will be multiple packages for this magical VHL 
(very-high-level) hardware description/conversion package and MyHDL will 
be an important package in the stack.  But something outside the MyHDL 
goals would probably be required.  I say outside the MyHDL goals because 
I think the VHL-DH will have many constraints where MyHDL like the other 
HDLs at similar abstractions levels are more general.

If you look at the other attempts this is what was being done.  Some 
projects provide means to connect things via streams (similar to the 
streams-C hdl).  And then created state-machines a certain way 
(sometimes using a cpu?), module connections, etc.  You traded possibly 
a simplified description for loss of implementation control.

>
>> The Hardware Module Class can be the base class of a particular set of
>> IP cores, but it shouldn't be part of core MyHDL. In this case, making
>> an analogy to software development, you could think this class as a
>> "library" that "programs" (IP cores) can use.
>
> Agreed, perhaps "Hardware Module Class" is misnamed?  RTLs like
> MyHDL express designs at an abstraction level significantly above
> hardware.

I lack the ability to see how the Hardware class thing is useful at all.

>
> Or maybe there is confusion; When showing interest in whether block
> RAMs in async logic chips are conventional RAMs in an async
> wrapper, or truly constructed from async logic, Chris L. suggested:
>
> "What is needed is a class called ClocklessGateArray, which you
> could just use, or read the code to see how it is modelled."

This whole tangent on async FPGA hasn't been that useful.  I missed what 
was trying to be achieved.  To use MyHDL on an Achronix FPGA, in that 
case nothing needs to be done just code away.  Or the interest to 
describe at a higher-level async logic.  If that latter see an older 
thread where this was discussed (a couple years ago).

Regards,
Chris

Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

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

On 5/17/12 5:22 AM, Oscar Diaz wrote:
> 2012/5/16 Christopher Lozinski<loz...@fr...>:
>> First thank you for the comments on my hardware module proposal.  I
>> learned a lot.  I always learn a lot from this group.
>>
>> On 5/16/12 6:58 AM, Oscar Diaz wrote:
>>> And following with the previous discussion, Christopher has proposed a
>>> particular abstraction through his Hardware Module Class. Although I
>>> think it's a correct proposal, maybe it's not suitable in other cases.
>>> Let me give you an example:
>>
>> So first I will admit I am extreme.  There is always a spectrum between
>> the functional approaches, and the object-oriented approaches.  I
>> strongly lean one way.  The lesson from python is that to gain broad
>> market adoption, both approaches must be supported.  But there are
>> reasons why I am extreme.
>>
>> One of my core beliefs is that software components should map directly
>> to hardware components.   It is just so much easier to understand.  Then
>> as the world changes, as the design evolves, the software component is
>> more likely to evolve easily.
>
> Well, keep in mind that developing software comes with a price in
> terms of performance, if you compare it with a pure hardware
> implementation; I mean a processor, as a general-purpose hardware, is
> slower, bigger and more power hungry that a custom hardware. On the
> other hand, designing hardware is more complex than writing software.
> Here you need to find a compromise between performance and complexity.
> I'm telling you this because, for some applications you just need to
> design for top performance (and of course, you have to deal with the
> added complexity).

I agree, you don't want to comprises the generality of MyHDL (the 
ability do explicitly describe the low-levels) in exchange for a 
different abstraction layer.  That is why I believe this VHLD 
(very-high-level-description) will be a separate package that uses MyHDL 
but not incorporated into MyHDL.

>
>> So if you do not want to initially model
>> ports, that is fine.  But do still have a class that models your high
>> level hardware module.  Of course if you are working at even higher
>> levels, no worries.
>>
>> Sure people can say this is just a software library.  Let us call it
>> OOHDL.   For Object-Oriented HDL.  But it is much more than that.  It is
>> a world view.   You get some benefit from reusing libraries.  You get a
>> lot more benefit from having a certain world view.   There are many
>> benefits from this world view, but the primary one is for new users.
>> Imagine the sales pitch.
>>
>> OOHDL is a library of objects for modeling, designing and simulating
>> digital designs.  Each class represents a real world hardware module
>> like clocks, multiplexers, memory, and other devices.   You use a
>> graphical tool to assemble your design from software components, or even
>> to design new components.  You can click into each hardware module to
>> see the hardware hierarchy. When you need to, you can even create new
>> hardware modules in python, optionally reusing existing hardware modules.
>>
>> By retaining the MyHDL functional approach, you greatly loose the
>> benefits of a pure OO approach, particularly the ability for new users
>> to understand, learn and use the system.   Let there be no doubt that I
>> had and still do have huge difficulty understanding MyHDL.  A class
>> library matching to hardware modules and signal types would have been so
>> much easier for me to understand, subclass and assemble.
>
> I understand your motivation, and I think is a valid idea. But, as I
> said it comes with a price: when you develop a digital design with
> OOHDL, you're imposing a particular way to model its modules, i.e. the
> way you declare ports, or how the relationships between modules are
> made.

Unfortunately, I don't understand his motives and not sure if it is a 
valid idea.  It would take much more conversation than I committed to 
right now.  But I don't know if I see the use (doesn't mean I can't be 
convinced) of a object inheritance building scheme for designing 
hardware behavior that is actually synthesized to hardware.

What I mean by this is that current HDLs use instantiation largely. 
They aren't considered OO languages but HDLs had instantiation from the 
get go.  You can build something out of other things, kinda like you do 
in real life.  But what you don't do is *inherit*.  A shift register 
does not inherit from a flip-flop but you could described a 
shift-register by instantiating a gaggle of ff.  I don't know if I see a 
use for hardware description which uses inheritance.

As we said, not much interest in this low-level building only useful for 
discussion.  For a more complex example, how would you propose building 
different Ethernet controllers and Ethernet tcp/ip offload engines off 
*inheritance* vs. instantiation.  I can visualize where component reuse 
is utilized (same as current instantiations and parameterization) but 
not via OO inheritance.

Regards,
Chris Felton

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

[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 10:28 AM, Tom Dillon wrote:
>
>
> On 05/18/2012 10:08 AM, Christopher Felton wrote:
>> On 5/17/12 8:35 AM, Tom Dillon wrote:
>>>
>>> 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?
>> I have already implemented this feature and created a MEP write-up,
>> MEP-108, http://www.myhdl.org/doku.php/meps:mep-108.  There hasn't been
>> much discussion so I haven't posted the patch yet.  I will post the
>> patch soon.
>
> Read that over quickly. What is the advantage to that over a function?
>
> Also, how do class attributes fit into this? I think I may not undertand
> what they are and how they would be used in MyHDL.
>

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.

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.

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.

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?

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

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

On 05/18/2012 10:08 AM, Christopher Felton wrote:
> On 5/17/12 8:35 AM, Tom Dillon wrote:
>>
>> 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?
> I have already implemented this feature and created a MEP write-up,
> MEP-108, http://www.myhdl.org/doku.php/meps:mep-108.  There hasn't been
> much discussion so I haven't posted the patch yet.  I will post the
> patch soon.

Read that over quickly. What is the advantage to that over a function?

Also, how do class attributes fit into this? I think I may not undertand 
what they are and how they would be used in MyHDL.

Re: [myhdl-list] MEP : Signal Containers

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

On 5/17/12 8:35 AM, Tom Dillon wrote:
>
>
> 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?

I have already implemented this feature and created a MEP write-up, 
MEP-108, http://www.myhdl.org/doku.php/meps:mep-108.  There hasn't been 
much discussion so I haven't posted the patch yet.  I will post the 
patch soon.

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

Yes, that is the intent of the class attribute "signal container".  A 
tool to group associated signals, like an embedded bus such as, Wishbone 
or Avalon.

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

A complex number is a good example as well but also an example that 
illustrates why I have some reservations.

With a complex number, in the SW world you also would want to define the 
operators on the new "type".  This MEP only covers class use as a 
container and not general OO.  That is my worry given some of the recent 
threads that this will open more confusion and misunderstanding, at 
least with Mr.Issues.

The signal container MEP is simply to use the classes like a VHDL record 
or an SV struct.  You can group associated signals and constants.  But I 
think the class attribute signal container could be very useful if the 
confusion can be curbed.

>
> 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 believe I have this resolved as long as the community agrees with the 
"feature", i.e gives the thumbs up.

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

I think the "hooks" could be a follow-on feature.  I believe the current 
proposal is clear that it only allows the class attribute to be used a 
signal container.  You still need to use the contained signal the same 
as you would handle current signals.  Once the straight-up signal 
attribute and class methods are supported it is a good stepping stone 
for what you suggest.

As mentioned, probably the most familiar example (I will add this to the 
MEP) is an embedded bus.  I can create the following class

     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)


In the above example the embedded bus is contained in the class 
description.  The benefit is clumping associated signals together.  It 
simply makes the hardware description more compact without losing 
descriptive information.  In the above example, if I have a bunch of 
peripherals the bus that connects them all is in a neat compact 
description.  As the MEP indicates the converted code these will all be 
individual signals in the lower HDLs, mainly so that the older most 
supported versions of Verilog/VHDL can be supported.

Regards,
Chris

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 05/17/2012 03:35 PM, Jan Decaluwe wrote:
> On 05/11/2012 04:37 PM, Tom Dillon wrote:
>>
>> On 05/11/2012 09:25 AM, Christopher Felton wrote:
>>> Yes, for the 0.8dev you have to check it out of the repo,
>>> http://www.myhdl.org/doku.php/dev:repo.
>>>
>>> Jan D. started a list of items for 0.8 release,
>>> http://www.myhdl.org/doku.php/dev:0.8.  There are additional tweaks that
>>> are not mentioned (I think) like the performance modifications to the
>>> Signal.
>>>
>>> I have been using the 0.8dev without issues.  With any repo tip or
>>> development branch use with caution.  Jan D. has put together a fairly
>>> comprehensive set of unit/regression tests.  Most cases nothing is
>>> committed to the repo if it doesn't pass the tests.  Meaning that the
>>> dev branches is pretty stable.
>>>
>>> Thing to note, if you clone the repo, named branches are being used for
>>> development.  After you clone the repo you have to "update" to the
>>> development branch, example.
>>>
>>>       >>    hg clone http://hg.myhdl.org/myhdl
>>>       >>    hg branches
>>>       >>    hg up -C 0.8dev
>> Thanks. Is there an easy to tell what version you are using? I know,
>> getting a little lazy now.
> Perhaps you mean which branch you are on:
>
> hg branch
>
> To see all available branches:
>
> hg branches
>
> Currently, 0.8-dev is used as development branch for 0.8, and default
> as the maintenance branch for 0.7.

No, I wanted to make sure python was loading the one I wanted. I am on 
0.8dev now and it is working fine.

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 05/11/2012 04:37 PM, Tom Dillon wrote:
>
>
> On 05/11/2012 09:25 AM, Christopher Felton wrote:
>> Yes, for the 0.8dev you have to check it out of the repo,
>> http://www.myhdl.org/doku.php/dev:repo.
>>
>> Jan D. started a list of items for 0.8 release,
>> http://www.myhdl.org/doku.php/dev:0.8.  There are additional tweaks that
>> are not mentioned (I think) like the performance modifications to the
>> Signal.
>>
>> I have been using the 0.8dev without issues.  With any repo tip or
>> development branch use with caution.  Jan D. has put together a fairly
>> comprehensive set of unit/regression tests.  Most cases nothing is
>> committed to the repo if it doesn't pass the tests.  Meaning that the
>> dev branches is pretty stable.
>>
>> Thing to note, if you clone the repo, named branches are being used for
>> development.  After you clone the repo you have to "update" to the
>> development branch, example.
>>
>>      >>   hg clone http://hg.myhdl.org/myhdl
>>      >>   hg branches
>>      >>   hg up -C 0.8dev
>
> Thanks. Is there an easy to tell what version you are using? I know,
> getting a little lazy now.

Perhaps you mean which branch you are on:

hg branch

To see all available branches:

hg branches

Currently, 0.8-dev is used as development branch for 0.8, and default
as the maintenance branch for 0.7.

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

[Tom D. <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 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.

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.

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

Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

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

2012/5/16 Christopher Lozinski <loz...@fr...>:
> First thank you for the comments on my hardware module proposal.  I
> learned a lot.  I always learn a lot from this group.
>
> On 5/16/12 6:58 AM, Oscar Diaz wrote:
>> And following with the previous discussion, Christopher has proposed a
>> particular abstraction through his Hardware Module Class. Although I
>> think it's a correct proposal, maybe it's not suitable in other cases.
>> Let me give you an example:
>
> So first I will admit I am extreme.  There is always a spectrum between
> the functional approaches, and the object-oriented approaches.  I
> strongly lean one way.  The lesson from python is that to gain broad
> market adoption, both approaches must be supported.  But there are
> reasons why I am extreme.
>
> One of my core beliefs is that software components should map directly
> to hardware components.   It is just so much easier to understand.  Then
> as the world changes, as the design evolves, the software component is
> more likely to evolve easily.

Well, keep in mind that developing software comes with a price in
terms of performance, if you compare it with a pure hardware
implementation; I mean a processor, as a general-purpose hardware, is
slower, bigger and more power hungry that a custom hardware. On the
other hand, designing hardware is more complex than writing software.
Here you need to find a compromise between performance and complexity.
I'm telling you this because, for some applications you just need to
design for top performance (and of course, you have to deal with the
added complexity).

> So if you do not want to initially model
> ports, that is fine.  But do still have a class that models your high
> level hardware module.  Of course if you are working at even higher
> levels, no worries.
>
> Sure people can say this is just a software library.  Let us call it
> OOHDL.   For Object-Oriented HDL.  But it is much more than that.  It is
> a world view.   You get some benefit from reusing libraries.  You get a
> lot more benefit from having a certain world view.   There are many
> benefits from this world view, but the primary one is for new users.
> Imagine the sales pitch.
>
> OOHDL is a library of objects for modeling, designing and simulating
> digital designs.  Each class represents a real world hardware module
> like clocks, multiplexers, memory, and other devices.   You use a
> graphical tool to assemble your design from software components, or even
> to design new components.  You can click into each hardware module to
> see the hardware hierarchy. When you need to, you can even create new
> hardware modules in python, optionally reusing existing hardware modules.
>
> By retaining the MyHDL functional approach, you greatly loose the
> benefits of a pure OO approach, particularly the ability for new users
> to understand, learn and use the system.   Let there be no doubt that I
> had and still do have huge difficulty understanding MyHDL.  A class
> library matching to hardware modules and signal types would have been so
> much easier for me to understand, subclass and assemble.

I understand your motivation, and I think is a valid idea. But, as I
said it comes with a price: when you develop a digital design with
OOHDL, you're imposing a particular way to model its modules, i.e. the
way you declare ports, or how the relationships between modules are
made.

However, don't be discouraged, IMHO for an OO approach it is necessary
to define a class hierarchy and some sort of an API for
interoperability between its objects. The really hard part is to come
with such library that satisfy most of the design needs. The "price" I
mentioned before is unavoidable, but at least we should find a way to
"lower that price" as much as possible.

>
> That would make this into a much more vibrant community.
>
> Regards
> Chris L.
>
> ------------------------------------------------------------------------------
> 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

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

2012/5/14 Christopher Felton <chr...@gm...>:
> On 11/14/2011 10:32 PM, Christopher Felton wrote:
>> The following is a *start* to a MEP that describes the conversion
>> support for classes, lists, and dictionaries.  This is just a start of
>> the enhancement description and does not include some of the mechanical
>> (code changes) items worth identifying in a MEP.
>>
> <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.

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



-- 
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] Example of MyHDL for Python Developers Documentation

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

First thank you for the comments on my hardware module proposal.  I
learned a lot.  I always learn a lot from this group.  

On 5/16/12 6:58 AM, Oscar Diaz wrote:
> And following with the previous discussion, Christopher has proposed a
> particular abstraction through his Hardware Module Class. Although I
> think it's a correct proposal, maybe it's not suitable in other cases.
> Let me give you an example:

So first I will admit I am extreme.  There is always a spectrum between
the functional approaches, and the object-oriented approaches.  I
strongly lean one way.  The lesson from python is that to gain broad
market adoption, both approaches must be supported.  But there are
reasons why I am extreme.

One of my core beliefs is that software components should map directly
to hardware components.   It is just so much easier to understand.  Then
as the world changes, as the design evolves, the software component is
more likely to evolve easily.  So if you do not want to initially model
ports, that is fine.  But do still have a class that models your high
level hardware module.  Of course if you are working at even higher
levels, no worries.

Sure people can say this is just a software library.  Let us call it
OOHDL.   For Object-Oriented HDL.  But it is much more than that.  It is
a world view.   You get some benefit from reusing libraries.  You get a
lot more benefit from having a certain world view.   There are many
benefits from this world view, but the primary one is for new users.  
Imagine the sales pitch.

OOHDL is a library of objects for modeling, designing and simulating
digital designs.  Each class represents a real world hardware module
like clocks, multiplexers, memory, and other devices.   You use a
graphical tool to assemble your design from software components, or even
to design new components.  You can click into each hardware module to
see the hardware hierarchy. When you need to, you can even create new
hardware modules in python, optionally reusing existing hardware modules.  

By retaining the MyHDL functional approach, you greatly loose the
benefits of a pure OO approach, particularly the ability for new users
to understand, learn and use the system.   Let there be no doubt that I
had and still do have huge difficulty understanding MyHDL.  A class
library matching to hardware modules and signal types would have been so
much easier for me to understand, subclass and assemble. 

That would make this into a much more vibrant community.

Regards
Chris L.

Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

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

On 16/05/12 12:58, Oscar Diaz wrote:
    . . . [big snip]
>
> What I wanted to say is that Christopher's proposal maybe is not
> suitable for all cases, and IMHO one of the strengths of MyHDL is that
> it doesn't tie you to a particular way to describe your objects at
> high level, the only condition is that you provide a list of
> generators and signals that link them, but you can use whatever you
> want to create them.

If Chris L. wants a higher level of abstraction, this will likely 
still depend on tools to describe RTL, for example MyHDL. 
Suggesting that this might be an extension, or revised expression 
method for MyHDL is incorrect, because it, like IP modules, is not 
expressed at the same level of abstraction.

> The Hardware Module Class can be the base class of a particular set of
> IP cores, but it shouldn't be part of core MyHDL. In this case, making
> an analogy to software development, you could think this class as a
> "library" that "programs" (IP cores) can use.

Agreed, perhaps "Hardware Module Class" is misnamed?  RTLs like 
MyHDL express designs at an abstraction level significantly above 
hardware.

Or maybe there is confusion; When showing interest in whether block 
RAMs in async logic chips are conventional RAMs in an async 
wrapper, or truly constructed from async logic, Chris L. suggested:

"What is needed is a class called ClocklessGateArray, which you 
could just use, or read the code to see how it is modelled."

This answer might/might-not be right, because, to write this class 
a person might/might-not choose to incorporate the information 
derived by answering my original question about RAMs in async gate 
array fabric.

Jan Coombs.

Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

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

2012/5/12 Christopher Felton <chr...@gm...>:
> On 5/3/2012 10:03 AM, G. Andrew Stone wrote:
>> In fact, what I thought myHDL was going to let me do is create classes that
>> define blocks of logic at the RTL level (synthesizable), perhaps with
>> inputs and output "Signals" as variables passed in the constructor and then
>> by instantiating those classes I'd be in effect plunking down copies of
>> that logic in the FPGA (or within larger logic blocks by instantiating
>> these within the constructor of another class).  4 years ago I did not ever
>> figure out how to do this... I don't think anything wrapped in a class was
>> synthesizable back then.  But maybe that has changed now; I haven't tried
>> using classes since.
>
> These are some good points and similar topics pop up here and there. And
> based on these threads Jan D. has made some good changes to the
> documentation; -splitting the sections- and the "What MyHDL is not"
> page.  Hopefully, these help set the expectations and clear up some of
> the confusion?

Sorry for joining the thread so late, but I want to tell my opinions
about OO paradigm for hardware development.

I agree everyone has different objectives and needs when using MyHDL;
in my case I want to use it mostly for synthesis (I mean replace VHDL
in my daily work, letting MyHDL to generate the code to pass the
synthesizer), but also I did some simulation stuff. IMHO the direction
this project is following is the correct one: a generic paradigm where
you have concurrent objects with "signal" objects that communicate
them, and a event-driven simulation support (Jan: correct me if I
misunderstood something ;) ). And based on this paradigm you build
your models or even frameworks for your modelling (and implementation)
needs.

OO paradigm is implicit in HDL development, a synthesized design is
described by primitive objects and connections between them. The
interesting part is to make the correct abstractions in order to make
your design efforts easier and/or error-proof...

>
>  From my point of view; your class use case is only partially usable. If
> you pass the ports to the instantiation that object is literally "tied"
> in a particular use.  If I follow your description, in the following
> example I have a hypothetical python class and python function
> implementations, which is which.
>
>    a,b,c,d,w,x,y,z = [Signal(False) for ii in range(8)]
>    iFoo = Foo(a,b,w,x)
>    iBar = Bar(c,d,y,z)
>    toVerilog(iFoo, a,b,w,x)
>    toVerilog(iBar, c,d,y,z)
>
> If I added more code (use code not implementation) it might become
> clearer which is which.
>
> In my case, I actually do not want to pass the "ports" to my
> instantiation but rather the parameters of the design.  If we are
> talking about using classes to model and describe complex pieces of
> hardware the "IP" usually includes much more than the hardware description.
>
> If you get a complex piece of IP today is has a ton of stuff that comes
> with it.  It has the hardware description (Verilog/VHDL), scripts galore
> (tcl or worse perl), and models in C/C++/SystemC, Matlab, or whatever
> else HLL.  In my mind, Python/MyHDL objects are a great tool for
> simplifying complex IP organization.

And following with the previous discussion, Christopher has proposed a
particular abstraction through his Hardware Module Class. Although I
think it's a correct proposal, maybe it's not suitable in other cases.
Let me give you an example:

I want to design a module that has some I/O ports, that are part of a
bigger system compound by some of those modules interconnected between
them. First part of the design process is to check the communication
scheme used at a system level, so I want to build a model at high
level, just taking account of the flow of the information, but
ignoring low level details like ports. My model will consist of a
class that has an interface for message passing, and make the
simulation model by instantiate several objects and make its
connections for that message passing. Of course, I want to go further
until its implementation, but this first verification step is needed
in my design, and therefore I propose my own set of classes and
methods.

What I wanted to say is that Christopher's proposal maybe is not
suitable for all cases, and IMHO one of the strengths of MyHDL is that
it doesn't tie you to a particular way to describe your objects at
high level, the only condition is that you provide a list of
generators and signals that link them, but you can use whatever you
want to create them.

The Hardware Module Class can be the base class of a particular set of
IP cores, but it shouldn't be part of core MyHDL. In this case, making
an analogy to software development, you could think this class as a
"library" that "programs" (IP cores) can use.

>
> Software to sea of gates (SoG) isn't a MyHDL thing.  This is an industry
> trend / problem to solve.  If you happen to be the person to correctly
> solve, you probably would have you billions and sitting on a beach some
> where :)  That assumes it is solvable with a generic high-level
> description or translation from existing program languages.
>
> <snip>
> On 5/3/2012 10:03 AM, G. Andrew Stone wrote:
>> The fact of the matter is that Jan seems to have written myHDL to solve
>> issues in complex hardware design and hardware simulation that only experts
>> in the field can understand (either that or they are such totally obvious
>> mistakes in doing a simulation that any software person would think OMG!!
>> so we think that that CAN'T be the real issue:-)  ) and a lot of us are
>> trying to twist the project to: 1. make it really easy to do quick and
>> dirty FPGA hackups 2. learn how to program these "seas of gates".
>
> To get to the quick and dirty FPGA, as Jan D. eluded we probably need a
> large open-source IP collection.  Then someone can tie together a bunch
> of components and implement something.
>
> 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

Best regards
-- 
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] Object type is not supported in this context

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

On 14/05/12 12:28, Christopher Felton wrote:
> I do not know for certain but my guess is the previous block as well.
> But it is hard to line up the line number with the code pasted.  In
> general (AFAIK) the error messages and lines numbers depend heavily on
> the Python ast package.  The conversion code doesn't try and re-parse
> but uses the information provided by the ast package.

Yes, the error line was always the one before a new code block 
started, i.e. when the parser/ast knew it had to complete clean-up 
of the previous block.

> I think your issue with using the enum() is in combination with the
> always_comb decorator.  The enums don't seem to work in an always_comb?

Agreed, the error changed/disappeared when I temporarily tested 
with a clocked process.

>    I didn't realize this limitation existed.  The following is the simple
> example I used (one of your previous questions) to see if this was true
> or not.

Thanks for checking.  I'm so good at writing dodgy code that it 
could easily have been just me.  Hopefully this will get better, 
and I will also be able to provide some insight into what is happening.

> In your example you do not need to write you state-machines with the
> separate "next state" and "state" blocks.  If you convert your
> state-machines to a single always(clock.posedge) you should be able to
> avoid the issue you are seeing with the enums.

Yes, this is true for the sample code, but in the processor design 
I need the next state decode to drive some register transfers. I'll 
continue to use plain constants to describe the states, but it is 
much easier to trace in gtkwave with the states named.

>> I did start looking at the MyHDL source,  ...

To debug conversion, I turned off simulation, then selectively 
edited the top level return line to find the non-convertible code. 
  After that, selectively editing the block(s) that failed to 
convert isolated the problem.  This may be obvious to others, but 
it took me a while to figure out the method.

> Sandbox examples are usually easier to work with.  If you think the
> error is XYZ then create a small generic example to try and expose the
> issue and then present to the group.  Large code examples can be hard to
> dissect quickly.

With the processor, the three pages of code seemed to me to be 
about the minimum convenient size for initial testing.  There is 
another monolithic block to add soon, so I'll try to find ways of 
testing this thoroughly before next big integration.

Jan Coombs
-- 

Re: [myhdl-list] MEP : Signal Containers

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

On 11/14/2011 10:32 PM, Christopher Felton wrote:
> The following is a *start* to a MEP that describes the conversion
> support for classes, lists, and dictionaries.  This is just a start of
> the enhancement description and does not include some of the mechanical
> (code changes) items worth identifying in a MEP.
>
<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.

Regards,
Chris

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 5/13/2012 9:50 PM, Tom Dillon wrote:
> On 05/11/2012 06:00 PM, Jan Decaluwe wrote:
>> For a new release I would like to make some progress on Chris Felton's
>> work with what he calls Signal containers, but I still have to start
>> studying the concrete proposals. Jan
>
> I too have some interest in Signal containers. I have been a little of
> the flow here so how are we supposed to discuss new features? On the
> mailing list or edit the MEP? I would prefer the mailing list to bounce
> around ideas.
>

I think hashing it out in the mailing list is most effective.  I will 
respond to my previous proposal thread, we can use that thread to 
comment on the signal containers.

Regards,
Chris

Re: [myhdl-list] Object type is not supported in this context

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

On 5/12/2012 8:03 AM, Jan Coombs wrote:
> This error message points to a blank line, which is always
> immediately before the start of a code block:
>
> myhdl.ConversionError: File
> /home/jan/work/projects/MyHDL/SDP_3o4/work/sdp3o4.py, line 123:
> Object type is not supported in this context: ExST
>
> Does it refer to the next or previous block of code?

I do not know for certain but my guess is the previous block as well. 
But it is hard to line up the line number with the code pasted.  In 
general (AFAIK) the error messages and lines numbers depend heavily on 
the Python ast package.  The conversion code doesn't try and re-parse 
but uses the information provided by the ast package.

>
> I assumed that it would be the previous block of code, and
> commented out all lines referring to the state constants, but the
> error remains the same, even the line number.
>
> ExST = enum('Fetch1','Fetch2','NewAddr','Skip',  \
>                          'Gap','Broken', encoding='one_hot')
>
>
> The next block of code would be difficult without the enum, but
> this seems to be where the problem is:
>
>     @always_comb
>     def execNextStateLogic_AsyncNoVar():

I think your issue with using the enum() is in combination with the 
always_comb decorator.  The enums don't seem to work in an always_comb? 
  I didn't realize this limitation existed.  The following is the simple 
example I used (one of your previous questions) to see if this was true 
or not.

     from myhdl import *

     def case_ex1(clk, key, led):
         tKey = enum('UP', 'DOWN', 'LEFT', 'RIGHT')
         @always(clk.posedge)
         def hdl():
             if   key==tKey.UP:    led.next = 0xDE
             elif key==tKey.DOWN:  led.next = 0xCA
             elif key==tKey.LEFT:  led.next = 0xFB
             elif key==tKey.RIGHT: led.next = 0xAD
             else:                 led.next = 0x00

         return hdl

     def case_ex2(key, led):
         tKey = enum('UP', 'DOWN', 'LEFT', 'RIGHT')
         @always_comb
         def hdl():
             if   key==tKey.UP:    led.next = 0xDE
             elif key==tKey.DOWN:  led.next = 0xCA
             elif key==tKey.LEFT:  led.next = 0xFB
             elif key==tKey.RIGHT: led.next = 0xAD
             else:                 led.next = 0x00

         return hdl

In the above, the second does not convert correctly and fails the 
freevar check in the _analyzeGens, determines the enum is an unsupported 
type.

In your example you do not need to write you state-machines with the 
separate "next state" and "state" blocks.  If you convert your 
state-machines to a single always(clock.posedge) you should be able to 
avoid the issue you are seeing with the enums.

<snip>
>     File
> "/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py",
> line 743, in visit_Call
>       self.write(f.__name__)
>     File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_Signal.py",
> line 479, in __getattr__
>       return getattr(self._val, attr)
> AttributeError: 'intbv' object has no attribute '__name__'
> jan@T60:~/work/projects/MyHDL/SDP_3o4/work$
>
>
> I did start looking at the MyHDL source, but suspect that this
> would be a very long route to a solution.  My code is only three
> pages, should I try to convert smaller pieces?  Or can anyone else
> suggest the type of problems/typos I should look for?

Sandbox examples are usually easier to work with.  If you think the 
error is XYZ then create a small generic example to try and expose the 
issue and then present to the group.  Large code examples can be hard to 
dissect quickly.

Regards,
Chris

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 05/11/2012 06:00 PM, Jan Decaluwe wrote:
> For a new release I would like to make some progress on Chris Felton's 
> work with what he calls Signal containers, but I still have to start 
> studying the concrete proposals. Jan 

I too have some interest in Signal containers. I have been a little of 
the flow here so how are we supposed to discuss new features? On the 
mailing list or edit the MEP? I would prefer the mailing list to bounce 
around ideas.

Re: [myhdl-list] Object type is not supported in this context

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

On 12/05/12 14:03, Jan Coombs wrote:
> This error message points to a blank line, which is always
> immediately before the start of a code block:

The complex error messages were caused by confusion about intbv 
indexing, using:
     memRdNetSlice.next = memRdSlice(NSW,0)
instead of:
     memRdNetSlice.next = memRdSlice[NSW:0]


As the code now converts to Verilog, although not VHDL, I tried to 
restore the enum code, just in case, but this still fails, likely 
in the block shown below:

> ExST = enum('Fetch1','Fetch2','NewAddr','Skip',  \
>                          'Gap','Broken', encoding='one_hot')
>
>
> The next block of code would be difficult without the enum, but
> this seems to be where the problem is:
>
>     @always_comb
>     def execNextStateLogic_AsyncNoVar():
>       ''' determine what next execution state will be '''
>       ''' line 159: Object type is not supported in this context:
> ExST '''
>       if reset:   execNextState.next = ExST.Skip
>       else:
>         if (execState==ExST.Fetch1):
>           if (memRdSlice==ToMem)|    \
>              (memRdSlice==Alu2op)|   \
>              (memRdSlice==Alu1op)|   \
>              (memRdSlice==FromMem):  \
>                   execNextState.next = ExST.Fetch2
>           elif (memRdSlice==Branch):   \
>                   execNextState.next = ExST.NewAddr
>           elif (memRdSlice==Skip)|  \
>                (memRdSlice==Lit)|   \
>                (memRdSlice==Call):  \
>                   execNextState.next = ExST.Skip
>           else:   execNextState.next = ExST.Gap
>         elif execState==ExST.Fetch2:  \
>                   execNextState.next = ExST.Gap
>         elif execState==ExST.NewAddr:
>           if (memRdMore==0):  \
>                   execNextState.next = ExST.Gap
>           else:   execNextState.next = ExST.NewAddr
>         elif execState==ExST.Skip:
>           if (memRdMore==0):  \
>                   execNextState.next = ExST.Gap
>         elif execState==ExST.Gap:  \
>                   execNextState.next = ExST.Fetch1
>         elif execState==ExST.Broken:  \
>                   execNextState.next = ExST.Broken
>         else:     execNextState.next = ExST.Broken
>
>
> Now I have converted the code using enum to use constants, and
> don't get the improper use of ExST error.

Now I can get on, wrap my code in a test harness, and try it with 
the on-chip RAM block.

Jan Coombs.

[myhdl-list] Object type is not supported in this context

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

This error message points to a blank line, which is always 
immediately before the start of a code block:

myhdl.ConversionError: File 
/home/jan/work/projects/MyHDL/SDP_3o4/work/sdp3o4.py, line 123: 
Object type is not supported in this context: ExST

Does it refer to the next or previous block of code?

I assumed that it would be the previous block of code, and 
commented out all lines referring to the state constants, but the 
error remains the same, even the line number.

ExST = enum('Fetch1','Fetch2','NewAddr','Skip',  \
                        'Gap','Broken', encoding='one_hot')


The next block of code would be difficult without the enum, but 
this seems to be where the problem is:

   @always_comb
   def execNextStateLogic_AsyncNoVar():
     ''' determine what next execution state will be '''
     ''' line 159: Object type is not supported in this context: 
ExST '''
     if reset:   execNextState.next = ExST.Skip
     else:
       if (execState==ExST.Fetch1):
         if (memRdSlice==ToMem)|    \
            (memRdSlice==Alu2op)|   \
            (memRdSlice==Alu1op)|   \
            (memRdSlice==FromMem):  \
                 execNextState.next = ExST.Fetch2
         elif (memRdSlice==Branch):   \
                 execNextState.next = ExST.NewAddr
         elif (memRdSlice==Skip)|  \
              (memRdSlice==Lit)|   \
              (memRdSlice==Call):  \
                 execNextState.next = ExST.Skip
         else:   execNextState.next = ExST.Gap
       elif execState==ExST.Fetch2:  \
                 execNextState.next = ExST.Gap
       elif execState==ExST.NewAddr:
         if (memRdMore==0):  \
                 execNextState.next = ExST.Gap
         else:   execNextState.next = ExST.NewAddr
       elif execState==ExST.Skip:
         if (memRdMore==0):  \
                 execNextState.next = ExST.Gap
       elif execState==ExST.Gap:  \
                 execNextState.next = ExST.Fetch1
       elif execState==ExST.Broken:  \
                 execNextState.next = ExST.Broken
       else:     execNextState.next = ExST.Broken


Now I have converted the code using enum to use constants, and 
don't get the improper use of ExST error.  The simulation still 
looks ok, but I now get this:

jan@T60:~/work/projects/MyHDL/SDP_3o4/work$ ./testSdp3o4.py
<class 'myhdl._SuspendSimulation'>: Simulated 350 timesteps
Traceback (most recent call last):
   File "./testSdp3o4.py", line 46, in <module>
     toVerilog(sdp3o4, clk,reset, addr, doSim)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 151, in __call__
     _convertGens(genlist, vfile)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 374, in _convertGens
     v.visit(tree)
   File "/usr/lib/python2.7/ast.py", line 241, in visit
     return visitor(node)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 964, in visit_Module
     self.visit(stmt)
   File "/usr/lib/python2.7/ast.py", line 241, in visit
     return visitor(node)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 1285, in visit_FunctionDef
     self.visit_stmt(node.body)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 1141, in visit_stmt
     self.visit(stmt)
   File "/usr/lib/python2.7/ast.py", line 241, in visit
     return visitor(node)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 667, in visit_Assign
     self.visit(node.value)
   File "/usr/lib/python2.7/ast.py", line 241, in visit
     return visitor(node)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/conversion/_toVerilog.py", 
line 743, in visit_Call
     self.write(f.__name__)
   File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_Signal.py", 
line 479, in __getattr__
     return getattr(self._val, attr)
AttributeError: 'intbv' object has no attribute '__name__'
jan@T60:~/work/projects/MyHDL/SDP_3o4/work$


I did start looking at the MyHDL source, but suspect that this 
would be a very long route to a solution.  My code is only three 
pages, should I try to convert smaller pieces?  Or can anyone else 
suggest the type of problems/typos I should look for?

Jan Coombs
-- 

Re: [myhdl-list] Developing PLI module for cosimulation with VCS

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

On 05/11/2012 03:40 PM, Tom Dillon wrote:
>
>> I concur, the cver version is more standard (?) should work with most
>> Verilog simulators out of the box.  If you get the latest development
>> code, 0.8dev, there is a modelsim directory in the cosim as well.
>> Modelsim had a memory leak some tweaks had to be made and a separate dir
>> was made.
>
> Off topic, but I have been wondering about this. I am using the 0.7
> release. Should I be using the 0.8dev?
>
> What is new? Do you have to check it out of the repos to use it?

In general, I try to make sure that all unit tests work before a
development changeset is committed. So your existing code should
normally work fine. Of course, new features may be incomplete or
not yet work reliably.

0.8 development has stalled somewhat due to circumstances. (When I
became active again recently, I intended to "warm up" by first
solving some "easy" issues on the newsgroup - a serious misjudgment ;-)).
It has modular bit vector types, which I think are a great
addition:

http://www.myhdl.org/doku.php/meps:mep-106

Some restrictions are not yet checked in the convertor.

For a new release I would like to make some progress on Chris Felton's
work with what he calls Signal containers, but I still have to
start studying the concrete proposals.

Jan

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