myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Testbench problems

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

On 4/19/2011 1:09 PM, Terry Brown wrote:
> I am in the process of writing a module implementing registers in an fpga.  I
> have the module logic working.
>
> In the testbench, I instantiate the module and generate a clock and use this to
> handle reset:
>
>
>      @instance
>      def reset_stim():
>          yield delay(1)
>          reset_n.next = 0
>          dstb.next = 0
>          rdstb.next = 0
>          din.next = 0
>          adr.next = 0
>          i2c_stop.next = 0
>          status_input.next = 0
>          yield delay(100)
>          reset_n.next = 1
>
> Then I use another @instance for the actual test. The test simply toggles the
> inputs to the module to write and read the registers.
>
> To generate the read and write cycles, I use a combination of delays and
> assignments.  However, in verilog, I am used to using tasks to define these
> operations, then calling them.
>
> I want to use the high-level capability of python to code the test, but I
> haven't been able to make it work with defined tasks of the verilog type that
> use delays to manipulate signals.

Make your "tasks" generators and then use yield test_readit()

Below is an example from a USB interface model that I have used.

#---------------------------------------------------------------------------
# In main testbench
yield fx2Model.WriteAddress(0x0101, 1)


     def WriteAddress(self, addr, data):

         wbuf = [0xDE, 0xCA, 0x01, 0x00, 0x00, 0x01, 0xFB, 0xAD, 0x00]
         rbuf = [0]*9

         wbuf[3]  = (addr >> 8) & 0xFF
         wbuf[4]  = addr & 0xFF
         wbuf[5]  = 1
         wbuf[8]  = data

         self.Write(wbuf, self.EP2)
         while not self.IsEmpty(self.EP2):
             yield delay(2*self.IFCLK_TICK)
         while not self.IsData(self.EP6, 9):
             yield delay(2*self.IFCLK_TICK)

         for i in range(9):
             rbuf[i] = self.Read(self.EP6)

         for i in range(9):
             assert wbuf[i] == rbuf[i]
#---------------------------------------------------------------------------

The above WriteAddress is a generator because it contains the yield. 
The top-level testbench can yield to the generator, you can yield as 
many levels down as you need.

Hope that helps.
Chris Felton

[myhdl-list] Testbench problems

[Terry B. <tt...@gm...>]

I am in the process of writing a module implementing registers in an fpga.  I 
have the module logic working.

In the testbench, I instantiate the module and generate a clock and use this to 
handle reset:


    @instance
    def reset_stim():
        yield delay(1)
        reset_n.next = 0
        dstb.next = 0
        rdstb.next = 0
        din.next = 0
        adr.next = 0
        i2c_stop.next = 0
        status_input.next = 0
        yield delay(100)
        reset_n.next = 1

Then I use another @instance for the actual test. The test simply toggles the 
inputs to the module to write and read the registers.

To generate the read and write cycles, I use a combination of delays and 
assignments.  However, in verilog, I am used to using tasks to define these 
operations, then calling them.  

I want to use the high-level capability of python to code the test, but I 
haven't been able to make it work with defined tasks of the verilog type that 
use delays to manipulate signals.  

For example, I would like to do this:

def readit (adr):
  yield clk.posedge
  yield delay(1)
  reg_module_address.next = adr
  yield clk.posedge
  yield delay(1)
  return reg_module_data_out

And then in the test do this:
def testit():
  for reg in reglist:
    rddata = readit(reg)
    print str(rddata)

But when I do that the readit function doesn't apparently do anything--no 
clocking occurs, no delays occur.  I get no runtime errors, but the function 
doesn't execute.  If I place the readit code inline within the testit function, 
it all works properly.

What am I missing?  Must be something basic.  If it's not and someone wants to 
see the actual code, let me know.

Thanks for the help.

Terry Brown

Re: [myhdl-list] Motor Controller in MyHDL

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

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
>

Re: [myhdl-list] intbv.wrap()

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

The following are the proposed changes to the intbv class (WIP).

I added the attribute but I have not added the "wrap" __setitem__ and i* 
operators.

Need to determine if the intbv.wrap function will remain a public 
function or move to a private function.  If it remains an advertised 
public function then the conversion will need to handle the wrap function.

Feedback always welcome.

Note the attached change set is *INCOMPLETE* add for convenience.

----------------------
# Simple test code
x = intbv(0, min=-8, max=8)
for ii in xrange(x):
     x[:] = x.wrap(x+1)
     print x

for ii in range(1333):
     x[:] = x.wrap(x+77)
     # bound checking will catch errors, more test cases needed
	
# Additions to the intbv class
class intbv(object):
     __slots__ = ('_val', '_min', '_max', '_nrbits', '_range', '_wrap')

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

         ...

         self._nrbits = _nrbits
         self._wrap  = wrap
         self._range = 2**_nrbits


     def wrap(self, val):
         """ Wrap the value back to the range of the inbv

         The following will check that the defined min-max is the full
         range of the binary word.  If the full range is specified if
         the value is outside the bounds of the range it will be adjusted
         to the proper value in bounds.
         """
         assert abs(self.min) == self.max
         assert (abs(self.min) + self.max) == self._range

         rval = self.min + ((val +self.max) % self._range)

         return rval
