Skip to content

Generated Liberty sets input-pin max_transition (0.04 ns) below the PDK's achievable slew #298

Description

@cpehle

Summary

For the OpenRAM-generated sky130 SRAM sky130_sram_2kbyte_1rw1r_32x512_8, the
output Liberty declares max_transition : 0.04 (40 ps) on the input pins
(address and write-mask buses), while the same library's default_max_transition
is 0.5 (500 ps).

40 ps is tighter than sky130 standard cells can physically drive, so any
timing-driven P&R/STA flow that enforces slew limits treats the design as having
an infeasible constraint and stops.

Details

  • Macro / config: sky130_sram_2kbyte_1rw1r_32x512_8
    (macros/sram_configs/sky130_sram_2kbyte_1rw1r_32x512_8.py), corner
    TT_1p8V_25C.

  • The timing LUTs use the input-transition axis index_1("0.00125, 0.005, 0.04")
    — i.e. inputs are characterized only up to 0.04 ns.

  • The input buses then carry that maximum as their max_transition:

    library (sky130_sram_2kbyte_1rw1r_32x512_8_TT_1p8V_25C_lib) {
        time_unit : "1ns" ;
        default_max_transition : 0.5 ;
        ...
        bus (addr0)  { direction : input; max_transition : 0.04; ... }
        bus (wmask0) { direction : input; max_transition : 0.04; ... }
        ...
    }
    

    (three input buses in total) — 12.5x tighter than the file's own
    default_max_transition.

Downstream effect

A timing-driven flow rejects it. With OpenROAD (global_placement -timing_driven
→ resizer slew pre-check):

[ERROR RSZ-0090] Max transition time from SDC is 0.040ns.
Best achievable transition time is 0.098ns with a load of 0.00pF

OpenROAD's check is correct — the smallest sky130 buffer cannot produce a
transition below ~0.098 ns even at zero load — so the 0.04 ns input constraint is
physically unmeetable. The value originates in the Liberty, not the tool
(reproduced with OpenROAD @ 51c9638, but independent of tool version).

Question / suggestion

  • Is the input-transition characterization range (max 0.04 ns here) the intended
    default? For a macro whose inputs are driven by ordinary standard-cell logic,
    the characterized input slew should span realistic drive (hundreds of ps), or
    at minimum should not be tighter than the target PDK's achievable transition.
  • Would it make sense to (a) widen the default input-slew list used for
    characterization, and/or (b) avoid emitting a per-pin max_transition that is
    tighter than the library's own default_max_transition?

Happy to attach the full .lib or the config if useful.

Environment

  • sky130 PDK, ngspice Liberty characterization.
  • The same views are also redistributed via efabless/sky130_sram_macros.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions