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
(). 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."