Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.
    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages
    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IQ
      • Verification IP
      • Static-Based Techniques
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.
    • Universal Verification Methodology (UVM)

      • Introduction to UVM
      • UVM Basics
      • Advanced UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time
    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters
    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking
    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.
    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum
    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum
    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum
    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).
    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns
    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns
    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizons - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.
    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook
    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines
    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.
    • Featured & On-Demand

      • Questa Verification IQ - April 11th
      • Continuous Integration
      • SystemVerilog Assertions
      • SoC Design & Functional Safety Flow
      • 2022 Functional Verification Study
      • Design Solutions as a Sleep Aid
      • CDC and RDC Assist
      • Formal and the Next Normal
      • Protocol and Memory Interface Verification
      • Webinar Calendar
    • On-Demand Library

      • Practical Flows for Continuous Integration
      • Lint vs Formal AutoCheck
      • The Three Pillars of Intent-Focused Insight
      • Formal Verification Made Easy
      • Fix FPGA Failures Faster
      • HPC Protocols & Memories
      • FPGA Design Challenges
      • High Defect Coverage
      • The Dog ate my RTL
      • Questa Lint & CDC
      • Complex Safety Architectures
      • Data Independence and Non-Determinism
      • Hierarchical CDC+RDC
      • All On-Demand Recordings
    • Recording Archive

      • Aerospace & Defense Tech Day
      • Exhaustive Scoreboarding
      • Improving Initial RTL Quality
      • CDC Philosophy
      • Hardware Emulation Productivity
      • Visualizer Debug Environment
      • Preparing for PCIe 6.0: Parts I & II
      • Automotive Functional Safety Forum
      • Siemens EDA Functional Verification
      • Improving Your SystemVerilog & UVM Skills
      • All Webinar Topics
    • Conferences & WRG

      • Industry Data & Surveys
      • DVCon 2023
      • DVCon 2022
      • DVCon 2021
      • Osmosis 2022
      • All Conferences
    • Siemens EDA Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • EDA Xcelerator Academy(Learning Services) Verification Training, Badging and Certification
      • View all Learning Paths
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.
    • Blog & News

      • Verification IQ
      • Verification Horizons Blog
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - March 2023
      • Verification Horizons - December 2022
      • Verification Horizons - July 2022
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Academy News
      • Contact Us
    • Training

      • Learning @OneGlance (PDF)
      • SystemVerilog & UVM Classes
      • Siemens EDA Classes
Ask a Question
SystemVerilog
  • Home
  • Forums
  • SystemVerilog
  • SVA : using $past

SVA : using $past

SystemVerilog 6323
SVA:$past 3
sraja
sraja
Full Access
40 posts
December 04, 2015 at 1:21 am

Hi,

