We've all heard about the RTL-to-GDSII flow. Lately there's
been discussion about a TLM (transaction-level modeling) to GDSII flow. How
about embedded Linux to GDSII? Such a concept is implied by a newly
announced collaboration between ARM and Cadence to create an "ARM optimized
System Realization solution."
To drill down a bit into what all this means, let's start with
System Realization. As described in the EDA360
vision paper, System Realization is the completion of an end system ready
for applications deployment, including hardware (multiple SoCs, FPGAs, boards,
packaging) and software (the entire stack up to applications layer). With more
differentiating value going into applications or "apps," this is what
semiconductor vendors are increasingly expected to provide.
System Realization can only come about with a robust
third-party ecosystem, which is why the System
Realization Alliance, with 24 initial members, was announced along with the
ARM collaboration. But where does embedded Linux come in? The EDA360 paper
argues that silicon IP should be assembled into IP "stacks" that include a
physical layer, a synthesizable layer, a verification environment, and driver
software. Cadence provides such a solution today with a USB 3.0 IP
Including driver software is an important step towards
system development because 1) the driver provides a direct link between the
application and the hardware and 2) most hardware teams really hate driver
development. But drivers work best when they're fully optimized to work with
the underlying hardware. So, as part of the new ARM/Cadence collaboration,
Cadence will test its IP stacks with embedded Linux that's optimized for ARM
Running the ARM-optimized embedded Linux on top of the
drivers will point the way to driver enhancements. The end result will be
better power and/or performance for ARM-based devices. In one test, USB 3.0 IP received
a 20-30% performance boost just from enhancements to drivers. What's interesting
to me is that you can get these kinds of gains through software alone,
complementing the optimization you do in hardware. And this illustrates why the
EDA industry can no longer focus solely on hardware.
Connecting to Hardware
The next challenge is to link the embedded Linux world with
the hardware development and verification environment (and ultimately GDSII).
That brings us to another phase of the collaboration announcement. ARM and
Cadence are working to link ARM IP and software development tools including the
RealView Development Suite, Fast Models, DS-5, and the VSTREAM transactor with
Cadence verification tools, including the Palladium-XP Verification Computing
Platform and the Incisive verification suite.
These links will facilitate hardware/software co-development
and co-verification. With the use of Incisive Software Extensions, hardware and
software verification could be managed by a single metric-driven verification
In a third part of the collaboration, ARM and Cadence will
expand their existing collaboration on AMBA IP-verification IP pairs. This reinforces
the "IP stack" concept, which includes verification IP.
Extending the Flow
The overall message, I think, is that "RTL to GDSII" and
even "TLM to GDSII" are not enough. What we really need is an "application to
GDSII" flow. It will take some time to develop everything this implies, but for
now, we have a nice start as a major EDA company (Cadence) reaches up into the
embedded Linux world to provide better optimized IP.