Chip Design Magazine..

Now online at www.chipdesignmag.com: “Trends” reports, iDesign, IP Designer, FPGA Developer, Blogs, Resource Catalog, Back Issues, ... Includes
www.chipdesignmag.com April 2008
Lead Story:
BURNING ISSUES IN
TESTBENCH AUTOMATION
Also in this issue:
MEMORy CONTROllERS − BUIld OR BUy
65-NM dESIGN − GETTING IT RIGHT
FlExIBlE RAdIO: AN SdR AlTERNATIvE?
Affiliate Sponsors:
The SPIRIT
Consortium
Guide

EVER GET THE FEELING RTL DESIGN
JUST ISN’T CUTTING IT ANYMORE?
Electronic System Level Design What if you had the option of producing and verifying
your complex designs up to 100 times faster while maintaining exceptional quality levels? You’d
take it right? Of course you would, because Mentor Graphics ® has perfected ESL methodology.
ESL elevates design to a higher level of abstraction so you can accomplish more every day, and
move your complex new products to market on time, every time. Use the right tool for the job.
To learn more go to www.mentor.com/AVM or call us at 800.547.3000.

More gates, more speed, more versatility, and of course, less cost
— it’s what you expect from The Dini Group. This new board features 16 Xilinx Virtex-5
LX 330s (-1 or -2 speed grades). With over 32 Million ASIC gates (not counting memories or
multipliers) the DN9000K10 is the biggest, fastest, ASIC prototyping platform in production.
User-friendly features include:
• 9 clock networks, balanced and distributed to all FPGAs
• 6 DDR2 SODIMM modules with options for FLASH, SSRAM, QDR SSRAM, Mictor(s),
DDR3, RLDRAM, and other memories
• USB and multiple RS 232 ports for user interface
• 1500 I/O pins for the most demanding expansion requirements
Software for board operation includes reference designs to get you up and running quickly. The
board is available “off-the-shelf” with lead times of 2-3 weeks. For more gates and more speed,
call The Dini Group and get your product to market faster.
www.dinigroup.com • 1010 Pearl Street, Suite 6 • La Jolla, CA 92037 • (858) 454-3419 • e-mail: sales@dinigroup.com

In thIs Issue
18
1
8
15
1
4
6
Cover story
Burning Issues in TestBench
Automation
With intelligent testbench automation,
it’s possible to bring verification
costs back in line.
by Mark Olen and Matt Balance,
Mentor Graphics
Features
Keeping FPGAs on Time
by Andrew Haines, Synplicity
Focus Report: What Makes Chips Different?
IBM, Samsung team up to differentiate chips
with embedded software modules.
by Ed Sperling
Special:
Synplicity's Confirma Seminar Series
Make an Informed Build or Buy Decision
for Memory-Controller Solutions
When it’s time to make a memory mind, don’t
forget to measure all of the risks and rewards.
by Raj Mahajan and Raghavan Menon, Virage Logic
Get Designs Right at 65-nm and Beyond
Up-front planning and more attention to
detail can help make the transition to new
process nodes less daunting.
by Prasad Subramaniam, eSilicon
Cellular Standards May Demand
Alternatives to SDR
Is there a better way to meet growing
consumer demands than relying on softwaredefined
radios?
by Duncan Pilgrim, Sequoia Communications
READ ONLINE:
www.chipdesignmag.com
9
special section—
the sPIRIt
Consortium Guide
30 A Message from SPIRIT
33 Doulog
34 Evetronix
35 IP Extreme
36 Magillem
37 Mentor Graphics
38 Scarlet Code
39 Synplicity
Departments
4 Chip Design Online
6 Editor's Note-Synopsys and the
Power of Programmability
by John Blyler
8 In the News-People in the News
by Jim Kobylecky
9 Max's Chips & Dips — Silicon
Canvas Blows My Socks Off
by Clive “Max” Maxfield
14 BlogSphere -- Taken for Granted:
The persistence of ESL synthesis
by Grant Martin
16 Top view — Performance and Cost
Now Drive Emulation
by Luc Burgun, EVE
28 Dot.org— The Second
Commandment for Effective
Standards
by Karen Bartleson, Synopsys
40 No Respins— Compilation
Can Play a Big Role in System
Performance
by Clyde Stubbs, HI-TECH Software
www.chipdesignmag.com
Publisher & Sales Director
Karen Popp (415) 255-0390 x19
kpopp@extensionmedia.com
EDitorial Staff
Editor-in-Chief
John Blyler (503) 614-1082
jblyler@extensionmedia.com
Contributing Editor
Ed Sperling
Managing Editor
Jim Kobylecky
Coordinating regional Editor
Pallab Chatterjee
associate Editor—China
Jane Lin-Li
Chief analyst
Erach Desia
Business Editor
Geoffrey James
Executive Editor – iDesign
Clive "Max" Maxfield
Contributing Editors
Cheryl Ajluni, Dave Bursky, Nicole Freeman, Craig Szydlowski
Editorial Board
Tom Anderson, Product Marketing Director, Cadence • Cheryl
Ajluni, Technical Consultant, Custom Media Solutions •
Karen Bartleson, Standards Program Manager, Synopsys •
Chuck Byers, Director Communications, TSMC • Rich Faris,
Marketing Director, Real Intent • Kathryn Kranen, CEO, Jasper
Design Automation • Barry Marsh, Vice President Marketing,
Actel • Tom Moxon, Consultant, Moxon Design • Walter Ng,
Senior Director, Design Services, Chartered Semiconductor
• Scott Sandler, CEO, Novas Software • Steve Schulz,
President, SI2 • Adam Traidman, Chip Estimate
CrEatiVE/ProDUCtioN
Production Director
Stephanie Rohrer (415) 255-0390 x13
Graphic Designers
Keith Kelly & Brandon Solem
traffic Coordinator
Liz Matos (415) 255-0390 x20
SalES Staff
advertising and reprints
Karen Popp (415) 255-0390 x19
kpopp@extensionmedia.com
audience Development / Circulation
Jenna Johnson • jjohnson@extensionmedia.com
President
Vince Ridley (415) 255-0390 x18
vridley@extensionmedia.com
Vice President, Marketing & Product Development
Karen Murray • kmurray@extensionmedia.com
Vice President, Business Development
Melissa Sterling • msterling@extensionmedia.com
Vice President, Sales
Embedded Systems Media Group
Clair Bright • cbright@extensionmedia.com
to SUBSCriBE or UPDatE yoUr ProfilE
www.chipdesignmag.com/subscribe
SPECial thaNkS to oUr SPoNSorS
Chip Design is sent free to design engineers and engineering managers in
the U.S. and Canada developing advanced semiconductor designs. Price for
international subscriptions is $125, US is $95 and Canada is $105.
Chip Design is published bimonthly by Extension Media LLC, 1786 18th
Street, San Francisco, CA 94107. Copyright © 2008 by Extension Media
LLC. All rights reserved. Printed in the U.S.
• April 008 Chip Design • www.chipdesignmag.com

4������
� �� �����
� �� �����
4���4������4�����4�������4�������������
�����������������������������������������������
��������������
������������������������
4�������
� �� �����������
� � ����������
� �� �����������������
� �� �����������
� �� ����
��������������������������������
4����������
� ����������
� �������������
� ��������
� ����������������
� ��������
� ������
4���������
� �� ���� � �� ����
� �� �������� � �� ������
� �� �������� � �� �����
� �� ������ � �� �����

www.chipdesignmag.com
ChIP DesIGn OnlIne
Blogs:
www.chipdesignmag.com/blogs
JB’S CIRCuIT
With VC investment down
and acquisitions up, we’re
taking care of “now.” But what will
tomorrow be like?
TAKEN FOR GRANTED
Grant Martin takes a closer
look at our use of embedded
processors and ESL where, he points
out, “hope springs eternal.”
FAhRvERGNüGEN'
Juergen Jaeger celebrates the
skills and pleasures of highperformance
verification. Use the right
tools he proclaims and enjoy the journey.
RICK'S WIRELESS NETWORKING
The efficiency of a tool, Rick
Denker explains, depends
on how well it affects our end goals.
Rick’s blog is a model of efficiency.
PALLAB’S PLACE
Pallab Chatterjee takes a
close look at the SNUG
event in San Jose, reporting on talks
and new developments.
TuNING IN TO JIM
Jim Lipman continues his
Everyman approach to finetune
the mind-bending world of
technology and invention.
KOBY’S KAOS
Editor Jim K finds that most
future mistakes begin in the
past. If you forget the human element,
hard science can produce random events.
iDesign:
www.chipdesignmag.com/idesign
METhODOLOGY AND FLOW ChALLENGES
IN SYSTEM-LEvEL CO-DESIGN OF
MuLTI-DIE PACKAGED SYSTEMS
Today’s designs require new robust design
flows with concurrent capabilities that
bridge the communication gap.
COORDINATING FROM SILICON TO PACKAGE
A new IC/Package/Board co-design
and co-verification methodology needs
to be implemented.
IF YOu CAN’T MEASuRE PROGRESS
AGAINST YOuR PLAN, YOu hAvE NO PLAN!
There are verification technologies
available today that use markup languages
to capture functional verification plans,
enabling measurement of completion
throughout a project.
And always look for Max’s latest Chips
and Dips column!
Max's Chips and Dips: Silicon Canvas
Blows My Socks Off
By Clive (Max) Maxfield
Max is still trying to wrap his brain
around all of the incredible things the
company’s working on in the field of
automating analog layout.
vISIT
www.chipdesignmag.com
Recent Poll Results:
How will the chip design
industry fare 2008?
Grow – 52%
Level Off – 29%
Shrink – 19%
To take part in our current poll,
visit www.chipdesignmag.com
e-Newsletters
www.chipdesignmag.com/enewsletters
Stay ahead of the pack with latest industry
viewpoints and news from our e-newsletters.
Here’s a sample of recent issues:
ChIP DESIGNER
• The Case for Heterogeneous Multi-
Core SoCs
• Atom Launches for Low-Power
Processors
• Synopsys to Acquire Synplicity
IP DESIGNER & INTEGRATOR
• Algorithmic Synthesis Boosts
Platform-Based SoC Design and
Validation
• What You Need to Know about
PCI Express
• Field Programmable SoCs Require
IP-centric Solutions
NEW! - COMING TO A SCREEN NEAR YOu:
ChIP/PACKAGE/BOARD -- AN IDESIGN
NEWSLETTER - Edited by Clive (Max)
Maxfield
ChIP DESIGN TRENDS (CDT)
BIANNuAL REPORT – 2007
Basis of Report
• Over 44,000 unique, worldwide
and regional pre-silicon design
investigations
• Analysis and forecasting of key chip
design metrics, including power, die
size, clock speed, analog vs. digital
IP, metal layers, technology nodes,
memory usage and much more.
Available Now!
Report ID: TB10235
Price: $1,950 (One Issue); $2,950
(Two Issues)
To learn more contact: Melissa Sterling
at 415.970.1910 or
msterling@extensionmedia.com
4 • April 008 Chip Design • www.chipdesignmag.com

sensors expo
& conference
Education:
Featuring Nine Research-Based Technical Tracks:
• Novel Approaches to Measurement & Detection
• Wireless Sensing
• Systems & Embedded Intelligence
• Power Management, Battery Technology & Low-Power Sensing
• Sensor Standards
• Emerging Technologies & Applications
Including Three ALL-NEW Tracks Examining:
• Transportation Infrastructure & Structural Health Monitoring
• Machine Health & Predictive Maintenance
• “Green” Sensing Technologies & Applications
And Three Optional Pre-Conference Symposia:
• Digital Data Acquisition & Analysis Symposium
• Nanotechnology & MEMS/MST/Micromachines Symposium
• Energy Harvesting for Powering Sensor Applications Symposium
June 9 - 11, 2008
Donald E. Stephens
Convention Center
Rosemont, Illinois
www.sensorsexpo.com
Advances in Measurement, Monitoring,
Detection and Control
N e w A p p r o a c h e s • N e w T e c h n o l o g i e s • N e w A p p l i c a t i o n s • N e w I d e a s
OPENING KEYNOTE
James
McLurkin
MIT Roboticist, Inventor,
Researcher, Teacher
“Engineering
Creativity”:
Exercises for
the Right Brain
Expo Hall – Over 200 key suppliers showcasing their products and solutions at Sensors Expo.
Register Today & Take Advantage of the Early Bird Rates or Sign-up Now for Your
FREE Expo Hall Pass! Register at www.sensorsexpo.com or call 877-232-0132.
Please use your source code: 327M
Produced By: Official Publication: Gold Sponsors: Silver Sponsor: Media Sponsor:

eDItOR's nOte
By John Blyler
Synopsys and the Power of Programmability
Many have commented about the Synopsys’s intention to
acquire Synplicity - a high-end FPGA synthesis and hardware
verification prototyping company. Much has also been made about the
significance of the later capability, i.e., highlighting the important of
prototyping in any verification methodology. But I believe the FPGA
synthesis portion – that is, the programmability of reconfigurable
hardware – may ultimately prove to be as important. Let’s consider
what both capabilities have to offer
The capability to prototype complex ASIC/ASSP designs in
FPGA-hardware will complement Synopys’s existing product
lines, most noticeably their virtual prototyping business. You may
recall that roughly two years ago Synopsys expanded into the
electronic system level (ESL) market through the acquisition of
Virtio – a company that created virtual platforms for embedded
software development. Combing high-level virtual with hardware
prototyping means that Synopsys now covers both the software
and hardware sides of system level chip design.
Still, the acquisition is not without risks. FPGA-prototyping
is still a relatively low-end technique for verification – though
the hardware prototyping market is definitely a growth area.
Synopsys is well known for high end tools. Will they be able
to attract the developers who use FPGA prototyping? The
acquisition of Synplicity will help attract many of these
developers to Synopsys, but will the integration of the low-end
and high-end technologies be successful? Synopsys has some
system-level experience, but very little board level capabilities.
These will be challenges that must be overcome.
Still, I can’t help but wonder if a presence in
the “programmability” market won’t prove
as important as the capability to perform
hardware prototyping.
Now, let’s look at the timing of this intended acquisition.
Why now? George Zafiropoulos, vice president of solutions
marketing at Synopsys, explains that the removal of past
product overlaps contributed to the current acquisition. “A
few years back, we (Synopsys) had a product called FPGA
Compiler that competed with Synplicity. We exited that
market because we felt that our primary target market was the
high end ASIC space and custom IC space.”
Conversely, George notes that in the recent past Synplicity
focused on the structured-ASIC (S-ASIC) market. This
focus – at least in some measure – offered competition to
Synopsys. Synplicity has since exited the S-ASIC market,
just as Synopsys left the FPGA world. “We went from being
competitors to non-competitors,” said George. “ The door
was now open for both companies to collaborate together,
which we did about a year ago with a join marketing and
development program in verification.”
All of which makes good business sense. Still, I can’t help but
wonder if a presence in the “programmability” market won’t prove
as important as the capability to perform hardware prototyping.
For example, Intel’s recent announcement that they are developing
reconfigurable hardware capabilities – in the area of digital multiradios
SoCs – highlights the need for programmability in today’s
SoCs. Either way, the Synopsys acquisition of Synplicity seems
like a move in the right direction. ◆
6 • April 008 Chip Design • www.chipdesignmag.com

