Synthesizable System Verilog Model For Hardware Metastability In Formal Verification

Ahmed Ismail, Haytham Saafan Design Verification Technology

Mentor Graphics Egypt Cairo, Egypt

{ahmed_ismail,haytham_shoukry}@mentor.com

Abstract— In this work, we present a formal analysis method that incorporates a standard hardware and property description language, System Verilog, and information from clock domains analysis to detect circuits that do not tolerate hardware metastability effect. We provide a case study to prove the feasibility and usefulness of the approach.

Keywords— metastability, clock domains, formal, verification, assertions, properties

I. INTRODUCTION Functional verification is a critical element in the

development of today’s complex digital designs. Up to 70 percent of the design development time and resources are spent on functional verification. Functional bugs are still the number one cause of silicon re-spins. There are hard-to-verify structures for which traditional simulation based verification is inefficient and for which formal verification is a better approach [1].

Formal verification, as one component of the assertion based functional verification process, mathematically proves that a design property holds for all points of the search space. It comes in complement to simulation such that it needs no test bench or stimulus to operate, only the design intent (or specifications) described as properties (assertions, assumptions and cover statements) along with the design written in hardware description language are passed to the formal verification tool and assertions are examined whether they are proven to hold or found to falsify during the formal analysis session such that the given assumptions are satisfied.

Formal verification is to explore the correctness of digital designs against the specifications expressed as mathematical models. A model can be sets of states, sequences of events or an infinite domain with relations. One methodology on which formal verification is based is the Model Checking, where the design is given as automata and the specifications are given as temporal logic formulas, and it’s required to check if all computations of a given design description satisfy a given specification formula [2]. Various variants of temporal logic formulas are available such as Linear Temporal Logic (LTL) and Computation Tree Logic (CTL). Variations of model checking are Bounded Model Checking and Symbolic Model Checking [3], [4].

A property is a codified statement about the intended behavior of a part of the design logic. An asserted property is a property that’s expected to be always true; formal analysis is the process of proving that expectation, or finding a legal DUT stimulus (counterexample) that violates the asserted property. An assumed property should be satisfied during the whole formal analysis session. In formal verification assumptions can be useful to:

1) constrain the design primary inputs and pseudo-inputs to take only legal values, pseudo-inputs could be:

a) outputs of blackboxed design units (those that the formal compiler does not analyze)

b) user specified cutpoints (where the user decides to throw away some circuit logic to simplify the problem for formal analysis)

2) specify complex design resetting or initialization sequences

3) assure assumptions taken from design specification document.

For formal tool to work the user is often required to supply information about the clocks in the design, their periods and waveforms; also the clock domains which design inputs are synchronous to.

The verification layer is added onto the design under verification as separate modules or verification units, and gets bound to the design during the verification phase. In System Verilog, this is done using the ‘bind’ construct, with which the verification layer modules can be bound to design modules and/or instances.

A design that passes the formal verification with all the assertion proven is not guaranteed to function correctly in silicon, because when the assertions are proven in formal verification, they are proven in absence of silicon metastability effect. And when the design goes on silicon, the design intent could be violated because of a register settling on an incorrect value. The silicon metastability effect is introduced in silicon because of setup and hold time violations which are not detected in the normal formal run.

All the registers in the design have setup and hold time constraints specified according to the technology used. Ideally,

978-1-4673-6195-8/13/$31.00 ©2013 IEEE

the input of the register should remain stable for at least the setup time and the hold time before and after the active edge of the clock respectively to make sure that the input value is sampled correctly at the active edge of the clock. The metastability window is defined as the time period where the register input should be kept stable, so it is the summation of the setup and hold times.

A clock domain crossing (CDC) signal is generated by a certain clock and gets sampled by registers in another clock domain that’s often asynchronous to the transmitting clock domain. In this case there is no guarantee that the setup and hold times constraints of the receiving registers are not violated. Therefore, the registers at the CDC boundaries are more susceptible to the metastability window violation. When the registers are metastable, due to input data changes in the metastability window, they may have unpredictable behaviors. Receiving registers in that case may settle to 0 or 1 as shown in fig. 1.

