myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] intbv wrap

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

<snip>
>>>
>>> I can try to put together a real patch with tests this evening ...
>>> can't promise it though.
>>
>> I will provide my latest patch tonight, I believe it should be finished,
>> I am still working on the test cases.  If you like you can review my
>> patch and send suggestions.  Jan D. published procedures for creating
>> patches with Mercurial, http://www.myhdl.org/doku.php/dev:patches.
>
> I was not aware of the state of your patch. I thought this was only a
> proof of concept. I'd be delighted to review it in its whole !
>

Here is the latest I have put together.  It has both the wrap and the 
public val property.

Simple test case
-----------------

from myhdl import *
x = intbv(0, min=-8, max=8, wrap=True)
x[:] = x + 1
assert x == 1
x[:] = x + 2
assert x == 3
x[:] = x + 5
assert x == -8
x[:] = x + 1
assert x == -7
x[:] = x - 5
assert x == 4
x[:] = x - 4
assert x == 0
x[:] = x - 1
assert x == -1

Chris

Re: [myhdl-list] Modules interface information

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

On 5/5/11 5:00 AM, Oscar Diaz wrote:
> Hi
>
> In a recent discussion with some colleagues about traditional HDL's
> (more VHDL than Verilog) vs MyHDL we came to a controversial point:
>
> In traditional HDL you have a well-defined interface in the modules:
> i.e. VHDL has entity declarations with generics and ports, each with a
> well-defined type. So, you can easily create an IP core and someone
> can easily see the entity description and hopefully use it correctly.
>
> But, when you use MyHDL, you have the function definition with only a
> list of arguments to pass on. So they wonder, what is each argument? a
> signal or a parameter? in case of a bit vector (intbv), with what
> width? So they said that using a MyHDL core you need to deduce that
> types by looking the implementation. I tried to argue that you can put
> that information on the docstring, but that's an optional feature, not
> enforced by language constructs. However there was one thing that I
> could put in favor: there is an implicit rule that a required argument
> is a signal and an optional argument is a generic (talking in VHDL
> jargon).
>
> Another thing that I came to mind was that there is possible to put
> error-check code before generators, maybe something like:
>
> def adder(a, b, x, width=8):
>      assert_generic(width, int)
>      assert_signal(a, intbv, nrbits=width)
>      assert_signal(b, intbv, nrbits=width)
>      assert_signal(x, intbv, nrbits=width+1)
>
>      @always_comb
>      ....
>
> So, in a way you put type information visible and provide
> error-checking when using cores in top-module code.
>
> What's your opinion?
>
> Best regards
>

Different people have done it different ways, some have specific 
functions to check, built into classes, etc.  I think you are asking if 
there could be a standard published way to address the issue you 
encountered.

I think having some utility functions like this could be useful to those 
use to the other HDLs.  But, I think a more Pythonic terminology should 
be used.  Not assert_generic.

Also, for the above width parameter could be removed.  The adder module 
becomes generic based on the type of signals provided.  Instead of 
enforcing that the inputs and outputs are a certain width, you might 
want to assert they follow some set of rules, for the adder example.

assert len(x) >= max(len(a), len(b)) + 1

That gives the function a little more modularity (more generic).

In my mind this is a better way to develop IP.  Any IP is going to need 
documentation above the "entity" definition.  Defining that your IP can 
except these types (more than a single type) and then the IP enforcing 
these rules is really good.  Example for the adder, no we can except 
different a,b sizes, etc.  Instead of having (in this example) different 
variants of the adder we can have one that is a little more flexible.


Chris

[myhdl-list] Modules interface information

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

Hi

In a recent discussion with some colleagues about traditional HDL's
(more VHDL than Verilog) vs MyHDL we came to a controversial point:

In traditional HDL you have a well-defined interface in the modules:
i.e. VHDL has entity declarations with generics and ports, each with a
well-defined type. So, you can easily create an IP core and someone
can easily see the entity description and hopefully use it correctly.

But, when you use MyHDL, you have the function definition with only a
list of arguments to pass on. So they wonder, what is each argument? a
signal or a parameter? in case of a bit vector (intbv), with what
width? So they said that using a MyHDL core you need to deduce that
types by looking the implementation. I tried to argue that you can put
that information on the docstring, but that's an optional feature, not
enforced by language constructs. However there was one thing that I
could put in favor: there is an implicit rule that a required argument
is a signal and an optional argument is a generic (talking in VHDL
jargon).

Another thing that I came to mind was that there is possible to put
error-check code before generators, maybe something like:

def adder(a, b, x, width=8):
    assert_generic(width, int)
    assert_signal(a, intbv, nrbits=width)
    assert_signal(b, intbv, nrbits=width)
    assert_signal(x, intbv, nrbits=width+1)

    @always_comb
    ....

So, in a way you put type information visible and provide
error-checking when using cores in top-module code.

What's your opinion?

Best regards

-- 
Oscar Díaz
Huella de clave = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

Recomiendo usar OpenDocument Format
para uso e intercambio de documentos

http://www.spreadopendocument.org/

[myhdl-list] Custom stream output for conversion

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

Hi

A long time ago (five months according to the list archive, sorry for
the delay) I ask about a way to get the conversion output to a string
object. So I wrote a patch to add file objects and StringIO support as
output to both converters.

With this patch, you can add an attribute called "fileobject", which
can be any object with the following restrictions:

