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

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

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​

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

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?

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