----------------------

Re: [myhdl-list] intbv.wrap()

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

On 04/18/2011 05:25 PM, Christopher Felton wrote:
> On 4/18/2011 12:08 PM, Tom Dillon wrote:
>> Why not make it part of the intbv object? It seems like when you create
>> the intbv you should know if you want bounds checking or wrapping.
>>
>> So you would do this:
>>
>> x = intbv(0,min=-8,max=7,wrap=True)
>> x[:] = x + 5
>>
>> The default would be wrap=False.
>>
>>
>>
> In the past the explicit stating of a wrap was preferred.  In the case
> of an unsigned, x[:] = x % 8 was preferred over building in a attribute.
>    Someone reading the code would not need to know if wrap attribute was
> set or not.

I generally like keeping the low level details down in the class.

  I think it comes down to if we think it is a basic part of the intbv. 
To me it is since we are really modeling the behavior of the logic.

Now if we were talking about something like saturation, then there would 
be a good case for a function call and not an attribute as it would be 
additional logic to implement as well. Although if we were talking about 
saturation I would also vote for an attribute.


> I can't think of an example but if for some reason, you wanted to mix
> bound checking and wrapping.  Maybe mixing would be a bad thing to allow?

You could solve that with an attribute too.

> But the attribute would solve the conversion implementation!

I think it is fine either way, just like the discussion and hearing the 
different perspectives.

Re: [myhdl-list] intbv.wrap()

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

On 4/18/2011 12:08 PM, Tom Dillon wrote:
> Why not make it part of the intbv object? It seems like when you create
> the intbv you should know if you want bounds checking or wrapping.
>
> So you would do this:
>
> x = intbv(0,min=-8,max=7,wrap=True)
> x[:] = x + 5
>
> The default would be wrap=False.
>
>
>

In the past the explicit stating of a wrap was preferred.  In the case
of an unsigned, x[:] = x % 8 was preferred over building in a attribute. 
  Someone reading the code would not need to know if wrap attribute was 
set or not.

I can't think of an example but if for some reason, you wanted to mix 
bound checking and wrapping.  Maybe mixing would be a bad thing to allow?

But the attribute would solve the conversion implementation!

Chris Felton

Re: [myhdl-list] intbv.wrap()

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

On 4/18/2011 12:08 PM, Tom Dillon wrote:
> Why not make it part of the intbv object? It seems like when you create
> the intbv you should know if you want bounds checking or wrapping.
>
> So you would do this:
>
> x = intbv(0,min=-8,max=7,wrap=True)
> x[:] = x + 5
>
> The default would be wrap=False.
>
>

In the past the explicit stating of a wrap was preferred.  In the case 
of an unsigned, x[:] = x % 8 was preferred over building in a attribute. 
  Someone reading the code would not need to know if wrap attribute was 
set or not.

Second, if for some reason you wanted to mix bound checking and 
wrapping.  I can't think of an example and maybe this would be a bad 
thing to allow.

But the attribute would solve the conversion implementation.

Chris Felton

Re: [myhdl-list] intbv.wrap()

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

I guess Jan D, and I see the world differently.  On so many issues.  
This should be interesting ongoing discussion.  Oh well here goes.

Jan D said:

    Really? Python doesn't have 32 bit integers that yield an overflow
    error. If you want that, tryintbv(0)[32:].


Actually I did not even know how python implements integers.  That is 
how it should be.  So I took a look at the docs and this is what they say.

http://docs.python.org/reference/datamodel.html#objects-values-and-types

    Plain integers

        These represent numbers in the range -2147483648 through
        2147483647. (The range may be larger on machines with a larger
        natural word size, but not smaller.) When the result of an
        operation would fall outside this range, the result is normally
        returned as a long integer (in some cases, the exception
        OverflowError
        <http://docs.python.org/library/exceptions.html#exceptions.OverflowError>
        is raised instead). For the purpose of shift and mask
        operations, integers are assumed to have a binary, 2's
        complement notation using 32 or more bits, and hiding no bits
        from the user (i.e., all 4294967296 different bit patterns
        correspond to different values).


So this is all useful.  Actually I prefer returning a long integer to 
the overflow error.   I wonder when the overflow error is raised?   So, 
as a python guy, using MyHDL, this is how I would like integers to behave!
No Wrapping please!   It is not part of the python spec.     Of course 
if others want wrapping, that is fine by me.

And yes, I understand that returning a different types is not typically 
done in hardware!
> Terrible? Ada has modular types. They wrap around.
Proves my point!

Regards
Chris







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

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

On 04/18/2011 08:23 PM, Christopher Lozinski wrote:
> Thank you to Tom Dillon and to Chris Felton for explaining the wrapping
> stuff.  It took me forever to understand it.  Now I know why.
>
> I totally understand how hardware engineers would want to do that.  But
> for the software engineer, it is a terrible idea.  Different people
> really do see the world differently.

