feature article
Subscribe Now

The Real Fear Factor

Dealing with mass quantities of unsavory bugs is commonplace in both reality TV and modern-day chip design. And, the “fear factor” for both is the same, too: failure to do so in the time specified can put an end to a contestant’s 15 minutes of fame or cost a designer his or her job.

In the era of the system on chip (SoC), dealing with tens of millions of gates is a given for hardware design teams, but the time-to-market game is getting more complex and fraught with danger due to the explosion in embedded software. According to several design teams in the midst of budgeting for their next design, the software portion of an SoC is on an annual growth rate of 140 percent. Hardware is expanding just 40 percent year to year.

If this is today’s reality, how are design teams able to keep up? And, are there any more practical ways to debug and verify embedded parts of the design before the hardware is done?

In this new reality, there are three alternatives. The first is a software-based development environment that models hardware in C at a high level of abstraction, or above the register transfer level (RTL) level. While it’s fast, it suffers two drawbacks. First, creating the model is time consuming and access to a complete library of ready-made models is beyond reach. Second, it is not suitable to verify the integration between the embedded software and the underling SoC hardware because of the difficulty of accurately modeling hardware at this high level of abstraction.

Another option is the self-built field programmable gate array (FPGA) prototype, which allows the design team to represent its device in actual silicon at quasi-real time speeds. A few shortcomings should be pointed out with this approach. First, it is limited to the specific design so it will only have one use. Additionally, it steals time away from the actual work of creating chips. Second and the most vexing drawback: it can be devilishly difficult to implement, especially true when arrays of six or more FPGA devices are required.

Reality bites. To get a properly functioning prototype, the design team is forced to address a range of complex issues, such as design partitioning, clock tree routing, bus handling and memory mapping. It is often problematic enough to get these stressed designers wondering if they are addressing design errors or errors in prototyping.

A reality check shows that the most promising method available today is a commercially available, souped-up FPGA prototyping platform. It has the ability to test embedded software on large designs of tens of millions of application specific integrated circuit (ASIC) gates and can still be used for conventional hardware verification and hardware/software integration.

A single platform for hardware verification and embedded software validation offers a real cost-effective alternative to the other two approaches. Built with arrays of a few large FPGAs, it features an automated design mapping process to slash setup time from months to days. This prototyping platform can apply a software testbench to the FPGA implementation of the design that when based on transaction-mode can execute at several megahertz speed. Or, it can execute embedded software at several megahertz speed, while simultaneously supporting hardware debugging and software validation.

Megahertz speed in transaction-mode opens up several unique possibilities. For instance, designers can create a virtual test environment to replace the cumbersome and erratic in-circuit emulation (ICE) testbed. Unlike an ICE testbed that serves one specific design and is not reusable on a different design, transactors can be reused. No ICE hardware means designers can verify their designs from remote locations.

Hardware debugging becomes easier and more effective 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. It’s faster and more effective because it supports step-by-step execution essential for efficient software debugging.

Design teams are working on ever more complex designs that combine many interconnected blocks, including reduced instruction set computer (RISC) processors, digital signal processors (DSPs) and co-processors. They need to debug hardware and develop software in parallel, and now have the means to do it with this new generation of FPGA prototyping platforms.

The next time a design team is up against the clock and the bugs seem to be winning, it doesn’t need to have a “You’re fired!” ending. Unlike reality TV, today’s chip designers have more options, along with new and better ways to approach the problem than simply eating as many as you can. That’s the reality!

Leave a Reply

featured blogs
Feb 27, 2021
New Edge Rate High Speed Connector Set Is Micro, Rugged Years ago, while hiking the Colorado River Trail in Rocky Mountain National Park with my two sons, the older one found a really nice Swiss Army Knife. By “really nice” I mean it was one of those big knives wi...
Feb 26, 2021
OMG! Three 32-bit processor cores each running at 300 MHz, each with its own floating-point unit (FPU), and each with more memory than you than throw a stick at!...
Feb 26, 2021
In the SPECTRE 20.1 base release, we released Spectre® XDP-HB as part of the new Spectre X-RF simulation technology. Spectre XDP-HB uses a highly distributed multi-machine multi-core simulation... [[ Click on the title to access the full blog on the Cadence Community si...

featured video

Designing your own Processor with ASIP Designer

Sponsored by Synopsys

Designing your own processor is time-consuming and resource intensive, and it used to be limited to a few experts. But Synopsys’ ASIP Designer tool allows you to design your own specialized processor within your deadline and budget. Watch this video to learn more.

Click here for more information

featured paper

Functional Safety-Relevant Wireless Communication in Automotive Battery Management Systems

Sponsored by Texas Instruments

With increasing energy density in HEV/EVs, effective battery management and monitoring is essential to avoid any kind of hazards related to overvoltage or overtemperature. This paper explores achieving ASIL D functional safety compliance while using a wireless battery management system.

Click here to download the whitepaper

featured chalk talk

Medical Device Security

Sponsored by Mentor

In the new era of connected medical devices, securing embedded systems has become more important than ever. But, there is a lot medical device designers can borrow from current best-practices for embedded security in general. In this episode of Chalk Talk, Amelia Dalton chats with Robert Bates from Mentor about strategies and challenges for securing modern medical devices and systems.

Click here to download a whitepaper called "Medical Device Security: Achieving Regulatory Approval"