With design complexity increasing significantly

Transcription

1 With design complexity increasing significantly over the years, the verification of asynchronous designs has become one of the biggest challenges in modern systems-on-a-chip (SoCs). Functional simulation, linting, and other traditional verification methods have proven to be inadequate when it comes to accurately and exhaustively verifying asynchronous designs. These verification methods are manual, error-prone, and partial. The problem is that they rely on the designer s or verification engineer s capability to accurately comprehend the architectural specification and verify all of the possible complex scenarios that can occur in the design. Asynchronous design challenges have proven particularly hard to verify using traditional verification methods. Such methods include modeling non-deterministic behavior in asynchronous clock-domain crossings (CDCs), modeling phase and frequency jitter accurately, datapath verification, low-power designs with complex clocking, and more. If these complex and hard-to-identify asynchronous design issues aren t detected and verified early on, they can potentially lead to re-spins. The costs associated with them are enormous. Formal verification is an ideal candidate for verifying tough SoC design challenges. It can exhaustively verify all possible complex scenarios without any need for a testbench or input stimulus. With formal verification, a designer or verification engineer doesn t have to spend time simulating all possible scenarios. The formal engines carry out this task under the hood, which results in increased confidence. This approach eliminates the uncertainty of not verifying a scenario that s either difficult to think of or is missed due to design complexity. Examples of Asynchronous Designs PHY and other mixed-signal blocks: A physical-layer (PHY) block deals with unpredictable inputs due to noise from the analog line and the asynchronous timing associated with the inputs possibly resulting in deadlock situations. Following are some of the issues associated with verifying a PHY block and other mixed-signal designs: by Carlo Del Giglio and Alok Sanghavi, Jasper Design Automation Formal Verification Solves Asynchronous Design Challenges New solutions reduce dependence on functional simulation and provide increased confidenc Verifying droppage of a packet when a cyclicredundancy-check (CRC) error occurs, duplication of packets (multi-cast packet in which one packet is duplicated in multiple output ports), or reordering of packets whereby high-priority packets will be reordered in front of a low-priority packet. Verifying asymmetrical input and output ports (for example, ports with different data and address widths, one input packet broken into multiple output packets, multiple input packets combined into a single or fewer packets at the output, different clock domains between input and output ports, standard protocols, etc.). Verifying different input to output delays. For example, many configurations of fixed delays may exist as well as a range of variable delays. Low-power designs with complex clocking: The number of power domains and different power modes in a design is constantly increasing. Low-power verification requires designers to exhaustively verify power-up/down sequences, proper state-saving and restoring steps, and data integrity during state changes. This requirement prevents power problems that are both structural (demanding respin) and temporal (violating the power specification and possibly requiring respin). Clock-tree optimization and clock gating with possible asynchronous clock-domain crossing are typical in lowerpower architectures. After all, clock trees are a large source of dynamic power. Typically, simulation cannot be relied upon for the detection of functional errors due to the tricky timing required to trigger frequency and phase jitter. Clock frequency scaling introduces the possibility of issues in the clock-domain crossing, whereas power gating introduces undriven signals and loss of state. 28 June / July 2010 Chip Design

2 Failures can happen when clock gating is implemented incorrectly. For example, designers may have implemented a power-saving scheme by which the clock is stopped in the middle of a pipeline computation due to invalid data (see Figure 1). If the data isn t flushed out before the computation resumes, the wrong data in the pipeline can result in functional failures. Understanding and modeling clock and phase jitter will help in verifying such failures. In this example, the clock could be stopped when the data is in stage 2. Clock restoration without considering the holdtime of stage 2 could result in data corruption. Frequency Jitter Because synchronous clocks aren t frequency locked, frequency will fluctuate between the clocks. Frequency or cycle-to-cycle jitter is the difference in length of any two adjacent clock periods (see Figure 3). It can be important for certain types of clock-generation circuits that are used in microprocessors and random-access-memory (RAM) interfaces. clk1 ESL clk2 1:2 2:3 Figure 3: Frequency jitter is the difference in length between any two adjacent clock periods Figure 1: This low-power design leverages complex clocking. Asynchronous Design Challenges One of the main problems with asynchronous clocks is that their relationships are usually fixed. In the real world, however, the relationship is uncertain. This uncertainty requires correct modeling. If two asynchronous clocks are typically the exact same frequency in simulation and formal, for example, their edges will always be lined up. They may be skewed by an edge, but that doesn t really help to address the problem. In the real world, the relationship of the edges between the two domains is uncertain. So the added challenge in verification is to generate all of the relationships and model the effects of those relationships. Phase Jitter Phase or period jitter is the difference between any one clock period and the ideal clock period (see Figure 2). It tends to be important in synchronous circuits, where the error-free operation of the circuitry is limited by the shortest possible clock period. In addition, the circuitry s performance is limited by the average clock period. Hence, synchronous circuits benefit from minimizing period jitter so that the shortest clock period approaches the average clock period. clk1 clk2 Figure 2: Phase jitter is the difference between any one clock period and the ideal clock period Data Loss and Data Incoherency To prevent data loss from one clock domain to the other in synchronous clock circuits, data should be held constant in the source domain long enough to be properly captured in the destination domain. To hold data constant, setup and hold requirements should be met. For asynchronous clock circuits, handshake or FIFO techniques can be used to prevent data loss. When crossing from one clock domain to the other if the signals change values and the source and destination clock edges arrive close together signals seem to be captured in the destination domain at different clock cycles. This occurs because of metastability and can result in an invalid combination of signal values at the destination side. The challenge with an asynchronous clock-domain crossing is that the phase difference between the asynchronous clocks can be quite unpredictable, resulting in metastability. Current Solutions and Drawbacks Functional simulation techniques have proven to be inadequate in accurately verifying complex clock-domain crossing issues, such as FIFO and handshake-based synchronization mechanisms. It s extremely difficult to stimulate all of the possible input scenarios and the inherent uncertainty of how registers operate when data changes during the setup and hold times. Simulation isn t fully exhaustive. With simulation, for example, one can model glitches. But the designer cannot stimulate all of the possible interactions or scenarios between the normal logic and the glitches that he or she is Chip Design June / July