Terrible? Ada has modular types. They wrap around.

> As a software guy I just want a 32 bit integer that yields an error
> condition when it overflows.  That is what I expect.  And of course if
> it is made up of a sign object and a mantissa so much the better.

Really? Python doesn't have 32 bit integers that yield an overflow
error. If you want that, tryintbv(0)[32:].

> I am not trying to change the intbv library.  It is perfect for its
> users.  I am just pointing out that we software engineers see the world
> differently from the hardware engineers.

As my counter-examples show, many software engineers apparently see
the word differently from you. Let's sort that out, before even
starting with the hardware engineers.

>  So maybe eventually there can
> be two different integer libraries, with different models behind them,
> and maybe different users.  Those building application specific circuits
> would use one, those building generic microprocessors could use the other.

I don't see what good this would do for these cases. Both users
are hardware designers for which hardware efficiency is probably
a crucial cost factor, especially for those building generic
microprocessors.

-- 
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] intbv.wrap()

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

Thank you to Tom Dillon and to Chris Felton for explaining the wrapping 
stuff.  It took me forever to understand it.  Now I know why.

I totally understand how hardware engineers would want to do that.  But 
for the software engineer, it is a terrible idea.  Different people 
really do see the world differently.

As a software guy I just want a 32 bit integer that yields an error 
condition when it overflows.  That is what I expect.  And of course if 
it is made up of a sign object and a mantissa so much the better.

I am not trying to change the intbv library.  It is perfect for its 
users.  I am just pointing out that we software engineers see the world 
differently from the hardware engineers.  So maybe eventually there can 
be two different integer libraries, with different models behind them, 
and maybe different users.  Those building application specific circuits 
would use one, those building generic microprocessors could use the other.

Hope that helps.

-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] Motor Controller in MyHDL

[Andrew S. <g.a...@gm...>]

That was me.  Its a stepper motor controller.  Give me a day or so to dig it
up!

Cheers!
Andrew

On Mon, Apr 18, 2011 at 10:39 AM, David Rodríguez <
dav...@gm...> wrote:

> If I remember right, somebody mentioned that had a MyHDL version of a motor
> controller, would you be willing to share it?
>
> regards
>
> --
> David Rodríguez Martin
> Cambridge,UK
>
>
> ------------------------------------------------------------------------------
> 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
>
>

[myhdl-list] Motor Controller in MyHDL

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

If I remember right, somebody mentioned that had a MyHDL version of a motor
controller, would you be willing to share it?

regards

-- 
David Rodríguez Martin
Cambridge,UK

Re: [myhdl-list] intbv.wrap()

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

Why not make it part of the intbv object? It seems like when you create 
the intbv you should know if you want bounds checking or wrapping.

So you would do this:

x = intbv(0,min=-8,max=7,wrap=True)
x[:] = x + 5

The default would be wrap=False.



On 04/18/2011 10:10 AM, Christopher Felton wrote:
> I have been working on a intbv.wrap() function.  Below are a couple
> comments and questions.
>
> **Modeling**
> The intbv has the convenient bound checking.  This bound checking is
> enforces the min-max which can be arbitrary. The max and min properties
> can be set regardless of the inherent min and max of the binary word.
>
> Here I refer to a binary word as a collection of bits.
>
> Example, and intbv can be declared as x = intbv(0, max=6, min=-5).  This
> is perfectly legal and can be useful.  This type of usage states that I
> would like to have a binary word and I expect its values to always be in
> this range min-max.  Declaring an intbv of this type doesn't add any
> additional logic to a design it only enforces the desired behavior
> during simulation.
>
> An intbv wrap function doesn't make sense in the previous example.
> Because it is not the inherent behavior of the binary word being
> modeled.  Wraps of this type can be implemented but they require
> additional logic and this additional logic should be stated in a design.
>
> To use the wrap function, the inherent wrapping of a binary word, the
> min and max must match the min-max of the binary word.  An assertion is
> added to enforce this rule, any objections?
>
> **Conversion**
> For the conversion I will need some assistance.  I assume the wrap
> function will be handled similar to the concat and intbv.signed
> functions.  I believe the a condition needs to be added to the
> *visit_Call* function the _analyze.py module.  Jan D. could you give me
> some pointers if this is correct?  For conversion, the proposed method
> would be to ignore the wrap functions and just include whatever is
> passed to wrap (if that makes sense?).  Example x.next = x.wrap(x+1)
> would result in x<= x + 1;
>
> **Questions**
> In the visit_Call function, what is the node.obj?
>
> Do you think the handler for the wrap function should also determine if
> node.signed should be set True?
>
>
> Note:  Above I indicated the wrap is a inherent property of a binary
> word.  A binary word is just a container so this isn't exactly correct.
>    In this context I am extending it to any operation that results in a
> limited number of bits.  Example is an adder whose results are always N
> bits regardless of the inputs.
>
> Chris Felton
>
> On 4/12/2011 6:52 AM, Christopher Felton wrote:
>> I created a small write-up here,
>> http://www.myhdl.org/doku.php/user:cfelton:projects:wrap, for a proposed
>> intbv.wrap() function.
>>
>> I wrote this quick and probably needs a second look.  I will look at the
>> implementation details later.
>>
>> Any comments welcome.
>>
>> Thanks
>> Chris Felton
>>
>>
>
> ------------------------------------------------------------------------------
> 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