EVE AD

In the neWs
People in the News
J. MARK GOODE BECOMES PRESIDENT
AND CEO OF vIASIC
ViASIC Inc. has promoted J. Mark Goode to the
position of president and chief executive officer.
Goode holds a bachelor’s degree in music from the
University of Miami, a master’s degree in computer
science from New Jersey Institute of Technology, and a master’s
degree in business administration from the Wharton School at the
University of Pennsylvania
DR. ILIA OvSIANNIKOv JOINS MAGNAChIP AS
vICE PRESIDENT OF SOC ENGINEERING
MagnaChip Semiconductor Ltd. has named
Dr. Ilia Ovsiannikov vice president of SoC
engineering in the Imaging Solutions Division.
Ovsiannikov received a BS cum laude in computer
engineering from MIREA Moscow State Technical University as
well as an MS and PhD in Computer Science from the University
of Southern California.
MAuRY AuSTIN SELECTED AS MIPS CFO
MIPS Technologies Inc. has appointed Maury
Austin as chief financial officer. Austin brings
more than 25 years of financial experience to
the company. Most recently, he served as SVP
and CFO of Portal Software Inc. Austin holds a
bachelor’s of science in finance from the University of California,
Berkeley and an MBA from Santa Clara University.
GERhARD ANGST RECEIvES EDA AChIEvEMENT AWARD
Concept Engineering has announced that Gerhard Angst, its founder
and CEO—together with the company’s entire engineering team—
has received the EDA Achievement Award 2007 from edacentrum
(www.edacentrum.de), an independent association. This award is
given for results in research or development and for improvements
within the Ekompass Project.
JIM hOGAN AND ED ChARRIER
TO ADvISE PYxIS TEChNOLOGY
Pyxis Technology Inc. announced
that EDA veteran Jim Hogan
and KLA-Tencor vice president
and general manager Ed Charrier
have joined as advisors to the company’s board of directors.
Jim Hogan is general manager of Vista Ventures Partners. Ed
Charrier is vice president and general manager of the Process
Control Information Division at KLA-Tencor. ◆
KEEPING FPGAS ON TIME
By Andy haines
One of the big reasons companies love FPGAs
is because they provide a great way to get an
electronic product to market quickly and without
all the hassles of ASIC design. Early market entry
and being first with an application has proven over and over again
to be critical for product success. With FPGAs now containing
millions of equivalent ASIC gates, high-density RAM, DSP
functions, embedded processors and high-speed IO, finding a way
to take full advantage of all these resources without re-inventing the
wheel and maintaining the early-to-market advantage offered by
programmable logic, is becoming an increasingly tough challenge.
As ASIC designers have done for years, FPGA designers are now
turning to the use of IP as a solution. In fact, almost half of the
FPGAs designed today contain some sort of IP. IP may come
from an FPGA vendor, a 3rd party or developed in-house from
previous designs, but nevertheless it is quickly becoming standard
practice for higher-end FPGA design. With this migration
of IP into FPGAs comes new methodologies and design tool
requirements. A key problem here is that as the complexity of the
IP itself has increased, it has become critical for EDA tools such
as those for simulation and synthesis, to understand timing within
the IP. Synthesis for example needs to have good timing estimates
of paths within the IP in order to ensure optimization is working
on true critical paths within the design and that logic around the IP
is also optimized. This is not so much an issue for in-house IP, but
as more designers turn to 3rd party IP which is typically encrypted,
it can be a significant problem.
A second difficulty for FPGA designers comes in just locating
the right IP, and then determining technically if it will work in
their system. Working through legal agreements permitting
access to protected IP alone can be time consuming even if
only evaluating one or two alternatives.
What’s needed is an easy-to-use source for systems designers
targeting FPGAs to browse a wide range of IP offerings,
download and then evaluate it in their system. This would allow
designers to more easily determine the best alternative for their
particular design. At the same time IP providers need to be
assured that their IP is protected during such evaluations. EDA
and IP providers must work together to offer FPGA designers a
solution to their advanced IP needs. ◆
8 • April 008 Chip Design • www.chipdesignmag.com

By Clive (Max) Maxfield
Silicon Canvas Blows My Socks Off
MAx's ChIPs & DIPs
Recently, I was chatting to the folks at Silicon Canvas, and I'm still trying to wrap my brain around
all of the incredible things they've been working on in the field of automating analog layout.
Good grief, things are certainly moving fast in analog
EDA space (where no one can hear you scream).
Recently, I was chatting to the folks at Silicon Canvas, and
I'm still trying to wrap my brain around all of the incredible
things they've been working on.
Due to the fact that my background is that of a digital logic
designer, I have a tendency to focus my attention on digital
design tools and to neglect what's happening on the analog
side of the fence. I need to stop doing this, because I'm
coming to realize that there's a lot of really exciting stuff
going along in the analog domain.
Like many people, for example, I tend to think that analog
designs are still predominantly created painstakingly
by hand and that very little automation is available to
analog designers (with the exception of stuff like PCells,
of course). Similarly, like a lot of folks, I've considered the
Laker product from Silicon Canvas only in the context of
an analog layout editor – until now I didn't realize just how
much automation this little beauty provides.
Truth to tell, it can be a little tricky to fully grasp how
the Silicon Canvas product family has evolved over time.
Figure 1 provides a high-level historical perspective of the
way in which the Silicon Canvas products, starting with the
initial Laker layout editor, have grown into a full-featured,
technology-leading custom IC design flow.
Note that Laker OA is not a specific product per se, but instead
represents an Open Access capability that is of special interest
in context of the Interoperable PCell Library (IPL) initiative.
Now, let's see if I can do this justice without confusing the
issue too much. The original Laker-L2 was a rules-driven
analog layout tool that provided some sophisticated realtime
DRC/LVS capabilities. Of particular interest was its
concept of Mcells ("Magic Cells"), in which a simple forms-
Figure 1: A historical perspective of Laker product introductions.
driven interface allows you to quickly and easily create
analog cells without requiring any programs or scripts.
The next major advance was Laker-L3, which supported
schematic entry (for new designs), automatic schematic
generation (from legacy design netlists), and automated
schematic-driven layout capabilities that are fully integrated
with Laker-L2's powerful rules-driven technology.
Laker-L3 includes a custom floor planner that assigns
pin locations automatically, provides congestion map
information, and mixes soft and hard instances to
minimize the gap between top-down planning and
bottom-up layout realization. The integrated Stick
Diagram Compiler provides a high level of abstraction to
facilitate efficient transistor floorplanning, including gate
merging, swapping, and splitting. Meanwhile...Please visit
www.chipdesignmag.com to read more online! ◆
Clive (Max) Maxfield is author of Bebop to
the Boolean Boogie (An Unconventional Guide
to Electronics) and The Design Warrior’s
Guide to FPGAs (Devices, Tools, and Flows).
Max also is the co-author of How Computers
Do Math, featuring the pedagogical and
phantasmagorical virtual DIY Calculator
(www.DIYCalculator.com).
Chip Design • www.chipdesignmag.com April 008 • 9

Where the electronics design industry meets…
EDA tools, design methods and solutions
for ICs, ASICs, FPGAs and SoCs.
Electronic design has never been easy. And with
today’s growing technical challenges, customer
expectations, and competitive pressures, it’s not
getting any easier.
More than 10,000 members of the electronics
design community will convene in Anaheim in
search of the latest technologies and ideas and find
personal exchanges that spark creativity and drive
bold innovations.
Their destination will be the 45th Design
Automation Conference (DAC) at the
Anaheim Convention Center, June 8-13, 2008,
in Anaheim, California, USA.
So make your plans now. Come to the place where
design meets your critical challenges. Come to DAC.
Only DAC offers:
• A robust technical program covering the latest
research developments and trends, ranging from
management practices to products, methodologies
and technologies for the design of SoCs, FPGAs,
ASICs, digital ICs and more.
• Worldwide attendance from developers,
designers, researchers, academics, managers and
engineers from leading electronics companies and
universities.
• A vibrant exhibition with over 250 companies
displaying products, technologies and services for
the electronic design industry.
• A full roster of panels and presentations is once
again planned for the DAC Pavilion on the Exhibit
Floor, open for all attendees.

Call for Exhibitors:
DAC is actively expanding its exhibitor base to encompass the entire design eco-system from embedded
software and system-level design tools, IP, EDA, and design services through to silicon manufacturing. The
expanded scope of the show floor along with DAC’s unique booth/suite combination and world-class
conference and educational program makes participation a must for companies with products used in the
design and development of circuits and systems.
Contact Susie Horn at 303-530-4333 or Susie@dac.com for details.
June 8-13, 2008
Anaheim Convention Center
Anaheim, California
T +1 303.530.4333
F +1 303.530.4334
US Toll-free 1 800.321.4573
©2007 Design Automation Conference
www.dac.com

FOCus RePORt
What makes chips different?
IBM, Samsung team up to differentiate chips with embedded
software modules, but can it work this time?
Re-using embedded software has been the subject of
exuberant marketing for nearly two decades—and so far
it has amounted to little more than that. But in recent months,
quietly and far from the blaring hype, real-world testing is under
way to use software as a cost-effective means to embedding
functionality in a wide range of devices. Perhaps no where
is this development of re-useable embedded software more
evident than with the major players of the Power Architecture
(Power.org) community – especially with IBM.
The most experiment in re-useable software comes from a
joint effort between Samsung and IBM’s Haifa Research
Lab in Israel. If all goes as planned, IBM plans to begin
commercializing what is essentially a middleware framework
that allows embedded software to plug in and differentiate
semiconductors. That means in many cases it will no longer be
necessary to build new chips for every new device.
Exactly where this plays in the real world is unknown, but the
first beneficiaries are likely to be IBM’s partners in its growing
ecosystem, most notably the members of Power.org, which
includes companies such as Freescale, Sony, Cadence Design
Systems, Synopsys and Applied Microcircuits (AMCC).
The re-usable code project is based on what IBM calls the
Consumer Electronics Development Environment, known
inside IBM as COMPETENCE. At the heart of this
environment are architecture description languages, a class of
descriptive languages that includes Darwin, C2 and Acme, to
provide a high-level of abstraction for writing software. None
actually exists for the consumer electronics world, a fact that
IBM wants to change and to capitalize on.
Normally, embedded software is written for specially
developed processors with very specific functionality. With
COMPETENCE, a single chip design theoretically will be
sufficient to replace many designs, because the embedded
software modules will add different functionality.
The advantages are immediately obvious to anyone who has
designed chips for such areas as cell phones or MP3 players.
Each chip can cost many millions of dollars to develop, with
those costs escalating at each new process node. At 65nm and
45nm, non-recurring engineering costs render it impossible
By ed sperling
to earn a profit without an enormous sales volume. Adding
more functions only increases that cost, and it can slow the
time it takes to bring products to market, in large part because
of the difficulty of verifying the chip.
“The world of modeling is well known in hardware because
it’s so difficult to work with,” said Alan Hartman, research
scientist manager at IBM’s Haifa Research Lab. “In software,
this is new. But when you look at the cost of a luxury car, a
large part of that cost is the software.”
hISTORY REPEATS…SORT OF
In the realm of software, component-based systems engineering
is a relatively new field. Some of the groundbreaking research
was performed by Philips Electronics a decade ago using
various component models, and in the mid-1990s many
software companies including IBM had plans for software
objects—portions of applications rather than applications
themselves—that could be bundled together like Legos and
plugged into a framework.
The problem was that at the application level, these software
objects never played together like a single-vendor plugand-play
system. IBM, however, was large enough and had
enough of an investment in middleware that it could shift
the development to where there was a strong business need.
That need grew as the cost of developing ASICs and ASSPs
escalated into the tens of millions of dollars.
“If you look at multifunction printers, some have faxes,
scanners, and different speeds, and each is implemented by
a separate component,” said Hartman. “We can design a new
printer with new components so you only have to write a very
small amount of code.”
The approach plays off of the holistic design that IBM has
been pitching for the past several years. “What this allows
you to do is manage a product line as a whole,” said Julia
Rubin, an IBM research scientist for industry solutions in
the Haifa Lab. “You determine what features you want, and
only the pieces you want go to market.”
That works in principal, at least. But the real trick in this
scenario is what is relegated to software. Tony Massimini,
1 • April 008 Chip Design • www.chipdesignmag.com

