Planning for Verification

INTRODUCTION

Verification planning is most important part of verification, irrespective of the size of the design. Since, about 70% of the design cycle time is spent on verification, with proper verification planning some of the issues faced during the later stages of the design cycle can be easily avoided earlier. Verification planning is described as a set of goals that needs to be verified. A verification plan would consists of:

1. Functional requirements
2. Design requirements
3. Defining coverage goals and
4. Embedded firmware requirements
   

Apart from these requirements, the verification plan should also focus on reusable methodology.

SPECIFICATION

The specification is for capturing the requirements of the design. It is required to split the specification into Functional and Design requirements. Functional requirements can be defined as the behavior required by the system while the Design requirements is used to check the implementation of the function against the design specification. For verifying the design requirements, bottom-up verification approach can be adapted to reduce the effort spent on SOC level. The Design requirements need to be split into system-specific requirements and peripheral specific requirements . The peripheral-specific requirements are those which can be verified in module level. Examples of peripheral-specific requirements are

• Verifying all possible packet types for all HS/FS/LS for USB
  

• Verifying all possible baud rate for a UART
  

System specific requirements focus more on system level issues such as reset generation logic and clock generation logic can be completely verified only on system level.

Examples of system-specific requirements are

1. Verifying the system is properly reset for the different types of reset

2. Verifying the system for different types of power saving modes

3. Verifying the interconnectivity of clock

4. Verifying the connectivity to pads, interrupts, debug interfaces.

With this approach, the peripheral is verified completely in the module level. The SOC level verification could then focus more on top-level issues such as interconnectivity, interrupt system behavior (response of interrupt for that peripheral), bus interfaces, I/O interfaces. The system level verification could focus more on system level issues and speed up the overall verification process.

COVERAGE HOLES

It is good to have a complete coverage metric for all the peripherals, but this would mean additional overhead for simulators which would slow down the simulation speed drastically. There has always been a compromise for coverage against the simulation speed. Hence it becomes necessary to understand the complexity of the design before identifying the coverage points.

For SOC verification it would be good to have interconnectivity coverage, coverage for interrupts, system-specific behavior such as power saving features, recovery sequences, reset and clock (power saving features), and system buses.

EMBEDDED F/W REQUIREMENTS

An embedded firmware can be described as a piece of software embedded into the ROM/EPROM which would initialize the chip into a defined state on reset. This piece of software could contain Startup sequences, bootstrap loaders, memory test routines, tests for production etc. It can be seen that this software is very complex and the corresponding verification is a complex task. Unlike the verification of peripherals, firmware verification is restricted to SOC level which further increases the complexity of verification. So how do we ensure this piece of software works? For firmware verification, it is necessary to have a good coverage metric. During the verification planning phase, we need to identify all the coverage points with iterative process of review from the members involved in the development of concept and firmware. Normally the firmware verification plan is a list of coverage items that needs to be addressed in the process.