* Must have a "write()" method like a file object
* Must have a "closed" bool attribute (also like a file object)
* If "fileobject" is a string, the converter create a new cStringIO
  object (and the string contents is lost). 

Ideally you can use an existing file object (and must not be closed),
or a StringIO object.

So you can do something like:

toVHDL.fileobject = StringIO()
toVHDL(myTopGenerator, mysig1, mysig2, reset, clock)
print(toVHDL.fileobject.getvalue())

And the VHDL output will be printed to the console. This works for VHDL
and Verilog converters.

There is another issue that I think could be a problem but I don't have
a smart way to solve it: you *must* provide a fresh object before
calling toVHDL (or toVerilog), otherwise the converter just append the
output code to previous conversions. Maybe doing 

toVHDL.fileobject.truncate(0)

before using it inside the function, but that breaks the initial
assumption to accept any object with only "write" y "closed"
attributes. Any suggestions?

Best wishes

--
Oscar Díaz
Huella de clave = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

Recomiendo usar OpenDocument Format 
para uso e intercambio de documentos 

http://www.spreadopendocument.org/

Re: [myhdl-list] intbv wrap

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

On 5/4/2011 10:13 AM, Ben wrote:
<snip>
>
> I was not aware of the state of your patch. I thought this was only a
> proof of concept. I'd be delighted to review it in its whole !
>
> Regards,
> Benoît

Thanks for the additional input!  And no problem, I posted the first 
rough patch a week or so ago.  I will think about limiting the change to 
_val only.  Because I have already made the changes and would have to 
undo or start over (which isn't a huge deal) I would prefer to clump the 
two changes together.

Since I have made the change, ran the regression tests, and ran new 
tests I would like to add the public val property in this patch, as 
well, if it is not too big an issue.  Just to save a little of my time. 
  In general, I agree, it is nice to keep changes separate and minimal. 
  Try to avoid including too many changes with one patch.

>
> As a side note your "I am still working on the test cases" is not
> really comforting, as the test case should be finished before you type
> the first line of code ;) ... in a perfect world.
>

I know, sigh, I had a small set of test cases first but I want to add 
more exhaustive tests and incorporate it with py.test.  The gen2 test 
framework in the distro.  For some reason, I have a horrible time 
getting py.py (py.test) installed.  I can't get easy_install installed 
to install py.test, doh.

Chris

Re: [myhdl-list] Decorator Question

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

On 5/4/11 12:17 AM, Jan Decaluwe wrote:
> http://www.myhdl.org/doc/current/manual/modeling.html#rtl-modeling

Thank you.  I missed that page.


On 5/4/11 12:55 AM, Ben wrote:
> Let me also point you to another advise from Jan D. to you dating from 
> March 31:
> http://sourceforge.net/mailarchive/message.php?msg_id=27287048
>
> On Thu, Mar 31, 2011 at 11:13, Jan Decaluwe<ja...@ja...>  wrote:
>> To avoid disappointments, it may be wise to start by
>> reading an introductory text to digital electronics
>> and synthesis first. Starting with MyHDL before this
>> is probably not the right approach, because it assumes
>> implicit knowledge, especially about limitations :-)
>> (Until someone writes the book "Introduction to
>> digital design using MyHDL" of course :-))

Thank you for the reminder.  Excellent advice for me personally if my 
focus were to build something.   Of course I never did it.   And more to 
the point that is not what the newbies want to do.  They just want MyHDL 
to be an easy way to do stuff.  So we need to make that easy to happen.  
As I go along and stumble on these problems, I am happy to fix them.  So 
I updated the MyHDL.org website to say:

http://myhdl.org/doku.php/meps:mep-100


    Background

Decorators are just a way to simplify the python code. There are three 
types of Decorators. @always indicates a module which is driven by a 
clock signal or by a reset. @always_comb indicates a module which is 
driven by changes in the inputs. @instance, is just used for convenience 
in test scripts, since test scripts need to participate in the 
simulation framework. Onto the software description of decorators.






-- 
Regards
Christopher Lozinski

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

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] intbv wrap

[Ben <ben...@gm...>]

On Wed, May 4, 2011 at 16:46, Christopher Felton <chr...@gm...> wrote:
> On 5/4/2011 9:30 AM, Ben wrote:
>> On Wed, May 4, 2011 at 10:00, Christopher Felton<chr...@gm...>  wrote:
>>> At this point in time I am going to defer converting the wrap function
>>> as briefly discussed in other threads.  It is beyond my current
>>> capabilities.  But this doesn't change the approach.  It simply means
>>> the wrap can only be used as an attribute of the intbv object, thank you
>>> Tom Dillon for the pointer here.
>>
>> Looks like a good idea. See my comments bellow.
>>
>>>
>>> It also seemed appropriate to add a property for _val, see the following.
>>>
>>>      # val property
>>>      def _get_val(self):
>>>          return self._val
>>>
>>>      def _set_val(self, pval):
>>>
>>>          if self._wrap:
>>>              self._val = self.wrap(pval)
>>
>> do both _wrap and wrap exists ?
>>
>>>          else:
>>>              self._val = pval
>>>
>>>          self._checkBounds()
>>>
>>>      val = property(_get_val, _set_val)
>>
>> I guess you'd better like to call the property _val and put its
>> internal value inside __val. This way you minimize your impact on the
>> rest of the code.
>
> Good point, I think the issue will be if we want val to be published as
> a public or private property?

