|
|
|
|
|
by aDfbrtVt
1812 days ago
|
|
I'm very surprised by the reported cost to verification. One of the major reasons to move to a high level synthesis design strategy is to ensure equivalence between your models and RTL. I have experience with C++ HLS and it has enabled massive reductions in verification time. |
|
That said, I think one of the problems the google team was struggling with is that in traditional HW development there is design and a separate verification team. The design team bought into Chisel since it would let them generate hardware more quickly, but the verification team just tried to apply their traditional verification methods on the _generated_ Verilog. This is almost like trying to test the assembly that a C++ compiler generates instead of trying to test the C++ program since all your testing infrastructure is setup for testing assembly code and that is "what we have always been doing".
In order to catch verification up to modern Hardware Construction Languages [0] we need more powerful verification libraries that can allow us to build tests that can automatically adapt to the parameters that were supplied to the hardware generator. There are different groups working on this right now. The jury is still out on how to best solver the "verification gap". In case you are interested:
- https://github.com/chiselverify/chiselverify
- https://github.com/leonardt/fault
- https://github.com/ucb-bar/chisel-testers2/
I am probably missing some approaches from the nmigen world that I am not familiar with. You can always write cocotb [1] tests in python, but I am not sure if they can directly interface with nmigen generators to adapt to their parameterization.
[0] besides Chisel, there is also https://github.com/nmigen/nmigen and https://github.com/SpinalHDL/SpinalHDL
[1] https://github.com/cocotb/cocotb