- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's from avmm_data_read to an internal node in the ip:
-0.060 motor_ctrl:loop1|ufm_stmac:ufm_stmac|data_read motor_ctrl:loop1|ufm_stmac:ufm_stmac|max10_ufm:max10_ufm|altera_onchip_flash:onchip_flash_0|altera_onchip_flash_block:altera_onchip_flash_block|ufm_block~XE_YE_TO_CLK clk25mhz_i clk25mhz_i 0.000 0.478 1.428 1
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you post your .sdc and more of this report (a screenshot would be better)? Is the 0.478 the clock relationship/skew? How are you creating the clock and connecting it?
#iwork4intel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But this way, I can see what the delays are. And constrain them later.
https://downloadnox.onl/ https://vidmate.vet/ https://vlc.onl/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
0.000=relationship, 0.478 = skew. 1.428=Data Delay
Here's the bulk of the sdc file. Of course, I just rerouted it and didn't get the hold violation. This morning, all the routes had a hold delay.
#**************************************************************
# Create the Input Clock from the external oscillator
#**************************************************************
create_clock -name {clk25mhz_i} -period 40.000 [get_ports { clk25mhz_i }]
#**************************************************************
# Create Generated Clock
#**************************************************************
derive_pll_clocks
create_clock -name clk25Virt -period 40.000
#**************************************************************
# Set Clock Latency
#**************************************************************
#**************************************************************
# Set Clock Uncertainty
#**************************************************************
derive_clock_uncertainty
#**************************************************************
#**************************************************************
# Set Output Delay
#**************************************************************
set_output_delay -clock { clk25Virt } -max 0.0 [get_ports {motor_h1_o motor_l1_o motor_h2_o motor_l2_o}]
set_output_delay -clock { clk25Virt } -min 0.0 [get_ports {motor_h1_o motor_l1_o motor_h2_o motor_l2_o}]
set_output_delay -clock { clk25Virt } -max 0.0 [get_ports {buzz_o }]
set_output_delay -clock { clk25Virt } -min 0.0 [get_ports {buzz_o }]
set_output_delay -clock { clk25Virt } -max 0.0 [get_ports {led_blank_o led_data_o led_latch_o led_sclk_o}]
set_output_delay -clock { clk25Virt } -min 0.0 [get_ports {led_blank_o led_data_o led_latch_o led_sclk_o}]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Having a max and min of 0 for your output delays doesn't make any sense and could be part of the problem. But are these outputs driving something that has setup and hold requirements (doesn't look like it). If not, you should use false paths on the outputs instead of set_output_delay.
Does your design not have any inputs?
#iwork4intel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The output delays are just place holders. Actually all inputs are asynchronous and outputs don't have any real setup and hold requirements.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So you should false path all your inputs and outputs. You're basically heavily overconstraining your design by using 0 on all the outputs here.
#iwork4intel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But this way, I can see what the delays are. And constrain them later.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
True. But as you can see, you're getting timing violations, so the timing analysis isn't really matching up with the way your design would work for real. Chances are in hardware, you'd have no problems, but because of your overconstraints, the tool is essentially reporting false timing failures.
If you're still in the design phase, like I said, try false paths on all your inputs and outputs. You'll still be able to see timing on internal paths as selected by the Fitter.
#iwork4intel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I want to constrain most of my outputs to 1 - 25Mhz clock period (40 ns). With the min and max set to 0 & referenced to the virtual 25 mhz clock, this is assured. And for this device, it shouldn't be a problem. My worst case setup slack is 14 ns to my outputs and worst case hold slack is 1.7ns. So, I'm meeting that by a pretty large margin.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Then I would want to look at the Data Path and Waveform tabs in the timing analyzer to see details on the failing path. Are there other paths failing or just this one?
#iwork4intel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, it was just one internal path to the User Flash Memory IP. avmm_data_read to some internal node in the IP. I saw there was a bug a couple years ago in quartus that they said they fixed that had a similar hold problem to an internal node in the UFM IP. Anyhow, I can't reproduce it any longer. Thanks for taking the time to help me with this though.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page