Update yosys submodule#48
Draft
github-actions[bot] wants to merge 219 commits into
Draft
Conversation
Signed-off-by: Martin Povišer <povik@cutebit.org>
Signed-off-by: dsengupta0628 <dsengupta@precisioninno.com>
- Created docker/setup_compiler_wrappers.sh for reproducible builds - Updated Dockerfile.dev and Dockerfile.builder to use the shared script - Fixed typo 'scrip' -> 'script' in build_openroad.sh help text Signed-off-by: Vi-shub <smsharma3121@gmail.com>
Signed-off-by: Vi-shub <smsharma3121@gmail.com>
Signed-off-by: dsengupta0628 <dsengupta@precisioninno.com>
Signed-off-by: dsengupta0628 <dsengupta@precisioninno.com>
Signed-off-by: dsengupta0628 <dsengupta@precisioninno.com>
Signed-off-by: dsengupta0628 <dsengupta@precisioninno.com>
Signed-off-by: dsengupta0628 <dsengupta@precisioninno.com>
Signed-off-by: Jack Luar <jluar@precisioninno.com>
Signed-off-by: Jack Luar <jluar@precisioninno.com>
Signed-off-by: dsengupta0628 <dsengupta@precisioninno.com>
os.path.realpath() follows symlinks. Inside a Bazel sandbox, the bazel-out/ tree is symlinked from the sandbox back to the bare execroot; realpath resolves through that symlink and yields the bare-execroot path, not the sandbox path. That alone doesn't matter for os.path.relpath(a, b) when both operands are realpath'd from the same sandbox — the relative result is unchanged. But the resulting <lef-files> path in the generated klayout.lyt is later resolved by klayout against the LYT file's location. Klayout opens the LYT (also through a symlink), resolves through to the bare execroot, and then looks for the sibling klayout_tech.lef at the bare-execroot path — where the in-flight file does not exist during action execution (only the sandbox copy does), so def2stream fails with errno=2. Fix: don't realpath. os.path.relpath produces the correct relative path from sandbox-relative inputs directly. Map files keep their absolute form via abspath for the unchanged-under-non-sandbox case. Surfaced for the first time on bazelisk build //flow/designs/sky130hd/gcd:gcd_final_blender_html — the orfs_blender macro is the first bazel-side consumer of orfs_gds (klayout def2stream), so the latent path bug had no prior trigger. Mirrors bazel-orfs's patches/0037-fix-generate_klayout_tech-drop-realpath.patch into ORFS directly so bazel-orfs no longer needs to carry it. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
The previous switch to relpath (commit 01652ca) cleaned up the content but did not actually fix def2stream's errno=2 under a Bazel sandbox. Investigation via strace shows klayout's Layout.read(def, layout_options) opens the input DEF (a sandbox symlink to the bare execroot, staged from orfs_final), realpath's it to the bare-execroot results dir, and then resolves <lef-files> relative paths against THAT dir. Sibling intermediates like objects/klayout_tech.lef only exist in the per-action sandbox, not at the bare execroot, so the lookup lands at .../execroot/_main/bazel-out/.../klayout_tech.lef and fails with errno=2. Declaring klayout_tech.lef as a Bazel output of orfs_gds doesn't help -- Bazel only materialises declared outputs at the bare execroot at action completion, not while the action is still running and klayout is reading them. Plain abspath (NOT realpath -- realpath would chase Bazel input-file symlinks back out to the bare execroot for any input already at the bare execroot) writes the in-sandbox absolute LEF path into the LYT. KLayout opens that absolute path directly with no relative-path resolution involved, so the sibling lookup never escapes the sandbox. Cost: the LYT's content now embeds the per-invocation sandbox number, so the orfs_gds action cannot be cross-action cached. That's an acceptable trade-off for correctness while we wait for a klayout-level fix or a Bazel feature that lets us write a stable bare-execroot path from inside the action. Confirmed end-to-end: bazelisk build //flow/designs/sky130hd/gcd:gcd_final_blender_html produces 6_final.gds and the blender_html sh_binary, with both the sandbox sandbox-id N going forward and after fresh action re-runs (verified by deleting outputs and rebuilding). Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Earlier commit a1552a8 switched generate_klayout_tech.py to write absolute LEF paths into the LYT (bypasses klayout's relative-resolution escape to the bare-execroot under a Bazel sandbox). The unit test test_basic_generation still asserted the old relpath form and failed in CI: AssertionError: '../tech.lef' not found in '...<lef-files>/tmp/tmpwlgkq96a/tech.lef</lef-files>...' Update the assertion to expect os.path.abspath(lef_path). Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
…orkaround
Two pieces, bundled because they only make sense together:
1. Bump bazel-orfs ce6efd9 -> 3a5ddd7 (~80 commits of upstream main).
This pulls in the orfs_blender() rule plus the layerstack-trim
`_LAYER_PRESETS` heuristic in render_gds.py. The previously
vendored //bazel:0001-orfs_design-add-user_sources.patch is now
upstream as of 5b65b4e so it goes away.
2. Flip `blender = True` once in flow/designs/design.bzl's design()
funnel so every design routes through the same blender-supported
branch. Designs whose PDK has no BlenderGDS stackup (asap7,
nangate45, ...) silently no-op via the upstream
`blender_supports_pdk` predicate.
A small vendored patch on render_gds.py works around a real bug in
the BlenderGDS addon (`UnboundLocalError: pdk_info` inside
import_gdsii's custom-config branch); routing the trimmed YAML
through `addon.PDK_CONFIGS[pdk]['config_path']` instead of
`gdsii_use_custom_config = True` avoids the bug. TODO: upstream the
fix to aesc-silicon/BlenderGDS and drop this patch.
End-to-end on sky130hd/microwatt (a 562 MB merged GDS), the trim
heuristic produces a 123 MB GLB and a 158 MB self-contained HTML
viewer in ~71 s of wall time once synth/place/route are cached.
gcd-class designs already fit under the addon's full default
layerstack so the preset is a no-op for them.
Usage:
bazelisk run //flow/designs/sky130hd/gcd:gcd_final_blender_html
opens the resulting model-viewer page in the default browser via
xdg-open.
Signed-off-by: Øyvind Harboe <oyvind@ascenium.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
github-actions
Bot
force-pushed
the
update-yosys
branch
from
4cbb275 to
e6c019c
Compare
oharboe
force-pushed
the
post-slang-state-hash
branch
2 times, most recently
from
18499f9 to
fffb07a
Compare
github-actions
Bot
force-pushed
the
update-yosys
branch
2 times, most recently
from
bffbc3d to
5bb1b00
Compare
…enROAD-Project#4234 Two follow-ups from gemini's review of The-OpenROAD-Project#4234: * The map-file test in test_with_map_files still asserted `os.path.realpath(map_path)`, inconsistent with the LEF test's `os.path.abspath` switch. On platforms whose tmpdir contains symlinks (macOS /var -> /private/var) the test would fail. Switch to `os.path.abspath` to match the LEF case. * `reference_dir` and `use_relative_paths` are now both unused. Update the function docstring to say so, default both to `None` / `False` so callers can drop them, and demote the CLI flags to `required=False` so external scripts that don't pass them still work. flow/Makefile still passes `--reference-dir` so we keep accepting the flag. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
github-actions
Bot
force-pushed
the
update-yosys
branch
from
5bb1b00 to
5de721d
Compare
…ect#4234 Three follow-ups from gemini's second review pass: * Restore the original positional argument order (template_lyt, output_lyt, lef_files, reference_dir, map_files, use_relative_paths) so Python callers that pass the args positionally still work. Prior fix reshuffled `map_files` ahead of `reference_dir`, breaking positional compatibility. * Re-order the Args block in the docstring to match the new signature order. * `map_files` is now `None`-defaulted (to keep the positional-order fix above), so iterate via `map_files or []` rather than dereferencing `None` directly. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
github-actions
Bot
force-pushed
the
update-yosys
branch
2 times, most recently
from
a449acb to
9fe902e
Compare
The C values in setRC.tcl were placeholders ("the ICT shipped with the
PDK does not contain extracted C ... should be replaced with values
from a calibrated RCX/QRC model before treating any C-derived quantity
as physical"). The R values were derived from Fig 1(b) of the GT2N
paper and were already grounded, but the via R was a fake "scaled
roughly by cut size" stand-in.
The PDK's StarRC ITF file (GT2N/nxtgrd/GT2.itf) carries enough physical
data to derive both R and C analytically: per-layer RPSQ, dielectric
thickness and permittivity above and below each conductor, conductor
thickness, WMIN, SMIN, and per-VIA RPV. Use those to compute:
R/um = RPSQ / WMIN
C/um = (Ca + Cb) * fringe_factor + 2 * Cc (fF/um, then to pF/um)
Ca = eps0 * eps_above * W / d_above
Cb = eps0 * eps_below * W / d_below
Cc = eps0 * eps_side * T_wire / SMIN
fringe_factor = 1.5x coarse fringe-field correction
Via R = RPV (single via, from ITF VIA entries)
itf_to_rc.py drops next to the platform so the derivation is
reproducible; setRC.tcl is its output rendered into set_layer_rc
commands plus the existing set_wire_rc selections.
These numbers are still approximate -- the proper fix is real RCX
extraction (run a 3D solver, e.g. FasterCap, against OpenRCX's pattern
DEFs and feed the resulting SPEF to OpenRCX generate_rules.tcl). The
ITF/NXTGRD/QRC files in GT2N/ carry everything that pipeline needs.
The analytical table is the working stand-in until those rules exist.
Smoke (gt2n/gcd full flow): clean, EXIT=0. Achieved core_clock period
moves from 373.6 ps (placeholder C) to 344.6 ps (analytical C); slack
goes from 106.8 ps to 137.3 ps. Lower C reduces wire delay, so timing
reports tighter -- consistent with the analytical C being ~33-60%
below the placeholder, which itself had no physical grounding.
Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
Default tapcell.tcl was using `-distance 5` (5 um between taps along each row), which is loose enough that small designs end up with a single tap column. The gt2n tap cell does double duty: it is both the well/body-bias tap (the conventional purpose) and the per-row M1<->BPR or sole BPR riser for the BSPDN power network -- each tap is the only hard via from the cell row's BPR rail into the BSPDN power source. Tap density therefore directly sets per-row BPR resistance and the worst-case BSPDN IR drop, which is not true in flows where taps only exist for latchup avoidance. Drop `-distance` to 2 um. On gt2n/gcd (4-5 um core side, 55 rows): -distance 5 2 tapcells 28 114 (+4x) vdd worst 10.9 mV 8.49 mV (-22%) vdd avg 2.62 mV 2.59 mV vss worst 7.25 mV 7.35 mV (essentially same, already well distrib) vss avg 2.27 mV 2.27 mV (IR numbers from analyze_power_grid on 6_final.odb with leakage-only currents -- absolute drop is small at this design size, but the worst-case-vdd improvement is what we expect from more BPR risers.) Detail-route runtime goes up roughly 3x because of the denser obstacle field, but converges cleanly to 0 DRC + 0 antenna. Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
Adds jpeg_encoder as a larger reference benchmark alongside gcd and aes -- representative of designs that meaningfully exercise the upper-stack routing layers and the multi-W / multi-Vt library menu. config.mk mirrors the asap7 / nangate45 jpeg configurations (ABC_AREA=1, TNS_END_PERCENT=100, conservative CORE_UTILIZATION). constraint.sdc uses a 1500 ps clock as a first-pass loose target; period_min lands around 950 ps so the design has substantial headroom to tighten once OpenRCX rules replace the analytical RC. Signed-off-by: Matthew Guthaus <mrg@ucsc.edu>
The platform exposes metal up to M13, but the reference designs route well below that (gcd uses up to M5, jpeg M9, aes M10; layers above carry no wire). Pinning MAX_ROUTING_LAYER at the platform M13 top forced detailed routing to build its grid graph, via stack, and DRC checks across the full layer range for every design, inflating runtime and memory. Move MAX_ROUTING_LAYER out of the platform config (leaving a comment) and set it per design at the highest layer each actually uses. gcd@M5 was verified to route DRC-clean; aes/jpeg caps only drop layers that carry zero wire. Signed-off-by: mrg <mrg@ucsc.edu>
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
Note where GT2.itf comes from (the StarRC interconnect tech file shipped with the GT2N PDK, not in this repo) and the matching NXTGRD/QRC files, mirroring the existing setRC.tcl header, and point readers to the platform README for additional GT2N information. itf_to_rc.py also flags that __main__ hardcodes a local path to the ITF that must be adjusted to a local PDK copy. Comments only. Signed-off-by: mrg <mrg@ucsc.edu>
…t-staging/update-or update OpenROAD
Add rules-base.json baselines for the gcd, aes, and jpeg gt2n designs, generated via 'make metadata' + 'make update_ok' from a clean run at each design's committed MAX_ROUTING_LAYER (M5/M10/M9) on the pinned OpenROAD. All three route DRC-clean; metadata-check passes with 0 failures/warnings. This gives the gt2n designs CI metadata baselines (previously absent). Signed-off-by: mrg <mrg@ucsc.edu>
gt2n: add 2nm BSPDN platform with gcd and aes designs
The phony check-klayout target was a normal prerequisite of $(GDS_MERGED_FILE), which forced the KLayout def2stream merge to re-run on every `make finish`/`make metadata` invocation regardless of whether the GDS inputs had changed. Moving it behind `|` keeps the KLayout availability check when the GDS needs building, without marking the GDS perpetually out-of-date. Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
…t-staging/fix-gds-rebuild-check-klayout Make check-klayout an order-only prereq of merged GDS
Update the OpenROAD submodule to the private secure-fix-cts-propagated-clock commit that preserves virtual clock latency during CTS. This lets the SDC virtual IO clock latency changes affect post-CTS timing and downstream QoR in CI. Only the OpenROAD submodule pointer is changed. Signed-off-by: Jaehyun Kim <jhkim@precisioninno.com>
…agated-clock # Conflicts: # tools/OpenROAD Signed-off-by: Jaehyun Kim <jhkim@precisioninno.com>
Update metadata golden files for the public PR-4294 merge run. Use the PR-4294-merge #10 report metrics for designs that failed the public inline metric comparison so the expected metric baseline matches the virtual IO clock constraints. Signed-off-by: Jaehyun Kim <jhkim@precisioninno.com>
Revert the deprecated metadata-base-ok.json updates from the previous metric rebase. Update rules-base.json for the public PR-4294 merge run using the reported metrics so the public metric checks match the virtual IO clock constraints. Signed-off-by: Jaehyun Kim <jhkim@precisioninno.com>
Update the gf12 ariane rules baseline from secure CI build 16. Relax the CTS setup TNS rule to match the virtual IO clock timing result while keeping deprecated metadata-base-ok.json files untouched. Signed-off-by: Jaehyun Kim <jhkim@precisioninno.com>
Add an empty commit to retrigger the public PR merge CI after the rules rebase. Signed-off-by: Jaehyun Kim <jhkim@precisioninno.com>
…t-staging/ci-jobname-support ci: support for jobName flag and v3 messages
…t-staging/secure-fix-cts-propagated-clock flow: Use Virtual Clocks for IO Delays
Allows you to see the data in the inspector. Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
…t-staging/view_cells-with-liberty Load the Liberty in view_cells.tcl
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
…t-staging/update-or update OR for pdn changes
github-actions
Bot
force-pushed
the
update-yosys
branch
2 times, most recently
from
34ebafe to
b22f45b
Compare
Add flow/util/plot_wns.py, a local (no-bazel) script that reads the committed rules-base.json baselines and regenerates, per PDK, a worst-setup-slack bar chart (wns.png) and a "## WNS" README section between generated markers. It covers all 9 PDKs that ship timing baselines (76 designs); the bar is finish-stage WNS, with cts and globalroute drawn as markers so stage-to-stage movement is visible. No OpenROAD/ORFS run is required -- the data already lives in the tree, so the plots are deterministic and the committed PNGs + tables render on GitHub with nothing to run. asap7/README.md additionally carries a hand-written findings section discussing the results. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
github-actions
Bot
force-pushed
the
update-yosys
branch
from
b22f45b to
850b412
Compare
Extend plot_wns.py to quantify how well the cts and globalroute worst-slack estimates predict the final WNS. Each design's per-stage error (stage - finish) is normalized by its clock period, parsed from the .sdc, so PDKs with different timing units are comparable. Adds flow/designs/wns_accuracy.png (per-PDK strip plot of normalized estimate error, + optimistic / - pessimistic) and a new flow/designs/README.md with a "## WNS estimate accuracy across PDKs" section: a per-PDK MAE/bias table plus hand-written findings. Covers the 67 designs across 8 PDKs that expose cts/globalroute slack and a parsable clock period; the rest are noted as omitted. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
github-actions
Bot
force-pushed
the
update-yosys
branch
from
850b412 to
c0c0737
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated changes by create-pull-request GitHub action