For about two decades, hardware designers have been trying to use high-level synthesis (HLS) tools. The primary goal of high-level synthesis tools has been to increase design and verification productivity by raising the level of abstraction and by defining the architectures using less code. In addition, the idea is to also reduce complexity and the number of bugs introduced due to human-error, increase simulation speed, and facilitate exploration of alternative micro-architecture choices.
This article describes the work done at Texas Instruments (TI) to research the suitability of the latest generation of HLS tools for hardware design. Particularly, the analysis is focused on C-to-Silicon Compiler from Cadence Design Systems. The findings will interest RTL designers and architects who might be considering adoption of HLS tools, methodologies, and flows.
Past experience with High Level Synthesis
At TI, multiple HLS technologies and tools have been investigated. These were based on C/C++, custom languages, as well as SystemC in recent projects. The limitations and challenges faced were manifold. Some tools focused either on control logic or data-path thus limiting their applicability. Others would have custom constructs or languages, making integration with existing flows inefficient. And in most cases, it was difficult to generalize the performance of a tool across various designs as tools gave different results on different designs – one tool could deliver better results than another on one design but would be worse on a second design.
In almost all cases, one advantage was noticeable – designs implemented at a higher abstraction level indeed accelerate the implementation process and reduce the occurrence of low-level implementation bugs that are routine in RTL code. It is also easier to quickly try different operating points for frequency and explore the tradeoffs – something that cannot be practically achieved in an RTL flow.
Requirements for adoption of HLS tools
Before HLS flows can be adopted in the mainstream, there are two major requirements for the technology to fulfill. First is the return on investment, and second is the maturity and ease-of-use of HLS tools.
1. Provide sufficient value to justify the costs of adoption
a. Equal or better than hand-coded designs in terms of quality of results in implementation
b. Order of magnitude improvement in design productivity
c. Equal or reduced verification workload
2. Maturity, ease-of-use requirements for tools
a. Help designer understand when a design is optimal
b. Unified/integrated solution for control and data-path
c. Extensive debug support and visibility into high level implementation
d. Tight coupling with industry accepted synthesis tools
e. Equivalence checking
f. Incremental synthesis for ECO
g. Clean RTL output
h. Ease of integration of structural components (memories, hard macros, etc.)
How do SystemC simulations perform these days compared to C or C++?
About 5 years ago we used SystemC to develop models of our designs during the architecture exploration phase. Synthesis from SystemC was immature at that point, so we did not perform any synthesis from SystemC, but we had hopes to move in that direction. The stumbling block we hit was the performance of the SystemC models, which was somewhere between one and two order of magnitude slower than C or C++. We found that there was a lot of simulation overhead involved in using the SystemC data types, which was the primary cause of the poor simulation performance. Following that experience, SystemC was not used for subsequent projects.
If the tools or libraries for SystemC have improved since then, we may have to take another look at it. I've always believed that SystemC held great promise as an integrated synthesis and verification language.
Frank, you bring up an interesting point about the history of High Level Synthesis. The architects of C-to-Silicon Compiler were well-aware of the many shortcomings of the previous generations of HLS tools (Behavioral Compiler and Visual Architect were 2 or 3 generations ago).
Thus CtoS was designed from the ground-up to specifically address these shortcomings.
Namely:
*SystemC adds value over C++ to better describe hierarchy, concurrency, and other hardware care-abouts in an _industry standard_ way (important to develop full methodologies!).
*Tight Integration to implementation flows means great QoR with predictable logic synthesis timing closure and ECOs.
*Complete design support means the big productivity gain works for all design logic –not just the datapath.
*And now since all the logic is driven by HLS, functional verification moves up to TLM which offers the largest productivity gains.
*Plus CtoS still you full visibility and control of everything via its very modern GUI (unlike those previous tools)
These add up to show why now is the time where technology is enabling the next required step up the design abstraction curve. And why many large, complex designs are being taped out using CtoS.
I was an earlier user of Cadence's previous HLS offering, back in the '90s when they bought an HLS tool from a Swedish company, integrated it into SPW and called it Visual Architect.
Back then we only used it on DSP designs, and we got similar big boosts in productivity compared to manual RTL coding -- but with many of the same caveats mentioned in this article: unfamiliar design flow, limitations on debug capability/visibility, etc. One benefit of that earlier HLS approach was that design capture was graphical, so it was at least a more familiar flow for existing SPW users.
Fast forward 15 years to today, and it looks like the deck chairs have been rearranged, but fundamentally, not that much has changed for HLS.
Back then, our HLS flow looked much like the flow described in the article, except that our design entry was in SPW + Visual Architect, which had high level models in C++ and the output was an RTL controller and an RTL DSP block. Back then we used Synopsys for RTL synthesis, but Cadence did have their Build Gates synthesis tool they bought from Ambit.
So today Cadence offers "C-to-Silicon". C++ models are now System C models that the user must write -- no more block diagram design capture -- Build Gates has been replaced with RTL Compiler (a big improvement), and Synopsys now owns the SPW tool. Let's not forget that Synopsys was also offering Behavioral Compiler back then, which fell by the wayside just as Visual Architect did.
Around and around in circles we go!
Our experiences at Cadence working with customer designs has shown that datapath-oriented designs require about 10x less lines of code in SystemC vs. RTL, while control-oriented designs are around 3-4x less lines of code. That's lines of code...the bigger efficiencies are gained in being able to verify and debug at a higher level and easier re-use, and these are less dependent on the nature of the design.
It would be nice to see efficiency for a range of designs. I would expect control oriented designs and data path designs to have very different efficiencies. Can we get some more examples?
To save this item to your list of favorite EE Times content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.