The real difference is that in event-driven languages, clock events are explicit, instead of implicit like in Chisel and the whole array of dead HDLs that preceded it. So if history is any guide, Chisel is dead upon arrival.
Converting to yet another format can be a pain and potentially dangerous, if you are creating a commercial ASIC you need to guarantee each of these formats/representations are equivalent, if there is a discrepancy between the generated C++ and generated Verilog for implementation - oh boy.
I should say that in generating Verilog or VHDL from MyHDL, you can do proper simulations with that... but Chisel's C++ simulator is significantly faster than a Verilog simulator, while still being cycle accurate.
MyHDL is talking about co-simulation on the gate-level netlist. They do not recommend it. However they say MyHDL can do co-simulation on Verilog RTL. That will be cycle accurate I believe.
As I understand it Chisel can't even do co simulation at all.
Am I incorrect? Essentially once you translate your Chisel design to verilog you basically can't reuse your verification environment for the RTL simulation or the gate-level. How are you going to check timing if you wrote all your tests in Chisel?
So Chisel seems worse than MyHDL but neither can support verifying a gate-level sim so you are somewhat screwed either way. It's just a matter of how badly screwed you are.
That's kinda the problem with all these tools I believe. A while ago someone posted about Clash. Same issue.
Getting into my opinion here: High level synthesis has never been (and I doubt for a long time) able to beat an experienced RTL engineer because of that fact that a software description (such as MyHDL, Clash, SystemC, etc) of a piece of logic will never map perfectly to hardware. Chisel doesn't have this problem, as you are just describing (or "constructing") the logic itself. No "translation" process happens, and thus you don't have any problem actually simulating at the same RTL level as Verilog.
In sharp contrast to what you suggest, logic generation is not the main hardware design problem. And the fact that you think you can beat RTL synthesis by "generating" or "constructing" the logic itself proves one thing: you don't have the slightest idea of the real power of RTL synthesis.
The main problem with hardware design is verification. VERIFICATION. And for that reason, HDLs should not be limited a "fully synthesizable" subuset, but support powerful modeling concepts in the first place. And so far, nothing beats the event-driven paradigm for that purpopse.
So it should simulate RTL and give you cycle accurate waves.
No gate level sim for either tool means you're dead meat which ever way you go, so I am not sure why I am even bothering to look at this stuff.
The respective merits of each approach is somewhat pointless when crucial steps in the HW process are completely ignored.
And now you are saying you don't test on the generated Verilog from Chisel? That's no good. No one should just run tests in Chisel. You're delivering HW not Chisel code as far as I am concerned. That's a few huge steps more in the flow that need vigorous testing. Where is the quality control?
So much more logic is added to chips during/after synthesis these days and you have no way to get any of your tests running on that net list.
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.
What simulator do you use to test the generated Verilog? And what language do you write the tests in?
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.
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.
Tape out using these tools?
My guess is they skipped gate level and other stuff that I consider good quality (BISTs, DFT logic, power estimation etc). You either skip it or rewrite your tests in Verilog/VHDL/etc.
Static Timing Analysis etc. can only do a little of what's needed. You have to check your constraints are correct.
Academics don't know what they are doing. They probably never had to do a design flow for a real product or even touched a commercial tool. It's too expensive. That's why they make these other tools. And that's why these tools kinda suck at getting to a finished product.
You do realize you can do all of that simulation after you generate your verilog and put it through your RTL compiler?
Yep. Check out this https://github.com/ucb-bar/rocket-chip ... there are plenty of testing options you can do, including waveform vcd testing.
EDIT: Also, relevant paper: http://www-inst.eecs.berkeley.edu/~cs250/fa11/handouts/lab3-... ... check out the part regarding test harness
Looking at a lot of stuff you referenced.
I think my definition of tests is a lot more generic than yours. Taking a look at your links it seems tests are written in RISC-V machine code? The code will execute some functionality of the CPU and check for an expected response then possibly through a logging IO from the chip send a pass/fail message to the test harness or update a status register that is polled.
They run Verilog simulation on RTL and gate-level using Synopsys VCS. (At least they didn't skip it! Which is good!)
This is a very specific way of doing stuff that really only applies to this particular core with very little I/O.
We don't do it this way in industry. (This is where a throw a drink in the face of whichever Berkley academic that put this crap together.) The last time I saw something like this was maybe 1999-2000. It is terrible. Usually testing is done at the interfaces.
A real-world design has lots of I/O. For me, a test generically should stimulate the inputs to the design as well as have code for the CPU if it exists. Checkers check the outputs of the design for correct behavior. These stimuli and checkers are written in the verification language of your choosing. This is the standard approach. More checkers peek into signals inside the design itself usually.
If that stuff is written in Chisel so it can be simulated by the C++, then you are screwed for the RTL and gate-level. This is what I am saying.
The RISC-V test harness pretty much only has a clock and reset for inputs, Some sort of host bus. That's it! And the tests are assembly code or whatever.
If your design is not a CPU, what would your test be? say it's a HW cryptography encoder thing, no code to load into a memory.
Hypothetically I wrote my tests and checkers in Chisel. I now want to run a gate level simulation of my tests. I asked the same thing to the Clash guys. Can it do that?