I am getting a hold violation using the on chip flash ip. What can I do to resolve this issue?

[KLohr]

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

[sstrell]

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

[kadon]

But this way, I can see what the delays are. And constrain them later.

 https://downloadnox.onl/ https://vidmate.vet/ https://vlc.onl/

[KLohr]

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}]

[sstrell]

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

[KLohr]

The output delays are just place holders. Actually all inputs are asynchronous and outputs don't have any real setup and hold requirements.

[sstrell]

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

[KLohr]

But this way, I can see what the delays are. And constrain them later.

[sstrell]

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

[KLohr]

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.

[sstrell]

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

[KLohr]

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.