This memo documents and distributes a 2nd order Cascaded Intergrator Comb (CIC) decimation filter implemented in a 16 bit datapath (also called a Sinc^2 decimator). The decimator supports decimation rates as low as 2 and as high as 128, producing effective resolutions of up to 10.5 bits when used with a first order Delta Sigma modulator and raw results as large as +/- 16,384, the equivalent of a signed 15 bit number at a decimation rate of 128. The decimator requires a maximum of 8 clock cycles to complete a calculation, requiring a clock 8 times faster than the modulator clock. When combined with the SC/CT modulator at the maximum modulator clock rate of 4 Mhz, the decimator requires a 32 Mhz clock, resulting in an output sample rate from 363 Ksps with 5 bits of effective resolution, down to 31 Ksps with 10 bits of effective resolution. The decimator component includes a DMA capability file for simplifying the use of DMA with the decimator. Start() is the only API required to use the decimator.
This component is not "complete" since it lacks an official datasheet, but I am not sure when I get around to writing that so I decided to publish this "As is" since something is better than nothing. The zip file include lots of info on how I made the component, as well as something that will pass as a rudimentary datasheet. The zip file also includes the component in a .cycomp archive, an example project bundle, a scan of the UDB datapath instructions and the python simulation.
Cool! This pairs nicely with these isolated Sigma-Delta-Modulators I have here. There are not so many corresponding digital filters available. Any MCU is to slow to handle this in software (at least at 10MHz speed), and it normally needs a FPGA to be handled in hardware (or a really large CPLD). Hats off to you!
Without looking at the implementation: how difficult would it be to extend this to a higher resolution (at the cost of a slower sample rate)?
On a difficulty scale, not too difficult (all the hard work was figuring out how to actually do it in the UDB) although for decimation rates above 128, I would need an external counter. As always, it boils down to time. I included lots of information in the zip file on how I achieved it, so an adenventerous PSoC 3/5 user could theoretically figure it out.
I just did look at the Verilog file, and from there it was not obvious how to increase the resolution. But using the Counter7 seems sensible - I should have thought of that when reading about the decimation rate of 128...
I think when using an external counter, the decimator might need more than 8 clock cycles for each calculation. For my use case even the 8 clock cylces of now are a little problem, since the AMC1203 I'm using (the link in my previous post has gone wrong, it should have been http://www.ti.com/product/amc1203 ) uses a clock rate of 10MHz which is too fast your component. I think I might just trick it and divide the clock by two...
yeah, a 10 Mhz, 3rd order 24 bit CIC decimator is going to be a stretch in the UDBs, or even the DFB. : )
Fortunately I don't need such a high resolution. About 14bit would be sufficient, and I also don't need a high sample rate (the interesting bit is to have isolation). I will give it a try soon.
14 effective bits for a 2nd order modulator and a 3rd order decimator requires a decimation rate of ~64 (48 really, but I like powers of 2) which requires a CIC decimator capable of dealing with 1+3*log2(64) = 19 bits. This is where I got "24 bits" in the decimator since it has to be able to keep track of 19 bits at a minumum, and since we only get multiples of 8 bits per datapath, you need a 24 bit datapath to make a decimator capable of handling what you need : )
Your situation wont be quite as bad as 10.5 bits of effective resolution since that assumes a first order modulator, you will actually see something higher for the same decimation rate withthe second order modulator (2 bits for every doubling of the OSR rather than the 1.5 bits for the first order modulator / second order decimator) You will actually see something closer to 12 bits of effective resolution at a decimation rate of 128.
aaaaaand, if speed really isn't a concern, then I can suggest the DFB as a possible choice, although the hardware input signals are a bit of a pain to use.
Until now I didn't dare to use the DFB - and I still think it's way about may head to do something like such a filter with it. But I will have a deeper look at your explanations, and compare it with the explanation TI delivers for the AMC1203 (there is an app note explaining the Sinc3 filter and its implementation in an FPGA - looks like in the PSoC it would need 15 UDBs...).
But I have a much simpler idea: since I don't really need a high sample rate, I could just count the pulses. When I wait for 65536 pulses of the clock signal, and count each time I encounter a '1' on the data line, I should get a proper result. (the resolution won't be 16bit though since the AMC1203 only uses the range from 12.5% up to 87.5%, so there never are all ones or all zeros). This gives me still 152 samples per second, and it should be dead simple to implement... (but it isn't as cool as your decimator of cource 🙂