val is currently private. to access it directly, you have to call
A._val or use one of the wrapper function (+, -, etc ...)

by wrapping the property "_val", every affectation inside the module
would make use of the wrapping functionnality. currently, only the
__setitem__ method.

I think making val available to the outside as a public property
should be the purpose of a separate patch.

>
>>
>>>
>>>
>>> This had been discussed in some older threads.  Are there any objections
>>> against this type of implementation?  The _checkBounds and wrap will be
>>> called only from the _set_val property function.
>>>
>>> Above self._wrap is a data member initialized in the constructor based
>>> on a parameter.
>>>
>>> def __init__(self, val=0, min=None, max=None, wrap=False, _nrbits=0):
>>
>> My understanding is that in the constructor, if wrap is a boolean
>> (isinstance(wrap, boolean)), and equal to True, then do the regular
>> wrapping (modulo max), otherwise if set to False, don't do wrapping
>> (same as now), in a third case, one could give a function to use as
>> parameter like for instance one that throw an overflow exception when
>> it occurs:
>>
>> def mywrapfunc(self, val):
>>      if val>  self._max or val<  self._min:
>>        raise OverflowException()
>>      self._val = val
>>
>> this function would simply be given as parameter to the constructor
>> like intbv(wrap=mywrapfunc).
>
> The normal behavior now is to throw and exception (assert?) if min or
> max are exceeded (non wrap case).  And the wrap function will verify the
> correct type, the intbv max and min need to be the full range for the
> binary word.

Did not remembered that ... Then consider my example as a
representation of the current situation using your new machinery ;)
BTW, a ValueError is raised.

>
> I would be a little worried about a user supplied function because it
> would be difficult to state what is valid.  No additional logic could be
> added only binary word behavior.  I think there are only the two cases,
> wrap case and non-wrap.  In the final HDL nothing actually prevents it
> from wrapping but in simulation/verification this will automatically be
> caught if the min/max should be be exceeded (non-wrap).

Fair enough, this could be the purpose of a following patch.

>
>>
>> I can try to put together a real patch with tests this evening ...
>> can't promise it though.
>
> I will provide my latest patch tonight, I believe it should be finished,
> I am still working on the test cases.  If you like you can review my
> patch and send suggestions.  Jan D. published procedures for creating
> patches with Mercurial, http://www.myhdl.org/doku.php/dev:patches.

I was not aware of the state of your patch. I thought this was only a
proof of concept. I'd be delighted to review it in its whole !

Regards,
Benoît

As a side note your "I am still working on the test cases" is not
really comforting, as the test case should be finished before you type
the first line of code ;) ... in a perfect world.

Re: [myhdl-list] intbv wrap

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

On 5/4/2011 9:30 AM, Ben wrote:
> On Wed, May 4, 2011 at 10:00, Christopher Felton<chr...@gm...>  wrote:
>> At this point in time I am going to defer converting the wrap function
>> as briefly discussed in other threads.  It is beyond my current
>> capabilities.  But this doesn't change the approach.  It simply means
>> the wrap can only be used as an attribute of the intbv object, thank you
>> Tom Dillon for the pointer here.
>
> Looks like a good idea. See my comments bellow.
>
>>
>> It also seemed appropriate to add a property for _val, see the following.
>>
>>      # val property
>>      def _get_val(self):
>>          return self._val
>>
>>      def _set_val(self, pval):
>>
>>          if self._wrap:
>>              self._val = self.wrap(pval)
>
> do both _wrap and wrap exists ?
>
>>          else:
>>              self._val = pval
>>
>>          self._checkBounds()
>>
>>      val = property(_get_val, _set_val)
>
> I guess you'd better like to call the property _val and put its
> internal value inside __val. This way you minimize your impact on the
> rest of the code.

Good point, I think the issue will be if we want val to be published as 
a public or private property?

>
>>
>>
>> This had been discussed in some older threads.  Are there any objections
>> against this type of implementation?  The _checkBounds and wrap will be
>> called only from the _set_val property function.
>>
>> Above self._wrap is a data member initialized in the constructor based
>> on a parameter.
>>
>> def __init__(self, val=0, min=None, max=None, wrap=False, _nrbits=0):
>
> My understanding is that in the constructor, if wrap is a boolean
> (isinstance(wrap, boolean)), and equal to True, then do the regular
> wrapping (modulo max), otherwise if set to False, don't do wrapping
> (same as now), in a third case, one could give a function to use as
> parameter like for instance one that throw an overflow exception when
> it occurs:
>
> def mywrapfunc(self, val):
>      if val>  self._max or val<  self._min:
>        raise OverflowException()
>      self._val = val
>
> this function would simply be given as parameter to the constructor
> like intbv(wrap=mywrapfunc).

The normal behavior now is to throw and exception (assert?) if min or 
max are exceeded (non wrap case).  And the wrap function will verify the 
correct type, the intbv max and min need to be the full range for the 
binary word.

I would be a little worried about a user supplied function because it 
would be difficult to state what is valid.  No additional logic could be 
added only binary word behavior.  I think there are only the two cases, 
wrap case and non-wrap.  In the final HDL nothing actually prevents it 
from wrapping but in simulation/verification this will automatically be 
caught if the min/max should be be exceeded (non-wrap).

>
> I can try to put together a real patch with tests this evening ...
> can't promise it though.

