For several years, the semiconductor industry has not been driven by a single killer application, but by the convergence and consumerization of existing markets. Moreover, the increased complexity that comes with 90nm and smaller geometries has made product development harder and more costly.
The net result for engineers is a myriad of severe challenges, including hardware/ software (HW/SW) co-design, power management and verification. An Electronic System Level (ESL) methodology offers a viable solution to these challenges if it includes a clear-cut path to established implementation flows.
ESL, which is defined here as design and verification done above the RTL, is used today by most semiconductor and system companies. For years, architects have been writing ESL models to prototype and validate systems.
In the past, however, other engineers seldom used these models. What has changed is that ESL languages, tools and methodologies now exist, which fosters reuse and allows the ESL investment to be leveraged across the design process.
|Figure 1: Separation of computation and communication allows for reuse across verification.|
An ESL approach to design invigorates innovation and collaboration. Designing at higher levels of abstraction frees engineers from mundane details, giving them time to explore multiple architectures, quickly make trade-offs and understand decisions in the context of the whole system.
Without ESL, it becomes impossible to manage the interdependence of algorithm refinement, power consumption, HW/SW interfacing and intellectual property integration while still meeting production schedules and budgets. Similar to the shift from gate level to RTL over a decade ago, engineers are learning new languages, tools and design methods.
And like before, there are hurdles to overcome. ESL promises increased productivity. Numerous ESL offerings are available, including system modeling tools, HW/SW co-design, behavior synthesis, optimization tools and verification solutions.
Even if these tools deliver on the promise of productivity, they will not be successful unless they remain tightly linked to the established RTL implementation flow – this is a prerequisite.
The value of behavioral synthesis is diminished if the RTL code does not fit into the RTL implementation flow with better than average quality-of-results. Likewise, system modeling tools must work with RTL models, or the productivity gained with ESL is minimized by remodeling and additional verification.
Performance benefits of ESL verification are clear. But unless confidence of system verification can be leveraged onto the RTL implementation, the engineer is left with repeating, or worse, incomplete RTL verification. With ESL, productivity gains from faster system verification, true HW/SW co-development and increased power savings are ready for the taking. The tools and methodology exist. But the question is: How do we bridge system and RTL design?
There are more ESL languages, language extensions and language abstractions today than there were three years ago. This is a sign of a new market with an increasing number of companies that are solving problems in uniquely advantageous ways. Standards organizations are trying to keep pace.
However, the landscape is changing quickly and it appears that there will be multiple languages. While much has been written about SystemC and SystemVerilog, the relevant point is that hardware engineers need a solid understanding of software concepts and object-oriented programming in order to take advantage of ESL.
Writing system-level models requires design trade-offs between performance and accuracy. In general, the more abstract the model, the higher the performance and the quicker it is to create.
However, abstract models have less correspondence to hardware timing, power and architecture. Likewise, models with specific hardware detail run slower and take longer to code, but easily link to the RTL domain. Transaction models balance performance, and hardware details at the transaction level are becoming well-established.Performing verification
Behavioral synthesis is typically thought of as the link between ESL and RTL implementation. This is a misconception. In fact, verification is the bond between ESL and RTL domains. Engineers require faster verification. ESL models meet that need and, with a little forethought, can be used for RTL verification.
Experienced design teams write system models in such a way that they can be lever aged across system, software and hardware verification. For example, the clean substitution of communication and computation leads to reuse of code across models.
By using software encapsulation, different interfaces and levels of performance are possible for a given function.
For example, a video encoder processes images in a pipeline fashion. Each stage calculates an intermediate result and passes it to the next. With a structured approach, the computation in each stage does not change, but the interface between stages does, depending on the purpose of the model.
A function call interface is used for system verification, while a transaction interface for HW/SW verification and pin-level, cycle-accurate interface is used for hardware verification.
To further leverage the extensive system-level verification onto RTL code, Sequential Logic Equivalence Checking (SLEC) formally proves that system models and RTL models are functionally equivalent. This gives design teams the confidence that what they are building into silicon has the same functionality as their original system model.
SLEC works by establishing the interface alignment between models written in different levels of abstraction and language. It then applies sequential analysis and formal techniques to ensure that the two models are the same for all inputs conditions over time. In simulation terms, this is the same as running all possible test benches and checking that outputs match. Clearly, for even the simplest designs, exhaustive RTL simulation would take years of computation.
The most successful and widely adopted examples of an ESL use can be found in verification. ESL models have the flexibility and performance that make them ideal for system verification. They can directly be used to verify hardware implementations written in RTL.
Enabling SoC designs
According to a 2006 Gartner report, 70 percent of ASIC designs are system-level integration/SoC. Correspondingly, every SoC has a system integration and HW/SW co-verification challenge. Pair this with the need to assimilate IP from other groups or third parties, and the RTL verification effort can take months.
The influence from consumer markets demands quick assembly and creation of new feature sets. The rapid definition and re-configuration of SoC design requires an ESL design methodology. The architectural freedom of ESL methodology allows engineers to specify assembly functionality without the burden of defining the micro-architecture and cycle timing. ESL synthesis and optimization tools take advantage of this abstraction to optimize timing, area and power.
An ESL design methodology enables efficient SoC assembly and concurrent HW/SW co-design, which translates into shorter time-to-market, higher design quality and lower development costs.
Historically, architects used system models as a prototyping platform. But simply using system models for algorithm development does not take full advantage of ESL. Today, design teams with established ESL flows integrate system models into their RTL implementation. They write system models so that they can be reused for system, HW/SW and RTL verification.
ESL is changing the way designs are done. The benefits are clear, even though there are trade-offs and techniques to consider. With a good understanding of software programming, engineers armed with ESL tools are moving design to the next level of productivity.
Mitch Dale is Director of Marketing at Calypto Design Systems Inc.