Hacker News Reader

Comment by dailykoder | Hacker News Reader

Do those languages get used in the industry, except of academia? There are so many HDLs and I am wondering if there is any other benefit of learning any of these, except of possible fun.

View on HN

We do a fair bit of FPGA design in SpinalHDL, and have taped out several ASICs with parts of the design done in SpinalHDL at my dayjob.

In general: No, alternative HDLs don't see a lot of use, and I'd argue that we qualify as 'academia' since the ASICs are NIH funded and we tend to work with a lot of academic partners and on low-quantity R&D projects.

Having said that, every time we've deployed SpinalHDL for a commercial client they've been blown away by the results. The standard library, developer ergonomics, test capabilities, and little things like having clock domains as a part of the type system make development so much faster and less error prone that the NRE for doing it in verilog just doesn't make sense.

You get access to the entire Java and Scala ecosystem at elaboration and test time. We deploy ScalaCheck in our test harnesses to automatically generate test cases that can reduce inputs to identify edge cases. It's incredibly powerful.

Huh, this sounds interesting. Maybe I'll give it a shot. Thanks!

In hardware everything boils down to volume and NRE.

If the design is low volume then minimizing NRE, which is mostly set by engineering hours, makes sense. At low volume, the semiconductor unit cost is mostly irrelevant so you can potentially use things like SpinalHDL to keep engineering hours down, and therefore potentially save NRE, and eat the higher unit cost which occur due to toolchain inefficiencies.

At high volume NRE is mostly irrelevant and unit cost is everything. So even if a tool or language is hard and annoying to use, if it gives a lower unit cost, you use it. Here you see things like an engineers hand tuning the layout of a single MUX to eek out a bit more of something good in the PPA space.

I only have experience with high volume HW and there something like Chisel or SpinalHDL wouldn't be considered as it just adds complexity to the flow, and makes it hard to do the optimizations that high volume enable us to consider, for a potential benefit we're not interested in.

I don't know much about SpinalHDL or Chisel, but one example of an alternate HDL is HardCaml, which is used by JaneStreet for FPGA designs:

https://github.com/janestreet/hardcaml

Basically no. Almost everybody uses SystemVerilog. The main issue is that all the simulators only support SystemVerilog so every other HDL is compile-to-SV, and often they output truly awful code that is a nightmare to debug.

Also SV has an absolutely enormous feature set, and often alternative HDLs miss out important parts like support for verification, coverage, formal verification, etc.

Getting away from SV is like getting away from JavaScript. The network effects are insane.

There was an attempt to make a kind of IR for RTL that would break the tie with SV (kind of like WASM has for JS)... I can't remember the name (LL..something?) but it seemed to have died.

Maybe this is similar I'm not sure: https://github.com/llvm/circt

Anyway the only really interesting new HDL I've seen is https://filamenthdl.com/

> There was an attempt to make a kind of IR for RTL that would break the tie with SV

It's probably FIRRTL and CIRT is the compiler for that [1], [2].

[1] The specification for the FIRRTL language:

https://github.com/chipsalliance/firrtl-spec

[2] Original FIRRTL compiler that's now been replaced by CIRT:

https://github.com/chipsalliance/firrtl

Ah no I found it: https://github.com/fabianschuiki/llhd

It does seem to be part of CIRCT in some way though. Maybe it inspired FIRRTL or something. Slightly unclear relationship between the projects!

They're overall more prevalent in the FPGA world, I think. I've used and done several jobs with them (Clash/Haskell, Bluespec, etc) and know others who have, too. But you basically need to know someone or do it yourself. Pretty marginal overall, but IME the results have basically been good (and more fun to write, too.)

At lumiguide we use clash for FPGA stuff. It's not perfect but we are very, very happy we didn't go the verilog route. What a horrible experience that is.

no matter what anyone says to you on here (or elsewhere on the blagosphere): no. the answer is absolutely flat out no.

No is a good first approximation.

There is a little bit of industry usage, with the biggest user being SiFive - the founders come from the UC Berkeley group that developed Chisel.

Also, VexRiscv has some industry presence.

> There is a little bit of industry usage, with the biggest user being SiFive

do ask sifive how much they regret that decision though <shrug>

This is off topic, but I recognize your username from a thread a couple weeks ago but your account is relatively new. Out of curiosity did you just find hacker news and decide to make an account, or is this a new alias and you have an older account? I guess I'd be surprised if there's still new people joining lol.

my account is 8 months old? also i'm sure new people join hn all the time because you know... new people are being born all the time...

I was just wondering. It seemed like you had a perspective that I wouldn't associate with someone new to the industry.

I have no idea who they are, but I think you'd find there are lots of "old-timers" (even notable ones) who've never had HN accounts. Any of them could decide to join at any moment

I'm pretty sure they're going to say they don't regret it at all. Either because it's true, or because they are too invested in it.

When I've started doing FPGA consulting a few years ago I've started using Chisel, but eventually had to go back to SystemVerilog due to client reluctance.

I was dramatically more productive with Chisel than with SystemVerilog.

> I'm pretty sure they're going to say they don't regret it at all.

i didn't say that as a supposition - i know that they regret it. the chisel compiler has been an enormous (enormous) technical debt/burden for them because of how slow/resource intensive it is.

> how slow/resource intensive it is

compared to what?

It's not like all the other EDA tools are really fast or not resource intensive. For smaller design firms I would think things like FireSim [1] would be a significant advantage.

I can imagine it is a disadvantage in other ways, i.e. it's only possible to do single phase positive edge synchronous design, which could be an impediment to high performance digital design.

But I wouldn't imagine that scala performance is particularly significant.

[1] https://fires.im

It's pointless to argue with people on hn because you'll tell them "I have cold hard experience" and they'll respond with hype links and conjecture.

> But I wouldn't imagine that scala performance is particularly significant.

Imagine all you'd like - reality is much less imaginative though.

Just curious, do they have a migration plan? Have they started new designs using Verilog/SystemVerilog/VHDL?

Interesting. So, do you know what they'd choose now if they started over? SystemVerilog?

In the ASIC space, sure, I don't think any of these tools scale in the way that most ASIC companies have forced their "traditional" HDL toolchains to scale.

In the FPGA-based space (accelerators, RF/SDR, trading), hard disagree. There's plenty of boutique FPGA work going on in these.

Reply on news.ycombinator.com