I will provide my latest patch tonight, I believe it should be finished, 
I am still working on the test cases.  If you like you can review my 
patch and send suggestions.  Jan D. published procedures for creating 
patches with Mercurial, http://www.myhdl.org/doku.php/dev:patches.

>
> @Tom: backward compatibility is a must there.
>
> Regards,
> Benoît
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd

Re: [myhdl-list] intbv wrap

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

On 5/4/2011 9:11 AM, Tom Dillon wrote:
>
>
> On 05/04/2011 03:00 AM, Christopher Felton wrote:
>> At this point in time I am going to defer converting the wrap function
>> as briefly discussed in other threads.  It is beyond my current
>> capabilities.  But this doesn't change the approach.  It simply means
>> the wrap can only be used as an attribute of the intbv object, thank you
>> Tom Dillon for the pointer here.
>
> Do you mean we won't have wrap support in conversion? Would it be
> possible to put an error or warning in so you would know the logic won't
> match the MyHDL code?

No, it will be *available* in conversion.  And the Verilog/VHDL will 
match.

In my previous post I mentioned there might be two approaches supported.

   1.  x = Signal(intbv(0, wrap=True)
       x.next[:] = x + 1  # automatically wraps
This method is automatically handled by the conversion, nothing has to 
be done.  But the designer needs to remember which Signal(intbv) have 
been setup to wrap.

   2.  x.next[:] = x.wrap(x + 1).
This approach is more explicit and follows current approach of 
explicitly indicating a wrap (for unsigned).  I think both approaches 
would be nice, but with approach 1 conversion is free and approach 2 
conversion is not free :(

>
> It is beyond my capabilities too, I still conversion is magic.
>
>> It also seemed appropriate to add a property for _val, see the following.
>>
>>        # val property
>>        def _get_val(self):
>>            return self._val
>>
>>        def _set_val(self, pval):
>>
>>            if self._wrap:
>>                self._val = self.wrap(pval)
>>            else:
>>                self._val = pval
>>
>>            self._checkBounds()
>>
>>        val = property(_get_val, _set_val)
>>
>>
>> This had been discussed in some older threads.  Are there any objections
>> against this type of implementation?  The _checkBounds and wrap will be
>> called only from the _set_val property function.
>
> Will intbv work as it does now? I am a little rusty on properties.

Yes, this does not change the functionality only the implementation.  A 
property is syntax sugar, when you have a data member _val you can 
assign getter and setter functions using the property.  Instead of using 
this._val = x, this.val = x is used and will call _set_val(x).

This way the wrap checking and bound checking which would be included 
with each _val assignment can be confined to one spot.  Hopefully 
minimize human errors without too much overhead.

This was discussed previously, that a property be added as an 
alternative to assign values to intbv

x = intbv(0, min=-8, max=8)
x[:]  = 4
x.val = 4

Both accomplish the same thing.  This was mentioned as a *possible* 
addition in the past.  I forget if there were any reasons not to do this.

Chris

Re: [myhdl-list] intbv wrap

[Ben <ben...@gm...>]

On Wed, May 4, 2011 at 10:00, Christopher Felton <chr...@gm...> wrote:
> At this point in time I am going to defer converting the wrap function
> as briefly discussed in other threads.  It is beyond my current
> capabilities.  But this doesn't change the approach.  It simply means
> the wrap can only be used as an attribute of the intbv object, thank you
> Tom Dillon for the pointer here.

Looks like a good idea. See my comments bellow.

>
> It also seemed appropriate to add a property for _val, see the following.
>
>     # val property
>     def _get_val(self):
>         return self._val
>
>     def _set_val(self, pval):
>
>         if self._wrap:
>             self._val = self.wrap(pval)

do both _wrap and wrap exists ?

>         else:
>             self._val = pval
>
>         self._checkBounds()
>
>     val = property(_get_val, _set_val)

I guess you'd better like to call the property _val and put its
internal value inside __val. This way you minimize your impact on the
rest of the code.

>
>
> This had been discussed in some older threads.  Are there any objections
> against this type of implementation?  The _checkBounds and wrap will be
> called only from the _set_val property function.
>
> Above self._wrap is a data member initialized in the constructor based
> on a parameter.
>
> def __init__(self, val=0, min=None, max=None, wrap=False, _nrbits=0):

My understanding is that in the constructor, if wrap is a boolean
(isinstance(wrap, boolean)), and equal to True, then do the regular
wrapping (modulo max), otherwise if set to False, don't do wrapping
(same as now), in a third case, one could give a function to use as
parameter like for instance one that throw an overflow exception when
it occurs:

def mywrapfunc(self, val):
    if val > self._max or val < self._min:
      raise OverflowException()
    self._val = val

this function would simply be given as parameter to the constructor
like intbv(wrap=mywrapfunc).

I can try to put together a real patch with tests this evening ...
can't promise it though.

@Tom: backward compatibility is a must there.

Regards,
Benoît

Re: [myhdl-list] intbv wrap

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

On 05/04/2011 03:00 AM, Christopher Felton wrote:
> At this point in time I am going to defer converting the wrap function
> as briefly discussed in other threads.  It is beyond my current
> capabilities.  But this doesn't change the approach.  It simply means
> the wrap can only be used as an attribute of the intbv object, thank you
> Tom Dillon for the pointer here.

Do you mean we won't have wrap support in conversion? Would it be 
possible to put an error or warning in so you would know the logic won't 
match the MyHDL code?

It is beyond my capabilities too, I still conversion is magic.

> It also seemed appropriate to add a property for _val, see the following.
>
>       # val property
>       def _get_val(self):
>           return self._val
>
>       def _set_val(self, pval):
>
>           if self._wrap:
>               self._val = self.wrap(pval)
>           else:
>               self._val = pval
>
>           self._checkBounds()
>
>       val = property(_get_val, _set_val)
>
>
> This had been discussed in some older threads.  Are there any objections
> against this type of implementation?  The _checkBounds and wrap will be
> called only from the _set_val property function.

Will intbv work as it does now? I am a little rusty on properties.

Re: [myhdl-list] Motor Controller in MyHDL

[David R. <dav...@gm...>]

Hi All,

My board has been held by customs. I had to pay a fee due to VAT. Anyway,
that will motivate me to start using it.  By the way,  was the motor
controller uploaded (I've Cced Andrew Stone)? I have some spare boards for
video processing (Cyclocone II+QDRII+DVI reciver and transmitter) that I can
use for some  image processing project. My main interest at the moment are:


   - get up to speed with MyHDL
   - write some memory controller with MyHDL (home project)


Regards,
Drod


On Tue, Apr 19, 2011 at 12:42 PM, Christopher Felton <chr...@gm...
> wrote:

> Andrew,
>
> You can create a wiki page on myhdl.org and post it there if you are
> interested.
>
> Chris Felton
>
> On 4/18/11 1:12 PM, Andrew Stone wrote:
> > That was me.  Its a stepper motor controller.  Give me a day or so to
> > dig it up!
> >
> > Cheers!
> > Andrew
> >
>
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
David Rodríguez Martin
Cambridge,UK

[myhdl-list] intbv wrap

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

At this point in time I am going to defer converting the wrap function 
as briefly discussed in other threads.  It is beyond my current 
capabilities.  But this doesn't change the approach.  It simply means 
the wrap can only be used as an attribute of the intbv object, thank you 
Tom Dillon for the pointer here.

It also seemed appropriate to add a property for _val, see the following.

     # val property
     def _get_val(self):
         return self._val

     def _set_val(self, pval):

         if self._wrap:
             self._val = self.wrap(pval)
         else:
             self._val = pval

         self._checkBounds()

     val = property(_get_val, _set_val)


This had been discussed in some older threads.  Are there any objections 
against this type of implementation?  The _checkBounds and wrap will be 
called only from the _set_val property function.

Above self._wrap is a data member initialized in the constructor based 
on a parameter.

def __init__(self, val=0, min=None, max=None, wrap=False, _nrbits=0):

Thanks
Chris Felton

Re: [myhdl-list] Decorator Question

[Ben <ben...@gm...>]

On Wed, May 4, 2011 at 09:17, Jan Decaluwe <ja...@ja...> wrote:
> On 05/03/2011 09:57 PM, Christopher Lozinski wrote:
>> I just finished the first draft of the translation of Martin Gaitan's
>> Introductory document to English.
>>
>> I am sure I made some mistakes.  But I know I did not get Generators
>> right.  It is not too hard to understand them in Python.  But I think my
>> larger problem is understanding what they represent in hardware.  I
>> presume that my mental model of hardware is too simplistic.
>>
>> And it is not just me.  I suspect that other newbies will have a hard
>> time understanding generators.
>>
>> So what do generators represent in hardware?  what is the difference
>> between @instance, @always, and @always_comb from a hardware perspective?
>
> http://www.myhdl.org/doc/current/manual/modeling.html#rtl-modeling
> http://www.myhdl.org/doc/current/manual/reference.html#decorator-functions
> http://myhdl.org/doku.php/meps:mep-100
>

Let me also point you to another advise from Jan D. to you dating from March 31:

http://sourceforge.net/mailarchive/message.php?msg_id=27287048

On Thu, Mar 31, 2011 at 11:13, Jan Decaluwe <ja...@ja...> wrote:
> On 03/29/2011 10:07 PM, Christopher Lozinski wrote:
>> I know a lot about semiconductor manufacturing, but very little about
>> digital electonics.  This MyHDL stuff looks hugely interesting, but hard
>> to wrap my head around.
>
> To avoid disappointments, it may be wise to start by
> reading an introductory text to digital electronics
> and synthesis first. Starting with MyHDL before this
> is probably not the right approach, because it assumes
> implicit knowledge, especially about limitations :-)
> (Until someone writes the book "Introduction to
> digital design using MyHDL" of course :-))

Re: [myhdl-list] Decorator Question

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

On 05/03/2011 09:57 PM, Christopher Lozinski wrote:
> I just finished the first draft of the translation of Martin Gaitan's
> Introductory document to English.
>
> I am sure I made some mistakes.  But I know I did not get Generators
> right.  It is not too hard to understand them in Python.  But I think my
> larger problem is understanding what they represent in hardware.  I
> presume that my mental model of hardware is too simplistic.
>
> And it is not just me.  I suspect that other newbies will have a hard
> time understanding generators.
>
> So what do generators represent in hardware?  what is the difference
> between @instance, @always, and @always_comb from a hardware perspective?

http://www.myhdl.org/doc/current/manual/modeling.html#rtl-modeling
http://www.myhdl.org/doc/current/manual/reference.html#decorator-functions
http://myhdl.org/doku.php/meps:mep-100

-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

[myhdl-list] I ordered both boards

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

Both the DspTronics board and I ordered the cheaper be board, for the 
class.

http://www.arrownac.com/offers/altera-corporation/bemicro/

My thinking is that it would be easier to get the DSPtronics board 
working.  I have the blinking light tutorial on my desk.   Then I can 
figure out how to port it to the Be board for the class.

The first pass translation on the introductory slide show translation is 
done.  Soon I will have the boards.  I have the tutorial.  I am getting 
much closer very fast to offering this class.

Thanks for all the help everyone.

-- 
Regards
Christopher Lozinski

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

Expect a paradigm shift.
http://MyHDL.org

[myhdl-list] Decorator Question

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

I just finished the first draft of the translation of Martin Gaitan's 
Introductory document to English.

I am sure I made some mistakes.  But I know I did not get Generators 
right.  It is not too hard to understand them in Python.  But I think my 
larger problem is understanding what they represent in hardware.  I 
presume that my mental model of hardware is too simplistic.

And it is not just me.  I suspect that other newbies will have a hard 
time understanding generators.

So what do generators represent in hardware?  what is the difference 
between @instance, @always, and @always_comb from a hardware perspective?

There is a memory example in the documentation, but that did not clear 
it up in my mind either.

Much appreciated.

-- 
Regards
Christopher Lozinski

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

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] I am working on the first translation.

[Martín G. <ga...@gm...>]

2011/5/3 Christopher Lozinski <loz...@fr...>:
> My apologies.  I should have looked that up.
>
> From the manual.
>
>  Inside the top level function we declare a local function called sayHello()
> that defines the desired behavior. This function is decorated with an
> always() decorator that has a delay object as its parameter. The meaning is
> that the function will be executed whenever the specified delay interval has
> expired.
>
> How about:
>
>>       - ``@always_comb`` executes when you change any input signal
>>       - ``@always``: executes after on a scheduled interval
>

ok, wrong again. that is a particular case because you are using
delay(10)  delay is helper function wich produce an event until a
period of time. But you could use @always either with  your own
signal, as usually with a "clock" for synced logic.

Ok, ask in the list and read the manual carefully, please ;-)

Re: [myhdl-list] MyHDL at PyDay in Córdoba

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

  Is there a video or audio of your talk.

Otherwise I am going to botch the translation.

-- 
Regards
Christopher Lozinski

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

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] MyHDL at PyDay in Córdoba

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

