Add force-empty hwif_in/hwif_out generation options

[Topi-ab]

Description of change

Summary

This PR adds support for forcing HWIF ports to be generated even when the inferred HWIF side is empty.

New capability

• Force empty hwif_in generation.
• Force empty hwif_out generation.
• Keep generated VHDL legal by adding a reserved dummy member only when needed.

What changed

CLI / config / exporter API

• Added CLI flags:
  • --force-hwif-in
  • --force-hwif-out
• Added config keys under [regblock-vhdl]:
  • force_hwif_in
  • force_hwif_out
• Added exporter kwargs / design-state plumbing:
  • force_hwif_in
  • force_hwif_out

HWIF generation behavior

• If an inferred HWIF side is empty and corresponding force flag is enabled:
  • Emit record type with one dummy member:
    • \0_dummy_entry\ : std_logic;
• If inferred side is non-empty:
  • No dummy member is added.

Deterministic generated behavior

• Forced-empty input side:
  • hwif_in : in <type> := (\0_dummy_entry\ => '0')
• Forced-empty output side:
  • hwif_out.\0_dummy_entry\ <= '0';

Tests

• Added new test suite:
  • tests/test_force_empty_hwif/
• Covers 4 scenarios:
  1. no force
  2. force input only
  3. force output only
  4. force both

Validation

Notes

• No behavior change for non-empty HWIF inference.
• Dummy member is emitted only for forced-empty sides.

Checklist

• I have reviewed this project's contribution guidelines
• UNABLE TO TEST - missing the tools. This change has been tested and does not break any of the existing unit tests. (if unable to run the tests, let us know)
• If this change adds new features, I have added new unit tests that cover them.

[darsor]

Hi @Topi-ab, thanks for the PR and the thorough unit tests. Before merging, can you describe what the use case for this new feature would be?

In general my preferred workflow for adding new features to this project is to add them first to the upstream SystemVerilog exporter, then merge them into this repo. That maintains feature parity and ensures users of either language have access to both features.

[Topi-ab]

Hi @Topi-ab, thanks for the PR and the thorough unit tests. Before merging, can you describe what the use case for this new feature would be?

Hi,

The need is to have consistent interface to/from the regblock even when e.g. read direction has zero signals.

As the code is now, the interface signature changes depending on RDL contents.

With the change on this PR, the signature can be forced to be constant (the record content changes, but the record itself is listed on port declaration, even if empty).