3 trying to inject. Clock-domain crossing checkers or linters only partially address this problem. Often, they contain too much noise (reporting thousands of warnings) and may overlook real warnings, resulting in improperly waived CDC violations. Traditional formal property check tools normally model the verification environment as if all events are synchronous. As a result, potential bugs stemming from events like glitches or metastability on clock-domain crossings can be missed. It s very difficult to model the effects of non-determinism on asynchronous CDCs. In addition, error conditions resulting from the incorrect encoding of buses crossing a CDC can be missed. For example, when the incoming bus values aren t Gray encoded (that is, more than one bit changes per clock cycle), bus values on the target clock domain might appear to be incorrect. This scenario occurs because of the nondeterministic sampling of the individual bits of the bus. Data integrity and data loss verification: Data-transport verification problems exist in many design applications today. Their shortcomings include the following: Verification only occurs on the supplied vectors, which creates the potential for data corruption or dropped data packets. Simulation data-transport verification typically runs at the system level with poor low-level input controllability. The higher the level of the testbench, the more complicated it is to generate specific data patterns at block-level inputs. This challenge becomes even bigger when crossing clock domains and dealing with metastability problems. The Scoreboard PA addresses this problem with built-in checkers to enable the verification of input/output datatransport behavior (see Figure 4). The push-button nature of CDC checkers has proven to be inadequate in verifying complex CDC challenges. It also has escalated the need to have formal verification exhaustively verify the non-deterministic behavior in asynchronous CDCs. DATA_IN source_clk clock domain crossing destination_clk DATA_OUT An Advanced Formal-Verification Approach Modeling non-deterministic behavior in asynchronous designs: Advanced formal-verification tools can prove the functional correctness of asynchronous circuits. Proof accelerators (PAs) are production-proven models that exist for many common components, such as FIFOs, memories, and data-transport components. These models greatly reduce the verification property coding effort. One PA example is the Asynchronous CDC PA, which makes it possible to achieve exhaustive verification of properties for all possible outcomes of non-determinism on CDCs. In addition, it s possible to model frequency and phase jitter in the formal model, which represents the design being verified. Modeling effects of frequency jitter: The frequency-jitter PA can be used to model the effects of frequency jitter when proving assertions in a design under verification (DUV), which includes multiple clock domains. Using this PA makes it possible for the ratio between fast and slow clocks to vary within a defined range instead of always being locked at the same value. glitch insertion SCOREBOARD Figure 4: With built-in checkers, the Scoreboard Proof Accelerator can enable the verification of input/output data transport behavior Proofpoints: Real-World Asynchronous Design Experiences Verification of a reset circuit to detect lock-up condition: In one case, a design would lock up due to improper CDC design. There was a reset circuit that would detect a lock-up condition and reset the block. Formal verification was used to ensure that the reset mechanism would work correctly by verifying that the reset triggers in a stuck condition. Using formal, a bug was found. One of the signals that were used to activate the reset condition didn t behave correctly under a certain corrupt state. As a result, the design couldn t recover to the reset state. Formal helped the designers find this critical bug in time. Otherwise, it could have proved disastrous and potentially caused a re-spin. 30 June / July 2010 Chip Design

