Netlist by desmonddak · Pull Request #675 · intel/rohd

desmonddak · 2026-07-02T23:59:59Z

Description & Motivation

This is a netlist synthesizer that produces a netlist for the generated design in an extension of the Yosys output netlist format.
It provides routines for emitting just the hierarchy and ports ("slim" mode) as well as fully expanded and has hooks for even more incremental expansion modes.

Related Issue(s)

None.

Testing

There is a suite of tests that compare the netlist and its names against the SystemVerilog output. This netlist depended on the last central_naming branch to assure that signals in both formats had identical names.

Backwards-compatibility

Is this a breaking change that will not be backwards-compatible? If yes, how so?

No.

Documentation

Does the change require any updates to documentation? If so, where? Are they included?

This is a minor API addition (Module.generateNetlist()) but we will add more documentation and examples of the format, etc.
It will have some options as well, such as multiFile, which should parallel the generateSynth() API.

…agree on names

…al/instance naming routine names

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.

…ning

# 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.

Add regression test for _BusSubsetForStructSlice.instanceNameKey. Each SynthModuleDefinition pass creates fresh _BusSubsetForStructSlice instances for any submodule with a LogicStructure output port. Without the instanceNameKey override those instances use 'this' as the cache key, so the namer allocates a new suffix every pass ('struct_slice' → 'struct_slice_0'). Restoring _destination and overriding instanceNameKey => _destination pins the cache to the stable destination Logic, keeping names consistent. Fixes: _BusSubsetForStructSlice._destination removed in 249b210.

…test

Records which Logic the namer chose as the source of each signal name (an additive reverse map; does not influence naming). Lets source-trace and cross-probe callers attribute a merged net to its declared signal rather than an arbitrary internal signal that merged into the same net.

mkorbel1 · 2026-07-10T18:03:17Z

  }
+
+  /// Returns a synthesized netlist JSON representation of this [Module].
+  String generateNetlist(


i've been sort of regretting having generateSynth at all, maybe long term can deprecate it, but it keeps being convenient. this expansion of the pattern is maybe not great in that regard. what if we instead upgraded the generateSynth to accept a Synthesizer and default to SystemVerilogSynthesizer to maintain backwards compatibility? thoughts?

Please look at the module_services branch. I move away from generateSynth -- not deprecate (yet), but I use a 'Service' that has its own options and output instead of in the Module api

This was ONLY done to make this branch reviewable at this point in time (this 'era' of having generateSynth).

Should we omit it then from this PR if it's going to be removed/deprecated soon anyways?

Tests need it. We will deprecate in module_services_api.

im concerned that once we merge this if we do a release it will become an API that needs deprecation

This PR is designed to come before module_services_api which we are still not completely sure of.
meanwhile, netlist needs tests.
So we could simply mark this as testing only for now.

This is why this PR is from branch netlist_pre. The _pre means before module_services. I tried to peel apart the changes into digestible PRs, but this means things like this need to happen: APIs need to be there for a period and then disappear. I cannot design a perfect merge order, especially when we can't quite agree on the services api.

I marked it @visibleForTesting.

or we can make it an extension only visible in that test that uses it?

mkorbel1 · 2026-07-13T21:34:38Z

@@ -1,7 +1,12 @@
 // Copyright (C) 2024-2025 Intel Corporation


copyright year (and check in general)

I scanned for these. I think this file was indeed changed in 2025 as I started netlist then. But I didn't check, might as well make it 2026 to match the significant amount of changes made.

this still has 2025

mkorbel1

can you pull main also again just so it's up to date?

mkorbel1 · 2026-08-10T21:00:38Z

  }
