chisel2-deprecated icon indicating copy to clipboard operation
chisel2-deprecated copied to clipboard

Make Chisel test benches more like software unit testing

Open doughnit opened this issue 10 years ago • 0 comments

Testing frameworks like JUnit are more self-contained and simpler to use: you just declare a test, define set-up and tear-down functions, and the system automatically finds all the tests to run. However, for Chisel Tester, it depend on having a properly instantiated DUT passed into it (breaking encapsulation) and a call from chiselMainTest (which is essentially boilerplate).

A solution would be to have the DUT be instantiated in the Tester's test set up function, and have Chisel's main() manifest all the tests through reflection / dynamic class loading. The tricky part here is dealing with the multi-stage test functionality, where you need a separate test-harness generation step and test run step (with the external-to-chisel C++ compile inbetween).

Related: Rocket uses dynamic class loading for their main() dispatch: https://github.com/ucb-bar/rocket-chip/blob/master/project/build.scala

As part of the setup, can the Tester take an argument to an executable? This would allow us to retain the multi-stage test functionality where DUT build and test execution are done in separate processes. That could be one part of the solution, separating DUT code generation and execution.

More importantly it would be making the interface elegant and easy to use (like a completely encapsulated Tester, where the module set up is done as a method in Tester, rather than passed in externally, and automatic test manifesting) and system robust. Especially if you're passing around executables, you probably want a way for Chisel Tester to verify that the executables are equivalent to the graph being tested (hasing function?) and up-to-date.

doughnit avatar Sep 09 '15 00:09 doughnit