myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Restrictions for conversion

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

On 5/21/2012 11:58 AM, Jan Decaluwe wrote:
> On 05/21/2012 02:06 PM, Christopher Felton wrote:
>
>> As I write this, I think the rules should be :
>>
>>       1. intbv can have a type None but not the other
>>          Python built-in types: bool, int, long, etc.
>>          (I realize only bool is convertible).
>
> Can you tell me in one sentence why intbv would need this,
> unlike the other types?

To control initial value support, because intbv can be used to model 
memories and the initialization of large internal memories might be 
inefficient and/or unwanted.

This is all in the context of initial value support and extended to 
pre-init RAM (which is possible in an FPGA).

>
> It used to be a like that, and then I kicked it out because
> of too many issues with operators, and lack of a use case.
>
> None is used in TristateSignal to represent high-impedance.
> I don't see another useful use case.
>

What we have been discussing is the API to disable initial value support 
if it was added.  Would it be via additional arguments, special value 
(i.e. None), or a separate type (NoInitSignal?)?

Regards,
Chris

Re: [myhdl-list] Restrictions for conversion

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

On 05/21/2012 02:06 PM, Christopher Felton wrote:

> As I write this, I think the rules should be :
>
>      1. intbv can have a type None but not the other
>         Python built-in types: bool, int, long, etc.
>         (I realize only bool is convertible).

Can you tell me in one sentence why intbv would need this,
unlike the other types?

It used to be a like that, and then I kicked it out because
of too many issues with operators, and lack of a use case.

None is used in TristateSignal to represent high-impedance.
I don't see another useful use case.

-- 
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] Restrictions for conversion

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

On 05/21/2012 01:28 PM, Norbo wrote:

> then i realized that it probably would just be better to make the Signal
> as a base class and derive every other type from it, wheter it is (intbv,
> bool"x" or modbv, enum, etc.). This probably doesnt made sense once when
> only the intbv existed?
> or is it done the way it is done because of performance reason?

I'm just jumping in on this thread, but if that is the conclusion
there is something fundamentally wrong.

intbv is just a hardware friendly datatype. Signal is the
type we need to do racefree communication. These types should
be complementary - they can be used together (because you
want to be able to do racefree communication with any
datatype) or separate (because the datatype are useful
for plain variables also.)


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] MEP : Signal Containers

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

On 05/19/2012 04:05 PM, Christopher Felton wrote:

> In the current proposal and threads I would have been using /class
> attribute/ to refer to class attributes and instance attributes.  And
> the examples have been instances attributes, so I see why there might be
> confusion, I will update the MEP to clarify.  I guess in future
> conversations I should simply use *attributes* and not specify class or
> instance unless applicable.

Yes, it is best to talk about attribute lookup in general, no need
to specify what type of object the attribute belongs to.

In practice, I suspect the principal use case will be instance
attributes though. If you have several wishbone interfaces, you
want signals with the same attribute name to refer to different
signals :-)

-- 
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] Restrictions for conversion

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