[myhdl-list] intbv.wrap()

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

I have been working on a intbv.wrap() function.  Below are a couple 
comments and questions.

**Modeling**
The intbv has the convenient bound checking.  This bound checking is 
enforces the min-max which can be arbitrary. The max and min properties 
can be set regardless of the inherent min and max of the binary word.

Here I refer to a binary word as a collection of bits.

Example, and intbv can be declared as x = intbv(0, max=6, min=-5).  This 
is perfectly legal and can be useful.  This type of usage states that I 
would like to have a binary word and I expect its values to always be in 
this range min-max.  Declaring an intbv of this type doesn't add any 
additional logic to a design it only enforces the desired behavior 
during simulation.

An intbv wrap function doesn't make sense in the previous example. 
Because it is not the inherent behavior of the binary word being 
modeled.  Wraps of this type can be implemented but they require 
additional logic and this additional logic should be stated in a design.

To use the wrap function, the inherent wrapping of a binary word, the 
min and max must match the min-max of the binary word.  An assertion is 
added to enforce this rule, any objections?

**Conversion**
For the conversion I will need some assistance.  I assume the wrap 
function will be handled similar to the concat and intbv.signed 
functions.  I believe the a condition needs to be added to the 
*visit_Call* function the _analyze.py module.  Jan D. could you give me 
some pointers if this is correct?  For conversion, the proposed method 
would be to ignore the wrap functions and just include whatever is 
passed to wrap (if that makes sense?).  Example x.next = x.wrap(x+1) 
would result in x <= x + 1;

**Questions**
In the visit_Call function, what is the node.obj?

Do you think the handler for the wrap function should also determine if 
node.signed should be set True?


Note:  Above I indicated the wrap is a inherent property of a binary 
word.  A binary word is just a container so this isn't exactly correct. 
  In this context I am extending it to any operation that results in a 
limited number of bits.  Example is an adder whose results are always N 
bits regardless of the inputs.

Chris Felton

On 4/12/2011 6:52 AM, Christopher Felton wrote:
> I created a small write-up here,
> http://www.myhdl.org/doku.php/user:cfelton:projects:wrap, for a proposed
> intbv.wrap() function.
>
> I wrote this quick and probably needs a second look.  I will look at the
> implementation details later.
>
> Any comments welcome.
>
> Thanks
> Chris Felton
>
>

Re: [myhdl-list] MyHDLClass

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

On 04/14/2011 12:15 AM, Jan Decaluwe wrote:
> On 04/13/2011 11:05 PM, Christopher Lozinski wrote:
>> Home page is massively updated.
>>
>> http://MyHDLClass.com
>>
>> That provides links to the course material, still on Chris Felton's Hg
>> server.  Next I start editing the course material.
>>
>> We are releasing this material under a creative commons non-commercial
>> license, same as MyHDL.org.
>
> This may be the appropriate license for your purposes,
> but for myhdl.org it really is a (my) mistake.

We are jumping to conclusions way too fast, me in the first place.

The reference to CC BY-NC-SA is misleading, that's all.
It is clearly qualified by "Except where otherwise noted ..."

The next line says "All content is avaiable under the
terms of the GFDL". Therefore the current license is
the GDFL. The crucial difference is that the GDFL
permits commercial use.

I will propose to change the license to a license similar
in spirit but more appropriate for wiki's, probably
the CC BY-SA - certainly not to a license that
precludes commercial use.

-- 
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] Floating Point Libraries

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

Even though the signals and logic are in a class, does not keep the
>> generator from resolving it. As long as you used class methods to
>> instantiate your logic.
> Really? That convertor truly is magical :-)
>
I was amazed when I first did it but my conclusion was it was very well 
written.

Re: [myhdl-list] Floating Point Libraries

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

On 04/15/2011 02:37 PM, Günter Dannoritzer wrote:
> Am 15.04.2011 09:56, schrieb Jan Decaluwe:
> ...
>
>> For clarity: it is not my intention to include design IP
>> libaries ever in MyHDL itself. Those should be different
>> (potentially competing) libraries, with an appropriate
>> license, as decided by the project.
>
>
> Would you be willing to host that library under myhdl.org or do you see
> it as something, placed at a different site?

No preference. I'll leave that decision up to the project lead.

myhdl.org is available to document all MyHDL related stuff,
if you can live with the license, which is GDFL and should
evolve to CC BY SA.

