corgen cic = terrible efficiency?

If they are truely thrown away, it shouldn't be the cause of why you aren't fitting into the device.

Why do you need DSP48s? Isn't the whole point of a CIC that it doesn't use multiplies?

Aren't all the integrators cascaded together, then followed by all the combs?

Cheers, Jon

It's all here:

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

implement as

the

should

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

is

thrown

I throw them away at the output, I'm not convinced that the compiler trims them all the way back through the integrators. In fact I'm pretty sure it doesn't because I found a colleague that had to implement his own CIC that uses significantly less resources then the coregen block because he was able to trim the widths of the integrator sections.

compiling

CICs?

I have them available. Should be less power and faster speed than implementing a 48 bit accumulator in slices right?

the

so

Yes. My point is the width of the integrators and combs don't seem to be optimized at all. For example, If I'm only using 16 bits at the output why would the combs need to be more than say 16+N*2 wide? My coregen sets them at 66. Similarly, the first integrator should only need input width plus log2(R) width, the second needs input width + 2*log2(R) and so on. And that's only if you really need full precision which I suspect you don't. At any rate the coregen doesn't seem to employ any of these optimizations?

The coregen doesn't support V4 simply because no one has re-written it to instantiate the DSP48s instead of LUTs. You should be able to use a V2 LUT version in V4 though, although it will not be all that fast because the carry chains in V4 are fairly slow compared to the DSP48's. The DSP48 limits the CIC width to 48 bits without going through some design gymnastics to cascade DSP48's. For a CIC, 48 bits isn't very much.

The CIC's response is a sinc function, which provides only about 13dB attenuation of the first sidelobe for a first order filter. In order to increase the effectiveness of the filter, several sections are cascaded to increase the attenuation of the sidelobes. You typically need 4th or

5th order filters for practical applications. The gain of the CIC filter is (N*R)^M where N is the delay in the comb section (usually 1), R is the decimation ratio, and M is the order of the filter. The width of the integrators must accommodate the input signal times the gain without overflow. Unfortunately, because the filter relies on differences of an integration, the integration has to be full precision so that rounding errors do not get accumulated in the integrators. The result is that the integrators cannot be truncated, and they have to have enough bits to represent the maximum input times the gain of the filter. You can reduce the word width between the integrator and comb sections by simple truncation so that the comb section only has to be M bits wider than the output (and can taper down one bit per stage as it progresses to the output). Rounding isn't necessary if the width is reduced before the comb sections because the difference operation of the comb removes the bias anyway.

A first order CIC is equivalent to an N*R stage boxcar filter. To get the response of a 5th order CIC, you'd have to cascade 5 such filters together, and you can't decimate until after the last stage. The adder and subtractor still has to be wide enough to accommodate the gain of the filter (N*R) at each stage. Like the CIC, you can reduce the width of the subtractor, but the integrator has to be wide enough to accommodate the max signal times N without overflow. You wind up with adders that are only log2(N) bits wider than the input if you truncate between stages instead of M*log2(N), but you also wind up with a memory for each stage as well.

If your CIC is decimating, you can take advantage of the lower rate through the comb section by using bit or digit serial arithmetic, or by sharing the comb section among multiple channels.

No, the integrators all have to have enough bits to hold the input times the gain. Keep in mind each one is keeping a running accumulation of its input, and the modular overflow has to be above the bits you are taking out of the bank. You cannot use fewer MSBs on the first integrators because the CIC takes advantage of the modular property of the 2's complement system and doing so puts the modular overflow in the bit field you are taking out.

The 66 bit width coregen is using should be a result of the gain calculated for the maximum decimation ratio and order of your filter. For a 4th order filter with 10 bits input, that means it is set up for decimation ratios upto 2^14. If you can reduce the maximum decimation ratio, it should reduce the width of the integrators.

Yes, implementing using the DSP48s is faster than using straight fabric adders. Most CIC's need more than 48 bits, so you have to cascade them. The comb section isn't as bad because you can reduce the width before the comb.

I'm not sure that's true. At least this reference (and a colleagues optimized design implies they can be trimmed):

see 11.4.2

-Clark

is

thrown

compiling

CICs?

the

so

implement as

the

should

It is for a boxcar filter though, right? If I just implement a straight box car I need log2R+B+1 bits in the accumulator. The max log2R in coregen is 14 so that leaves data sizes up to 34 bits.

I think the integrators can be trimmed (see other response). Agree about the comb but it doesn't seem to me that xilinx is doing that optimization. In fact I don't know that it could for a CIC that supports multiple decimation rates.

Yes, but I have plenty of brams and dsp48s, I'm short on slices. Plus I want to minimize power consumption.

I'm not convinced xilinx even does this optimization.

I assumed the OP is asking about a decimating CIC, in which case my assertion is absolutely true. The article you cited also says the same thing: "In a down-sampling filter the growth appears immediately in the first integrator stage, and all subsequent integrators and comb filters must honor the most significant bit of the first integrator stage."

It is possible he was asking about an interpolating (up-sampling) CIC, in which case the math is a little bit different, and as a result there are differences in how pruning can be applied.

I'm the OP. That article says the LSBs can be trimmed in the decimating case, right?

In the comb section, and in certain cases on the last integrator sections at the price of increased noise.

The variable R CIC can still drop LSBs between the integrator and comb sections by adding a shifter controlled by the decimation ratio between the stages so that you always keep the N most significant bits for that decimation ratio.