myhdl-list — Mailing list for discussions on MyHDL

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

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

Yes, the fix is needed for the added wiki page.  But I have not posted 
the code that is dependent on the fix, yet.

Thanks for the procedure, sounds good and will do.  I am not familiar 
(yet) with mercurial, I will acquaint myself with the tool.

Sounds like Thomas has taken care of this issue (diff, etc?).

I have seen this issue/error before as well, when the following 
conditional is used in the code

in (posedge, negedge)

  


On Mon, 21 Jul 2008 22:38:04 +0200
  Jan Decaluwe <ja...@ja...> wrote:
> Christopher L.Felton wrote:
>> Yes, definitely a more general approach was needed.  That looks like 
>>a  
>> good solution.
> 
> Is this patch needed for you new webpage to work? In that case it
> should probably be included in the codebase. The procedure that
> minimizes my work is as follows :-):
> 
> * describe shortly why the patch is needed, what it does
> * discuss shortly why it won't break forseeable things
> * as a minimum, run test/core to check nothing breaks
> * use mercurial to commit and use "hg bundle" to generate a
>   patch file to send me
> 
> The last step makes it really easy for me to apply and check
> the patch. Moreover, it preserves the patch author, so you
> get eternal credit for your work :-)
> 
> Jan
> 
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>challenge
> Build the coolest Linux based applications with Moblin SDK & win 
>great prizes
> Grand prize is a trip for two to an Open Source event anywhere in 
>the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

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

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

Christopher L.Felton wrote:
> Yes, definitely a more general approach was needed.  That looks like a  
> good solution.

Is this patch needed for you new webpage to work? In that case it
should probably be included in the codebase. The procedure that
minimizes my work is as follows :-):

* describe shortly why the patch is needed, what it does
* discuss shortly why it won't break forseeable things
* as a minimum, run test/core to check nothing breaks
* use mercurial to commit and use "hg bundle" to generate a
   patch file to send me

The last step makes it really easy for me to apply and check
the patch. Moreover, it preserves the patch author, so you
get eternal credit for your work :-)

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

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

Christopher L.Felton wrote:
> I started (WIP) a wiki page for this, it is more convenient for  
> outlining code and displaying plots than the newsgroup, http://myhdl.jandecaluwe.com/doku.php/projects:gcicexample?do=backlink 

Thanks - I have added sidebar navigation for this. BTW, this
is done simply through a wiki page called 'sidebar' in a
certain namespace.

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

Yes, definitely a more general approach was needed.  That looks like a  
good solution.

On Jul 17, 2008, at 2:56 AM, Thomas Traber wrote:

> I just started to look at Christophers script.
>
> At first:
>
> Instead of
>
>> if not isinstance(obj, list) and not isinstance(obj, numpy.ndarray):
>
> in his _Waiter.diff, I would prefer the more general approach:
>
>> if not hasattr(obj,"__iter__"):
>
> In the hope that it is not too general.
>
>
>
>
>
>
>
>
> < 
> _Waiter 
> .diff 
> > 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

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

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

I started (WIP) a wiki page for this, it is more convenient for  
outlining code and displaying plots than the newsgroup, http://myhdl.jandecaluwe.com/doku.php/projects:gcicexample?do=backlink 
.

Example is intended to illustrate parameterizable modules in MyHDL and  
designing the CIC for max gain (no integrator overflows).  Which  
requires more resources (bits and delay elements in the comb) but  
works good for higher order and no overflows.


On Jul 10, 2008, at 8:35 AM, Blubaugh, David A. wrote:

>
> Chris,
>
>
> Please tell us as to when you have finally generated Verilog or VHDL
> source code.  This sounds truly interesting to have NUMPY integrated
> with the MyHDL environment.
>
>
>
> David
>
>
>
>
>
>
>
> -----Original Message-----
> From: myh...@li...
> [mailto:myh...@li...] On Behalf Of
> Christopher L. Felton
> Sent: Thursday, July 10, 2008 8:36 AM
> To: General discussions on MyHDL
> Subject: Re: [myhdl-list] intbv.saturate, intbv.wrap
>
> Attached is an example of the CIC filter without using 2's compliment
> wrapping or modulus.  Adjusted the bitwidth for the maximum gain.  The
> plot attached is of the frequency response of the filter, green is
> averaged input spectrum and the blue is the averaged output spectrum.
> You can see that after scaling the response is expected for a D=5  
> (comb
> delay = 5) cic filter.  Only simulation thus far, haven't converted to
> Verilog or VHDL.
>
> Note, Because the comb filter is before the integrator (to help  
> control
> infinite gain of the integrator, hence no wrap) cannot take  
> advantage of
> inserting the decimation before the comb filter to reduced storage (#
> registers) for the comb.  this could be a draw backs (depending on how
> you look at it).
>
>
> Also, for this implementation I had to "hack" the MyHDL space.  This  
> is
> a complete hack (just temporary to do what I wanted to do).  Also
> attached are the diff's that I had to make to allow the numpy types in
> the generator (?).
>
>
> 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.
>
>
> -------------------------------------------------------------------------
> 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

