43 ms·
It's not the same thing. Chisel will help you do things like write more reusable RTL, because the language itself is more expressive -- so the potential level o
by aseipp 7y ago
It's not the same thing. Chisel will help you do things like write more reusable RTL, because the language itself is more expressive -- so the potential level of abstraction is much higher than what you can achieve in Verilog. You can do more flexible kinds of parameterization, for example. And doing that can help avoid certain kinds of bugs, for sure. (And it also means you simply need less RTL to describe the same thing, because re-use is so much higher.)
But Chisel will not help you when you have some errata like "the BRAMs on these devices take 67 cycles to initialize after coming out of reset" tucked away in a manual somewhere that you forgot to read. That's just an FPGA example -- you can run a hundred simulations and your design will still fail immediately in real hardware because of such things. (Even "cycle accurate simulations" from your vendor may not account for these things.) You're going to encounter a lot of problems like this, before you even move to ASIC level flows.
Ultimately the hardware industry does need much better RTLs, because the current ones mostly suck from a language POV in a huge number of ways. But verification is still a much bigger problem in general no matter what RTL you've chosen.
- 9q9 7y agotucked away in a manual With a better eco-system, the (temporal) specification (such as "take 67 cycles to initialize after coming out of reset") such be given formally, so a tool can ensure that it's not forgotten. In principle this is possible. much better RTLs Have you got any concrete ideas and proposals? I'm asking because (A) I agree with you, and (B) I'm very much in a position where I can influence research in this direction.
- _chris_ 7y ago> (B) I'm very much in a position where I can influence research in this direction. Could you elaborate on what you do? > Have you got any concrete ideas and proposals? My recommendation is: try to build something complex, or take something from open-source that is very complex and extend it (test it, verify it, improve performance, etc.). Notice the problems you encounter, and then try to solve those problems. I could give you a laundry list of pain points myself (why do I have to pay money for lint, and why does lint still suck???), but I think the best research is done by people trying to solve problem X, but along the way ended up having to solve Y and Z just to get to X.
- 9q9 7y agoI've spoken to a lot of processor designers, usually from an EE background, and they prefer Verilog: "we tried more high-level languages in the 1980s ... it was a failure" is something I've heard more often that than I wish I had. I think there is an interesting C. P. Snow-like Two Cultures thing at play between SW and HW people. I think the latter don't quite get the abstraction power of modern programming languages, they don't understand that syntax, types, modularity matter. They think PLs are something like C and C++: a mess that we simply accept and get on with life. The former really underestimate the extreme scale and complexities involved in processor design and verification. Never the twain shall meet? laundry list of pain points Think bigger: what would you do if you have a team of 3 engineers, or 30 engineers to work on a better tooling ecosystem?