feature article
Subscribe Now

Tool Integration for ESL Design

Electronic System Level (ESL) design claims to offer not just a quicker path from concept to hardware, but a cost-effective one when targeting platform FPGAs. And yet some hold out on ESL due to concern over the netlist’s quality of results (QoR)—a path from concept-to-silicon is not of much use if it does not meet performance and area requirements.

20081007_mentor_fig1.jpg
Figure 1: ESL Flow for C-Based Design

Using the same building blocks

Quality-of-results, however, not only depends on ESL synthesis itself but its interaction with downstream tools. For example, given that high-level algorithms are commonly specified in C++, the best algorithmic synthesis tools take standard ANSI C++ as input and automatically produce RTL based on user-defined design goals. This in turn must go through RTL synthesis and FPGA place-and-route before it reaches real hardware, as depicted in Figure 1. Hence, the extent of integration among these various stages can affect whether or not design goals are met. 

Within the C synthesis environment itself, designers should be able to explore different potential architectural implementations and examine the tradeoffs among performance, area, latency, and throughput. These tradeoffs can only be explored effectively if the hardware building blocks that are inferred from the un-timed C++ models have accurate timing and area information.

A C++ design is essentially an algorithm that describes a series of arithmetic operations that can be mapped to hardware components. To add timing behavior to the algorithm, delays for these hardware components must reflect their downstream implementation. For example, if a multiplier of specific size is to be inferred from a C++ model, the delay information must be understood in order to determine the scheduling of the overall algorithmic operation—and ultimately determine the best implementation for the design.

It is RTL synthesis that must provide this information—e.g., delay in nanoseconds and area in units of logic-utilization (depending on the FPGA architecture), as shown in Figure 2. Whether the component is a multiplier, adder, counter, memory, or other series of logic gates representing a specific function, each has correlating physical information needed by high-level synthesis.

20081007_mentor_fig2.jpg
Figure 2: RTL Synthesis Data is needed for C Synthesis
Library Component Characterization

Hence, accuracy of component data is largely driven by the degree of integration and certification across the C synthesis and RTL synthesis environments. By providing RTL synthesis timing information to C Synthesis, and using the same RTL synthesis tool for the actual implementation, architectural tradeoffs are based on the most accurate data, allowing the high-level synthesis tool to arrive at the optimal hardware implementation.

Not only should the two point-tools be certified with each other and the flow routinely tested, but library data must be kept up to date between them. Because RTL synthesis tools are always improving their quality-of-results, the latest version may have improved library component performance and area results. While the C synthesis tool should naturally have component data within its own installation, it becomes out of date when a new version of RTL synthesis is released, installed, and used within the current flow. This means a slightly older version of C synthesis may have out-of-date component information and implementation results may be inaccurate. The two tools should have a simple mechanism to keep data synchronized, such as pointing to the same component library. This ensures that architectural tradeoffs are made with the best information.

Design Analysis Across the Flow

Yet even with the most accurate component information, and with a robust high-level synthesis point tool, extensive analysis may be required to close in on aggressive design goals—not just within each point tool but across the entire ESL flow.

Among the advantages of C synthesis is that designers can find the most suitable hardware architecture for their algorithms, without having to change the actual C-code and without blindly coding different RTL implementations by hand as a matter of trial-and-error. This reduces the number of potential RTL bugs and allows for quick adaptation to changing specifications.

This does not rule out, however, the possible need to iterate throughout the flow to close in on aggressive timing requirements, for example. Out-of-the-box QoR from C synthesis, to RTL synthesis, to FPGA place-and-route is desirable, but analysis at various stages of implementation must be available to resolve any design closure problems.

Even hand-coded RTL must go through re-iteration at times to meet difficult QoR goals. High-end RTL synthesis tools allow intuitive cross-probing from critical paths in schematics and timing reports to the offending RTL code. This is in order to allow the designer to review the written code and understand the root-cause of QoR bottlenecks—such as performance, area, throughout, or latency issues. Similar cross-probing is typically available within the front-end C  synthesis environment itself (e.g., C-code, HDL code, schematics, Gantt charts). This degree of visibility should be available throughout the entire implementation flow, as shown in Figure 3. This way designers can easily trace back from post-synthesis and post-place-and-route data to source C++ code to understand what hardware is generated and why quality-of-results are being impacted.

