Comment by artemonster | Hacker News Reader

Comment by artemonster | Hacker News Reader

Parent Full thread

ha! I guess you haven't worked as a designer or verification engineer, designing chips then? let me tell you: you work with a commitee-designed c++ like abomination language with 300 non-composible keywords that make no freaking sense. all of that crap grew from legacy-upon-legacy of crutches as an attempt to fix the goddamn broken-by-design verilog. Ultimately, this craplanguage + library that is 90% non-debuggable macros, works only with ~3 vendor simulators (all 3 would do different stuff on big designs and you are locked almost forever). When you simulate you designs, most of external components would be either encrypted blackboxes or be calling "magic" functions (called system tasks) that are absultely opaque to you and do some global side-effects. All of this multiplied by the fact that every statement is executed in parallel in your huge design and evolves in time. Oh, did I mention how crappy the actual tools are? Think of 90's era with outdated and moronic UI/UX, some poorely integrated quasi-TCL interpreter for configuration & ability to crash that tool in <3 clicks. Ah, you will be paying 15kUSD/year per license, thank you very much. You will be needing lots of them (> 50).

Or working with a 40M Loc codebase started in the 80s with 50% code duplication. Because it's so mission critical that nobody really touches existing code. Or that everything needs to be rubber-stamped by a ton of people and even a rename takes months to make it in the codebase. Oh well. That's probably every enterprise

As somebody without any experience in that field: When you say "codebase", what is that? Is it code describing circuit blocks (e.g. an ALU) that is reused in different projects or is it code for the tools that you use? (in-house tools, plugins for commercial tools, etc.)

There are several machines required to make a chip, and many steps involved. Those machines are crazy complex and accurate (i remember having a precision of around 3 atoms of silicon, femtometer scale). I meant firmware fot these machines, in general. Crazy complex (and amazing) tools with complex software

That's probably every enterprise

Yep, pretty much any industry or individual organization that's been around for 40 years will have decades-old cruft complicating attempts to make changes. That's why it's good to have some sort of skunkworks unit as well.

Hmmm, isn't there people pushing for better standards, language, tools?

Yes there is. But moving at enterprise speeds. Python considered "new" and young. Codebases are 30 to 40 years old

there are some developments, but mostly you would get new additional tool on top of existing stack, rather than a new stack.

Problem 1. patents. in early FOSS days people got momentum to push hard for corporations to give up compiler patents and other obvious nonsense and let GCC flourish. same situation is here in hardware, the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence.

Problem 2. features. there are a lot of features that you need to push out a working chip into an existence. open source tools or alternatives are SO far behind that they cannot be used or can be used only on something really small.

Problem 3. verification. there are no (VIABLE! that python coco stuff doesnt count!) open-source alternatives to UVM (uvm as a library is open source, but there are either no simulators that can run it). If we had some of the older verificaion languages to go open source (like specman, vera), maybe we had a chance.

> the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence.

Doesn't that apply to basically every kind of software? How's it different for HDL simulation software?

the point is that for FOSS there was an active movement that forced IBM and old megacorps to forfeit such "nonsense" patents. So if you roll out a brand new c++ compiler you may have some buffs with intel if you try to go to their turf about some propreitary x64 specific optimizations, but, say, IBM wouldnt sue you because you dared to create "a program/method of transforming source code into machine code" that violated 250 patents from their portfolio.

I get that, but you wrote:

> the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence

Do you think a startup selling a new HDL simulator is any more at risk of getting sued than any other software-based startup?

Not trying to be combative, I'm genuinely curious.

Yes. Happened twice? already

Really? Wow! Do you happen to remember their names?

one remember - "magma automation". they were sued to pieces and then bought out

Thanks!

According to their Wikipedia page, they paid 12.5 M$ to settle in 2007 and continued to operate for another 4 years before being bought for half a billion USD. Not exactly what I would consider "sued to pieces" ;-)

https://clash-lang.org/ http://www.clifford.at/yosys/

I am hoping we can start proving many if the things they brute-force model check today, too.

From FPGA design point of view SystemVerilog is OK. I think it gives high enough level of abstraction to create even complex systems. It can also be readable after some years if care is taken to keep the code clean.

But I believe we need LISPy syntax - mainly for simplicity, also for easier parsing and static analysis. I think LISP is a natural way to describe data flow. Unfortunately none of the attempts to write functional synthesizable code that I found so far make the code simpler.

BTW I'm preparing a talk on simplifying RTL code. Can I cite some of your posts in this thread?

What's the compensation / benefits / work-life balance like?

My experience in this industry is that it pays well, good benefits, but it ebbs and flows much like the defense industry with large boom times and slower times with large layoffs.

Any thoughts on Chisel?

as much as it pains to say me, but IMO its a wasted effort. we don't need new design languages. VHDL/Verilog "pain points" as RTL are tiny and don't require solving, we pretty much figured out design. Verification, on the other hand, is still an evolving (now stagnating) mess that needs inputs.

The biggest offender on that project list is FIRRTL. Cleary outgrew as someone's university work of "hey, lets do IR, but for RTL" without knowing anything of the industry, tools, etc. At best you can do the same with one reduced canonical simplified verilog source-to-source translation. at worst it does not do the primary function of "being" IR for RTL, because it should've been a graph, not another language with simplified syntax.

Chisel's being hooked into the Java / Scala tool chain give makes setting up automated verification pipelines much easier:

- You can use SBT or MVM to pull in dependencies

- You can wrap up designs as .jar files

- Powerful testing tools like QuickCheck come ready made

None of the above is rocket science, but simply by being there things become easier.

   without knowing anything of the 
   industry, tools,

It's pretty difficult for a student to find out about what is actually used in industry. The semi industry's secrecy doesn't help. But software and hardware people really don't even have a shared language, and misunderstand each other's abilities and pain points. The very term "verification" is understood quite differently between the different communities.

> At best you can do the same with one reduced canonical simplified verilog source-to-source translation.

Parsing Verilog and generating valid Verilog is fairly difficult. If you want to stay with Verilog, the most realistic alternative to firrtl right now is the RTL-IL representation used inside of yosys.

> at worst it does not do the primary function of "being" IR for RTL, because it should've been a graph, not another language with simplified syntax.

Canonicalized LoFirrtl (i.e., the representation the compiler lowers Chisel to) is essentially SSA (single static assignment) which encodes a dataflow DAG. So on a per module level, firrtl does represent the circuit as a graph.

What you might be talking about is the fact that this graph isn't global. Having a global circuit graph could make some analyses easier, but it might require essentially in-lining the whole circuit which is something a lot of designers are opposed to. Even small optimizations like removing unused pins from internal modules are often times opposed.

Chris Lattner and others are currently working on an "industry" version of firrtl as part of the CIRCT hardware compiler framework: https://github.com/llvm/circt As you can see they did not decide to go with a global graph based IR and instead opted to just represent local data-flow graphs as SSA.

Reply on news.ycombinator.com