Presentation is loading. Please wait.

Presentation is loading. Please wait.

Verification SV3.1a Assumptions Surrendra Dudani Nov. 14, 2003 Synopsys, Inc.

Published byIsaac Woolcott Modified over 8 years ago

Similar presentations

Presentation on theme: "Verification SV3.1a Assumptions Surrendra Dudani Nov. 14, 2003 Synopsys, Inc."— Presentation transcript:

1 Verification SV3.1a Assumptions Surrendra Dudani Nov. 14, 2003 Synopsys, Inc.

2 Accellera Proposal: Assumptions 11.14.2003(2) Property Assumptions assume property ( property_spec ) ; Allow properties to be considered as assumptions for formal and dynamic simulation Tools must constrain the environment such that a property holds No obligation for tools to prove the property Assumptions may be used as embedded or as declarative

3 Accellera Proposal: Assumptions 11.14.2003(3) Request - acknowledge protocol When reset asserted, keep req de-asserted req can be raised at any other time req once raised, stays asserted until ack is asserted In the next clock cycle both req and ack must be de-asserted

4 Accellera Proposal: Assumptions 11.14.2003(4) Assumptions governing req property pr1; @(posedge clk) !reset_n |-> !req; // when reset_n is asserted (0),keep req 0 endproperty property pr2; @(posedge clk) ack |=> !req; // one cycle after ack, req must be deasserted endproperty property pr3; @(posedge clk) req |-> req[*1:$] ##0 ack; // hold req asserted until and including ack asserted endproperty

5 Accellera Proposal: Assumptions 11.14.2003(5) Assertions governing ack property pa1; @(posedge clk) !reset_n || !req |-> !ack; endproperty property pa2; @(posedge clk) ack |=> !ack; endproperty

6 Accellera Proposal: Assumptions 11.14.2003(6) Assume req - Assert ack a1: assume property (pr1); a2: assume property (pr2); a3: assume property (pr3); s1: assert property (pa1) else $display("\n ack asserted while req is still deassrted"); s2: assert property (pa2) else $display("\n ack is extended over more than one cycle");

7 Accellera Proposal: Assumptions 11.14.2003(7) Assumptions with biasing assertion_expression ::= expression | expression dist { dist_list } Needed for driving random simulation Biasing provides a weighted choice to select the value for free variables Alignment with constraint block syntax For assertions and formal, dist converted to inside Properties must hold with or without biasing

8 Accellera Proposal: Assumptions 11.14.2003(8) Assume req - Assert ack with biasing a0: assume property @(posedge clk) req dist {0:=40, 1:=60} ; a1: assume property (pr1); a2: assume property (pr2); a3: assume property (pr3); s0: assert property @(posedge clk) req inside {0, 1} ; s1: assert property (pa1) else $display("\n ack asserted while req is still deassrted"); s2: assert property (pa2) else $display("\n ack is extended over more than one cycle");

9 Accellera Proposal: Assumptions 11.14.2003(9) Sequential constraints in constraint block constriant_block ::= property_instance ; | ….. Extend constraint block to allow property instances Properties become assumptions, and automatically create boolean constraints Boolean constraints from properties solved with other boolean constraints, whenever randomize function called Procedural control over randomization as before

10 Accellera Proposal: Assumptions 11.14.2003 (10) Example: constraints using properties When signal X is set to 1, then on the next cycle X must be reset to 0, and remains stable for four cycles, at the end of which signal Z must be set to 0 for at least one cycle When signal Y is set to 1, then on the next cycle it is reset to 0, and remains stable for two cycles at which point signal Z must be set to 1 for at least one cycle.

11 Accellera Proposal: Assumptions 11.14.2003 (11) Code using sequential constraints property pA; @(posedge clk) X |=> (!X)[*4] ##0 !Z; endproperty property pB; @(posedge clk) Y |=> (!Y)[*2] ##0 Z; endproperty class drive_XYZ_class; rand bit X; rand bit Y; rand bit Z; constraint pAB_Z {pA; pB;} endclass

