1. My first-pass silicon is usually clean. Why do I need ClearBlue?
Customers have reported that the ClearBlue validation platform significantly reduced the time required to fully validate their designs in system, at speed.
Determining that a design is truly ready for volume production requires the evaluation of extensive application-level validation scenarios. With the use of comprehensive observability and control features of the on-chip, reconfigurable instruments, ASIC/SoC design teams can easily “stress test” individual IP blocks as well as the chip-level integration of those sub-systems in the target application environment. ClearBlue is also invaluable in quickly and systematically diagnosing complex and unexpected behaviors that, at first, appear as bugs, but ultimately turn out to be a simple misunderstanding of functionality or a harmless system integration condition that is actually “normal” behavior. Without ClearBlue, such issues often initiate a flurry of stressful, non-productive, time-consuming debug activity.
2. What is the difference between post-silicon validation and post-silicon debug?
Silicon validation is the act of proving that the ASIC or SoC works correctly at speed and in system (in the lab with the rest of your target system) under actual operating conditions. Silicon debug is the hunt for the root cause of a malfunction somewhere in your system.
Silicon validation and debug require a labor-intensive engineering effort, which is now stretching out to many months and has become the least predictable portion of the product development schedule.
3. What is the impact of the instrumentation on my chip’s performance?
Some instruments are used for “tapping” (observing) signals, while others are used for “wrapping” (controlling) them. For tapping, the effect is an additional load on the node (which is nominal due to synthesis and STA tools resizing the drivers to meet path constraints). For wrapping signals, an additional multiplexer is inserted in the signal path. ClearBlue creates timing constraint files for all instrumented paths so the final impact on path delays can be understood during RTL sign-off.
4. What instrumentation strategy do you recommend?
The instrumentation strategy is tailored to the needs of a particular ASIC/SoC project, architecture, or application. The specific strategy depends on:
- Requirements for using portions of the pre-silicon testbench in silicon (assertions, watch points, etc.).
- Post-silicon objectives (performance monitoring, data acquisition, IP validation, general observability, mode control, assertions in silicon, etc.) and the need to observe and/or control key signals, interfaces, or state machines.
Key points of interest for instrumentation typically include the following:
- New logic circuits, including IP blocks provided from 3rd parties.
- Analog-to-digital boundaries.
- Key state machines.
- Complex and shared resources such as interfaces and arbiters.
- Chronic problem areas such as power control, reset logic, and mode switching.
- Common trouble spots such as clock domain crossings, interacting state machines, hardware pipelining, and caching.
- Key circuits that are invisible to software-visible registers.
With a thorough understanding of the design and the validation requirements, developing an instrumentation plan is straight-forward. Such plans are developed with designers (hardware and software), integrators, and key architects, taking into consideration clock domains, the reset system, design hierarchy, power domains, control logic, and the physical floor plan.
5. How much silicon area on my chip does your instrumentation consume?
Instrumentation investment (or area) is user-defined. A typical instrumentation solution on a 5M gate design might realize an instrumentation investment of 2 to 4 percent.
The instruments are parameterized, compact devices that are reprogrammable in silicon, and therefore can be used for a variety of applications, thus minimizing the total instrumentation investment.
6. How much time do I need to allocate in my project schedule for instrumentation?
Basic instrumentation can generally be achieved in a matter of hours. ClearBlue Instrumentation Studio wizards can perform automatic probe-point extraction and instrument generation. These wizards use default or user-specified parameters.
Complex strategies involving major interfaces and buses, control signals, FSMs, and new or third-party IP can typically be implemented in a matter of a day or two, but they are often developed and refined in parallel with RTL code development. DAFCA application engineers are available to help with defining your instrumentation plan and inserting the instruments.
7. What languages are supported for instrument insertion?
ClearBlue 2007.2 supports Verilog, VHDL, or a combination of both. The language of the instrument will match that of the module in which it is inserted.
8. How does ClearBlue deal with designs that have multiple clock domains?
Clock-domain handling is entirely under the user’s control. Analysis can be done on a clock-domain basis, with analysis instruments operating at the same frequency as the signals being analyzed. ClearBlue also supports signals that cross one or more clock-domains.
Signals from multiple clock-domains can be fed into a multiplexer network that contains pipeline resisters, synchronizing registers, and/or FIFOs for buffering the signals. The network is constructed with signals from lower frequency domains fed through higher frequency domains, such that FIFOs may under-run but not overflow.
The signals are typically connected to analysis instruments that operate at a clock frequency equal to the highest frequency clock-domain feeding the network.
The number and location of analysis instruments, as well as the composition of each signal network, are entirely under user control such that clock-domain crossings can be minimized or maximized depending on post-silicon application needs.
9. How do I control the instruments after my device is in the lab?
Each instrument on the chip has a control GUI in ClearBlue SVStudio that enables you to manipulate the instrument. Through the control GUI, you configure the appropriate instruments, initiate an operation, and monitor the status. These tasks can also be automated.
ClearBlue communicates with the on-chip instruments via a standard JTAG interface (IEEE 1149.1), allowing for efficient use of an existing TAP (Test Access Port) controller and chip I/O.
10. What kind of validation and debug tasks are best addressed by ClearBlue?
A partial list of typical applications include:
- On chip logic analysis using trigger and trace capture.
- Protocol and transaction validation using at-speed, on-chip stimulus and trace capture.
- Analysis and debug of unexpected behavior in silicon.
- Performance monitoring.
- Scan-based debug tasks.
- Fault injection to monitor the behavior of the system in the presence of faults and its ability to recover.
- Implementation of triggers and assertions for “soak testing” in order to identify problems that may appear after the system has been running at a high activity level for an extended period of time in environmentally stressful conditions.
11. How can ClearBlue help with my embedded processor and subsystem validation?
ClearBlue provides systematic and automated transaction- and bit-level observability for the embedded processor and bus, as well as for the entire SoC/ASIC. This is especially useful when validating the operation of complex and shared resources, multi-core systems, heavily utilized buses, and sophisticated queuing systems. Moreover, ClearBlue provides transaction stimulus capabilities that enables rapid validation and certification of complex logic and IP blocks.
ClearBlue instrumentation is not constrained to any particular processor core, architecture or technology.
12. How do I verify that the instrumented design works correctly prior to RTL sign-off?
There are generally three components of a complete verification scheme:
- Verification that the instrumentation process didn’t change the original function of the design
- Verification that the basic instrumentation connections are correct and that all registers can be access properly
- Verification that the instrumentation is appropriate for carrying out desired functionality, and that it is operating correctly
To verify that the original user functionality was not changed, ClearBlue generates equivalency-checking scripts (both Formality and Conformal) to compare the original design to the instrumented design, with the instrumentation “off” to allow formal verification that the design function is unchanged.
To verify that the basic instrumentation connectivity is correct, ClearBlue generates a small simulation testbench that checks intra-instrument connections and key user-to-instrument connections.
To verify that the instrumentation is operating correctly in a comprehensive manner, you use ClearBlue SVStudio to exercise all on-chip instrumentation via the JTAG interface pre-silicon. SVStudio communicates with a simulator via the ClearBlue Sim-Bridge (socket/PLI), or with an FPGA target via a JTAG cable, or with an emulator (e.g., Cadence Palladium) via a JTAG cable.
Most users employ one or more of the above schemes to create validation and test scenarios in Tcl so they can control, observe, and transfer information from the system-level testbench to the instrumented pre-silicon RTL model. You can use these same configurations to create and verify “ready-to-go” data acquisition, silicon validation, and assertion and performance monitoring scripts to be used when the first silicon becomes available.
|
