ESL synthesis: tips for implementing a viable ESL-synthesis flow

Here’s a checklist of what to do and what not to do when performing ESL synthesis. The items discussed help set realistic expectations for those about to take the plunge.

Nancy Wu, Gary Smith Consulting -- EDN, July 15, 2010

View as PDF

It would be an understatement to suggest that the ESL (electronic-system-level) market is an enigma. At the 1994 DAC (Design Automation Conference), vendors touted ESL as the panacea that would catapult the next growth spurt in the EDA market. The next 10 to 12 years were a bit disappointing in regard to the mainstream adoption of ESL methods. Depending on how you break up the data, the ESL market in 2005 likely accounted for $150 million in revenues across approximately 20 to 25 companies. Thus, mid-2006 represents a good point at which to assess the ESL user community.

According to early adopters at the time, the top three benefits of ESL were its ability for high-level specification, its strong capabilities for architectural exploration, and the existence of reasonable tools and methods for high-level verification. During the same period, the top three challenges were the fact that ESL offered no clear path to RTL (register-transfer-level) implementation from high-level specification, significant gaps in ESL methodology and flow, and the absence of embedded-software designers from system-level interactions. According to an anonymous user at a major North American electronics-system OEM at the time, the Holy Grail for ESL was an executable and synthesizable specification that designers can simulate and eventually sign off at a high level of abstraction.

By mid-2009, this Holy Grail was still missing. But there has been progress, especially in the synthesizable-specification arena. EDA analyst Gary Smith says that three key segments in ESL are stable and growing: architectural design and exploration, which is primarily the behavioral exploration segment that CoWare and The MathWorks serve; software virtual prototypes, or virtual software development, the tools—from CoWare, Synopsys, Vast, and other vendors—that enable software validation on models of the intended hardware; and ESL synthesis, the tools that generate RTL code from various high-level specifications, including C/C++, and SystemC from companies including Forte, Mentor, and Synfora. Smith calculates that each of these segments grew 30 to 80% on a year-over-year basis during 2008.

As with any other technology, ESL invites squabbling among vendor technologists and early adopters about the goal of synthesis. One goal seems to capture the key aspects from a user perspective: An ESL-synthesis platform enables high-level specification, optimization, and verification and automatically leads to verifiable RTL code with result quality comparable to that of manual methods.

Smith asserts that a viable path to implementation from high-level specification to RTL code enables mainstream users to adopt leading ESL-synthesis tools. In his view, the time for return-on-investment justification has passed; it is now time to educate new adopters about rules of deploying ESL-synthesis tools.


Based on input from the technical media and user postings over the past six months, there still appears to be a fervent, vendor-biased debate on one key issue: which high-level language should participants in the EDL market use? This issue is not trivial; it lies at the core of industry participants’ objectives for deploying an ESL-synthesis flow.

The choice of high-level language can be a critical factor for successful use of ESL. C/C++ offers the highest level of algorithmic exploration, and designers can easily simulate it with freeware. The greatest challenge is that C/C++ has sequential execution semantics and provides no explicit support for parallel structures. Obtaining good results for the synthesized RTL requires an advanced parallelizing compiler embedded in the synthesis tool to automatically extract parallelism in an application. Thus, the quality of the parallelizing compiler distinguishes one tool from another.

SystemC has emerged as the high-level specification language for hardware modeling and verification. SystemC has seen strong adoption on the hardware specification and, therefore, verification, side in Asia—primarily Japan—and Europe and within a host of consumer-electronics OEMs. SystemVerilog, on the other hand, is essentially a high-level hardware-verification language, one step higher than RTL. Clearly, the benefits a user hopes to derive from adopting ESL drive the choice of high-level language and, thus, the level of abstraction.


All of these architectures have one or two core processors that assume a supervisory role, a main bus structure, embedded memory, and a variety of off-the-shelf IP (intellectual property) for interfacing and control. Each has three to eight application processors or computationally intensive accelerators. These components include hardware accelerators, graphics accelerators, image-signal processors, video accelerators, and security engines. The application processors and accelerators therefore form, in conjunction with the interconnection fabric and embedded-software stack, the basis for competitive differentiation of the SOC. Everything else is essentially off-the-shelf IP.

