Comment by gluggymug | Hacker News Reader

Comment by gluggymug | Hacker News Reader

Parent Full thread

I used to work in ASIC design and verification. I have to agree with you. I can't take any of this stuff seriously.

They are all toys aimed at newbies. They address problems that are no problem at all to a qualified engineer in the profession.

Combinatorial logic is not hard. I would argue sequential stuff isn't that hard either. It's all undergrad engineering stuff studied in the first year or two.

The design size of a modern ASIC is at a massive scale that makes the problems of whichever description language trivial. Even the cheapest stuff has quite a few modules: memory controllers, CPU, caches, power stuff, bus controllers, various io modules, debugging modules. Nowadays it's multiple cores. Even the sub modules are just wrappers around other cores sometimes.

The teams are large, usually in the dozens because the problems are non-trivial.

This clash stuff is like building a mailbox. Engineers in the profession are designing and verifying the equivalent of an apartment complex.

Reduceron, which I try to maintain, is written in York Lava. It has a module for writing sequential logic (called Recipe) and while it makes sequential logic way easier, I have been working on an alternative for a while.

I completely agree that the sequential parts of a design is the challenging (= bug prone) part and IMO this is the area where an EDSL like Lava can really shine.

If you have worked in ASIC designs that you are almost certainly used to not work with Verilog directly, but with an ad-hoc macro language. I've seen them all, but most commonly Perl is used. It is especially for circuits that we desperately need better tools and abstractions.

When designing with Lava you aren't describing a circuit, but a the method to create that circuit. That makes it relatively trivial to completely parametrize it or statically check properties of the circuit.