On 5/21/2012 6:28 AM, Norbo wrote:
>> * Adding support for None in the intbv (also setting None as the default
>> value?)
>> * Creating initial values in Verilog/VHDL (when not None)
>> * Changing the verilog continuous assignment to the behavioral statement
>> in the verilog conversion
>> * Work through the implementation changes needed, because of the None in
>> the intbv (boundchecks, etc ..)
>
> I started to try to implement these points.
> the real issues started where i came to the :
> * Work through the implementation changes needed, because of the None in
> the intbv (boundchecks, etc ..
> the issue arises when the intbv has a value of None in the myhdl
> implementation, and something like this is done:
>
> 	sig1=Signal(intbv(None)[8:))
> 	sig2=Signal(intbv(None)[8:))
>
> 	@always(clk.posedge)
> 	def aritmetic():
> 		square.next=sig1*sig1+sig2*sig2

I am not sure of the answer right now but what is the correct course? 
To propagate the "None" or to raise and exception?

>
> i first changed all __add__ and __mult__ operater of the intbv to return
> None as a value if one of the operands
> is None. But as the two multiplications are done first the last plus
> operation has two None values (None+None) which
> doesnt works. So i returned for every operation a new intbv(None). Anyway
> there seem to be some operators where intbv() are
> returned and other operaters there is just the value returned (in the
> orginal code ->  has this any special reson?).

This has been discussed briefly in the past.  IIRC it is for 
performance?  I might be plausible to to return intbv type for all 
operations (I have prototyped this in the past, again IIRC it didn't 
break anything).  But I think we would want very good reason to modify 
before doing so.

>
> But there was an other case:
>
> 	mem=[Signal(intbv(0)[8:]) for i in range(200)]
> 	
> 	@always(clk.posedge)
> 	def mem_read():
> 		our.next=mem[addr]
>
> if here the addr._val is None then it also crashes.
> So my short just to try workaround was to subclass list and accept the
> None as a index
>
>     class listx(list):
>         def __getitem__(self, key):
>             if key==None:
>                bits=super(listx, self).__getitem__(0)._nrbits
>                return intbv(None)[bits:]
>             return super(listx, self).__getitem__(key)
>
> then the implementation would have to look like this:
>
> 	mem=listx([Signal(intbv(0)[8:]) for i in range(200)])
> 	
> 	@always(clk.posedge)
> 	def mem_read():
> 		our.next=mem[addr]
>
> then the issue with the bool arised because if you write code like this:
>
> 	sig=Signal(bool(None))
>
> because bool(None) evaluates to false the _val of the Signal gets false an
> not None
> So i tried with a bool definition like the following:
>

I think that might be an ok behavior.  I know it doesn't match the other 
non-initialized but the bool not having a non-initialize is probably 
acceptable.

> def boolx(val=None):
>       if val in (0, 1):
>           return bool(val)
>       else:
>           return None
>
> Then i changed all Signal operators (__add__, __sub__, etc..) that they
> return None if one of the operaters is None
> which brings the same problem with the plus to the signal as i had in the
> intbv() which is that two None values can't be added or multiplyed or etc.
> like in the intbv.
>
> then i realized that it probably would just be better to make the Signal
> as a base class and derive every other type from it, wheter it is (intbv,
> bool"x" or modbv, enum, etc.). This probably doesnt made sense once when
> only the intbv existed?
> or is it done the way it is done because of performance reason?
>

Hmmm, I am not sure about that.  In some cases, mainly modeling, I want 
to use intbv directly and do not want it to be a Signal.  Example, I 
don't want to have to call the "update" explicitly or implicitly to have 
the get the value.


As I write this, I think the rules should be :

    1. intbv can have a type None but not the other
       Python built-in types: bool, int, long, etc.
       (I realize only bool is convertible).

    2. If an intbv with a value of None is used an
       exception should be raised.

The main use of the "None" was to control if initial values were written 
to the lower (v)HDLs.  Which I think is fair.  But MyHDL currently does 
not have this concept in conversion or modeling.  That is, you can't 
have an unknown value.  I think we preserve this by raising an 
exception.  The rules is changed slightly, currently you cannot have a 
type with an unknown value and proposed you can't use a type with an 
unknown (a.k.a None).

And there is the limitation that the Python built-in types will always 
be initialized.  Only the intbv can not be initialized.  I believe the 
only arguable reason for not initializing so far is for large arrays 
(memories).  Or did I quickly forget?

Regards,
Chris

Re: [myhdl-list] Restrictions for conversion

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

> * Adding support for None in the intbv (also setting None as the default  
> value?)
> * Creating initial values in Verilog/VHDL (when not None)
> * Changing the verilog continuous assignment to the behavioral statement  
> in the verilog conversion
> * Work through the implementation changes needed, because of the None in  
> the intbv (boundchecks, etc ..)

I started to try to implement these points.
the real issues started where i came to the :
* Work through the implementation changes needed, because of the None in  
the intbv (boundchecks, etc ..
the issue arises when the intbv has a value of None in the myhdl  
implementation, and something like this is done:

	sig1=Signal(intbv(None)[8:))
	sig2=Signal(intbv(None)[8:))

	@always(clk.posedge)
	def aritmetic():
		square.next=sig1*sig1+sig2*sig2

i first changed all __add__ and __mult__ operater of the intbv to return  
None as a value if one of the operands
is None. But as the two multiplications are done first the last plus  
operation has two None values (None+None) which
doesnt works. So i returned for every operation a new intbv(None). Anyway  
there seem to be some operators where intbv() are
returned and other operaters there is just the value returned (in the  
orginal code -> has this any special reson?).

But there was an other case:

	mem=[Signal(intbv(0)[8:]) for i in range(200)]
	
	@always(clk.posedge)
	def mem_read():
		our.next=mem[addr]

if here the addr._val is None then it also crashes.
So my short just to try workaround was to subclass list and accept the  
None as a index

   class listx(list):
       def __getitem__(self, key):
           if key==None:
              bits=super(listx, self).__getitem__(0)._nrbits
              return intbv(None)[bits:]
           return super(listx, self).__getitem__(key)

then the implementation would have to look like this:

	mem=listx([Signal(intbv(0)[8:]) for i in range(200)])
	
	@always(clk.posedge)
	def mem_read():
		our.next=mem[addr]

then the issue with the bool arised because if you write code like this:

	sig=Signal(bool(None))

because bool(None) evaluates to false the _val of the Signal gets false an  
not None
So i tried with a bool definition like the following:

def boolx(val=None):
     if val in (0, 1):
         return bool(val)
     else:
         return None

Then i changed all Signal operators (__add__, __sub__, etc..) that they  
return None if one of the operaters is None
which brings the same problem with the plus to the signal as i had in the   
intbv() which is that two None values can't be added or multiplyed or etc.  
like in the intbv.

then i realized that it probably would just be better to make the Signal  
as a base class and derive every other type from it, wheter it is (intbv,  
bool"x" or modbv, enum, etc.). This probably doesnt made sense once when  
only the intbv existed?
or is it done the way it is done because of performance reason?



greetings
Norbo

Re: [myhdl-list] MEP : Signal Containers

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

<snip>
>> The promise of MyHDL is in debugging, what you call verification, but it
>> does not provide me with a tree of hardware modules that I need to
>> iterate over in order to write my required debugging harnesses.
>>
>> Anyhow there is no one critical point.  There are work arounds to each
>> piece.  It is just that the big picture would be so much simpler for
>> newbies to get, and so much simpler to build complex systems on top of.
>>
>> While this is a signal mep,  this point is not about a better signal, it
>> is about a better overall system.   Jan is asking show me the critical
>> feature.  I am responding we need a different elephant.
>
> It is clear that you still don't understand what beast we currently have,
> so I don't think you are in pole position to specify a different one.
>
> The problem is that I see zero progress, despite all the energy invested.
> I think the issue is that your learning methodology is broken. You keep
> on posting, but it seems you don't listen to the good advice you get from
> the experts here: start with learning the basics of digital design,
> including synthesis, use the manual as a close reference, use the cookbook
> examples to go through the process yourself in small steps. Actually your
> own suggestion to start simple with Verilog may be a good one, but now it
> seems you're even ignoring your own good advice.
>
> I hope that you understand how irritating it is to hear about visions
> and world views all the time, and even get programming lessons, from
> someone in that position.
>

I would like to add some emphasis.  I hope he does understand how 
*irritating* it is!  Not the fact of asking a questions.  This community 
has been very receptive to questions and helping newcomers.  But the 
barge of this vision and the inability, in any shape or form, to really 
understand what his own vision is.

As stated, the most frustrating appears to be his unwillingness to put 
the effort forward to grow in this area.  I also hope he realizes how 
much effort is being spent on his behalf.  Patient and eloquent 
explanations has been provided which has not been digested.

Regards,
Chris

Re: [myhdl-list] MEP : Signal Containers

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

On 05/19/2012 02:42 PM, Christopher Lozinski wrote:
> On 5/19/12 4:02 AM, Jan Decaluwe wrote:
>> There should be some feature
>> that many people find useful and that cannot reasonably done in
>> a different way. Conversion is complex enough as it is!

> I think if you only did classes, conversion would be so much easier.

I don't see why.

> Right now you have to mess with the AST tree.

That's the Migen rationale, isn't it?

Well, everyone can see where that leads to: ridiculous restrictions
and awkward syntax. In short, HDL design for amateurs.

No thanks, I settle for the AST. I need python's expressiveness
and syntax to describe hardware behavior.

>  If everything were a
> class, it would be easier to query them for signals public and private.

Signal handling is currently a minor task in conversion.

> You would only have to touch the AST tree for the code that is inside a
> python method, not for its arguments.

That's how it works currently, except at the top level. Elaboration
takes care of the other arguments.

> You could have two representations of signals, the short list, and the
> expanded list.  Two methods, one for short list, one for expanded list.
> Then just convert the expanded list.   That would give you hierarchical
> signals much more easily.  Verilog would just see a longer list of signals.

As I said, a minor task.

> And if everything were a class, they could all multiply inherit from a
> graphics drag and drop class, and you would get a great GUI.

That is called schematics entry, an intelligent form of it at best.
Not for me, thanks.

> But those are all details.  There are work arounds to each item.  The
> real issue is at a much higher level.
>
> But the real feature would be in making MyHDL understandable to newbies,
> and in doing so growing the community.
>
> An even big feature is that it would give the MyHDL users a different
> mental model of MyHDL.   I want to do some very very complex things, not
> very performance intensive things, but to even be able to think at this
> level of abstraction, to reduce the complexity of what I am doing,  I
> need a simpler mental model of what I am building on top of.    OOHDL
> hardware classes give me that simple conceptual model to build on top of.
>
> Ignoring licensing issues, If Jan C's microprocessor were a bunch of
> OOHDL hardware modules, it would be so easy to grab and use them.  Right
> now I would have to edit them to fit my world view.   They do not
> provide the right debugging functionality.

I have zero interest to compare the benefits of some virtual super
system with MyHDL, a proven system that works today.

I you think you are on to something, it is your job to show it. With
code and a manual I mean, not with vague visions and world views.

> Looking at waveforms is just not the right way to be debugging this
> stuff.

Agreed.

>  For example I might want to  keep the history of each signal,
> then print out a tree of  hardware modules and their signal values to
> figure out what is going wrong.

But that is exactly what a waveform viewer (and the associated
input file) does!

> The current approach, A function
> returning a list, first calls the top level function, then returns me me
> a list of modules, not a tree of modules.  Not what I need to debug this
> thing.

Wrong, it is a tree, represented as a nested list.

http://www.myhdl.org/doc/current/manual/intro.html#parameters-and-hierarchy

> The promise of MyHDL is in debugging, what you call verification, but it
> does not provide me with a tree of hardware modules that I need to
> iterate over in order to write my required debugging harnesses.
>
> Anyhow there is no one critical point.  There are work arounds to each
> piece.  It is just that the big picture would be so much simpler for
> newbies to get, and so much simpler to build complex systems on top of.
>
> While this is a signal mep,  this point is not about a better signal, it
> is about a better overall system.   Jan is asking show me the critical
> feature.  I am responding we need a different elephant.

It is clear that you still don't understand what beast we currently have,
so I don't think you are in pole position to specify a different one.

The problem is that I see zero progress, despite all the energy invested.
I think the issue is that your learning methodology is broken. You keep
on posting, but it seems you don't listen to the good advice you get from
the experts here: start with learning the basics of digital design,
including synthesis, use the manual as a close reference, use the cookbook
examples to go through the process yourself in small steps. Actually your
own suggestion to start simple with Verilog may be a good one, but now it
seems you're even ignoring your own good advice.

I hope that you understand how irritating it is to hear about visions
and world views all the time, and even get programming lessons, from
someone in that position.

> But those are just my thoughts.  My vision.   I could be wrong.  Thank
> you for helping me to clear these issues up in my mind.

Visions are for those who know where they are. The others
should not lose time with them, and work hard to get there.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] MEP : Signal Containers

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

On 05/20/2012 04:43 PM, Tom Dillon wrote:

>> Best of my knowledge this is only an issue when the top-level is a class
>> method.  It appears class methods can be buried in the hierarchy but not
>> the top-level.  Which I think it self is a valid reason to add the
>> feature, for completeness.
>
> It is only a top level issue. Works fine at lower levels.

Logical perhaps, but I didn't realize this because never tried it myself.
This stuff is more powerful than I thought :-)

