fake sram clock network insertion latency

[oharboe]

Near as I can tell, the clock network insertion latency within a macro is zero, which I found surprising.

Surely there is some clock network latency within an SRAM that CTS should take into account?

The two cases are different, but I'm having a hard time figuring out what OpenROAD is telling me.

I have compared the network insertion latency for a fakesram and a mock-sram.

Standalone example below based on make DESIGN_CONFIG=designs/asap7/riscv32i-mock-sram/config.mk and make DESIGN_CONFIG=designs/asap7/riscv32i/config.mk

Untar mock-sram.tar.gz and fakesram.tar.gz

fakeram has 0 clock network insertion latency 0.00 119.98 ^ dmem/dmem0/clk (fakeram7_256x32) below:

>>> report_checks -through {dmem/dmem0/rd_out[0]}
Startpoint: dmem/dmem0 (rising edge-triggered flip-flop clocked by clk)
Endpoint: riscv/dp/rf.rf[6][0]$_DFFE_PP_
          (rising edge-triggered flip-flop clocked by clk)
Path Group: clk
Path Type: max

  Delay    Time   Description
---------------------------------------------------------
   0.00    0.00   clock clk (rise edge)
 119.98  119.98   clock network delay (propagated)
   0.00  119.98 ^ dmem/dmem0/clk (fakeram7_256x32)
 218.00  337.98 v dmem/dmem0/rd_out[0] (fakeram7_256x32)
  19.53  357.51 v dmem/_172_/Y (OA22x2_ASAP7_75t_R)
  14.03  371.54 v dmem/_173_/Y (OA21x2_ASAP7_75t_R)
  22.78  394.33 v riscv/dp/_16029_/Y (OR3x1_ASAP7_75t_R)
  47.33  441.65 v riscv/dp/_16030_/Y (OA211x2_ASAP7_75t_R)
  66.19  507.84 v riscv/dp/_18872_/Y (AO21x1_ASAP7_75t_R)
   0.05  507.89 v riscv/dp/rf.rf[6][0]$_DFFE_PP_/D (DFFHQNx2_ASAP7_75t_R)
         507.89   data arrival time

1660.00 1660.00   clock clk (rise edge)
  99.49 1759.49   clock network delay (propagated)
   1.26 1760.75   clock reconvergence pessimism
        1760.75 ^ riscv/dp/rf.rf[6][0]$_DFFE_PP_/CLK (DFFHQNx2_ASAP7_75t_R)
  -2.91 1757.84   library setup time
        1757.84   data required time
---------------------------------------------------------
        1757.84   data required time
        -507.89   data arrival time
---------------------------------------------------------
        1249.95   slack (MET)

>>> report_clock_skew
Clock clk
 127.56 source latency dmem/dmem1/clk ^
 -86.68 target latency riscv/dp/rf.rf[25][6]$_DFFE_PP_/CLK ^
  -2.72 CRPR
--------------
  38.16 setup skew

mock sram:

>>> report_checks -through {dmem.dmem1/rd_out[0]}
Startpoint: dmem.dmem1 (rising edge-triggered flip-flop clocked by clk)
Endpoint: riscv/dp/rf.rf[7][0]$_DFFE_PP_
          (rising edge-triggered flip-flop clocked by clk)
Path Group: clk
Path Type: max

  Delay    Time   Description
---------------------------------------------------------
   0.00    0.00   clock clk (rise edge)
  47.47   47.47   clock network delay (propagated)
   0.00   47.47 ^ dmem.dmem1/clk (fakeram7_256x32)
 120.27  167.74 v dmem.dmem1/rd_out[0] (fakeram7_256x32)
  16.91  184.65 v _116_/Y (OA22x2_ASAP7_75t_R)
  23.03  207.69 v _119_/Y (OA21x2_ASAP7_75t_R)
  32.40  240.08 v riscv/dp/_16111_/Y (OR3x1_ASAP7_75t_R)
  48.24  288.32 v riscv/dp/_16112_/Y (OA211x2_ASAP7_75t_R)
  68.54  356.86 v riscv/dp/_16833_/Y (AO21x1_ASAP7_75t_R)
   0.06  356.93 v riscv/dp/rf.rf[7][0]$_DFFE_PP_/D (DFFHQNx2_ASAP7_75t_R)
         356.93   data arrival time

