Of course we do all of our real tests on the generated verilog. (Note: There is a big difference between generated verilog, in the Chisel sense, and synthesized verilog, in the MyHDL sense). We use Chisel to write our RTL and do quick and dirty testing with our gold model, and if that matches up, we generate the verilog and do the "real" testing from that point. This whole flow is a iterative process that can happen several times a day, or once a week, depending on how much development is going on. This of course leaves out the other steps once you synthesize the verilog for either a FPGA or VLSI tools, which we also do.
What you linked to there seems to be a "mode" (Can't think of a better name to describe it at the moment), similar to how you can embed verilog or C++ into Chisel.
This is useless without any data: "big difference between the generated verilog". You would need an actual case study to confidently state these and as pointed out with programming languages this is difficult to do.
Ok. If you do the majority of your testing on the generated Verilog, I am not sure what the point of the Chisel C++ cycle accurate simulator is. I thought that ran on the Chisel RTL.
What simulator do you use to test the generated Verilog? And what language do you write the tests in?
Actually this is the area that I am most interested in. I am responsible for writing SystemC models of our designs so that firmware/software guys are able to work in parallel with RTL development but it takes me some time to create the models and get the timing reasonably equivalent (AT in SystemC speak) to the RTL. If I had a flow were the same source could generate cycle accurate models AND verilog this might be an acceptable answer and allow us to develop SW/FW much more quickly.
In my world even though hardware takes an extraordinarily long time the FW/SW is still the long poll in developing complex systems and anything that shortens the time to $$$ in the door we should probably be looking into.
That does sound like a good aspect of Chisel. How do they test that the Chisel RTL and the generated Verilog are equivalent though?
To me I would want a good verification environment that tests one against the other. Testing just via loading self-checking code into FW/SW is not enough. That's almost like SW verification. It assumes way too much is working correctly.
I am fantasizing if its possible to also write the Verification IP in Chisel AND convert that into a separate c++ library, then you can reuse it in a commercial Verilog RTL and gate-level simulator via a PLI.
That would serve many purposes and make Chisel useable in a generic flow.
What you linked to there seems to be a "mode" (Can't think of a better name to describe it at the moment), similar to how you can embed verilog or C++ into Chisel.