Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
2,598 Views

Accumulator in IP and RTL timing errors

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
0 Kudos
9 Replies
Altera_Forum
Honored Contributor I
36 Views

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
Honored Contributor I
36 Views

 

--- 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
Honored Contributor I
36 Views

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
Honored Contributor I
36 Views

 

--- 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
Honored Contributor I
36 Views

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
Honored Contributor I
36 Views

 

--- 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
Honored Contributor I
36 Views

 

--- 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
Honored Contributor I
36 Views

 

--- 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
Honored Contributor I
36 Views

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).

Reply