Okay, I am delighted to translate this document to English.

It is not just about supporting this project.   When I got here I was 
hugely confused about the licensing issues.  There was a lot of 
fighting.  I very quickly learned a lot.  Now it is much clearer.  So I 
am also supporting the concept of MyHDL as a community with different 
licenses, based on what makes different authors feel comfortable.  The 
consumers may not like a choice of license.  We have to live with it.    
And so I am supporting not only this project, but also your choice of 
license.
Even if it is not my first choice.   I can live with it.

I have a couple of  pages I want to add for beginners.

Why Python?
Why not CPU?
Why not GPU?
Why not DSP?
Why FPGA?
Which FPGA vendor?
Which board?

Of course you did not need those slides at a FPGA conference.   But the 
beginners will be asking.  And it helps to put the context in place for 
what we are doing.    I am still looking for the answers to the GPU, and 
DSP questions.  Any suggestions for what should be on those pages would 
be most appreciated.  In your email please say that you release your 
copyright, and agree to the license this material is made available under.

CC BY-SAhttp://creativecommons.org/licenses/by-sa/3.0/

On to the details.  It looks like it is one file.
MyHDL.rst.  This looks easy.  It is always harder than expected.

I presume we should maintain this in multiple languages.  Should we call 
the english version english.rst?  Do we have to translate index.html 
also?  How are you serving it?  Will your server autodetect browser 
language?  Zope does that very nicely.

