Skip to content

Blackbox IO doesn't actually "exist" #633

Open
@ducky64

Description

@ducky64

Related: #249 and #282.

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 of ExtModule, 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 to MultiIoModule 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 a Bundle.
  • Something else?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions