Electronic System Level (ESL) design is a rapidly involving and ever more important segment of the Electronic Design Automation (EDA) industry. While ESL is still in a relatively early stage of deployment, there are many experiences that have been garnered from careers in the register transfer level (RTL) market that are applicable to this evolving domain.
A couple of important lessons learned from the RTL space:
* Hardware design has become highly “language” oriented
* Description of hardware devices requires specific hardware-oriented constructs, including hierarchical blocks, communicating modules, time and concurrency
* Efficient synthesis of the hardware description language (HDL) is critical
* Simulations in new languages must coexist with existing intellectual property (IP) blocks
* Development and support of industry standard languages is essential
High-Level Synthesis (HLS) is a critical element of a long-term ESL strategy. It provides a logical path to silicon for those parts of a system that a design team will implement as custom blocks, as opposed to existing block implementations from either past designs or those commercially acquired.
|Figure 1: C++ Synthesis in a Block-Level Flow|
Figure 1 above shows where HLS fits into a block-level implementation flow. Let's start with a description of this flow and then a discussion of the implications.
In this flow, a design team will pull together a multi-block system from blocks in commercial IP libraries and from their own internal IP libraries. In addition, some blocks will be created by the design team either by writing RTL code directly, or by writing some form of C++ code, and using an HLS tool to convert that C++ code to RTL.
One important issue with this flow is that the multi-block description that will comprise the “system” will be constructed and verified in RTL code. This is exactly the same as the current status-quo “” the flow that has existed for the last 20 years.
In this case, the use of the HLS tool in this context is certainly useful for block-level RTL code creation, but it does nothing to impact a major problem “” the verification of the multi-block system.
The reasons why a design team will insert C++-based HLS tools into this kind of flow include:
1) They are in the beginning phase of their adoption of HLS technology and are learning the process by implementing a few simple blocks with the HLS tool. This is a common situation during the initial deployment stages of HLS.
2) There are vast proportions of the design that already exist in RTL form and where higher level (i.e. abstract C++) models do not yet exist. In this case, verification of the multi-block system still takes place in RTL code. Simulations are slow and often require some form of hardware assistance in the form of emulation or field programmable gate array (FPGA) prototyping.
3) The HLS tool chosen only supports a block-level flow. Often, this is a function of the language used as input into the synthesis tool. If the input language does not support hierarchical design, multi-block connectivity and other such hardware modeling constructs, then the designer will have no choice but to remain at the block-level deployment of the HLS tool.
|Figure 2: C++ Synthesis in a System Level Flow|
Now, let's consider an alternative to this flow, shown in Figure 2 above . In this case, functional blocks in IP libraries exist as high-level SystemC models that have transaction-level interfaces. The multi-block system is then constructed from high-level blocks with high-level interfaces (known as transaction level).
Because simulations of these kinds of systems are orders of magnitude faster than RTL code, multi-block functional verification can realistically be done using software simulations often called “virtual prototypes.” This is different from “hardware prototypes” that use custom FPGA verification boards.
In this flow, the HLS tool can be applied after the high-level verification process. Inserting HLS technology at this point in the flow and the development of this design methodology brings the maximum benefit to moving to a higher level of abstraction.
That's because it yields significant productivity gains not only in the design implementation process “” such as the synthesis of the custom blocks “” but also in the verification domain.
In addition, the form of the IP stored in the IP repository is high-level C++ that has the additional benefits of being more re-targetable, more maintainable, and, overall, more reusable.
If this is so, why don't all design teams use this second flow? A number of valid reasons were listed above. For example, during the transition from gate-level design to RTL design back in the late 1980s, design teams did not throw away all the gate-level IP and simply switch over to RTL-based synthesis. It took time to develop new IP in the RTL languages and for that to become the dominant flow.
The vision back then was that one day 100% of the bulk of designs would be created using RTL synthesis tools for implementation and this analogy holds true today. HLS tool developers believe that, in the near future, all designs done today with RTL synthesis tools will be done with HLS tools.
These HLS tools will be initially adopted on a block-by-block basis. It's critical to remember that the flow in Figure 2 above must be the eventual target.
Then, why is language so important to this problem? Is not one flavor of C++ the same as another? The answer is no. A number of HLS solutions on the market support the industry standard SystemC extensions to the C++ language and a number of other solutions that claim to support ANSI-C++.
The serious tool providers that claim to support only ANSI-C++ actually provide extensions of their own. They recognize that if they provide only ANSI-C++ as delivered with a GNU C++ compiler, they will be uncompetitive and restricted to narrow niche markets.
They are asking design teams to adopt a non-standard extension to ANSI-C++ over an industry-standard extension to ANSI-C++ – SystemC.
However, the problem runs deeper than that. None of the proprietary extensions to C++ offered by these tool suppliers offer the richness of SystemC and none can fulfill the promise of the system-level flow articulated in Figure 2.
For certain kinds of blocks they can provide viable synthesis to RTL solutions. Yet, they will be restricted to block-level implementation and cannot help design teams move to a design methodology that impacts both the design and verification processes.
Covering the majority of design styles is an important requirement for any HLS technology to replace the current RTL synthesis tools as the front-end to the design process.
Rather than being restricted to the traditional “datapath-only” niche of traditional ANSI-C++-based HLS tools, it is critical that solutions be delivered that can handle models that implement complex control behaviors.
This implies that the input mechanism (or, the language) needs to support a variety of constructs that hardware designers require. These include:
* Hierarchical design
* Well-defined modules with clear inter-module communication mechanisms
* A notion of “time”
Straight ANSI-C++ does not provide these constructs. A productive HDL that supports both the transition from RTL code as well as the high-level abstractions required for the future must add extensions to ANSI-C++ to provide them. SystemC is one such set of extensions.
The question is often asked: “Who will be the primary users of HLS – hardware engineers, hardware architects or software programmers”? Based on my years of experience in the HLS market, I believe that the vast majority of HLS users will be hardware engineers who will move from RTL implementation.
These hardware engineers need specific constructs in their specification (or modeling) language that allow them to express their intent in the most accurate and productive manner. Software languages such as C++ have some attractive impacts on the high-level modeling of hardware, but they do not provide all of the constructs required for this purpose.
That makes hardware-modeling-specific extensions a must for higher level design to succeed. SystemC is an industry standard that enjoys wide support and is the most viable choice.
Sean Dart is president and chief executive officer of Forte Design Systems. He joined Forte in 1997 and has more than 20 years of software design experience, 14 of those years in EDA. Prior to joining Forte, he was chief technology officer of Speed Electronics S.A., a company specializing in front-end design tools for logic synthesis flows. Dart graduated from the University of N.S.W. in Sydney, Australia.