Translating the images is perhaps more difficult.  I looked at it 
carefully and besides the text all but 2 images are already 
multilingual.  Page 3 has a photo in Spanish. I can't translate that.    
One code sample is in Spanish.  I wonder what Preguntas means.   Mostly 
I understood the google translate version.  The few lines that were 
cryptic, I will ask you when I get to them.

I am not quite sure how to maintain the different languages versions in 
sync.  Maybe when someone changes a page, or adds a page, they can email 
the other maintainers to update the changes in their language 
versions.   I am happy to translate and maintain the English version.  I 
reserve the right to resign if I need to.  I invite others to help 
translate this to other languages.  MyHDL needs introductory material in 
multiple languages.   Many hands make light work.

Could you give me write permissions on the archive please?

Regards
Christopher Lozinski




On 5/1/11 3:36 PM, Martín Gaitán wrote:
> Yesterday was the PyDay and I gave my talk about MyHDL. It's very
> short and basic, oriented to people who knows about python but not
> hardware design (not so far from myself!)
>
> here are the slides
> http://nqnwebs.github.com/myhdl-talk/
>
> and here all  sources
> https://github.com/nqnwebs/myhdl-talk
>
> I think it was fine :-)
>
> cheers
> Martin
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


-- 
Regards
Christopher Lozinski

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

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] MyHDL at PyDay in Córdoba

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

