Electronic-system-level (ESL) design flows are for real. They're in use right now at some of the world's largest systems houses, and with those flows, chips are being taped out and put into production. So obviously, ESL flows can be made to work. But does this mean that everyone is happy with the state of the ESL art? In a word, no. ESL design, which comprises any tools, languages, models, or methodologies that operate at a level of abstraction higher than the register-transfer level (RTL), is slowly taking shape as users continue their ongoing shakeout of available resources. Standards organizations such as the Open SystemC Initiative and the SPIRIT Consortium, among others, are moving toward a set of standards related to intellectual-property (IP) integration.
Alas, ESL design still isn't for the faint of heart. For systems-on-a-chip (SoC) design teams, many bumps lay in the road between a high-level functional design description, a sheaf of IP-block datasheets, and a finished design that comes out of the fab on time and under budget.
ESL design flows and methodologies don't just appear out of thin air, but rather someone is responsible for putting them together and ironing out the wrinkles. In this report, the architects of ESL flows at six large systems houses will spill the beans about their methodologies. They'll discuss what works for them, where the holes exist in their flows, and what they'd like to see happen to make ESL really fly. Take heed, EDA vendors: Consider this an open letter from your ESL constituents.
ESL AT EMULEX
Emulex Corp., based in Costa Mesa, Calif., is a maker of enterprise-level storage-area network (SAN) technology, and Terry Doherty, principal engineer, is responsible for Emulex's ESL efforts. Emulex has now used an ESL approach on three SAN controller projects all told, one of those being a second-generation device.
Emulex's ESL methodology centers around building SystemC hardware models and using them to explore and refine the algorithms meant for SAN traffic management. "Our cycle-approximate SystemC models are accurate at the inter-faces but not necessarily accurate internally," says Doherty.
A continuing issue for Doherty and Emulex is the validation of RTL against the SystemC hardware models and vice versa. "Are the assumptions made in the models valid? Does the RTL accurately reflect the model? These things are still very difficult to prove," says Doherty.
Emulex is weighing the merits of two approaches to this dilemma. One is to adopt usage of SystemC assertions. The other is to employ a code-conversion tool for converting RTL to SystemC and then running the resulting models in its high-level modeling environment (Summit Design's System Architect, Visual Elite, and Vista).
Among the code-conversion tools Emulex has evaluated is Carbon Design Systems' VSP. "Carbon gives us a pretty good speedup, but I'm not 100% convinced it's fast enough to do the job," says Doherty.
Another issue with the code-conversion approach is that any remaining bugs in the RTL will end up in the system-level model. "That's why, in the long run, SystemC assertions may be more promising," says Doherty. "We can insert them into the models and bring them into the application-specific integrated-circuit (ASIC) simulation environment to check against throughout the process."
FREESCALE'S FLOW
For most ESL adopters, the technology serves to address the challenges posed by growing design complexity. Such is the case at Freescale Semiconductor's Wireless Modem Products Division, where Ryan Bedwell is system-level design manager.
"The complexity of the systems and software precludes use of a serial flow," says Bedwell. Thus, Freescale's philosophy toward ESL emphasizes concurrency (Fig. 1). Freescale's flow begins with performance models of the hardware blocks for a quick analysis of the architecture in terms of latencies, throughput, queue disciplines, shared resource contention, and power consumption.
As the design gels, the performance models must be gradually extended into a functional executable specification that serves as a system-level virtual platform. "It's important to push the use of untested software on an untested hardware model, or the 'double-blind bringup,' as early as possible," says Bedwell.
That executable specification is assembled starting with areas that are of concern from an architectural standpoint. Its function is architectural validation as well as early firmware/ read-only-memory (ROM) code development, hardware/soft-ware co-verification, and RTL co-simulation. "The executable spec is a timed model, maybe cycle-approximate," says Bed-well. (Some refer to cycle-approximate models as Programmers' View with Timing, or PVT.)
In addition to its design-related uses, the executable spec serves as the foundation for a "fast virtual prototype," which is a "productized" version of the executable spec suited for distribution to software developers. The fast virtual prototype has most of the timing information stripped out to increase simulation speed. It also includes a user interface with which software coders can execute their latest builds.
Yet another model that can be derived from the executable spec is a detailed performance-analysis model. While the fast virtual prototype satisfies the needs of about 95% of the overall software development effort, the detailed model is used to create and optimize "that 5% of really critical code," as Bedwell puts it.
Bedwell cites the need for architects to embrace the use of high-level models for making decisions. "Architects should see their fledgling ESL flows as a new tool for gaining insight," says Bedwell.
To make life easier, Bedwell also has a wish list he'd like filled. From IP vendors, he'd like to see transaction-level models (TLMs) become a standard part of IP deliverables. "I think untimed and cycle-accurate views are required. I'd also like an approximately timed view, but it's harder for everyone to agree on just what that means," he says.
A key wish-list item for Bedwell is the adoption of standard application-programming interfaces (APIs). "I like SystemC and what's come out of the Open SystemC Initiative (OSCI) and its TLM Working Group. But we need more. We need standards at a higher level of abstraction, and we need much faster development of new interfaces," says Bedwell.
From EDA vendors, Bedwell calls for open APIs. "We do not want to be locked into a specific vendor," says Bedwell. "When we write code, it's got to be movable. We can't work in a single-vendor environment."
Vendors, Bedwell opines, should "find differentiators that work within the context of open standards, fill some of our needs without locking us in. That might not be what they want to hear, but that's what we really need."
Reprints