I want to use $past in assertion to check ($past(din != 2'b00,0..2)) // 0,1,2 clocks.The requirement is to check din != 00 for 0,1,2 clocks.how can i use it ?

Something like this i would like to give range - ($past(din != 2'b00,[0:2]))// This is not valid coding style....

($past(din != 2'b00,0)),($past(din != 2'b00,1)),($past(din != 2'b00,2)) My requirement is to merge to range [0:2].

Can i know the correct coding style?

-Regards,
-Raja.

Replies

Log In to Reply
ben@SystemVerilog.us
ben@SystemVerilog.us
Full Access
2601 posts
December 04, 2015 at 11:51 am

The syntax of the function is:
$past( expression1 [, number_of_ticks] [, expression2] [, clocking_event])
expression1 represents the expression being sought.

You can use the OR or the generate to achieve what you need; of course, that depends on what you need. Those 2 solutions are different.

import uvm_pkg::*; `include "uvm_macros.svh" 
module past; 
	bit clk, a; 
	bit[1:0] din; 
	default clocking @(posedge clk); endclocking
	initial forever #10 clk=!clk;  
   // 	 ($past(din != 2'b00,[0:2])) 
     ap_past_or:  assert property (
      	$rose(a) |-> $past(din !=2'b00 , 0)  || 
      	             $past(din !=2'b00 , 1)  || 
      	             $past(din !=2'b00 , 2)   ); 
 
   // This will create 3 separate assertions 
   generate for (genvar g_i=0; g_i<3; g_i++) begin 
      ap_delay_gen:  assert property (
      	$rose(a) |-> $past(din !=2'b00 , g_i));  
      end 
    endgenerate
 
     initial begin  // Generation of verification testbench 
                    // as described in my new assertion book
     repeat(200) begin 
       @(posedge clk);   
       if (!randomize(a, din)  with 
           { a dist {1'b1:=1, 1'b0:=3};
       		 din dist {1'b1:=1, 1'b0:=2};
 
           }) `uvm_error("MYERR", "This is a randomize error")
       end 
       $finish; 
    end    	
endmodule 

Ben Cohen
http://www.systemverilog.us/
* SystemVerilog Assertions Handbook 4th Edition, 2016 ISBN 978-1518681448
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
* Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8
* Component Design by Example ", 2001 ISBN 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115
--------------------------------------------------------------------------
sraja
sraja
Full Access
40 posts
December 04, 2015 at 5:14 pm

Thank you for the solution.

Now i am using like this,
$past(din !=2'b00 , 0) || $past(din !=2'b00 , 1) || $past(din !=2'b00 , 2)).

I am using on the LHS (antecedent) side. To filter the assertion from triggering.
we can use it right?
Because i see most of the assertions using $past on RHS(Consequent) side.

Kindly let me know on the usage.

once again thanks for the solution.

-Regards,
-Raja.

Solution

Solution

ben@SystemVerilog.us
ben@SystemVerilog.us
Full Access
2601 posts
December 04, 2015 at 5:49 pm

In reply to sraja:
Syntactically, you can use ($past(din !=2'b00 , 0) || $past(din !=2'b00 , 1) || $past(din !=2'b00 , 2)) as an antecedent since it is a sequence (of length 1 in this case).
However, it is generally odd to see assertions written in this style because it is not expressed in a forward manner. Consider:

($past(din !=2'b00 , 0) || 
 $past(din !=2'b00 , 1) || 
 $past(din !=2'b00 , 2)) |-> a;

What is this is expressing? It is saying that "a" is true it is because in the last 2 cycles or in the last cycle or in the current cycle "din" was !=2'b00.

Generally, assertions are written as "cause then effect", rather than "effect because of cause". However, what you have is OK.
Ben Cohen
http://www.systemverilog.us/
* SystemVerilog Assertions Handbook 4th Edition, 2016 ISBN 978-1518681448
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
* Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8
* Component Design by Example ", 2001 ISBN 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115
--------------------------------------------------------------------------

sraja
sraja
Full Access
40 posts
December 04, 2015 at 8:37 pm

Yeah I agree with your answer.

Basically,I want a filter.

i.e the assertion should not trigger if the past [0 to 2] clock cycles value is din == 00.

Any ideas or inputs will be helpful to filter assertion.

-Regards,
-Raja.

ben@SystemVerilog.us
ben@SystemVerilog.us
Full Access
2601 posts
December 04, 2015 at 9:02 pm

In reply to sraja:
Am not clear as to what you mean by "the assertion should not trigger if the past [0 to 2] clock cycles value is din == 00." If I call "a" what I am looking looking for, and that any sequence of 1, 2, or 3 occurrences of (din ==2'b00) means a result of "!a" then you can express it as follows:

 //the assertion should not trigger if the past [0 to 2] clock cycles value is din == 00.
     ap_din_a: assert property((din ==2'b00) [*1:3] |-> !a); 

Ben Cohen
http://www.systemverilog.us/
* SystemVerilog Assertions Handbook 4th Edition, 2016 ISBN 978-1518681448
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
* Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8
* Component Design by Example ", 2001 ISBN 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115
--------------------------------------------------------------------------
pk_94
pk_94
Forum Access
74 posts
March 26, 2017 at 4:18 am

In reply to ben@SystemVerilog.us:

HI ben , I want to write an assertion for a signal "a" and "b" where the signal "a" is the exact replica of signal "b" just one cycle before.

I am implementing this : -

$rose(a) |-> $past(b,1);

Also it is to be noted that the width of both signals are exactly the same.

Correct me If I am wrong here , because I think this sequence is not checking the width of both signals rather ,only posedges of signals with a cycle of one delay.

ben@SystemVerilog.us
ben@SystemVerilog.us
Full Access
2601 posts
March 26, 2017 at 9:33 am

In reply to prashantk:

Quote:
In reply to ben@SystemVerilog.us:

HI ben , I want to write an assertion for a signal "a" and "b" where the signal "a" is the exact replica of signal "b" just one cycle before.
I am implementing this : -
$rose(a) |-> $past(b,1); // width of both signals are exactly the same.

Correct me If I am wrong here , because I think this sequence is not checking the width of both signals rather ,only posedges of signals with a cycle of one delay.


  • $rose(a) |-> $past(b,1); is s property and is NOT a sequence
  • $rose(a_4bitbus) means that a_4bitbus went from 4'b0000 to something other than 4'b0000. Thus you would get a rose if a_4bitbus went from 4'b0000 to 4'b0001 or to 4'b1010 or 4'b0100 ....
  • When you say $past(b,1), you are saying the in the last cycle "b" was not a zero
  • What you may want is something like $changed(a) |-> b==$past(b,1); // if "a" changed, then current "b"== past "b"
    Note the comparitor b==$past(b,1)
Ben Cohen
http://www.systemverilog.us/
* SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
* Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 978-1539769712
* Component Design by Example ", 2001 ISBN 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115
--------------------------------------------------------------------------
pk_94
pk_94
Forum Access
74 posts
March 26, 2017 at 10:16 am

In reply to ben@SystemVerilog.us:

Hi ben , Thanks for the explanation.

I didn't get the second point. As I think $rose() is posedge kind of thing. In your example :-
$rose(a_4bitbus) where a_4bitbus is a 4 bit signal.SO do you mean that anyvalue other than 4'b0000 will satisfy $rose , I mean $rose will take the 4bit bus as single entity and be true , a_4bitbus is changed from 0 to a non zero value.

One more thing : for this four bit bus if value changes from 4'b1100 to 4'b1000 will $rose work here as it is going from value 12 to 8.Please clarify this "a_4bitbus used with $rose"

As you have provided :- $changed(a) |-> b==$past(b,1). But according to this assertion .It implies that whenever a changes(at some ref. clock) , "b" should be 1 one clock cycle before.

But my use case is signal "a" is just a one cycle(of ref clock) delayed version of "b" and nothing else.

ben@SystemVerilog.us
ben@SystemVerilog.us
Full Access
2601 posts
March 26, 2017 at 12:26 pm

In reply to prashantk:

First, I was wrong on the following statement
"$rose(a_4bitbus) means that a_4bitbus went from 4'b0000 to something other than 4'b0000. Thus you would get a rose if a_4bitbus went from 4'b0000 to 4'b0001 or to 4'b1010 or 4'b0100 ...."
That is in error. after doing the following simulation, it became clear to me that for

bit[3:0] a_4bitbus;
$rose(a_4bitbus) is same as $rose(a_4bitbus[0])

I should have re-read my book, as in it I state
Quote:
$rose returns true when the sampled value of a Boolean signal argument transition is true at the current cycle (i.e., least significant bit of the expression==1’b1) and FALSE in the previous cycle (i.e., was 0, X, or Z), with respect to the clock of its context, otherwise it returns FALSE.

My apologies, when I am wrong, I am wrong.
import uvm_pkg::*; `include "uvm_macros.svh" 
`timescale 1ns/1ns
module top; 
	bit clk, a, b; 
	bit[3:0] data, data_past; 
	default clocking @(posedge clk); endclocking
	initial forever #10 clk=!clk;  
 
	always_ff  @(posedge clk)  begin 
		data_past <= data; 
	end 	
 
	ap_rose_4bits: assert property( 
				($rose(data), $display("@t=%t, data=%b", $time, data)) |-> data[0]) 
				$display("@t=%t  PASS", $time);  else $display("@t=%t  PAIL", $time); 
 
	ap_change: assert property($changed(data) |-> data_past==$past(data,1)) 
			$display("@t=%t, ap_change PASS", $time);  else
            $display("@t=%t, ap_change FAIL", $time);
 
	initial begin 
		repeat(200) begin 
			@(posedge clk);   
			if (!randomize(data)) `uvm_error("MYERR", "This is a randomize error") 
				/*if (!randomize(data)  with 
					{ data dist {4'b0000:=8, 4'b1001:=1, 4'b0110:=1, 4'b0100:=1};
					}) `uvm_error("MYERR", "This is a randomize error")	*/		
		end 
		   $stop; 
	end 
endmodule  
// simulation 
 @t=                  30, ap_change PASS
# @t=                  70, ap_change PASS
# @t=                 110  PASS
# @t=                 110, data=0101
# @t=                 110, ap_change PASS
# @t=                 130, ap_change PASS
# @t=                 150, ap_change PASS
# @t=                 170  PASS
# @t=                 170, data=1111
# @t=                 170, ap_change PASS
# @t=                 190, ap_change PASS
# @t=                 230, ap_change PASS
# @t=                 250, ap_change PASS
# @t=                 270, ap_change PASS
# @t=                 290  PASS 

For your $past question, here is what I wrote in my book. Hopefully that should answer your questions.
SVA Handbook 4th Edition
"The $past function provides the sampled value that an expression held in a previous nth cycle. The syntax of the function is: [1]
$past( expression1 [, number_of_ticks] [, expression2] [, clocking_event])
expression1 represents the expression being sought.
The three optional arguments define the following:
 expression1 and expression2 can be any expression allowed in assertions.
 number_of_ticks specifies the number of clock ticks in the past. number_of_ticks must be one or greater, and must be static (i.e., known at elaboration time). If number_of_ticks is not specified, then it defaults to 1. If the specified clock tick in the past is before the start of simulation, the returned value from the $past function is a value of X.
 expression2 is used as a gating expression for the clocking event. The value returned for $past is expression1 sampled number_of_ticks gated cycles ago. In other words, for:
$past(data, 3, load_enable, @(posedge clk)) the returned value is the sampled value of data in the 3rd prior cycle in which load_enable was true. This is demonstrated in Figure 4.1.1.1-2 /ch4/4.2/past.sv
 clocking_event specifies the clocking event for sampling expression. A clock tick is based on clocking_event.
 Examples: :
regload |=> reg_data==$past(data); // value of load_data at the previous cycle
regload |-> ##2 reg_data==$past(data, 2); // value of load_data at 2 cycles ago
regload |-> ##2 reg_data==$past(data, 2, 1, @(posedge clk)); // value of load_data at 2 cycles ago
regload |-> ##2 reg_data==$past(data, 3, load_enable, @ (posedge clk) );"

One more thing on the $past, To avoid intial potential errors, consider using a ##1 in the antecedent; thus, " ##1 $changed(data) |->$past(..."
A long time ago, when I first learned VHDL, a consultant taught me a simple lesson: Whenever you fail to understand a syntax, run a samll sample program to test your understandings. The likelyhood that the simulation tool understands and implements the language better than you do is very high.
:)
----------------
Ben Cohen
http://www.systemverilog.us/
* SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
* Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 978-1539769712
* Component Design by Example ", 2001 ISBN 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115
--------------------------------------------------------------------------

pk_94
pk_94
Forum Access
74 posts
March 26, 2017 at 11:52 pm

In reply to ben@SystemVerilog.us:

Thanks Ben.

Mechanic
Mechanic
Full Access
66 posts
April 23, 2020 at 4:27 am

I have a question stating that "If signal a i active then signal b was active somewhere in the past"
someone please help me out in writing the assertion.
how can we pass the ranges to the number of clock ticks in "$past(exp1,number of clockticks,exp2 )" ?

in case of time advancement we have [+]/[*] ? in case of $past how can we achieve that ?

Thanks in advance

ben@SystemVerilog.us
ben@SystemVerilog.us
Full Access
2601 posts
April 23, 2020 at 8:04 am

In reply to Mechanic:

// ""If signal a i active then signal b was active somewhere in the past"
// This is the wrong way to see or express an assertion.  The recommended approach is the 
// forward-looking.  Thus, instead of saying
// BAD STYLE:  If  some_sequence_of_events then some_events must have happened in the past. 
// BETTER STYLE:  If some_events then other events now or in the future 
// Something like
   b |-> strong(##[1:$] a);
   $rose(b) |-> strong(##[1:$] a);

Ben Cohen
http://www.systemverilog.us/
For training, consulting, services: contact http://cvcblr.com/home
* SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
* Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 978-1539769712
* Component Design by Example ", 2001 ISBN 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115
--------------------------------------------------------------------------
1) SVA Alternative for Complex Assertions
https://verificationacademy.com/news/verification-horizons-march-2018-issue
2) https://verificationacademy.com/forums/systemverilog/sva-package-dynamic-and-range-delays-and-repeats
3) SVA in a UVM Class-based Environment
https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment
pavan_hyd
pavan_hyd
Full Access
2 posts
July 29, 2020 at 3:54 am

You can do something like this.

bit a;
bit b;
bit [N-1:0] arr;

always @(posedge clk)
arr <= { arr[N-2:0], b };

property check_a;
@(posdege clk) (a==1) |-> $countones(arr[N-1:1]) >= 1;
endproperty

Branex
Branex
Full Access
6 posts
October 28, 2020 at 4:40 am

Hi Ben, I was brought here looking for a solution to write something like "did a signal rise in the past". Just wanted to comment about your suggestion to use forward looking statements. I agree with your comments, but sometimes I want to check the following.
1) If signal A rises, then signal B rises after 2 cycles. This is obviously easily done with a forward looking statement (rose A implies ##2 rose B).
2) But at the same time I want to make sure that it was not something else that caused B to rise, i.e. I want to make sure that it was signal A. So I kind of want to check if $rose(B), then looking at the past for 2 cycles, A rose as well.
Do you think it makes sense to use backwards looking statements (like $rose with $past) in that case, or would you suggest something else to check that?

ben@SystemVerilog.us
ben@SystemVerilog.us
Full Access
2601 posts
October 28, 2020 at 7:31 am

In reply to Branex:

Quote:
Do you think it makes sense to use backwards looking statements

The simple answer is "maybe makes sense". The issue is that verification (whether through SVA or other assertion means) checks that the requirements, which tend to be forward looking, are met. Checking that an observed effect is the cause of possible actions in the past can be complex. In critical missions, that is something that maybe useful. Taking the simple case of a traffic light controller, if a RED light occurs, it should be because there was a yellow light previously or because the system just booted. Also, if there is a green light it is because there was a red light before or because the fire dpt turned it on wirelessly and definitely not because it was a boot procedure (assuming at boot you want all the lights to be RED until initialization is done.
Below is a model from a previous post that addresses a technique to do this using support logic. Code is commented and should be self-explanatory.
module top; 
    timeunit 1ns/100ps; 
     bit clk, req, valid, force_on, force_on_ack, ack;  
 
     default clocking @(posedge clk); 
     endclocking
     initial forever #10 clk=!clk;  
 
     // 1.when req asserted I should check for valid that needs to be get asserted within 500clocks,
     // then ack should get asserted IN THE NEXT CYCLE.
     ap_req_valid: assert property(@ (posedge clk) $rose(req) |-> 
                                      first_match(##[1:500] valid) ##1 ack); 
 
    // valid must exist in between req and ack.
    // The following is ILLEGAL 
    ap_desired_but_ILLEGAL : assert property(@ (posedge clk) 
            rose(valid) |-> $past(1:$, was_a_req));    //                                  
     // Instead, store the fact that a "req" occured. reset when valid 
     bit was_a_req;
     always  @(posedge clk) begin 
       if(req) was_a_req <= 1'b1; 
       if(valid) was_a_req  <= 1'b0; 
     end 
 
       ap_valid_req: assert property(@ (posedge clk)  
             $rose(valid) |-> was_a_req);      
 endmodule  

Ben Cohen
http://www.systemverilog.us/
For training, consulting, services: contact http://cvcblr.com/home

** SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
...
1) SVA Package: Dynamic and range delays and repeats https://rb.gy/a89jlh
2) Free books: Component Design by Example https://rb.gy/9tcbhl
Real Chip Design and Verification Using Verilog and VHDL($3) https://rb.gy/cwy7nb
3) Papers:
- SVA Alternative for Complex Assertions
https://verificationacademy.com/news/verification-horizons-march-2018-issue
- SVA in a UVM Class-based Environment
https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment
- Understanding the SVA Engine,
https://verificationacademy.com/verification-horizons/july-2020-volume-16-issue-2

Siemens Digital Industries Software

Siemens Digital Industries Software

#TodayMeetsTomorrow

Portfolio

  • Cloud
  • Mendix
  • Electronic Design Automation
  • MindSphere
  • Design, Manufacturing and PLM Software
  • View all Portfolio

Explore

  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Customer Stories
  • Partners
  • Trust Center

Contact

  • VA - Contact Us
  • PLM - Contact Us
  • EDA - Contact Us
  • Worldwide Offices
  • Support Center
  • Give us Feedback
© Siemens 2023
Terms of Use Privacy Statement Cookie Statement DMCA