13 ms·
Oh boy, this is a sore subject for me. It's pretty obvious that Verilog and VHDL, modeled after C and Ada respectively, both imperative languages, follow a dra
by anyfoo 5y ago
Oh boy, this is a sore subject for me.
It's pretty obvious that Verilog and VHDL, modeled after C and Ada respectively, both imperative languages, follow a drastically mismatched paradigm for hardware design, where circuits are combined and "everything happens in parallel". It becomes even more obvious when you have tried a functional alternative, for example Clash (which is essentially a Haskell subset that compiles to Verilog/VHDL: https://clash-lang.org https://clash-lang.org).
The problem is, it is hard, if not downright impossible, to get the industry to change. I have heard many times, in close to literally these words: "Why would I use any language that is not the industry standard". And that's a valid point given the current world. But even for people that are interested, it might just be hard to switch to something like Clash and not give up pretty quickly.
Unlike imperative languages, functional languages with a rich modern type system like Haskell are hard to wrap your head around. It's no news that Haskell can be very hard to get into for even experienced software engineers. In 2005, after already having more than a decade of programming experience in C, C++, Java, various Assemblers, python (obviously not all of these for the same time) and many other languages, I thought any new language would mostly be "picking up new syntax" at that point. Yet Haskell proved me very wrong on that, so much that it was almost like re-learning programming. The reward is immense, but you have to really want to learn it.
And to my surprise at the time, when I got heavily into FPGAs, the advantage proved to be even stronger when building sequential logic, because that paradigm just fits so much better. My Clash code is much smaller, but also much more readable and easier to understand than Verilog/VHDL code. And it's made up of reusable components, e.g. my AXI4 interfacing is not bespoke individual lines interspersed throughout the entire rest of the code. That's mainly because functional languages allow for abstraction that Verilog/VHDL don't, where often the only recourse is very awkward "generated" code (so much so that there is an actual "generate" statement that is an important part of Verilog, for example).
So by now, I have fully switched to using Clash for my projects, and only use Verilog and VHDL for simple glue logic (where the logic is trivial and the extra compilation step in the Verilog/VHDL-centric IDE would be awkward) or for modifying existing logic. But try to get Hardware Engineers who probably don't have any interest in learning a functional programming language to approach such an entirely different paradigm with an open mind. I've gotten so many bogus replies that just show that the engineer has no idea what higher order functional programming with advanced type system is on any level, and I don't blame them, but this makes discussions extremely tiring.
So that basically leaves the intersection of people that are both enthusiastic software engineers with an affection for e.g. Haskell, and also enthusiastic in building hardware. But outside of my own projects, it just leaves me longing for the world that could exist.
- eeks 5y agoI had a similar experience with HardCaml back in 2015/2016. The benefits where overwhelming: higher productivity, higher reusability, less intractable bugs, tighter TTM, and no more slippage in deliverables timeline. The performance where comparable to Verilog-only project (density, path length). In the end, the effort was shut down by management because the approach was “too complicated”.
- anyfoo 5y agoAnd commonly also because it's, currently at least, very hard to find people for it. Which is an entirely valid concern, but is still so frustrating. Because while C for system programming might not be ideal, it still makes sense, whereas Verilog (that was meant to look like C because people knew C for programming already) for hardware design is just so much more of a mismatch.
- bob1029 5y agoHigher order functional thinking is such a ridiculous superpower, but it's also really hard to do correctly without some programming tool helping you along and tons of experience. In your case, any piece of hardware can effectively be abstracted by some top-level function that takes arguments of time, inputs, outputs, environmental variables, etc. Mastering higher order function development is how one can properly address complexity in any domain. SQL views are another good example of this. In fact, you could very likely build a competent digital circuit design system around SQL ideologies. SQL is the best tool I've ever found for modeling and applying constraints.
- pjc50 5y agoLogged in just to upvote this and largely agree with you. Verilog/VHDL are stuck at the 1980s coding paradigm level, as if the industry grabbed the first working solution for automated hardware developement and has clung on to it. > The problem is, it is hard, if not downright impossible, to get the industry to change. Yes. I don't think it will until either, say, Intel does it by CEO fiat, like the Amazon memo, or a startup from outside somehow dominates the industry by using a different technology. (I have worked both sides of this, a chip design startup that was bought by Cadence, and a medium size fabless semi company) > I've gotten so many bogus replies that just show that the engineer has no idea what higher order functional programming with advanced type system is on any level, and I don't blame them, but this makes discussions extremely tiring. "A monad is just a monoid in the category of endofunctors, what's the problem?" (I'm joking, but this is an us problem and not a them problem, you can't evangelize things to people that they don't understand, and you have to reach them where they are. Yes, this is very hard work) However one thing that us software types may not appreciate is that all the weird imperative stuff in Verilog that isn't synthesizable probably gets used in more lines of code than the synthesizable subset - because testbenches are absolutely critical to shipping hardware. The hardware industry can't benefit from rapid iteration because every iteration costs a mask set.