Background: The image below is, in essence, a simplified schematic of the, so called asynchronous state machine (AM_fsm.v). The design does not have any clock input signal. It contains many SR latches and a lot of combinatorial clouds. (aka OR/AND/MUX gates). enter image description here
I would like to reduce the delay from the Q of the SR latch to the output m1. In essence, I need to reduce the propagation delay from pk_in to m1. The delay_A and the delay_B are not critical. In short, I need to reduce the delay_C as much as possible. The main reason why the delays A and B are not critical is very simple. The logic gates, selected/calculated by the synthesizer are such that every in-to-out propagation delay is in the range between 15 and 80 ps per gate. On the other side (delay_C), the propagation delay per gate is between 150-350 ps. So, there is still room for improvement I've tried various commands to convince the 'genus' (CADENCE's synthesis tool) to size the gates to reduce the delay.

set_max_delay -from [get_pins AM_fsm/SR_latch/Q] -to [get_ports m1] 0.2
create_clock -name virtual_clk -period 3 -domain virtual
set_max_delay 0.2 -from [get_ports pk_in] -to [get_ports m1] 
set_min_delay 0.0 -from [get_ports pk_in] -to [get_ports m1]

I even tried to put big load on the m1. It did help (slightly).

RESULT: Nothing from above reduced the delay_C.

Is there some other way to convince 'genus' to shorten the delay_C.

  • 1
    \$\begingroup\$ It is not always possible to reduce delay. If that was the case CPUs would be able to run at a few Terra Hertz. They don't. The only solution in these cases is to overhaul your design. More pipeline stages or move where the registers are. \$\endgroup\$
    – Oldfart
    Commented Jan 29, 2020 at 4:25
  • \$\begingroup\$ As I said in my question, this design is 'asynchronous state machine'. In essence, it makes decisions in real time. There is no clock present, no registers, no pipeline possible, no latency allowed. What I would like to do is to reduce 'delay_3' using synthesis tool with the appropriate SDC file. \$\endgroup\$
    – Igor
    Commented Jan 29, 2020 at 5:15
  • 3
    \$\begingroup\$ The does not matter. If you reached the minimum, you can't reduce the time any further. Also "no latency allowed" implies that your output comes at the same time as your input changes. I know of no logic which can do that. \$\endgroup\$
    – Oldfart
    Commented Jan 29, 2020 at 5:41
  • \$\begingroup\$ I made a mistake saying 'no latency allowed'. Of course there is delay (latency) in ever circuit. My bad. I also changed the original post explaining why i think the tool should be able to reduce the 'delay_C'. \$\endgroup\$
    – Igor
    Commented Jan 29, 2020 at 7:00
  • \$\begingroup\$ @Oldfart FPGA synthesis tools can often reduce latency in one place by increasing latency in other places, but they need to know what is supposed to have the lowest latency. \$\endgroup\$ Commented Jun 30, 2020 at 10:00

1 Answer 1


SOLUTION which works for my test case. I was able to reduce the delay_C from approx. 1200 ps (unconstrained) down to 420 ps (constrained).

create_clock -name virtual_clk -period 2.5  -domain virtual
set_input_delay  -clock virtual_clk 2.0   [find / -pin AM_fsm/SR_latch/Q]
set_output_delay -clock virtual_clk 0.100 [find / -port m1]

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.