On 05/03/2011 12:40 AM, Christopher Lozinski wrote:
> Thank you for writing that talk.  It is just what is needed.  My
> Spanish was not that good but with the help of Google translate, it
> quite made sense.
>
>> CC BY-SA looks as a good
>> idea.http://creativecommons.org/licenses/by-sa/3.0/
>
>
> If you wrote it under that license, I am happy to use it under that
> license.  I had thought there would be one set of licenses for the
> MyHDL community, but i now understand that all kids of people will
> want to participate under different licenses.  For example, one
> person I spoke to was thinking of just releasing to the public
> domain.   We just have to use what is available as is.  Okay.  I get
> it.

Now what is all this supposed to mean?

For the MyHDL core - software, documentation and myhdl.org - there
*is* a single set of licenses. The minimum set of 2, one for
software and one for documentation. I have proposed to move
to CC BY-SA for documentation - but the saldo remains two.

If you want to participate to the core project, you have to
comply with those licenses. For example, Martin's choice makes
it possible to incorporate his contributions in myhdl.org
(after the move) if he or someone else chooses to do so.

If you don't want to participate to the core project, that
is fine. You can still be part of the community. However,
for the community as whole, with all initiatives, ventures
and projects one can imagine, it would be very unwise to
strive for a common set of licenses. Obviously, you don't
want that yourself. For example, for your training class project,
you may (understandably) prefer a closed source license, and
you wouldn't want us to tell you that you should open source
it 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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Proposal to change license of wwww.myhdl.org

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

Hi all,

I have been trying to follow this discussion but have really lost track 
of the problem, if there ever was one.

I find MyHDL very useful and have done many presentations that have 
included references to how I use it in my design flow.

The open license is a major advantage and I would not like to have it 
any other way.

Tom



On 05/02/2011 05:02 PM, Jan Decaluwe wrote:
> On 05/02/2011 04:45 PM, Christopher Lozinski wrote:
>>> Let's see, what problem could that be?
>> MyHDL is not going anywhere fast.  Of course just this morning that
>> lovely Spanish introductory python material showed up, as if to
>> disprove my beliefs.  But the larger issues is still there.  The
>> class libraries, the board interfaces, the test cases are just not
>> there.    To be specific, it does not have the functionality I need
>> to build my project.  And nothing visible is happening on the mailing
>> list.
>>
>>> Right from the start, you made it very clear that you were looking
>>> for a closed-source project.
>> That is not entirely correct.  I rather like the idea of the core
>> being LGPL, meaning you are not allowed to make money reselling it.
>> I like the idea of the class libraries and content being more open,
>> like Zope public libraries, meaning you are allowed to resell them.
> This illustrates very well why it so tiresome to discuss
> with you. You change opinions all the time, without getting
> the basic facts right.
>
> Now you suddenly like the LGPL. I guess I should be happy,
> but I'm not. You were against it for the wrong reasons, and now
> you like it, also for the wrong reasons.
>
> The difference between (L)GPL and "public" licenses is not that
> you are allowed to resell or not. If you manage to sell (L)GPL
> licensed software for millions of dollars, I think you would
> instantly become Richard Stallman's biggest hero. The ultimate
> proof of his concept. (It may not be easy, but that is really a
> different issue.)
>
> The difference is whether you can close the source of a modified
> version, or not. With (L)GPL you cannot, with "public"
> licenses you can. In the worst case, if two projects are
> based on my codebase, and mine stays open and yours is closed,
> you could start making legal troubles about my project, based
> on my own hard work. That is why I don't like "public"
> licenses (and why I think Richard Stallman is a genius, for
> making free software *feasible*.)
>
>>> Actually, some went to work immediately with considerable efforts.
>>>
>> Let me correct you.  Chris Felton and Jan Coombs, did brilliant
>> work, but we later learned we were working under different
>> assumptions.
> Such an unfortunate order of events should be avoided.
>
>>> There must be something in your approach that they dislike very
>>> much.
>> That is very clear to me.  There are those, Richard Stallman
>> included, who do not like companies make money off their software,
>> and so despite the good marketing name, "open source",  they close
>> the source to commercial use.   Coming from the Zope community, I had
>> not understood how strong those sentiments were.
> Again, the facts are wrong. (L)GPL is not about closing
> the source to commercial use. It is about keeping the source,
> and its derivatives, open to any use.
>
> Anyway, you suggest that the reason why people over here dislike
> your approach is that they are "open-source heroes". Perhaps,
> I don't know. I would be really surprized though, and my
> guess is the reasons are much more down-to-earth.
>
>> But in this case, we have a problem, that MyHDL is not growing as
>> fast as we would like, and furthermore, the class libraries and test
>> harnesses are barely there.   They certainly do not meet my needs.
>>
>> I am just pointing out a problem.  Please do not shoot the messenger.
>> I would appreciate it if those who  agreed with my position would
>> also speak up.
> The diagnosis is not really the problem. I have posted a similar one
> on April 4 myself, so I have no intention to shoot the messenger.
>
>>> The real question is how it is even possible to waste so much
>>> goodwill in such a small period of time.
>> I like the saying, "Hard on issues, soft on people".  Please let us
>> stay focused on what it takes to build MyHDL into the thriving
>> community that it deserves to be.  Let us figure out what strong
>> medicine this weak patient needs.  I am sorry if strong medicine
>> tastes bad.
> A bad taste doesn't make it a strong medicine.
>

Re: [myhdl-list] MyHDL at PyDay in Córdoba

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

Thank you for writing that talk.  It is just what is needed.  My Spanish 
was not that good but with the help of Google translate, it quite made 
sense.

>CC BY-SA looks as
>a good idea.http://creativecommons.org/licenses/by-sa/3.0/