[myhdl-list] Noob on the list

[Newell J. <pil...@gm...>]

Hi all,

A little bit about me:
I am new to the list but have been keeping a distant eye on myhdl for some
time.  I am currently a google summer of code participant working for the
gEDA project.  I am creating from scratch, a project manager that
incorporates all the different tools in the gEDA suite and puts them in one
place and also manages your project and all its files.  I am using Python
and PyGTK.

Jan, I saw that you are looking for a CMS for myhdl.org.  I am actually
currently in the process of creating my own blog using Django and Byteflow.
Byteflow is a blog engine that also shows up as a CMS on wikipediea.  I
think it has everything that you are looking for.

I hope to actually get used to myhdl more in the future so that I can use it
in some hardware designs as well as contribute to the project.

Cheers,

-- 
Newell

Before enlightenment, chop wood and carry water
After enlightenment, code and build circuits

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

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

I just started to look at Christophers script.

At first:

Instead of 

 > if not isinstance(obj, list) and not isinstance(obj, numpy.ndarray): 

in his _Waiter.diff, I would prefer the more general approach:

 > if not hasattr(obj,"__iter__"): 

In the hope that it is not too general.

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

[<cf...@ie...>]

The numpy is only used for analysis (plots etc), no numpy types are used for conversion to Verilog/VHDL. The CIC filter should convert to Verilog/VHDL just haven't got to it...

-----Original Message-----

From:  "Blubaugh, David A." <dbl...@be...>
Subj:  Re: [myhdl-list] intbv.saturate, intbv.wrap
Date:  Thu Jul 10, 2008 8:35 am
Size:  2K
To:  "General discussions on MyHDL" <myh...@li...>
cc:  "Christopher L. Felton" <cf...@ie...>

 
Chris,


Please tell us as to when you have finally generated Verilog or VHDL
source code.  This sounds truly interesting to have NUMPY integrated
with the MyHDL environment.  



David


  




-----Original Message-----
From: myh...@li...
[mailto:myh...@li...] On Behalf Of
Christopher L. Felton
Sent: Thursday, July 10, 2008 8:36 AM
To: General discussions on MyHDL
Subject: Re: [myhdl-list] intbv.saturate, intbv.wrap

Attached is an example of the CIC filter without using 2's compliment
wrapping or modulus.  Adjusted the bitwidth for the maximum gain.  The
plot attached is of the frequency response of the filter, green is  
averaged input spectrum and the blue is the averaged output spectrum.   
You can see that after scaling the response is expected for a D=5 (comb
delay = 5) cic filter.  Only simulation thus far, haven't converted to
Verilog or VHDL.

Note, Because the comb filter is before the integrator (to help control
infinite gain of the integrator, hence no wrap) cannot take advantage of
inserting the decimation before the comb filter to reduced storage (#
registers) for the comb.  this could be a draw backs (depending on how
you look at it).


Also, for this implementation I had to "hack" the MyHDL space.  This is
a complete hack (just temporary to do what I wanted to do).  Also
attached are the diff's that I had to make to allow the numpy types in
the generator (?).


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.


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


-------------------------------------
Christopher L. Felton
sent from mobile email
-------------------------------------

-------------------------------------
 mobile email
-------------------------------------

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

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

 
Chris,


Please tell us as to when you have finally generated Verilog or VHDL
source code.  This sounds truly interesting to have NUMPY integrated
with the MyHDL environment.  



David


  




-----Original Message-----
From: myh...@li...
[mailto:myh...@li...] On Behalf Of
Christopher L. Felton
Sent: Thursday, July 10, 2008 8:36 AM
To: General discussions on MyHDL
Subject: Re: [myhdl-list] intbv.saturate, intbv.wrap

Attached is an example of the CIC filter without using 2's compliment
wrapping or modulus.  Adjusted the bitwidth for the maximum gain.  The
plot attached is of the frequency response of the filter, green is  
averaged input spectrum and the blue is the averaged output spectrum.   
You can see that after scaling the response is expected for a D=5 (comb
delay = 5) cic filter.  Only simulation thus far, haven't converted to
Verilog or VHDL.

Note, Because the comb filter is before the integrator (to help control
infinite gain of the integrator, hence no wrap) cannot take advantage of
inserting the decimation before the comb filter to reduced storage (#
registers) for the comb.  this could be a draw backs (depending on how
you look at it).