chief of technology at Semico Research, said certain
functions are fine in software, particularly with a powerful
PowerPC processor running those functions. But he said
the model runs into trouble when it comes to video because
the response time has to be so high that it needs to be hardwired
into the processor.
“ The PowerPC has a lot of performance, and if it’s not a
portable application you may get away with it in software,”
Massimini said. “If you look at a car, the response time versus
streaming video is easy to accomplish in software. With a
portable application, you can overload the processor.”
WhAT’S IN ThE PACKAGE?
What IBM and Samsung are developing goes beyond just writing
embedded software, though. Hartman said the companies also
are providing an editing environment, the ability to validate the
software with rules and to configure a particular product.
“ Then, at the touch of a wand, you get general building
scripts,” he said. “Companies in consumer electronics have
already moved to a component-based architecture, so this
is a natural fit. What we’re also doing is taking legacy code
and componentizing it.”
When exactly that will become productized remains to
be seen, however. At this point, the legacy code work is
relegated to some future date. IBM will offer that type of
work as a service through its consulting group. However,
IBM researchers contend that fixing the bugs in software
is a relatively simple and inexpensive process, versus
trying to fix them in hardware. In part, that is because the
programming languages for software are relatively flexible.
C++, for example, is highly modular, compared with trying
to scour through massive amounts of verification data to
pinpoint a bug and then fix it in hardware.
LANGuAGE ISSuES
One of the reasons that ADLs remain relatively unknown in design
is that there is no single standard. As such, there is no agreement
on what needs to be included in the overall description.
IBM is looking to establish such as standard for the consumer
electronics industry, along with a modeling framework that
third-party components can plug into to provide consistent
behavior. IBM said it also plans to extend that framework
to other industries in the future.
FOCus RePORt
At least part of that will be based on a standard modeling
framework, called the Unified Modeling Language. IBM’s
COMPETENCE relies on the Rational toolset (see
diagram), which allows designers to develop components
based on established models. But how quickly all of this
technology comes to fruition, and just how widely it is
deployed, remains to be seen. Building better software,
particularly for the embedded world, is not a new problem.
REAL-WORLD APPLICATIONS
What this means for chipmakers such as Freescale,
interconnet makers such as AMCC, and large OEMs such
as Sony depends on when and how this technology hits
the market. Nevertheless, such moves could make both
companies more competitive because re-usable code means
faster time to market and lower NRE costs.
In Freescale’s case, for example, such code could be used across
a raft of vertical market applications, including automotive,
consumer electronics, industrial, and wireless, while for AMCC
the code would be used in embedded interconnect applications.
In Sony’s case, re-usable code could help cut NRE costs in the
consumer electronics market, where price is a key differentiator
for many of its competitors. ◆
Ed Sperling has spent the past two decades immersed
in technology and is the recipient of numerous awards
for journalistic excellence.
Chip Design • www.chipdesignmag.com April 008 • 13

Receive a Complimentary
EDA & IP Industry Market Report
Is your company a missing piece
in the EDA & IP industry?
The EDA Consortium Market Statistics Service
(MSS) is the timeliest and most detailed market
data available on EDA & IP. Top companies have
been participating in the MSS since 1996, but no
report is complete without ALL the pieces.
If your company is not contributing to the MSS, it
is a missing piece in the puzzle. Contribute your
company’s data to the MSS and receive a
complimentary Annual MSS Executive Summary.
What’s in it for your company?
• Worldwide statistics on EDA & IP revenue
• Ability to size your market
• Six years of market data for trends analysis
• The opportunity to make a positive difference
in the industry
For details contact:
mss@edac.org
(408) 287-3322
www.edac.org

photo courtesy of www.fotos.org
Confirma Seminar Series
Theme: Prototyping as Productive
Verification Methodology
When: May-June (Exact dates tbd)
Dates and Locations:
• Wednesday, May 28 - Sunnyvale, CA
• Wednesday, June 18 - Toronto, Ontario
• Thursday, June 19 - Schaumburg, IL
• Tuesday, June 24 - Austin, TX
• Wednesday, June 25 - San Diego, CA
• Thursday, June 26 - Longmont, CO
“The sophistication of verification tools and techniques has
increased with design complexity.”
– John Blyler, Chip Design magazine
** Agenda **
• Verification market and technology trends – 30 min
(John Blyler or Clive “Max” Maxfield)
There are many ways to verify ASIC and SoC designs, and
several tools have to work together to successfully complete
a design. But what are the recent trends and developments?
Which methodology is gaining momentum and which is losing?
And how do successful companies verify their designs?
ThE PERSISTENCE OF ESL SYNThESIS
Many people are familiar with Salvador Dali’s painting, The
Persistence of Memory:
When I look at developments in ESL, I sometimes think of
the painting and its title. Some of the old ideas in ESL must
be good ones because they keep coming back. ESL synthesis,
for example, has now been through at least two or three
generations. In fact, to many people, ESL = ESL synthesis
(or behavioural synthesis, or high-level synthesis). We have
seen some recent activity in this area - for example, Celoxica
got out of ESL synthesis to focus on FPGA-based accelerators
for high performance computing applications, and moved its
technology and team to Catalytic, forming Agility Design
Solutions. At the recent Electronic Design Process Workshop,
I saw Rishiyur Nikhil, CTO of Bluespec, give a talk on Parallel
Atomic Transactions in the Bluespec synthesis approach.
I’ve heard some people comment that they don’t really
consider Bluespec (using System Verilog and some particular
• Prototyping – a mandatory step for successful ASIC/
ASSP and SoC design – 60 min (Synplicity)
Prototyping, the use of FPGAs to verify an ASIC or SoC
design has come a long way and is no longer a ‘ad-hoc and
assembly required’ methodology. Prototyping has evolved into
a productive and without any doubt, highest performance,
verification solution. So what are the things you should
consider when deploying prototyping? And what are the
necessary steps involved to take an ASIC design and get it to
work on a prototyping board?
• And it works … - 30 min (customer)
Real-world example of a successful prototyping project. Design
setup, challenges, results.
• The HAPS prototyping systems – 30 min (Synplicity)
A closer look at the HAPS architecture and capabilities.
System set-up and configuration. Getting the most out of a
prototyping system
• Lunch
• Confirma demonstration – 60 min (Synplicity)
Life demonstration of the complete flow:
- preparing the ASIC design for prototyping
- design partitioning and implementation
- prototype system configuration and bring-up
- debugging the design and fixing errors
constructs to express their atomic transactions) to be “highlevel”
enough to be ESL synthesis. Most ESL synthesis
tools use C/C++/SystemC or other dialects of C as inputs.
However, the atomic transaction semantic used by Bluespec
is definitely more abstract than the normal way people write
HDL for RTL synthesis, so I think we can count it... Please
continue reading at Taken for Granted by Grant Martin at
http://www.chipdesignmag.com/martins/?p=6 ◆
Chip Design • www.chipdesignmag.com April 008 • 15

Top View
By Luc Burgun
Performance and Cost Now Drive Emulation
Within electronic design automation (EDA), the
emulation market sector has a set of dynamics all its
own. Just consider that this market has been growing steadily
since 2001. It went from $120 million in 2001 to $160+
million in 2007. To say that the emulation market sector is
thriving is almost an understatement.
Emulation has evolved from infancy at the end of the 1980s
to childhood in the 1990s and finally to maturity after 2000.
Yes, it has been around for close to 20 years. Who remembers
Supersim, the first custom field-programmable-gate-array
(FPGA) -based emulator launched in 1988? It pre-dated the
rise of Zycad, Quickturn, and Ikos—icons of the 1990s.
During the ’90s, significant engineering efforts were invested
to decrease the problem of emulation installation and enhance
debugging features. Until then, “black boxes” served in the absence
of native visibility into the mapped designs. In the early days, the
deployment of an emulation system came with a “field application
engineer in the box” to compensate for drawbacks. These limitations
drove the introduction of custom chip emulators to replace standard
FPGA-based solutions. Of course, the casualties of this trend
are legend and came from sub-par performance and prohibitive
cost. FPGA-based emulators responded by reaching Megahertz
performance in 1995. By the end of the 1990s, the typical selling
price of these tools decreased to 5 to 10 cents per gate from more
than 50 cents per gate.
Over the last 10 years, capacity has grown from 500,000
application-specific-integrated-circuit (ASIC) gates to five
million gates on an average design. For these reasons, FPGAprototyping
popularity soared at the beginning of the new
century. Within the past three years, the market for emulation
has evolved once again. Development teams are now requesting
higher performance, lower cost, and a more flexible test
environment. They also want debugging capabilities at a
higher level of abstraction. Meanwhile, hardware/software coverification
is driving the demand for higher performance and
software diagnostic validation. Billions of cycles are needed for
drivers and a real-time operating system (RTOS) or to execute
applications like high-definition display/compression.
According to the “old” metric, the price must be 1 cent per gate
to target software deployment or have access to the software
community. The actual goal is to reduce the cost per cycle. After an
active consolidation period, there are several strong competitors in
this field. Such competition will translate into a significant price
erosion.
While in-circuit emulation (ICE) is less popular, the need for a
more flexible test environment is growing. Application hardware
bridges fail to offer controllability/reproducibility. They also add to
the complexity of the test environment. In addition, synthesizable
testbenches (STBs) are difficult to develop. Transaction-based
verification (TBV) is the only alternative to quickly set up a test
environment for a full design.
At higher levels of abstraction, debuggers are needed. Although
it may be considered useful to generate waveforms of all signals
at any clock cycle, it won’t be effective. Instead, designers need
system-level hardware/software debugging tools because they
don’t want to look at the assembly code. Transaction-based
testbenches and a multi-layer debugging methodology are a
good way to address this need.
Looking ahead, the emulation market’s growth will come from new
applications, such as software development and design architecture
investigation or ESL emulation. These new applications will
continue to call for more performance and lower cost. Capacity
won’t be the key driver for this market—except for some specific
applications of more than 100-million gates. Performance and cost
are going to become predominant. Design teams will buy or renew
emulation because it will become fast and affordable.
Under these conditions, the use of custom chips is questionable.
They are slower than standard FPGAs and their development
cost is high at 65-nm technology. It doesn’t make sense to
invest $50 million to develop a custom-chip-based emulator
to address an annual market of $150 million in a competitive
environment and with lower margin.
Ultimately, standard FPGA-based emulators will address cost/
performance needs and keep the emulation sector growing. ◆
Luc Burgun is chief executive officer and president of
EVE in Paris, France.
Burgun is a co-founder of EVE and has 18 years of
experience in CAD development and digital system
design. He holds a PhD in computer science from
the University of Paris-Jussieu, France. Burgun can be reached at
luc_burgun@eve-team.com.
16 • March 2008 Chip Design • www.chipdesignmag.com

Methods-tools VeRIFICAtIOn
As design complexity has increased, design verification has
become an increasingly difficult problem. Today, project
teams spend more time verifying their designs than they do creating
them. To bring verification costs back into line with design costs,
teams need test benches that find more bugs with less engineering
investment. The answer lies in intelligent testbench automation.
This type of automation generates optimal sets of tests to improve
both productivity and effectiveness.
Through a unique, rule-driven test-generation technology,
intelligent testbench automation delivers many benefits.
For example, it cuts design respins by using rules to generate
significantly more unique tests than are possible with conventional
methods. In addition, intelligent testbench automation reduces
testbench bugs by minimizing the amount of testbench code that
engineers need to write. It also avoids the most time-consuming
testbench edits through a testbench redirection facility. This
facility allows engineers to change their simulation goals without
altering their test implementation code.
Intelligent testbench automation also eliminates duplicate
testing. It utilizes test-generation algorithms that use closedloop
adaptive coverage algorithms, which only produce unique
tests. By providing dynamic design-resource allocation and
facilitating layered testbench modules, this type of automation
also retargets module-level testbenches at the system level
without changing the testbench environment. Finally, intelligent
testbench automation enables testbench-module reuse through
functionality sub-setting and adaptive morphing technology.
OPTIMAL TESTS FOR ELECTRONIC DESIGNS
For the electronic-design-automation (EDA) industry, the
need for better testbenches has resulted in considerable
investment in testbench-related research and development.
Such R&D has largely focused on improving the coding
languages that engineers use to write their testbench programs.
Language improvements have made a noticeable difference.
Because design complexity has continued to increase, however,
the verification problem has been simultaneously getting more
difficult. Yet another new language would offer incremental
improvements at best. An entirely new type of testbench based
on rule sets is a more fundamental advance.
By Mark Olen and Matt Ballancee
Burning Issues in TestBench Automation
With intelligent testbench automation, it’s possible to bring verification
costs back in line while improving productivity.
Essentially, a rule set describes how a high-level testing activity
can be performed as a series of lower-level testing activities. A
modest number of rules—taken together—can describe a very
large set of tests. In fact, a well-chosen set of rules can compactly
define how to run every test scenario that engineers might want
to simulate during a digital design project—no matter how
large or complex. A few pages of rules can easily define test sets
containing thousands, millions, or even billions of tests. The
result is a substantial savings in verification engineering cost.
Rule sets also make it possible to employ an entirely new
class of algorithms. Intelligent testbench automation provides
algorithms that generate optimal sets of tests specifically for
engineers verifying electronic designs.
Figure 1: Unlike traditional testbenches, algorithmic testbenches can
be used across different design projects. They also can be retargeted at
different levels of a design’s hierarchy and redirected to generate different
tests based on the verification engineer’s goals for the next simulation run.
REDIRECTED TESTBENChES CuT CODE
With rule-based algorithmic test generation, every simulation run
has a purpose that’s captured in a verification goal. A verification
goal makes references to relevant parts of a set of rules. Those rules
specify a particular verification objective. For example, a verification
goal might be to test all of the firmware instructions that are
intended to execute conditionally. In doing so, one would verify that
the instructions react correctly to each possible condition.
When a simulation starts, intelligent testbench generation
initializes along with the simulator. It begins generating tests
per the verification goal. As simulation proceeds, the algorithms
monitor the progress toward the verification goal, and to avoid
18 • March 008 Chip Design • www.chipdesignmag.com

