SoC Verification: A Life-or-Death Issue for Medical Electronics




While hands on care helps patients, when the subject is functional verification for the SoCs that medical electronics (and patients’ lives) rely on, the limits to what can be done by hand are just as important. Recent advancements, however, could mean that relying on such things as hand-written C tests to verify SoCs with multiple processors is a thing of the past.

It is widely accepted that functional verification is a major bottleneck in the development of system-on-chip (SoC) semiconductor devices. As silicon geometries shrink and more functionality is packed into every chip, it becomes harder to thoroughly exercise the design in simulation and verify all corner cases before the device is fabricated. When first chips are available, they must be validated in the lab even more thoroughly to be certain that no functional bugs slipped through and that no manufacturing errors were introduced.

Flat line alert on heart monitor
Figure 1. Where SoCs combine hardware and software, software workarounds are sometimes used to counter hardware bugs, but software updates themselves are not without risk.

Unverified corner cases can hang a chip or kill important software processes. Many smartphone users have had the experience of a call being dropped when the cell switched towers at the same time that an email or text message arrived, and the GPS recalculated its location. Verification teams invest a huge amount of time and effort into trying to trigger these corner-case conditions in SoC simulation. Anything untested is likely to contain hidden bugs that will eventually cause trouble for the end user.

Why Bugs Go Undetected
Elimination of corner-case bugs can be a life-or-death issue for medical electronics. An inaccurate reading from a medical instrument may lead to misdiagnosis and mistreatment during a critical period for the patient. The possibility of an implanted medical device hanging, resetting, or doing the wrong thing is even more frightening. Even if a bug has not yet been triggered, the potential for failure puts the patient at considerable risk.

Many medical instruments and implanted devices are based on SoCs that use a combination of hardware and software to achieve their functionality. In some cases, a software workaround can negate the risk of a hardware bug in the chip. But software updates carry their own risks and can take significant resources. A lurking hardware bug that can be fixed only by replacing the SoC is the worst-case scenario, especially for implanted devices. No patient would be happy about another surgery to fix a design problem that should have been caught much earlier.

There are several reasons why bugs may slip through the verification process, but the most fundamental issue for SoCs is that the prevailing methodologies do not support embedded processors. The Universal Verification Methodology (UVM) standard from Accellera views verification from the point of view of a testbench, with verification components (UVCs) providing all data into the chip and reading all data back from the chip. As shown in Figure 2, a testbench element called the virtual sequencer coordinates inputs, and a scoreboard checks results.

fig02
Figure 2. The standard USB testbench for a medical electronics chip does not leverage embedded processors.

Beyond Chip Verification from the Inside Out
Note that the in the UVM testbench processors have been replaced by UVCs that emulate the activity of the processor bus. This is partly for simulation efficiency, but also because the UVM provides no guidance on what sort of code to run on the processors or how to coordinate the processors with the testbench. This sort of testbench is used successfully on individual IP blocks, clusters of multiple blocks and even some types of large chips. However, it is not effective for an SoC device, where the embedded processors control most of the chip’s functionality.

Trying to exercise and verify deep behavior purely by manipulating the SoC’s inputs is an arduous task, even given the semi-automatic capabilities of a UVM testbench. It makes more sense to leverage the power of the embedded processors to verify the chip “from the inside out.” Many SoC verification teams realize this, so they borrow a few embedded programmers to hand-write some C tests to run on the processors in simulation. This is certainly better than running no software at all, but it has two major limitations.

The first issue is that humans are not good at thinking in parallel, and so hand-written tests tend to be quite simple. If the SoC has multiple processors capable of supporting multiple threads each, simple tests will not stress the design thoroughly. The other problem is that neither the UVM nor any other popular methodology makes provisions for linking code running on embedded processors with the testbench. The result is that UVM tests and hand-written C tests are largely disconnected verification efforts.

Another possibility is running the actual production software on the embedded processors in simulation. This code is rarely available during the hardware verification phase of the project and is not effective at finding chip bugs since it’s not designed to stress the design or aid diagnosis if a problem is found. It is essential to co-verify production software and hardware together before fabrication. This typically happens late in the project during in-circuit emulation (ICE) or on an FPGA-based prototype.

The best answer to this dilemma is further automation of the functional verification process by replacing hand-written C tests with automatically generated test cases. The technology exists today to generate multi-threaded, multi-processor, self-verifying test cases that stress the corner cases of the chip design in simulation. These test cases are portable so that they can be run during ICE, on prototypes, and even on the actual silicon when it arrives from the foundry.

These are “bare metal” test cases, including their own memory management, interrupt handling and other system features. The test cases do not require an operating system to be booted and run efficiently even in the relatively slow simulation testbench. Adopting this approach makes it possible to find more bugs more quickly than with a pure testbench, hand-written tests or production software. The generator can produce a test case map that shows how all the threads and processors interact, an invaluable tool for debugging if a test fails due to a bug in the design or an error in the scenario model.

Producing Aggressive, Legitimate Test Cases
The running C code coordinates with the testbench via a runtime element in the testbench that coordinates data flowing on and off the chip. When the test case expects data, it sends a message to the testbench asking for it. When the test case has data ready, it sends a message for the testbench to receive it and compare it to its expected value. The runtime element replaces the UVM virtual sequencer as well as most or all of the scoreboard functionality.

Missing from this puzzle is a way for the generator to acquire enough knowledge of the design and its verification space to produce aggressive, legitimate test cases. The SoC team fills this gap with a graph-based scenario model. Because the model looks like a dataflow diagram of the chip, it is easy to develop. Constraints can be applied on the graph to control test case generation, such as biasing for certain conditions or suppressing verification of design blocks that are not yet implemented.

Figure 3 shows how all this technology comes together in a commercially available implementation of a test case generator and its accompanying runtime testbench element. The graphs can be built top-down, with limited functionality, to supplement an existing UVM-based methodology. Alternatively, graphs can be built for each IP block and plugged together to compose an SoC-level graph. Constraints can be used to ensure that not every design detail for every IP block is re-verified at the full-chip level.

fig03
Figure 3. Automatically generated multi-processor test cases verify the medical electronics chip more thoroughly.

Graph-based scenario models and automatic test case generation replace a risky and tedious manual verification process, increasing the chance for first-silicon success and reducing the possibility of a lurking bug in a medical electronics device. SoC development teams now have powerful technology at their fingertips to produce better, more reliable products and perhaps even save some more lives along the way.


Tom AndersonThomas L. Anderson is vice president of marketing at Breker Verification Systems, the SoC Verification Company. He has more than a dozen years of experience in EDA verification applications and marketing, having served in increasing responsible roles at Cadence, Synopsys and 0-In Design Automation. Before moving into the EDA industry, he was vice president of engineering at Virtual Chips. Anderson holds a Bachelor of Science degree in Computer Systems Engineering from the University of Massachusetts at Amherst and a Master of Science degree in Electrical Engineering and Computer Science from the Massachusetts Institute of Technology (MIT).

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis

Tags: ,