Such application processors and accelerators, along with interblock communications, dictate what you must specify, verify, and synthesize at ESL. The other leg of system-level differentiation comes from the various stacks of application-specific embedded software. Not surprisingly, programmers debug most such software in C/C++ during the architectural and functional-exploration stage. Thus, true ESL-design specification should begin at the C/C++ level. Proponents of SystemC may disagree with this assessment. However, SystemC primarily finds use in transaction-level modeling that enables performance validation at the system level.

The issue of sequential execution of C/C++ and the challenge of handling parallelism and implicit control also arise. Vendors and leading-edge customers offer several observations.

Most customized logic for new SOCs comprises application processors and accelerators—computationally intensive accelerators with a predominant datapath structure. These architectures put design teams at the forefront of architectural exploration. Architects have for several years been using C/C++ for high-level modeling and specification. The ability to do both high-level specification and functional verification, with an automated path to implementation, brings out the ultimate benefit of adopting ESL. In addition, both Mentor and Synfora have now generated dozens of customers that are willing references that these tools more than adequately handle a flow to RTL. For example, Synfora boasts a unique parallelizing compiler that seamlessly handles both the datapath and the control-logic components of application accelerators.

You must separate the issues of timing verification and performance verification. The focus of high-level verification is functional behavior and the possibility of running more test vectors. Although C/C++ lacks explicit timing information, designers can specify clock frequency and overall performance requirements and can verify them starting with a high-level specification in C/ C++. The design team should, however, relegate the issue of detailed timing analysis to SystemC and RTL.

If the goal of adopting an ESL methodology is to begin with the highest level of abstraction with a proven path to implementation, it makes sense to begin at the C/C++ level. Designers can now generate both an RTL model and a SystemC transaction-level model from this specification. You can successfully implement an ESL synthesis flow using C/ C++, including Mentor’s CatapultC and Synfora’s Pico. For the more than 75% of the design community still using handcrafted RTL for design specification and verification, the issue is to outline the options available and set the right set of expectations for successful implementation of an ESL methodology.

Mentor and Synfora provide a list of top dos and don’ts that their users have adopted after going through the learning curve of implementing an ESL-synthesis flow. Some common themes advise designers to design at the highest level of abstraction; build architecture awareness into the code at the highest possible level of abstraction; and optimize architecture, system, and power constraints at the high-level design phase. Results matter, and the length of the learning curve and ease of adoption are important productivity considerations. However, you cannot compromise by accepting results that are not in the same quality range as handcrafted RTL. Keep in mind that these are company- and application-specific metrics that are difficult to generalize.

Consider verification early and often and how it fits into the overall picture of your high-level-synthesis flow. A key benefit of high-level synthesis is to do most of the verification and debugging at the highest level of abstraction. The vendor’s ESL-synthesis tool must thus provide capabilities to debug both functional and performance issues rather than force you to debug at RTL. You should also determine whether the ESL tool generates both RTL and SystemC models, so that hardware designers can perform transaction-level-modeling analysis.

Target larger blocks of logic. Otherwise, you derive no productivity benefits, and the flow and methodology will not scale to larger blocks or real-life designs. You should also use true hierarchical abstraction and ensure that the ESLsynthesis tool supports a multilevel hierarchical method. If the tool internally flattens the design before synthesis, this flattening adversely affects your ability to reuse or retune the design. This loss also affects the issue of results.

Your tools should also provide visibility into what you are building and the downstream design implications. You should have high-level control over architectural trade-offs and the ability to drive RTL implementation.

Systems comprise datapaths, control logic, and IP. The productivity boost of designing at a high level comes from the deployment of complex systems. Pay close attention to how the ESL-synthesis tool handles and optimizes control logic. The synthesis tool should be able to automatically connect the sub-blocks without manual intervention at the RTL.

---

For More Information
ARM	Gary Smith EDA	Synfora
Broadcom	MathWorks	Texas Instruments
Desaisive Technology Research	Mentor Graphics	Vast Systems Technology
Forte Design Systems	STMicroelectronics