1
\$\begingroup\$

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.

\$\endgroup\$
5
  • 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 Jan 29 '20 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 Jan 29 '20 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 Jan 29 '20 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 Jan 29 '20 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\$ – user253751 Jun 30 '20 at 10:00
1
\$\begingroup\$

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]
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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