My only restriction is that design IP libraries should live
in their own Python namespace and repository. That could
be on hg.myhdl.org, though I'm not even sure that is currently
the best choice for myhdl itself, given the rise of
powerful popular systems like github and bitbucket.
I can perhaps also be a little confusing and messy.

What I want to avoid is that the MyHDL community endorses
one "official" design IP library. I hope to see many
approaches, target domains and competition.

-- 
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] Floating Point Libraries

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

On 04/15/2011 03:39 PM, Tom Dillon wrote:
>
>
> On 04/15/2011 02:56 AM, Jan Decaluwe wrote:

>> That is how I was thinking. I just don't know how
>> easy/feasible it will be to support such a class in conversion.
>> I recommend to experiment with such a class extensively
>> in modeling first, to see what we really want.
>
> I have done similar for complex fixed point numbers and it works fine.
> Just have to unwrap the objects for top level I/O.
>
> Even though the signals and logic are in a class, does not keep the
> generator from resolving it. As long as you used class methods to
> instantiate your logic.

Really? That convertor truly is magical :-)

-- 
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] Inclusion of Libraries in MyHDL

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

On 04/15/2011 03:13 PM, Ben wrote:
> 2011/4/15 Günter Dannoritzer<dan...@we...>:
>> Am 15.04.2011 09:56, schrieb Jan Decaluwe:
>> ...
>>
>>> For clarity: it is not my intention to include design IP
>>> libaries ever in MyHDL itself. Those should be different
>>> (potentially competing) libraries, with an appropriate
>>> license, as decided by the project.
>>
>>
>> Would you be willing to host that library under myhdl.org or do you see
>> it as something, placed at a different site?
>>
>> This idea hast been around on the mailing list on and off, but never
>> really started to be implemented. However, looking at the wiki, there
>> are already now generic functions that could go into such a library. One
>> to name would be the CORDIC core.
>>
>> Say it would be under myhdl.org, starting from the wiki perspective, the
>> documentation of the library and its cores could be under a different
>> namespace. Then an extra mecurial repository could be set up for the
>> source code in a similar manner as it is done for the myhdl code itself.
>>
>> I think setting up the structure and documenting it on the wiki might
>> attract other developers to contribute.
>>
>> However, it would be good to setup quality guidelines to avoid
>> cluttering the library with unfinished projects, as can be seen on
>> opencores.
>
> I would propose the scheme used by mercurial with its numerous
> extensions. there are two kind of them. The one integrated with
> mercurial source code (living beside mercurial in the same
> repository), and the other ones. The promotion to the "integrated"
> status is based on the code maturity, stability, usability, and use of
> the extension. What they win in being integrated is that they are then
> also maintained by the core developers. At any point in time, they
> will work, and won't stop working if the original maintainer isn't
> interested in it any more (running their testsuite is part of
> mercurial testsuite). Another big advantage is being integrated in the
> mercurial documentation.
>
> In the same manner, external MyHDL libraries implement extra features
> who don't make sense cut away from MyHDL, but MyHDL still works
> perfectly fine without them. This is why, I think the same model as
> mercurial extensions could be applied to MyHDL libraries. They don't
> need to be integrated from day 1, but knowing that the possibility
> exists would be a bonus for the contributors of those external
> libraries.

I think you are mixing two seperate issues. One is extensions
to MyHDL itself. For example: a floating-point number class. Or Chris
Felton's fix-point numbers. Those are extensions similar
in nature to the mercurial extensions. They may start out
separately,but eventually live under the myhdl namespace.

Guenter is talking about design IP libraries. For example,
a library of floating-point modules written in MyHDL. I don't
want to put those under the myhdl namespace. In my mind, design
IP is completely separate from the language. There is a
single MyHDL, but I hope to see a lot of (potentially competing
and overlapping) libraries with design IP and various
licenses.

Jan

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

Re: [myhdl-list] Floating Point Libraries

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

