Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

How to tell timing closure is achieved? How to create real timing constraints?

JPowe1
Beginner
2,889 Views

I'm working on a Max 10 FPGA that implements a SPI master and a Manchester encoder/decoder. The decoder looks for transitions  in the middle of each bit to recover the data clock. The SPI clock is 1/4 and the Manchester data clock is 1/8​ the FPGA clock, which is about 80 ns.  

I used a simple sdc file based another design:

 

create_clock -name clk_in -period 80 [get_ports clk_in]

derive_pll_clocks

derive_clock_uncertainty

set_input_delay -clock clk_in -max 3 [all_inputs]

set_input_delay -clock clk_in -min 2 [all_inputs]

set_output_delay -clock clk_in 2 [all_outputs]

 

The timing analyzer reported no errors I could detect with these constraints.

Please provide suggestions for steps necessary for timing closure.

0 Kudos
5 Replies
KhaiChein_Y_Intel
1,198 Views

You may refer to Timing Analyzer section in Processing > Compilation Report and see if there is any timing violation.

0 Kudos
JPowe1
Beginner
1,198 Views

Here is the output from the compilation report.

I don't see anything indicating a timing violation.

The design runs off a single master clock.

The spi port is a master and generates a spi clock and the external slave will transfer valid data as long as it reads and writes data on the correct clock edge.

The Manchester encoder/decoder looks for transitions in the data and counts 1/2 bit from the last transition to detect whether the bit is a 0 or 1 and recover the clock which is always in the middle of the bit. This seems like something that should be described by a virtual clock that I've read about in the apnotes but I'm not sure how to do this.

Are the input and output delays I'm using correct for a Max 10?

Should the spi clock be described by a generated clock?

 

Info: *******************************************************************

Info: Running Quartus II 64-Bit TimeQuest Timing Analyzer

 Info: Version 14.0.2 Build 209 09/17/2014 SJ Web Edition

 Info: Processing started: Wed Nov 28 12:30:52 2018

Info: Command: quartus_sta top_IPFE_Podcom -c top_IPFE_Podcom

Info: qsta_default_script.tcl version: #1

Info (11104): Parallel Compilation has detected 4 hyper-threaded processors. However, the extra hyper-threaded processors will not be used by default. Parallel Compilation will use 2 of the 2 physical processors detected instead.

Info (21076): Core supply voltage operating condition is not set. Assuming a default value of '1.2V'.

Info (21077): Low junction temperature is 0 degrees C

Info (21077): High junction temperature is 85 degrees C

Info (332104): Reading SDC File: 'SDC1_edited_111618.sdc'

Info (332151): Clock uncertainty is not calculated until you update the timing netlist.

Info (332123): Deriving Clock Uncertainty. Please refer to report_sdc in TimeQuest to see clock uncertainties.

Info: Found TIMEQUEST_REPORT_SCRIPT_INCLUDE_DEFAULT_ANALYSIS = ON

Info: Analyzing Slow 1200mV 85C Model

Info: Can't run Report Timing Closure Recommendations. The current device family is not supported.

Info (332146): Worst-case setup slack is 32.502

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   32.502              0.000 clk_in

Info (332146): Worst-case hold slack is 0.458

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):    0.458              0.000 clk_in

Info (332146): Worst-case recovery slack is 36.855

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   36.855              0.000 clk_in

Info (332146): Worst-case removal slack is 42.329

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   42.329              0.000 clk_in

Info (332146): Worst-case minimum pulse width slack is 40.450

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   40.450              0.000 clk_in

Info (332001): The selected device family is not supported by the report_metastability command.

Info: Analyzing Slow 1200mV 0C Model

Info (334003): Started post-fitting delay annotation

Warning (12535): Advance timing characteristics for device 10M08SAU169C8GES

Info (334004): Delay annotation completed successfully

Info (332123): Deriving Clock Uncertainty. Please refer to report_sdc in TimeQuest to see clock uncertainties.

Info (332146): Worst-case setup slack is 33.072

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   33.072              0.000 clk_in

Info (332146): Worst-case hold slack is 0.411

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):    0.411              0.000 clk_in

