Published on January 19th, 2008

Improved IP-Centric Post-Silicon Validation Solutions Create A New IP Opportunity

Suppliers can accelerate the proliferation of their IP by embracing some practical solutions to difficult problems.
Semiconductor developers are creating significantly more complex devices and incorporating more third-party IP. As a result, post-silicon system-on-a-chip (SoC) validation- especially IP validation-has become an immensely complicated effort. This complexity is compounded by the fact that these sophisticated SoC devices are finding their way into missioncritical systems. Such systems require extensive post-silicon validation methodologies to ensure that all performance, reliability, and safety requirements are achieved.

Indeed, such rigorous in-system validation methods are often difficult to implement. Typically, the IP lacks the built-in facilities that are needed to evaluate on-chip, at-speed functionality in an embedded environment. Moreover, SoC integrators lack detailed knowledge of the acquired IP, which they would need to compensate for this shortfall. Currently, many IP suppliers provide a comprehensive, pre-silicon verification solution along with their design IP. These solutions include functionalverification models, assertion checkers, and compliance testing software. Other than embedded-processor vendors, however, very few IP vendors provide solutions that can be carried all the way to silicon. This trend is problematic, as unexpected postsilicon issues often delay market introduction or negatively impact early production cycles.

Designers of complex SoCs understand that a few surprises are inevitably discovered in first silicon. Those "surprises" aren't catastrophic errors that slipped through the pre-silicon verification environment. Rather, they're subtle and unpredictable problems resulting from complex and unique interactions among many sophisticated subsystems. These aren't always (or even often) digital logic functional errors-even though they generally manifest themselves as those types of errors. Rather, the problems may originate from the power or clock system. In addition, they can be caused by switching noise, crosstalk, or PVT-dependent timing errors. They may even result from an unexpected hardware-software interaction.

Many problems are first detected on chip-in-system within the digital logic. As a result, that is often where the "detective work" begins. The digital logic does contain many clues leading to the root cause. Unfortunately, it is becoming increasingly difficult to perform this work with limited or inferior tools in and around an embedded IP block of which the developers have limited knowledge. As a result, developers waste precious days or weeks being hobbled by a lack of on-chip visibility and control. Moreover, this happens during the most visible and perhaps the most stressful phase of development. As if the diagnostic process isn't frustrating enough, it is often further complicated by communication and cooperation challenges that are introduced when IP blocks from multiple suppliers are potential culprits.

Of course, the challenges aren't limited to isolating and diagnosing unexpected IP-related problems. In fact, one can argue that bigger challenges lie in proving or validating correct operation across all operating conditions. Even if an IP block is designed perfectly and meets all operational requirements, complete and comprehensive validation can be exceptionally time consuming. Complex circuits require complex validation and testing systems. Exercising and testing the basic circuitry is straightforward. But reaching corner cases and deep-state conditions is often impossible without substantial and advanced planning and design efforts. Who should provide the advanced planning and design? The IP supplier? The integrator? Both?

The validation and debug problem is becoming more unmanageable because SoC/application-specific-integrated-circuit (ASIC) designs include increasing amounts of third-party IP. This IP includes embedded processors, networks on chip, peripherals, and more. The time spent performing post-silicon validation, performance monitoring, optimization, and debug will continue to expand. It also will continue to offset many of the schedule gains realized with superior design and verification methodologies.

Some SoC developers are taking matters into their own hands by developing validation and debug solutions for procured IP. Yet this approach places an unnecessary burden on design teams with limited resources, time, and expertise. It also may create an IP "ownership" problem if instruments are embedded deep within the soft IP. Perhaps most importantly, placing such burdens on IP consumers mitigates many of the primary benefits of IP procurement and re-use. Clearly, it's in the IP supplier's best interest to provide solutions that enable customers to move through all phases of chip development more efficiently. In today's world of complex submicron systems, both third-party IP suppliers and internal IP-development teams need to adopt better post-silicon validation methodologies.

