Nine reasons to adopt SystemC ESL design

Now, why should you care?

Well, according to Gartner DataQuest, SystemC design and verification environments were used as the design flow front-end for about 100 SoC designs that taped out in 2003. Many of those designs are the flagship products of the world's leading SoC design companies.

According to recently published material, Texas Instruments used a SystemC ESL design methodology to design and develop its OMAP processor and modem platforms, and STMicroelectronics used it to design its Nomadik application processor. Moreover, leading system design companies such as Nokia and Qualcomm are now establishing SystemC-fronted design flows.

But why are all of these leading companies adopting a SystemC methodology? What is driving companies to enhance their existing design methodologies with SystemC ESL design? In other words, how do you decide whether you need a SystemC ESL design methodology?

You should consider SystemC ESL design when you have any of these issues:

1. When your SoC deploys employs multiple embedded microprocessors and DSPs to realize convergent functionality, such as communications and/or multimedia — and design of the complex architecture, functions and protocols is mired in a profusion of time-consuming RTL detail.

A SystemC ESL design methodology can reduce the architectural design time from months to weeks. How?

Optimizing SoC architectures necessitates the exploration and analysis of multiple candidate HW/SW partitioning schemes and hardware architectures, each with different performance and economic trade-offs. In this phase, the SoC architect is concerned with developing and optimizing system behavior and architecture.

But RTL's pin-accurate connectivity and nanosecond-accurate timing detail obscures the system-wide view, and slows design considerably. Using this low productivity approach, designers occasionally settle for "whatever works" rather than designing "what works best" — and risk launching an uncompetitive product. A survey of leading SoC companies performed by International Business Strategies (IBS) forecasts that SoC architectural development effort will soon exceed the physical design effort, so this productivity problem promises to become even worse.

SystemC ESL design speeds complex HW/SW partitioning and hardware architecture development by executing at a higher level of abstraction than RTL, using only those design attributes relevant to system design. This is the level at which "design intent" is most meaningfully captured — a level that affords the SoC architect a direct and clear view of system behavior.

The SoC architecture is designed with SystemC IP blocks connected via application program interfaces (APIs) to implementation-independent high-level bus models. Using transaction level modeling (TLM), the architecture is designed and verified in terms of functionality as characterized by high level block input and output events, and inter-block data transfers.

System IP components and buses may be modified or replaced with greater ease than at RTL, and simulated more than 1,000 times faster. Thus designers can quickly optimize the design to achieve "what works best."

The TLM model of the resulting optimized architecture constitutes an "executable specification" that drives the entire subsequent RTL implementation.

2. When full system, functional verification consumes an ever-larger majority of the design time and budget — and you're still not confident of first-pass success.

Designers report that SystemC ESL design can reduce verification time by so much that the overall design and verification effort by is reduced by 50%, and ensure that it's right the first time. In fact, this is the single largest factor in the ROI when a design team uses SystemC ESL design for the first time to design and develop an SoC. How does SystemC ESL design deliver this value?

RTL verification begins with the designer's comprehensive interpretation of system-level behavior in terms of a profusion of intra-block circuit states and nanosecond-accurate transitions, together with their associated bit-accurate bus behavior. It then requires the definition of a large number of detailed scenarios that exercise these behaviors, and the creation of multitudinous stimuli/expected responses for these scenarios, followed by simulation, which typically executes at one-millionth of real chip speed.

This is why verification consumes an ever-increasing portion of design time as SoC complexity increases. The verified RTL design is then transferred to synthesis. But what if the comprehensive interpretation wasn't comprehensive enough?

SystemC ESL design automates development of SoC architecture and verifies behavior in terms of high-level block input and output events, and inter-block data transfers, at the transaction level. This direct view of system-level behavior eliminates the manual RTL-to-system-behavior interpretation that is all too prone to being not comprehensive enough, and significantly reduces the number of both the scenarios required and the stimuli/responses necessary to test them.

The elimination of so many tasks dramatically simplifies verification effort and time. Moreover, cycle accurate TLM simulation executes more than 1,000 times faster than RTL.

The resulting system-level functional testbench constitutes the "golden" verification suite that ensures that the RTL design conforms to the specification. Moreover, SystemC's co-simulation capability with RTL enables the verification team to use the SoC's TLM model as a testbed in which to verify the RTL blocks as they become available.

3. When market survival requires you to spin multiple derivatives of the original SoC design at a consumer-like rate — and you're desperate for major design productivity increases.

Designers report that SystemC ESL design can reduce the time to spin a derivative by up to 75%. In fact, derivative design is where SystemC ESL design's productivity has the greatest impact on ROI. How?

Derivative design seeks to maintain the SoC platform's fundamental architecture and behavior while enhancing or adding selected features. The traditional approach is to establish a baseline RTL platform around the processors of choice for the first SoC, then design derivatives by "mixing and matching" appropriate RTL IP to realize the desired new functionality.

The problem is that "mix and match" implies a degree of "plug and play" that RTL IP models have never achieved because they are too complex. All too often, derivative design is almost as difficult as a "clean sheet" design.

Again, SystemC ESL design solves the problem. IP models really can be "mixed and matched" within a SystemC TLM of the SoC platform. The new SystemC IP is simulated rapidly with the rest of the SoC design, and the verified TLM model of the derivative SoC may be used as a testbed in which the RTL view of the new IP may be co-verified.

4. When SoC performance and/or low power can make or break your market position — and tweaking the RTL design cannot deliver the required improvements.

SystemC ESL design can deliver higher performance and achieve 10x to 20x greater power savings than that achieved at by RTL optimization. How?