On 04/15/2011 02:56 AM, Jan Decaluwe wrote:
> On 04/14/2011 07:00 PM, Tom Dillon wrote:
>> some comments below:
>>
>> On 04/14/2011 08:32 AM, Christopher Felton wrote:
>>> At the risk of embarrassing myself but to keep this thread going I
>>> will start a FP interface based on Jan D and Tom D. suggestions.
>>> Something like the following could be a start to an interface
>>> definition.
>>>
>>> class FloatingPoint(object):
>>>
>>> def __init__(self): pass
>>>
>>> def Add(self, clk, reset, a_sign, a_mant, a_exp, dva, b_sign,
>>> b_mant, b_exp, dvb, r_sign, r_mant, r_exp, dvr, EXP_W=8,
>>> MAN_W=23): pass
>>>
>>> def Mul(self, clk, reset, a_sign, a_mant, a_exp, dva, b_sign,
>>> b_mant, b_exp, dvb, r_sign, r_mant, r_exp, dvr, EXP_W=8,
>>> MAN_W=23): pass
>>>
>>> def Div(self, clk, reset, a_sign, a_mant, a_exp, dva, b_sign,
>>> b_mant, b_exp, dvb, r_sign, r_mant, r_exp, dvr, EXP_W=8,
>>> MAN_W=23): pass
>>>
>> I would recommend the class be the MyHDL representation of the number
>> itself.
>>
>> I don't think there is any real benefit to the operators being in the
>> class as they will just be called like function calls returning the
>> MyHDL instances.
>>
>> So I see it as something like this:
>>
>> class fp(object) : __slots__ = ['sign', 'exp', 'man', '_expW',
>> '_manW'] def __init__(self,initNum=0.0,expW=8,manW=23) : self._expW =
>> expW self._manW = manW self.setvalue(initNum)
>>
>> Note the fp object would keep all information about the structure and
>> widths.
>>
>> Then a Add module would look like this:
>>
>> def FpAdd(x,a,b,clk=None,reset=None,pipes=0) :
>>
>> x,a, and b being the required ports of type fp (could expand to other
>> types (fixed point). Option ports and parameters follow. You will end
>> up with more parameters before you are done.
>>
>> In floating point, something like an Add will have to have the option
>> for pipelines to be very useful. You may also want options for
>> multi-cycle operation to optimize the logic when they don't need to
>> run at the full clock rate.
>>
>> The operators don't need to know the width of the operands. That will
>> be determined by the i/o ports. You may want to allow mixed widths.
>>
>> You will like passing only the objects and not the sign, man and exp
>> separately. You may also decide that you don't store the sign
>> internally if that turned out to be more efficient. Keeping the sign
>> in the mantissa.
>>
>> Now when this is done it will be cleaner to use but will present a
>> problem with you get to conversion as the you won't be able to have
>> an fp object in the ports list at the top level. That is where you
>> will need a wrapper that breaks out and attaches the elements inside
>> fp.
>>
>> I think that is much easier than having three times the ports for all
>> module connections. You also increase your cross wiring chances.
>>
>> You can add a lot to the fp class that will make your life easier as
>> well.
> That is how I was thinking. I just don't know how
> easy/feasible it will be to support such a class in conversion.
> I recommend to experiment with such a class extensively
> in modeling first, to see what we really want.

I have done similar for complex fixed point numbers and it works fine. 
Just have to unwrap the objects for top level I/O.

Even though the signals and logic are in a class, does not keep the 
generator from resolving it. As long as you used class methods to 
instantiate your logic.

Some thing like:

x = a * b

Will not work for the generator if x,a, or b or an object from your 
floating point class.

Instead

U0 = fp.mult(x,a,b)
return U0

will work fine as by the top fp.mult is flattened all references to the 
fp class are gone, since at the lowest level all the operations are 
using types that MyHDL can convert.

> My workaround proposal was intended for those who want to
> get started today, including conversion support.
> To be honest, usage can hardly be worse than using
> ip libraries such as altera. Thinking futher about it,
> I'm not even sure the altera ip is about efficiency -
> it may just be about obfuscation and vendor lock-in.
>
I would recommend starting simple, then adding features. Good unittests 
and behavioral (not convertible, more like a model) code first. There 
are a lot of nuances to the operators to make all cases work.

Then as users have applications for different types of operators, they 
could be built, tested, then added to the common IP.
> In other words, if floating point ip is hot, there
> may be an opportunity here for someone who would like
> to develop a technology-independent MyHDL libary.

I am not sure how hot they would be. They would be useful for anyone 
developing with MyHDL and needing them and might attract some folks to 
MyHDL if they were available.

It will take some work to make them as efficient as the proprietary 
vendor (Xilinx, Altera) libraries.

Floating point operators are fairly expensive logic wise, which keeps 
most DSP logic using fixed point numbers. In FPGA systems, you get some 
transplants with DSP processor experience who absolutely think they need 
floating point. It is much simpler for them if you can deliver a system 
that will just match the accuracy they had using a floating point 
processor.

Python has very strong math/science modeling capability with 
Numeric/Numpy package. The combination of Numpy for the system guys and 
MyHDL with floating point logic development would be attractive.


> For clarity: it is not my intention to include design IP
> libaries ever in MyHDL itself. Those should be different
> (potentially competing) libraries, with an appropriate
> license, as decided by the project.

That is one of the strong points for MyHDL and python, it is very simple 
to include other packages (IP libraries). Just get the package in your 
PYTHONPATH and import.

In time you would want some common structure to the IP delivery, like 
documentation, delivery/install and interfaces just to make it simpler 
to bring in IP and use it.

[myhdl-list] Inclusion of Libraries in MyHDL

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

2011/4/15 Günter Dannoritzer <dan...@we...>:
> Am 15.04.2011 09:56, schrieb Jan Decaluwe:
> ...
>
>> For clarity: it is not my intention to include design IP
>> libaries ever in MyHDL itself. Those should be different
>> (potentially competing) libraries, with an appropriate
>> license, as decided by the project.
>
>
> Would you be willing to host that library under myhdl.org or do you see
> it as something, placed at a different site?
>
> This idea hast been around on the mailing list on and off, but never
> really started to be implemented. However, looking at the wiki, there
> are already now generic functions that could go into such a library. One
> to name would be the CORDIC core.
>
> Say it would be under myhdl.org, starting from the wiki perspective, the
> documentation of the library and its cores could be under a different
> namespace. Then an extra mecurial repository could be set up for the
> source code in a similar manner as it is done for the myhdl code itself.
>
> I think setting up the structure and documenting it on the wiki might
> attract other developers to contribute.
>
> However, it would be good to setup quality guidelines to avoid
> cluttering the library with unfinished projects, as can be seen on
> opencores.

I would propose the scheme used by mercurial with its numerous
extensions. there are two kind of them. The one integrated with
mercurial source code (living beside mercurial in the same
repository), and the other ones. The promotion to the "integrated"
status is based on the code maturity, stability, usability, and use of
the extension. What they win in being integrated is that they are then
also maintained by the core developers. At any point in time, they
will work, and won't stop working if the original maintainer isn't
interested in it any more (running their testsuite is part of
mercurial testsuite). Another big advantage is being integrated in the
mercurial documentation.

In the same manner, external MyHDL libraries implement extra features
who don't make sense cut away from MyHDL, but MyHDL still works
perfectly fine without them. This is why, I think the same model as
mercurial extensions could be applied to MyHDL libraries. They don't
need to be integrated from day 1, but knowing that the possibility
exists would be a bonus for the contributors of those external
libraries.

Regards
Benoît

Re: [myhdl-list] Floating Point Libraries

[Günter D. <dan...@we...>]

Am 15.04.2011 09:56, schrieb Jan Decaluwe:
...

> For clarity: it is not my intention to include design IP
> libaries ever in MyHDL itself. Those should be different
> (potentially competing) libraries, with an appropriate
> license, as decided by the project.


Would you be willing to host that library under myhdl.org or do you see
it as something, placed at a different site?

This idea hast been around on the mailing list on and off, but never
really started to be implemented. However, looking at the wiki, there
are already now generic functions that could go into such a library. One
to name would be the CORDIC core.

Say it would be under myhdl.org, starting from the wiki perspective, the
documentation of the library and its cores could be under a different
namespace. Then an extra mecurial repository could be set up for the
source code in a similar manner as it is done for the myhdl code itself.

I think setting up the structure and documenting it on the wiki might
attract other developers to contribute.

However, it would be good to setup quality guidelines to avoid
cluttering the library with unfinished projects, as can be seen on
opencores.

Anyhow, just some thoughts.

Cheers,

Guenter

Re: [myhdl-list] New MyHDL Tutorial Available.

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

On 4/14/11 7:27 PM, Jan Decaluwe wrote:
> On 04/13/2011 05:32 PM, Andrew Stone wrote:
>> Hi Christopher,
>>
>> Please explain what you mean by:
>>
>> "So the course material is not strictly open source.  By contributing
>> to it, you are allowing me to make some money off of it."
>>
>> Please state what the license to the course material is.
>>
>> There has never been any requirement that nobody make any money off
>> open source!  So I think that your argument to keep it closed source
>> for that reason is weak.  For example people can use OSS in their
>> daily jobs, include it as part of selling products, teach courses on
>> it, write books, consulting, etc.
>>
>> If your idea is that since this course material is closed source,
>> then only you (or people who license the course material from you)
>> will be able to use it to teach courses, then I shall certainly
>> retract my offer to test it on the Lattice Brevia XP2.  And
>> regardless of the goodness that you are currently bringing, shall
>> heartily wish that you find another endeavor.
>>
>> However, I don't think that it would come to that.  Just open-source
>> the course material.  If and when myHdl becomes popular, you'll have
>> plenty of paid opportunities as the author of the course.  After all,
>> who would you pay to hear a lecture about myHdl from: Jan D. or me
>> :-).
>>
>> Frankly, if you keep it closed source, you are simply inviting a
>> competitor.  Once you've created a market for training classes,
>> consulting, etc, someone else will make a completely separate
>> open-source course and rapidly overtake your course in popularity due
>> to its somewhat "free" nature.  The value is not in the actual course
>> material...the value is in the generation of the market.  Fortunately
>> that cannot ever be cornered because of the OSS nature of myHdl.
>> Your best strategy is to dis-invite competition by open-sourcing your
>> training material.
>>
>> Regards, Andrew
>
> Andrew:
>
> Thanks for these convincing arguments in favor of open source
> solutions. I fully agree, and I hope people will develop MyHDL
> training material along these lines.
>
> Jan
>
>>
>>