If you wrote it under that license, I am happy to use it under that license.  I had thought there would be one set of licenses for the MyHDL community, but i now understand that all kids of people will want to participate under different licenses.  For example, one person I spoke to was thinking of just releasing to the public domain.   We just have to use what is available as is.  Okay.  I get it.

I really like the idea of your rsttoslides application.  One minor point, at my font size the text disappeared off the bottom of the screen, I had to shrink the font size.

Thank you for the hard work.  I feel like that is a huge step forward for MyHDL.

Regards
Chris






On 5/1/11 3:36 PM, Martín Gaitán wrote:
> Yesterday was the PyDay and I gave my talk about MyHDL. It's very
> short and basic, oriented to people who knows about python but not
> hardware design (not so far from myself!)
>
> here are the slides
> http://nqnwebs.github.com/myhdl-talk/
>
> and here all  sources
> https://github.com/nqnwebs/myhdl-talk
>
> I think it was fine :-)
>
> cheers
> Martin
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


-- 
Regards
Christopher Lozinski

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

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] Proposal to change license of wwww.myhdl.org

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

On 05/02/2011 04:45 PM, Christopher Lozinski wrote:
>> Let's see, what problem could that be?
> MyHDL is not going anywhere fast.  Of course just this morning that
> lovely Spanish introductory python material showed up, as if to
> disprove my beliefs.  But the larger issues is still there.  The
> class libraries, the board interfaces, the test cases are just not
> there.    To be specific, it does not have the functionality I need
> to build my project.  And nothing visible is happening on the mailing
> list.
>
>> Right from the start, you made it very clear that you were looking
>> for a closed-source project.
> That is not entirely correct.  I rather like the idea of the core
> being LGPL, meaning you are not allowed to make money reselling it.
> I like the idea of the class libraries and content being more open,
> like Zope public libraries, meaning you are allowed to resell them.

This illustrates very well why it so tiresome to discuss
with you. You change opinions all the time, without getting
the basic facts right.

Now you suddenly like the LGPL. I guess I should be happy,
but I'm not. You were against it for the wrong reasons, and now
you like it, also for the wrong reasons.

The difference between (L)GPL and "public" licenses is not that
you are allowed to resell or not. If you manage to sell (L)GPL
licensed software for millions of dollars, I think you would
instantly become Richard Stallman's biggest hero. The ultimate
proof of his concept. (It may not be easy, but that is really a
different issue.)

The difference is whether you can close the source of a modified
version, or not. With (L)GPL you cannot, with "public"
licenses you can. In the worst case, if two projects are
based on my codebase, and mine stays open and yours is closed,
you could start making legal troubles about my project, based
on my own hard work. That is why I don't like "public"
licenses (and why I think Richard Stallman is a genius, for
making free software *feasible*.)

>> Actually, some went to work immediately with considerable efforts.
>>
> Let me correct you.  Chris Felton and Jan Coombs, did brilliant
> work, but we later learned we were working under different
> assumptions.

Such an unfortunate order of events should be avoided.

>> There must be something in your approach that they dislike very
>> much.
> That is very clear to me.  There are those, Richard Stallman
> included, who do not like companies make money off their software,
> and so despite the good marketing name, "open source",  they close
> the source to commercial use.   Coming from the Zope community, I had
> not understood how strong those sentiments were.

Again, the facts are wrong. (L)GPL is not about closing
the source to commercial use. It is about keeping the source,
and its derivatives, open to any use.

Anyway, you suggest that the reason why people over here dislike
your approach is that they are "open-source heroes". Perhaps,
I don't know. I would be really surprized though, and my
guess is the reasons are much more down-to-earth.

> But in this case, we have a problem, that MyHDL is not growing as
> fast as we would like, and furthermore, the class libraries and test
> harnesses are barely there.   They certainly do not meet my needs.
>
> I am just pointing out a problem.  Please do not shoot the messenger.
> I would appreciate it if those who  agreed with my position would
> also speak up.

The diagnosis is not really the problem. I have posted a similar one
on April 4 myself, so I have no intention to shoot the messenger.

>> The real question is how it is even possible to waste so much
>> goodwill in such a small period of time.
> I like the saying, "Hard on issues, soft on people".  Please let us
> stay focused on what it takes to build MyHDL into the thriving
> community that it deserves to be.  Let us figure out what strong
> medicine this weak patient needs.  I am sorry if strong medicine
> tastes bad.

A bad taste doesn't make it a strong medicine.

-- 
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
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Looks Great

[Martín G. <ga...@gm...>]

Hi Christopher,

I'm glade if you think my humble work is useful.. Would be great if
it's improved (I'd like to use that version)... So , CC BY-SA looks as
a good idea. http://creativecommons.org/licenses/by-sa/3.0/

I could help you translating this if you want.

By the way, I used rst2slides which is a tiny project I've started.
http://pypi.python.org/pypi/rst2slides

cheers


2011/5/2 Christopher Lozinski <loz...@fr...>:
> Although my spanish is not that good.
>
> I love the example.
>
> So what license are you making this material available on?
>
> Feel free to answer on the mailing list.
>
> --
> Regards
> Christopher Lozinski
>
> Check out my iPhone apps TextFaster and EmailFaster
> http://textfaster.com
>
> Expect a paradigm shift.
> http://MyHDL.org
>
>



-- 
nqnwebs.com
textosypretextos.com.ar