You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 19, 2024. It is now read-only.
Apparently a requirement for practically building chips.
Ideas:
Support for using blackbox as the module passed into a test() function, so that we don't need to re-elaborate to Chisel circuit.
Separation of circuit interface (potentially the blackbox solution as above, or a full Chisel elaborated module that we discard the circuit for) and implementation (which you can plug in a separate Verilog module or something)
Potentially a blackbox where you can specify a FIRRTL file, or some other file that contains data like combinational paths for cross-thread-ops checking or implicit clock resolution.
I have viewed the second bullet point as the critical problem and path to a solution. Chisel intermixes specification (IO) and implementation (module internals) whereas other languages opt to make this explicit (VHDL has specification/implementation). Because of this, it's difficult in Chisel to think about abstracting over implementations.
I've used the following recently as something towards this:
/** A [[Module]] mixin that exposes the type of the underlying IO * @tparamA the type of the [[Module]]'s IO*/traitSpec[A<:Record] { this:Module=>overridevalio:A
}
I was then able to write tests for any Module with Spec[A]. However, there then needs to be some means to convert between different module types and blackboxes. A typeclass interface object pattern worked here with toLegacy and toBlackBox methods.
This is likely related to programmatic IO discoverability.
Apparently a requirement for practically building chips.
Ideas:
@seldridge, @jackkoenig ?
The text was updated successfully, but these errors were encountered: