Test Plan For Assertion based verification using PSl

(ANSI/IEEE Standard 829-1983)

Test Plan Identifier: To be set according to certain issues.

REFERENCES

List of all documents that support this test plan USING ASSERTIONS TO SATISFY DO-254 ELEMENTAL ANALYSIS David- Landoll, Mentor Graphics, Austin, Texas IEEE Standard VHDL Language Reference Manual Introduction
This test plan is set to verify that Mentor Graphics tool Questa can

support Assertion Based Verification using property specification language (PSL) with VHDL designs. Questa is a comprehensive platform used for complex designs verification and can support high performance simulation acceleration and pre-silicon real world testing. In the coming new release we are planning to start support Assertion Based Verification (ABV) using PSL with VHDL designs, to get benefit from ABV which is improving efficiency of verification, and help in early detection and fixing of bugs, and overcome the shortage and drawbacks of elemental analysis. For VHDL what is new for this release is that we are planning to support the generate blocks in VHDL language which was not supported by our previous release. Test Items

Assertion Based Verification (ABV) using PSL with VHDL designs is going to be tested using Questa simulator version1, which is a simulation platform developed by Mentor Graphics to support different HDL (VHDL, Verilog, SystemVerilog and System C), also PSL is used to create assertions where it works alongside a design written in VHDL or Verilog, and may be embedded within the HDL code as comments or may be placed in a separate file alongside the HDL code.

Software Risk Issues

To be determined after team meeting and discussions

Features to be tested
Assertion based verifications along side QUESTA. PSL (property specification language) platform, and how to be written alongside VHDL and Verilog. Generate Blocks using VHDL inside QUESTA environment Approach Here the issue is to drive different test cases to verify the functionality of generate blocks, and the flow of these test cases is verified based on assertions (conditional statement that checks for specific behavior and displays a message if it does not occur). The test will be based on Providing internal test points in the design and change the condition and location of this test point , and for each iteration check for assertion if it passs or not and so on. For each of those pre-described test case assert desired condition which will repot message. The flow of these test cases will be as shown

Describe certain condition Fail check for this condition Describe another condition

Case study 1
In this stage I will try to drive test case based on the example (given case study), however in the next part I will show another examples with another case studies Approach: to violate the conditional if statement Set input signal a=0, which mean to modify the value of input signal (a) at the test bench, so it will violate the conditional if statement of the generate blocks.

For example:
architecture beh of tb is component e1 generic ( a : integer := 1); port(CLK in1 in2 : in bit; : in bit_vector (1 downto 0); : in bit);

end component; constant PERIOD : time := 100 ns; constant PERIOD1 : time := 130 ns; signal CLK : bit := '0'; signal in1 : bit_vector (1 downto 0); signal in2 : bit; constant w_a : integer := 0;

check

Inside the conditional if do: assert that a is high, if the program continue to run this mean that the program isnt running correctly.

Case study 2 (using same DUT as of case1 ) Approach: to violate the iterative for loop of generate block. Write the for generate such that the inner for loop is dependent on the outer for loop For example: Inside DUT do as shown
l2:for I in 0 to 10 generate l3:for J in 0 to I generate l4:if (a > 0) generate

check

In the inner for loop assert that j is always smaller than or equal to I and check if the assert fail or not Case study 3 (using same DUT as of case1 ) Approach: verify the functionality of the dut and using an alternative syntax in expressing the cascading for loop
For example: Inside DUT do as shown
l2:for I in 0 to 10 generate l3:for J in 0 to 10 generate l4:if (j < i) generate

check

the assertion must verify that the output from this DUT is the same as output from case study 2, else if assertion fail it means that the tool map the blocks wrongly either in study case 2 or study case 3 or in both.

Case study 4 use a block diagram which perform the functionality of xor gate as shown
ENTITY xor3 IS PORT( A : IN STD_LOGIC; B : IN STD_LOGIC; Result : OUT STD_LOGIC); END xor3;

Using generate statement to connect these blocks to perform the functionality of parity encoder as shown

This figure only illustrate the functionality

The overall architecture will be as shown

Out1
Block1

out2

out3

out4

out5

Approach: check on connections between generated blocks (out1, out2 ,etc..),using known input output pattern. Check: Assert on the values of the intermediate signal, if the Boolean PSL is true (success) this indicate that blocks are mainly connected as required, and generate block is correctly

Case study 5
Approach: we want to check If the program handle infinite loops correctly or not, using the same DUT of parity encoder, which mean I am going to set an infinite loop inside the generate block
For example inside the DUT do as shown i=1; For j=0:i generate I=i+1;

The previous syntax will cause generation of infinite number of blocks, here the simulator is assumed not to compile this syntax and give compilation error. Check: based on PSL Vunit (verification unit) or mainly using static assertion (which is checked at compile time), the assertion must fail, else it means that generate block has a severe drawback

Case study 6
Approach: in this approach we want to verify that generate blocks are also verified with synchronous circuit (or sequential circuit) For example: Assume set of cascaded registers (may be used as synchronizer in clock domains crossing circuits) these set of registers (blocks) are assumed to drive static signal correctly

Clock domain 1

Clock domain2

clock

. In this issue we will write the structure of register inside the entity of the block, then use generate statement to make set of register (generate blocks). . If a signal is classified as static then it means it does not require any special synchronization circuit since it is guaranteed not to change during normal functionality of the device. In order to ensure that static signals are used correctly throughout the entire design the following property should be asserted:

Check: Assert that the static data is stable with clock edges and along the operation of the circuit.

Test tools (using Mentor Graphics tools)

QUESTA : platform for verification of complex designs

VISTA

: transaction level modeling tool

VELOCE2 : Full SoC RTL simulation