myhdl-list

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

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

Christopher L.Felton wrote:

> When we have changes like this, do you want them emailed to you only or 
> copied to the mailing list as well?

I have written a page about how to contribute patches:

http://myhdl.jandecaluwe.com/doku.php/dev:patches

Please review it, it answers your questions and has some additional
relevant info.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Christopher L. F. <cf...@uc...>]

>
>
>> This should be a benign change because the previous code simply  
>> tested
>> "if obj".  Again the numpy array errors in this test.  Explicitly
>> testing that obj is not None, "obj != None" prevented the error.
>
> ... though I think the idiomatic test should be 'obj is not None'.

Thanks for the hg information!  So I created another bundle that used  
the test "obj is not None" as you pointed out.  And includes the  
makefile.  Ran the tests again.

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Christopher L. F. <cf...@uc...>]

I missed the earlier discussion, but my opinion the wrap is used very  
often in DSP applications.  Any time you use an integrator (CIC, loop  
filters, etc) you frequently take advantage of the wrap.  Even FIR  
filters will often use the wrap "feature".

Now with that said, you don' t have to use the wrap, the wrap buys  
another bit(s) of precision (or growth) without adding the additional  
bit(s).  At the expense of an additional bit(s) you should be able to  
use the bounded intbv for the design, and the limits will be checked.

If you are using something like an integrator (or something that has  
one) on a very slow signal it will require more bits so it can be  
expensive this is usually where the wrap is used.  Any DC offset will  
cause problems in this case (integrator growth).

In the figure below (attached?) you can see for a pure integrator the  
gain vs. frequencies and can calculate the maximum bits required.  If  
the design can handle the additional bits it is probably worth while  
having it bounded in simulation, may find other issues etc.

Re: [myhdl-list] intbv.saturate, intbv.wrap

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

Christopher L. Felton wrote:
> I missed the earlier discussion, but my opinion the wrap is used very 
> often in DSP applications.  Any time you use an integrator (CIC, loop 
> filters, etc) you frequently take advantage of the wrap.  Even FIR 
> filters will often use the wrap "feature".

I suspect those DSP algorithms are not specified in Verilog/VHDL.
It wouldn't be surprizing if the specs used modulo operations -
the high-level version of a wrap. We could do this in MyHDL also,
even at the RTL level. (I have often done this in VHDL.)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Christopher L. F. <cf...@uc...>]

Correct the DSP spec would not be in Verilog/VHDL nor would it specify  
a modulus.  The spec would call for some kind of filter or something.   
As in this discussion if the filter incorporates an integrator it  
could accumulate to infinity.  Since it can't go to infinity it needs  
some limits or be allowed to wrap.

DSP you are dealing with a frequency so the integrator will grow then  
shrink, it has a frequency response.  In most cases for a "wrap" it is  
not a modulus operation, but an intended overflow.  The accumulation  
register would be allowed to overflow with the intent that it will  
underflow (back to where you started) when you start subtracting the  
negative portion of the signal, then go back to zero.

I may be missing the point but I don't think the modulus helps in this  
case?  The wrap is intended to go positive -> negative -> positive.   
In the real algorithm it should stay positive (infinite gain).  It  
will be the implementations job to meet the spec and determine the  
number of bits required.  But people will exploit the wrap property to  
get away with less bits.  This is for the signed case (common DSP  
implementation).  Unsigned modulus would be equivalent.

I went back and read the previous posts, I agree with the conclusion  
from that discussion.  You can design for a worst case maximum and  
minimum.  Then you don't need the wrap function, it may take more bits  
but should be a more stable design.  I can't think of a reason why the  
CIC filter would require a wrap.

On Jun 28, 2008, at 2:12 PM, Jan Decaluwe wrote:

> Christopher L. Felton wrote:
>> I missed the earlier discussion, but my opinion the wrap is used very
>> often in DSP applications.  Any time you use an integrator (CIC, loop
>> filters, etc) you frequently take advantage of the wrap.  Even FIR
>> filters will often use the wrap "feature".
>
> I suspect those DSP algorithms are not specified in Verilog/VHDL.
> It wouldn't be surprizing if the specs used modulo operations -
> the high-level version of a wrap. We could do this in MyHDL also,
> even at the RTL level. (I have often done this in VHDL.)
>
> Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Blubaugh, D. A. <dbl...@be...>]

