Timing 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