ram: add placement sanity checks to the regression tests (check_placement, etc.) #10561

Activity

1. rovinski

   added a parent issue on May 30, 2026

   • ram: feature tracker #9392
2. rovinski

   changed the title [-]Add placement sanity checks to the regression tests (`check_placement`, etc.)[/-] [+]ram: add placement sanity checks to the regression tests (`check_placement`, etc.)[/+] on May 30, 2026
3. rovinski

   self-assigned this

   on May 30, 2026
4. rovinski

   added the

   Feature

   issue type on May 30, 2026
5. rovinski

   added

   ramDFF Ram GeneratorDFF Ram Generator

   on May 30, 2026
6. rovinski commented on May 30, 2026

   

   rovinski

   on May 30, 2026

   CollaboratorAuthor

   More actions

   @tnguy19
7. tnguy19 commented on Jul 7, 2026

   

   tnguy19

   on Jul 7, 2026

   Contributor

   More actions

   FYI/notice on this issue. There's a known error that will happen if placement check is added where RAMs with column muxing will have a layer conflict issue with clock gates.

   Reproduces on make_8x8_mux2_sky130.tcl with check_placement -verbose:

   [WARNING DPL-0010] Blocked layers check failed (8).
    storage_0_0_0.cg ... storage_3_1_0.cg
   [ERROR DPL-0033] detailed placement checks failed during check placement.
   

   Cause of issue is currently believed to be:

   There's a check in src/dpl/src/infrastructure/network.cxx (lines 98-100):

   • If a cell has a pin on met1, also reserve met2 above it for via access

   • Clock gate (sky130_fd_sc_hd__dlclkp_1) CLK pin is on met1, so met2 gets reserved. VDD power stripe also physically sit on met2 at that location leading to this conflict

   • Other cells (DFFs, buffers) have pins only on li1 which is skipped by this check so no conflict is raised

   Routing and functionality still works normally despite this. Will be resolved in a follow-up.
8. github-actions commented on Sep 5, 2026

   

   github-actionsBot

   on Sep 5, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 21 days if no further activity occurs. Remove the Stale label or comment to keep it open.
9. github-actions

   added

   StaleA stale PR or issue subject to automated closure.A stale PR or issue subject to automated closure.

   on Sep 5, 2026
10. maliberty

    removed

    StaleA stale PR or issue subject to automated closure.A stale PR or issue subject to automated closure.

    on Sep 5, 2026