wasting time on duplicate tests, they intelligently adapt their
test-generation strategies. As a result, engineers don’t need to
write constraints to avoid duplicate tests. The self-adapting
algorithms automatically make continuous progress toward
completion of the verification goal.
The verification goal enables an engineer to focus the testbench
on producing the types of tests that are currently needed. This
capability, which is known as testbench redirection, is important
because a project team’s engineers need different tests at different
times. Sometimes they’re investigating a problem report and
they need a specific test sequence. Other times, they’re trying to
give quick feedback on a design fix and they need to concentrate
testing on a particular functional area. Or they could be running
a regression test and need to thoroughly test a wide variety of
functionality. Each time the project team wants different tests,
it only needs to modify the verification goal to specify the
type of tests that are needed. The rest of the testbench doesn’t
need to be changed. The algorithms take care of all of the testcustomization
details. This aspect saves editing time while
eliminating a significant source of testbench bugs.
SCALABLE TESTBENChES
In addition to testbench redirection, testbench retargeting
is a capability that’s often requested by testbench tool users.
Testbench retargeting is important because complex designs need
to be tested at the module, subsystem, and system levels. Ideally,
a testbench module that’s used to drive a particular interface (like
USB 2.0) during module testing would be retargeted without
changes to drive that interface during subsystem- and systemlevel
testing. In the real world, such retargeting rarely happens.
Usually, subsystem- and system-level testing require completely
new (or at best heavily edited) testbench code.
Retargeting a module-level testbench is problematic for two
reasons. One barrier is the accessibility of the target module.
As it’s incorporated into a subsystem, some or all of the target
module’s pins recede from the periphery and become internal
connections. The original module-level testbench is therefore
rendered unusable. Intelligent testbench automation helps
project teams solve this problem with layered testbenches.
The second barrier to retargeting a module-level testbench is the
target module’s dependency on system-level resources during
system testing. For example, some PCI transactions require a
direct-memory-access (DMA) channel, which is a system-level
resource. A PCI testbench module that’s testing a PCI design
module in isolation can ignore DMA-channel availability issues.
After all, it can run transactions that require a DMA channel
anytime. In contrast, a PCI testbench module that’s testing a PCI
design module in a system doesn’t have that luxury. During system
testing, the PCI testbench module must avoid DMA transactions
when all of the system’s DMA channels are busy handling
transactions that were initiated by other testbench modules.
Attempts to address system-resource problems by parameterizing
testbench modules haven’t provided a general solution. This
approach locks specific resources to particular testbench
modules for the duration of a simulation. Real systems have
more modules that can initiate DMA transactions than there are
DMA channels available. As a result, locking schemes cannot be
used without sacrificing large swathes of functional coverage.
To solve this problem, intelligent testbench automation provides
a dynamic-resource allocation facility. Thus, a PCI testbench
module can request a DMA channel for a single test. If one is
available, the DMA channel is “checked out” to the PCI testbench
module. The DMA transaction then runs and the DMA channel
is “checked in” so another testbench module can use it. If no
DMA channel is available, the PCI testbench can run non-DMA
transactions and make good use of the available simulation time
until such a channel is available. The combination of testbench
layering and dynamic-resource allocation enables project teams
to retarget testbench modules without changing them. In other
words, the same testbench modules work for testing a module
design, subsystem design, and a complete system design.
MAKING TESTBENCh REuSE A REALITY
After a project team has invested in a testbench for a particular
design, management often wants to reuse testbench modules on
other design projects. For example, say a team develops a USB
2.0 testbench module for a cable-modem chip design. Ideally, it
would be reusable on a subsequent Global Positioning Satellite
(GPS) chip design. Unfortunately, attempts to reuse testbench
code often result in substantially more editing and “tailoring”
than expected. One common problem is that the first design
has a different resource configuration (memory, DMA channels,
interrupts, etc.) than the second design. Intelligent testbench
automation solves this problem by editing the system resource
list to match the second design. No changes to the testbench
modules are needed, as the dynamic-resource allocation facility
automatically makes the necessary testing adjustments.
Another common testbench-reuse problem is that different
designs implement different subsets of the underlying specification.
The original design, for example, may implement the full range of
AMBA AHB functionality, including wrap transfers to optimize
performance with the system’s cache. Yet the second design may
implement an AMBA AHB subset without wrap transfers
because there’s no cache in the system. Normally, such a change
would require multiple edits to the AMBA testbench to remove
or disable all wrap-transfer-related code. This task is problematic
Chip Design • www.chipdesignmag.com March 008 • 19
VeRIFICAtIOn
Methods-tools

Methods-tools VeRIFICAtIOn
because the engineers on the second design team aren’t the ones
who wrote the original testbench code. As a result, they cannot
be sure which changes can be made safely.
With intelligent testbench automation, there’s a safe, standard way
to test functionality subsets. Users can simply disable portions of
the rule set to “knock out” unimplemented functionality, such as
wrap transfers in the AMBA AHB example. No knowledge of
testbench coding details is required.
Figure 2: By separating the functional specification from design
implementation, a testbench module becomes highly reusable across multiple
implementations of the same specification.
A third common testbench-reuse problem is that two design
teams may intentionally implement functionality from a common
specification quite differently. This doesn’t mean that one of the
design teams is wrong. On the contrary, it usually means that the
two teams are addressing different end-use markets. Almost all
modern specifications give design teams room to optimize their
implementations for specific applications.
For instance, one design team may be optimizing its
implementation for low cost (i.e., gate count), while another
team may be optimizing its implementation for high speed.
Both implementations are designed to conform to the same
specification. Yet their interactions with the testbench at the
detailed electrical level can be quite different. One AMBA
AHB slave implementation may have a very small input buffer
and frequently force “split” transactions. Another AMBA AHB
slave implementation may have a very large input buffer and
never force such transactions.
Engineers want to be able to verify both implementations with
a single testbench. To maximize the potential for reuse, such
a testbench would ideally be able to adapt itself to work with
any legal implementation of the specification. At the same
time, it should be able to reject any illegal implementation.
It’s very difficult for humans to write such a highly flexible
testbench by hand while getting all of the details right for
each of the many different possibilities.
Intelligent testbench automation solves this problem in two steps.
First, it captures all of the different behavioral possibilities allowed
by a specification using a non-deterministic rule-set description.
Second, a patented “morphing” technology automatically adapts
test generation to simultaneously conform to both the rule set
and the dynamic responses of the design during simulation.
Dynamic-resource allocation, functionality-subset specification,
and morphing make it practical to reuse the resulting testbench
modules on a wide variety of real-world designs. In addition,
project teams aren’t required to incur the expense and risk of
modifying unfamiliar testbench code.
The advantages of intelligent testbench automation are quite
dramatic. The time needed for testbench programming is reduced
while the overall coverage area is increased. It is reusable across
multiple designs without requiring significant changes to the
rule sets. Furthermore, algorithmic testbenches can be reused
across module, sub-module, and full-system design levels. With
testbench redirection capabilities, design teams can easily redirect
test generation at various times during verification.
Ultimately, intelligent testbench automation finds more bugs
more quickly while requiring less engineering time. It cuts down
on the respins caused by the functional design errors that escape
traditional functional verification. This technology is exactly
what companies need if they’re to bring their verification costs in
line with their design costs—especially as they face ever-growing
and increasingly complex design challenges. ◆
Mark Olen is a product manager at Mentor Graphics
for Advanced Functional Verification Technologies.
He has worked for Mentor for 10 years and has more
than 25 years of experience in the semiconductor
design verification and test industries. He can be
reached at mark_olen@mentor.com.
Matthew Ballance is an engineer at Mentor
Graphics for the inFact product. He holds a
BSCpE from Oregon State University and has
worked in the areas of HW/SW co-verification
and transaction-level modeling. Ballance can be
reached at matt_ballance@mentor.com.
0 • March 008 Chip Design • www.chipdesignmag.com

When planning a complex product-development project
using an application-specific integrated circuit (ASIC)
or system-on-a-chip (SoC), it’s critical to analyze the various
risks, project costs, resources, and expertise required to allocate
resources (money, equipment, and people). Often, such analysis
fails to include many of the key hidden costs and risks associated
with the implementation of a complex double-data-rate (DDR)
memory-controller solution. If those risks and costs are more
clearly anticipated, the choice between building a DDR memory
controller internally and buying third-party intellectual property
(IP) will be much easier. In a complex DDR memory-controller
SoC/ASIC design, for example, buying a third-party IP core
can lower cost, improve profitability, and reduce risk.
Designing an efficient DDR memory controller is now a
very complex and time-consuming task—whether in lowpower
consumer electronics, where mobile DDR memories
require power-efficient high-bandwidth access, or in the highperformance,
low-latency data-communication applications that
require cutting-edge DDR3 memories. It may seem daunting to
decide whether to design a portion of an ASIC or SoC product
or to purchase third-party IP. When looking at buying from
a third party, one must consider the direct cost of purchasing
an IP core along with the costs and resources required for
integration and support. Determining the cost to develop the
IP core internally is much more complex. The direct costs for
planning, designing, verification, debugging, integration, and
tools must all be understood and estimated.
DDR memory controllers are key components to nearly
every SoC/ASIC design with access to external memory.
It doesn’t matter if the design objective is to reduce cost,
improve performance, provide advanced features, lower power,
reduce board space, or any combination of these goals. The
implementation of the DDR memory controller will be critical
to accomplishing the desired outcome.
Developing an optimal DDR memory controller is a
complicated design and verification task. Many standards need
to be considered. For example, DDR, DDR2, DDR3, GDDR3,
GDDR4, and LP-DDR are key standards. Each one contains
a variety of capabilities. Among the many memory-controller
features that need to be considered are the following: access
By Raj Mahajan and Raghavan Menon
Make an Informed Build or Buy Decision
for Memory-Controller Solutions
When it’s time to make a memory mind, don’t forget to measure all of the risks and rewards.
priority, error checking and correcting (ECC), read-modifywrite
support, byte-write implementations, out-of-order access
support, FIFO options, latency, and bandwidth tradeoffs.
DEvELOPMENT SuPPORT
In addition to designing the DDR memory controller, it’s critical
to make modifications to the design (optimization and tuning)
during the design-integration phase. A DDR memory-controller
expert would need to be available for support during system
integration, verification, and built-in testing and error checking.
He or she also should support the testing and verification of the
physical-layer (PHY) portion of the design.
It can be difficult to model the complete behavior of the system
unless a platform for system integration has already been created
and can easily support this task. Ideally, such modeling would
allow modifications and what-if scenarios to be created during
system integration. In doing so, it would require design changes
and a variety of experiments. Tradeoffs for latency, performance,
and special features that impact the system bandwidth and
cost must be explored to identify the mix that fits the design
requirements. The verification of the DDR memory controller
itself can be very complex. Deep knowledge of the corner cases
for each standard and feature must be used if the verification
process is to obtain the coverage required to create a robust
solution.
All of the above points cover the controller portion of the design.
Yet the PHY interface also needs to be considered. If an analog
approach to the design is taken, a completely separate skill set is
required—along with specialized tools and a test methodology.
One additional task that’s usually overlooked is the need for
built-in testing and error-tracking features. Often, a DDR
memory-controller design is already completed and testing is
well underway before it’s discovered that it’s not possible to test
the system memory within the time allowed or to the quality
level required by the test plan. The result could be a schedule slip
very late in the development cycle.
Although all of the risks discussed so far can impact schedules
and development costs, the overall impact on profitability can be
dramatic. An example is provided to show how profitability could
be impacted by a schedule slip in a project if an internal DDR
Chip Design • www.chipdesignmag.com April 008 • 1
DIGItAl
Memory Controllers

Memory Controllers DIGItAl
memory-controller effort—the “build” option—runs into some
design, verification, support, and integration schedule issues.
Assume that these issues result in a three-month schedule slip
for Company Y. Also, assume that Company X is introducing
a similar product. Because it has selected the “buy” option,
however, Company X introduces its product on time—three
months ahead of Company Y. The profit and gross margin for
both Company X and Company Y are illustrated in Figure 1.
Figure 1: This profit comparison shows Company Y with a three-month
schedule slip.
Because Company X introduces its product three months earlier,
its profit starts sooner and grows to a higher level than the profit
of Company Y. Note that the gross margin is higher during the
early portion of the sales cycle, thereby providing a profit boost
to Company X over Company Y. Late in the sales cycle, however,
Company Y shows slightly higher profit than Company X. This
is deceiving, as Company X is introducing a new, follow-on
product with higher margin. That higher margin is accounting
for a significant amount of additional company profit that isn’t
shown on the single product-comparison chart. If Company X
leverages its three-month advantage to create a new product
earlier than Company Y, it will again obtain higher profit. Yet if
Company Y is late again, this delay can compound the schedule
slip. Company Y could end up being six months behind.
Development costs are higher when a schedule slips, which
leads to increased project costs while further reducing overall
profitability. If a schedule slips three months, engineering costs
will be that much higher. If the project is a year long, three
months will be about 25% of the overall cost. The manufacturing
costs must be paid again if the SoC or ASIC requires a re-spin.
This could be a multi-million-dollar expense. Typically, it will
account for a large percentage of the project cost. Other costs,
such as materials for scrapped wafers, testing expenses, EDA
license costs, computer time, or equipment rental, all add up. A
three-month schedule slip with a re-spin could easily cost $5 to
$10 million. Amortizing this amount over the project sales cycle
and subtracted from profitability for Company Y indicates the
result (see Figure 2).
Figure 2: Here, the profit comparison depicts Company Y with both a
schedule slip and increased costs.
BuILD vS. BuY AND PROJECT RISK
The potential sources of slips—design risks that can turn into
schedule delays and requirements to re-spin an SoC/ASIC
design—are numerous. For a DDR memory-controller design,
however, there are three main areas of risk. Functionality
requirements can grow during development. Timing closure can
be delayed. In addition, verification can take more time.
When “building” a DDR memory controller, the first area of
schedule risk comes from the fact that functionality requirements
can grow over the course of the project. Memory bandwidth is
a key element of a typical system’s performance, functionality,
power, and cost metrics. As a result, it’s not unusual for the DDR
memory controller to be targeted as the area for improvement.
When using the “buy” option on IP with a robust set of features
and expert support from a vendor with an experience-based
schedule, the above functionality risks can be dramatically
reduced.
When the feature set is finalized and verified, timing closure—
the second key source of risk—can be difficult to estimate while
pursuing the “build” option. The DDR memory controller alone
has a variety of critical design areas, which are primarily due to
the importance of the PHY interface timing between the DDR
memory controller and the external memory. When using the
“buy” option from an IP vendor with a robust and proven design
that meets critical timing constraints with sufficient margin, the
risk of a prolonged timing closure effort is eliminated.
Verification is the third significant area of risk in a “build” option.
A DDR memory controller must operate under a variety of
different conditions. The “buy” option significantly reduces
verification risks. If the DDR memory-controller IP is part
of a complete solution, it will have been exhaustively verified
using a wide variety of corner cases, conditions, and target
applications. These areas comprise a few of the key risks
that a development team needs to consider when comparing
a third-party IP “buy” option versus an in-house “build”
approach to implementing a DDR memory controller.
• April 008 Chip Design • www.chipdesignmag.com