Verifying the functional behavior of the circuits, that have clock domain crossings, with the regular simulation or formal verification methods without taking into account the unpredictable behavior when the metastability window constraint is violated may result in missing issues that may appear on silicon. This mismatch in the behavior between the design behavior in simulation and formal verification methods, and the design behavior on silicon is illustrated in fig. 2. The simulation behavior is always predictable; the value at the input of the register at the active edge of the clock is always propagated to the register output. Unfortunately, this is not always the case on silicon where due to the metastability effect the register may obtain unpredictable values. In fig. 2 (a) the register input data’s change within the setup time is caught by simulation, so the new value of q is 1. The behavior on silicon is unpredictable since the setup time is violated, and the signal q may have different value from simulation as in the wrong-q signal on the time diagram. While in fig. 2 (b) the register input data’s change within the hold time is missed in simulation, while it may be caught in silicon (see the signal wrong-q) due to the metastable behavior of the register.

Synchronizers are needed for the clock domain crossing signals to decrease the failure rate caused by metastability at the receiving register. A simple form of a synchronizer is the two-Dff synchronizer which is built of two registers that are clocked by the receiving clock domain and connected to each other as in fig. 3. When the synchronizer is used, the

metastable value is not propagated to the circuit, and the metastable value settles before it appears at the output of the synchronizer. This does not solve the metastability problem completely because in this case the number of the cycles needed before the new value appears at the synchronizer output is unknown. For the example in fig. 2 (a) if the q value is the correct-q, then the new value will appear at the output of the synchronizer after one cycle delay. However, if the q value is the wrong-q, the new value will appear at the output of the synchronizer after two clock cycles from the instant when the input data of the receiving register changed. So the uncertainty in the value of the metastable register is converted to uncertainty in the delay cycles after the synchronizer is used. Thus metastability still can produce unpredictable behavior in the circuit with presence of synchronizers and may cause the circuit to operate wrongly, and it’s the designers’ responsibility to build a circuit that tolerates this metastability effect.

In this paper, we propose an approach to incorporate the knowledge of clock domains analysis and hardware metastability effect into the assertion based formal verification flow. And this approach helps increase the reliability of formal

clk

s

correct-q

wrong-q

q (sim)

(a)

clk

s

correct-q

wrong-q

q (sim)

(b)

Fig. 2. The uncertainty in the silicon behavior for (a) setup time violation and (b) hold time violation

TX Clock Domain RX Clock Domain

tx_clk

tx_sig

rx_clk

rx_sig

Two DFF Synchronizer

Fig. 3. Two DFF Synchronizer

s

q

R

q s

clk

clk

Fig. 1. Metastability effect on the register q

verification techniques leading to quicker time to market for systems on chip.

The rest of the paper is organized as follows. Section II describes the related work in modeling metastability effect in simulation and formal verification. Section III discusses the flow of the proposed approach for assertion based formal verification in presence of metastability effect, and is followed by an illustration for the proposed model for injecting metastability effect in formal analysis in section IV. In section V we apply the proposed approach on a benchmark example. Section VI includes the paper conclusion and the future work.

II. RELATED WORK There are different methods for modeling the metastability

effect in the circuit in simulation [5]. Some of those methods require modifications in the circuit design to replace the cells in the design with other cells with variable delays in the clock or the data paths to model the metastability effect. Other methods do not require any change in the design where the metastability effects are applied from outside the design. One of the methods used is to apply random clock jitters for the clocks from inside the testbench. Another method for metastability effects modeling is done by forcing a different value in simulation run when the metastability window is violated [6], [7].

Metastability modeling in formal is discussed in [7] where a transformation is proposed for the circuit such that the register at the CDC boundary is replaced by a circuit containing a multiplexer and a register, where the inputs of the multiplexer are the register input in the original circuit and its inverse. The multiplexer select signal is controlled by three signals; the first signal “is_changing” detects when the transmitting data is changing, the second signal “in_phase” detects when the transmitting and receiving clocks are close enough to each other to permit metastability to occur, and the third signal is a pseudo-primary input that controls whether or not to insert the metastability effect.