1660.00 1660.00   clock clk (rise edge)
 112.42 1772.42   clock network delay (propagated)
   0.00 1772.42   clock reconvergence pessimism
        1772.42 ^ riscv/dp/rf.rf[7][0]$_DFFE_PP_/CLK (DFFHQNx2_ASAP7_75t_R)
  -3.05 1769.38   library setup time
        1769.38   data required time
---------------------------------------------------------
        1769.38   data required time
        -356.93   data arrival time
---------------------------------------------------------
        1412.45   slack (MET)

>>> report_clock_skew
Clock clk
 125.41 source latency riscv/dp/rf.rf[3][23]$_DFFE_PP_/CLK ^
 -44.87 target latency dmem.dmem1/clk ^
 -41.11 target clock tree delay
   0.00 CRPR
--------------
  39.44 setup skew

Looks like the mock-sram has a clock network delay of internally for the flip-flop that is driving the rd_out[0]

[tspyrou]

@oharboe The liberty in the mock sram can be updated with the clock latency information.
CTS reads that attribute form the liberty and uses it in the balancing.
You could open an issue for this. The latency could be programable by the user, since its an estimate with some default which is a % of clk to output time.

[oharboe]

Doesnt the lack of this in fakeram introduce very large performance inaccuracies.

I am going to leave it to others who use fakeram to file a github issue. We use SRAM mocking, fakeram is just interesting to compare with.

Could you bring up the fakesram and mock sram examples here and look for what you think are material differences between the two as far as PPA is concerned?

[rovinski]

Proprietary algorithms generally don't even use the clock tree latency of macros for CTS. They look at the setup/hold time on the inputs and the delay on the outputs in order to balance the path timing. It then adds useful skew in order to try to balance the timing paths on the inputs and outputs. During this process, the CTS algorithm doesn't need to know what (if any) internal clock trees look like, so that property isn't needed.

The main reason OR uses it is because it is much easier to use the internal clock tree latency property of the macro than to implement a concurrent clock optimization algorithm, which is what proprietary tools use.

[oharboe]

I think I understand, but EDA tools is a mystery to me and I don't understand why it was easier to introduce the clock tree latency property to support CTS in lieu of a having support for useful skew support in CTS. No matter. :-)

If I understand, fakeram is that it is fine the way it is, provided CTS was more sophisticated at which point the clock tree latency could be removed from all macros as well. Hopefully represented in some way in reports though.

[rovinski]

If I understand, fakeram is that it is fine the way it is, provided CTS was more sophisticated at which point the clock tree latency could be removed from all macros as well. Hopefully represented in some way in reports though.

Spot on. Clock tree latency is indeed useful for e.g. reports and clock tree debugging, but it isn't necessary if the CTS algorithm was more complex.

[b62833]

Is the fakeram a non-physical model with no gates? If so, I'm not surprised there's no clock insertion modeled.

For what it's worth, the commercial synchronous memories I've seen typically don't show any internal clock delay. Their timing basically look like a multi-input and output D flop with arcs from the clock pin(s) to the I/O pins.

(They typically tend to be self timed so the rising edge of clock kicks of a sequence of events internal to the RAM - sample the inputs, decode the address, fire word lines, trigger sense amps, go back to precharging bit lines, etc. That all gets buried in an effective C2Q in the timing model. Some of those stages are small swing analogish steps that static timing can't model accurately anyways.)

[oharboe]

Thanks! This adds some useful color to my understanding of what is going on.