SoC performance is determined primarily by HW/SW partitioning, the speed of processors, buses and memories, and their communications protocols. These system components and attributes cannot be tweaked in RTL. SystemC ESL design maximizes SoC performance by enabling the designer to devise the optimum HW/SW partitioning, hardware architecture and protocols.

Up to 80% of SoC power is consumed by processors, memories and related bus activity, and is thus heavily influenced by HW/SW partitioning and the efficiency of software algorithms and data storage. Again, these system components and attributes cannot be tweaked in RTL, so RTL tweaking can at best deliver incremental improvements in the remaining 20%.

Power-optimizing memory consists of minimizing the number of memory accesses and tailoring the memory architecture to the given application. Clustering the high-use memory accesses into a separate optimized cache memory simplifies memory transactions, which reduces power consumption (and often increases SoC performance), so cache memory architecture is power-critical.

SystemC ESL design's direct and immediate view of memory accesses and the activity associated with them enables direct correlation between the cache hit-miss ratio as a function of cache size, with a software Gantt chart to determine optimum memory sizes. Algorithm optimization candidates are identified from the correlation of function calls with the frequency of memory access.

5. When your system customers demand early SoC models to enable them to complete their designs and win design-ins — and they can't wait until the RTL design is complete.

This is often the case in wireless communications, and is one of the reasons that Qualcomm, one of the world's largest fables semiconductor companies, has standardized on SystemC.

System designers often need SoC models before silicon availability to verify the overall system design as it progresses, and to win early approval from their customers. Verification at this stage enables the system designers to detect and correct system non-conformance, or downright malfunction, prior to completion of prototype hardware, eliminating expensive and time-consuming hardware re-spins.

As well as being "late," the RTL model is not particularly suitable for this purpose, because its verification speed of one-millionth of real chip speed slows system simulation to a crawl. And the system designer doesn't necessarily know how to debug RTL.

A SystemC TLM model becomes available months in advance of the RTL implementation, encapsulates all of the system-level behaviors and attributes of interest to the system designer, and executes 1,000 times faster than RTL. Thus, it not only satisfies the system designer's demand for early SoC models, it also executes at a level of abstraction with which the system designer is most familiar.

6. When you commence software development only upon availability of a prototype — and software completion gates the product release.

With more than 50% of SoC functionality being implemented in embedded software, this is becoming the pacing item for SoC design. The IBS survey forecasts that embedded software development effort will soon exceed the SoC hardware design effort, so the problem is becoming worse. The Software developers must start work effectively before the RTL design is finished.

Prior software development methods using 'stubs' for peripherals can no longer adequately represent modern, multi-processor, multi-bus architectures. Without an early SystemC TLM prototype, the software is developed in total isolation from the hardware team design, creating a significant integration risk. Integration at the tail end of the design process makes time to market very unpredictable.

The use of FPGA prototypes to implement earlier software and system hardware integration will only improve the schedule moderately, because such prototypes still arrive too late. At this stage, RTL design changes — even minor ones — necessitated by problems experienced at integration are very time consuming.

Again, a SystemC TLM prototype enables commencement of effective software development months earlier. Hardware-dependent software, such as the RTOS, can be ported to the model without the necessity for connecting individual pins. Application software — which is hardware-independent — may be developed and ported using the TLM as a data flow model.

7. When co-verifying software with the RTL prototype is too slow, and you cannot verify enough to be confident that either is bug-free.

Qualcomm gives an example of this problem. A Viterbi decoder executes a packet in 20ms, but takes 6 hours to simulate at C/RTL level. Qualcomm estimates that 1,000 packets must be simulated to achieve a reasonable confidence level, but considers the necessary 6,000 hours of simulation time to be impractical.

SystemC ESL design can co-verify the hardware architecture with hardware-dependent software more than 1,000 times faster than at RTL, with cycle accuracy. That Viterbi decoder can be verified in less than 6 hours instead of 6,000. Hardware-independent software, such as application software, can be co-verified even faster by using a timing and protocol-independent simulation.

8. When your team wants to establish, or is already maintaining, a home grown system-level design environment, and it diverts significant engineering resource and budget from revenue-earning design.

Building and maintaining a homegrown ESL design environment is expensive, and offers no strategic differentiation. The homegrown ESL design environment makes as much economic sense as homegrown logic synthesis or place-and-route tools — none at all.

Moreover, many long-established ESL design environments leverage C or C++ dialects that, unlike SystemC, do not possess the concepts of time, bit-accuracy and concurrency that are necessary to describe the real world behavior and performance required by both RTL designers and embedded software developers. Worse, there is no standard C/C++ modeling methodology, resulting in a lack of usable models and difficulty in sharing and re-using those that are available.

The solution to both problems is to deploy a commercially available SystemC ESL design environment. The provider ensures that the tool, and you, remain at the leading edge of SoC design automation.

9. When you lose sleep over schedules, first time success, and design and mask cost over-runs — and you wonder how you can continue to compete with other leading edge SoC companies.

The solution is simple. Adopt the same SystemC ESL methodology that the leading SoC designers already use.

Electronic system-level design and verification methodology adoption is accelerating. ESL design tool demand is being driven by the challenges of complex multi-processor design with more than half the functionality implemented in embedded software, while SystemC is enabling ESL design's rapid adoption.

This year will see far more than 100 SoC designs using ESL design methodology. The methodology is finally crossing its adoption chasm because SoC design has met a chasm of its own — a system-level design productivity chasm.

Mark Creamer is vice president of CoWare, Inc.