open-source-silicon.dev

<@U016EM8L91B> <@U016HSAA3RQ> Recently i got to know that SRAM timing model(.lib) are just placeholder and it's not good for timing sign-off.  I see caravel integrated SRAM 2KB in mgmt_core and looks to be using SRAM .lib for timing analysis ?  Is this will not break caravel silicon behavior ?

<https://skywater-pdk.slack.com/archives/C016ULUQXDF/p1644606309636959>

seems not. would be great to get some advise on how to handle this

maybe we need to add adjustable input and output delays

Adding adjustable delay for 76+ signal (32 wdata + 32 Rdata + 8 Address + 4 Mask + Chip Select) not a got option .. One option is adding adjustable delay for Memory clock .. But If Write and Read uses same clock then it be tough to manage it

<@U01634FH82K> can you please comment?  we did update timing delays for the SRAM in Caravel from values provided by Matt G.

<@U016HSAA3RQ> In latest discussion in <#C016ULUQXDF|openram> slack with Matt G has confirmed that delay in SRAM .lib are just placeholder and not good for timing sign-off
<https://skywater-pdk.slack.com/archives/C016ULUQXDF/p1644606309636959>

<@U0172QZ342D> One of the option to manage SRAM Timing is:
As SRAM capture data at Pos edge and Launch at Neg Edge.
Better design fix is:  Launch functional data =&gt; SRAM (In) in Neg edge.
As SRAM data out is already in neg edge =&gt; Functional capture at Posedge will be fine.
This will help take care of both setup and hold issue. If there setup issue we need to reduce the SRAM clock .
Adding 5 to 10ns of adjustable delay for each SRAM input is not a good option