Timing Analysis in FPGA

Hello All,

I have written a code for gray to binary conversion in verilog using Xillinx XST and also checked the output on FPGA (Spartan 3E).Now I want to perform the timing analysis for the same.I need help here how to get it started ,things are completely new to me.


Thanks

what time analysis you want to do exactly? you want to know the longest path?

I think you want to find the maximum freq that your design can work at. This will be defined by the longest path of your computational logic.
You should first define the clock frequency you have in your board and assign this to the input clk pin. Then define the clock generated from the PLL (if you have one).
After you run the compilation flow, you read the reports to know the longest path and the max frequency that your design can work at.
Timing analysis is a very large topic. What I just told you is a very small topic. You should read more tutorials about this.

This is not a clear scenario to me.
You said you've already check on FPGA. So what was that check ? FPGA hardware output, or just verilog simulation ?
If it was hardware/board check with correct result, your timing have been MET.

If you want to confirm something else, please post "exactly" what it is.

Like Sheriff said, you specify the clock frequency and compile the design. It shall generate reports based on post fit netlist. This shall contain the setup slack, hold slack, and the max frequency that your design can run at. Please note that all such data is "worst case" i.e in practice most FPGA parts you buy from a production batch will not have these numbers, but in a batch some may have the "worst case" properties.

For any nontrivial design digital design, there will be registers inside it. It is usually important (unless design is explicitly done in a different way) that the data from launch register to latch register takes less than a clock period. The path that takes the longest time to traverse between two registers shall be the "critical path" and this shall limit your design max frequency. Since if the design is run beyond this max frequency, the data will alteast not be able to be latched within 1 clock period after being launched in this 1 path; and as you know, that may be enough to cause the design to fail.

- - - Updated - - -

What you are looking for is called Static Timing Analysis and is done on the basis of the design, the delay it takes for data to traverse from one register to another in each single register-register path. It does not consider any specific input stimulus.

matrixofdynamism said:

.... Please note that all such data is "worst case" i.e in practice most FPGA parts you buy from a production batch will not have these numbers, but in a batch some may have the "worst case" properties.

Click to expand...

That only covers the P (process) in the worst case PVT. The other two Voltage and Temperature can be controlled by the user. I've heard from others where designs were found to sometimes work or not work depending on very small changes to a design due to the core supply V being at some mV below the minimum allowed voltage. Fixing the V of the supply fixed the problem. The problem appeared to be an issue with setup violations as the problem would get worse as the T increased.

Thanks sir ,for the getting me started ,I have implemented the design on Xillinx it shows the worst case time slack is 18.08ns and it can be improved to the 1.08 ns so for that is it necessary to get the fundamentals of Static timing analysis be applied here??
and I have also changed the frequency of clock in the timing constraints editor earlier it was 20 ns .I changed it to 3.5 ns ,what are the things I should look into??

Thanks in advance

Ravindrakant Jha said:

Thanks sir ,for the getting me started ,I have implemented the design on Xillinx it shows the worst case time slack is 18.08ns and it can be improved to the 1.08 ns so for that is it necessary to get the fundamentals of Static timing analysis be applied here??
and I have also changed the frequency of clock in the timing constraints editor earlier it was 20 ns .I changed it to 3.5 ns ,what are the things I should look into??

Thanks in advance

Click to expand...

Static Timing Analysis give you the judgement for timing result based on a constraint which you have applied.
So, it can be applied anytime you want. But it has no optimization to make timing better.
The optimization is in Xilinx Tool engine.

About clock period changing from 20ns to 3.5ns, that is a big deal.
The stricter the constraint ( clock is faster ) the harder the tool engine work.
But it has limitation, then, you should check the new STA to see if the timing result is OK or NOT GOOD.

Whenever I head "gray code" I immediately think of "clock domain crossing".

If this is intended for clock-domain-crossing, the timing constraints would be different.