Also, for this implementation I had to "hack" the MyHDL space.  This is
a complete hack (just temporary to do what I wanted to do).  Also
attached are the diff's that I had to make to allow the numpy types in
the generator (?).


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

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

Attached is an example of the CIC filter without using 2's compliment  
wrapping or modulus.  Adjusted the bitwidth for the maximum gain.  The  
plot attached is of the frequency response of the filter, green is  
averaged input spectrum and the blue is the averaged output spectrum.   
You can see that after scaling the response is expected for a D=5  
(comb delay = 5) cic filter.  Only simulation thus far, haven't  
converted to Verilog or VHDL.

Note, Because the comb filter is before the integrator (to help  
control infinite gain of the integrator, hence no wrap) cannot take  
advantage of inserting the decimation before the comb filter to  
reduced storage (# registers) for the comb.  this could be a draw  
backs (depending on how you look at it).


Also, for this implementation I had to "hack" the MyHDL space.  This  
is a complete hack (just temporary to do what I wanted to do).  Also  
attached are the diff's that I had to make to allow the numpy types in  
the generator (?).

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

[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

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

> 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

[myhdl-list] Sad news

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

Hi all:

Unfortunately I have some sad news.

Recently I have learned that George Pantazopoulos has died, already
more than a year ago. George made significant contributions to
the MyHDL project. I have added a page on the web site:

http://myhdl.jandecaluwe.com/doku.php/users:george_pantazopoulos:memory

Out of respect, I'd like to ask not to reply to this post here. You
can always contact me through private e-mail if you wish.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium

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

[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

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

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

Thomas Traber wrote:
> Picking up an rather old issue again:
> 
> 
> In the discussion about the missing wrap around behaviour of intbv I wrote:
> 
>> I agree with Tom. There is not much use of wrap around in a DSP 
>> application.
> 
> I have to withdraw this statement.
> 
> Just wanted to implement a CIC filter. For that the wrapping behaviour 
> is definitely needed.
> 
> I tried to modifiy myhdl. But, as Jan mentioned last year, this is not 
> an easy task.
> As there is no need to modify the conversion code I thought subclassing 
> would help, but I didn't get it to work  - yet.
> So, the only short time workaround is to use "__verilog__" and "__debug__".
> 
> Any suggestions?

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

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] website maintenance

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

Jan Decaluwe wrote:
> I need to do some maintenance to the MyHDL website.
> 
> It is temporarily set to read-only. Also, there may be
> some glitches and it may temporarily show an older
> version.

By now the website should be functional again.

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

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

Picking up an rather old issue again:


In the discussion about the missing wrap around behaviour of intbv I wrote:

> I agree with Tom. There is not much use of wrap around in a DSP 
> application.

I have to withdraw this statement.

Just wanted to implement a CIC filter. For that the wrapping behaviour 
is definitely needed.

I tried to modifiy myhdl. But, as Jan mentioned last year, this is not 
an easy task.
As there is no need to modify the conversion code I thought subclassing 
would help, but I didn't get it to work  - yet.
So, the only short time workaround is to use "__verilog__" and "__debug__".

Any suggestions?



BTW:
__slot__ (without __dict__) in _Signal.py and _intbv.py could be a 
considered good to prevent different behaviour of myhdl code and 
converted code. But I would suggest to allow new attributes and raising 
a warning at conversion time if there is something different.

Re: [myhdl-list] MyHDL Wiki Pages still outdated

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

Jan Decaluwe wrote:
> Thomas Traber wrote:
>> Jan, you mentioned that your are working on the wiki engine.
>> The wiki pages are still at an old revision.
>> Are you still working on it? Or are my changes from June lost?
> 
> Nothing is lost - I'm still working on it.

Update. First, be assured - nothing is lost :-)

The temporary issues arise because I have to address several
unexpected issues at the same time.

One is that I'm having problems with going from yahoo to
webfaction. When I started the transition, my yahoo web hosting
plan allowed to modify DNS settings. So, I could switch between
yahoo and webfaction smoothly and selectively (e.g. by
subdomain).

However, this has changed recently: when you have a yahoo
web hosting plan, you can no longer change DNS settings to
other IP addresses. The more you pay, the less flexiblity
you get :-)

So I had to downgrade my plan to be able to make the complete
transition. As a result, the web site may be disfunctional
for some time - it will come back!

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] MyHDL Wiki Pages still outdated

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

Thomas Traber wrote:
> Jan, you mentioned that your are working on the wiki engine.
> The wiki pages are still at an old revision.
> Are you still working on it? Or are my changes from June lost?

Nothing is lost - I'm still working on it.

Jan

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