Accumulator in IP and RTL timing errors

[Altera_Forum]

Hello, I've implemented accumulator that computes the sum of 19-bit incoming data samples magnitudes for particular period of time to 33-bit bus. 

I use RTL: always @ (posedge clk)  if (frame)  accum <= 33’h0;  else  accum <= accum + magnitude;  The functional simulation works fine but the in Quartus I got -14 ns timing error for setup time. I target Arria5. The clock rate is 122 MHz. I also tried to implement the same function using ALTERA_MULT_ADD IP and got even worse timing error: -20 ns instead of -14 ns. What Altera IP I should use to be able to meet timing? Thanks, Mike

[Altera_Forum]

Timing error(s) on what path? 

Where do the inputs 'frame' and 'magnitude' come from (another register or device input pins)? Will make a big difference on timing.

[Altera_Forum]

--- Quote Start ---  Timing error(s) on what path? Where do the inputs 'frame' and 'magnitude' come from (another register or device input pins)? Will make a big difference on timing.  --- Quote End ---   The inputs frame and magnitude come from other registers. The TimeQuest reports setup error between particular MSB of the inputs and outputs of the accumulator. Correction: The TimeQuest errors are from all bits of the accumulator input and MSB of the accumulator output. Another correction: The magnitude comes from the output of the ALTSQRT IP.

[Altera_Forum]

Are the registers for 'frame' and 'magnitude' operating in the exact same clock domain (ie, clocked from @(posedge clk) )? 

Is the output port of ALTSQRT that 'magnitude' comes from registered on @(posedge clk) ?  A 122MHz clock rate is a period of 8.2ns. A 14ns setup error says that the clock period needs to be 22.2ns minimum, or about 45MHz Fmax. I would try registering the output of ALTSQRT into 'magnitude' on @(posedge clk) just to see how that works. You don't explicitly say the width of 'accum' but I am inferring it is 33 bits. I would think that device can do a 33b add in 8.2ns or less.

[Altera_Forum]

--- Quote Start ---  Are the registers for 'frame' and 'magnitude' operating in the exact same clock domain (ie, clocked from @(posedge clk) )? Is the output port of ALTSQRT that 'magnitude' comes from registered on @(posedge clk) ?  A 122MHz clock rate is a period of 8.2ns. A 14ns setup error says that the clock period needs to be 22.2ns minimum, or about 45MHz Fmax. I would try registering the output of ALTSQRT into 'magnitude' on @(posedge clk) just to see how that works. You don't explicitly say the width of 'accum' but I am inferring it is 33 bits. I would think that device can do a 33b add in 8.2ns or less.  --- Quote End ---     All signals including frame, magnitude, ALTSQRT inputs, outputs operate in the same clock domain, 122.88 MHz. The ALTSQRT IP output is the magnitude signal. The magnitude signal is the input of this always statement:  always @ (posedge clk) if (frame) accum <= 33’h0; else accum <= accum + magnitude;  The magnitude width is 19 bits. The accum width is 33 bits. The frame signal is asserted every second clock cycle. The data rate is 61.44 Msps. The new sample comes from ALTSQRT IP every ~16.4 ns. I don't register output of the ALTSQRT IP. I will try it. Thanks, Mike

[Altera_Forum]

you can also apply a setup multicycle of 2 (hold of 1) to paths fom sqrt to accum and from accum to accum(as it is under frame enable)

[Altera_Forum]

--- Quote Start ---  Are the registers for 'frame' and 'magnitude' operating in the exact same clock domain (ie, clocked from @(posedge clk) )? Is the output port of ALTSQRT that 'magnitude' comes from registered on @(posedge clk) ?  A 122MHz clock rate is a period of 8.2ns. A 14ns setup error says that the clock period needs to be 22.2ns minimum, or about 45MHz Fmax. I would try registering the output of ALTSQRT into 'magnitude' on @(posedge clk) just to see how that works. You don't explicitly say the width of 'accum' but I am inferring it is 33 bits. I would think that device can do a 33b add in 8.2ns or less.  --- Quote End ---     I tried to pipeline outputs from the ALTSQRT and from the accumulator itself. It did not help. I also tried to replace my RTL accumulator with ALTERA_MULT_ADD IP and got even larger timing error, -20 ns instead of -14 ns.

[Altera_Forum]

--- Quote Start ---  you can also apply a setup multicycle of 2 (hold of 1) to paths fom sqrt to accum and from accum to accum(as it is under frame enable)  --- Quote End ---    I've tried it. It still give me the same -14 ns error at the accumulator output.

[Altera_Forum]

--- Quote Start ---  I've tried it. It still give me the same -14 ns error at the accumulator output.  --- Quote End ---    That can't be right. You have either applied multicycle to another path or your constraint is ignored.

[Altera_Forum]

Agreed. If we take the setup error of -14ns as being correct (ie, the logic path you have really does take 8.2ns+14ns = 22.2ns) then having FRAME asserted every other clock is still not sufficient. It takes a minimum of three clock cycles (ie, 3x8.2ns = 24.6ns > 22.2ns) to compute and have a positive setup time (24.6-22.2 = +2.4ns).