As an example, if done right (Recipe isn't), adding a pipeline stage can be a matter of adding a single line. Compare that to what it takes in say Verilog.

This style of ASIC development is simply incomparable to the primitive Verilog-style, but there's not enough experience in the industry to understand it [yet].

Now, Clash isn't (IIUC) an EDSL like Lava so without knowing more about it, I fear it looses much of the point.

EDIT: formatting

Working in industry it IS straight Verilog directly. No macro language in Perl or anything else.

Maybe people use emacs to help make stuff neat but that's it. Qualcomm has their own tool that created register files for sub modules from a MSWord table and it sucked big time.

Parametrizing is just via `defines.

On the verification side, it is System Verilog or something similar. On top of that is a pile of crap called UVM.

For an engineer it does not matter about the language that describes the circuit. It does not matter how many lines it takes to add a pipeline stage. The effort is in creating the design itself, not how it is represented in text files.

Typical engineers write hundreds of lines every day when they feel like it. Think of the complexity of an SoC in a mobile device. There are millions of lines of Verilog for the design and the same or more lines of System Verilog to do the verification. Typing it in is the easiest part.

The real work is simulation of the design under test running millions of cycles. Say we are verifying the wifi, we have to simulate traffic of transactions to and from the device. Millions of transactions while the design is running at various clock speeds with other modules also creating traffic on the buses etc.

Waveforms and log files is the majority of the work.

These languages from academia don't fix anything I care about.

> For an engineer it does not matter about the language that describes the circuit. [...] Typing it in is the easiest part.

Well... once upon a time, people were writing software with assembly, and they probably didn't care about the number of lines either. After all, typing was easy, in fact the only problem was just porting your program to a different architecture :-)

You talk about the complexity of a SoC, and you are right it is complex. But software is complex, too: an application relies on hundreds of millions of lines of code, counting everything between the hardware and the application (OS, network stack, HTTP server, all libraries, database, etc). So how do software engineers manage all that? They use better languages than assembly. Because what matters is the performance/expressiveness ratio (which is why C is still relatively popular) and how hard it is to shoot yourself in the foot (which is why C is not as popular as it once was :D).

> They are all toys aimed at newbies. They address problems that are no problem at all to a qualified engineer in the profession.

I think this kind of attitude is one of the main problems of the hardware design industry (the other one is the conservative mindset). Today's beginners could be tomorrow's hardware designers, instead they switch to software because the culture is much more open and friendly. Besides, you know what they say about asking users what they want: if Henry Ford has asked his customers what they wanted, they'd have asked for a faster horse ;-)

> So how do software engineers manage all that? They use better languages than assembly.

Well, better languages than assembly, yes, but the situation is not so simple. In the past 40 years or so in the software industry, there were two, and exactly two, language-related major productivity leaps in the production of "serious" software: C and Java. Java didn't add too much in expressivity over C (in fact, it added less than C++ had), and neither did C add a lot of expressivity over assembly (more convenient syntax but not too many new abstractions) -- but both added a lot in terms of safety, modularity, portability and the like.

The problem is that we haven't been able to make yet another significant jump. Much of current PL research focuses on expressivity and proof of correctness -- two things that aren't the really painful problems for the software industry these days, and aren't what made C and Java such productivity boosters, either. In both cases, productivity was enhanced not through some clever language syntax design, but through the ecosystem the language supported (i.e. extra-linguistic features).

Yes, some other languages like Ruby added some productivity benefits, but mostly in the "toy" application department -- the same kind of applications people used to use MS Access or VB for, or other "application generators" prior to those -- and you see Ruby shops transitioning to Java as they become "serious". The thing is that with modern hardware, even toy software projects are quite usable, but this isn't the case with hardware design.

Good point about the reasons of productivity leaps. Funnily enough, I recall that one of the main selling points of Java was portability (the famous "Write Once Run Everywhere"), even though C was already supposed to be portable; but the environment wasn't, and you still had to develop OS-specific code.

Anyway, yes I agree the ecosystem is key. This is why a lot of new languages are either running on the JVM (like Clojure and Scala) or are interoperable with C (like Rust and Nim). In other cases, languages have managed to create an entire ecosystem very rapidly (Node.js and Javascript in general, Ruby and others).

> The thing is that with modern hardware, even toy software projects are quite usable

You're right. I must admit I'm not a big fan of this "throw more at the problem" approach, and I wonder for how long this approach will work. After all, Moore's law is slowing down, as the unit cost per transistor has stopped decreasing after 28nm.

> but this isn't the case with hardware design.

Yes, for one because if you design hardware that is sub-optimal, in other words that requires more transistors, that translates into higher costs, and lower margins. That's some powerful incentive IMO. Not to mention that if the hardware is not powerful enough, the toy software projects that you mention will have trouble running ^^

Therefore I think a central question is the loss of performance compared to the gain in productivity. A naive translation of C to assembly leads to disastrous performance. For years (decades?) people had to resort to assembly for speed-critical routines, and you can still find assembly in video decoders for instance. But the productivity is so much higher than the loss of performance is acceptable.

To whomever downvoted this: would you mind telling me why? Have I offended you in some way? Is it because of the criticism of the hardware industry? Or the sarcasm?

Today's beginners don't make the tools.

I must be too old. The new guys can come and bring their new tools. I am retired now.

Back when I started, we used to care how the older engineers did stuff. The academics who trained us at uni had never worked in industry and had no real clue. Hence we had to learn the real stuff from the older guys. These days we are the old guys but just treated like yesterday's newspaper.

> Today's beginners don't make the tools.

Not necessarily, I am a beginner in hardware design, and I am creating a new programming language and IDE for hardware design.

> The academics who trained us at uni had never worked in industry and had no real clue. Hence we had to learn the real stuff from the older guys.

I can relate, this is by talking to older designers that my co-founder and myself learned that CDC is a big thing to address for instance. But a lot of times we were just dismissed as too young and inexperienced. Anyway, I'm curious, in your opinion what would be the biggest pain points in digital hardware design today?

Verification and synthesis are the pain points. Projects revolve around them not the design. In HW, the design of each module itself is usually pretty conservative. We are a conservative bunch remember! But it's feature creep that crams in more and more modules to handle the variety of ways a single SoC can be applied to multiple markets.

The end result is multiple clock domains and buses going everywhere, multiple RAM modules, lots of different clock gating options to shut down parts of the system not in use. Etc.

When I look at a large design, I don't worry about the design effort. The first thing that comes to mind is the verification effort. You spend about four times or more the amount of effort verifying the design because you cannot afford any mistakes. That effort is building everything around the ports of a design that makes it thoroughly verifiable. The stimulus is constrained randomly generated transactions on every input to the design and checkers of every output. Coverage determines whether the random transactions have covered every case. And it not just every combination of inputs. Every module has state internally: you have to cover every possible state transition.

One of the older guys at my old company joked that: These days the design is done by the verification team.

The behavior of the design is modeled by the verification engineer so they can detect when the design has a bug. Often the verification team is working with an empty stub because they get ahead of the design team. It gets to the extreme case of the verification team telling the design team how to write everything.

Thank you for this perspective from the top. Sure, when verifying the final ASIC design, the problems of the implementation language don't matter much anymore. However, those IP cores have to be written by someone, and they actually get to suffer the deficiencies of the HDL.

> I would argue sequential stuff isn't that hard either. It's all undergrad engineering stuff studied in the first year or two.

So? That's like saying that "writing software isn't that hard either. It's all undergrad comp science studied in the first year or two", which is obviously false. If your tools and languages suck, they'll slow you down and you'll produce more bugs – in software as in hardware.

I often get the impression, that many hardware engineers don't even realize how much their tools suck, because the lack the perspective on the outside world, specifically the software world, to see better ways of doing things.

I am a pretty junior ASIC engineer who has relatively more exposure to software world compared to many of my peers.

In my last project I did some IP integration work and the lack of decent development tools led to significant chores. I did make use of Emacs verilog-mode like GP mentioned and even wrote some small macros in elisp but overall experience is far from satisfactory. Not to even mention the usability of propriety EDA tools and flows. The software world just looks like heaven with so many awesome development tools available (VS, PyCharm, intelliJ, to name a few I've used). And I can tell the difference because I once managed to convert a C# GUI software into a console application mainly with the help of an IDE (Visual Studio), without first learning C#.

Sadly, I think ASIC (or maybe broader, hardware) industry has a pretty poor ecosystem in general. I'm not aware of good hardware focused community comparable to HN, no high quality active Q&A on sites like stackoverflow; even the HDL languages look inelegant and not well thought out. And you have a point, I'm not even sure how many of my colleagues realize that. I want to make some difference. But I'm not sure where to start...

> I want to make some difference. But I'm not sure where to start...

1. Take a promising language, improve it where necessary.

2. Add excellent support for translation to VHDL and Verilog. The generated HDL code has to be readable, editable, and it has to reflect the structure of the original code more or less 1:1. You also need to support "inline VHDL/Verilog" (like inline assembly in software). Otherwise, your language doesn't integrate into the ecosystem of synthesis software, simulators, vendor-dependent Map/P&R, and existing IP cores, which makes it useless in the real world. This is the main reason why all innovative VHDL/Verilog replacements have failed so far. Without this feature, there's just no way your language is going to gain any significant market share.

2. I am curious to hear what you think about our solution of wrapping existing VHDL/Verilog in an external task in Cx? http://cx-lang.org/documentation/tasks#external

Very nicely done!

Is there a way to get in contact with you? I suppose you're either Nicolas or Matthieu?

Yep, I'm Matthieu! You can send me an email at matthieu.wipliez at synflow.com

Are you referring to a new DSL based on software languages, something like MyHDL? I think this is definitely promising for designs that are started from scratch. However, as soon as there is need to integrate with other legacy code, it falls back to the current painful way of manual integration.

What do you think about an IDE that supplements existing HDL languages? Not as drastic as making a shiny new language, but it avoids many challenges you brought up.

Since you are coming from a CS background, do you have recommendation for good IDE frameworks that can be leveraged?

I wrote and verified IP and I worked at the SoC integration level. I would say hardware engineers realize the tools suck but this stuff is targeting issues I don't care about.

The bugs are not due to language generally. If software guys want to write a new language for HW engineers, they need to ask HW engineers what the issues are rather then go off on a tangent.

As it is they don't even know what the workflow is like and where the real pain lies. They are just writing tools for themselves. The problem is their applications are not commercial.

New commercial tools are targeted at the verification side: UVM etc. This is where most of the time is consumed. This is where the software guys could offer some actual solutions because UVM is object oriented all over the place. Us HW guys are idiots and don't understand the performance costs of making all the object hierarchies and using reflection everywhere. When simulations are so long and on such large designs, the computing resources needed becomes huge.

> The bugs are not due to language generally.

That's like saying that buffer overflows are not due to how strings are represented in C. Yes a bug is the programmer's fault, but languages can make it harder to have bugs in the first place (for instance you can't have buffer overflows in any other higher level language than C).

In the case of the hardware industry, we see a language with a weak type system (Verilog). So the "solution" is to use lint tools to check that your design is properly typed. Similarly, nothing in VHDL/Verilog prevents you from accidentally creating latches, or crossing domains badly, or many other small bugs. So again, the "solution" is to do extensive verification. That's the Haskell VS Python debate: you can either make it impossible to have a certain class of bugs (and detect them very early), or you can just write a lot of tests (which, in the case of hardware, take forever to run).

The same logic extends at a higher level. You can have a language that models common patterns (like a synchronous loop, a "ready before valid" port) so you can reduce the amount of verification needed because you don't need to always re-verify everything. One could even argue that having such higher-level mechanisms would also make static verification easier, since you might reason in terms of transactions rather than updates to registers.

Latches are caught by the synthesis tools generally. Designers usually run a unconstrained synthesis as a matter of course to determine whether they have written junk.

As for the other bugs, I look forward to this new paradigm of spotting them early without verification effort.

Reasoning about transactions is already how verification works. It is transaction based. UVM is a library of SystemVerilog classes aimed at abstracting the verification to higher levels.

Check out: https://verificationacademy.com/verification-methodology-ref...

We build over these classes to create our test benches.

Reply on news.ycombinator.com