Why three buffers for a through signal in mock-array/Element?

[oharboe]

Using The-OpenROAD-Project/OpenROAD-flow-scripts#1322 to be merged, but the same issue exists in master), I looked at a path going through Element (no registers, just a signal going from left to right through the Element):

There are three buffers in this path: input, a middle buffer inserted by synthesis, and an output buffer. The input and output buffers are introduced by OpenROAD. What motivates synthesis to introduce this middle buffer? Isn't that the job of resizing?

From 1_synth.v we see the middle buffer:

  BUFx2_ASAP7_75t_R _776_ (
    .A(io_lsbIns_5),
    .Y(io_lsbOuts_4)
  );

The buffer is inserted by this code:

https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/4a6fdcebf8361481090acde05d596e8db946c806/flow/scripts/synth.tcl#L96

>>> report_checks -path_delay max -to io_lsbOuts_4 -fields {slew net cap}
Startpoint: io_lsbIns_5 (input port)
Endpoint: io_lsbOuts_4 (output port)
Path Group: path delay
Path Type: max

Fanout     Cap    Slew   Delay    Time   Description
-----------------------------------------------------------------------------
                          0.00    0.00 v input external delay
                  6.80    0.80    0.80 v io_lsbIns_5 (in)
     1    0.83                           io_lsbIns_5 (net)
                  4.97   12.72   13.52 v input261/Y (BUFx2_ASAP7_75t_R)
     1    0.79                           net261 (net)
                 13.54   15.20   28.72 v _776_/Y (BUFx3_ASAP7_75t_R)
     1    5.63                           net268 (net)
                 17.44   23.37   52.09 v output268/Y (BUFx4f_ASAP7_75t_R)
     1   10.23                           io_lsbOuts_4 (net)
                 17.59    0.91   53.00 v io_lsbOuts_4 (out)
                                 53.00   data arrival time

                         29.60   29.60   max_delay
                          0.00   29.60   output external delay
                                 29.60   data required time
-----------------------------------------------------------------------------
                                 29.60   data required time
                                -53.00   data arrival time
-----------------------------------------------------------------------------
                                -23.40   slack (VIOLATED)

Overview:

The two nearly back-to-back buffers on the output:

Moreover: there are two buffers(synthesis introduced buffer + output buffer) nearly back to back at the output. The Element is routed by abutment horizontall, so we get a third input buffer immediately from the Element to the right.

If I disable https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/4a6fdcebf8361481090acde05d596e8db946c806/flow/scripts/synth.tcl#L96, I get no buffers, which was unexpected as OpenROAD, not synthesis inserts input and output buffers...

>>> report_checks -path_delay max -to io_lsbOuts_4 -fields {slew net cap}
Startpoint: io_lsbIns_5 (input port)
Endpoint: io_lsbOuts_4 (output port)
Path Group: path delay
Path Type: max

Fanout     Cap    Slew   Delay    Time   Description
-----------------------------------------------------------------------------
                          0.00    0.00 ^ input external delay
                 31.60   16.96   16.96 ^ io_lsbIns_5 (in)
     1   15.09                           io_lsbIns_5 (net)
                 42.77    0.00   16.96 ^ io_lsbOuts_4 (out)
                                 16.96   data arrival time

                         29.60   29.60   max_delay
                          0.00   29.60   output external delay
                                 29.60   data required time
-----------------------------------------------------------------------------
                                 29.60   data required time
                                -16.96   data arrival time
-----------------------------------------------------------------------------
                                 12.64   slack (MET)

At the mock-array level, I see something unexpected, 0 delay for the in-out paths:

>>> report_checks -path_delay max -through ces_7_1/io_lsbIns_* -fields {net cap slew}
Startpoint: ces_7_0 (rising edge-triggered flip-flop clocked by clock)
Endpoint: ces_7_4 (rising edge-triggered flip-flop clocked by clock)
Path Group: clock
Path Type: max

Fanout     Cap    Slew   Delay    Time   Description
-----------------------------------------------------------------------------
                          0.00    0.00   clock clock (rise edge)
                        287.91  287.91   clock network delay (propagated)
                 83.67    0.00  287.91 ^ ces_7_0/clock (Element)
                  3.44  164.65  452.56 v ces_7_0/io_lsbOuts_7 (Element)
     1    0.00                           ces_7_0_io_lsbOuts_7 (net)
                  5.80    0.00  452.56 v ces_7_1/io_lsbOuts_6 (Element)
     1    0.00                           ces_7_1_io_lsbOuts_6 (net)
                  5.80    0.00  452.56 v ces_7_2/io_lsbOuts_5 (Element)
     1    0.00                           ces_7_2_io_lsbOuts_5 (net)
                  5.80    0.00  452.56 v ces_7_3/io_lsbOuts_4 (Element)
     1    0.69                           ces_7_3_io_lsbOuts_4 (net)
                  5.80    0.00  452.56 v ces_7_4/io_lsbIns_4 (Element)
                                452.56   data arrival time

                        300.00  300.00   clock clock (rise edge)
                        238.74  538.74   clock network delay (propagated)
                        -10.00  528.74   clock uncertainty
                          1.40  530.14   clock reconvergence pessimism
                                530.14 ^ ces_7_4/clock (Element)
                         70.02  600.16   library setup time
                                600.16   data required time
-----------------------------------------------------------------------------
                                600.16   data required time
                               -452.56   data arrival time
-----------------------------------------------------------------------------
                                147.59   slack (MET)

[maliberty]

The third buffer buffer looks to have been from yosys. I imagine the incoming netlist was a single buffer (776). The other two come from buffer_ports. You could skip that if you want a single buffer.

[oharboe]

The third buffer buffer looks to have been from yosys.

Yep.

I imagine the incoming netlist was a single buffer (776). The other two come from buffer_ports. You could skip that if you want a single buffer.

Surprisingly, the input output buffers go away if I disable yosys buffer insertions. Any thoughts about why that is happening?

It sounds like you only expected input/output buffers in this case...

How can I disable output/input buffers for only in-out paths and is it a good idea in this case?

Also, I didn't expect zero propagation time when there are no buffers, is that expected?

[maliberty]

You need a driver and its full load to calculate a meaningful delay. Once you have a driver in the block a meaningful value can be calculated that includes the wire delay.

[oharboe]

Before I close this discussion as answered: is there a way today to disable input/output buffers for an in-out path and would that be OK in this case as I know this is routed by abutment and that there is then one buffer per Element in mock-array?

[maliberty]

There is not currently. Its not just an in-out path but also a single gate.

[oharboe]

I meant that it is not registered, it is a combinational path.

[maliberty]

I'm not sure why they should be a specific exception.

[oharboe]

@maliberty One last question, why is this line in synth.tcl? I understand what it does, I just don't know why it is there.

insbuf -buf {*}$::env(MIN_BUF_CELL_AND_PORTS)

[maliberty]

Verilog isn't great for modeling pure feedthrus so I don't suggest doing that.

[rovinski]

The insbuf command has been part of the synth script since the initial commit of ORFS from the old alpha repo. I vaguely recall being told that yosys needed a buffer name in order to buffer properly. It could very well be obsolete.

[maliberty]

I think insbuf is fine - its more that we buffer the inputs & outputs again in OR.

[rovinski]

So is this something to handle on the OR side then? I don't see any buffering command in the synth script other than insbuf.

[maliberty]

Yes OR