> I guess I give some credit to the completeness argument when I think of
> it that way. This is really the same argument for the signal containers
> as it just makes a consistent use for top level vs lower levels.

Let's go for it then, changeset welcome.


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] MEP : Signal Containers

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

On 05/19/2012 04:05 PM, Christopher Felton wrote:
> On 5/19/12 4:02 AM, Jan Decaluwe wrote:
>> On 05/18/2012 09:57 PM, Christopher Felton wrote:
>>
>>> 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.
>>
>> I think there has to be a much better reason than this to warrant
>> the effort to support this in conversion. There should be some feature
>> that many people find useful and that cannot reasonably done in
>> a different way. Conversion is complex enough as it is!
>
> Oh oh, I setup this enhancement up poorly here, doh.  In the context of
> describing hardware behavior using a class method (as proposed) or a
> python function, they will do the same thing.  So what is the benefit to
> justify the changes in the conversion code?
>
> My opinion, the benefit is that it helps organize larger more complex
> designs (yes, complex can be subjective, what is complex?).  To me this
> benefit is worth the inclusion.  In the past couple years this topic has
> surfaced a couple times.  Others do intuitively want to use a class
> method instead of a function in some cases.
>
> The changes can be diffed here (viewed),
> https://bitbucket.org/cfelton/myhdl_0.8dev_work/changeset/d61bf91023b7 .
>
> The changes are localized in two spots.  The enhancement doesn't touch a
> lot of the conversion code.  Hopefully, minimizing additional complexity
> in the conversion code.
>
> Is the concern that it will add unneeded complexity to the conversion
> code or be confusing for users?