The method described in this paper does not involve a direct transformation for the circuit like the one described in [7], but instead we pass the information to the formal tool to cut away the logic driving the metastable register and drive the register from a module that is bound to the design. The model that we introduce is a simple synthesizable model that uses SV sampled functions to detect the metastability condition, and adds a clock to mimic the metastability window; in the related work the calculation of the clocks relationship and the setup/hold time violation was not clear, and we assume that such calculation was done offline or with using simulation trace. The model details are described in section IV.

III. PROPOSED APPROACH In this section we introduce the approach for applying the

metastability effect in the formal analysis run, the metastability effect is only applied in the formal run if all the targets are proven in the normal formal run.

The first step in the approach is to run the formal analysis tool on the design assertions, check the violations (counterexamples) – if any – of the targeted properties, and fix

the design or properties accordingly, until all the formal targets are proven.

The clock domain crossing analysis is done after that to extract the transmitting/receiving pairs for the clock domain crossings. The second formal analysis run is done after applying the metastability injector model on every receiving register that is also in the cone of influence of the formal targets. The formal compiler tool cuts away all the logic driving the receiving register, basically all the logic behind the q pin of the register and the register is driven from inside the metastability injector model. And for each one of the receiving clocks, upon the clock specification provided by the user (i.e. clock period and setup/hold times), the metastability window is calculated and constructed as a formal clock. Formal analysis is then run on the design with the System Verilog metastability injector model bound to it. Counterexamples indicate parts of the design that are not tolerable to hardware metastability effect.

Below is a pseudo-code describing the proposed approach for injecting the metastability effect in formal analysis. compile the design (DUT) and properties read in the user specified clocks in the form <clk , period , waveform> run formal analysis (on a user list of targeted assertions; default: run all assertions) if ( there exists a fired assertion ) { print “The given assertions should be proven to apply the approach.” quit } detect and extract the asynchronous clock domains detect and store the domain crossing signals in the form < tx_sig , rx_sig > // filter the crossings based on assertions for each assertion Asrt { for each crossing cdc { if ( cdc.rx_sig in sequential fanin of Asrt ) { save cdc in cdc_array } } } // Write the metastability injector code for each crossing cdc in cdc_array { i = 0 // infer the D-pin expression of the cdc.rx_sig rx_sig_d_expr = get_d_pin_expression(cdc.rx_sig) // Construct metastability window (setup & hold are percentages of rx_clk.period) cdc.rx_clk_msw.period = cdc.rx_clk.period rise = cdc.rx_clk.waveform.rise – (setup * cdc.rx_clk.period) fall = cdc.rx_clk.waveform.rise + (hold * cdc.rx_clk.period) cdc.rx_clk_msw.waveform = { rise , fall } cut_away_all_logic_in_fanin(cdc.rx_sig) // Write out SV bind statement write_to_file( “bind DUT ms_injector ms_inj_i_ (cdc.tx_sig , cdc.rx_clk , rx_sig_d_expr , cdc.rx_sig)” ) i = i + 1 } write the metastability injector SV module ms_injector to a file compile the inferred SV module and bind statements run formal analysis report results review the firings after applying the approach // any firing is a bug due to metastability that is missed by normal formal verification

IV. PROPOSED METASTABILITY INJECTOR MODEL The metastability effect that causes mismatches in the

behavior between the silicon and the formal verification tool occurs only when the register input changes in the metastability window of the register. On silicon, when the register is metastable it may settle to either 0 or 1 so it may have a value different from the simulation or formal verification value. Applying the metastability effect in formal verification run

requires injecting the uncertainty behavior on the metastable register value. The metastability model should do the following two main functions to work correctly in formal verification run: detect when the register is metastable, and inject the metastability effect on the metastable register.