I agree with you both as well.  I will not be contributing to training 
efforts that are not open-source and more specifically efforts that are 
not under a LGPL type license.

I apologize, I never asked for or intended any public mailing-list / 
newsgroup to be an avenue to advertise a commercial product.

If it is not know, for full disclosure, I have an interest in 
DSPtronics.  I provide design consulting for the boards.  I have very 
little to no involvement with the sales and manufacturing of the boards. 
  I am happy to forward or answer questions.  Anyone looking at a 
development boards should look at the many different types and decide 
which board is appropriate for them.  I hope the users of this group to 
remain development board agnostic.

Chris Felton

Re: [myhdl-list] Floating Point Libraries

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

On 15/04/11 08:56, Jan Decaluwe wrote:
    . . .
> My workaround proposal was intended for those who want to
> get started today, including conversion support.
> To be honest, usage can hardly be worse than using
> ip libraries such as altera. Thinking futher about it,
> I'm not even sure the altera ip is about efficiency -
> it may just be about obfuscation and vendor lock-in.

The Altera libraries are 32/64 bit, with options on both for 7/15 
cycle latencies, new result every clock cycle(?) - see:
   http://www.altera.com/literature/ug/ug_altfp_mfug.pdf

> In other words, if floating point ip is hot, there
> may be an opportunity here for someone who would like
> to develop a technology-independent MyHDL libary.

