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
Dec 1, 2020
If you'€™d asked me at the beginning of 2020 as to the chances of my replicating an 1820 Welsh dresser, I would have said '€œzero,'€ which just goes to show how little I know....
Dec 1, 2020
More package designers these days, with the increasing component counts and more complicated electrical constraints, are shifting to using a front-end schematic capture tool. As with IC and PCB... [[ Click on the title to access the full blog on the Cadence Community site. ]...
Dec 1, 2020
UCLA’s Maxx Tepper gives us a brief overview of the Ocean High-Throughput processor to be used in the upgrade of the real-time event selection system of the CMS experiment at the CERN LHC (Large Hadron Collider). The board incorporates Samtec FireFly'„¢ optical cable ...
Nov 25, 2020
[From the last episode: We looked at what it takes to generate data that can be used to train machine-learning .] We take a break from learning how IoT technology works for one of our occasional posts on how IoT technology is used. In this case, we look at trucking fleet mana...

featured video

AI SoC Chats: Protecting Data with Security IP

Sponsored by Synopsys

Understand the threat profiles and security trends for AI SoC applications, including how laws and regulations are changing to protect the private information and data of users. Secure boot, secure debug, and secure communication for neural network engines is critical. Learn how DesignWare Security IP and Hardware Root of Trust can help designers create a secure enclave on the SoC and update software remotely.

Click here for more information about Security IP

Featured paper

Top 9 design questions about digital isolators

Sponsored by Texas Instruments

Looking for more information about digital isolators? We’re here to help. Based on TI E2E™ support forum feedback, we compiled a list of the most frequently asked questions about digital isolator design challenges. This article covers questions such as, “What is the logic state of a digital isolator with no input signal?”, and “Can you leave unused channel pins on a digital isolator floating?”

Click here to download the whitepaper

Featured Chalk Talk

Rail Data Connectivity

Sponsored by Mouser Electronics and TE Connectivity

The rail industry is undergoing a technological revolution right now, and Ethernet connectivity is at the heart of it. But, finding the right interconnect solutions for high-reliability applications such as rail isn’t easy. In this episode of Chalk Talk, Amelia Dalton chats with Egbert Stellinga from TE Connectivity about TE’s portfolio of interconnect solutions for rail and other reliability-critical applications.

Click here for more information about TE Connectivity EN50155 Managed Ethernet Switches