SuPPORT COSTS
When pursuing the “build” option, the work on the DDR
memory controller is far from finished even after the design
is completed and a new product is started. The DDR
memory controller will need to be supported during the
following: code development; feature, customer-specific,
and test-coverage enhancements; and all other engineering
support required for a complex system.
If a product is successful, a follow-on product also will be
required. Say that follow-on product is in a new process.
The DDR memory controller will then need to be ported
to the new process and another set of complexities will
appear. New library elements will need to be tested and
optimizations for power, performance, and die size may
need to be repeated. New memory technology (for example,
the migration from DDR2 to DDR3) must be taken into
account along with potential new vendors, memory features,
and characteristics. The “buy” option can reduce or eliminate
all of these concerns.
Keep in mind that IP vendors can afford to invest in a
very robust infrastructure for the design, development,
testing, and support of standardized and highly specialized
products. Because IP vendors amortize a product over many
projects, they can make a significantly higher investment
than a company with only one or two projects.
When engineering resources are being used to design a
DDR memory controller, they’re not being utilized to
differentiate a system’s core technology. The “opportunity
cost” of this use of resources is sometimes overlooked.
But it can allow a competitor to do a better job of adding
compelling features, pushing performance, or lowering
cost. In doing so, it makes it difficult to compete in the
marketplace. If the DDR memory controller was made
using third-party IP—the “buy” option instead of an inhouse
“build” option—internal engineering resources could
be applied to counter likely moves by the competition and
enhance a product line’s core technology.
Significant costs are associated with designing a DDR
memory controller in house instead of sourcing it from
a third party. For products with less sales and profit
potential, even small impacts to overall profitability can
make the difference between a company staying in business
or closing its doors. As shown in Figure 2, Company Y has a
dramatically lower profit curve because it is burdened with
a three-month schedule slip, additional engineering costs
for spinning the SoC/ASIC, and additional engineering
costs for designing, verifying, supporting, and testing the
DDR memory controller. The company also suffered the
opportunity cost of missing features and capabilities in the
current project.
In summary, building a DDR memory controller internally
can put development schedules and cost estimates at risk
due to three development complexities. First, functionality
requirements can grow during development. In addition,
timing closure can be delayed and verification can require
additional time. When building a DDR memory controller,
the opportunity cost of not applying engineering talent to
core capabilities also needs to be factored into the financial
analysis of a “build” versus “buy” decision. A third-party
DDR memory controller improves profitability by avoiding
the key development and support risks. It also eliminates
the opportunity costs of engineering deployment. ◆
Raj Mahajan has more than 10 years of experience
architecting, designing, and verifying memory-access
solutions for advanced ASICs for a variety of target
markets. At startup Ingot Systems, he guided the
architecture, design, and verification of MemCore’s
flagship memory controller, which led to the sale of
the company to Virage Logic in 2007. Mahajan
continues to lead the development of this IP, branded as “IntelliDDR,”
at Virage Logic.
Raghavan Menon has more than 14 years of
experience leading development teams and a
proven track record in delivering complex multichip
solutions with first-silicon success. He is currently
a senior director at Virage Logic. Previously, he
held the position of vice president of engineering
and CTO at Covalent Semiconductor Inc. Menon
holds an MSEE with honors from the University of Kansas
Pallab's Place blog: RSA Conference 2008
The keynotes RSA Conference held in San Francisco followed
the theme that data Security is no longer an option,
it is required. This was reiterated several times by RSA
president Art Coviello who also noted the dialog box pop-up
of “Are you sure?” before you submit information is the tech
worlds equivalent of the old movie line “Do you feel lucky?”.
A later keynote by Dept of Homeland Security Secretary
Michael Chertoff identified today’s threat of cyberspace is
on a par with 9/11. Replays of the conference keynotes are
available after registration at the following site...Read more
at: www.chipdesignmag.com/blogs ◆
Chip Design • www.chipdesignmag.com April 008 • 3
DIGItAl
Memory Controllers

Methods-tools 65nM DesIGn
Designing in 65-nm and smaller geometries can be
intimidating. But engineers can ensure first-time silicon
success by paying attention to certain aspects of their design
methodologies. Many of those methodologies have already
been used for 130- and 90-nm designs. They simply need
more attention at 65 nm and beyond (see Figure 1). Power
management, for example, is a key aspect of design—especially
if the application is battery powered. There are two kinds of
power: active and leakage. A variety of techniques exist to
A 65nm flow must take into consideration low power,
timing and DFM issues.
manage both types.
For active power, it’s essential to incorporate power-management
techniques at the architectural level. Yet additional techniques are
available during the physical implementation of the design. Because
a significant portion of the power dissipated is due to net capacitance,
signals with high activity are used to minimize interconnect
capacitance. In addition, logic is restructured to minimize the fanout
of high-activity signals.
During timing optimization, cell sizing and buffer insertion
are performed with power taken into consideration. Because
a significant portion of active power is in the clock network,
several methods are used to reduce clock-tree power. Clock
gating optimizes clock power while integrated clock-gate cells
eliminate the need for close placement of the flip flop and gating
logic. In addition, clock gating is integrated with clock-tree
synthesis to optimize power with timing, skew, and insertion
delay constraints. Other tools create custom flip flops to reduce
power even further. Another useful method is using multiple
voltage islands, as power is proportional to the square of the
voltage. Yet that approach requires multiple power supplies and
more than two generally isn’t practical.
By Prasad subramaniam
Get Designs Right at 65-nm and Beyond
up-front planning and more attention to detail can help make the
transition to new process nodes less daunting.
eSilicon • Enabling Your Silicon Success CONFIDENTIAL
Figure 1: A 65-nm flow must take into
consideration low power, timing, and
DFM issues.
Leakage power is a concern as geometries shrink and the gate
oxide thickness of the transistor and operating voltage gets
smaller. At 65 nm and below, it is a significant component of
the total power—especially at higher operating temperatures.
The most effective way to reduce leakage power is to use power
islands and shut-off sections of the design when they’re not
active. This approach reduces total power consumption including
leakage power. Two considerations need to be taken into account
with power islands. First, critical data should be saved in dataretention
flip flops before shutting down. When the main power
island is shut down, its output signals also should go into a
high-impedance state and leave the inputs of the active island
in floating state. Depending on the voltage level at these floating
inputs, short-circuit currents could occur in the active island’s
input stages. They would consume significant power. As a result,
inputs are always gated with sleep-mode signals to ensure that
the signals are always in a known state. The wake-up time is
typically in the range of a few milliseconds.
Another way to reduce leakage power is to use footer switches with
1
the logic. In this design, the logic cells are connected to ground by
a low-leakage footer switch. That switch is implemented using a
high-threshold transistor. In the normal mode of operation, this
transistor is on and the logic cells have a common virtual ground. In
sleep mode, the footer switch is off—causing the logic to go inactive.
Because the footer uses high-threshold transistors, it minimizes
leakage in the logic circuitry.
Although this approach reduces leakage, it negatively affects area
and performance. To be effective, the footer switch is distributed
across the layout. Each switch controls a group of logic cells.
Additional resources are required for routing the sleep signal and
virtual ground across all switches. The switch presence causes
some degradation to the logic speed as well. As it is in the powerisland
scenario, retention flip flops are required. But the switches
are typically fast with wake-up times in the range of µs.
A third method of reducing leakage is by applying a back-gate bias
to the substrate. The MOSFET has four terminals. Yet it’s typically
treated as a three-terminal device by tying the source and substrate
terminals together. By applying a separate voltage to the substrate
terminal, the threshold voltage can be increased—thereby reducing
leakage. This approach has area and performance penalties, however.
An internal charge pump is required to generate the substrate voltage.
4 • March 008 Chip Design • www.chipdesignmag.com

Additional routing resources also are needed to distribute this voltage
across the logic cells. Unfortunately, the logic slows down as well.
The final method for reducing leakage is the use of multi-threshold logic
process
cells. This approach invites very little penalty in area or performance.
During the physical design process, multiple threshold-voltage libraries
are used for logic synthesis and optimization. Standard or lowthreshold
devices are selected for critical portions of the design, while
high-threshold cells are used in non-critical sections. Typically only 20%
of the design uses the standard or low-threshold devices. The remaining
cells are therefore high threshold, enabling lower leakage.
TIMING SIGNOFF
Typically, timing signoff is achieved by performing analyses at the
fast and slow corners of a design. In 65-nm and lower geometries, the
worst-case corner isn’t clearly defined. It also is design dependent—
especially with a large operating-voltage range due to multiple voltage
islands. The corner for the worst-case timing path becomes circuit
dependent. In addition, the circuit timing behavior is no longer
monotonic. As a result, there may be multiple conditions when the
worst-case timing occurs. Such conditions arise due to temperature
inversion, in which a transistor becomes slower at a lower temperature
and affects the delay of a path depending on its location. Clearly,
timing analysis needs to be performed at more corners.
Signal integrity, crosstalk, and on-chip variations also become
significant at smaller geometries. Variations arise from process,
geometry, and power-supply changes due to IR-drop and temperature
fluctuations. The relative magnitude of these variations can be as
much as 20%. Although static timing analysis uses additional margins
for on-chip variations, it could be overly pessimistic. In other words,
achieving signoff may require additional area overhead or may simply
not be possible. Statistical-timing-analysis techniques are emerging
that promise to address both of these issues. These techniques treat
each timing path as a statistical variable and determine the probability
of it meeting the timing requirements.
DESIGN FOR MANuFACTuRABILITY
Normally, design-for-methodology (DFM) rules are incorporated
in a technology’s design rules. While it’s necessary for a design to
pass the technology’s design rules, that requirement isn’t sufficient
to achieve good yield. Although a design may pass a rule, how close
it adheres to that rule and the statistical distribution of its deviation
from the rule have an impact on yield. Many foundries don’t
mandate DFM analysis for 90-nm and larger geometries. Yet it is
critical for 65-nm and smaller geometries (see Figure 2). Performing
DFM analysis for these designs can identify simple changes that will
improve overall yield. DFM rules are useful in the early stages of a
technology. As the technology matures, the manufacturing process
is under tighter control and becomes more robust.
Two types of DFM rules exist. The first set affects critical parameters
of the circuit and its operation. It is used by extraction tools to more
accurately model the physical layout. This set also is applied to cell
libraries, analog circuits, and custom layout designs. The second set of
rules isn’t critical. But it should improve yield.
DFM aware design flows are a necessity at 65nm to
address emerging physical effects earlier in the design
Placed & Router Design
- Native redundant VIA
- Native wire spreading
CAA driven wire spreading
CAA driven wire widening
Redundant VIA insertion
Recommended end-of-line
LPC hot spot removal
CMP driven metal fill
Tape Out
Figure 2: DFM-aware design flows are a necessity
eSilicon • Enabling Your Silicon Success 2
CONFIDENTIAL
at 65 nm to address emerging physical effects
earlier in the design process.
Many foundries perform DFM analysis for a design and make
suggestions to improve yield. Some of those suggestions can be
implemented by modifying the layout without increasing the design
area. Such capabilities also have been introduced in the layout tools
based on a target foundry. These can be applied throughout the
design flow—from cell level to completed chip. Wire spreading and
wire widening, for example, can be performed to reduce critical areas
during multiple stages of the flow. Examples of such stages include
global and detailed routing. Lithography process check (LPC) is an
analysis that’s superior to rule-based systems, which don’t address
design complexity and variability well. By using a model-based
approach that utilizes lithography simulation, these tools provide
better accuracy. Lithography-aware routing and extraction provide a
more robust design and sign-off.
In summary, designing in 65 nm and beyond isn’t as hard as one
would imagine. There are more steps with more pitfalls. As long
as the designer is aware of them and proactively addresses them
in the methodology, however, he or she has a good chance of
first-time silicon success. ◆
Dr. Prasad Subramaniam is responsible for
developing the technology platforms for IC design
at eSilicon. From 1982 to 1998, he was with Bell
Laboratories, where he held a variety of technical and
management positions culminating as the head of
analog and RF CAD. Subramaniam joined Cadence
Design Systems as VP of R&D in 1998. He is a senior member of the
IEEE and has published over 40 papers in technical conferences and
journals. Subramaniam holds a PhD in electrical engineering from the
State University of New York at Stony Brook.
Chip Design • www.chipdesignmag.com March 008 • 5
65nM DesIGn
Methods-tools

Flexible Radio MIxeD sIGnAl
Cellular Standards May Demand Alternatives to SDR
Is there a better way to meet growing consumer demands
than relying on software-defined radios?
Cellular standards continue to evolve—a trend that was first seen
in the second-generation (2G) space with GSM developing
into GPRS and then EDGE. Now, a similar progression is occurring
for the third generation (3G) as Wideband Code Division Multiple
Access (WCDMA) advances toward High Speed Packet Access
(HSPA). Multi-mode WCDMA became a mainstream standard
in 2007, while HSPA provides carriers with a relatively pain-free
upgrade path to a more efficient network capable of supporting
high- and low-data-rate traffic. In addition, WCDMA provides
support for high-speed data by bundling multiple data channels
and using spread-spectrum hybrid-phase-shift-keying (HPSK)
modulation. The spread-spectrum modulation and orthogonal
coding allow multiple users to share the same radio channel.
Moreover, the wideband signal helps mitigate frequency-selective
fading. As a result, WCDMA ushers in the packet data services
needed for Web surfing and file transfer. It also provides multimedia
broadcast multicast services (MBMSs), such as mobile TV.
Figure 1: This graphic depicts the evolution of cellular standards.
The development of all of the cellular standards is shown in Figure 1.
This graphic illustrates the two main branches of standards: the CDMA-
and GSM-based branches. It also shows how they compare in terms of
data rates. HSPA was developed on the existing WCDMA framework.
Compared to WCDMA, it provides the user with higher data rates,
reduced latency, and improved network efficiency. HSPA is divided
into two sections: High-Speed Downlink Packet Access (HSDPA)
and High-Speed Uplink Packet Access (HSUPA). HSDPA, which is
part of 3GPP Release 5, improves the downlink performance. As part
of 3GPP Release 6, HSUPA enhances the uplink performance.
HSDPA is now widely deployed across the world. It provides
theoretical data rates for downloads (web browsing) of 14.4 Mbps,
which is achieved through the use of a 16 quadrature-amplitude-
By Duncan Pilgrim
modulation (QAM) scheme. QAM allows four bits of data to be
transmitted per symbol compared to two bits for quadrature phase
shift keying (QPSK)—the modulation scheme used for WCDMA.
HSDPA is complemented by HSUPA, which is being quickly
deployed and provides theoretical upload speeds of 5.7 Mbps. In
addition to improved data rates, HSPA makes use of a number of
other features that enhance network efficiency. The resulting benefits
include faster responses to changing radio conditions, improved
resource scheduling, and higher efficiency in error processing.
For its part, HSPA provides consumers with their first real taste
of DSL-like data rates for mobile devices. With these data rates,
consumers will—for the first time—see comparable performance
between the speeds of their home and mobile data connections.
Beyond HSPA, the evolution continues with HSPA+ followed
by Long Term Evolution (LTE). Both of these technologies offer
further improvements with lower latencies, higher data rates, and
improved network coverage. In parallel to this is the Chinese TD-
SCDMA standard, which exhibits very similar characteristics to
those of WCDMA. This plethora of air standards—together with
the increasing global penetration of cellular networks—requires
versatile solutions that can cover multiple modes and multiple bands.
At the same time, such solutions must meet the strict performance,
cost, and size constraints imposed by the handset providers and—
ultimately—the consumer.
In summary, GSM/EDGE/HSPA/LTE provide an integrated path
for the evolution of wireless communications that efficiently supports
increasing data rates. Moreover, the connection between these networks
and the requirement for backward compatibility make multi-mode
devices essential. With this multi-mode requirement and the desire to
use a single platform that can cover all geographic regions, traditional
architectures have been stretched to the breaking point. To support the
various performance requirements, current solutions either use suboptimal
implementations, which trade off performance, or multiple
architectures within the same device that increase cost. These tradeoffs
have led to renewed interest in the concept of a software-defined radio
(SDR) and its viability for cellular applications.
According to the SDR Forum (www.sdrforum.org), SDR is the
panacea of RF design: “SDR technologies provide software control
of a variety of modulation, interference management and capacity
enhancement techniques over a broad frequency spectrum (wide
and narrow band).” This technology allows a single radio to support
6 • April 008 Chip Design • www.chipdesignmag.com