+
+  /// Returns a synthesized netlist JSON representation of this [Module].
+  String generateNetlist(


or we can make it an extension only visible in that test that uses it?

mkorbel1 · 2026-08-10T21:09:50Z

+/// );
+/// final synth = NetlistSynthesizer(options: options);
+/// ```
+class NetlistOptions {


the systemverilog one uses the word "configuration" instead of "options" (I know I think you came first, sorry, but mine merged first unfortunately), should we align?

mkorbel1 · 2026-08-10T21:12:31Z

+  ///
+  /// This is backward-compatible: Yosys-format arrays already mix
+  /// integers with constant strings `"0"` and `"1"`.  Parsers can
+  /// detect range strings by the presence of `:`.


why do you want this to be exposed as a configurability option? any config you have is something you have to support or else deprecate in the future. this applies to the other ones in here too (e.g. enableDCE)

mkorbel1 · 2026-08-10T21:12:48Z

+  /// When `true`, dead-cell elimination is performed after aliasing to
+  /// remove cells whose inputs are entirely undriven or whose outputs
+  /// are entirely unconsumed.
+  final bool enableDCE;


nit: why not enableDeadCellElimination?

mkorbel1 · 2026-08-17T19:54:53Z

@@ -1,7 +1,12 @@
 // Copyright (C) 2024-2025 Intel Corporation


this still has 2025

mkorbel1 · 2026-08-17T19:59:17Z

+
+import 'package:rohd/rohd.dart';
+
+/// Provides bit ranges and field names for a packed [LogicStructure].


question: this applies to the leaves of a structure if there is hierarchy?

mkorbel1 · 2026-08-17T20:01:36Z

  String get instanceTypeName => getInstanceTypeOfModule(module);

+  /// Non-fatal warnings reported while producing this synthesis result.
+  final List<String> warnings;


In general, been avoiding adding "warnings" to ROHD -- either things are bad and fatal or good and allowed. Trying to avoid warning soup that happens in a lot of EDA flows, where they grow forever to the point where it's just slowing down and bloating logs. Do we really need warnings?

mkorbel1 · 2026-08-17T20:01:52Z

@@ -1,8 +1,10 @@
 // Copyright (C) 2021-2025 Intel Corporation


mkorbel1 · 2026-08-17T20:02:01Z

 export 'synthesis_result.dart';
 export 'synthesizer.dart';
 export 'systemverilog/systemverilog.dart';
+export 'utilities/synth_module_stop_policy.dart';


why export this?

desmonddak and others added 30 commits April 17, 2026 08:30

move synthesis naming to a common naming utility so all synthesizers …

82e900e

…agree on names

dart 3.11 parameter_assignments pickiness

85f88ce

Merge branch 'main' into central_naming

b1de1e5

conflict resolved and dart format . works

b7087c4

properly assign naming spaces for instances vs signals

4a55214

format issue

ed7be36

Controllable enforcement of signal vs instance name uniqueness.

ab09aed

Refactored to Namer class. No external API changes for ROHD

520d280

signal registry

61d0319

module context name uniquification instead of signal/instance split

becdb36

Merge branch 'main' into central_naming

a86f80c

cleanup of port vs signal name assumptions, constant merging and sign…

d5904a6

…al/instance naming routine names

simplified forModule, improved code doc

6dfe0f9

more coverage for Namer

3c90e5d

canonical names at last, even in the comments

42fba62

pesky override rule surfaced again on tutorials file

6a41f8d

new keyring-based installation for dart in codespaces

139280f

new keyring-based installation for dart in codespaces

62e4a2c

keyring-style dart installation rather than holding keys

caecb02

new dart analyzer failure with bad override

089faf8

Merge branch 'override-bug' into new-dart

e015889

Potential fix for pull request finding

1232afb

Clarify comment Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Fix orthogonalized Namer: remove stale instanceNameOf method

8ef6820

Clean DevTools extension analysis and formatting

1225df1

Keep DevTools extension changes on owning branches

c8440c4

added back pubkeys, and made a wget a fallback solution with loud war…

a87fa5c

…ning

Merge branch 'new-dart' into central_naming

d2760eb

# Conflicts: # tool/gh_codespaces/install_dart.sh

desmonddak added 10 commits June 27, 2026 01:19

chore: remove stale moduleOrder signal tests from naming_consistency_…

5130601

…test

feat(Namer): expose public signalNameOf for wave-dumper and tests

7fc952d

cleanup copyright / signalNameOf export

ea3c759

copyright and make method private

32055a9

remove _nameSources backward map, relocate to FLC production

666d211

Split netlist compute layer

f8979b2

formatted

e6fc88a

Merge branch 'main' into netlist_pre

a9b7ada

mkorbel1 reviewed Jul 9, 2026

View reviewed changes

desmonddak added 5 commits July 10, 2026 08:04

Refactor netlist synthesis helpers

f73526d

Fix netlist top marker selection

179fea0

cleanup formatting tail commas

9199a40

filter bank cleanup

0baf624

Move filter bank example modules out of lib

8c48a81

mkorbel1 reviewed Jul 13, 2026

View reviewed changes

desmonddak added 5 commits July 15, 2026 08:22

major bug fixes for LogicArray and LogicStruct

1c7cd05

conflict resolved, sv_gen test fix

cbda4eb

inout fix

57fc237

attempt with better VS links

5a8a25f

bump copyright

8ac1936

mkorbel1 reviewed Jul 22, 2026

View reviewed changes

desmonddak added 5 commits July 24, 2026 07:53

major cleanup from PR comments -- complete at this point

2001f47

much better testing of netlist passes

d43f406

Merge branch 'main' into netlist_pre

ded32ed

false positive on validation fixed

5f7999a

handle inouts properly

1cb81d9

desmonddak requested a review from mkorbel1 August 8, 2026 22:48

mkorbel1 reviewed Aug 17, 2026

View reviewed changes

		@@ -1,7 +1,12 @@
		// Copyright (C) 2024-2025 Intel Corporation


		import 'package:rohd/rohd.dart';

		/// Provides bit ranges and field names for a packed [LogicStructure].

		@@ -1,8 +1,10 @@
		// Copyright (C) 2021-2025 Intel Corporation

Uh oh!

Conversation

desmonddak commented Jul 2, 2026

Description & Motivation

Related Issue(s)

Testing

Backwards-compatibility

Documentation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mkorbel1 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects