4 ms·
I'm curious what your objections to Chisel are! (I don't really care for Scala either .. unless you mean that like, this somehow affects the way that IP is deli
by eigenform 3y ago
I'm curious what your objections to Chisel are! (I don't really care for Scala either .. unless you mean that like, this somehow affects the way that IP is delivered to you as a customer? I thought you just get a big blob of verilog in the end, and I'm not sure how that'd affect you?)
- OhMeadhbh 3y agoI'm not the worlds biggest fan of Verilog, but Verilog's semantics are relatively fixed. The interpretation of verilog has remained fairly stable for a decade at least. Chisel is in some ways still a work in progress. So if you want to use it, you have to keep track not only of Chisel productions specific to your design, but also the version of the boom or rocket generator you're using with it. Chisel was never at the center of our design flow, and none of the people I currently work with went to UCB. When we used the Rocket generator we were often "nervous" about whether the version we were using would interpret Chisel productions in the way in which it had previously. But yes... this led us to a working style where we tried very hard to avoid having to use rocket or boom generators. I didn't want to be in the business of maintaining RISC-V Verilog tools. At around the same time we realized RISC-V was overkill and built a very poorly designed Lisp DSL which output Verilog for a dog-simple 6-bit controller. Not an ideal solution to be sure, but it worked better for us than spending a couple years learning Rocket/Scala/Chisel. Nick Tredennick (who I believe was the main designer of the 68k) has a quote in his book "Logic Design: The Flowchart Method": The problem with many texts is that we lie about details. We are sloppy in areas that are not our primary concern. Academics are method fanatics. Practitioners are solution fanatics. In school, we glorify the methods and lie about the sophisticated problems we solved. In industry, we glorify the problems and lie about the sophisticated methods we used. Each side loses credibility the minute one side reads the other's literature. The academic knows that the practitioner's "method" is (ugh!) arbitrary, just as the practitioner knows the academic's "solution is (ugh!) not applicable. Because we oversell method and solution, it takes too long to figure out what really works. I don't want to say Rocket / Chisel / Firrtl is bad, but it always seemed to be more in support of a "process focused" methodology than the "solution oriented" focus I'm used to. If it works for you, I'm absolutely not going to tell you it's a bad idea to use it. It's just too much overhead for the small projects I work on. That being said... SiFive was working on CoC (theorum prover) extensions to validate designs using formal methods. THAT sounds fascinating, but I'm not sure how they would monetize it. [Edit: To recap, I don't have a problem with Rocket / Chisel / Firrtl per se, but they operate at a level I'm uncomfortable with and seem to be less stable than I would prefer. I completely understand this is not the case for many other people.]
- eigenform 3y agoI can totally understand it being too "heavy-handed" a solution for tons of cases, definitely! Thanks for sharing :)
- taway32r41 3y ago> SiFive was working on CoC (theorum prover) extensions to validate designs using formal methods. THAT sounds fascinating, but I'm not sure how they would monetize it. Synopsys seems to think it's a decent business to be in. :) https://www.synopsys.com/verification/static-and-formal-verification.html https://www.synopsys.com/verification/static-and-formal-veri...