TimeQuest Timing issue

It means your design will not operate correctly at 250 MHz due to timing violations. It will work only up to 117 MHz.

You need to find the paths which are failing timing and try to improve your design.

rbugalho,

The following is my testing code, which is a very simple one. The function is to do the accumulation of several input data and return the upper 16bit result. Why it fails at 250MHz clock? Cyclone VE should be way fast than that speed. I am a green-hand in using the TimeQuest Time Analyzer. It will be very thankful if you can help me through.

**********************************************************************************

module average

(clock,

reset,

datain,

add_enable,

g_value,

dataout,

data_ready

);

input clock;

input reset;

input [15:0] datain;

input add_enable;

input [15:0] g_value;

output reg [15:0] dataout;

output reg data_ready;

reg [31:0] adder;

reg [7:0] add_counter;

always @ (posedge clock, posedge reset)

begin

if (reset)

begin

adder <= 32'b0;

data_ready <= 1'b0;

end

else

begin

if (add_enable)

begin

data_ready <= 1'b0;

adder <= adder + {16'b0,datain};

end

else

begin

dataout <= adder[31:16];

adder <= 32'b0;

data_ready <= 1'b1;

end

end

end

endmodule

yyt2002arc,

No clue. The adder can easily meet 250 MHz.

Can you post your .sdc file as well?

The comments asking if you told quartus the frequency of 'clock' with an sdc file are, of course, spot on. If you don't tell quartus that 'clock' runs at 200MHz it may not put in the effort needed to fit your design's fmax.

Another thing to consider is that if your design is synthesized as the top-most entity, quartus will assign random pins to the inputs and outputs. It's possible they are far enough apart that the propagation delay impacts your timing results.

Try inserting an additional register before all of your inputs and outputs.