Hacker News Reader

Comment by UncleOxidant | Hacker News Reader

This plus the Verilog to Routing that was posted yesterday showcase the algorithms used in chip design (this post being more about the physical side, v2r covering frontend synthesis as well). The field of Electronic Design Automation (EDA) has some of the most interesting, hardest problems in tech, yet the pay in EDA is kind of mediocre. And EDA is essential in developing new chips -> Semiconductors are essential to our economy.

The EDA companies complain about not being able to attract new talent, but maybe if they paid better? The other problem with the EDA companies (as someone who has worked in EDA in the past) is that they're just plain stodgy - they feel like some kind of old boys club. We had C++ code from the early 90s and to a large extent they still coded C++ in a 90s style. C++ Templates? Nope, not allowed in the group I was in.

View on HN

Wow, people seem to like my EDA submissions :)

Another aspect, at least what I have experienced, is that these tools are built on top of themselves and layered over older versions of themselves, making the code base fragile and hard to work on. For example, Xilinx's Vitis HLS is based on AutoESL, an academic work that underwent commercialization and transitioned into a Xilinx product. You can tell in Vitis HLS that there are many layers on top of simple tool actions that go through custom TCL functions and then down to the most likely Java/C++ software, which also calls out to outdated versions of LLVM tools. I would imagine this is not a pleasant code base to work on and add new features to.

Also, making changes to an EDA tool has large implications for downstream customers who depend on your FPGA chips and are maximizing the utilization on the chips, making them super sensitive to any changes in the EDA algorithms used. This also makes the software development process for these commercials a little sticky. This makes it hard to even plug into and build on top of these tools as an academic.

However, this is no excuse for bad software engineering. I agree that a big investment in software engineering for EDA could be a slam dunk. I think Synopsys and Cadence realize this payoff for their use cases (mostly ASIC), while maybe the payoff is not as big for FPGA companies? Who knows what they are thinking.

On the technical side, more open-source EDA tools help even if they are not fully practical in a commercial setting. Even the C++ codebase for VPR is readable and mostly easy to follow. As a thought experiment, a Rust-based port of that would be interesting from an API and program architecture perspective. There are also some DARPA programs that are pushing for better open-source tools for EDA flows as well as better EDA algorithms for large-scale, 3D, and heterogeneous semiconductor design, so I think they see the technical problems we are behind on.

Can you recommend books on the algorithms used in frontend synthesis? And/or FPGA-specific algorithms?

Logic Synthesis And Verification Algorithms by Hachtel and Somenzi the copy I have is copyright '96, not sure if it's been updated.

It hasn't been updated.

The book is considerably out of date, but a lot of the concepts and definitions are still relevant.

This deck has a great introduction to mapping and the references at the end are more up to date

https://www.eng.biu.ac.il/temanad/files/2018/11/Lecture-4-Sy...

Similarly out of date.

A good starting point for more modern techniques would be something like this:

https://people.eecs.berkeley.edu/~alanmi/publications/2006/t...

I came across this survey paper on Combinatorial Optimization in VLSI Design: https://www.or.uni-bonn.de/research/montreal.pdf

I don't know how up-to-date the information is. Two of the authors (Korte, Vygen) wrote a textbook on combinatorial optimization. I haven't read it and I don't know enough about the subject to be able to say how useful the contents are to VLSI design. I think they focus more on the theory than the application: https://link.springer.com/book/10.1007/978-3-662-56039-6

> is that they're just plain stodgy - they feel like some kind of old boys club

I mean just go look at that post from yesterday where I complain that yosys uses C++ to script flows and the response to the complaint - I'm starting to think these people just enjoy being miserable.

I think it’s more likely these people mainly enjoy designing hardware, not tools for designing hardware (aka software). Learn to use a tool, and use it. It’s a hammer, start driving nails

Software development is unique in that tools for building software are also software. This hammer is great and all, but I make hammers, and I know this one could be better

This is apologetics.

The real reason is the hardware vendors are entrenched and don't make money off the software at all. The situation is exactly the same as it was in the proprietary compiler space before gcc (and then clang) - no incentive to improve or open source the compilers -> no access to good tools -> proprietary tools remain only option.

Yosys though, being an open source attempt, is just making unforced errors, hence my ranting and raving in the other thread.

You're talking about FPGA tools but this thread is about VLSI design where the major EDA vendors (Synopsys, Cadence, and Mentor) don't sell hardware(*) and *do* make a lot of money from software.