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!