That sounds exactly as to what I will need for the multidimensional FFT problem that I currently tasked with at this time.   I was also wondering, if MyHDL can handle multidimensional arrays within Python that will be generated into Verilog?  
 
 
Thanks,
 
 
David Blubaugh

________________________________

From: myh...@li... on behalf of Jan Decaluwe
Sent: Sat 6/28/2008 4:12 PM
To: myh...@li...
Subject: Re: [myhdl-list] intbv.saturate, intbv.wrap



Christopher L. Felton wrote:
> I missed the earlier discussion, but my opinion the wrap is used very
> often in DSP applications.  Any time you use an integrator (CIC, loop
> filters, etc) you frequently take advantage of the wrap.  Even FIR
> filters will often use the wrap "feature".

I suspect those DSP algorithms are not specified in Verilog/VHDL.
It wouldn't be surprizing if the specs used modulo operations -
the high-level version of a wrap. We could do this in MyHDL also,
even at the RTL level. (I have often done this in VHDL.)

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com <http://www.jandecaluwe.com/> 
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com <http://myhdl.jandecaluwe.com/> 


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you receive 
this e-mail in error, please do not read, copy or disseminate it in any manner. 
If you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.

Re: [myhdl-list] intbv.saturate, intbv.wrap

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

Blubaugh, David A. wrote:
> That sounds exactly as to what I will need for the multidimensional FFT problem that I currently tasked with at this time.   I was also wondering, if MyHDL can handle multidimensional arrays within Python that will be generated into Verilog?  

David,

You should find an answer to your question in this section of the 
manual, describing the conversion to Verilog:

http://www.jandecaluwe.com/Tools/MyHDL/manual/conv.html

To quote from it:

 > 6.3.2 The structural description can be arbitrarily complex and
 > hierarchical

 > As the conversion works on an elaborated design instance, any modeling
 > constraints only apply to the leaf elements of the design structure,
 > that is, the co-operating generators. In other words, there are no
 > restrictions on the description of the design structure: Python's full
 > power can be used for that purpose. Also, the design hierarchy can be
 > arbitrarily deep.


That sounds like a big yes to you question.

Cheers,

Guenter

Re: [myhdl-list] multidimensional arrays

[Thomas T. <tho...@de...>]

David wrote:

> I was also wondering, if MyHDL can handle multidimensional arrays
> within Python that will be generated into Verilog?  

I am afraid it is not possible directly.
Below is a short test piece. It works for one dimensional arrays but not
for twodimensional.
So for your multidimensional FFT you have to use an big array and deal
with the pointers correspondingly, e.g. 

globalptr =  ptr + array_no * array_size. 

That should be no problem, especially if your array sizes are 2**N. Then
you can use bitshift for the multiplication.


-----------

from myhdl import *

def Arraytest():

    a = [[Signal(intbv(i*j)[8:]) for i in range(16)] for j in range(16)]
    #a = [Signal(intbv(i)[8:]) for i in range(16)] 

    #@always(a[0])
    @always(a[0][0])
    def printer():
        print a

    return printer

arraytest = Arraytest()

toVerilog(Arraytest)

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Blubaugh, D. A. <dbl...@be...>]

Will there eventually be a 32 or 64-bit version of intbv?  



Thanks,


David Blubaugh



 

-----Original Message-----
From: myh...@li...
[mailto:myh...@li...] On Behalf Of Thomas
Traber
Sent: Thursday, July 03, 2008 3:56 AM
To: General discussions on MyHDL
Subject: Re: [myhdl-list] intbv.saturate, intbv.wrap

> Why can't you use modulo operations ('%')

I can use it.
As conversion of modulo to Verilog works, I could skip the
__debug__/__verilog__ clause  - in the hope that the compiler optimizes
the modulo operation out (not tested yet).

Christopher's hint at putting the comb before the integrator could also
be useful. But with large decimation rates the delay for this first comb
grows large too.




Thomas


------------------------------------------------------------------------
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you receive 
this e-mail in error, please do not read, copy or disseminate it in any manner. 
If you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Thomas T. <tho...@de...>]

David wrote:
> Will there eventually be a 32 or 64-bit version of intbv?  

It is already there:

>a = intbv(2**32-1)[32:]

>a
   = intbv(4294967295L)

>a = intbv(2**64-1)[64:]

>a
   = intbv(18446744073709551615L)


BTW: I overlooked the mails comming in last weekend, sorry.
I will respond to it this weekend.


Thomas