Today's semiconductor design specifications are as thick as a New York Times bestseller. With faster data rates, lower power requirements, emerging communication protocols, rapidly evolving standards, increasing memory demands and support of legacy software, the design task is exponentially growing. To get a product to market on time, design teams must digest and implement the entire product specification within a fixed development schedule to be successful. Consequently, semiconductor designers are turning to Electronic System Level (ESL) solutions in growing numbers.

To build increasingly sophisticated chips, engineers must be freed from low-level details and limiting methodologies. ESL design flows raise the level of abstraction from the register transfer level (RTL) to the system level. For today's multimedia and wireless devices, this is mandatory and is in fact analogous to the transition the industry made from schematics to RTL over 15 years ago. By working at the system level, design teams increase flexibility, improve verification and reduce design time. ESL delivers these benefits by enabling advanced methodologies based on second-generation, system-level tools and languages.

ESL methodologies are already in use in production design flows today. Many of the consumer electronic products sold during the last holiday season (such as HDTVs and wireless mobile devices) contained semiconductors built using ESL methods. A typical ESL design flow starts with untimed C code to model the system and develop algorithms. The high-speed models allow for extensive verification at the system level. The untimed C code is then refined for hardware implementation using C synthesis, which automatically generates the RTL implementation. Formal equivalence checking is used throughout the process to keep C code refinements in sync with the original untimed model and to comprehensively verify that the RTL functionality matches the C code.

But tools alone are not sufficient. Just as hardware engineers know how to write RTL to get predictable gate-level results, experienced ESL designers know how to write system-level code that yields high-quality RTL. Hardware designers moving to ESL will find that many of the best RTL design practices are not the same with ESL. For those who don't understand these nuances, there can be considerable pain. However, those who do will realize vast improvements in their daily design and verification tasks.

Experienced designers write the initial C code so that much of it can be reused in later refinements. This requires an understanding of how to express hardware detail in C code while maintaining fast simulations. By using algorithmic data types that faithfully represent hardware semantics such as truncation, rounding and overflow, the chance of introducing errors during refinement is reduced and simulation performance maintained. When C code is written that adheres to the ever-growing synthesizable subset, less refinement for synthesis is needed, leaving more time to focus on system performance and RTL quality of results (QOR).

The best way to demonstrate the power of ESL is to look at some real-world examples of complete ESL flows and ways in which designers are successfully raising the level of semiconductor design. Below are two case studies of ESL methodologies deployed at leading semiconductor companies in existing projects; the first uses an ESL virtual prototype and the other an FPGA prototype.

Boosting "correctness"
Integrated ESL flows can be extremely effective for algorithmic-based designs, especially in the demanding communications sector. To illustrate, we'll look at a MIMO (multiple-input/multiple-output) 802.11n design developed using an ESL methodology. MIMO is a new standard for wireless communication that uses two antennas at different frequencies to better manage signal interference. It is being widely adopted in wireless home networking applications that demand high, very cost-competitive performance. The digital MIMO receiver hardware is extremely complex and has an iterative learning process by which it adaptively synchronizes to a pair of wireless signals. The digital MIMO receiver is typically implemented purely in hardware, with little or no direct interaction with software.

For this type of design, it is very effective to start with an ESL virtual prototype written in C to simulate the adaptive synchronization algorithm before any hardware is constructed. An ESL virtual prototype is most appropriate when there is a "right" answer, when no requirement exists to run the hardware in real time and when the C simulation completes in a reasonable time. An ESL approach for a MIMO design focuses on system-level C simulation of conformance tests to verify that the system is working correctly. At the ESL level, the first step is to develop a bit-accurate C model partitioned into functions that are roughly equivalent to the major hardware blocks in the system. The conformance tests are then run on the C code to verify correctness.

The next step is to optimize the MIMO blocks in the system for hardware implementation. This is based on an iterative process of running high-level synthesis and checking the performance, area and power of each block in the system. The C code is then modified as needed to improve the block. Because rerunning the system-level simulation after each block-level change is not practical, sequential equivalence checking is used to verify that the optimized C code is functionally the same as the "golden" C code. A subset of the system-level simulation is run to verify that all the blocks, including changed blocks, continue to work together as expected. This process continues until all blocks have been optimized for hardware implementation.

Once all blocks are optimized and the design meets the quality targets, the entire system is synthesized from C to RTL. Sequential equivalence-checking is run once again to verify that the RTL for the ASIC has the exact functionality of the "golden" C code. At this point, a final sign-off verification is run on the RTL before moving on to RTL synthesis.