12 Accellera Proposal: Assumptions 11.14.2003 (12) Randomizing sequential constraints program P(input bit clk, output bit x_port, y_port, z_port); drive_XYZ_class XYZ_driver = new(); initial forever begin @(negedge clk) void’XYZ_driver.randomize(); x_port = X; y_port = Y; z_port = Z; end … endprogram

13 Accellera Proposal: Assumptions 11.14.2003 (13) Code using combinational constraints class drive_XYZ_class; bit [2:0] A_state; bit [1:0] B_state; rand bit X,Y,Z; constraint AB_Z { (( |A_state[1:0]) == 1’b1 ) => (X == 1’b0); (A_state == 3’b100) => (Z == 1’b0) && (X == 1’b0); (B_state == 2’b01) => (Z == 1’b1); (B_state == 2’b10) => (Z == 1’b1) && (Y == 1’b0); } // functions on the next slide endclass

14 Accellera Proposal: Assumptions 11.14.2003 (14) Functions for combinational constraints function void new(); // initialize state variables A_state = 3’b0; B_state = 2’b0; endfunction function void post_randomize(); // advances state machine case (A_state) 3’b000 : if (X == 1’b1) A_state = 3’b001; 3’b001, 3’b010, 3’b011 : A_state = A_state + 3’b001; 3’b100 : A_state = 3’b000; default : $display(“bad A_state”); endcase case (B_state) 2’b00 : if (Y == 1) B_state = 2’b01; 2’b01 : B_state = 2’b10; 2’b10 : B_state = 2’b00; default : $display(“bad B_state”); endcase endfunction endclass

15 Accellera Proposal: Assumptions 11.14.2003 (15) Randomizing combinational constraints program P(input bit clk, output bit x_port, y_port, z_port); drive_XYZ_class XYZ_driver = new(); initial forever begin @(negedge clk) void’XYZ_driver.randomize(); x_port = X; y_port = Y; z_port = Z; end … endprogram

16 Accellera Proposal: Assumptions 11.14.2003 (16) Path to dead end state In either implementation, the constraint solver can legitimately set X to 1 in a cycle, then two cycles later, set Y to 1. After two cycles the solver is unable to solve for Z, i.e., the system of constraints is inconsistent at that point The problem is due to under-constraining (an incomplete set of constraints) Adding an additional constraint, dead end state can be eliminated

17 Accellera Proposal: Assumptions 11.14.2003 (17) Eliminating dead end state In either implementation, adding an additional constraint, dead end state can be eliminated property pC; @(posedge clk) X |-> ##2 !Y; endproperty

18 Accellera Proposal: Assumptions 11.14.2003 (18) Summary Simple syntactic extensions assume construct provides assumptions for formal analysis assume construct with biasing provides automatic random simulation Properties as sequential constraints simplify coding for randomizing complex sequences Difficulties and issues of dead end state exists for both combinational and sequential constraints

Download ppt "Verification SV3.1a Assumptions Surrendra Dudani Nov. 14, 2003 Synopsys, Inc."

Similar presentations

1 IP-Based System-on-Chip Design 2002 IP Reuse Hardening via Embedded Sugar Assertions Erich Marschner 1, Bernard Deadman 2, Grant Martin 1 1 Cadence Design.

1 IP-Based System-on-Chip Design 2002 IP Reuse Hardening via Embedded Sugar Assertions Erich Marschner 1, Bernard Deadman 2, Grant Martin 1 1 Cadence Design.
VERILOG: Synthesis - Combinational Logic Combination logic function can be expressed as: logic_output(t) = f(logic_inputs(t)) Rules Avoid technology dependent.

VERILOG: Synthesis - Combinational Logic Combination logic function can be expressed as: logic_output(t) = f(logic_inputs(t)) Rules Avoid technology dependent.
CS 510 Lecture 16: Verification Case Studies: Evolution From SVA 2005 to SVA 2009 Adapted from DVCon 2009 paper by Eduard Cerny 1, Surrendra Dudani 1,