anything from cellular to military applications. SDR also is an
overused word, as there are now many “SDR solutions” entering
the market. Yet 99% of these products are in fact software-defined
basebands, which don’t provide the RF radio portion. As a result,
they’re only part of the overall solution.
Traditionally, SDR has been plagued by many issues, such as being
cost prohibitive and having lackluster performance. Such aspects
explain why it has never been implemented in a handset. There
are many ways to create an SDR product and there is no single
correct SDR architecture. At one end of the spectrum, companies
are working on developing pure digital SDR solutions that require
high-performance digital-signal-processing (DSP) techniques.
These solutions suffer from high current consumption, linearity
constraints, and noise/spurious-emission issues. At the other end
are the solutions that rely predominately on analog circuitry, which
is reconfigured by using a simple DSP or state machine. To meet
the diverse needs of an SDR, these solutions have a tremendous
amount of circuit overhead. This overhead leads to uncompetitive
solutions with respect to size, cost, and current consumption.
In all cases, developing a radio that has the capability of reconfiguring
itself to meet the broad range of modes and frequencies required for
an SDR has a negative impact on performance, size, cost, or any
combination of the three. The viability of a true SDR solution is
therefore difficult to determine. After all, consumers have become
accustomed to end products that meet their expectations.
A FLExIBLE APPROACh
Cellular standards are well-defined and the rollout of nextgeneration
technologies is relatively well mapped out. By focusing
only on the cellular standards and frequencies, a solution’s required
flexibility can be constrained. Traditionally independent paths have
been used to transmit GSM/EDGE and WCDMA, which leads to
very little design reuse between the two paths. To address this issue,
RF semiconductor company Sequoia Communications created
FullSpectraTM, a multimode architecture designed to support
cellular standards. The vision was to provide a single RF path that
could support both narrowband and wideband modulation schemes
while being linear enough to meet the next generation requirements.
The only transmit architecture that met these requirements was
polar modulation (see Figure 2).
Polar modulators have already been verified to provide very lownoise
and high-efficiency solutions for narrowband modulation
standards, such as GSM and EDGE. The difficulty, however,
was extending it to support the dynamic range and widebandmodulation
requirements of next-generation standards while
maintaining the performance achieved in narrowband solutions.
The first commercial instantiation of the FullSpectra architecture
is the company’s SEQ7400 multimode RF transceiver. In this case,
the common transmit polar modulator has been proven to meet the
performance requirements of GSM, GPRS, EDGE, WCDMA,
HSDPA, HSUPA, and TD-SCDMA, which means that a single
cost-effective product can potentially be configured to support any
or all of these cellular standards.
Figure 2: The development of a single multi-mode RF path is shown here.
Due to the inherently low-noise nature of polar modulation and
the development of innovative digital-processing techniques, these
implementations promise to efficiently remove transmit surfaceacoustic-wave
(SAW) filters. When combined with the single
path architecture, such a solution also paves the way for the use of
multimode power amplifiers. Such solutions have great potential for
the constantly evolving cellular industry, which must provide higher
data rates and increased geographic coverage while maintaining
backward compatibility with old technology. These developments
increasingly translate into increased data rates, lower latencies, and
improved coverage for the consumer.
To support the growing number of modes, the ideal solution
should boast sufficient flexibility while satisfying the performance
and cost targets that are now expected by the consumer. Originally,
this dilemma appeared to provide an opportunity for the growth
of software-defined radios. But if SDR solutions cannot overcome
the known tradeoffs in performance and cost, other approaches will
emerge, such as the polar modulation architecture discussed above,
which has been shown to satisfy these requirements. ◆
Duncan Pilgrim brings over 14 years of RF engineering
and marketing experience to Sequoia Communications,
where he serves as director of product marketing. He
completed his Executive Fast Track MBA in 2005 from
Wake Forest University, and received a bachelor’s degree
in electronic engineering from the University of Birmingham in the U.K.
Chip Design • www.chipdesignmag.com April 008 • 7
MIxeD sIGnAl
Flexible Radio

DOt.ORG
The Second Commandment for Effective Standards
Standards committees are all about creating technically sound
standards, right? Wrong! There are more aspects to standards
committees than just producing the standard itself. Over the years, I’ve
learned a lot about these other, non-technical aspects. I’m currently
rolling out my “Ten Commandments for Effective Standards” in my
blog, The Standards Game, at www.synopsysoc.org/thestandardsgame.
The “Second Commandment for Effective Standards” deals
with a topic that generates more debate in the standards arena
than just about anything else.
Before I say more, however, I must give a disclaimer: I’m not a lawyer
and I’m not giving anyone legal advice. That being said, here is
Commandment #2: Do Not Mix Patents and Standards.
Participating in standards committees can have implications
for a company’s patent portfolio. It’s possible that company
employees who work on standards can inadvertently create
intellectual-property (IP) ramifications for their employers. In
simple terms, it’s cheating to help develop a standard, not reveal
associated patents, and then assert patent rights against others
who use the standard. Famous lawsuits continue to show that
companies cannot introduce patents into the standards arena
and automatically expect to retain rights to assert those patents.
Whether the lawsuits are won or lost, there’s a significant cost to
the companies involved as well as the industry at large.
The phrase that’s often used for patents that have standards
implications is “essential patent.” To make use of the standard,
the patent would necessarily be infringed upon. If a company
owns an essential patent and an employee of that company
participates in a related standards committee, there’s a risk that
the company could lose the IP rights provided by the patent.
Yet patents that are related to a company’s product, which
complies with a standard, can be a different situation. Product
implementations that use the standard belong to the developer.
If those implementations are copied, the developer can be
entitled to assert IP rights.
Some individuals, companies, and organizations have tried
to address patents mixed with standards. They sought to
preserve their essential patent’s IP rights while contributing
to a standard. Complicated proposals to both license and
require cross-licensing have been made. So far, however, these
proposals have only caused confusion while derailing progress.
There have even been attempts to pressure or trick companies
into relinquishing their patent rights.
On the positive side, there have been companies that elected to
withdraw from standards committees to preserve their patent
rights. In other instances, companies have made conscious decisions
to forgo their IP rights in support of an important standard.
The ideal situation would be for all standards (including formats,
languages, databases, and APIs) to be free of IP and patent
issues. There should be no essential patents from the beginning.
Alternatively, essential-patent owners should be willing to offer
their patents up if they want to participate in standards creation. If
they wish to protect their IP rights, the companies holding essential
patents should be forthcoming about them. Or they shouldn’t
participate in developing standards associated with the patents.
What should a person do if he/she wants to participate on
a standards committee and represent a company that has a
patent portfolio? It’s a very good idea to ask for advice from
company legal counsel before starting work in a standards
body. Standards organizations usually have policies to address
patents. Some won’t accept donations of patented technology.
In addition, most—if not all—standards organizations don’t
require participants to conduct patent searches. Legal counsel
can interpret these policies and help determine how to proceed.
A company could choose to not participate at all. Or it might
decide to contribute its essential patents to the standards effort
for the good of its customers and the industry. ◆
Karen Bartleson contributes to several electronicdesign
standards organizations, drawing on 27 years
of experience in the semiconductor industry. She also
is senior director of interoperability at Synopsys.
By Karen Bartleson
8 • April 008 Chip Design • www.chipdesignmag.com

The SPIRIT
Consortium Guide

The SPIRIT Consortium Guide
30
Sometimes change creeps up on us
in a subtle and imperceptible way
and, at some point in time, the effects
seem to catch everybody by surprise
and require wholesale reassessement
of the ways of working. This type of
significant change has crept up on the
silicon design community in the last 5
years or so. It was such a non-event that there were no big
announcements and no earth-shattering technical papers,
but the change is starting to have massive repercussions in
the electronics industry.
So, what happened? Well - silicon capacity increased a bit!
“Duh - so what?”, I hear you say. “Moore’s Law has been
with us for decades, and if increased silicon capacity caught
anybody by surprise then they might possibly qualify as the
most insular and out-of-touch engineer on the planet”.
The recent increases in silicon capacity seem to have propelled
us past one of those subtle threshold points. For a compelling
number of designs, designers are no longer constrained by
silicon capacity. If you can can conceive a design, there is a
pretty good chance that you can fit it onto the available silicon.
And this simple step-change is starting to have massive
repercussions on the way that people create designs.
First of all, designers used to spend a lot of time optimising
designs to minimise gate-count and silicon area. There are still
good reasons to optimise designs, but silicon area concerns are
no longer anywhere near the top of that list.
Removing constraints imposed by silicon capacity has
enabled designers to use much bigger building blocks
for their designs. It used to be transistors, then gates,
then MSI. Today, the building blocks are often major
functional subsystems in their own right. USB, ethernet,
IP-Reuse :
It’s Time To Get Serious!
By John Wilson, Mentor Graphics
PCI Express, processors, SATA. Nobody cares if a USB
module uses up 30K or 40K gates - just as long as it works
properly in the design.
And that’s they key challenge facing designers today; how
can they use pre-existing IP in new designs and get the
designer productivity boost to enable them to make most
use of the available silicon capacity?
In the past, integrating building block modules together was
done primarily at the electronic level. But no longer.
Integrating an ethernet controller, USB interface and
processor together requires electronic compatability (of
course!), and also requires compatability at the software
level (are there compatible drivers for the USB and Ethernet
blocks for the RTOS that I want to run on the processor?).
Why waste valuable design time to develop new software
stacks for a module, when I can just choose an alternative
that is good enough, and has the right software already
available. In fact, software compatability is such a big issue
that the primary factor in choosing the IP may not be the
HDL in which it is written, or the simulator on which it
was verified, but compatability with an existing OS for
which existing software applications may already exist.
Verifying those IP modules is relatively easy when looked
at as standalone modules, but is fantastically more difficult
when the IP modules are integrated into a system. If two
different verification strategies were used by the different IP
suppliers, it is asking a lot of the system integrator to learn
enough about the IP to recreate the verification environment
in a way that is compatible with the current design. The effort
required is often comparable with developing that module
from scratch. In fact, it can be worse than that. Because
IP providers want the biggest possible potential market for
their IP, it is often highly configurable. And that causes a
exponential increase in verification complexity.
The SPIRIT Consortium Guide www.chipdesignmag.com/spirit

