Re: corgen cic = terrible efficiency?
- From: "cpope" <cepope@xxxxxxxxx>
- Date: Mon, 25 Jun 2007 12:31:11 -0400
"comp.arch.fpga" <ksulimma@xxxxxxxxxxxxxx> wrote in message
news:1182783858.357110.273650@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 23 Jun., 19:30, "cpope" <cep...@xxxxxxxxx> wrote:implement as
3. If the cic is just a box car filter wouldn't it be easier to
thea single subtractor/accumulator whose inputs are the current sample and
shouldsample delayed by R? At least for reasonable R (< 8192) seems like it
fit in block ram okay.
It's all here:
http://www.phptr.com/articles/article.asp?p=361985&rl=1
If you sum up R values, you have a gain of R, independently of your
implementation.
If you do that k times, you have a gain of R^k.
The CIC implementation has exactly the same cost as the boxcar minus
the RAM.
So indeed, if you can afford the RAM you can use the boxcar.
Kolja Sulimma
Thanks, I had a colleague forward me to a similar article that included
information on how to trim the bits between the integrator sectrions. I
guess my point with the ram is in V4 the bram and dsp48 are designed to be
efficiently integrated so it might be possible to just implement a cascade
of N boxcar filters using just N dsp48/BRAM pairs rather than doing the very
high bitwidth integrators in the fabric. Should be lower power and run
faster.
-Clark
.
- References:
- corgen cic = terrible efficiency?
- From: cpope
- Re: corgen cic = terrible efficiency?
- From: comp.arch.fpga
- corgen cic = terrible efficiency?
- Prev by Date: Re: Multidimensional Register in Modul Port List
- Next by Date: Interfacing expansion ports thru EDK
- Previous by thread: Re: corgen cic = terrible efficiency?
- Next by thread: Re: corgen cic = terrible efficiency?
- Index(es):
Relevant Pages
|
Loading
