Blog

Comment


DKC

9/22/2010 4:03 PM EDT

Seems to me that the design methodology is at fault, just making the ...

More...



Max the Magnificent

9/21/2010 12:37 PM EDT

I would be very interested to see a breakdown of ASIC/SoC Designs showing the ...

More...

Desperately seeking solutions

Lauro Rizzatti

9/21/2010 12:19 PM EDT

SoC design teams are desperate to find solutions to the verification nightmare.  Solutions come in abundance, but not all are what they claim.  A situation so outrageous it takes a new and versatile approach to solve it; for example, high-performance FPGA prototyping platforms.

These days, the C in SoC could stand for "complexity" and not "chip" due to the explosion of embedded software just as design teams juggle hundreds of millions – or even billions – of gates.  Several design teams currently budgeting for their next project have calculated that the software portion of a system on chip (SoC) is on an annual growth rate of 140 percent.  Hardware is expanding at approximately 40 percent year to year.  All this goes on as the time-to-market budget condenses and verification nightmares grow.

Design teams are hardly able to keep up and are desperately searching for solutions practical enough to debug and verify embedded parts of the design before the hardware is done.  They’ve found three...

The first is the commonly used software-based development environment that models hardware in C at a high level of abstraction – or, above the register transfer level (RTL).  While it’s fast, it has two drawbacks.  Creating the model is time consuming and access to a complete library of ready-made models is limited.  Moreover, it is impossible to verify the integration between the embedded software and the underling SoC hardware because it’s difficult to accurately model hardware at this level of abstraction.

Field programmable gate array (FPGA) prototypes are another well-used and popular option because they let the design team represent a device in actual silicon at close to real time speeds.  This approach is not without a few shortcomings, however:
  • Most notably, a high degree of customization to a specific design is necessary to reach maximum speed, ultimately compromising its reusability on a different design.  Another drawback is poor or no visibility into the design that makes debugging look like the movie, "Desperately Seeking Susan."
  • Perhaps the biggest shortcoming is that prototypes can be difficult to implement, especially when arrays of six or more FPGA devices are required.  This added step can consume a chunk of the project cycle.
  • To get a properly functioning prototype, the design team needs to address a range of issues, from design partitioning and clock tree routing to bus handling and memory mapping.  At times, this can be confusing and it can be unclear to the design team whether it is addressing design errors or errors in prototyping.

Desperately seeking a viable solution, design teams are evaluating commercially available, high-performance FPGA prototyping platforms – call them fast emulators – and reporting great success.  These versatile solutions are able to test embedded software on large designs of many millions or billions of application specific integrated circuit (ASIC) gates and can be used for conventional hardware verification and hardware/software integration.

Not only versatile, one such platform for hardware verification and embedded software validation is cost effective.  Built with an array of a few large FPGAs, it includes automated design mapping to reduce setup time from months to days.  It can apply a software testbench to the FPGA implementation of the design and, when used in transaction mode, can execute at several megahertz speed.  Or, it can execute embedded software at several megahertz speed while supporting hardware debugging and software validation.

Megahertz speed in transaction-mode opens up several possibilities.  Design teams can create a virtual test environment to replace an in-circuit emulation (ICE) testbed, for example.  Transactors can be reused, unlike an ICE testbed that serves one specific design and is not reusable.  Additionally, members of a design team can verify their designs from remote locations.

Hardware debugging is more useful when design clocks not sourced by the hardware testbed are controlled.  It also provides the means to read/write interactively all design registers and memories without compiling access to the FPGAs.

Software debugging can proceed at higher speed when a software debugger is linked to the design via a JTAG transactor instead of a JTAG physical port.  Also, it’s faster and more effective because it supports step-by-step execution essential for efficient software debugging.

Design teams are working on complex SoC designs that combine interconnected blocks, including reduced instruction set computer (RISC) processors, digital signal processors (DSPs) and co-processors.  Then, they need to debug in parallel hardware and develop software, a formerly tall order.  They have the means to do it with a new generation of FPGA prototyping platforms.  Desperately seeking solutions to the verification nightmare may be coming to an end.

About the author
Lauro Rizzatti (lauro@eve-team.com) is general manager of EVE-USA (www.eve-team.com).

Lauro has more than 30 years of experience in EDA and ATE, where he held responsibilities in top management, product marketing, technical marketing and engineering.




Max the Magnificent

9/21/2010 12:37 PM EDT

I would be very interested to see a breakdown of ASIC/SoC Designs showing the distribution of size. Like out of 100 designs how many have 5 million gates or less... how many have 10 million gates... 50 million gates ... 100 million gates ... more than 1 billion gates...

Sign in to Reply



DKC

9/22/2010 4:03 PM EDT

Seems to me that the design methodology is at fault, just making the verification faster doesn't fix that - it will just reduce the time it takes to execute the same old bad practices. Some correct-by-construction tools and formal verification should at least remove the functional verification problem. Verifying your power-management, timing, analog and RF stuff is beyond what an FPGA box will do.

Sign in to Reply



Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Featured Job On
Scroll for More Jobs