Alex, I’ll Take “SoC Verification” for $600

As you may have noticed, we call Breker “The SoC Verification Company” because we truly believe that we are defining a new category of EDA tools for SoC verification that has not been adequately addressed by other approaches. In the spirit of an engineer defining his or her terms before use, and with a nod to the long-running TV game show Jeopardy, let’s discuss what defines SoC verification and why it is different from verification of IP blocks and other types of chips.

Let’s start one clue higher on the Jeopardy board, with “SoC” for $400. What exactly is a system on chip (SoC)? Some would argue that any large, complex chip qualifies. We beg to differ. Should a pure processor, no matter how powerful, be called an SoC? Alternatively, should a giant network crossbar switch with no central processor be considered an SoC? The Breker viewpoint says that neither qualifies. We believe that an SoC contains at least one reasonably powerful embedded processor (8-bit MCUs don’t count) and multiple IP blocks interconnected by some sort of bus or fabric.

A recent definition from techradar is close to the mark: “In very broad terms, a system on chip is a microchip that has all the components required to power a computer.” Or, as you might answer on Jeopardy, “What is a microchip that has all the components required to power a computer?” This is too narrow in that the article focuses on SoCs replacing traditional PCs, but it has the right flavor. An SoC contains all of the elements for a complete system that used to require multiple chips. The system being shrunk to a single chip might be a PC, laptop, tablet, cell phone, radio, infotainment system, etc.

Now that we’ve answered the “SoC” clue correctly, let’s move on to “SoC Verification” and  try to grow our $400 to $1000. The fact that an SoC contains one or more embedded processors is the key to why SoC verification is different. In an SoC, the processors are in charge. They run the code that enables the SoC to fulfill its intended function. Therefore, it’s just common sense that any effective verification of the SoC must involve and leverage the embedded processors.

Unfortunately, all the methodologies developed for IP blocks and non-SoC chips are testbench-centric. They focus on building a testbench to stimulate the inputs of the design being verified and check the design’s outputs while somehow correlating the input and outputs together. The embedded processors are ignored. In fact, most verification engineers remove the embedded processors from the design and replace them with bus functional models (BFMs) while running the testbench.  Even the widely adopted Universal Verification Methodology (UVM) standard doesn’t address embedded processors.

We clearly want to take advantage of the sort of test automation provided by the UVM for the chip’s inputs, but apply it to generating C code that you can compile and run in the embedded processors in simulation. The C test cases must be able to run on multiple processors and multiple threads on each processor to stress the SoC’s parallel capabilities. Since the processors control the chip, they can thoroughly exercise not just individual IP blocks but chains of IP blocks working together on realistic application scenarios.

Some of the test cases will exercise the I/O IP blocks and will need to receive data on the chip’s inputs or send data from the chip’s outputs. This can be accomplished by having a runtime component in simulation, also under control of the processors, that communicates with the existing UVM testbench components on the chip’s I/O ports. Wrapping this all up, the right response to Alex Trebek to earn the $600 might be: “What is a process for automatically generating multi-threaded, multi-processor, self-verifying C test cases that run on the SoCs embedded processors while coordinating with the testbench components?”

Yes, our definition is a little circular, but that’s only natural. We studied the SoC verification problem deeply, looked at what was missing in existing approaches, and built our TrekSoC product to fill that gap. So of course we believe that SoC verification should be defined to match our solution. Four years of working with many of the largest SoC projects in the world have convinced us that we are on the right track.  We welcome your thoughts and comments on “SoC verification” from your perspective.

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Breker, EDA, functional verification, integration verification, jeopordy, SoC, SoC verification, TrekSoC

This entry was posted on Tuesday, July 16th, 2013 at 7:07 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.