@User I'm still learning about running sta on the whole chip, and I was digging a little bit on how the analysis is done on the srams. I looked at some sta results related to the sram modules and I see that the "library hold time" is -0.056ns. That is defined in the .lib file right? That number sounded super optimistic in my head after analyzing many report_checks from our projects. Looking into the sram gds I see that the clock goes through

pdriver_2

(a series of 6 inverters) before getting to the din0 or addr0 FF. Wouldn't that path generate a slack between the data (that enters direclty to the FF from the port) and the clock that is not being taken into account on the .lib ?

The .lib files are optimistic now. They are generated with simple (uncalibrated) analytical models for now. The setup and hold are directly from a flip flop. We are working on improving the timing models right now.

@User wouldn't it be better to use a safer, positive value while your are working on the better timing model? Wouldn't the

pdriver_2

inverter sequence generate a positive delay bigger than those -0.056ns ?

@User yes it would. As I mentioned, this timing is not valid and shouldn't be used

Ok. I'm trying to understand how can we handle this in the future, because if I'm not wrong, those values are used by the openlane flow and the caravel signoff sta (make caravel_timings_xxx) to calculate timing violations on designs that use the SRAMs. As sram users we would have to analyze those reports and choose some value for the slack that we consider safe, because just being above 0 wouldn't be enough, right?

@User Yes, this is consistent with what we have seen

@User Great, we’ll have that number in mind when doing STA on the whole chip