Unused outputs can be controlled by logic outside the module

[chykon]

Describe the bug

Unused outputs can be controlled by logic outside the module.

To Reproduce

import 'package:rohd/rohd.dart';

class Example extends Module {
  Logic get out => output(_out.name);
  late final _out = addOutput('out');
}

void main() async {
  final example = Example();
  final logic = Logic();
  example.out <= logic;
  await example.build();

  print(example.out.value);
  logic.put(1);
  print(example.out.value);
}

Expected behavior

The outputs are controlled only by the module itself.

Actual behavior

Unused outputs can be controlled by logic outside the module.

Additional: Dart SDK info

No response

Additional: pubspec.yaml

No response

Additional: Context

ROHD v0.4.2

[mkorbel1]

ROHD actually is architected in a way that makes this hard/impossible to detect depending on how it is done. The hierarchy of modules is defined by the connectivity of wires, not by where the logic is declared. While the "normal" case is that you want all the logic associated with a Module to be declared "within" that Module, in reality logic could be generated by functions, classes, etc. that live anywhere and apply the logic to be connected within that module.

This can be leveraged as a strength, even in some sort of weird scenarios. For example, imagine building up some hierarchy of hardware modules, then later wanting to generate logic that stitches something throughout the hierarchy from a utility that sits "outside" all of those modules. As long as the connectivity lines up in a reasonable way (i.e. logic doesn't connect between modules without going through ports to get there), then that can be achieved legally.

Does this answer your concern? Do you have any thoughts on a specific scenario where this methodology poses a problem? Is there some check you wish was there that would prevent "bad" things without overly restricting "intentional" things?

[chykon]

Thank you for the clarification! I didn't even think about such use cases.

Does this answer your concern? Do you have any thoughts on a specific scenario where this methodology poses a problem? Is there some check you wish was there that would prevent "bad" things without overly restricting "intentional" things?

After you explained that ROHD uses a connectivity of wires to build the module hierarchy, I have nothing more to offer. I am not particularly familiar with the development of logic simulators/synthesizers and hardware, so I can point out supposedly “wrong” things that I don’t have enough experience and knowledge to understand. Thank you for being patient and talking about the design of this or that solution.

I think I will close the problem, since a detailed answer was received.

[mkorbel1]

Glad it clarified, thanks for filing! It's very helpful to hear feedback and concerns even if not all of them directly lead to a code change. Perhaps some documentation could be improved somewhere to make this more intuitive. It is a significant change from writing code in SystemVerilog, though.