The latter is an often overlooked, but important concern.
If something is supported it should be "all the way", otherwise it may
just raise new expectations and increase confusion.

However, it looks like this case is indeed simple and clean.

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

On 05/19/2012 09:05 AM, Christopher Felton wrote:
> On 5/19/12 4:02 AM, Jan Decaluwe wrote:
>> On 05/18/2012 09:57 PM, Christopher Felton wrote:
>>
>>> 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.
>> I think there has to be a much better reason than this to warrant
>> the effort to support this in conversion. There should be some feature
>> that many people find useful and that cannot reasonably done in
>> a different way. Conversion is complex enough as it is!
> Oh oh, I setup this enhancement up poorly here, doh.  In the context of
> describing hardware behavior using a class method (as proposed) or a
> python function, they will do the same thing.  So what is the benefit to
> justify the changes in the conversion code?
>
> My opinion, the benefit is that it helps organize larger more complex
> designs (yes, complex can be subjective, what is complex?).  To me this
> benefit is worth the inclusion.  In the past couple years this topic has
> surfaced a couple times.  Others do intuitively want to use a class
> method instead of a function in some cases.
>
> The changes can be diffed here (viewed),
> https://bitbucket.org/cfelton/myhdl_0.8dev_work/changeset/d61bf91023b7 .
>
> The changes are localized in two spots.  The enhancement doesn't touch a
> lot of the conversion code.  Hopefully, minimizing additional complexity
> in the conversion code.
>
> Is the concern that it will add unneeded complexity to the conversion
> code or be confusing for users?
>
>>> 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.
>> I don't remember - can you provide simple examples? Is the issue only
>> related to the very top level, as I MEP 108  seems to suggest, or also
>> to intermediate hierarchical levels?
> Best of my knowledge this is only an issue when the top-level is a class
> method.  It appears class methods can be buried in the hierarchy but not
> the top-level.  Which I think it self is a valid reason to add the
> feature, for completeness.

