Adding mechanisms to avoid unnecessary swizzle conversions.

[gus-bonilla-86]

Description & Motivation

The use of swizzle conversions could be unnecessary in the generated SystemVerilog code when there are assignments between a LogicArray with 1 dimension (packed), and a Logic of the same width. This changes add mechanisms to identify those cases and replace the swizzle conversions with simple assignments.

Related Issue(s)

#559

Testing

A unit testing script was created to validate the [SystemVerilogSwizzleOptimizer] functionality.
rohd/test/swizzle_opt_test.dart

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?

The [SystemVerilogSwizzleOptimizer] class was added with its code documentation, no need to add more.
rohd/lib/src/utilities/swizzle_opt.dart

[mkorbel1]

I'll take a deeper look through this as soon as possible, but at first review, I'm a little concerned about the approach of post-processing generated SystemVerilog with regular expressions rather than modifying the generation mechanism before SystemVerilog is generated.

For example, the _collapseArrays flow in the SystemVerilogSynthesizer stack handles collapsing of assignments more generically by reference before SystemVerilog is emitted:

rohd/lib/src/synthesizers/systemverilog.dart

Line 1284 in 4413925

void _collapseArrays() {

Is there a reasonable way to transform your algorithm to apply more generically pre-SV generation? My intuition is that it would become more robust and less brittle to specific SV generation styling, since these regular expressions are not as robust as a full SystemVerilog parser anyways.

Another consideration is that generated SV may contain "custom" SystemVerilog modules written by users, and we wouldn't want to modify those at all.

[mkorbel1]

In this PR and #586, the implementation should really be from the perspective of generation rather than post-processing of SystemVerilog output. As implemented, this is a Dart implementation of a SystemVerilog code modifier. Unfortunately, that approach won't work well for ROHD's applications:

• Code generation may change, and this implementation without a full SystemVerilog parser is not robust to those types of changes
• Custom SystemVerilog modules in ROHD may have their own specific style and implementation, and it breaks the API contract to modify that code

A couple ways this could be implemented:

• Keep it in ROHD, and move the algorithmic manipulation inside the synthesizer stack
• Make a SystemVerilog "beautifier", similar to verible, which contains these features. This probably doesn't belong in the ROHD repo, and would be a substantial effort to build.

Happy to discuss ways to migrate over to the right spot in ROHD if you need more guidance!

[mkorbel1]

I think this PR is not on a trend where it will be merged into ROHD, so I'm closing it. Thank you for the time you've spent on this, and the original issue is still worth addressing, but this approach isn't quite right. If you'd like to continue on this development with an adjusted approach, we can either re-open this PR or open a new one.