Practical and effective post-silicon validation tools are available today. Using these solutions, IP suppliers can provide on-chip observability and control that enable developers to more efficiently validate functionality. When necessary, they can even diagnose problems. It's important to note, however, that instrumentation for on-chip observability isn't always enough. On-chip control-when it's designed correctly-can provide a means to reach corner cases that might otherwise be difficult to test. It also can hasten the completion of lengthy and complex test sequences. In some cases, it may even accelerate the appearance of infrequently occurring problems.

Post-silicon validation isn't a new concept. Most sophisticated and many experienced chip designers embed some form of instrumentation into their designs to provide on-chip visibility of key design elements. State-machine values are captured in memory-mapped registers. Memories are inserted with built-in self-test (BIST) collars. Embedded-processor subsystems include instruction breakpoint control, single-stepping, and instruction trace-capture functions. All of these aspects are essential for validating system functionality and resolving complex post-silicon issues.

Unfortunately, SoC/ASIC design teams are already stretched by aggressive schedules and limited resources when they're integrating a multitude of complex in-house and third-party IP blocks. As a result, they don't seriously consider providing anything more than the simplest instrumentation solution. They understand that this new, additional circuitry will increase the verification workload, further stretching finite resources. If it isn't done carefully, adding instrumentation within IP blocks is dicey-especially if the IP integrator isn't intimately familiar with the circuit. Considering the size and dispersed location of many design teams, the validation and instrumentation strategy is often inconsistent, insufficiently documented, and exposed to the least amount of pre-silicon verification. When faced with difficult resource assignments, current in-house instrumentation solutions are often de-emphasized in favor of more pre-silicon verification.

There's no doubt that the preponderance of resources should be focused on pre-silicon verification-and for good reason. Clearly, the goal is to deliver perfect first-pass silicon or at least a version that can satisfy early production needs. Yet many teams find themselves in situations where the first-pass silicon design is indeed (ultimately) suitable for early production usage. They cannot be sure, however, until they have spent months validating all of its complexities. Ironically, silicon-validation processes rarely leverage the pre-silicon verification system.

A variety of on-chip instrumentation and post-silicon validation techniques are widely accepted (if not consistently or methodically implemented). But employing such solutions as extensions to the pre-silicon verification environment is an overlooked technical and commercial opportunity. The most obvious pre-silicon extension is to re-apply assertions in silicon. Assertions are remarkably useful-not just during pre-silicon verification, but for quickly validating in-system at-speed circuit behavior in an automated and comprehensive manner. For IP consumers and/or integrators, a suite of post-silicon assertions provides a means for validating behavior without the need to analyze register transfer level (RTL), circuit diagrams, state tables, or transaction waveforms. Assertions also shield IP consumers from the detailed inner workings of a circuit while limiting the amount of knowledge that IP suppliers must impart on their consumers. They also limit the amount of time that consumers must invest in a given IP circuit.

While some assertions could be implemented in the IP itself, that's only feasible for a limited number of assertions. A more effective approach would be for IP suppliers to use reconfigurable instruments and sequentially apply (configure) select assertions during system validation. A large group of assertions could then time-share the same instruments.

Figure 1
Figure 1: Verification-driven instrumentation is shown here.

Note, however, that assertions alone aren't enough. A basic feature that an IP supplier can provide is optional access to key internal signals. These signals identify important transactions occurring in the IP block. The IP integrator then has the option of inserting a block- or chip-level logic-analysis circuit to operate on such signals from multiple IP blocks.

Other unique and perhaps more beneficial methods are emerging with compelling productivity multipliers. Consider the enormous value of a "verification-driven" validation and debug instrumentation scheme, which utilizes key stimuli and watch points (see Figure 1). For example, what if transactions created in the testbench could be realized in silicon? What if the event triggers implemented in on-chip instruments could be used equivalently in simulation, emulation, and silicon? Also, consider the following:
  • Instruments and instrumented signals could be integrated into the pre-silicon verification testbench and then selectively re-used during first-silicon testing.

  • With in-system at-speed control, the designer could easily reach complex corner cases and perform critical break testing using the same signals and test sequences developed during the verification flow.

  • The designer could capture on-chip data and then use that data to inform new simulation runs and analyze post-silicon validation coverage.

  • The designer could embed RTL instruments in his or her design so that they could be used in all targets. It would then be possible to design, implement, and verify the designer's own unique validation, data-acquisition, and performance-monitoring test suites in his or her simulation or emulation environment-in advance of and for immediate application upon the arrival of first silicon.

