- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have a 62.5 MHz input clock to a Max 10 (10M08SCM153I7G). Our RTL has been done for a while and the project compiles fine with just a clock period constraint.
Fast forward and we've added our set_input_delay and set_output_delay constraints. Setup and hold times are met, but we now fail the "Minimum Pulse Width" check. It only fails under the Fast 1200mV -40 C model in Timing Analyzer.
When I look at the paths that failed, it shows the following:
Note that SCK_1/2/3/4 are all just forwarded copies of SPI_CLK. I just use an assign statement to do this. The code looks like this
assign SCK_1 = SCLK_LO2;
assign SCK_2 = SCLK_LO2;
assign SCK_3 = SCLK_LO2;
assign SCK_4 = SCLK_LO2;
I'm confused because nothing changes architecturally with or without my input/output constraints, yet this pulse width failure only happens with my constraints applied. More specifically, the "required width" field changes to 20 ns when constraints are included, which obviously fails for a 62.5MHz clock.
What causes this? I've also included the relevant constraints below:
# clock definition
create_clock -name {SPI_CLK} -period 16.000 -waveform { 0.000 8.000 } [get_ports {SCLK_LO2}]
# These constraints cause Minimum Pulse Width to fail
# Input setup delay
set_input_delay -clock [get_clocks {SPI_CLK}] 2 [get_ports {MOSI_LO2_1 SS_PLL_1_IN}]
set_input_delay -clock [get_clocks {SPI_CLK}] 2 [get_ports {MOSI_LO2_2 SS_PLL_2_IN}]
set_input_delay -clock [get_clocks {SPI_CLK}] 2 [get_ports {MOSI_LO2_3 SS_PLL_3_IN}]
set_input_delay -clock [get_clocks {SPI_CLK}] 2 [get_ports {MOSI_LO2_4 SS_PLL_4_IN}]
# output setup and hold delays
set_output_delay -clock [get_clocks {SPI_CLK}] -reference_pin [get_ports {SCK_1}] -max 2 [get_ports {SDI_1 LE_1}]
set_output_delay -clock [get_clocks {SPI_CLK}] -reference_pin [get_ports {SCK_1}] -min 0 [get_ports {SDI_1 LE_1}] -add_delay
set_output_delay -clock [get_clocks {SPI_CLK}] -reference_pin [get_ports {SCK_2}] -max 2 [get_ports {SDI_2 LE_2}]
set_output_delay -clock [get_clocks {SPI_CLK}] -reference_pin [get_ports {SCK_2}] -min 0 [get_ports {SDI_2 LE_2}] -add_delay
set_output_delay -clock [get_clocks {SPI_CLK}] -reference_pin [get_ports {SCK_3}] -max 2 [get_ports {SDI_3 LE_3}]
set_output_delay -clock [get_clocks {SPI_CLK}] -reference_pin [get_ports {SCK_3}] -min 0 [get_ports {SDI_3 LE_3}] -add_delay
set_output_delay -clock [get_clocks {SPI_CLK}] -reference_pin [get_ports {SCK_4}] -max 2 [get_ports {SDI_4 LE_4}]
set_output_delay -clock [get_clocks {SPI_CLK}] -reference_pin [get_ports {SCK_4}] -min 0 [get_ports {SDI_4 LE_4}] -add_delay
Some weird things to consider:
- Our clock doesn't go to a PLL or anything. It just goes through a clock buffer at the input.
- Again, SCK1, 2, 3, and 4 are all forwarded copies of SPI_CLK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was able to answer the second question for myself. If I don't do input/output constraints, Timing Analyzer doesn't associate SCK_1, SCK_2, etc. as being "clocked" by the 62.5 MHz SPI_CLK. "They're just asynchronous signals, how would I know anything about their timing?" it says to itself, ignoring the explicit assign statement in my RTL. Thus it ignores them in the Minimum Pulse Width analysis. To confirm this, I was able to get the error to show up without input/output delays by explicitly identifying them as a clock like so:
create_clock -name {SCK_} -period 16.000 -waveform { 0.000 8.000 } [get_ports {SCK_*}]
This should be considered a bug... you would not believe the headache this caused in our design reviewing.
I'm still interested in knowing if this apparent 50 MHz maximum output frequency is documented anywhere. These pins are 3.3V LVCMOS. I don't see anything in the Max 10 datasheet. Should I be looking somewhere else?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ajala1,
You have to reduce the frequency for those ports or change the IO standard that can drive as faster clock.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not to be skeptical, but that raises more questions than it answers:
- If there's a maximum output frequency, where is this documented in the datasheet? How do I know which IO standard can handle 62.5 MHz?
- Why does this timing error only get called out when I apply input and output delay constraints?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was able to answer the second question for myself. If I don't do input/output constraints, Timing Analyzer doesn't associate SCK_1, SCK_2, etc. as being "clocked" by the 62.5 MHz SPI_CLK. "They're just asynchronous signals, how would I know anything about their timing?" it says to itself, ignoring the explicit assign statement in my RTL. Thus it ignores them in the Minimum Pulse Width analysis. To confirm this, I was able to get the error to show up without input/output delays by explicitly identifying them as a clock like so:
create_clock -name {SCK_} -period 16.000 -waveform { 0.000 8.000 } [get_ports {SCK_*}]
This should be considered a bug... you would not believe the headache this caused in our design reviewing.
I'm still interested in knowing if this apparent 50 MHz maximum output frequency is documented anywhere. These pins are 3.3V LVCMOS. I don't see anything in the Max 10 datasheet. Should I be looking somewhere else?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page