Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Is asap7 really signing off setup at the *best-case* corner? (`CORNER ?= BC`)

Abierto
  • ¿Algo no está bien?
#4,764 0 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Área
devops

Línea de trabajo

Start with flow/platforms/asap7/config.mk at the CORNER default and library selection, then compare the timing setup with gf180 and check whether the flow has separate setup and hold corner handling. Reproduce on designs/asap7/gcd/config.mk with the default and CORNER=WC, and inspect the loaded libraries and setup slack. Done means establishing whether the default is intentional or incorrect and documenting or correcting it accordingly.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I think I must be misreading the asap7 corner setup, because as far as I can tell the default flow evaluates setup timing at the fast / best-case corner — which would be backwards. I'd appreciate a sanity check before I conclude I've found a real problem.

What I see

flow/platforms/asap7/config.mk (upstream/master @ 7bf5a814e4) defaults the single timing corner to BC:

export CORNER ?= BC                                   # line 197
export LIB_FILES += $($(CORNER)_$(LIB_MODEL)_LIB_FILES)

and BC is the fast corner (0.77 V, 25 C, *_FF_* libs):

BC_VOLTAGE = 0.77 ;  BC_TEMPERATURE = 25C
BC_NLDM_LIB_FILES_T = .../asap7sc7p5t_*_FF_nldm_*.lib.gz    # FF  = fast / best case
WC_NLDM_LIB_FILES_T = .../asap7sc7p5t_*_SS_nldm_*.lib.gz    # SS  = slow / worst case
TC_NLDM_LIB_FILES_T = .../asap7sc7p5t_*_TT_nldm_*.lib.gz    # TT  = typical

Since the flow is single-corner (LIB_FILES comes from the one selected CORNER), all STA — setup included — appears to run at FF by default. Setup is normally closed against the slow corner, so this looks wrong. gf180 has the same CORNER ?= BC; nangate45/sky130hd are single-typical-corner and look unaffected.

Minimal reproduction — gcd (smallest design, no corner override)

designs/asap7/gcd/config.mk sets no CORNER, so it inherits the platform default. Running it stock vs. forcing worst-case:

make DESIGN_CONFIG=./designs/asap7/gcd/config.mk            # default (BC)
make DESIGN_CONFIG=./designs/asap7/gcd/config.mk CORNER=WC  # worst-case
run libraries actually loaded worst setup slack
default (BC) asap7sc7p5t_*_FF_nldm_* (fast) −35 ps
CORNER=WC asap7sc7p5t_*_SS_nldm_* (slow) −347 ps

(Slack values are worst slack reported at the same timing-driven global-placement stage,
identical clock and SDC; grep _FF_nldm/_SS_nldm in each run's log confirms which corner's
libraries were read.) The default run reads the fast libraries and reports ~−35 ps; the
same design at the worst-case corner is ~−347 ps — a ~10× difference, and the sign of the
engineering conclusion ("barely violating" vs "badly violating") flips with it.

So the stock gcd — and every asap7 design that doesn't override CORNER — is being timed at
the best-case corner, which under-reports setup violations by an order of magnitude here.

Questions
  1. Am I misreading this — is there a separate setup/hold corner mechanism I'm missing that makes setup actually use SS despite CORNER ?= BC?
  2. If not: is BC an intentional asap7/gf180 choice (e.g. tied to how these predictive PDKs were characterized), or an oversight? If intentional, could it be documented, since "asap7 setup is reported at best-case" strongly affects how the numbers should be read?

Happy to send a PR (flip the default to WC/TC, or add docs) once I know which it is.

Lenguaje dominante
Verilog
Estrellas
777
Forks
549
Merge medio
1 d 22 h
PR fusionados (30 d)
85

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de The-OpenROAD-Project/OpenROAD-flow-scripts

Todos los issues de The-OpenROAD-Project/OpenROAD-flow-scripts

Issues similares

Más issues de DevOps

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.