3 ms·
Okay this is getting weird. I just read your link so this is all from my first impressions. MyHDL is talking about co-simulation on the gate-level netlist. The
by gluggymug 11y ago
Okay this is getting weird. I just read your link so this is all from my first impressions.
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.
- trsohmers 11y agoChisel doesn't require co simulation, as it is actually RTL in itself... it describes actual logic (registers and gates) instead of the functionality of the chip (as MyHDL does). Chisel being actually RTL makes it much easier for actual hardware engineers to use, but still allows for very powerful paramaterization that cuts down on total number of lines that have to be written. I would even say that it being embedded within Scala helps software engineers who have basic knowledge of hardware be able to be much more productive than if they were trying to write in Verilog. 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.
- gluggymug 11y agoI've been skimming through MyHDL stuff. It does support RTL like Chisel supposedly. http://docs.myhdl.org/en/latest/manual/rtl.html http://docs.myhdl.org/en/latest/manual/rtl.html 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.
- stephenmm 11y agoI have some of the same concerns and would like to see someone from industry who has actually done it before I spend much more time on it. My additional question is then how did the academics do it? There are some tools that negate some/most of the need for gate sims but at my company we still do not ship without SOME gate sims.
- gluggymug 11y agohow did the academics do it? 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.
- trsohmers 11y ago@gluggymug You do realize you can do all of that simulation after you generate your verilog and put it through your RTL compiler?
- gluggymug 11y agoHow do I get my test stimulus into my simulator? And where is my checking? 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?
- trsohmers 11y ago@gluggymug (2nd... don't know why the 'reply' button doesn't appear below your comment) Yep. Check out this https://github.com/ucb-bar/rocket-chip 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-riscv-v2-icc-pt.pdf http://www-inst.eecs.berkeley.edu/~cs250/fa11/handouts/lab3-... ... check out the part regarding test harness
- cfelton 11y agoThat is very dangerous not verifying, in some means, that each of the formats are functionally identical. One could skip the Cosimulation in MyHDL as well. This has nothing to do with the so called abstraction level of chisel.
- jandecaluwe 11y agoComplete nonsense. First, a synthesizable MyHDL description is at exactly the same abstraction level as a synthesizable Verilog/VHDL description. This paradigm is the basis for the standard, successful industrial flow. This is what real hardware designers do and it is not HLS. 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.