Open
Description
The root cause of both issues is that the BlackBox IO object itself doesn't actually get emitted as FIRRTL, only its children are. So operations on that IO object would become invalid if emitted to FIRRTL, and any properties of it (like flipped-ness) are dropped.
The second is possible to fix by special-case logic in the emitter, and the first is (probably?) already worked around by resolving bulk-connects at the Element (leaf) level in Chisel. But the underlying issue is still there, and if we ever start emitting bulk connects again it will break.
Potential solutions:
- More and more special casing. Very ugly, high likelihood of missed edge cases and bugs.
- Deprecate the "legacy"
BlackBox
interface in favor ofExtModule
, which supports multiple top-level IO objects and doesn't do this special IO unwrapping. Possibly also introduce an "all IOs" function that returns all the top-level IOs as a record or record-act-alike object. Side note: this may be of interest toMultiIoModule
users? - Have the top-level BlackBox IO be dummy object that emits connects and stuff at its immediate children level, instead of being an actual object in the hardware graph. Unclear if this can work without requiring changes to user BlackBox code, since the IO
Bundle
would no longer be aBundle
. - Something else?