ucb-bar/chiseltest

Support for post-syn testing

ducky64 opened this issue · 3 comments

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.

@seldridge, @jackkoenig ?

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
  * @tparam A the type of the [[Module]]'s IO
  */
trait Spec[A <: Record] { this: Module =>
  override val io: 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.

Related: #2

ekiwi commented

I think this is out of scope right now.