Is there any interest in 'digit-serial' techniques. These are 5-50 
times slower by design, but use a much narrower connecting buss. 
The performance loss may be recouped if the design can be 
paralelised sufficiently, and may result in reduction of chip area 
used overall.

Jan Coombs

Re: [myhdl-list] Floating Point Libraries

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

On 04/14/2011 07:00 PM, Tom Dillon wrote:
> some comments below:
>
> On 04/14/2011 08:32 AM, Christopher Felton wrote:
>>
>> At the risk of embarrassing myself but to keep this thread going I
>> will start a FP interface based on Jan D and Tom D. suggestions.
>> Something like the following could be a start to an interface
>> definition.
>>
>> class FloatingPoint(object):
>>
>> def __init__(self): pass
>>
>> def Add(self, clk, reset, a_sign, a_mant, a_exp, dva, b_sign,
>> b_mant, b_exp, dvb, r_sign, r_mant, r_exp, dvr, EXP_W=8,
>> MAN_W=23): pass
>>
>> def Mul(self, clk, reset, a_sign, a_mant, a_exp, dva, b_sign,
>> b_mant, b_exp, dvb, r_sign, r_mant, r_exp, dvr, EXP_W=8,
>> MAN_W=23): pass
>>
>> def Div(self, clk, reset, a_sign, a_mant, a_exp, dva, b_sign,
>> b_mant, b_exp, dvb, r_sign, r_mant, r_exp, dvr, EXP_W=8,
>> MAN_W=23): pass
>>
> I would recommend the class be the MyHDL representation of the number
> itself.
>
> I don't think there is any real benefit to the operators being in the
> class as they will just be called like function calls returning the
> MyHDL instances.
>
> So I see it as something like this:
>
> class fp(object) : __slots__ = ['sign', 'exp', 'man', '_expW',
> '_manW'] def __init__(self,initNum=0.0,expW=8,manW=23) : self._expW =
> expW self._manW = manW self.setvalue(initNum)
>
> Note the fp object would keep all information about the structure and
> widths.
>
> Then a Add module would look like this:
>
> def FpAdd(x,a,b,clk=None,reset=None,pipes=0) :
>
> x,a, and b being the required ports of type fp (could expand to other
> types (fixed point). Option ports and parameters follow. You will end
> up with more parameters before you are done.
>
> In floating point, something like an Add will have to have the option
> for pipelines to be very useful. You may also want options for
> multi-cycle operation to optimize the logic when they don't need to
> run at the full clock rate.
>
> The operators don't need to know the width of the operands. That will
> be determined by the i/o ports. You may want to allow mixed widths.
>
> You will like passing only the objects and not the sign, man and exp
> separately. You may also decide that you don't store the sign
> internally if that turned out to be more efficient. Keeping the sign
> in the mantissa.
>
> Now when this is done it will be cleaner to use but will present a
> problem with you get to conversion as the you won't be able to have
> an fp object in the ports list at the top level. That is where you
> will need a wrapper that breaks out and attaches the elements inside
> fp.
>
> I think that is much easier than having three times the ports for all
> module connections. You also increase your cross wiring chances.
>
> You can add a lot to the fp class that will make your life easier as
> well.

That is how I was thinking. I just don't know how
easy/feasible it will be to support such a class in conversion.
I recommend to experiment with such a class extensively
in modeling first, to see what we really want.

My workaround proposal was intended for those who want to
get started today, including conversion support.
To be honest, usage can hardly be worse than using
ip libraries such as altera. Thinking futher about it,
I'm not even sure the altera ip is about efficiency -
it may just be about obfuscation and vendor lock-in.

In other words, if floating point ip is hot, there
may be an opportunity here for someone who would like
to develop a technology-independent MyHDL libary.

For clarity: it is not my intention to include design IP
libaries ever in MyHDL itself. Those should be different
(potentially competing) libraries, with an appropriate
license, as decided by the project.

Jan

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