CS 510 Lecture 16: Verification Case Studies: Evolution From SVA 2005 to SVA 2009 Adapted from DVCon 2009 paper by Eduard Cerny 1, Surrendra Dudani 1,
Traffic light contoller using FSM

Traffic light contoller using FSM
Synchronous Sequential Logic

Synchronous Sequential Logic
Combinational Logic.

Combinational Logic.
1 MODULE name (parameters) “Ontology” “Program” “Properties” The NuSMV language A module can contain modules Top level: parameters less module Lower level.

1 MODULE name (parameters) “Ontology” “Program” “Properties” The NuSMV language A module can contain modules Top level: parameters less module Lower level.
Give qualifications of instructors: DAP

Give qualifications of instructors: DAP
Slide 1 7. Verilog: Combinational always statements. VHDL: Combinational Processes: To avoid (I.E. DO NOT What in your HDL code?) Cases that generate Synthesis.

Slide 1 7. Verilog: Combinational always statements. VHDL: Combinational Processes: To avoid (I.E. DO NOT What in your HDL code?) Cases that generate Synthesis.
Sequential Circuit Analysis & Design Dr. Aiman H. El-Maleh Computer Engineering Department King Fahd University of Petroleum & Minerals Dr. Aiman H. El-Maleh.

Sequential Circuit Analysis & Design Dr. Aiman H. El-Maleh Computer Engineering Department King Fahd University of Petroleum & Minerals Dr. Aiman H. El-Maleh.
6/14/991 Symbolic verification of systems with state machines David L. Dill Jeffrey Su Jens Skakkebaek Computer System Laboratory Stanford University.

6/14/991 Symbolic verification of systems with state machines David L. Dill Jeffrey Su Jens Skakkebaek Computer System Laboratory Stanford University.
 2012 Bert Molenkamp, Jan Kuper, University of Twente, PSL Introduction to Assertion Based Verification with PSL (VHDL flavor) Bert Molenkamp Jan Kuper.

 2012 Bert Molenkamp, Jan Kuper, University of Twente, PSL Introduction to Assertion Based Verification with PSL (VHDL flavor) Bert Molenkamp Jan Kuper.
ECE 551 Digital System Design & Synthesis Lecture 09 Synthesis of Common Verilog Constructs.

ECE 551 Digital System Design & Synthesis Lecture 09 Synthesis of Common Verilog Constructs.
FSM examples.

FSM examples.
Leveraging Assertion Based Verification by using Magellan Michal Cayzer.

Leveraging Assertion Based Verification by using Magellan Michal Cayzer.
Spring 20067W. Rhett Davis with minor modifications by Dean Brock ECE 406 at UNASlide 1 ECE 406 Design of Complex Digital Systems Lecture 10: 9: State.

Spring 20067W. Rhett Davis with minor modifications by Dean Brock ECE 406 at UNASlide 1 ECE 406 Design of Complex Digital Systems Lecture 10: 9: State.
CS 151 Digital Systems Design Lecture 37 Register Transfer Level

CS 151 Digital Systems Design Lecture 37 Register Transfer Level
OUTLINE Introduction Basics of the Verilog Language Gate-level modeling Data-flow modeling Behavioral modeling Task and function.

OUTLINE Introduction Basics of the Verilog Language Gate-level modeling Data-flow modeling Behavioral modeling Task and function.
1 Assertion Based Verification 2 The Design and Verification Gap  The number of transistors on a chip increases approximately 58% per year, according.

1 Assertion Based Verification 2 The Design and Verification Gap  The number of transistors on a chip increases approximately 58% per year, according.
ECE 667 - Synthesis & Verification1 ECE 667 Spring 2011 Synthesis and Verification of Digital Systems Verification Introduction.

ECE Synthesis & Verification1 ECE 667 Spring 2011 Synthesis and Verification of Digital Systems Verification Introduction.

Similar presentations

Ads by Google