Forum Discussion
Occasional ContributorTiming failure with external synchronous SRAM
Sorry for the delay in response. Been taking some time to solve the timing violation.
For bidirectional I/O, they are analyzed as inputs and outputs, so they usually have both set_input_delay and set_output_delay assignments.
These sdc below in the project could be reason we got the huge negative slack. The tool analyze that the Data Arrival Path goes from clk_100_in -> sram_clk_out -> sram_clk_inout (o) -> external device -> sram_clk_inout (i) and then back to RAM block. This make it a very long timing path.
set_input_delay -clock sram_clk_out -min 1.3 [get_ports {sram_data36_inout*}]
set_input_delay -clock sram_clk_out -max 3 [get_ports {sram_data36_inout*}]With that, I create a virtual clock and add the input and output delay constraint to the sram_data36_inout*:
create_clock -name {sram_clk_ext} -period 10.000ns
set_input_delay -clock sram_clk_ext -min 1.3 [get_ports {sram_data36_inout*}]
set_input_delay -clock sram_clk_ext -max 3 [get_ports {sram_data36_inout*}]
set_output_delay -clock sram_clk_out -min 1.3 [get_ports {sram_data36_inout*}]
set_output_delay -clock sram_clk_out -max 3 [get_ports {sram_data36_inout*}]I also disable all the location assignment so that the fitter can place and route without being constraint, to meet the timing.
Attached the modified project. Though there is a timing violation of sram_address21_out and I believe it can be solved by tweaking the -max value to 1.0.
set_output_delay -clock sram_clk_out -max 1.0 [get_ports {sram_*_out*}]Best Regards,
Richard Tan
Occasional ContributorThanks for your reply. I've tried your suggestion (adding the false-path for sram_clk_out) and it doesn't seem to make any difference unfortunately. A few other things I've tried:
- I tried NOT forwarding the SRAM-clock through the FPGA (and connecting it directly from the XO to the SRAM clock input externally but that didn't fix my issue either);
- Using DCFIFO's instead of SCFIFO to allow one side to operate at clk_100_in and the other side on sram_clk_out but that didn't fix it either.
- Adding an extra input register for sram_data36_inout, again without any luck.
Do you have any other suggestions? Please note that (obviously) "clk_100_in" is also used for all the other logic in the FPGA, not just the SRAM-interface.
Super ContributorWhen you say adding the false path didn't make any difference, can you explain? Did you recompile the design and rerun the timing analysis? Show your updated .sdc and a detailed slack path report (including the data path and the waveform view) for a path that is still failing.
- arno_va
Yes I recompiled the design and reran the timing analysis.
My (relevant sections of) sdc now looks like:
create_clock -name "clk_100_in" -period 10.000ns -waveform { 0.000 5.000 } [get_ports {clk_100_in}] create_generated_clock -name {sram_clk_out} -source [get_ports {clk_100_in}] [get_ports {sram_clk_out}] # SRAM input minimum delay in ns set_input_delay -clock sram_clk_out -min 1.3 [get_ports {sram_data36_inout*}] # SRAM input maximum delay in ns set_input_delay -clock sram_clk_out -max 3 [get_ports {sram_data36_inout*}] # SRAM output minimum delay (=hold time) in ns set_output_delay -clock sram_clk_out -min -0.5 [get_ports {sram_address21_out*}] set_output_delay -clock sram_clk_out -min -0.5 [get_ports {sram_data36_inout*}] # SRAM output maximum delay (=setup time) in ns set_output_delay -clock sram_clk_out -max 1.5 [get_ports {sram_address21_out*}] set_output_delay -clock sram_clk_out -max 1.5 [get_ports {sram_data36_inout*}] set_false_path -to [get_ports sram_clk_out]And my failing paths now look like:
and d31's timing report looks like:
Let me know in case you need additional info. I have a feeling Quartus is having a hard time getting the timing right for sram_data36_inout input-path vs. output-path. What do you think?
