Update yosys submodule#46
Draft
github-actions[bot] wants to merge 213 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>
…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
7 times, most recently
from
a449acb to
9fe902e
Compare
github-actions
Bot
force-pushed
the
update-yosys
branch
from
9fe902e to
d936cfd
Compare
…viewer bazel: enable Blender 3D-viewer targets on every supported-PDK design
Signed-off-by: Arthur Koucher <arthurkoucher@precisioninno.com>
Signed-off-by: dsengupta0628 <dsengupta@precisioninno.com>
Signed-off-by: Arthur Koucher <arthurkoucher@precisioninno.com>
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