20081007_mentor_fig3.jpg
Figure 3: A C-Based ESL Flow should allow the ability to cross-probe across RTL Synthesis and C Synthesis Environments

In such scenarios either the user constraints or C++ code may need to be modified. For example, if a multiplier path is failing after place-and-route, cross-probing from the timing violation to the C synthesis environment allows for experimentation with different levels of pipelining constraints. Because pipelining is a constraint, no C++ code changes would be necessary. As another example, perhaps the number of DSP blocks generated is not as expected. Tracing to the relevant C++ source code makes it easier to understand if and where a code change may be necessary.

Designers should be able to launch RTL synthesis from the C synthesis environment itself, either interactively or in batch  mode, with an automated import of design and constraints into the RTL synthesis environment. From there, they should be able to trace back-and-forth between both environments as needed. Given that 3rd party RTL synthesis tools typically encapsulate FPGA place-and-route for most FPGA vendors—this cross-probing ability extends to post-place-and-route data as well. Collectively, the implementation stages of C Synthesis, RTL synthesis, and FPGA place-and-route reporting are part of a well connected analysis environment.

Productivity through Implementation

With the ESL imperative being to improve productivity of hardware design, it is only natural that downstream tools integrate with ESL environments to augment productivity down to final implementation. Those who sit on the sidelines over concern of ESL-generated netlist quality-of-results might want to consider not only the quality of today’s ESL synthesis tools but the degree of integration now available in implementation flows. For those targeting complex FPGA platforms, the integration among algorithmic synthesis, RTL synthesis, and place-and-route reporting allows not only for more accurate results but an integrated analysis environment to assist with design closure.

 

Leave a Reply

featured blogs
Jun 1, 2023
Cadence was a proud sponsor of the SEMINATEC 2023 conference, held at the University of Campinas in Brazil from March 29-31, 2023. This conference brings together industry representatives, academia, research and development centers, government organizations, and students to d...
Jun 1, 2023
In honor of Pride Month, members of our Synopsys PRIDE employee resource group (ERG) share thoughtful lessons on becoming an LGBTQIA+ ally and more. The post Pride Month 2023: Thoughtful Lessons from the Synopsys PRIDE ERG appeared first on New Horizons for Chip Design....
May 8, 2023
If you are planning on traveling to Turkey in the not-so-distant future, then I have a favor to ask....

featured video

The Role of Artificial Intelligence and Machine Learning in Electronic Design

Sponsored by Cadence Design Systems

In this video, we talk to Paul Cunningham, Senior VP and GM at Cadence, about the transformative role of artificial intelligence and machine learning (AI/ML) in electronic designs. We discuss the transformative period we are experiencing with AI and ML and how Cadence is revolutionizing how we design and verify chips through “computationalizing intuition” and building intuitive systems that learn and adapt to the world around them. With human lives at stake, reliability, and safety are paramount.

Learn More

featured paper

EC Solver Tech Brief

Sponsored by Cadence Design Systems

The Cadence® Celsius™ EC Solver supports electronics system designers in managing the most challenging thermal/electronic cooling problems quickly and accurately. By utilizing a powerful computational engine and meshing technology, designers can model and analyze the fluid flow and heat transfer of even the most complex electronic system and ensure the electronic cooling system is reliable.

Click to read more

featured chalk talk

Introduction to Bare Metal AVR Programming
Sponsored by Mouser Electronics and Microchip
Bare metal AVR programming is a great way to write code that is compact, efficient, and easy to maintain. In this episode of Chalk Talk, Ross Satchell from Microchip and I dig into the details of bare metal AVR programming. They take a closer look at the steps involved in this kind of programming, how bare metal compares with other embedded programming options and how you can get started using bare metal AVR programming in your next design.
Jan 25, 2023
17,075 views