4 Reset recovery mechanism verification: A property of interest was defined to check whether the reset mechanism would work. In this case, the reset mechanism was different than the one mentioned in the previous example. The user wanted to ensure that the reset sequence would work even if the circuit was in an unexpected state caused by glitches due to clock-domain crossing signals. The Scoreboard PA was used to verify end-to-end dataintegrity properties, which ensured that no address/datapropagation error would go undetected (see Figure 5). The address and data bit will be the same throughout both paths. The phase and frequency jitter PA was used to verify latency of the round-trip delay for all possible configurations, which is a critical concern for the PHY block. ESL With the help of formal, it was found that in a certain state, the clock would turn off. The reset procedure would then no longer work. This resulted in avoiding a potential deadlock situation, which could have proved fatal if it had been detected late in the design cycle. Even simulation wasn t able to detect this complex scenario. Formal verification was used to ensure that the reset state returns the state machine to idle state from any arbitrary state. As an added check, CDC check was done and the CDC waivers were verified using formal verification. It was then discovered that some waivers were incorrect. If the waivers hadn t been verified with formal verification, real clock-domain crossing issues would ve been overlooked. PHY verification of clock ratio and delay-mode configurations: An engineer had been working to set up the simulation environment. For two weeks, the engineer had been trying to verify different modes on a PHY design and was still not done. It was then decided to try formal on the same block. The formal environment was set up and running on day 2. Verification started on day 3. The PHY design contained many clock ratio configurations. The design was even more complicated, as data returned at the output port during read cycles could have different delays due to clock frequency jitter and routing delays. Consequently, there were more operational modes than it was possible to simulate. A corner-case problem was missed because one particular delay mode wasn t verified with one of the clock modes. Clock ratio configurations Variable delay Jasper Clock Generator DUT Jasper Scoreboard Concurrent verification of multiple clock ratios End-to-end data transport Concurrently verify all delay parameters Figure 6: Shown is the verification of all possible clock and delay modes Error Injection Jasper Asynchronous PA DUT Jasper Scoreboard Figure 5: Pictured is the Scoreboard and phase/frequency jitter proof accelerator (Source: Jasper Design Automation) Phase and Frequency Jitter End-to-end data transport for different clock domains, with considerations of error detection and correction (Source: Jasper Design Automation) The PA covered all frequency jitters while allowing multiple clock modes to be verified at the same time (see Figure 6). This resulted in avoiding violation of the protocol. The clocks and path delays were verified quickly. All of the verification tasks were completed in less than two weeks. Low-power verification of PMU and clock-gating logic Low-power designs combine all of the power-management functions within a single functional block, which is called the power-management unit (PMU). The PMU houses all of the control signals and the associated logic for sequencing and controlling the power domains. Different power domains typically run with different clocks as well. Chip Design June / July

5 The PMU must be verified for the proper generation of control signals and the various power sequences that result in reliable operating modes. Today, most designverification solutions check these signals when they become active within the design blocks. Because of the number of verification points in the design, this method led to long design-verification cycles. A better methodology is to model the uncertainty in the delay, which was accomplished by successfully modeling the frequency and phase jitter using the asynchronous CDC and frequency-jitter Proof Accelerators. Commonly used low-power techniques in any design are clock gating, power shut-down (power gating), and voltage scaling. Proper clock gating is necessary for data integrity. If the clock isn t shut down properly for a piece of logic, improper state signals and signal glitches can propagate and lead to data corruption. The asynchronous CDC PA was used to ensure that functionality was preserved in the clock gating logic that was responsible for the shutting down and powering up of the different power domains. Asynchronous designs and the challenges associated with them are a reality of today s complex SoCs especially lowpower designs. Advanced formal-verification solutions have emerged as the ideal choice for verifying such designs, as they don t require any input stimulus or testbench. In addition, such solutions can exhaustively verify all possible design scenarios. In summary, formal verification reduces the designer s dependence on functional simulation. It also maximizes user productivity and provides increased confidence by exhaustively verifying designs to reduce overall project risk. Carlo Del Giglio is a senior field applications engineer at Jasper Design Automation. He has more than five years of experience in formal verification. Prior to joining Jasper, Del Giglio was a field applications engineer at OneSpin Solutions. He holds a master s degree in electrical engineering from the University of Ancona, Italy. Alok Sanghavi is technical marketing manager for Jasper Design Automation. Prior to joining Jasper, he was in field applications engineering with Springsoft and Sonics Inc. Sanghavi was a senior ASIC engineer with AMD and hardware engineer with Interdigital Communications after teaching at New York s Polytechnic University. He holds a bachelor s degree in engineering from Sardar Patel University in India and a master of science degree from Polytechnic University, Brooklyn, New York. 32 June / July 2010 Chip Design