It’s been more than twenty years since I started working on high-level synthesis (HLS). You might say I’ve studied the topic a lot. For most of those two-plus decades, HLS has been widely considered the “design methodology of the future.” And there are those who have held onto the belief that it always will be.

For those of you not in tune with the terms, high-level synthesis is the automatic creation of hardware architectures from behavioral descriptions. At first, HLS was known as “behavioral synthesis.” But, after some early bad experiences, the EDA industry quietly shifted the name over to HLS – hoping that nobody would notice or have episodes of PTSD when confronted with the idea.

Why has HLS been so slow to find its way to mainstream adoption? First (and foremost) because HLS is really, really hard. Super hard. Crazy, maddeningly hard. Consider how difficult it is to write software to perform even seemingly simple human tasks – like driving a car, or recognizing English. Even for these basic skills that most humans can easily master, creating code that performs them with human-like decision-making can be a major challenge. 

Now consider how difficult it must be to write software that can perform a much more complex human-like task, one that only highly educated humans can master, like designing a sophisticated digital hardware architecture. There is no formula or algorithm that spits out an optimized solution. In fact, there is no clear definition of what “optimal” even means in this context. Any attempt to define it usually begins with, “Well, it depends…” 

Computer scientists will point out that the HLS problem is “NP-complete” and that any program we write must be relying on heuristic algorithms to make an educated guess (kinda like we human engineers always do). Nonetheless, over the years, with some very, very bright engineers working tirelessly on the problem, HLS has finally found its way to the forefront. 

Today, you can write some behavioral code in a language like C, C++, or SystemC, throw it at an HLS tool, and rapidly get back a detailed hardware design that is almost certainly better than the one you would have spent several months creating yourself in RTL. The productivity factor is amazing. A good hardware engineer armed with HLS can consistently design working hardware at 5x-10x the rate of a non-HLS engineer. And, when the HLS-equipped engineer needs to make an architectural change, the amount of work required is minuscule compared to an RTL revamp.

Cadence has been in the HLS business for years. The company’s C-to-Silicon Compiler has developed a following and has proven itself very capable for certain classes of designs. About a year ago, however, Cadence decided to double down in the HLS game, and they acquired Forte Design Systems – along with their popular Cynthesizer HLS tool.

Cynthesizer was strong in many areas where C-to-Silicon was not. For a while, the choice of Cadence HLS tools depended on what types of design you were doing. C-to-Silicon if your design was more control dominated, and Cynthesizer if you leaned toward datapaths. That made things a bit confusing and difficult for Cadence customers who often had design components with both sets of characteristics.

Now Cadence has merged the two tools into one new engine called “Stratus High-Level Synthesis Platform.” Stratus, the company claims, has the strengths of both C-to-Silicon and Cynthesizer, making the decision process for customers much simpler and the learning curve much easier to conquer. Cadence says Stratus can be used “across an entire system-on-chip (SoC) design.”

Cadence says HLS is now mainstream. The company claims that 15 of the top 20 semiconductor companies rely on HLS, that HLS projects regularly go into the 10M-30M gate range, and that over 1,000 tapeouts have been completed with HLS. That sounds pretty mainstream to us.

Cadence says that Stratus has been designed to optimize around the complex set of engineering goals faced by today’s chip designers, like rapid ECO turnaround, low-power, IP re-use, and routing- and timing-optimized RTL generation. Modern design projects are constantly juggling these factors – as well as the daunting challenge of verification – just about every day of their highly stressful design lives.

One of these in particular, IP re-use, deserves a closer look when it comes to HLS. Today, the vast majority of the re-usable IP is distributed in RTL form. That means you can drop the IP block into your design, and it will (you hope) synthesize nicely down into a set of well-behaved gates that play nicely with the rest of your creation. But different designs have different design goals. And most RTL IP blocks were designed with one specific set of tradeoffs in mind.

Additionally, most RTL IP was designed with pretty specific parameters regarding the target implementation technology. A change in the silicon process or in the available cell library can be a major roadblock for RTL IP use. However, when we distribute IP blocks in high-level language that can be synthesized with an HLS tool, a vast new world of possibility opens up for us. Using the same IP block, we can create a wide gamut of architectures, optimized for latency, throughput, power, area, or whatever our key constraints may be. We can also easily adapt to different changes in the process or library that affect cell-level timing (something RTL IP cannot readily do).  And, if we have source code, changing the behavior of HLS IP is much more straightforward than trying to reverse-engineer complex RTL to make a tweak.

Clearly HLS IP would be a major improvement in the world of re-use. And, it would bring a major change to the HLS market. Today, HLS is mostly used for designing at the block level. That means even big companies often have only a few HLS users – the gurus who are crafting the functional blocks for the rest of the team. But if we all start consuming HLS IP, we’ll all need HLS tools. It moves HLS from being an IP-producing tool to also being an IP-consuming tool. If you’re in the business of selling HLS tools, that could be very good news indeed. 

Cadence says they are focusing on this high-level IP model and working to provide an environment that facilitates the creation, management, and re-use of high-level IP. Since the company has also recently made a big investment in becoming a major IP supplier, the combination seems natural. Stratus itself looks to be a solid contender in the HLS race. It encapsulates many proven, successful Cadence technologies such as the Encounter RTL Compiler. It is designed to work smoothly in the Cadence design, implementation, verification, and IP re-use flows, and it should be a natural evolution for design teams already fluent in Cadence’s tool suite. 

It remains to be seen how the high-level IP story will play out in the real, practical world. But, if Cadence can pull it off, it will certainly usher in a new era in HLS adoption – moving the technology from early mainstream to commonplace. It’ll be interesting to watch.