Info (332146): Worst-case recovery slack is 37.011

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   37.011              0.000 clk_in

Info (332146): Worst-case removal slack is 42.177

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   42.177              0.000 clk_in

Info (332146): Worst-case minimum pulse width slack is 40.438

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   40.438              0.000 clk_in

Info (332001): The selected device family is not supported by the report_metastability command.

Info: Analyzing Fast 1200mV 0C Model

Info (332123): Deriving Clock Uncertainty. Please refer to report_sdc in TimeQuest to see clock uncertainties.

Info (332146): Worst-case setup slack is 35.455

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   35.455              0.000 clk_in

Info (332146): Worst-case hold slack is 0.150

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):    0.150              0.000 clk_in

Info (332146): Worst-case recovery slack is 39.491

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   39.491              0.000 clk_in

Info (332146): Worst-case removal slack is 40.893

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   40.893              0.000 clk_in

Info (332146): Worst-case minimum pulse width slack is 40.087

 Info (332119):    Slack      End Point TNS Clock

 Info (332119): ========= =================== =====================

 Info (332119):   40.087              0.000 clk_in

Info (332001): The selected device family is not supported by the report_metastability command.

Info (332101): Design is fully constrained for setup requirements

Info (332101): Design is fully constrained for hold requirements

Info: Quartus II 64-Bit TimeQuest Timing Analyzer was successful. 0 errors, 1 warning

 Info: Peak virtual memory: 508 megabytes

 Info: Processing ended: Wed Nov 28 12:30:54 2018

 Info: Elapsed time: 00:00:02

 Info: Total CPU time (on all processors): 00:00:03​

0 Kudos
IDeyn
New Contributor III
1,198 Views

Hi JPowe1!

 

First of all, SCK is not a true clock because of it's duty cycle, which is not constant.

Secondly, I think you can simply write set_false_paths for TQuest to ignore the timing if you are sure that timing is valid because your SPI and Manchester clocks are low speed compared to FPGA clock.

 

Hope that helps.

 

Best regards,

Ivan

0 Kudos
JPowe1
Beginner
1,198 Views

The SPI and Manchester clocks are lower speed than the FPGA clock and are asynchronous to the clocks in the external devices which generate timing for those devices and are at least as fast as the FPGA clock.

The external devices use the SPI clock and recovered clock from the data the FPGA sends to receive data when it's stable. The receiver will detect a SPI or Manchester clock edge no more than 2 FPGA clocks after the clock transition so that by the 3rd FPGA clock the data will be stable and the setup and hold times will be at least 1 FPGA clock.

While the FPGA and external clocks are asynchronous the data is synchronized through the mechanism described above. 

Is there a way to describe this in an sdc file or is this something that can't be described or evaluated using TimeQuest?

Are there typical values for input and output delays to use for different families of FPGAs and/or clock speeds to put in the sdc?

Is there an apnote for a similar design I could use as a template?

 

0 Kudos
IDeyn
New Contributor III
1,198 Views

Hi JPowe1!

 

First of all, you need to describe properly timing inside your FPGA. For that you need to tell TQ about your clock. You use PLL, and after derive_pll_clock TQ knows everything about timing paths inside FPGA except paths between FPGA regs and external devices. For external paths you need to create virtual clocks and probably exploit create_generated_clock command. You can of course use set_input and set_output_delay constraints, but your timing have a huge margin so most likely there is no need for this.

 

There are no typical values for input and output delays because they depend on speeds, type of interface, PCB board design, available I/O and logic and clock resourses and so on.

 

As about appnote, I think I could share that document wroty by David Hawkins, which was posted by him previously on alteraforum - https://www.ovro.caltech.edu/~dwh/correlator/pdf/timequest_quad_spi_flash.pdf

Also for me the best work which explains Timing is Time_Quest User Guide by Ryan Scoville https://fpgawiki.intel.com/wiki/TimeQuest_User_Guide

 

But again, in your case timing constraints (except set_clock_groups or set_false_path) most likely would be an overkill.

 

Hope that helps.

 

Best regards,

Ivan

 

0 Kudos
Reply