Detecting when the register is metastable in our model is done in two steps, first we identify the metastability period where the register input is expected to remain unchanged. The metastability period is specified for the formal tool as a clock with a period similar to that of the receiving clock and with a waveform such that the positive and negative edges of that clock represent the start and the end of the receiving clock metastability window respectively; we will refer to this signal as the metastability window clock. The model depends on the use of the System Verilog construct $global_clock. For formal verification this represents all the significant clock edges of all the system clocks. So specifying the metastability window as a clock will guarantee that the start and the end of the metastability window are sampled in the $global_clock and the System Verilog sampled value functions events [8] that we are using in the model. Second, the model detects the data changes in the metastability period (i.e. when the metastability window clock is high) using the sampled value functions, this is a straight forward step since the metastability window clock is affecting the $global_clock, so checking for the data stability at the $global_clock edges is sufficient to detect whether metastability window is violated or not. Once a metastability window violation is detected, the signal tx_data_changing_in_rx_msw is raised and is kept high until the rising edge of the receiving clock next cycle for setup time violation or until the end of the receiving clock cycle in case of hold violation.

The Second function for the metastability model is to inject the metastability effect in the formal run when the register is metastable. In our model the metastability injection is not done explicitly when the register is metastable by forcing a value different from the one that would have been obtained in the normal formal run. Instead when the model detects that the register is metastable the formal tool is allowed to freely control the register to violate any of the targeted assertions. Since the metastable register may have an unknown value independent on the input of the register, then any value applied by the formal tool to control this register should be a valid value. The RTL logic driving the receiving register is cut away in the formal netlist and so the receiving register is controlled from inside the model by a System Verilog assumption. The assumption controls the register to have the normal register behavior when the register input data is stable in the metastability window. While when the metastability window constraint is violated, the assumption is disabled and the register is left for the formal engine to control its value arbitrarily. The signal tx_data_changing_in_rx_msw provides the information of the metastability violations and is used to enable and disable that assumption. By this way the formal engine benefits from the uncertainty in the value of the metastable register attempting to falsify the targeted assertions. If formal failed to find counterexamples, then the tested functional property of the design is immune to the metastablity effects. This model can be applied also on the multi-bits signals

by binding an instance of the model to each bit of the signal; in this case each bit is controlled separately according to the corresponding input bit changes.

Fig. 4 is an example of a circuit with two clock domains and a signal crossing from the TX domain to the RX domain, and a formal target having that RX register in its cone of influence. In fig. 5, the same circuit is shown with the metastability modeling layer added on top of it.

In fig. 6, a legal stimulus is shown such that the assertion fires because the input on the receiving flip-flop rx_reg changes inside the metastability window of the receiving clock rx_clk. Consequently the formal tool chooses an arbitrary value to set on the output of rx_reg to violate the assertion.

V. CASE STUDY The approach proposed in this paper has been applied to a

FF

Tx Clk

FF

Rx Clk

combo logic

Tx Data

Proven formal target

TX DomainRX Domain

Fig. 4. Circuit with two asynchronous clock domains

FF

Tx Clk

FF

Rx Clk

ccombologic

pseudo primary input 1

0SV Assumption

is Tx Data changing inside the RX Metastability

Window?

cut away

Tx Data

Violation of formal target

TX DomainRX Domain

Fig. 5. The metastability injector model hooked up onto the original circuit

rx_clk

rx_clk_msw

Input of rx_reg

Output of rx_reg

Output of rx_reg(w/o metastability)

The value of rx_reg input changed within the metastability window of rx_clk → rx_regoutput is controlled by the formal engine Assertion violated

Metastability window of the receiving clock

Fig. 6. Firing waveform indicating assertion violation due to metastability effect

TABLE I. DESIGN TECHNICAL DATA

Metric Value Number of asynchronous clock domains 8 Number of registers/latches 531 Primary inputs 27 Primary outputs 5 Number of CDC Signals 180 Number of Assertions 57 Type of Assertions SVA

TABLE II. IMPACT OF THE PROPOSED MODEL ON THE FORMAL

VERIFICATION RUN

Formal Run Formal Run with MS Injection

Formal Targets 57 57 Formal Assumptions 0 75 Proven Targets 57 56 Design Logic Gates 1624 14681 Design Register/Latch bitsa 393 3213 Property Logic Gates 575 1026 Property Register/Latch bits 7 9 CPU Time (sec) 7 65 Memory (MB) 1086 2111

a. Numbers of registers/latches are only those affected by or affecting the formal properties.

