Typed operations

[desmonddak]

Description & Motivation

Our ROHD operations flatten attached structured signals, LogicArray and LogicStructure to Logic, and we lose abstraction. This is especially noticeable when composing modules that share these structured types, and it shows up when we netlist or produce other outputs that could retain this structure.

Really, a Mux can be interpreted as a Mux<T> where the baseline case is Mux<Logic>. We know the data input is the actual type, and so we can even infer the output type. Tricky cases exist when we pass in Const, so those need careful handling.

Note that this also needs to handle the new TypedLogicArray type, so this PR is based on PR #686.

This PR also has support for Const LogicStructure to support fixing ROHD-HCL Closes #200

Closes #426
Closes #559
Closes #587
Closes #615

Related Issue(s)

Testing

All existing tests pass. Several new tests, including some changes to the netlister, help validate this approach.
Especially issue #559 which has specific tests to keep the fix narrow.

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?

Yes. Changes were added to mentions of the operators and in the LogicStructure and LogicArray areas.

[mkorbel1]

Keeping structures and arrays intact through operations would remove a lot of reconstruction at call sites. I think we should build that capability into the existing APIs and shared machinery, rather than introduce parallel typed operation and pipeline families. The comments below suggest that direction and raise a few choices for us to work through, including output construction and whether a small, explicit compatibility break for constant inputs is worthwhile.

These proposed API upgrades would introduce breaking changes. For example, existing calls that flop a plain Const could need an explicit <Logic> type argument. If we accept that direction, we'd need to publish it as ROHD 0.7.0, rather than another 0.6.x release, and include migration notes for the affected calls. That release implication is part of the tradeoff for us to agree on, not just an implementation detail.

I've focused this pass on architecture and API design in the typed-operation increment, rather than re-reviewing the older #686 snapshot included in this branch. Bringing in the current #686 work would give us the integrated design for the next pass. Once we've worked through these decisions, we can follow up with the detailed correctness review.

Verification so far is limited: six focused existing tests passed at the reviewed head, including Icarus build-only checks for the structured-constant mux, flop, and passthrough. That is not a full-suite result or complete verification of constant handling and the packed/unpacked/mixed-array emission paths discussed below. Constants need thorough coverage across the affected typed APIs; the existing passing cases do not establish that coverage.

One nonblocking note: there is some formatting-only churn mixed into the change. It may be fine here; the main thing is that we avoid changes that the normal formatter would immediately reverse. We can use AI-assisted comparison to separate that noise from the semantic changes during review. The 27 incremental library files passed the non-writing formatter check under Dart 3.13.0, so I haven't found a formatter-stability problem.