Published on July 31st, 2013
High-level synthesis (HLS), which is software that transforms an untimed functional design into a register-transfer level micro-architecture implementation, has been an area of academic research since at least the 1980s. The intent of this early research sought to increase design and verification productivity by using a more concise high-level behavioral description such as C or MATLAB. Early HLS tools suffered from a number of adoption barriers that fundamentally limited the size and growth of the HLS market. These barriers to adoption including varied HLS description formats, a lack of high-level verification and design flows, and a limited set of design applications that could match the performance of custom RTL designs. In the last few years, major progress has been made to overcome all of these barriers to HLS adoption. This progress is having a profound effect on the growth and value of the HLS market.
II. The SystemC Standard
One of the early deterrents to the greater use and adoption of HLS technology was the unavailability of a standard high-level hardware description language. Each of the early tool purveyors of HLS operated from a semi-custom C-based input format. These customized C language formats generally included pragmas and unique commands in the source code that acted as guides and constraints for the HLS process.
With the creation of the Open SystemC Initiative (OSCI) in June 2000, the first representations of SystemC V2.01 were standardized. This set of C++ classes and macros provided an event-driven simulation interface in C++ and added support for abstract modeling of channels, interfaces, events, and libraries. SystemC was approved by the IEEE Standards Association as IEEE 1666-2005 and later updated as IEEE 1666-2011.
One of the great benefits of using SystemC for HLS is verification support. By using SystemC, you have a built-in event-driven simulator to address your verification efforts. SystemC supports multiple complex modules that can execute concurrently, can share data in memories, and can synchronize the execution using real signal-level protocols. Using SystemC, a large system-on-chip (SoC) design can be subdivided into multiple SoC IP blocks that can be connected by channels that follow a standard protocol. These complex modules can then be verified together to insure the overall operation of the SoC.
III. Design Flows for High Level Design and Verification
Another early deterrent to a greater use of HLS was the availability of tools and flows that supported the verification and validation of the high-level behavioral specification. Design flow support allows the seminal value proposition of SystemC-based flows—which is much greater productivity—to be realized. Figure 1 shows a representative SystemC-based design flow. While HLS forms a central role in this design flow, it is also critical to support virtual prototyping, RTL synthesis, and physical design. From a verification perspective, the virtual prototype forms an early software development platform and testbench that helps to verify the algorithm and to make hardware/software tradeoffs. At the HLS level, the testbench can be further refined and architectural tradeoffs can be made for timing, area, and power. Finally, this leads us to using the testbench to verify the structural integrity of the design in RTL, followed by providing a gate-level netlist for place and route. Having all of these pieces interoperable in a smooth flow is an imperative towards gaining the full productivity advantages that HLS offers the design team.
|Figure 1: TLM-Based Design Flow|
IV. Handling a Broader Set of Design Applications
Early HLS tools tended to focus on datapath style designs. These types of arithmetic-heavy designs lend themselves to unambiguous description in SystemC, with well-understood optimizations and scheduling algorithms that will generate a suitable design performance on this subset of the overall design set. Many of these designs were found in imaging and graphics applications where a high-level description was the best way to represent concurrency and repeated arithmetic operations. By only being able to improve productivity to the datapath portions of designs, overall productivity gains were subject to Amdahl’s law. Furthermore many of the early HLS tools constrained the target of these datapath designs to FPGAs versus ASIC designs to minimize the level of optimization needed.
Today there are SystemC-based HLS tools that can easily handle designs that are all datapath, all control or a mixture of both types of design. Additionally, some HLS tools now directly include powerful logic synthesis tools. This not only allows better control logic performance but it also helps to fine-tune timing, power and area optimizations. The result is that these HLS tools are able to deliver timing, power, and area that consistently matches or beats that of hand-written RTL. Figure 2 shows a number of new application areas in which customers are now applying HLS.
|Figure 2: Representative Areas that Utilize HLS Design and Verification|
V. Future Perspectives and Summary
It has taken a very long time for the HLS market to mature but the time has finally arrived for full-scale technology adoption. The emergence of the SystemC standard, design and verification flows, and tool optimizations that allow architectural exploration and a better quality of results (timing, power, and area) than custom RTL designs has fundamentally changed the HLS market trajectory. The opportunity to create a full-scale SoC design faster, with fewer resources, and with better results is now upon us.
The finest practitioners of HLS design methodologies actually have architecture and hardware knowledge, but also know how to express algorithms and architecture constructs in SystemC. They have learned how to utilize tool features to explore different SystemC design approaches to quickly optimize designs for these algorithm types. This opens up a whole new era of design applicability and design reuse via SystemC libraries that can apply to a very wide array of applications. Whether a design is dominated by datapath, control, or a mixture of both, no new IP module should be created without considering the use of HLS versus a custom RTL development.
Phil Bishop is the Vice President of R&D for System Level Design at Cadence Design Systems (San Jose, Calif.) Phil joined Cadence Design Systems in 2012 and has 30 years of experience in the Electronics Industry. Prior to joining Cadence, he was Corporate VP of Marketing for Magma, and before that he was the CEO of two startup companies in the EDA market, Pyxis Technologies and Celoxica Holdings. Phil also held leadership positions at Mentor Graphics, Motorola, and Boeing. Phil Holds an MBA from Duke University and has two engineering degrees from the University of Michigan.