It is only a top level issue. Works fine at lower levels.

I guess I give some credit to the completeness argument when I think of 
it that way. This is really the same argument for the signal containers 
as it just makes a consistent use for top level vs lower levels.

Sorry about combining two topics again, but I guess in this sense they 
are related.

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

[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 4:02 AM, Jan Decaluwe wrote:
> On 05/18/2012 09:57 PM, Christopher Felton wrote:
>
>> 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.
>
> I think there has to be a much better reason than this to warrant
> the effort to support this in conversion. There should be some feature
> that many people find useful and that cannot reasonably done in
> a different way. Conversion is complex enough as it is!

Oh oh, I setup this enhancement up poorly here, doh.  In the context of 
describing hardware behavior using a class method (as proposed) or a 
python function, they will do the same thing.  So what is the benefit to 
justify the changes in the conversion code?

My opinion, the benefit is that it helps organize larger more complex 
designs (yes, complex can be subjective, what is complex?).  To me this 
benefit is worth the inclusion.  In the past couple years this topic has 
surfaced a couple times.  Others do intuitively want to use a class 
method instead of a function in some cases.

The changes can be diffed here (viewed), 
https://bitbucket.org/cfelton/myhdl_0.8dev_work/changeset/d61bf91023b7 .

The changes are localized in two spots.  The enhancement doesn't touch a 
lot of the conversion code.  Hopefully, minimizing additional complexity 
in the conversion code.

Is the concern that it will add unneeded complexity to the conversion 
code or be confusing for users?

>
>> 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.
>
> I don't remember - can you provide simple examples? Is the issue only
> related to the very top level, as I MEP 108  seems to suggest, or also
> to intermediate hierarchical levels?

Best of my knowledge this is only an issue when the top-level is a class 
method.  It appears class methods can be buried in the hierarchy but not 
the top-level.  Which I think it self is a valid reason to add the 
feature, for completeness.

As for an example ... simple example.  I assume you mean an example that 
would demonstrate the benefits of using a class method?  I have 
struggled with this.  An example that can be easily digested is usually 
an example that is best suited for a non-class method implementation. 
But an example where a class method might be used is usually too 
complicated to be of benefit in conversation.  The example I will try to 
provide will be missing all the "interesting" stuff.

If I wanted to create a CRC module.  I might want to use a class to 
abstract the different functions and HDL that might be used with the CRC 
module.

     class CRC(object):
         def __init__(self, GeneratorPoly=[], BusWidth=8):
             ... # bunch of stuff to check/massage
                 # the generator polynomial

         def GetHammingDistance(self):
             ...
             return <hamming distance>

         def CrcHdl(self, <ports>):
             """Generate the hardware"""
	    return <list of generators>

In this example, this IP will have various data and methods used to 
create the generator polynomial, other house keeping, and then a method 
that describes the hardware behavior.  Most of the functions are for the 
user of the component and used during elaboration.

If the /CrcHdl/ is the top-level, currently you would need to do the 
following work around.

        def CrcHdl(self, clk, rst, data_in, data_out):
            return CrcFuncHdl(clk, rst, data_in, data_out)

>
>> 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.
> /114/50122263/
>
> I'm confused about terminology. When you talk about class attributes,
> are you sure you don't mean instance attributes instead?
>

That might be correct indeed.  At this point I did not have an 
definition that would differentiate a class attribute vs. an instance 
attribute (reviewing [1] some more ... ).

In the current proposal and threads I would have been using /class 
attribute/ to refer to class attributes and instance attributes.  And 
the examples have been instances attributes, so I see why there might be 
confusion, I will update the MEP to clarify.  I guess in future 
conversations I should simply use *attributes* and not specify class or 
instance unless applicable.


[1] http://docs.python.org/tutorial/classes.html


Regards,
Chris Felton

Re: [myhdl-list] Bernd Paysan's b16 processor in MyHDL

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

On 19/05/12 12:41, Christopher Lozinski wrote:
> It looks like you have made huge process on this device.  Not only in
> MyHDL, but also in forth.   Congratulations on the hard work.
Not mine!  Credits appear in sources.

> I like that you list the components, RAM, CPU, Stack, ALU.  Goes a long
> way to explaining what you have built. Of course code is always painful
> to read through, English high level description is always easier and
> faster to read.  The article on a forth processor in FPGA looks hugely
> interesting.  What is your relationship with the author?
Bernd rides what I dreamed of as a boy.  I just split his code into 
separate files, and expanded the signal names so it would be easier 
for you to read.

> I did not understand the table at the top of [Bernd's] web page.  What are
> the horizontal and vertical axes?
This is the instruction set matrix, but there is a much clearer one 
in the MyHDL source file.

> So let me ask the obvious marketing questions.  How many transistors are
> in this device?  How many in the 8051?  Better yet, how many in each
> component, where did you shrink it the most?   And how many instructions
> per second can each execute.   Which component slows you down the most?
> Obviously this is on a FPGA, the other on silicon, so one needs to scale
> between them.
Bernd has used this [2] in silicon, but, as I have no access to 
silicon I do not know.  Because the instruction set is unusual, you 
would need to test with some real code; give it a try.

> Many many years ago, Marvin Minsky, an AI professor at MIT tried to
> build a slower cpu.  A bit embarrassing.  He does not talk about it very
> much.  But a smaller, more power and space efficient cpu is a great idea.
I recently heard that the wiring in the brain is like layers of 
matting, providing X & Y axis fibers, with Z axis fibers 
penetrating the layers of matting. [1]  Having a large number of 
simpler slower processors is no problem if you have massive 
interconnect, and superb organisational skills.

> So how much better is this device?  Of course the real test are the
> benchmarks.
Yes, you could start with just the hardware description in MyHDL, 
and test a few instructions, then move on to using the cross 
development tools.  Any documentation shortages we could make up 
between us.

It would be good to get interactive code development working using 
the cross-dev tools and the MyHDL model.  Then you could choose 
some simple jobs, and get benchmarking.

Jan Coombs
-- 
[1] http://www.nsf.gov/news/news_images.jsp?cntn_id=123711&org=NSF
[2] http://bernd-paysan.de/b16.html

Re: [myhdl-list] MEP : Signal Containers

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

On 05/19/2012 07:42 AM, Christopher Lozinski wrote:
> On 5/19/12 4:02 AM, Jan Decaluwe wrote:
>> There should be some feature
>> that many people find useful and that cannot reasonably done in
>> a different way. Conversion is complex enough as it is!
> I think if you only did classes, conversion would be so much easier.

I think two discussion got merged here and I believe I did it. I believe 
Jan's comment was concerning conversion of a class method as apposed to 
a function.

The other discussion was about signals in class instances being converted.

Re: [myhdl-list] MEP : Signal Containers

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

On 5/19/12 4:02 AM, Jan Decaluwe wrote:
> There should be some feature
> that many people find useful and that cannot reasonably done in
> a different way. Conversion is complex enough as it is!
I think if you only did classes, conversion would be so much easier.

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

You could have two representations of signals, the short list, and the
expanded list.  Two methods, one for short list, one for expanded list. 
Then just convert the expanded list.   That would give you hierarchical
signals much more easily.  Verilog would just see a longer list of signals.

And if everything were a class, they could all multiply inherit from a
graphics drag and drop class, and you would get a great GUI. 

But those are all details.  There are work arounds to each item.  The
real issue is at a much higher level. 

But the real feature would be in making MyHDL understandable to newbies,
and in doing so growing the community. 

An even big feature is that it would give the MyHDL users a different
mental model of MyHDL.   I want to do some very very complex things, not
very performance intensive things, but to even be able to think at this
level of abstraction, to reduce the complexity of what I am doing,  I
need a simpler mental model of what I am building on top of.    OOHDL
hardware classes give me that simple conceptual model to build on top of.

Ignoring licensing issues, If Jan C's microprocessor were a bunch of
OOHDL hardware modules, it would be so easy to grab and use them.  Right
now I would have to edit them to fit my world view.   They do not
provide the right debugging functionality.

Looking at waveforms is just not the right way to be debugging this
stuff.   For example I might want to  keep the history of each signal,
then print out a tree of  hardware modules and their signal values to
figure out what is going wrong.   The current approach, A function
returning a list, first calls the top level function, then returns me me
a list of modules, not a tree of modules.  Not what I need to debug this
thing.

The promise of MyHDL is in debugging, what you call verification, but it
does not provide me with a tree of hardware modules that I need to
iterate over in order to write my required debugging harnesses. 

Anyhow there is no one critical point.  There are work arounds to each
piece.  It is just that the big picture would be so much simpler for
newbies to get, and so much simpler to build complex systems on top of.

While this is a signal mep,  this point is not about a better signal, it
is about a better overall system.   Jan is asking show me the critical
feature.  I am responding we need a different elephant. 

But those are just my thoughts.  My vision.   I could be wrong.  Thank
you for helping me to clear these issues up in my mind.

-- 
Regards
Christopher Lozinski

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

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

[myhdl-list] Jan Coomb's Processor

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

It looks like you have made huge process on this device.  Not only in
MyHDL, but also in forth.   Congratulations on the hard work. 

I like that you list the components, RAM, CPU, Stack, ALU.  Goes a long
way to explaining what you have built. Of course code is always painful
to read through, English high level description is always easier and
faster to read.  The article on a forth processor in FPGA looks hugely
interesting.  What is your relationship with the author?

I did not understand the table at the top of your web page.  What are
the horizontal and vertical axes?

So let me ask the obvious marketing questions.  How many transistors are
in this device?  How many in the 8051?  Better yet, how many in each
component, where did you shrink it the most?   And how many instructions
per second can each execute.   Which component slows you down the most? 
Obviously this is on a FPGA, the other on silicon, so one needs to scale
between them.

Many many years ago, Marvin Minsky, an AI professor at MIT tried to
build a slower cpu.  A bit embarrassing.  He does not talk about it very
much.  But a smaller, more power and space efficient cpu is a great idea. 

So how much better is this device?  Of course the real test are the
benchmarks.


Regards
Chris







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

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

On 19/05/12 02:13, Christopher Lozinski wrote:
    . . .
> Let us lighten up a little bit.  And embrace all the wonderful ideas
> that this group of people have.  Let us face it, we are not mainstream
> digital circuit designers.  There are some very interesting ideas
> floating around.  I love Dillon's examples of  Hierarchical signals,
> complex numbers.  I love the idea of building a python processor.

Excellent.  I have a delightful little processor, not python, but 
shares some features.  It should be able to support interactive 
code development while running in the MyHDL simulator, but,

I got stuck trying to choose the best way to simulate a comm port 
which would link the development tools to the hardware.  perhaps 
you could fix this?

You could also use this design to develop your ideas about higher 
level hardware description.  There is already one example of module 
reuse in the design.

This project is unusual, it is tiny, you will be able to understand 
the hardware and target code generation from top to bottom, and if 
successful you will have a silicon embeddable processor capable of 
interactive code generation and LED blinking.

The code set is summarised below, Jan Coombs.
-- 

b16_ComponentList_asat2012-05-19

Hardware Source in MyHDL
------------------------
test_b16.py        3.0
   b16_ram.py      11.0   (simple tests)
   b16_cpu.py      16.6
     b16_opcodes    5.2
     b16_alu.py     2.2
     b16_stack2.py  1.7
                   ----
                   39.7 kB

Cross Development Tools in gForth
---------------------------------
b16_jc.fs     10.6  assembler &c
   strings.fs   6.7  string support
   serial.fs    6.4  PC comm port support
   syscalls.fs  1.4  PC hw driver access
               ----
               25.1 kB

Code For Target in b16 'Assembler'
----------------------------------
boot.asm    6.2  signon & blink LED
b16.asm     2.4  instruction set test
sieve.asm   0.5  another test
usb.asm     0.3  incomplete
             ---
             9.4 kB

Original source:
http://bernd-paysan.de/b16.html

Re: [myhdl-list] MEP : Signal Containers

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

On 05/18/2012 09:57 PM, Christopher Felton wrote:

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

I think there has to be a much better reason than this to warrant
the effort to support this in conversion. There should be some feature
that many people find useful and that cannot reasonably done in
a different way. Conversion is complex enough as it is!

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

I don't remember - can you provide simple examples? Is the issue only
related to the very top level, as I MEP 108  seems to suggest, or also
to intermediate hierarchical levels?

> 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.
/114/50122263/

I'm confused about terminology. When you talk about class attributes,
are you sure you don't mean instance attributes instead?

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

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

On 5/18/12 6:57 PM, Jan Coombs wrote:
> On 18/05/12 22:32, Christopher Felton wrote:
>      . . .
>> This whole tangent on async FPGA hasn't been that useful.
>
> No, sorry.  It was intended to be an empathetic illustration to
> show that there is an optimum depth of hardware appreciation for
> effective RTL design.
>
> Jan Coombs.
>

Jan C.

I didn't mean any offensive by this.  I thought the "async" comments 
were a reference to an off-topic conversation about Achronix FPGAs in 
this thread?  But it wasn't, the async FPGA was brought up in a separate 
thread and was more applicable in the other context.  I had simply 
merged these two threads in my mind making them non-coherent, which was 
*not* the case.

I think your description on how flexible MyHDL can be was useful.  My 
comment was out of context, sorry about that.

Regards,
Chris Felton

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

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

>
> I agree, you don't want to comprises the generality of MyHDL

Fat finger that, should have been "compromise".

.chris

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

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

On 5/18/12 8:13 PM, Christopher Lozinski wrote:
> On 5/18/12 6:57 PM, Jan Coombs wrote:
>> On 18/05/12 22:32, Christopher Felton wrote:
>>      . . .
>>> This whole tangent on async FPGA hasn't been that useful.
>> No, sorry.  It was intended to be an empathetic illustration to
>> show that there is an optimum depth of hardware appreciation for
>> effective RTL design.
>>
>> Jan Coombs.
>>
> I loved Jan C's question.   I learned a lot from it.  He is also buiding
> great stuff, if I get it correctly, minimal space adders and other
> components.  That is an important set of ideas to include in this
> group.  He is one of only two or three guys working on cpu's.  And the
> whole idea of getting away from a central clock, to everything running
> at its own speed, I believe can lead to vast speed improvements.   In
> particular it helped me really understand that there can be different
> high level models of the same digital component, based on how it is used.

I might be getting confused here, this was a long thread.  But what was 
the question Jan C. asked?  Maybe you, Christopher L,  can refresh my 
memory for me and remind what the question Jan C. asked was?

Regards,
Chris Felton

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

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

On 5/18/12 6:57 PM, Jan Coombs wrote:
> On 18/05/12 22:32, Christopher Felton wrote:
>     . . .
>> This whole tangent on async FPGA hasn't been that useful.
> No, sorry.  It was intended to be an empathetic illustration to 
> show that there is an optimum depth of hardware appreciation for 
> effective RTL design.
>
> Jan Coombs.
>
I loved Jan C's question.   I learned a lot from it.  He is also buiding
great stuff, if I get it correctly, minimal space adders and other
components.  That is an important set of ideas to include in this
group.  He is one of only two or three guys working on cpu's.  And the
whole idea of getting away from a central clock, to everything running
at its own speed, I believe can lead to vast speed improvements.   In
particular it helped me really understand that there can be different
high level models of the same digital component, based on how it is used. 

Let us lighten up a little bit.  And embrace all the wonderful ideas
that this group of people have.  Let us face it, we are not mainstream
digital circuit designers.  There are some very interesting ideas
floating around.  I love Dillon's examples of  Hierarchical signals,
complex numbers.  I love the idea of building a python processor. 

You are all a very smart bunch of people.  As one person said, we post
ideas to stimulate others thinking.  Hopefully this is not just about
existing MyHDL, but about the dreams of where digital circuit design can
go. I am hugely stimulated by this group.  I have certainly done my
share of stimulating the conversation.    Please keep it up Jan C. . 

Chris L.

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

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

On 18/05/12 22:32, Christopher Felton wrote:
    . . .
> This whole tangent on async FPGA hasn't been that useful.

No, sorry.  It was intended to be an empathetic illustration to 
show that there is an optimum depth of hardware appreciation for 
effective RTL design.

Jan Coombs.