|
Post-silicon SoC "whole system" validation solutions have lagged behind the increasing complexity of low power schemes, multi-core architectures, complex clock domains and sub 90 nm manufacturing. This is a bad news/good news story. The bad news is that teams developing massive and complex SoCs already realize that they cannot ignore their plans for the post-silicon phase, and that legacy patchwork solutions are no longer sufficient. The good news is that the new paradigms and methodologies employed in the pre-silicon verification space can be leveraged in post-silicon validation. Indeed, the blueprint for abstraction, visibility, messaging, and assertion checking already exists.
Today, complex SOC and ASIC designs require advanced validation and debug solutions that bridge the gap, not just between pre-silicon and post-silicon, but perhaps more importantly, between embedded software and hardware systems.
The need for visibility and control between software and hardware systems is not new. However, the lack of visibility and control has become an acute problem, especially as SoC hardware functions and embedded software systems have grown more complex. The challenge is compounded by multi-core designs composed of heterogeneous third-party processors, buses, switches, and peripherals, where reduced on-chip visibility of key functions and inter-block communications is the current norm. The visibility problem is not limited to complex hardware interactions, but extends to embedded software systems operating on the hardware.
While teams occasionally experience hardware design issues that require a metal layer change or even a full re-spin, a major source of unscheduled delays in post-silicon system development today are problems stemming from the integration of complex hardware and software systems, power management issues, unexpected performance limitations, performance optimization efforts, and general system hardening (like break and compliance testing). These problems require concurrent system-wide visibility, transaction sequence tracking, and hardware-software event correlation. Without such on-chip capabilities, detection, isolation, and resolution of such problems are extremely time consuming.
Neither hardware-centric nor software-centric solutions are sufficient. The validation and debug solution must provide visibility and control at multiple levels of abstraction - from the software application level down to the hardware signal level. For example, validation and debug often require the analysis of a sequence of events, not the analysis of a single event. The ability to detect, monitor, and capture select sequences occurring over a span of nanoseconds, seconds, minutes, hours, or days is often the key to understanding and eventually solving complex multi-dimensional problems.
Fortunately, sequence visibility often permits reduced resolution (more abstract views) and has the benefit of reducing the requisite volume of data required for comprehension. This benefit, in turn, reduces the amount of data required to move off-chip through bandwidth-constricted serial interfaces such as IEEE 1149.1 (JTAG). Also note that higher abstraction often implies the need for on-chip computations such as assertions, pattern recognition, encoding, and performance monitoring. Such on-chip infrastructural services certainly reduce the off-chip streaming requirements, albeit at the incremental cost of additional instrument real estate. Bandwidth issues aside, there are times when a functional problem warrants a deeper look into specific transaction sequences or into bus activities and other hardware events. This may include the measurement of latency between transactions, detection of specific state machine transitions, or the assertion or de-assertion of a signal. Fortunately, the instruments that can deliver abstract views of complex sequential transactions can also deliver more granular visibility of individual transactions.
Good instrumentation is, clearly, one key to a comprehensive and complete solution. However, given the practical realities of systems composed of standards-based and proprietary buses, third-party hardware (and software) IP, in-house designs, and legacy designs, the solution does not lie in the instruments themselves but in comprehensive and cohesive methods that enable on-chip visualization of complex heterogeneous systems.
DAFCA Proposed Solution
DAFCA's solution addresses exactly these requirements. It was designed to ensure that the solution:
- Is not tied to any particular architecture.
- Can be used with any processor family.
- Can accommodate our customers' ASIC tool flows.
- Is technology-library independent.
- Is not bound to a particular standard, but is adaptable to a variety of existing and emerging standards.
Consequently, the DAFCA solution needs to:
- Automate the instrument creation and insertion processes to ease implementation within any design.
- Provide users a way to insert their own instruments and/or connect existing instrumentation to the DAFCA infrastructure.
- Allow users to customize the instruments and the instrumentation topology (fabric) so that it conforms to the design architecture - instead of forcing the design architecture to be influenced by instrumentation needs.
- Include user-defined, compact, programmable instruments for performing a wide variety of functions such as triggering, assertions, transaction stimulus, and performance monitoring.
- Include a software layer for instrumentation command and control.
- Include applications for the most common instrumentation usages.
- Provide the user a means to customize and extend the solution.
Whereas DAFCA initially promoted its basic "logic analysis" solution for hardware debugging, ongoing customer collaborations have helped us realize a number of validation applications. Transaction stimulus was the first validation application, where instruments were used to stimulate (control) circuitry for protocol testing, fault insertion, and basic out-of-band configuration. This was followed by systematic and automated test scripting, where triggers, assertions, monitors, and stimulus were applied continuously across the system, thereby providing both spatial and temporal coverage. Next came performance monitoring and analysis, which measured throughput, latency, and utilization of resources such as interfaces, buses, switches, DMA controllers, and arbitrators in both granular and coarse forms.
To address hardware-software co-validation DAFCA has introduced hardware and software cross-triggering, which enables the correlation of software instructions with lower-level "hardware" events or transactions. This has broadened the scope of applicability, and has, for example, enabled work on hardware and embedded systems security applications using the same "validation and debug" instruments for hardware and software intrusion detection.
While the solution has demonstrated up to now to be flexible, scalable, and extendable, there is no one-size-fits-all magic here. DAFCA recognized early the need to strike a balance between delivering complete and comprehensive solutions for the most common applications, while still enabling unique extensions.
The typical criticism of DAFCA's approach is that such a general-purpose solution requires unique implementation on each design, and puts the onus on the user to create their own triggers, assertions, transaction events, and performance monitors for not just their proprietary buses and interfaces, but even for the standards-based buses. In principal, this is a true statement. But automated instrumentation insertion and instrument re-programmability breeds re-use and scalability. One can imagine the creation, proliferation, and distribution of libraries that include the aforementioned system-validation functions and corresponding instrument insertion rules. In fact, one can find a few examples where such methodology and re-use is already taking hold.
Neglect (or avoidance) of an automated, programmable, and system-wide approach often results in arbitrary, ad-hoc schemes that can't, and don't, solve the fundamental problems of large, complex, heterogeneous designs. A solution that is processor-centric or applicable to only a singular standard bus is not a systematic solution but a short-term patch. The problem is that patches don't scale.
For most design teams, the current reality of on-chip instrumentation is a coordinated, two-pronged approach of leveraging embedded processor IP instrumentation and designing in-house custom solutions. The former is fine for software-centric systems, but the latter is, in most cases, neither scalable nor sustainable. An integrated solution as described in this paper, provides a real and practical path to ensuring that post-silicon validation techniques keep pace with emerging design and verification methodologies.
About the Author:
Paul Bradley is Vice President of Engineering at DAFCA, Inc. He can be reached at paul.bradley@dafca.com
|