Figure shows the coverage points for firmware ( Thanks to http://www.us.design-reuse.com)

An example of Firmware code

If (HWCFG == “010”) then
MEM(status) = software_boot;
Software_start();
else if (HWCFG == “011”) then
MEM(status) = ext_boot;
Ext_start();
else
MEM(status) = int_boot;
Internal_boot();
end if;

The firmware code can then be translated to a flow chart which gives the verification engineer an overview of the software flow.

Conclusion

Verification plan gives an early estimate on effort, resource required, reuse percentage and coverage goals. Verification closure is an iterative process where the plan is measured against the implementation and coverage goals. Verification reuse can be achieved with proper planning, reusable verification environment and proper documentation.

VLSI FAQ

Hi All,
I am back with bank after my UCSD mid-term test. Today I am going to post some of the important verilog questions.

How to solve setup & Hold violations in the design?

To solve setup violation

• Optimizing / Restructuring Combinational logic between FFs.
  

• Tweak flops to offer lesser setup delay.
  

• Tweak launch-flop to have better slew at the clock pin, this will make CK->Q of launch flop to be fast there by helping fixing setup violations.
  

• Play with skew (Tweak clock network delay, slow-down clock to capturing flop and fasten the clock to launch-flop) (otherwise called as Useful-skews)

To solve Hold Violations

• Adding delay / buffer [as buffer offers lesser delay, we go for special Delay cells whose functionality Y=A, but with more delay]
  

• Also, one can add lockup-latches [in cases where the hold time requirement is very huge, basically to avoid data slip]

What is tie-high and tie-low cells and where it is used?

Tie-high and Tie-Low cells are used to connect the Gate of the transistor to either Power or Ground. In deep sub micron process, if the Gate is connected to Power / Ground, the transistor might be turned ON / OFF due to power or ground bounce. The suggestion from foundry is to use Tie cells for this purpose. These cells are part of standard-cell library. The cells which require Vdd, comes and connect to Tie high.(so tie high is a power supply cell), while the cells which wants Vss connects itself to Tie-low.

What is metastability and steps to prevent it?

Metastability is an unknown state - it is neither Zero nor One. Metastability happens for the design systems violating setup or hold time requirements. Setup time is a requirement, that the data has to be stable before the clock-edge and hold time is a requirement, that the data has to be stable after the clock-edge. The potential violation of the setup and hold violation can happen when the data is purely asynchronous and clocked synchronously.

Steps to prevent Metastability:

• Using proper synchronizers(two-stage or three stage), as soon as the data is coming from the asynchronous domain.
  

• Using Faster flip-flops (which has narrower Metastable Window).

What is local-skew, global-skew,useful-skew mean?

Local skew : The difference between the clock reaching at the launching flop vs the clock reaching at the destination flip-flop of a timing-path.
Global skew : The difference between the earliest reaching flip-flop and latest reaching flip-flop for a same clock-domain.
Useful skew: Useful skew is a concept of delaying the capturing flip-flop clock path, this approach helps in meeting setup requirement within the launch and capture timing path. But the hold-requirement has to be met for the design.

What are the various timing-paths which i should take care in my STA runs?

1. Timing path starting from an Input-port and ending at the Output port (purely combinational path).
2. Timing path starting from an Input-port and ending at the Register.
3. Timing path starting from an Register and ending at the Output-port.
4. Timing path starting from an Register and ending at the Register.

What are the various Design constraints used while performing Synthesis for a design?

1. Create the clocks ( Frequency, Duty-Cycle).
2. Define transition-time requirements for the input-ports
3. Specify load values for the output ports
4. For the inputs and the outputs, specify the delay values (input delay and ouput delay), which are already consumed by the neighbour chip.
5. Specify the case-setting (in case of a mux) to report the timing to a specific paths.
6. Specify the False-paths in the design
7. Specify the Multi-cycle paths in the design.
8. Specify the clock-uncertainity values (with respect to jitter and the margin values for setup/hold).
9. Specify few verilog constructs which are not supported by the synthesis tool.

What is meant by wire-load model?

In the synthesis tool, in order to model the wires we use a concept called Wireload models. Wireload models are statistical based on models with respect to Fanout. Say, for a particular technology based on our previous chip experience we have a rough estimate we know if a wire goes for "n" number of fanout, then we estimate its delay as say "x" delay units. So a model file is created with the fanout numbers and corresponding estimated delay values. This file is used while performing Synthesis to estimate the delay for Wires and to estimate the delay for cells.

What are the measures or precautions to be taken in the Design when the chip has both analog and digital portions?

As today's IC has analog components also inbuilt, some design practices are required for optimal integration. Ensure in the floor-planning stage that the analog block and the digital block are not siting close-by, to reduce the noise. Ensure that there exists separate ground for digital and analog ground to reduce the noise. Place appropriate guard-rings around the analog-macro's. Incorporating in-built DAC-ADC converters, allows us to test the analog portion using digital testers in an analog loop-back fashion. Perform techniques like clock-dithering for the digital portion.

What is meant by inferring latches, how to avoid it?

Consider the following :

always @(s1 or s0 or i0 or i1 or i2 or i3)
case ({s1, s0})
2'd0 : out = i0;
2'd1 : out = i1;
2'd2 : out = i2;
endcase

In a case statement if all the possible combinations are not compared and default is also not specified like in example above, a latch will be inferred. In above case if {s1,s0} =3, the previous stored value is reproduced. The same may be observed in IF statement in case an ELSE IF is not specified. To avoid inferring latches make sure that all the cases are mentioned if not default condition is provided.

Tell me structure of Verilog code you follow?

A good template for your Verilog file is shown below.

// Timescale directive tells the Simulator the Base units and Precision time unit of the simulation
`timescale 1 ns / 10 ps
module name (input and outputs);
// Parameter Declarations
parameter parameter_name = parameter value;
// Input / Output Declarations
input in1;
input in2; // Single bit Inputs
output [msb:lsb] out; // A Bus Output
// Internal signal register type declaration -
// Register types (only assigned within always statements).
reg register variable 1;
reg [msb:lsb] register variable 2;
// Internal signal. net type declaration - (only assigned outside always statements)
wire net variable 1;
// Hierarchy - Instantiating another module

reference name instance name (
.pin1 (net1),
.pin2 (net2),
.
.pinn (netn)
);

// Synchronous Procedures
always @ (posedge clock)
begin
.
end

// Combinatinal Procedures
always @ (signal1 or signal2 or signal3)
begin
.
end

assign net variable = combinational logic;

endmodule

What is Boundary Scan?

Boundary scan is a board level design technique that provides test access to the input and output pads of ICs on PCBs. Boundary scan modifies the IO circuitry of individual ICs, so that the input and output pads of every boundary scan IC can be connected to form one or more serial boundary scan chains.

Boundary scan is used to check for shorts and opens in the interconnect between ICs on PCBs. It performs the checks by using the boundary scan chains to pass logic values b/w the pads of different ICs.

At the top level the boundary scan logic has 3 modules: the Test Access Port (TAP), the instruction and data registers.

The TAP, an external I/F between the chip and the board, consists of Test Mode Select (TMS), Test Clock (TCK), Test Data In (TDI) and Test Data Out (TDO) - that control the state of the boundary scan test logic and that provide the serial access to the instruction and data modules.

For more information, click here.

To Maximize the Fault Coverage

The scan design technique depends on the controllability and observability of the state of DUT. Observe the following guidelines to maximize the fault coverage.

• Use Full Scan
  

• Use cells that have full functional models
  

• Fix all design rule violations, in particular
  

• Be careful when you use the gated clocks. If the clock signal at a FF is gated, a primary clock might not be able to control its state. If your design has clock gating, disable it in test mode.
  

• Generate the clocks off chip. If clock signals are generated on chip (Clock dividers), you can't control the state.
  

• Minimize the combinational feedback loops. CFL are difficult to test because they are hard to place in a known state.
  

• Use scan compatible sequential elements.
  

• Avoid uncontrollable asynchronous behavior.
  

• Control bi-directional from Primary Inputs.
  

Uncontrollable clocks and resets in Scan Insertion

When we are doing the scan insertion, we may find many uncontrollable clocks and uncontrollable asynchronous signals like set and reset violations. How to avoid these violations?

Uncontrollable clocks are coming from a combinational logic (Clock Dividers). When doing scan insertion, the control of the FF must be with respect to the TEST EN signal, ie, if TEST EN = 1, the whole chip should be in scan mode. For this all the clock of FF should be controllable at the top level.

Wherever you get a uncontrollable clock violations, please do the following :

• MUX the functional CLK with the "test clk" with the TM(Test_Mode) as the select line and then give the output of MUX as the input to the FF.

You can also use Auto-Fix to fix uncontrollable clocks and asynchronous sets and resets.

Auto-Fix can automatically fix each uncontrollable clock input as shown in Figure.


To use the Auto-fix capability:

Use the set_dft_configuration command to enable the various Auto-fix options:

To fix the uncontrollable clock, use the option -fix_clock_enable
To fix the uncontrollable asynchronous set signals, use the option -fix_set_enable
To fix the uncontrollable asynchronous reset signals, use the option -fix_reset_enable

# Enable AutoFix
set_dft_configuration -fix_clock enable \
-fix_reset enable -fix_set enable