The problem caused by stepping over that silicon capacity
threshold – in truly building systems-on-chip –is that the
information used to make good choices about integrating
IP into designs does not exist in one place (in a single
information ‘domain’). Designers are challenged to
evaluate information across multiple information domains
simultaneously to enable the efficient selection of IP for
use in a new design. IP reuse has been a technology that
is full of promise but difficult to deploy.
That’s the challenge to which IP-XACT, the XML Schema
format from The SPIRIT Consortium, provides solutions.
And, in providing these solutions, IP-XACT seems to be
opening up new insights into design creation and processing
which have just not been practicable before.
Here’s the basic premise of IP-XACT : there is a lot of
information associated with any IP module, spread across
a wide range of information domains. It is impossible
to predict which information will be important to any
individual designer. This IP will be used in many different
designs, in different design flows and using different
design and verification processes.
So IP-XACT says, “let’s just write down everything we
know about the IP module, enabling the designer to use
that information quickly and effectively. We really don’t
know or care how that IP came into existence - here is
everything we know about this IP.”
This is not rocket science. Designers have recognised the
value of this sort of capability for many years - its called
a databook. I still have my orange TI TTL databooks
from twenty years ago on my shelf, but they are formatted
completely differently from the PDF files that I used to
learn about ARM processors today, so there is no easy
and consistent way to locate the equivalent information
in these different databooks.
IP-XACT uses XML. This enables us to label all the
different data in a consistent and machine-readable way,
so it’s a lot easier to understand IP from many different
sources. Using machine-readable XML data means that
many of the design processes can be highly automated
(that is the purpose of modular program modules called
The SPIRIT Consortium Guide
generators). This enables Design Environments (the tools
that understand IP-XACT databooks and generators) to
offer rapid design creation and verification possibilities using
a range of IP in many different formats, in a way that can by
easily customised for individual design requirements.
So for most designers, it’s simply a case of dragging and
dropping the IP modules into a design, configuring them,
and then invoking the generators to turn that XML data into
real life designs. If this sounds too fantastic to be true, then
please tell that to my mum (a retired nurse, with just enough
technical knowledge to turn on computers and mobile phones)
who used IP-XACT to create and verify an ARM 9-based
USB subsystem, and ran enough software on the system to be
sure that the system was functioning correctly. She did this
in about 15 minutes (10 of which were me explaining all the
wiggly waveforms displayed in the HDL simulator).
"If she had chosen a PowerPc Processor, she would
have ended uP usIng a dIfferent usB (one recognIzed
as comPatIBle wIth PowerPc, not amBa ahB), and
dIfferent comPIlers and dIfferent sImulators..."
I’m deadly serious here!
My mum’s success all came down to great preparation by
somebody else. The various IP experts had encapsulated
their knowledge in an IP-XACT way, which meant that
when she chose to include an ARM processor in the design,
the information about the supported bus interface (in this
case, AMBA AHB) and software compilers was immediately
available. That, in turn, invoked the choice of compatible
USB and also how to compile the USB drivers to work
with the ARM processor. It also enabled a generator with
AMBA AHB specialist knowledge to create the specialist
interconnect HDL, checked that suitable memory had been
connected into the system, offered up a list of verification
IP that could be useful in this design, and generated some
HTML design documentation and testbench. Finally, the
design was automatically compiled for her chosen HDL
simulator and verification system (no - I don’t know how
she selected one simulator from another either - I think she
www.chipdesignmag.com/spirit The SPIRIT Consortium Guide
31

The SPIRIT Consortium Guide
picked a name she liked from the list of simulators that were
capable of running the mixed VHDL/Verilog design she had
created) and she started simulating.
If she had chosen a PowerPC processor, she would have ended
up using a different USB (one recognized as compatible with
PowerPC, not AMBA AHB), and different compilers and
different simulators, but the result would have been the same -
a functioning processor-based USB subsystem. As she learned
more about USB subsystems, I bet she would also have gone
back and chosen some different configuration options that
would have produced even better results.
And using IP-XACT, it means that the USB subsystem
design that she created can now be shipped as a configured
IP-XACT component for somebody else to use in a larger
design (given her design experience, you see why I emphasize
that automated verification by the recipient of this module is
probably a good thing!).
The ‘big picture’ here is that IP-XACT can enable designers
to create and verify big designs very quickly, but only if the
expert has taken the time to prepare and check that data in the
first place. This information preparation is not a trivial task.
And it is only worthwhile investing in that data preparation
if there is a reasonable expectation that the IP will be used
in many different designs. For quality IP providers, this can
be a great way to put their IP directly into a working design.
I say ‘quality’ because IP-XACT automation means good IP
can be demonstrated to be working quickly, and bad IP will
be shown to fail equally as fast.
Adopters of IP-XACT are reporting some interesting data.
The IP preparation process is quite rigorous (IP providers
don’t know how the IP is going to be used in a design), and
one consequence is that the delivered IP-XACT enabled IP is
of measurably higher quality.
Here’s some information for proponents of all-in-one ESL
top-down design methodologies (by the way, IP-XACT is
completely design and process agnostic, so any mix of ESL,
RTL and gates is just fine). The recently released IP-XACT
1.4 XML schema has extended the data model to encompass
transactional interfaces. In trying to integrate ESL views of
IP with RTL views (IP-XACT information domains mean
that each IP might have multiple, equally valid, sets of data in
different information domains), it became clear RTL and ESL
data was being used inconsistently and there were only limited
circumstances where the data could be considered different
32
views of the same IP. This was initially perceived as a
problem - until it was realised that recognising, and working
with, the differences opens the way to sophisticated design
transformations that encompasses both ESL and RTL and
lots more besides. Do you want to map your RTL design onto
a ESL model format that enables power and performance
estimation? IP-XACT may be able to automate the design
transformation for you. And writing down the transform
means that the same automated processes can be applied
to many different designs automatically. This means that
there is no real concept of top down (or bottom up, or
middle out, for that matter), just transformations.
Is the IP-XACT data model complete? The answer is no,
and it probably never will be. There will always be new
information domains that can be added to the IP-XACT
model (the process is underway at the moment to enhance
the register description capabilities, and debug capabilites
and verification options). IP-XACT has been built in a way
that external groups can also add their own data, for eventual
inclusion in the IP-XACT standard.
But the well-established core framework enables
designers (and my mum) to exploit the expert knowledge
already embedded into IP-XACT, to focus on the key
design decisions and automate the non-value added
design tasks, and means that sophisticated designs that
fully utilize the available silicon capacity can be created
more quickly, reliably and productively than has ever
been possible before.
The next opportunity to see the range of IP-XACT enabled tools,
IP and design processes in action is at The SPIRIT Consortium
Open General Meeting at the 45th Design Automation Conference
on Monday evening, June 9th starting at 6:00pm in the Anaheim
Hilton. For more details and to register to attend, please visit
www.spiritconsortium.org/events �
The SPIRIT Consortium Guide www.chipdesignmag.com/spirit

Duolog Technologies
Duolog Technologies
The SPIRIT Consortium Guide
The Collaborative Design Automation Company
Our Vision Duolog, The Collaborative Design Automation Company, is a pioneering developer
of EDA tools that enable the flawless and rapid integration of today's increasingly
complex SoC, ASIC and FPGA designs. Duolog’s Socrates Chip Integration
Platform enables IC designs that are Perfect By Construction.
Value Proposition The world's leading IP and IC/SoC development companies rely on Duolog tools
to automate their chip integration processes - eliminating bugs, shrinking design
cycles and drastically reducing the risk of costly delays and respins.
Products Socrates Integration Suite – a comprehensive IC integration framework:
www.duolog.com
Spinner – Fully automated I/O fabric generator that eliminates I/O bugs
from top-level IC integration
Bitwise – Powerful register management tool that facilitates hardware/
software interface collaboration for IPs and systems
OCP Toolkit – a versatile suite of tools for OCP analysis and debug:
OCP-Tracker – Performance analysis tool for OCP-based systems with
powerful filtering and visualization capabilities
OCP-Conductor – OCP transaction visualization tool to greatly ease system
debug and provide intuitive transaction analysis
R&D Duolog tools are designed by “IC designers for IC designers” to prevent and
eliminate the design flaws that plague the integration of today’s complex chip
designs. Duolog has over 70 engineers at Development Centers in Dublin and
Galway, Ireland and Budapest, Hungary.
Sales & Support Dublin, Ireland Nice, France
Bangalore, India San Jose, California
Contact www.duolog.com info@duolog.com
“TI has been using Duolog's Integration tools since 2002 on our OMAP SoC
developments. Spinner has fully automated the creation and management
of the IO layers and has greatly enhanced the quality and timeliness of our
deliverables."
Ziad Mansour
OMAP Program Manager, Texas Instruments
Europe: +353 12178400 USA: +1.408.356.7702
About Duolog
Founded in 1999, Duolog Technologies, The Collaborative Design Automation Company, is a pioneering developer of groundbreaking EDA tools
that enable the flawless and rapid integration of today's increasingly complex SoC, ASIC and FPGA designs. Duolog’s Socrates Chip Integration
Platform enables IC designs that are Perfect By Construction
All information is subject to change without notice. © 2008 Duolog Technologies Ltd. All Rights Reserved
www.chipdesignmag.com/spirit The SPIRIT Consortium Guide
33

The SPIRIT Consortium Guide
34
Evatronix
Complete and integrated IP solutions
Evatronix, as a SPIRIT member, plays its active role by introducing the latest IP-XACT standards in the IP industry. As a leading IP provider, the company has
already implemented the IP-XACT packaging in the design and verification processes.
A set of deliverables for one of our USB products, USB-OTG Controller, has been enhanced by IP-XACT 1.2 and 1.4 packaging to facilitate integration of the component
in the SoC developer’s environment. RTL and TLM views, interface abstractors as well as verification components have all been described with IP-XACT meta-data.
IP-XACT packaging may also be provided with other IP cores from our offer, which is listed below.
Microprocessors & Microcontrollers
We offer a wide range of 8-, 16- and 32-bit architectures to satisfy area or
performance requirements of many SoCs.
Our best-selling product, R8051XC, is a fully customizable, silicon proven
microcontroller. It is also the heart of our pre-integrated solutions -
Embedded Internet and USB subplatforms.
The R8051XC includes many additions to the standard 8051
architecture, which spread the range of applications
and increase the performance. Proprietary features
make the CPU benchmark run from 6.9 up to
9.6 times faster than using Intel 80C51
at the same clock frequency.
C68000, C80186 and C6502 are
configurable equivalents to the
microprocessors once made by
Motorola, Intel and MOS
Technology, respectively.
Ethernet Solutions
All of our Ethernet Media Access
Controllers (MAC) are designed for long
and trouble-free operation within most
complex SoCs.
MAC-1G and its area-optimized version,
MAC-1G-L (Lite), support 1000 Mbps networks,
while MAC and MAC-L perform best in still popular
10/100 Mbps connections.
The Embedded Internet subplatform consists of the R8051XC
microcontroller accompanied by the MAC-L controller, proprietary Hardware
Acceleration module and a third-party TCP/IP software stack.
A Physical Connection Sublayer (PCS) that was recently developed for the
MAC-1G makes it an excellent choice for optical fiber dependant ICs.
USB Controllers
The USB Product Line offers a full scope of possible connections,
varying in speed and functionality. USB-IF certification guarantees
their comprehensive compliance with USB requirements.
USB Full and High Speed controllers (namely CUSB and CUSB2) are
supported by a range of dedicated applications. Both IP cores are available
with the R8051XC microcontroller as development subplatforms.
USB On-The-Go (OTG) is a dual-role component, ready to
act as a host or a device, depending on its current
function in the system.
Evatronix, Electronic Design Department
16 Dubois Street, Gliwice, PL43-300
tel. +48 33 499 59 15
fax. +48 33 499 59 18
www.evatronix.pl
ipcenter@evatronix.pl
All the USB controllers were used with a
number of third-party PHYs. Evatronix
performs USB-IF compliance pretesting
to discover and solve any
issues regarding interoperability of its
controllers and third-party USB PHYs.
Memory Controllers
Our solutions allow the development
of an SoC that makes use of every
available memory type.
Static Memory Controller (SMC) fully
supports RAM memory, while ATAIF
Controller enables seamless integration
of Parallel ATA drives.
Both SDIO and NANDFLASH controllers are
designed for more and more common flash
memories. SDIO, due to its compliance with the
latest SDIO specifications, supports a large spectrum of SDIO
applications - not only various memory cards, but also wireless
networking enhancements, like Bluetooth or Wi-Fi, as well
as other SDIO-based solutions – Global Positioning Systems,
cameras or TV tuners.
Evatronix SA, headquartered in Bielsko-Biala, Poland, founded in 1991 develops electronic virtual components (IP cores) along with
complementary software and supporting development environments. The company also provides electronic design services. Its main design
office location, Gliwice (Poland), guarantees easy access to the pool of talented graduates from the Silesian University of Technology. Evatronix
IP cores are available worldwide through the sales channels of its strategic distribution partner CAST, Inc. (New Jersey, USA). In the EU countries
(excluding UK) and in Switzerland Evatronix operates a direct sales channel. Design services are offered directly by Evatronix world wide.
The SPIRIT Consortium Guide www.chipdesignmag.com/spirit

Microprocessor Cores
Power Architecture e200
ColdFire Series
C166
TriCore
CR16
Nexus 5001 Debug for ARM®
Multi-Core Debug System
AMBA Subsystems
Famous IP for your Chips
Silicon Valley HQ
307 Orchard City Drive
Suite 202
Campbell, CA 95008
TollFree: 800 289 6412
Automotive Cores
FlexRay
CAN
Multi-Link Interface
(MLI)
MicroSecond Channel
(MSC)
Famous IP Available Online
We Proudly Support
Consumer Cores
Bluetooth
MPEG2
High Speed USB Hub
Clock Generators (PLL
replacement)
www.ip-extreme.com
Munich Design Center
Betastrasse 9a
85774 Unterföhring
Germany
Phone: +49 89 9954 8814
Methodology, Services, Tools
IP commercialization of
captive IP
IP design methodology
deployment
IP certification tools
IP packaging tools
IP repository and distribution
system
Tokyo Design Center
Ichibancho MS Bldg. 5F
17-6 Ichibancho, Chiyoda-ku
Tokyo, Japan 102-0082
Phone: +03-4334-3177

The SPIRIT Consortium Guide
36
Magillem Design Services
Magillem Design Services: Go with the Flow
Magillem Design Services offers tools and services that drastically reduce the
global cost of complex system design. The Magillem platform is designed to
preserve independence from EDA vendors and is built on a worldwide adopted
standard: SPIRIT IP-XACT.
The Magillem platform, the leading SPIRIT tool suite, provides an integrated
development environment to systems designers.
Offering
Our experience in both IT (Information Technology) and EDA (Electronic Design
Automation) allows us to efficiently help you and follow up your projects.
Customers have their own design environment and organization: it is key to
provide services to help them fully deploy the best tools.
MDS provides tools via Eclipse-based Magillem:
- IP Handling
- IP Integration
- Design Flow supervision for ASIC and FPGA
MDS provides expert services:
- Design process audit
- Custom tool development
- Design Flow integration for ASIC and FPGA
Solutions
Unlike major EDA vendors, Magillem offers a solution that integrates
existing tools while being unencumbered by proprietary software legacy.
Magillem’s interpretation of the IP-XACT schema has been optimized thanks
to its inputs of major early adopters. Magillem has a long term commitment
to SPIRIT IP-XACT and its technology roadmap is aligned with all future
releases of the specification.
Services
An IP-XACT Compliance Lab
We help companies assess their SPIRIT IP-XACT compliance:
• Semiconductors manufacturers: compliance of the database and
the design flow
• EDA vendors: compliance of the tools interfaces with IP-XACT
• IP Providers: compliance of the metadata description and
configuration nutshell
We audit the existing industrial flow and propose a work plan to
adapt them to IP-XACT. We validate and verify the full compatibility
of tools interfaces into a flow testbench.
We test the IP deliverables against a benchmark for compliance using
our SPIRIT PACKAGER and check IP integration properties onto a test
system.
Our offering includes software modules that guarantee early
adopters with full ascending compatibility of their IP files to any
future upgrade of the IP-XACT standard.
A Custom Generators Factory
Using our own versatile Magillem toolbox, we are well equipped to
offer a wide range of services
Magillem Design Services
161 West 54th Street
Suite 202A
New York, NY 10019 USA
contact@magillem.com
+1 646 226 3960 (tel)
+1 212 292 3999 (fax)
The SPIRIT Consortium Guide www.chipdesignmag.com/spirit
From:
• Analyzing customers database specifics and customizing SPIRIT
Packager accordingly
• Implementing new features to meet customer’s requirements
• Designing complex IP specific configuration nutshells
• Designing and implementing system configuration dashboard and
custom checkers
To:
• Streamlining Flow process
• Developing and integrating specific point tools
• Developing and integrating tools for the global architecture of a
start-to-end ESL flow

