tnt
10/25/2023, 10:57 AMFanout 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.tnt
10/25/2023, 2:13 PMset_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.