High-level synthesis has always been the “personal jet pack” of electronic design automation. We all know that someday, “in the future,” we won’t need all these cars and roads and stuff. We’ll each have our own personal jet pack to take us quickly and directly wherever we want to go. And, when we get there, we’ll do all of our electronic designs in abstract, powerful, high-level languages and synthesize them with high-level synthesis (HLS) technology. Hunger and war will be things of the past, disease will no longer exist, and billion gate semiconductor designs will be automagically conjured up from a few simple lines of easy-to-understand algorithmic code.
Timing analysis and RTL debugging? Bah! Those will be problems of the past – like repairing broken wagon wheels. In the future, our designs will be correct-by-construction masterpieces, and today’s verification issues will be distant memories.
Yep, back in 1994 that was pretty much the mainstream forecast for the future of electronic design, and it was just around the corner. Today, however, we know that corner has taken two decades to turn, and we are just now beginning to see what’s around the other side of it. It’s looking more and more like HLS is actually, finally becoming part of mainstream SoC design. And, although we may have dozed off (or retired) waiting for it to happen, it is no less dramatic and exciting today than it was twenty years ago when it first danced mysteriously onto the engineering stage.
This week, Cadence Design Systems announced plans to acquire the last major independent HLS company – Forte Design Systems. While Cadence was already a player in high-level design technology, the acquisition of Forte sends a strong message that Cadence believes the time is now for a major change in design.
High-level synthesis (HLS) is the current market-safe name for technology that was originally called “behavioral synthesis.” Back in those heady mid-90s, Synopsys, then the Gods of All Things Synthesis, launched (with great fanfare) a revolutionary tool called “Behavioral Compiler.” Behavioral Compiler was going to truly change the way the world designed. RTL methods were going to go the way of the dodo, and… as long as you could describe what you wanted to do in about fifteen lines of behavioral HDL, the vision was a success. The product, however, was a dismal failure. Behavioral synthesis technology was simply not up to production-level quality.
The promise of HLS is substantial. A design that would take 5,000-10,000 lines of RTL HDL code could be described in a couple hundred lines of behavioral code (which, these days, is usually something like SystemC or ANSI C/C++). Let’s pick a number and say that high-level code is 20x more compact. That means it probably takes 1/20th the time to write in the first place, and since the number of bugs we create is roughly proportional to the number of lines of code, we’d expect 1/20th the number of bugs as well. When you go to look for bugs, it’s a lot easier to find where they’re hiding in 200 lines of code than it is in 5,000. So far – that all sounds like a big win, right?
But the benefits just keep on coming.
HLS brings us the ability to do design exploration at the hardware architecture level. For any given design problem, there are usually hundreds, or even thousands, of different hardware architectures that could do the job. Each of those architectures brings different tradeoffs in performance, power, cost, and other important design variables. If you design at the RTL level, you are manually connecting yourself to a specific design architecture as soon as you write that code. (As the name implies, you are specifying what happens in your design at the register-transfer level.) Once you’ve written that code, you can optimize only within a narrow range (usually 10%-20%) because you’re stuck with that one architecture.
With HLS, however, you can quickly compare the characteristics of a wide range of potential architectures and choose the one that best fits your design objectives – without having to write and re-write thousands of lines of RTL code. You just describe what you want your design to do at the behavioral level (did we mention that takes far fewer lines of code) and let the tool do the heavy lifting to compare different potential architectures. Instead of optimizing in a puny-little 10%-20% design space, you can be dialing performance (frequency, latency, throughput), power consumption, and design cost/area by orders of magnitude.
So, if this has been around since the mid-1990s, why aren’t we all using HLS already?
After all, a dramatic increase in design productivity, fewer bugs, faster debug, and better designs, with the ability to do design exploration – those sound like compelling reasons to run out and buy a high-level synthesis tool.
There are several very good reasons for the slow adoption of HLS. First, HLS is really, really hard. In fact, I believe it is one of the most technically difficult problems ever attempted by EDA. Second, HLS requires a rethinking of our well-worn design verification strategies. And, finally, HLS requires a fundamental and uncomfortable mind-shift on the part of designers and management.
At a basic level, HLS usually involves two important steps: scheduling and allocation. Those steps can be done in any order, but they are completely dependent upon one another. Once you have completed either one of those steps, the other one is pretty straightforward – and therein lies the paradox. Allocation (or “resource allocation”) is the mapping of functional units (chunks of hardware) to tasks. Got two numbers that need to be multiplied together? This here multiplier will do it. Want to add the result of that to something else? How about this nice adder? See how easy that was? You are now an expert in resource allocation.
Of course, you’ll probably want to do more than one thing with each resource – you might have a lot of different multiplication problems happening in your design, and it wouldn’t be very efficient to build a separate hardware multiplier for each one. That means we’ll need to be sharing some of those resources and – that means we need a schedule. The schedule determines the cycle-by-cycle behavior of your design, and it must account for all data dependencies and hardware resources. It also must account for all the various constraints on your design – like how and when input data becomes available and how and when output data is required.
The algorithms that can do all this stuff are complex, and the computational complexity grows exponentially as the number of operations, hardware units, and constraints in your design increases. The exponential knee in the computational problem is so sharp that early behavioral synthesis tools could handle only a hundred or so operations. To go higher than that, tools had to rely on heuristics, which were, uh, let’s say, “less than stellar” when it came to producing high-quality results. Combine that with the unusual number of special conditions and constraints in real-world designs, and you have a nightmare from a tool developer’s perspective.
Early HLS tools reflected this difficulty by, well, sucking.
In the two decades since, however, technology has marched ahead, and today’s behavioral synthesis tools regularly boast results as good as – and usually better than – hand-coded RTL designs. They now do this across a wide range of design styles – including both datapath and control-dominated designs (whereas early tools were really suitable only for datapath designs). In countless benchmarks and tests, HLS has proven its mettle as far as quality-of-results and production-ready, real-world robustness are concerned.
That brings us to the second problem – verification.
Hey – didn’t we say that HLS methods should produce fewer bugs and make them easier to find? Yes, in fact, we did say that. However, most verification methodologies are built around verifying RTL. When that RTL is auto-generated by an HLS tool from some high-level language, we are left verifying some code that nobody wrote. That requires a different approach to verification at a fundamental level.
Luckily, the companies that want to sell us HLS also understand verification. Cadence, in fact, had the verification part pretty well covered before they even jumped into high-level synthesis. Today, you can adopt HLS without worrying that you’ll be left floundering without a verification strategy. For a little hard, cold cash, the EDA industry has your back.
This leaves us with the final issue with HLS adoption – the engineering and management mind-shift associated with changing proven design methodologies.
As engineers, we are constantly having to learn. When we spend years mastering a complex skill like RTL design, we are rightfully proud of it. It becomes a large part of the value we perceive that we bring to the table as professionals. Not surprisingly, when something threatens to make that skill obsolete (or at least less valuable) we ourselves feel threatened. Our high-value skill has been marginalized. Subconsciously, we resist that change – somehow hoping that our refusal to embrace the new will prolong the reign of the old. RTL experts are threatened by HLS because they fear no longer being “experts.” They don’t want to become “noobs” at the new thing.
Management has a different excuse. Since the dawn of EDA, “productivity” has been an unsuccessful argument for selling a high-cost EDA tool. When engineers find a six-figure tool that will make them “more productive,” management sees a large expense that will let engineers spend more time on the golf course. They don’t picture their development project being particularly more successful. However, “avoiding re-spins” has always had persuasive superpowers. Management will invest enormous sums to avoid being the one whose project cost the company millions of dollars in extra NRE costs and months of schedule delay.
HLS has always been a “productivity” sell. Now, however we are approaching the point where designs are so complex that they practically cannot be completed with conventional methods of stitching IP together with home-grown RTL blocks. HLS adoption joins “avoiding respins” as a fear-based decision. After all, you don’t need to worry about respins if you can’t even get to the first spin.
Part of the confusion in HLS is also identification of the customer. Many of the marketing efforts have historically positioned HLS as a power tool for HDL hardware designers. If you are doing RTL design, you can pick up HLS methods and technology and do your job better and faster with your new HLS superpowers. However, there has always been the promise of something more – giving a software developer the ability to create hardware directly from C or C++ code. While it is true that most HLS tools synthesize from C or C++, none have reached the level of automation one would associate with a “compiler.” Hardware design expertise is always required during major portions of the HLS design flow. However, HLS is still sometimes touted as a technology for accelerating software algorithms in hardware, making the market a bit confusing. Cadence’s position on that question is not confusing, however. Synfora’s focus on SystemC as a design language clearly targets the tool at hardware designers. SystemC is definitely a hardware description language (HDL) despite the C syntax, and its wide use in Cadence’s flow makes it a natural fit into the high-level design and verification environment.
The landscape of EDA companies selling HLS technology is interesting as well. The majority of today’s HLS technology was developed by startups, most of which were later acquired by large EDA companies. Synfora was acquired by Synopsys, AutoESL by Xilinx, and Celoxica by Mentor Graphics. Impulse C remains independent, and NEC’s CyberWorkBench is now being marketed by Aldec. Oddly, Catapult-C, one of the only successful HLS tools to be developed inside a major EDA company, was sold/transferred by Mentor to ESL startup company Calypto, reportedly in exchange for a stake in that company.
Before this acquisition of Forte, Cadence already had respectable HLS technology. Their C-to-Silicon compiler, introduced in 2008, was developed internally and has seen considerable success in Cadence’s system-level design flow. Craig Cochran, VP of Marketing at Cadence, explained to us that Forte complements C-to-Silicon, with C-to-Silicon excelling at control-dominated design and Forte’s Cynthesizer being dominant in datapaths. As in any EDA acquisition, the talent is probably a large part of the prize as well. Engineers who can develop HLS technology are a rare and valuable commodity.
This acquisition makes Cadence the clear commitment leader in the HLS space. This dual-pronged HLS offering fits nicely into the company’s system-level design flow and ecosystem. Since sending Catapult to the farm a couple years ago, Mentor’s commitment is unclear, and, despite buying Synfora back in 2010, Synopsys has had a bad case of PTSD regarding high-level synthesis since the Behavioral Compiler debacle two decades ago. Aldec’s NEC agreement is still young, so we don’t yet know if they will become a major factor in this space, and Calypto has soft-pedaled their Catapult HLS technology since acquiring it from Mentor. AutoESL has been absorbed into Xilinx’s Vivado tool suite and is being very productively focused on FPGA design, but that takes it out of competition in the EDA market.
Many large companies are adopting HLS into their real production flows these days, and Cadence’s timing on bulking up their offering couldn’t be better. With the reluctance of the rest of the industry to jump into the fray, Cadence could become the go-to supplier for HLS technology, and the rest of their system-level design and verification flow might frequently be pulled along for the ride. It will be interesting to see how it all plays out.