Repository navigation
Conversation
Both tool repositories now vendor the same 209 shared files with the same verification/shared.sha256; `cargo xtask shared diff` finds no difference. From the timing tool's side the shared crates gain: the STA store reader of versions 1 and 2 (opt-timing and resize read the tables the timing tool now commits; the builder writes v2 with unchecked design-rule counts), the Liberty pin attributes min_pulse_width_high/low and min_period with LIBERTY v4 rlib caches, the bounded SPEF reader and `rusteda import --spef`, netlist edit files, the RC waveform models and prepared arc values of the compute crate, typed set_propagated_clock/unset_propagated_clock (SDC-REQ-0070) and the honest design-rule status of `rusteda show` (RCLI-REQ-0023; renumbered from the timing tool's unpublished RCLI-REQ-0021, which here names BLIF/AIGER import). set_propagated_clock now reaches opt-timing, which reports it as S0535 like any other clock propagation it does not model (test extended). Synthesis output is unchanged: against the pinned c5ec23c producer, 283 cases (every fixture design on six libraries and two option sets, SERV and PicoRV32 workspace flows on sky130 and gf180) give byte-identical netlists, netlist tables and normalized reports, and the native checker proves all 282 netlists equivalent. Gates: workspace tests 837 passed, verify synth, verify pdk --require, all-feature clippy, fmt, layout, coverage 619/0, fixtures, deny, reuse, strict docs and the benchmark Python tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…et an option The shared netlist import test named a third-party program in its doc comment, function and temporary directory; it now describes the netlist it imports (concatenations, part-selects in both directions, sized constants), and the doc comment of the unresolved-cell test is attached to that test again. Two shared comments that named the timing tool's repository refer to it by its role. The 64 MiB budget of the full Verilog reader, for a netlist that the streaming reader declines, is the option `rusteda import --max-netlist-ast-mib` (default 64, requires --netlist, RCLI-REQ-0024); its V0300 error names the budget and the option. Measured: the full reader peaks at about 42 times the file size (1.07 GiB for a 26 MiB netlist, 95 MiB with the streaming reader), noted in the spec. Default behaviour is unchanged: against the pinned c5ec23c producer and a rusteda built from c5ec23c, 283 synthesis/flow cases are identical (netlists, reports, exit codes, stderr; SERV/PicoRV32 flows on sky130 and gf180 7t) and the native checker finds 282/282 equivalent; `rusteda import --netlist` of the 16 corpus netlists and of a netlist the streaming reader declines gives identical tables. Gates: workspace tests 838/0/19, all-feature clippy, fmt, layout, coverage 620/0, fixtures, shared check/diff (209 files, identical manifest in both tool repositories), verify synth 85/0, verify pdk --require 279/279, deny, reuse, markdown/strict docs/site checks, benchmark Python tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ompute crate The timing tool added rusteda_compute::rc::gate_detail_with_resistance: the bounded charge solve and waveform of rc::gate_detail for a caller-supplied driver resistance, with rc::gate_detail refactored onto the same private solver and unchanged bit for bit (unit test included). rc.rs is copied byte for byte and verification/shared.sha256 is regenerated with `cargo xtask shared update`; `cargo xtask shared diff` is clean in both directions (209 files). No synthesis code calls rc, so synthesized netlists are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…eform wire response in the shared compute crate Additive rc.rs entry points copied byte for byte from the timing tool: rc::gate_one_step (one Newton-Raphson correction of the Thevenin driver's effective capacitance from the total load) and rc::wire_from_driver (sink response of a driver's pi-root waveform through one pole of the sink's first moment). Existing functions are unchanged; manifest regenerated with cargo xtask shared update. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Chang Gao <gaochangw@outlook.com>
Signed-off-by: Chang Gao <gaochangw@outlook.com>
gaochangw
changed the title
This branch has not been deployed
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
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.
The RustEDA integration branch documents bounded synthesis, mapping, shared-foundation integration and the retained five-design/three-library arbitrary-state equivalence evidence. The 2026-10-28 status distinguishes experimental SRAM work from the pinned implementation.
The README and documentation use Signal Forge artwork: a 256×256 mark, a 760×176 wordmark displayed at 360px, and a 1200×400 84-frame banner. Responsive images omit fixed HTML heights.
Validation: source links, strict MkDocs builds and rendered links pass for the integration and standalone documentation. The unified RustEDA site passes publication and repository-boundary checks. This documentation update introduces no algorithm or new EDA performance claim. The branch retains the existing integration changes; standalone main receives a separate documentation-only update and is not merged here.