How effective use of ESL tools can increase your HW/SW system design productivity

Mitch Dale, Calypto Design Systems

October 5, 2007

Mitch Dale, Calypto Design Systems

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.

Innovation, collaboration
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.