design from InventraTM Soft Core Library [9], M8254 Timer Controller MegaMacro(R) Design, to verify the correctness of the model and to show how the metastability effect could corrupt the design functionality. The design is written in VHDL; while the assertions are in System Verilog. Assertions have been generated automatically from the simulation trace using Mentor Graphics Assertion Generation tool, while a few assertions have been specified manually by the authors of the paper. Table I, shows some technical data about the design.

During the experiments on this design, normal simulation with metastability injection, using Mentor Graphics Questa CDC and QuestaSim [10], has been run with the test bench and test vectors provided by Inventra. None of the assertions fired during simulation. Typically the verification engineer would have to change the test vectors to make sure that the specified functionality will never be violated on hardware, although this cannot be 100% guaranteed. Here comes the power of formal verification techniques, and with our proposed solution, Questa Formal tool [10] could find a legal stimulus and scenario violating one of the design properties, that is proven valid in lack of the hardware metastability effects.

Following is the SV assertion:

Normal_FF : assert property (

@ ( posedge nwr ) disable iff ( !nclr )

!stat_wr |=> alat_swr == $past(aswsync2) );

The counterexample waveform produced from the formal tool after metastability injection using the proposed solution is shown in fig. 7. The signals (in same order appearing in the waveform) are:

• nclr : Active low reset signal

• tx_clk : the transmitting clock

• nwr : the receiving clock

• rx_clk_msw : when high it signals the metastability window of the receiving clock. Setup and hold times are defined as 25% and 10% of the receiving clock period respectively

• aswsync2 : the transmitting signal

• alat_swr : the receiving register

• stat_wr : the receiving register write enable signal

Table II, shows the impact of the proposed model on the formal verification run. The part of the circuit impacted by the metastability effect is a flip-flop clocked by the rising edge of “nwr”. The receiving signal is driven by an asynchronous signal “aswsync2”. In regular formal analysis the specified property “Normal_FF” holds true all the time, however it could be violated if the transmitting signal “aswsync2” changes during the metastability window of the receiving clock at 595ns on the waveform of fig. 7, in that case the flip-flop output (i.e. the signal “alat_swr”) settles to an arbitrary value chosen by the formal tool that happens to be different from the past value of the data input of the receiving flip-flop (i.e. the signal “aswsync2” in this case). And this is what’s shown in the firing waveform.

No comparison with the related work in [7] was done because the paper did not provide enough information on the proposed model, the timing calculations and results of applying that model on a real design.

VI. CONCLUSION AND FUTURE WORK Formal verification techniques help find bugs that are

difficult for simulation based verification techniques to find. But normally they lack the knowledge of hardware metastability effect. With the proposed approach, errors due to silicon unpredictable behavior are considered in assertion based formal verification. And so, formally proven asserted properties, with the proposed model, will not be violated when the design is on silicon.

As it’s obvious in the case study, the proposed metastability injector model has a significant overhead on the design combinational and sequential logic. The main reason for this is that the model is instantiated for each and every single bit of TX-RX crossing contributing to a formal target. Consequently

Metastability window of the receiving clock

Assertion is violatedalat_swr != $past(aswsync2)

Fig. 7. Waveform of assertion violation due to metastability effect

the part of the model that determines when the data input of the receiving flop is changing in the metastability window of the receiving clock is redundant for all crossings ending at registers clocked by the same receiving clock. So we can study a way to share this logic among crossings having the same receiving clock.

REFERENCES [1] Yeung, P.; Larsen, K.; , "Practical Assertion-based Formal Verification

for SoC Designs," System-on-Chip, 2005. Proceedings. 2005 International Symposium on , 17 Nov. 2005

[2] Wang, F.; , "Formal verification of timed systems: a survey and perspective," Proceedings of the IEEE , vol.92, no.8, pp. 1283- 1305, Aug. 2004

[3] Veanes, M., Bjørner, N., Gurevich, Y., & Schulte, W.; , "Symbolic Bounded Model Checking of Abstract State Machines," Int J Software Informatics, 2009, pp. 149-170

