Central synthesizer naming#652
Open
desmonddak wants to merge 46 commits into
Open
Conversation
Closed
mkorbel1
requested changes
Apr 17, 2026
mkorbel1
left a comment
mkorbel1
left a comment
Contributor
There was a problem hiding this comment.
I haven't finished reading it all yet, but first pass a few questions
mkorbel1
requested changes
May 3, 2026
mkorbel1
left a comment
mkorbel1
left a comment
Contributor
There was a problem hiding this comment.
This is looking pretty good, thank you for refactoring it this way, I can see how it helps your other upcoming changes!
…al/instance naming routine names
mkorbel1
requested changes
May 7, 2026
mkorbel1
left a comment
mkorbel1
left a comment
Contributor
There was a problem hiding this comment.
Looking close now to mergeable!
mkorbel1
reviewed
Jun 10, 2026
Clarify comment Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
This aligns central_naming with the simplified naming approach already adopted by all downstream branches (module_services, netlist, source_debug, systemc_trace, fst-writer). Changes: - Remove Namer._instanceNames cache field - Remove Namer.instanceNameOf(Module) method - Update synthesizers to use Namer.allocateName(String) directly - Remove destination tracking from _BusSubsetForStructSlice Benefit: Eliminates duplication across 5+ branches, making each branch truly orthogonal and mergeable without conflicts. Trade-off: Instance names no longer cached across synthesis passes, but all downstreams already use this simpler approach.
# Conflicts: # tool/gh_codespaces/install_dart.sh
instanceNameOf(Module) allocates a collision-free instance name on the first call and returns the cached result thereafter. The _instanceNames Map is keyed by Module.instanceNameKey so repeated synthesis passes over the same hierarchy always produce stable names. This method belongs in central_naming because it is pure naming infrastructure with no dependency on any feature branch.
- Update comment: 'allocateName' → 'instanceNameOf' - Add 'submodule instance names are stable across repeated definitions' test (the canonical 'run synthesis twice, same names' regression test) Both belong here since they directly exercise Namer.instanceNameOf, which is now defined in central_naming.
SynthSubModuleInstantiation.pickName was calling namer.allocateName() directly, bypassing the _instanceNames cache in Namer.instanceNameOf. This caused the second SynthModuleDefinition build over the same module hierarchy to see 'inner' already taken and allocate 'inner_0' instead. Fix: call namer.instanceNameOf(module) which caches on first allocation and returns the same name on subsequent synthesis passes.
Two new tests in 'shared instance and signal namespace': 1. 'instance name wins the shared namespace; signal gets the suffix' Asserts deterministic ordering: non-reserved instances are picked before non-reserved signals, so the instance keeps the bare name and the colliding signal is uniquified to inner_0. 2. 'instance-signal collision resolution is stable across repeated synthesis passes' Calls generateSynth() twice and verifies the module body is identical (timestamp stripped). Guards against name drift where the second pass would assign different suffixes.
mkorbel1
requested changes
Jun 23, 2026
mkorbel1
reviewed
Jun 25, 2026
| } | ||
| } | ||
|
|
||
| List<SynthLogic> _signalsInModuleOrder(Iterable<SynthLogic> signals) { |
Contributor
There was a problem hiding this comment.
what's the point of this function? order is somewhat arbitrary, no?
Contributor
Author
There was a problem hiding this comment.
Logic's declared first get priority. Maybe this should say 'source order'. Once you are in SynthLogic, you have unordered sets, so the naming is truly arbitrary unless we use this routine.
Contributor
There was a problem hiding this comment.
Actually, surprisingly, the default Set implementation in Dart is a LinkedHashSet which iterates in the same order as things were added. I think we can rely on that for consistent ordering of identical hardware? It may be ordered based on something opaque (e.g. connectivity and construction order) but at least it is consistent?
Contributor
Author
|
I use Resolve if I think I have fixed. I accidentally thought I had resolved one I had not in the last round. But otherwise, you may not know I have read and attempted a fix. |
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
2 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.
Description & Motivation
Migrate synthesis naming to a central namer so that all synthesizers (and even WaveDumper) can agree on signal naming.
This is needed for a new synthesizer to be added (netlist).
Related Issue(s)
None.
Testing
I ran existing examples in ROHD and compared SV.
I added extensive test matrix
test/naming_cases_test.dartfor the combinations of naming options (reserved, mergeable, etc) for which I generated tests that pass before and after the central naming.Two bugs were filed: bug #648 and bug #649 which are fixed in PR # 650 for the traditional SV code as well as in this PR for central naming).
I ran a very, very, very large design example and compared SV before and after.
Backwards-compatibility
Naming is slightly different due to ordering, so when we do have collisions, we will see _0, _1 on different signals. Plus the two bug fixes involving unnamed substructures and repeated const names.
Documentation
No. None needed.