When a net is driven by multiple tristate buffer, ...
# timing-closure
t
When a net is driven by multiple tristate buffer, for the "slew" value at the input of the buffers "reading" from that net, it seems to take the value from the slowest driver of the net always, rather than the value from the driver of the path being analyzed. For instance, look at this excerpt :
Copy code
Fanout         Cap        Slew       Delay        Time   Description
---------------------------------------------------------------------------------------------
[...]
                      0.073909    0.000168    0.253725 ^ block[12].genblk1.tbuf_spine_ow_I[23].genblk1.cell0_I/A (sky130_fd_sc_hd__ebufn_8)
     1    0.289250    1.130828    0.881752    1.135478 ^ block[12].genblk1.tbuf_spine_ow_I[23].genblk1.cell0_I/Z (sky130_fd_sc_hd__ebufn_8)
                                                         block[0].genblk1.tbuf_spine_ow_I[23].z (net)
                      3.406518    0.065144    1.200622 ^ buf_spine_ow_I[23].genblk1.cell0_I/A (sky130_fd_sc_hd__buf_2)
     1    0.006288    0.113416    0.422576    1.623198 ^ buf_spine_ow_I[23].genblk1.cell0_I/X (sky130_fd_sc_hd__buf_2)
[...]
The output slew at the output of that
ebufn_8
is ~ 1.13 ns. But then at the next line the input slew at the
buf_2
is 3.4 ns. ( And no, there is no big resistive net or anything, looking at spice sims of that net, the output slew of the buffer is pretty much the same as the input slew of the receiver ). But on the same net I also have a very weak
ebufn_1
( in another path). And if I remove that
ebufn_1
(which is not involved at all in the path being reported here), then the 3.4 ns disappears and instead it's like 1.14 ns which is what I'd expect.
I did manage to get it to behave by using
set_case_analysis
to set the
TE_B
pin of the
ebufn_1
to its inactive value. Not sure if it's expected to have to do that, but at least, that got it working.