[4] Biere, A.; Cimatti, A.; Clarke, E.M.; Fujita, M.; Zhu, Y.; , "Symbolic model checking using SAT procedures instead of BDDs," Design Automation Conference, 1999. Proceedings. 36th , vol., no., pp.317-320, 1999

[5] Kwok, C.; Sabbagh, R.; , "A Comparison of Metastability Modeling Methods," White Paper, http://www.mentor.com/products/fv/techpubs.

[6] Ly, T. A., Kwok, K. K., Gupta, V. V., & Widdoes, L. C.; , "Metastability effects Simulation For A Circuit Description," Patent Pub. No.: US 2010/0287524

[7] Ly, T., Hand, N., Kwok, C. K. K.; ,"Formally Verifying Clock Domain Crossing Jitter Using Assertion Based Verification," Design and Verification Conference Proceedings 2004

[8] IEEE Standard for System Verilog – Unified Hardware Design, Specification and Verification Language, IEEE 1800 – 2009

[9] INVENTRA MacroWare Cores User Guide. 02/98 MWUG-40062.004-FC, Copyright 1996-1998, Mentor Graphics Corporation.

[10] Mentor Graphics Functional Verification Solutions, http://www.mentor.com/products/fv

APPENDIX System Verilog code for the proposed metastability effect

injector model in assertion based formal verification. // tx_data : Transmitting signal // tx_expr : The signal connected to the receiving register d pin // rx_clk : receiving clock

// rx_reg : receiving register // rx_areset : receiving register asynchronous reset // rx_async_data : receiving register asynchronous data module ms_injector (input tx_data, rx_clk, tx_expr, rx_reg, rx_areset, rx_async_data); logic tx_data_changing_in_rx_msw ; check_rx_metastable crm (tx_data , tx_expr , rx_clk , tx_data_changing_in_rx_msw ); assume property ( @($global_clock) if ( rx_areset ) rx_reg === rx_async_data else !tx_data_changing_in_rx_msw |-> (rx_reg === $past(tx_expr,,,@(posedge rx_clk))) ); endmodule

module check_rx_metastable ( input logic tx_data , tx_expr , input rx_clk , output logic tx_data_changing_in_rx_msw ); logic tx_data_changing_in_rx_msw_comb ; logic tx_data_changing_in_rx_prev_clock ; int tx_data_changing_in_rx_msw_count ; logic rx_clk_msw ; // Initialize the counter at the beginning of the m/s window and start counting for any change in tx_data (which affects tx_expr) until the end of the m/s window always_ff @ ( $global_clock ) if ($rose_gclk(rx_clk_msw)) tx_data_changing_in_rx_msw_count <= 0 ; else if ( (rx_clk_msw && !$rose_gclk(rx_clk_msw)) || ($fell_gclk(rx_clk_msw)) ) tx_data_changing_in_rx_msw_count <= ($changed_gclk(tx_data) && $changed_gclk(tx_expr)) + tx_data_changing_in_rx_msw_count ; // Using tx_data_changing_in_rx_prev_clock to keep the m/s information until the rx_clk edge, since the signal tx_data_changing_in_rx_msw_count is initialized at the beginning of the m/s window always_ff @ ( $global_clock ) if ($rose_gclk(rx_clk_msw)) tx_data_changing_in_rx_prev_clock <= tx_data_changing_in_rx_msw_count > 0 ; else if ($rose_gclk(rx_clk)) tx_data_changing_in_rx_prev_clock <= 0; // Combinational signal for instantaneous detection for the m/s period violation always_comb if ( rx_clk_msw && !$rose_gclk(rx_clk_msw) ) tx_data_changing_in_rx_msw_comb = $changed_gclk(tx_data) && $changed_gclk(tx_expr) ; else tx_data_changing_in_rx_msw_comb = 0 ; // The tx_data_changing_in_rx_msw signal is calculated from the three signals tx_data_changing_in_rx_msw_count, tx_data_changing_in_rx_msw_comb and tx_data_changing_in_rx_prev_clock assign tx_data_changing_in_rx_msw = tx_data_changing_in_rx_msw_count > 0 || tx_data_changing_in_rx_msw_comb || tx_data_changing_in_rx_prev_clock ; endmodule