Just a few of these features would signal a tremendous improvement over conventional post-silicon validation methodologies (see Figure 2). Such features are imperative for establishing a comprehensive validation protocol that ensures device performance and reliability.

While we all strive and hope for flawless first silicon, we also must plan for debug. Even with significant advances in pre-silicon verification tools and silicon instrumentation, debugging is often the primary bottleneck in both the silicon-validation process and the path to volume production. As such, it's important that silicon validation and debug solutions be available in all phases of the design flow. Note that subtle, unpredictable, and infrequently occurring problems cannot be diagnosed in silicon alone. They require a diagnostic approach that enables developers to move more easily from silicon back to simulation, emulation, and/or field-programmable-gate-array (FPGA) prototype. In fact, the solution should allow relatively unrestricted movement among all "target" platforms.

One can argue that problems in the power or clock system or related timing issues cannot be isolated (much less identified) in a simulation, emulation, or FPGA environment. That point is true enough. With diagnostic solutions that can be carried between multiple target systems, however, the suspect list can be pruned much more quickly than might otherwise be possible. Furthermore, this is precisely why on-chip post-silicon solutions are needed in the first place!

Figure 2
Figure 2: Extending verification into silicon:
1. Verification-driven instrumentation and test generation
2. On-chip results are carried back to simulation or emulation.
3. Simulation/emulation analysis informs additional validation and/or debugging.
4. Information bridge between pre-silicon and post-silicon development
environments


SoC and IP development teams understand that successful project outcomes require continued improvement in pre-silicon verification techniques. Even more importantly, a well-planned strategy and implementation methodology are needed for postsilicon validation. The key components for in-system, postsilicon validation and debug require:
  • Compact, parameterizable, distributed, reconfigurable, on-chip RTL instruments (technology-independent) with automated insertion for use in simulation, emulation, FPGA, and SoC/ASIC

  • A data flow that allows elements of the verification testbench to be applied in silicon and permits silicon results to be carried back and applied in simulation, emulation, or on FPGAs

  • Unobtrusive, in-system, at-speed access to instrumentation through a standard interface like JTAG  System-wide, multi-threaded, multi-clock domain visibility and control

  • Software applications and data-analysis tools available for use in simulation, emulation, FPGA, and SoC/ASIC that leverage instruments for tasks like logic analysis, trace capture, assertions, transaction stimulus, fault injection, and performance monitoring

  • SIn-system scan-chain dumping for observability of un-instrumented registers used during validation and debug (Event triggering and clock stopping is implied.)

The application of these solutions provides the basis for an automated post-silicon validation system (see Figure 3). With a modest investment in the above solutions, post-silicon resource utilization can be cut in half. Once a more fully automated, postsilicon testing framework is established, even larger gains will be achievable. In the same way that IP suppliers will transfer the benefits of advanced validation to SoC/ASIC developers, the benefits are transferred to board and system designers. As a result, the efficiency of the total development chain will be enhanced while the time required to deliver solutions to end users is reduced.

The electronics industry has achieved successes and continues to realize advances in design description languages, logic synthesis, physical design, and pre-silicon verification. Until now, though, very little automation has been realized in the realm of post-silicon validation. IP suppliers have a unique challenge and opportunity to accelerate the proliferation of their IP by embracing some of these practical solutions to difficult problems.
Paul Bradley is Vice President of Engineering at DAFCA Inc. Bradley specializes in product development and engineering leadership in emerging technology markets. Prior to joining DAFCA, he held numerous engineering and technical leadership positions at Motorola, Nortel, CrossComm, Sonoma Systems, and Internet Photonics. Bradley can be reached at paul.bradley@dafca.com.

Tech Videos

©2018 Extension Media. All Rights Reserved. PRIVACY POLICY | TERMS AND CONDITIONS

Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.