Hi All I came across two Xilinx product documents on their CIC compiler 1) According to a Xilinx article "CIC compiler" 2012 Hf = (sin(pi*f*M)/sin(pi*f/R)).^N Hf = amplitude response at frequency f M = number of comb delay stages N = number of cascaded comb/integrator pairs R = rate change(up or down) 2) According to another Xilinx document on same "CIC compiler" 2014 Hf = (sin(pi*f*R*M)/sin(pi*f)).^N In each case the documents shows various examples of responses. Surely one is wrong, the other right or am I missing something? Your help appreciated Kaz I have asked this before but _____________________________ Posted through www.DSPRelated.com
CIC formulas again
Started by ●December 22, 2014
Reply by ●December 22, 20142014-12-22
apologies. Just found out that first equation is relative to slow domain while second equation is relative to fast domain (irrespective of R, interpolation or decimation) Kaz _____________________________ Posted through www.DSPRelated.com
Reply by ●December 23, 20142014-12-23
So as not to waste this thread on cic I have some other concerns. according to "CIC filter Introduction" by M.P.Donadio 18 Jul 2000 in connection with maximum bitwidth (Bout) required for decimator: " It also turn out that Bout bits are needed for each integrator and comb stage. The input needs to be sign extended to Bout bits, but LSB's can either be truncated or rounded at later stages. The analysis of this is beyond the scope of this tutorial, but is fully described in [Hog81]". Doesn't sound right to me. firstly: each comb only needs one extra bit for subtraction. secondly: why should I sign extend input when I can just use the available bitwidth, possibly outdated view. Any thoughts please? Kaz _____________________________ Posted through www.DSPRelated.com
Reply by ●December 25, 20142014-12-25
On Tuesday, December 23, 2014 5:26:05 PM UTC-8, kaz wrote:> ... > " ... but is fully described in [Hog81]". > > Doesn't sound right to me. > firstly: each comb only needs one extra bit for subtraction. > secondly: why should I sign extend input when I can just use the available > bitwidth, possibly outdated view. > Any thoughts please? > > KazHogenauer described it correctly in 1981. It hasn't changed. Read the paper from 1981 or simulate thoroughly with full scale signals. Dale B. Dalrymple
Reply by ●December 25, 20142014-12-25
On 12/25/2014 12:49 AM, dbd wrote:> On Tuesday, December 23, 2014 5:26:05 PM UTC-8, kaz wrote: >> ... >> " ... but is fully described in [Hog81]". >> >> Doesn't sound right to me. >> firstly: each comb only needs one extra bit for subtraction. >> secondly: why should I sign extend input when I can just use the available >> bitwidth, possibly outdated view. >> Any thoughts please? >> >> Kaz > > > Hogenauer described it correctly in 1981. It hasn't changed. Read the paper from 1981 or simulate thoroughly with full scale signals.I don't know why people feel a reply like this is useful. I think the OP can figure out what to read and what not to read. The Hogenauer paper is a terrible reference for someone learning the filter. If you don't wish to help, why not just leave the guy alone? -- Rick
Reply by ●December 25, 20142014-12-25
On Thu, 25 Dec 2014 01:19:26 -0500, rickman <gnuarm@gmail.com> wrote:>On 12/25/2014 12:49 AM, dbd wrote: >> On Tuesday, December 23, 2014 5:26:05 PM UTC-8, kaz wrote: >>> ... >>> " ... but is fully described in [Hog81]". >>> >>> Doesn't sound right to me. >>> firstly: each comb only needs one extra bit for subtraction. >>> secondly: why should I sign extend input when I can just use the available >>> bitwidth, possibly outdated view. >>> Any thoughts please? >>> >>> Kaz >> >> >> Hogenauer described it correctly in 1981. It hasn't changed. Read the paper from 1981 or simulate thoroughly with full scale signals. > >I don't know why people feel a reply like this is useful. I think the >OP can figure out what to read and what not to read.If that were always true they probably wouldn't be asking questions in the first place.> The Hogenauer >paper is a terrible reference for someone learning the filter.I never thought so. Everything is there.>If you don't wish to help, why not just leave the guy alone?I thought it was an appropriate response. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●December 25, 20142014-12-25
On Thu, 25 Dec 2014 01:19:26 -0500, rickman wrote:> On 12/25/2014 12:49 AM, dbd wrote: >> On Tuesday, December 23, 2014 5:26:05 PM UTC-8, kaz wrote: >>> ... >>> " ... but is fully described in [Hog81]". >>> >>> Doesn't sound right to me. >>> firstly: each comb only needs one extra bit for subtraction. >>> secondly: why should I sign extend input when I can just use the >>> available bitwidth, possibly outdated view. >>> Any thoughts please? >>> >>> Kaz >> >> >> Hogenauer described it correctly in 1981. It hasn't changed. Read the >> paper from 1981 or simulate thoroughly with full scale signals. > > I don't know why people feel a reply like this is useful. I think the > OP can figure out what to read and what not to read. The Hogenauer > paper is a terrible reference for someone learning the filter. > > If you don't wish to help, why not just leave the guy alone?If I didn't know anything about the subject, and was presented with a statement that I couldn't tell from BS, with a pointer to a paper that also may or may not be BS, then having Kaz point out that the paper was, in fact, correct, would, in fact, be extremely helpful. -- www.wescottdesign.com
Reply by ●December 25, 20142014-12-25
I think I put forward a simple question about comb bit growth. For interpolator each comb needs one extra bit per stage starting from input width (and the paper says that). That is pretty easy to imagine. For decimator it says "it turns out to be" each comb needs Bmax bits. . If each integrator is Bmax then I expect each comb to be wider by 1 extra bit though zero insertion drops it by 1 per each zero/sample. So I expect first comb to be Bmax minus log2(R) then add 1 per further comb stage till end. The other question of sign extension is trivial. Sign extension is the norm for any two's complement and need not be even mentioned in the paper. In FPGAs it is done internally and is not visible to designer except if using inference. Kaz _____________________________ Posted through www.DSPRelated.com
Reply by ●December 25, 20142014-12-25
Just corecting my usual confusion. zeros are not inserted for decimator. so comb bit growth should be 1 extra bit per stage above Bmax Kaz _____________________________ Posted through www.DSPRelated.com
Reply by ●December 25, 20142014-12-25
On 12/25/2014 11:05 AM, Eric Jacobsen wrote:> On Thu, 25 Dec 2014 01:19:26 -0500, rickman <gnuarm@gmail.com> wrote: > >> On 12/25/2014 12:49 AM, dbd wrote: >>> On Tuesday, December 23, 2014 5:26:05 PM UTC-8, kaz wrote: >>>> ... >>>> " ... but is fully described in [Hog81]". >>>> >>>> Doesn't sound right to me. >>>> firstly: each comb only needs one extra bit for subtraction. >>>> secondly: why should I sign extend input when I can just use the available >>>> bitwidth, possibly outdated view. >>>> Any thoughts please? >>>> >>>> Kaz >>> >>> >>> Hogenauer described it correctly in 1981. It hasn't changed. Read the paper from 1981 or simulate thoroughly with full scale signals. >> >> I don't know why people feel a reply like this is useful. I think the >> OP can figure out what to read and what not to read. > > If that were always true they probably wouldn't be asking questions in > the first place. > >> The Hogenauer >> paper is a terrible reference for someone learning the filter. > > I never thought so. Everything is there. > >> If you don't wish to help, why not just leave the guy alone? > > I thought it was an appropriate response.Yes, that doesn't surprise me. -- Rick
