Success! Subscription added.
Success! Subscription removed.
Sorry, you must verify to complete this action. Please click the verification link in your email. You may re-send via your profile.
Timequest is Altera's ASIC class static timing analysis tool.
December 28, 2011
User Created Timequest Users Guide: TimeQuest User Guide
Main Altera Timequest resource page http://www.altera.com/support/software/timequest/sof-qts-timequest.html
derive_pll_clocks (avoid using -use_tan_name)
When doing a memory interface, call derive_pll_clocks in and SDC file that is after the memories SDC file, order of the SDC files do matter. The DDR UniPHY .sdc puts generated clocks on the PLL outputs and uses names that don’t match the normal nomenclature. If you call derive_pll_clocks before the UniPHY's SDC file, it will put its own generated clocks with its own name, which you don’t want. If you call your SDC file after the UniPHY's SDC file, then derive_pll_clocks will see that the PLL outputs are already constrained and will not add any new constraints, which is the desired behavior.
You can use the "Add Files" in Quartus to change the order of the SDC files so that the UniPHY's SDC file is first in the list (read first) before the user's SDC file is read.
The following material is designed to help get a “basic” SDC file created and show the math behind the constraint values. There is an Excel spreadsheet available for download that will allow you to put in values from external device data sheets and board delays and will create a template for an SDC file. The block diagram and waveforms are inteded to help undestand the I/O timing associated with the SDC constraint generation.
For a more in depth investigation into Timequest, there are many tools available on the Altera website in the form of application notes and instructor led classes and on line recordings. There is also a Timequest Users Guide on the Altera Wiki which goes into a lot more depth, reviewing that users guide is highly recommended: TimeQuest User Guide.
There are many ways to draw timing diagrams for timing analysis, this will show one way. The diagram below shows 3 different devices, Xmt (driving signals into the FPGA), Rcv (destination for the FPGA signals) and the FPGA. The Xmt and Rcv portions could easily be the same device, however is it shown below as two devices to better show the flow. The red numbers are used in the timing diagram to represent the waveform at that node. The blue arrows represent the delay paths from one node to another and the names are used in the SDC file. The PLL represents a Phase Locked Loop inside the FPGA, and the triangles are just representing buffers inside the devices and really have no bearing in the analysis. The squares with x's in them denote pins on the physical device.
The following block diagram is used in the discussion below as the main block diagram for timing analysis and the Excel based constraint creator.
The red numbers are used in the timing diagram to represent the waveform at that node. The blue arrows represent the delay paths from one node to another and the names are used in the SDC file. The PLL represents a Phase Locked Loop inside the FPGA, and the triangles are just representing buffers inside the devices and really have no bearing in the analysis. The squares with x's in them denote pins on the physical device.
Excel Spread Sheet discussion: there are 3 sections to the Excel spreadsheet, data entry, constraint value creation, and the SDC file content:
Below is a high level view of the excel spread sheet, the 3 sections will be described in more detail.
The yellow boxes on the left allow you to enter values that you would extract from your board layout tools for board delays and also from the datasheets for your external devices, the clock-to-out values and hold values.
On the right side of the Excel spreadsheet shows the math behind the values for the constraints that are placed into the SDC. The blue box values are transferred into the SDC file as the constraint value. Since the SDC file is a tcl file, you can use variables for the various delays, Tco, hold, etc and the calculations can be included in the SDC file; Using variables is highly recommended. The Tcl keyword is “set” to create a variable and then use $ and the variable name and the keyword “expr” to perform the math. Below just shows a simple example of the syntax.
set my_dly_one 8
set my_dly_two 4
set_output_delay [expr $my_dly_one + $my_dly_two] get_ports {my_data} –clock {my_clk} –max
For the set_input_delay max constraint, you take the worst case clock board delay from the clock source to the input pin of the transmitting device add the worst case Tco spec from the transmitting device's data sheet and then add in the worst case data board delay from the transmitting device to the input pin of the FPGA and then subtract off the shortest clock board delay from the clock source to the FPGA clock input pin. This is the worst case scenario for analysis, the data shows up as late as possible at the FPGA data input pin, and the clock shows up the earliest to the FPGA input clock pin so forces the the FPGA to meet the tightest requirements.
The 3rd section is the actual SDC file, in theory you can copy this directly into an SDC file, however you may need to clean up artifacts due to copying from Excel to a text editor.
Below shows the waveforms for the 4 different I/O analysis, setup and hold from the Xmt device into the FPGA and setup and hold from the FPGA to the Rcv device.
The top trace (1) represents the clocks at the output of hte board level clock
The next two traces represent the three possible clocks at its destination, either node 2,3, or 4.
The last two traces represent the data at the respective node; node 5,6,7, or 8.
Community support is provided Monday to Friday. Other contact methods are available here.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
For more complete information about compiler optimizations, see our Optimization Notice.