Hacker News Reader

Comment by adwn | Hacker News Reader

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.

View on HN

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