Three major differences exist between this integrated ESL flow when compared to a traditional flow that uses handwritten RTL. The first major difference is that by creating C code, designers can focus on the algorithm development, because changes are easier and quicker to make. The second major difference is that the majority of simulation is done in C code, which typically simulates about 10,000 times faster than RTL, allowing more vectors to run in less time. As a result, designers have greater opportunity to improve their algorithms and design quality. The third major difference is that the RTL is formally verified. Having an automated, formally verified path from system to RTL guarantees the correctness of the RTL and requires only one RTL simulation. When compared to the months of RTL debugging for a MIMO when using traditional methods, adopting an ESL approach makes eminent sense for such a demanding design.

FPGA in ESL
There are times when an FPGA prototype, instead of a virtual one, is more appropriate. This is especially true when the performance of the hardware is subjective, such as the crispness of an image, or when the number of vectors required overwhelms even C simulation. A case in point is when a design team is implementing an H264 decoder. The H264 standard is a complex algorithm for compressing and decompressing video that it is widely used in HDTV and related applications. There are two properties that make this system much different from the MIMO. The first is the tight integration of both hardware and software, which directly influences the verification effort. The second difference is that evaluating the correctness of the hardware is ultimately based on subjective standards. Although there are automated ways to test some aspects of the hardware design, the final, definitive test is how the image appears to the human eye.

The complexity of the H264 system, and the need to see a real image, means that the best approach for developing the system is to build an FPGA prototype. Similar to the MIMO application, the starting point is still untimed, bit-accurate C code, but the partitioning needs to consider hardware/software partitioning along with the major hardware blocks in the subsystem. Once this partitioning is complete, an initial set of C vectors is used to check the system. It is important to note that the full vector set is never run at this level; the massive simulations required would take weeks or even months.

Now the prototype is created. The C code is modified to be synthesizable, and high-level synthesis is used to construct RTL for the prototype. This RTL is rarely simulated, because it is immediately put on an FPGA for exhaustive testing. The prototype is used to evaluate image quality and the C code is modified until the quality is acceptable. The most interesting part of this flow is that the RTL for the FPGA is now the "golden" simulation model. Vector sets are captured for any problems uncovered in the FPGA prototype and then fed back into the C code for debugging. Sequential equivalence-checking between the RTL for the FPGA and the C code is used to ensure that the models remain in synch.

Because many of the architectural decisions needed for the FPGA may not apply to the ASIC implementation, a new version of the C code targeted for the ASIC hardware must be developed. Each block in the system is modified and synthesized to check whether area, power and performance goals are met. Similar to the refinement of the C code in the MIMO design, sequential equivalence-checking is used to verify C code refinements on each block. Once the C code meets the target specifications, a final formal equivalence run is used to verify that the C for ASIC has the same functionality as the C code for the FPGA prototype. The FPGA prototype, of course, is the "golden" model in this case.

Once all the C code is finished, it is synthesized and RTL is generated for the ASIC. Like the wireless MIMO application, a final sequential equivalence-checking run, and sign-off RTL simulation, is run.

Although this ESL flow requires a good deal of effort up front to develop an FPGA prototype, it eliminates virtually all RTL simulation. The majority of the design testing is done at, or near, real time, inside the FPGA. C simulation is only used for initial testing and debugging, and the only RTL simulation is for final RTL signoff. By eliminating the traditional long simulation times, this ESL flow delivers massive reductions in the development time and significantly increases the quality of the H264 product.

The other interesting point is that because the FPGA prototype acts as the "golden" model, the formal equivalence starts with the RTL for the FPGA, compares it to the original C code, and uses it to verify C code for the ASIC before finally implementing RTL for the ASIC. By using formal methods to guarantee correctness of design throughout the ESL flow, design teams avoid costly time spent in RTL simulation and debugging.

ESL for the masses
As these two real-world examples demonstrate, ESL-based design offers substantial benefits for mainstream design. The availability of mature, integrated design and verification flows from system level to synthesizable RTL helps designers confidently move to a higher level of abstraction for the creation of next-generation ICs. Whether used to design wireless consumer applications or high-bandwidth cable modems, the productivity of ESL enables innovation. ESL design allows hardware engineers to create, change and validate concepts instead of spending their time mired in the details of RTL coding.

Mitch Dale (mdale@calypto.com) is director of product marketing at Calypto Design Systems. Prior to joining Calypto, he was director of verification solutions with Mentor Graphics. He holds a BS in Applied Mathematics and Computer Science from U.C. Berkeley.

Bryan Bowyer (bryan_bowyer@mentor.com) is a technical marketing engineer in Mentor Graphics' High-level Synthesis Division. Bowyer has a BS in Computer Engineering from Oregon State University.