HLS: My favorite zombie

High Level Synthesis.

From my favorite trustworthy encyclopedia on the internet:

C Level Design was a computer software company based in San Jose, California. It developed a tools to translate from the C programming language to hardware description languages. The company was established in 1996 by Don Soderman, Denis Coleman and Yuri Panchul. The first product was called C2Verilog.

Some facts from a dinosaur ASIC designer:

• HDL tools have not evolved much, except for keeping pace with the gatecount in the designs. For synthesis, we still use the versions that are 6 to 12 months old, we prefer them to be at least SP1 (service pack) because of the bugs.
• Vendor lock-in was present in the nineties. But we could choose synthesis from vendor X and simulation from vendor Y. Today, all tools from the same vendor is the norm.
• The abstraction level today is still logic gates, the same as it was 20 to 30 years ago.
• Today we do have open source tools for simulation and synthesis. That wasn't the case in the nineties. I can't judge the efficiency of the simulators and synthesis open source tools but with a smart methodology, those tools can do most of the work without any license limit.

Maybe more things I come up with later that are relevant ...

This quote is not mine: "this to me shows that the semiconductor industry creates the devices of the future with the tools of a long past.".

I have given many examples in the past on Linkedin and Quora on the outdated nature of hardware design. Nothing wrong with a conservative stance, we are making multi-million dollar chips. But we can learn a lot from the software world. I am the first one to admit it. Version control in the sector is proprietary tools or subversion, while software is a long time git user. And we use it for version control, branching and merging HDL? Nah. The same for makefiles, it is intended to use dependencies, most of the time, the makefile is just a compile script where all files are fed via a list of files, not a dependency tree. We don't use the full power of tools that have proven their worth over many, many years. I didn't use open source simulation for a long time, but I use it now all the time. Hence, I adapt and even advocate for many small tools like makefile generators, automatic interconnect, register map tools, ...

And we are not even mentioning outdated ways of working together, we can work with cheap design centers in different time zones, but don't want anyone to work remote? What's up with that?

My point: I want to learn and improve any way I can and open source has given us a lot over time, but mainly on the tool front. As a good thief, I am ready to steal methodology and tools that software engineers use to improve. And, we all know they need that improvement, patch Tuesday anyone? The hardware world has the bugs and insecurity that can't be patched with software. We are crucial but chaos is the methodology we chose. Discussions aren't possible because everything we get from professional events, conferences and articles is sponsored content. The state of IP and tools is a well kept secret, and it needs to remain a secret. because billions of revenue are at stake.

Hence, HLS rears its ugly head from time to time. Every time I looked at it, it was time lost. Time I could have spent on Twitter or Facebook! 2020 is again the rise of HLS it seems.

A quote I saw on Linkedin:

"I'm looking forward to read the article, it seems that HLS is been around for a significant amount of time promising easing both design and verification, but for some reason(s) still not as adopted as expected, I've seen many design engineers not keen to use such tools under several arguments, but this to me shows that the semiconductor industry creates the devices of the future with the tools of a long past, sometimes due to stubbornness and sometimes due to 'fear' not meeting project deadlines."

Now, that is certainly a statement.

The fear of not meeting deadlines is a thing, since most project approvals are done with a fake underestimated budget and time projection than actually needed. because it is easier to get more money and time when the project is started. It won't even start if you give them the real numbers. Quite confronting that a bureaucratic profit generating corporation works like that. But it is real, it is called office politics. All engineers do accept inefficiency and flawed thinking because they need money to pay the bills. They are trained to accept and to comply no matter how dumb the company they work for is. Exactly the problem, you can't switch off critical thinking whenever you want. Critical thinking is required to improve and find real issues and root causes. Those engineers will indeed not take risks. But they aren't in the driver's seat, there are way more software engineers out there, than hardware engineers. If HLS was the holy grail, software engineers would make silicon that beats hardware designer silicon on all three metrics: speed, area, power for silicon. Plus budget, total manpower and time to market must be equal or better too! You don't need hardware engineers if you have software people writing software that gets translated into silicon. Like I wrote in the other article I posted today this is the difference in hardware versus software:

• HW: parallel, boolean logic, clocks (timing) and resets, tool flow for manufacturing defect detection, ...
• SW: serial, issues with multi-threading/parallel, no concept of clocks/resets, ...

The specific timing of logic gates (pipelining), memories, clock gating, reset synchronizers, is not something you can do in software. C2verilog mentioned above, was just the synthesizable subset of HDL languages in C. An extra step to translate C into verilog into a netlist. HLS makes sense if there is an abstraction level above logic gates. If there would be a sea of processors instead a sea of gates. Instead of a few hundred million gates, we would have a few million processors. A library of processors with network specific, memory control processors, video and AI cores, ... instead of a library of NAND2, OR, NOT, MUX2, ...

If HLS would solve my issues, bring me benefits in time and effort, I would gladly throw overboard the whole HDL thing and become the best advocate for HLS today.

Amazon FPGA as a service (FaaS, EC2 F1) is a kind of effort to have a few digital cores that are designed upfront and loaded into an Ultrascale FPGA with a software ML library on top of that. Similar to the CUDA stuff on a GPU but more tuned towards ML. It is clear that it is the future, there will be way more software built on top of hardware. Like I said, 100 times more software engineers around than hardware engineers. But we don't have millions of processors that we choose from a library. And whenever that happens, it will be like the cell library of the foundry today. Analog designers make digital cells and characterize them for us digital designers to use them. The specific processor library will be designed by digital designers that deliver them to the HLS people. Or something like that. I don't know.

The main thing is that verification engineers are the software people of the hardware world. Verification isn't synthesizable and therefor is a different mindset. My main statement is that the partitioning of hardware design into subgroups of verification, design, synthesis, STA and DFT has removed the understanding of the flow from the collective memory. Single skilled people to reduce the cost (experience with many fields in front-end is more expensive) is costing much more in the end because nobody remembers exactly what hardware is about. How we chose synchronous design to allow registers that shift in and shift out patterns to test for defects in manufacturing. How a digital design is partitioned the right way and verified on the right level with the right methodology. It all linked together and we were all on the same page, at least on the flow. This is not the case anymore in 2020.

Hardware is in its bubble and software is in its bubble. I believe that we first should understand each other, what exactly are we saying (the terminology thing I wrote about). And then, how do we solve things. But if it is driven from the business model of the past, we are going to get tools that create problems instead of problems that require tools to fix them.