Repository navigation
Register XEZIM_BIND_AUDIT and initialize the identifier binding (§23.9) - #963
philipaxer wants to merge 6 commits into
Conversation
The object model builds the tree on its own parse and reads each construct's implicit name. A directly nested branch opens no generate scope; its inner blocks are walked in the enclosing scope.
Each HierarchicalIdentifier built by the simulator starts unbound. The audit variable is listed in the env var registry.
|
Integrated by cherry-pick with @philipaxer's authorship preserved, as the whole series: xezim-core 38f31c3…d802056 (core #171–#183) and xezim 163df958…554812e6 (#962–#981). Each layer has a code commit and a test commit, with #952 in the subjects. The per-layer "Sync core revision" commits were replaced by one sync to the final core revision. Follow-ups for gaps found in review, each checked against the reference simulator:
Two cases are left: a Published in xezim 603c9bf3 with xezim-core 212dde0. |
Part 2 of the series for #952, which replaces name-string scoping in generate blocks with a scope tree and a binder. No behaviour change.
Depends on #962: until that merges, this branch also shows its commits. New here:
ae24b8dcRegister XEZIM_BIND_AUDIT and initialize the identifier binding (§23.9)6380eafaTest the bind audit's output and that it changes no artifact byte (§23.9)b2ed1df0Sync core revisionCore side: aionhw/xezim-core#172 (pinned at
420f850; the last commit, "Sync core revision", sets the pin).Changes:
boundis initialized at each identifier the simulator builds.XEZIM_BIND_AUDITis in the env var registry.Tests:
tests/hierarchy/bind_audit.rs: audit output, and no artifact byte changes.The audit results, memory cost and what is not covered are in the core PR.
Tests after the rebase onto main
Rebased onto core
5b0b02eand xezim2e4e7f99. The results above were measured before the rebase, against the previous PR of the series.cargo test: 443 passed, 0 failed.cargo test --release --test hierarchy(built without LTO): 784 passed, 0 failed.The series
This PR is one part of a stacked series for #952. This section is the same in every part, so each PR can be read on its own.
Problem. A generate block is a scope (§23.9, §27.5, §27.6), but xezim resolved names in generate blocks by string. The elaborator renamed declarations textually (
f→g.f) from per-block name lists, and the simulator retried a missed name by its last segment at run time. Each fix to that scheme, including the one for #897, broke other legal programs: a local hiding a block function was renamed anyway, items outside the copied list kept the bare name, two unlabelled blocks with the same variable collided, a child instance's call reached the wrong parent, anddisable g.tmatched by leaf.Approach.
scope_tree.rs).elaborate/bind.rs).g.f,u.g[1].x,genblk2.t) are the keys the runtime already uses, so xezim needs almost no source change.XEZIM_BIND_AUDIT=1prints each binding next to what the rename did, so every disagreement can be listed.Parts (core / xezim; each depends on the one before and repeats its commits until that merges):
genblk<n>, §27.6 zero padding, §27.5 direct nesting) come from itdisableby path and by label is bound like other names (§9.6.2)genblk<n>Independent of the series: #969 (time scope and clocking of a block in an instance) and #970 (a subroutine with no written lifetime stays static on the compiled tier).
Still to come.
The run-time retries by leaf name stay. They serve shapes the binder cannot decide before the run (a class method calling its instance's task,
g[k].f()with a variable index, virtual interfaces) and name resolution outside generate blocks (interface ports,$root, packages).Size so far (parts 1 to 13 against main): core +4,476/-1,066 outside tests (net +3,410), +2,458 tests; xezim +198/-101 outside tests, mostly the core pin, +3,550 tests.
Testing. Every part passed the full xezim suite and the core suite before the rebase onto main. After the rebase, part 7 passed the full suites on main, and parts 8 to 13 passed the
hierarchyand core suites. CI runs the rest. Each part's audit and artifact identity against the previous part are in its own text. Expected values come from IEEE 1800-2023 and are checked against Verilator 5.055 where it accepts the program.Review order. Parts 1 and 2 are the base; the rest read from them. Reviewing those two first settles the direction.