Mentor Graphics Corporation
Platform Express, Mentor Graphics’ Platform-Based Design
product, enables rapid design creation and verification through highly
automated IP Reuse. The product uses the latest IP-XACT 1.4
databook format from the The SPIRIT Consortium, enabling designers
to mix RTL and ESL components in the same designs.
Mentor Graphics is the key developer of the core technology behind The
SPIRIT Consortium’s IP-XACT specification and continues to advance
the specification by developing design tools that bring the benefits of
the specification to the end user.
Using the tool and its large number of sophisticated generators, SoC
designers can rapidly create and verify their system designs by automating
complex, error-prone design creation, IP integration, power domain
creation, software generation, verification steps, and a configurable
build environment to enable easy design hand-off. Based on standards
throughout, Platform Express is supplied in Eclipse plug-in format, enabling
the tool to operate as part of a larger, customized, design environment.
The SPIRIT Consortium Guide
Platform Express provides a new set of generators that support 0-In®
Checkerware verification IP, as well as PSL and OVL assertions. The
product also features direct links to the Mentor Graphics Questa
verification environment and provides a framework for enabling other
verification formats.
Mentor Graphics Corporation
8005 S.W. Boeckman Rd.
Wilsonville, OR 97070-7777
USA
Tel:503-685-7000
Fax: 503-685-1204
www.mentor.com
www.chipdesignmag.com/spirit The SPIRIT Consortium Guide
37

The SPIRIT Consortium Guide
38
Scarlet Code
IP-XACT Components
IP-XACT is a collection of real-data and meta-data describing
components, systems and their implementations, allowing IP providers
to create a standard, consolidated description of their IP components
and systems. The standardised IP-XACT format improves down-stream
usage for system Integrators and users of the IP.
The data required for an IP-XACT file is itself sourced from many places
and comes in several different formats, making IP-XACT creation an
error-prone and difficult multi-step process.
Component Foundry – eases your IP-XACT development flow
Component Foundry is a low-cost IP-XACT component creation, viewing
and editing tool, which will create IP-XACT descriptions straight from
your legacy IP. Parsing information straight from Verilog file sets and
PDF documents, it creates IP-XACT files in seconds.
The intuitive GUI and semantic checker offer easy and accurate
editing of IP-XACT components throughout their creation process,
without any prior knowledge of XML ! The tool provides wizards
to help where user input is required, and highlights any missing
referenced files, allowing the user to ensure IP-XACT descriptions
are complete and accurate.
Component Foundry offers a unique intuitive visualisation and
edit capability for;
• Component top-level overview
• Component interfaces, including bus-component port mappings
• Component channels
• Component model, including signals, busses and their directions
• Memory maps, including Address blocks, Registers & bitfields
• Associated files and file structures
• Address spaces
• Bus Definitions
• Semantic Rule-checking of all IP-XACT data
• A library capability to manage IP-XACT Components and Bus Defs.
Component Parser – create IP-XACT descriptions from legacy
IP automatically
Parse IP-XACT information from Verilog file sets and PDF documents,
creating IP-XACT files in seconds.
The Verilog parser;
• Supports Verilog 97 and 2001.
• Handles module hierarchy, can locate top module automatically
• Reads top-level signal list
• Identifies all modules within a design
• Builds a complete file list with ALL include files
• Handles ‘defines, and parameterisation
• Creates the IP-XACT component models
• Extracts Bus Interfaces from library bus definitions
• Extracts Bus signal mappings
The PDF parser;
• Extracts Register names, descriptions, offsets and access types,
NB the PDF parser is document-format dependant.
Component Foundry – Compare IP-XACT against source data
Component Foundry provides the facility to intelligently difference two
IP-XACT component files, displaying the results in an easy to understand
graphical format. This allows users to see at a glance the type, number
and context of the differences between two IP-XACT component files.
For users maintaining or creating IP-XACT component libraries, Scarlet’s
XACT-Delta file comparison capability allows comparison of later-revision
source files against controlled IP-XACT files.
Component Foundry – an eclipse plug-in
Component Foundry is supplied as Eclipse plug-in, allowing users
to focus on creating IP-XACT descriptions of their components, while
leveraging the full power of the eclipse development environment.
The Component Foundry GUI has been carefully designed to reflect the
structure of the IP-XACT specification and allows the user to create accurate
IP-XACT component descriptions in an intuitive step by step manner.
Jump start your IP-XACT flow today
Component Foundry including Component Parser, is available for
immediate download and available for a 2-week free trial from
the Scarlet website; www.scarletcode.co.uk. The toolset is licensed
on a twelve month rental basis, as a node-locked, single-named
user. Other license options are
available by negotiation;
Contact sales@scarletcode.co.uk
The SPIRIT Consortium Guide www.chipdesignmag.com/spirit

Synplicity, Inc.
Introducing The ReadyIP Program From Synplicity
Access. Evaluate. Integrate. Introducing the ReadyIP program
– the industry’s first “try before you buy” design methodology for
FPGA implementation. This program enables you to easily evaluate
and integrate IP from 3rd parties such as ARM, CAST, Gaisler
Research, and Tensilica, or any IP in the Spirit Consortium’s IP-
XACT format into your design. This new capability is a standard
feature of Synplicity’s Synplify Pro® and Synplify® Premier
solutions starting with version 9.2.
Key Benefits
• Access and select IP directly from your Synplify Pro and/or Synplify
Premier’s IP browser
• Evaluate 3 rd party IP instantly from participating 3rd party vendors
by downloading it via links from the product browser, eliminating
the need for complex licensing negotiations
• Integrate internal or 3rd party IP-XACT IP using the Synplify Pro
and/or Synplify Premier solutions’ System Designer capability, or
include the IP’s encrypted (or unencrypted) RTL in any Synplify Pro
or Synplify Premier project
How It Works
The ReadyIP program gives you the freedom to evaluate and choose
from a wide range of 3rd party IP, and then once you have acquired a
Analysis
View
domain@
corner
Operating
corner
Scope Sensitivity ??
SDC
Power
mode
Mode
transition
Library set
Libary
(.lib)
domain@
nominal
Nominal
condition
Cell
Power Domain
Power
switch rule
State
retention
Isolation
rule
Level
Shifter
switch
retention
isolation
level shifter
The SPIRIT Consortium Guide
license for the IP, target the design to your choice of FPGA vendor device.
This is accomplished using the new IP browser and System Designer tool
(now standard in both Synplify Pro and Synplify Premier products).
Benefits
• Use 3rd party FPGA IP from the most popular embedded IP and well-known
peripheral providers including ARM, CAST, Gaisler Research, and Tensilica
• Try 3rd party IP before you buy without the need for complex licensing
negotiations
• Gain design performance insights from Synplify Pro/Synplify Premier
timing reports
• Use the IP in your FPGA of choice once you have acquired IP usage rights
• Rapidly configure and assemble your design, including your own and/or
3rd party IP at the system level using Synplify Pro and Synplify Premier’s
System Designer and then implement it in your FPGA of choice
To learn more about ReadyIP, visit http://www.synplicity.com/readyip.
Low Power Coalition
Low-Power Information Model
Activity
File
Instance
pwr,gnd,n-bias,p-bias
pwr,gnd
• Purpose: Interoperable low-power design flows
• Approach: Flow-based, user-centric, validation of standard with
practical usage, supports wide range of power minimization
techniques, from mobile devices to large servers
• Status: CPF 1.0 Released, CPF 1.1 in process, CPF Pocket Guide
available, CPF Tutorial on-line, CPF part of
Reference Flow of major Fabs
Synplicity, Inc.
600 West California
Avenue
Sunnyvale, CA 94086
www.synplicity.com
info@synplicity.com
www.si2.org
www.chipdesignmag.com/spirit The SPIRIT Consortium Guide
Module
Net
Power
Gnd
Bias
Pins
virtual
Ports
LPC Members
AMD
Apache Design
ARM
Atrenta
Azuro
Cadence
Calypto
ChipVision
Entasys Design
Freescale
Golden Gate Technology
IBM
Intel
LSI
NXP
Sequence Design
STMicroelectronics
Virage Logic
39

nO ResPIns
Compilation Can Play a Big Role
in System Performance
People tend to emphasize the effects of the processor
architecture on performance and power consumption.
Yet both the coding and compilation methodology also
can have significant effects on performance and power
consumption. Most programs spend the bulk of their time
in loops of some kind, which can execute millions of times
a second. Generally, compilers use worst-case assumptions
to determine what’s required to get the job done. This
frequently results in redundancy in the compiled code—
especially because of assumptions made about code and
data in other modules.
The problem is that such assumptions cannot be divined by
conventional compiler technology, which only optimizes for each code
module. Redundant code in a loop can result in the millions of wasted
cycles that are spent executing the same function multiple times every
time the loop is executed. If just six instructions are repeated inside the
loop of a PIC16, 24 extra clock cycles will be required per iteration.
For a loop that executes 100,000 times per second, 2.4 million clock
cycles will be unnecessarily wasted. In a 20-MHz microcontroller, for
example, this translates into 12% of the total cycles.
Interrupts also can have a large effect on MCU performance. Again,
this is because of the worst-case assumptions used by conventional
compilers. Ordinary compilers save every register that might be used
by an interrupt because they have no way of knowing which registers
will or will not be used by a given interrupt. Most PIC16 compilers,
for instance, save 8 Bytes of data for every interrupt. They therefore
require 168 cycles per interrupt. A 480-kbps serial-communication
port, which generates 24,000 interrupts per second, will use 20%
of the available cycles on a 20-MHz PIC16. So far, we’ve stripped a
20-MHz MCU of 32% of its total available processing capacity. And
that’s just for handling loops and saving context!
New omniscient-code-generation (OCG) technology is available
that has the intelligence to identify and eliminate redundant code.
It also promises to optimize all pointer stacks and registers in the
program for better performance and more efficient code. Essentially,
omniscient code generation works by collecting comprehensive data
on register, stack, pointer, object, and variable declarations from all
program modules before compiling the code. An OCG compiler
combines all of the program modules into one large program, which
it loads into a call-graph structure.
Based on the call graph, the omniscient code generator creates a
pointer reference graph. This graph shows each instance of a variable
having its address taken. It also depicts each instance of an assignment
of a pointer value to a pointer (either directly via function return or
function parameter passing or indirectly via another pointer). It then
identifies all objects that can possibly be referenced by each pointer.
This information is used to determine exactly how much memory
space each pointer will be required to access.
An OCG compiler knows exactly which functions call and are
called by other functions as well as what variables and registers are
required and which pointers are pointing to which memory banks.
As a result, it knows exactly which registers will be used for every
interrupt in the program. The compiler also can identify redundant
or re-entrant code. It generates the object code to minimize the
total code size, SRAM requirements, and CPU cycles required.
By optimizing the context, the OCG compiler can cut the number
of cycles used for context save and restore them to as few as 68
cycles. In doing so, it can potentially reduce the CPU’s load to 1.6
million—conserving 12% of the CPU cycles.
By identifying and correcting redundant code in a loop, an
OCG compiler can provide comparable performance benefits.
Removing just 6 Bytes of unnecessary code from a loop would
save 24 clock cycles in a PIC device. This translates into 2.4
million cycles if the loop executes 100,000 times a second or an
additional 12% of the processor cycles.
Saving cycles in the code is equivalent to adding Megahertz to the
MCU hardware. If software and compilation technology can conserve
nearly 5 million clock cycles per second on a 20-MHz device, the
device’s ultimate performance or its ability to do other processing has
been effectively increased by 25%. In an application that’s reaching the
limits of the MCU’s ability to execute, getting the extra cycles might
prevent the forced migration to another faster and more expensive
microcontroller. Such a migration would require that the code be rewritten
as well. Omniscient compilation can improve performance
while saving both power and cost. ◆
Author: Clyde Stubbs is founder and CEO of HI-
TECH Software in Queensland, Australia. His
university research in compiler technology led to the
founding of HI-TECH Software in 1984.
By Clyde stubbs
40 • March 008 Chip Design • www.chipdesignmag.com

������������������
������������������
�����������������
����������������������������������
��������������������������������
�����������������������������������������������
�������������������������������������������������
���������� ���������� ��������� ����� ���������������
�����������������������������������������������
����������������������������������������������
������� ���������� ��������� ����� �������� ����
�������������������������
���� ���� ������������� ���������� �� ��������
������������� ��������� ��� ����� ����������� ����
��������������������������������������������
��� ���� ���������� ���� ����� �������� ��� �������
����������� �������� ��������� ������� ����������
��������������������������������������
���� ������ ���������� ������� ������ ���� ���� �����
������������������������������������������
��������������������
�������������

�
��� ��������������
��� ������ ����
���� ������� �� ������ ���� ����� ���� ���� ������
���
��
������ ��
������
�������
���������
����������
���
��������
����� ��� ������ ����������� ���� ��� ������ �������� �� ��� ���� ���
����� ���������� �������������� �� � ���������� ���������� �� ��� ������
������������ ���� ������� �� � ���������� ���������� �� ������� ������
�������� ������� ����� ����� ��� ��� �������� �� ����� ���������� �������
�
������
������ ���� ���� ������ ����
������� ������� ���� ������ �������� ���� ����
������ ��������� �� �� ����� �� � ���������� �� ���������
��� �������������� ��� �� ���� ������� ��� ��� ������ ���� ���
�������������� ��� ������������� ��������� �������� ��������
���� ��� ��������� ��������� ��� ����� ��� ������� �������� ���� �������
��� ���������� ������ ��������� ���������� ���� ��� �� ���� ������
����������� ���� ��� ��������� ��� ���� ������ ���� ��������������
�������� ����� �������� �� ��� ������ ��������
���� ������� �� ����
������ ���� ��� ��������� ��� � ������� �� ����������� ������� ������ ������
���� �� ���� ��� ������ ��� ��������� �������������� ���� ����������� ���
���� ���� ���� ��� ���� ���� ������ ���� ����� ��� �������� ������ ���������
����� ���� ������������ ���� �������������� ��� ������
��� ���� ����������� ����� �������������� ���� ��� �� ������������ ��
����� �� ������ �� ���������������������������
iv •January/February 2008 Chip Design • www.chipdesignmag.com
iv • April 008 Chip Design • www.chipdesignmag.com