Generating hardware assertion checkers: for hardware verification, emulation, post-fabrication debugging and on-line monitoring

Generating Hardware Assertion Checkers

Marc Boulé · Zeljko Zilic

Generating Hardware Assertion Checkers For Hardware Verification, Emulation, Post-Fabrication Debugging and On-Line Monitoring

ABC

Dr. Marc Boulé Prof. Zeljko Zilic Department of Electrical & Computer Engineering McGill University 3480 University Street Montreal QC H3A 2A7 Canada [email protected]

ISBN 978-1-4020-8585-7

e-ISBN 978-1-4020-8586-4

Library of Congress Control Number: 2008928686 c 2008 Springer Science + Business Media B.V. ° No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, microfilming, recording or otherwise, without written permission from the Publisher, with the exception of any material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Printed on acid-free paper 9 8 7 6 5 4 3 2 1 springer.com

A` mes fr`eres et a` mes parents bien-aim´es Marc To Kasia, Pauline, Ivan Alexander and Maria Zeljko

Foreword

When I was young, my dad liked to tell me, “If you don’t ask the question, you won’t get the answer.” Today, I have a deeper understanding of his message – and I have applied his wisdom to many areas in my life. In my professional life, in the domain of digital design and verification, I learned (perhaps the hard way) that if I neglect to write a checker, which asks whether some aspect of the design is behaving correctly – then it is unlikely that I will find certain bugs. This concept, known as observability, is at the heart of an assertion-based verification methodology. And if you ask any project manager, “What is the biggest bottleneck in your verification flow?” you are likely to hear the response “debug.” In fact, this typical response has been validated by various industrial surveys, which have identified that debugging consumes over 60% of a project’s verification effort. In contrast, there are various published papers from industry that have measured up to a 50% reduction in debugging time due to improved observability, which resulted from applying an assertionbased verification (ABV) methodology. Today, numerous organizations have come to this realization, and they are starting to reap the benefits of adopting an ABV methodology. Not only do assertions provide a means to describe design intent in an unambiguous form, once defined, assertions can be synthesized into checkers to improve observability. In turn, simulation, formal verification, emulation, post-silicon debugging, and hardware runtime monitoring can use these checkers. With the emergence of assertion language and library standards – such as the IEEE SystemVerilog Assertions (SVA), the IEEE Property Specification Language (PSL), and the Accellera Open Verification Library (OVL) – a wealth of books covering syntax and semantics for these languages have been published. Furthermore, numerous books that present assertion patterns, applied examples, and methodology suggestions targeted at designers and verification engineers have hit the market. However, a fundamental step within the ABV process is the synthesis of efficient checkers from an SVA or PSL assertion. And while there have been multiple papers covering various aspects of assertion checker synthesis within the growing body of work related to assertion-based techniques, there has not been a single comprehensive reference guide. Generating Hardware Assertion Checkers fills that void.

vii

viii

Foreword

In Generating Hardware Assertion Checkers, Marc Boul´e and Zeljko Zilic present novel techniques for generating resource-efficient hardware checkers. Their treatment of the subject is comprehensive and ranges from developing a basic understanding behind the automata and algorithms used to convert PSL and SVA into hardware checkers, to introducing enhancements required to improve checker debugging, and on to exploring checker extensions required for post-silicon assertion checking and hardware synthesis. Researchers and practitioners continue to “ask the questions” within the emerging field of assertion-based verification, and as in any field of study, asking the question is critical to finding the answer. Marc and Zeljko have eagerly and competently addressed the important question: How do you generate resource-efficient checkers from PSL and SVA? And in doing so, they have created a book that will serve as a valuable reference for years to come. Harry Foster Chair, IEEE 1850 Property Specification Language (PSL) Working Group Chief Verification Technologist, Mentor Graphics Corporation

Preface

In this book we present a number of techniques leading to the automated generation of checker circuits from modern hardware assertion languages. Today, verification takes over 70% of the time spent in the development of modern electronic Integrated Circuits (ICs) and systems. Furthermore, the systems increasingly need to be sent to the costly manufacturing process without being fully verified, and the term “verification crisis”, commonly used today, describes that succinctly. For many years there was little progress in making new verification methods usable to engineers. The relatively recent spreading of assertion languages and assertion-based verification is starting to make an enormous impact on the ability to verify more, and in an manner that is more readily adopted by designers and verification engineers. Assertions have been used in software for many years, but there they take much simpler forms, mainly dealing with localized expression evaluations. Modern hardware assertion languages have flourished and proliferated following more than a decade of IBM’s work on adopting temporal expression languages for assertions in a form suitable for engineers, which is now known as Property Specification Language (PSL), and was standardized internationally by IEEE in 2005. Similarly, SystemVerilog Assertions (SVA) have been developed recently and are an integral part of the SystemVerilog language, also standardized internationally by IEEE in 2005. This book presents techniques for the synthesis of assertion checkers, critical to assertion-based verification, but also to the wider area of assertion-based design, including debugging, communicating the design intent, on-line monitoring etc., and in the process unifies the treatment of all these areas. The tool devised in this work generates more efficient and more correct checkers, while at the same time it more thoroughly supports the PSL and SVA language constructs than any other checker generator found in the literature today. This research goes beyond the use of assertions in pre-fabrication verification and opens up the way for their use in severely needed post-fabrication debugging, as increasingly the ICs are discovered to be incorrect after manufacturing. The impact

ix

x

Preface

of this work on post-fabrication debugging will clearly show in the years to come, as companies start adopting assertions in debugging. This book is intended for anyone wanting to use assertions more effectively as means to improve the quality of their designs, and for those wanting to know more about generating hardware assertion checkers for modern assertion languages. The book’s main topics are organized as follows: • Chapter 1: General introduction, collaborations and more detailed book organization • Chapter 2: Broad scope of assertions in software, temporal property checking, post-fabrication debugging, formal and dynamic verification • Chapter 3: Background on regular expressions, finite automata and the different approaches to generating checkers • Chapter 4: PSL and SVA assertions languages • Chapter 5: Finite automata theory and algorithms used in the checker generator, creation of checkers from automata • Chapter 6: Automata construction for PSL assertions, case study of automated reasoning about PSL semantics and rewrite rules • Chapter 7: Debug enhancements for checkers, checker use in post-fabrication debugging, self test and on-line monitoring • Chapter 8: Experimental results for PSL checkers, benchmarking of real and synthetic assertions, experiments in creating hardware-accelerated protein matching checkers • Chapter 9: Automata construction for SystemVerilog assertions, experimental results and a case study on checker use in formal verification • Chapter 10: Extensive array of future work directions for continuing research Readers interested in implementing checkers for PSL in their own research tools will find Chapters 5 and 6 of particular interest, while those dealing with SVA can focus more on Chapter 9. In the case of SVA however, many topics and algorithms from the PSL case are utilized, thus familiarity with Chapters 5 and 6 is recommended. Readers new to this general area will find particularly useful the background material on regular expressions, finite automata and checker creation strategies outlined in Chapter 3. The experimental results in the book can serve as a comparison to those benchmarking checker generators and the circuits they produce. Readers wishing to explore other ideas to help improve the effectiveness of debugging with checkers, and/or those wanting to explore how checkers can play a greater role in debugging fabricated silicon will find Chapter 7 of special interest. Other interesting topics that may appeal to readers with diverse interests include the automated theorem proving of PSL semantics and language equivalences in Chapter 6, and a case study on how assertion checkers can be used in formal verification, more specifically with model checkers that do not support assertion languages, as shown in Chapter 9. The language presentation in Chapter 4 introduces the syntax of the PSL and SVA languages, and chooses to describe the semantics of its operators in a natural language manner, as opposed to the formal semantics contained in the respective

Preface

xi

manuals ([108] and [107]). Readers wanting to learn exact semantics of operators can (and should) complement their reading with such documents (Appendix B in [108] and Appendix E in [107]). Although the checkers generated in this work apply to a variety of scenarios, including formal verification, the primary context that is targeted is dynamic verification (ex: simulation, emulation). The checkers are designed with the goals that: (1) they should require few hardware resources when implemented in a circuit form, and should be fast, to allow high clock speeds; and (2) that they continually report errors in real time as the design is executed, as opposed to a static result at the end of execution. Many design choices are made throughout this work to reflect these two main underlying assumptions, such that the hardware checkers produced are wellsuited for pragmatic checker-based verification. The checker generator described in this book is also meant to be independent of any third party software packages, and can more easily be integrated as a module in other EDA tools, thereby greatly reducing licensing and intellectual property issues. Many of the topics described in this book, along with the MBAC checker generator, were developed during the first author’s Ph.D. at McGill University, of which the second author was the advisor. Montreal March 2008

Marc Boul´e Zeljko Zilic

Acknowledgements

The authors would like to thank Harry Foster and Eduard Cerny for reviewing a draft of the book and for providing suggestions and improvements to the text. We also thank Mr. Foster for writing the inspiring foreword to the book. The authors would like to thank Jean-Samuel Chenard for co-authoring the papers on debug enhancements and silicon debug, and for providing much needed feedback on the use of the checker generator. The Python scripts developed by Mr. Chenard really helped make the experimental results in the book less painful to produce. We also thank Mr. Chenard for many fruitful discussions and suggestions for improving the usability of MBAC. Thanks to Stephan Bourduas, Jean-Samuel Chenard and Nathaniel Azuelos for being the first to stress the checker generator in a real-world application. We would further like to thank Dominique Borrione and Katell Morin-Allory from the TIMA-VDS laboratory in France for the many interesting discussions and exchanges concerning the development of assertion checkers. We also acknowledge Katell Morin-Allory who has undertaken the computer-assisted proof of our proposed rewrite rules in PVS, and who also provided feedback and improvements to Subsection 6.4.5. The first author would also like to thank these two researchers for the research visit and the time spent in the VDS group, and in particular Katell Morin-Allory, for teaching so well the process of automated theorem proving of PSL semantics and rewrite rules. We would like to take the opportunity to highlight the thankless work done by the anonymous reviewers in providing important feedback on the publications submitted to conferences and journals, which helped us improve the work along the road to this book. We also thank the many people who provided advice at conferences, and in particular Alan Hu of the University of British Columbia, for interesting discussions on assertion checkers in the early stages of the work. We also thank the members of the online verification community spearheaded by Janick Bergeron at verificationguild.com; we thank in particular Cindy Eisner, who never spares any effort to help people with their questions about assertions. We were also greatly helped by the insightful and detailed feedback provided by Bart Vermeulen and Jeroen Geuzebroek of NXP Semiconductors on their use of

xiii

xiv

Acknowledgements

the checker generator. Further, Miron Abramovici and Paul Bradley from DAFCA have provided their support and feedback on the debug applications of assertion checkers, while Alpha Oumar Barry and Parviz Yousefpour of AMD have provided their encouragement and additional feedback on MBAC’s usefulness in industrial verification settings. Some of the features of the tool would not be here today, while some bugs would still have persisted if it wasn’t for all of them. Further, we are grateful to Pierre Paulin from ST Microelectronics for creating favorable conditions during the sabbatical leave of the second author, which included a cooperation with the IBM Haifa Research Lab that steered us into exploring assertion checkers in more depth. We are also grateful to IBM for providing us the access to their FoCs PSL tool. A few of the examples used in the experimental results are in the form of Verilog source code and also in the form of assertions, and we wish to highlight their respective authors’ work. The Verilog code for the CPU and PIC designs were created by Jean-Samuel Chenard and Richard Herveille, respectively. Many of the nonsynthetic assertions are from the literature in the field, and in particular, assertions from books by Ben Cohen et al. and Srikanth Vijayaraghavan et al. were used. Patience, friendliness and speedy acting during the book writing supplemented the prior encouragements received from Mark de Jongh and Cindy Zitter from Springer. Thanks for trying to ease the delivery and for bringing the best to the birth of this book. ´ The first author would like to thank colleagues and friends at Ecole de technologie sup´erieure, and in particular Patrick Cardinal and Andr´e St-Amand. The second author owes a great gratitude to Katarzyna Radecka for picking up the slack on other fronts during the work on this book. On the McGill side, acknowledgments are in place to Derrick Wong for persevering in promoting and supporting this work and to Sandra Beauchesne for her resourceful assistance in describing this technology to laymen and legal professionals. Further, Anna Wojciechowska stood for both authors in the final hours of this book writeup. The authors would also like to thank the graduates and undergraduates from McGill University who helped in polishing this book, including the students in the winter 2008 Logic Synthesis course (ECSE 530). Valuable feedback was obtained from (alphabetically): Ivan Bilicki, Alexandu Ciobanu, Michael Dang’ana, Sandrine Filion-Cˆot´e, Yu Pang, Sunyoung Park, Sayeeda Sultana, Jason Tong, Letao Wang and Andrew Wong.

Contents

1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Context and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Book Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Overview of the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 External Contributions and Collaborations . . . . . . . . . . . . . . . . . . . . . .

1 1 6 7 9

2

Assertions and the Verification Landscape . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Origins of Assertions: Software Checking . . . . . . . . . . . . . . . . . . . . . . 2.2 Uses of Assertions in Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Assertion Checkers and Checker Generators . . . . . . . . . . . . . . . . . . . . 2.4 Assertion Support in Simulators and Emulators . . . . . . . . . . . . . . . . . 2.5 Checkers in Silicon Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Assertions in Static and Dynamic Verification . . . . . . . . . . . . . . . . . . . 2.7 Supported Simulation and Emulation Semantics . . . . . . . . . . . . . . . . .

13 13 16 20 24 27 28 33

3

Basic Techniques Behind Assertion Checkers . . . . . . . . . . . . . . . . . . . . . . 3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Regular Expressions and Classical Automata . . . . . . . . . . . . . 3.1.2 Automata in Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Modular Approach to Checker Generation . . . . . . . . . . . . . . . . . . . . . . 3.3 Automata-Based Approach to Checker Generation . . . . . . . . . . . . . . . 3.4 Other Related Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37 37 38 44 47 49 52

4

PSL and SVA Assertion Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 The Property Specification Language . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 PSL Boolean Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 PSL Sequences and SEREs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 PSL Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4 PSL Verification Directives and other Declarations . . . . . . . . 4.2 SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 SVA Boolean Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55 55 58 59 62 68 70 73

xv

xvi

Contents

4.2.2 4.2.3 4.2.4

SVA Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 SVA Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 SVA Verification Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5

Automata for Assertion Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.1 Introduction and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2 Automaton Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2.1 Automaton Definition and the Symbol Alphabet . . . . . . . . . . 84 5.2.2 Determinization of Automata . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2.3 Minimization of Automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.2.4 Complementation of Automata . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3 Generating Circuit-Level Checkers from Assertion Automata . . . . . . 100

6

Construction of PSL Assertion Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.1 Introduction and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.2 Automata Construction for Booleans . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.3 Automata Construction for Sequences . . . . . . . . . . . . . . . . . . . . . . . . . 111 6.3.1 Conventional Regular Expression Operators . . . . . . . . . . . . . . 112 6.3.2 Sequence Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.3.3 Length-Matching Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.3.4 Repetition with a Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.3.5 Rewrite Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.4 Automata Construction for Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.4.1 Base Cases for Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 6.4.2 Rewrite Rules Based on Suffix Implication . . . . . . . . . . . . . . . 134 6.4.3 Rewrite Rules Based on Sequences as Properties . . . . . . . . . . 136 6.4.4 Rewrite Rules Based on Property Variations . . . . . . . . . . . . . . 138 6.4.5 Computer-Assisted Correctness Proofs for Rewrite Rules . . . 140 6.5 Automata Construction for Verification Directives . . . . . . . . . . . . . . . 152

7

Enhanced Features and Uses of PSL Checkers . . . . . . . . . . . . . . . . . . . . . 155 7.1 Introduction and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 7.2 Recursive Compilation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 7.3 A Special Case for eventually! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 7.4 Debug Enhancements for Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.4.1 Reporting Signal Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 163 7.4.2 Monitoring Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7.4.3 Signaling Assertion Completion . . . . . . . . . . . . . . . . . . . . . . . . 165 7.4.4 Assertion and Cover Counters . . . . . . . . . . . . . . . . . . . . . . . . . . 167 7.4.5 Hardware Assertion Threading . . . . . . . . . . . . . . . . . . . . . . . . . 168 7.5 Checkers in Silicon Debug and On-Line Monitoring . . . . . . . . . . . . . 172 7.5.1 Checkers in Silicon Debugging . . . . . . . . . . . . . . . . . . . . . . . . . 173 7.5.2 In-Circuit On-Line Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 173 7.5.3 Assertion Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Contents

xvii

8

Evaluating and Verifying PSL Assertion Checkers . . . . . . . . . . . . . . . . . 179 8.1 Introduction and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 8.2 Non-synthetic Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 8.3 Evaluating Assertion Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 8.4 Pre-synthesis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 8.4.1 Experiments with Hardware Protein Matchers . . . . . . . . . . . . 191 8.4.2 Complex Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 8.5 Benchmarking Debug Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.6 Benchmarking Sequences and Properties . . . . . . . . . . . . . . . . . . . . . . . 198 8.6.1 Comparison of the Two eventually! Approaches . . . . . . . . . . 198 8.6.2 Occurrence-Matching Sequences . . . . . . . . . . . . . . . . . . . . . . . 199 8.6.3 Failure-Matching Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 8.6.4 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

9

Checkers for SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.1 Introduction and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.2 Checker Generation for SystemVerilog Assertions . . . . . . . . . . . . . . . 207 9.2.1 Automata Construction for Booleans . . . . . . . . . . . . . . . . . . . . 208 9.2.2 Automata Construction for Sequences . . . . . . . . . . . . . . . . . . . 212 9.2.3 Automata Construction for Properties . . . . . . . . . . . . . . . . . . . 218 9.2.4 Automata Construction for Verification Statements . . . . . . . . 225 9.3 Experimental Results for SVA Checkers . . . . . . . . . . . . . . . . . . . . . . . 229 9.3.1 Non-synthetic Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 9.3.2 Benchmarking Sequences and Properties . . . . . . . . . . . . . . . . 235 9.3.3 Using SVA Checkers with Formal Verification Tools . . . . . . . 240

10

Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 10.2.1 Optimizations and Improvements . . . . . . . . . . . . . . . . . . . . . . . 253 10.2.2 Checkers and Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 10.2.3 Assertion Language Compilation . . . . . . . . . . . . . . . . . . . . . . . 255 10.2.4 Testing the Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 10.2.5 Beyond RTL Assertion Languages . . . . . . . . . . . . . . . . . . . . . . 257

A

Example for Up-Down Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Acronyms

The following is a short list of acronyms used throughout the book. ABA ABD ABV ASIC AMBA ATPG BDD BIST BNF CAD CTL CPU CUT DFA DFF DUV EDA EOE FF FL FPGA HDL IC IEEE IP LTL LUT NFA OBE

Alternating B¨uchi Automata Assertion-Based Design Assertion-Based Verification Application Specific Integrated Circuit Advanced Microcontroller Bus Architecture Automatic Test Pattern Generation Binary Decision Diagram Built-In Self Test Backus-Naur Form Computer-Aided Design Computation Tree Logic Central Processing Unit Circuit Under Test Deterministic Finite Automaton D-type Flip-Flop Design Under Verification Electronic Design Automation End of Execution Flip-Flop Foundation Language (properties) Field Programmable Gate Array Hardware Description Language Integrated Circuit Institute of Electrical and Electronics Engineers Intellectual Property Linear Temporal Logic Lookup Table Nondeterministic Finite Automaton Optional Branching Extensions

xix

xx

NOC PCI PIC PSL RAM RE RTL SERE SOC SV SVA

Acronyms

Network On Chip Peripheral Component Interconnect Programmable Interrupt Controller Property Specification Language Random Access Memory Regular Expression Register Transfer Level Sequential Extended Regular Expression System On Chip System Verilog System Verilog Assertions

Chapter 1

Introduction

Abstract This chapter is intended as a short introduction to the modern uses of assertions in hardware design. An overview showing the various applications of assertionchecking circuits is also given. Many terms and expressions are used somewhat loosely in this chapter, and are explained in more detail in the next chapter. The objectives and topics in the book are presented, along with a short description of the collaborations and the external contributions made by others that at various points influenced and augmented this research.

1.1 Context and Motivation Since numerous errors and faults inevitably arise in the design of high-quantity, high-complexity Integrated Circuits (ICs), it becomes increasingly impossible to weed them all out. Instead, producing high-quality ICs that come as close as economically possible to a perfectly working device has become of paramount importance in the semiconductor industry. In many cases the importance is of an economic nature, as product recalls and loss of market shares are but some of the consequences of providing faulty circuits. In military and aerospace applications, the consequences can be more dire especially when human lives enter the equation. Defects and faults in ICs, caused either by manufacturing imperfections or by designer errors, can cause everything from satellite and rocket malfunctions, to glitches and failures in consumer applications. One well-known case is the floatingpoint error found on early models of the Pentium processor by Intel. This “bug”, known as the FDIV bug was not a fabrication or manufacturing defect, but rather a functional error in the design of the division algorithm. Although the effect was barely perceptible, the flaw has caused a large recall of processors, and most estimates place the total cost to Intel at nearly half a billion US dollars. The recalls and product delays have happened numerous times after that, with the recent instances being as late as of December 2007. 1

2

1 Introduction

With such high prices to pay for producing faulty devices, the electronics industry is constantly seeking ways to improve the quality of delivered products. In some contexts, quality refers to quality of processes, quality management and quality assurance. Quality in electronic design targets the initial design specification steps, the actual design, verification and validation stages, as well as the manufacturing testing stage, where the elimination of design and fabrication faults is the supreme goal. Designing a system is all about ensuring that it correctly performs its intended functions. There are several facets of the correctness that designers and managers need to worry about. While realizing increasingly complex systems that perform ever more ambitious functions, companies need to ensure that first of all, the product solved the right problem. This task of design validation starts with gathering and then analyzing the requirements to produce the specification for design teams, and can often be finished only after the product is deployed in its intended environment. Once the overall specification is completed, design teams face a variety of design verification and implementation verification tasks on the road to obtaining a working design. Essentially, every transformation or refinement step requires its verification. For instance, translation of high-level architectural descriptions into more refined Register Transfer Level (RTL) or gate level descriptions can introduce errors, whether done manually or by employing CAD tools. One can rightly talk about the verification gap (i.e. growing proportion of verification time and effort in the overall development cycle1 ), or even about the verification crisis. In today’s complex digital circuit designs, verification typically requires more effort than the actual design phase itself. Verification deals with functional errors in circuit designs. In contrast, manufacturing testing aims at detecting fabrication faults in integrated circuits and systems. Testing is yet another instance of verification problems, where the goal is to ensure that the mass-production manufacturing process yielded in the intended devices. Many a design manager has wished that all the verification and testing tasks were accomplished quickly together, and indeed, research on the topic is worth its weight in gold. Since validation, verification and testing tasks deal with increasingly complex engineering objects, their completeness is becoming less feasible over time, especially when trying to make economical and cost-efficient products. Then, one increasingly talks of various quality metrics that express how close to the complete validation, verification and manufacturing testing goals the team arrives. Quality is hard to define fully, however there is an interesting definition in the ISO 8402 standard for quality management and quality assurance [111]: Quality: the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.

Improving quality requires long-drawn processes of verification and validation that go beyond debugging or even showing absence or presence of faults. Since it 1 The verification gap is nicely illustrated on the cover page of the book “Scalable Hardware Verification with Symbolic Simulation” [19].

1.1 Context and Motivation

3

ultimately aims to reduce risks of using the designed systems, quality improvement becomes a mental discipline to be developed by designers and their managers [12]. In the field of digital system design, the ability of a system to satisfy any stated or implied needs is compromised by the presence of faults. Examples of types of faults that can be present in digital circuits are: design faults, fabrication faults and faults that arise during usage [118]. A logic bug in a Boolean function is an example of a design fault, whereas stuck-at-value faults and short circuits are examples of fabrication faults. When a correct circuit subsequently becomes faulty under unexpected conditions or prolonged use, these are termed user faults. In modern design, the key point is that quality costs and that it must be traded for time and other company resources – the companies then need to choose between the unappealing prospects of delaying product releases and recalling the manufactured products. Failures of various types that escape to the products then become a liability in the product chain, which is a lesson that the engineers and their managers learn the hard way over and over again [58]2 . The measures for quality improvement should preferably be built into the design and production processes, rather than be relied upon during the quality inspection process. Product planning hence requires quality standards, such as the Zero Defects quality standard [59] which was a somewhat controversial concept at the time of its appearance, but the engineering community has recently started to rediscover it again. Hardware assertions have become an important addition to the majority of verification and quality improvement efforts in practice. Assertions are additional statements that are added to a design to specify its correct behavior. Assertions have been used in software for many decades, and only in the last decade have they made a widespread impact to hardware design. In hardware, assertions typically model the correct behavior of the design using properties specified by temporal logic and a generalized form of regular expressions. Assertions can also be seen as a formal documentation language, free of the ambiguities inherent to natural language specifications. In another view, assertions can be seen as an executable specification [108], or a computable specification, when interpreted by verification tools. Once the assertion language is learned, adding assertions to a design to perform verification requires low overhead since assertions are text-based commands. Furthermore, assertions can be added incrementally as needed or as time permits. Even a single assertion can help find design errors. Engineers seeking to produce quality designs should use mechanisms that help find flaws in their designs, and assertions provide such mechanisms. After all, if an engineer is so confident in his or her design, there should be no problem with writing assertions that won’t fail. In the narrow sense, we say that hardware verification aims to ensure that a design fulfills its given specification. The major problem in realizing the verification tasks lies in the difficulty of obtaining a complete specification. In the absence of an overreaching single specification for a complete system, the designers and verification engineers are forced to verify narrower sets of properties. 2

Two lessons that engineers can learn are well understood by homemakers when providing for their families: quality costs, but it pays over time.

4

1 Introduction Specification

Simulation

Design

Emulation

Dynamic Verification

Fabrication

Formal

Prototype Silicon

Silicon Debug

Production

On-Line Monitoring

Static Verification Assertion Checkers in:

Fig. 1.1 Assertion checkers in hardware verification, silicon debugging and on-line monitoring.

Assertion-Based Verification (ABV) [62, 75] is emerging as the predominant methodology for performing hardware verification. Assertions are high-level statements built on temporal logic that are added to a design under verification in order to specify how the circuit should behave. Assertions can (and should) be added before the verification step, and should be part of the design process as well. Figure 1.1 shows a summary of the main engineering tasks leading to a finished integrated circuit. Assertions should ideally be used in the specification stage to allow the formal documentation of requirements. More details on various uses of assertions, including those used during the specification phase, appear in a very insightful book on assertion-based design [75]. Rapid spread of assertions in recent years is due to their convenience – they can be added at any stage and in any quantity. The designers and verification engineers do not feel pressure to produce a complete specification at once, and the ability to add them in “piecemeal” fashion is, in fact, greatly encouraging their use. Designs with tens or hundreds of thousand of assertions are not uncommon, and clearly would not happen if all the assertions were to be written at once. Further, assertions can be reused across different stages of the design process, as well as in different designs. They are suitable for creating assertion libraries that greatly help their re-use [74]. Assertions should ideally be adopted in the first two blocks in Figure 1.1, namely specification and design. The assertion’s main role is in verification through simulation, emulation and formal verification. Synthesizing assertion-checking circuits is an effective way of allowing assertions to be used in the verification, silicon debugging and on-line monitoring steps in the flow in Figure 1.1. The use of checkers in these various applications is overviewed throughout this section, and an introduction of checkers and checker generation (checker synthesis) is given in the next chapter in Section 2.3. Hardware assertions are typically processed by simulators in dynamic verification, or by model checkers and theorem provers in static verification. When large designs are to be simulated, it is tempting to emulate or accelerate them by hardware, where the implicitly parallel nature of logic circuits can be exploited for faster

1.1 Context and Motivation

5

run-times. To allow assertions to be used in hardware, a checker generator is required to transform the assertions into circuit-level checkers. Assertions are written in high-level languages and are not suitable for direct implementation in circuit form. Generating resource-efficient assertion-checking circuits is of primary importance when assertion-based verification is to be used in hardware emulation, postfabrication silicon debugging and on-line monitoring applications. Assertions are often first viewed as a means of performing, enabling or facilitating the task of hardware verification, hence the term Assertion-Based Verification (ABV). However, to emphasize that assertions should be adopted in the earliest stages of the design cycle, the term Assertion-Based Design (ABD) was introduced to convey this philosophy [75]. Using assertions at the initial specification and design phases can have important benefits throughout the remainder of the design cycle. One example of this is when separate design and verification teams work together to correct the errors. Having a formally written set of properties upon which both teams can interact will help shorten the overall verification cycle. The method of specifying hardware designs has evolved over the years, ranging from low-level schematic capture to the behavioral design languages that are currently in use today. However, as envisioned by Foster et al., the properties used in assertion-based design could actually become the essence of the design and verification process [75]: The way design and verification has traditionally been performed is changing. In the future, we predict that design and verification will become property-based.

Properties are emerging as a new way of improving the verification process, and have the potential for becoming the new way of doing things in design. With the emerging adoption of assertions in verification, and their expected evolution as hardware design mechanisms, is it no wonder the assertion-based revolution is often referred to as a new paradigm [119]. The main hardware assertion languages are SystemVerilog Assertions (SVA) and Property Specification Language (PSL), both of which are by now standardized by IEEE as standards 1800–2005 [107] and 1850–2005 [108], respectively. They are also standardized by Accellera (www.accellera.org). The language used primarily throughout the book is PSL; however SVA is also treated in detail, including the synthesis techniques for SVA assertion checkers presented in Chapter 9. Further, Verilog is the most widely employed Hardware Description Language (HDL) in use today [55], and is certainly expressive enough in describing most hardware endeavors. The Verilog language is used in this work as the underlying language for expressing circuit designs, thus the Verilog HDL and the Verilog flavor of PSL will be used throughout much of the book. The concept of checker generators for PSL was pioneered by IBM and their FoCs tool [103]. The original assertion language that served as the foundation for PSL was actually developed by IBM and was called “Sugar”. The FoCs tool was originally intended for simulation use; however, the circuit checkers that are produced can also be synthesized in hardware. As witnessed in the history of publications (in chronological order) [25–32], the checker generator developed in

6

1 Introduction

this book has consistently been at the forefront of generating resource-efficient checkers for circuit implementations. In one example, a checker that is three orders of magnitude smaller in terms of code size was produced, compared to the FoCs tool [29]. Automatic generation of checkers from assertions is much more advantageous than designing checkers by hand. For one, a single line of PSL can sometimes imply hundreds of lines of HDL code. Maintaining checker code in HDL form is also not desirable, as the specification can sometimes change during the development. Furthermore, if complex checkers are coded by hand they will likely contain errors themselves that will need to be debugged. The checker generator developed in this research is particularly tailored for synthesizing assertion checkers that consume the least amount of circuit resources when implemented in hardware. Many design choices and optimizations are performed with the underlying goal of reducing the circuit sizes of the checkers. In this document, unless specified otherwise, the expression “the checker generator” refers to the checker generator developed in this work, called MBAC.

1.2 Book Objectives Within the powerful emerging Assertion-Based Design paradigm, the authors feel that on the road to improved design quality there is a large number of research topics, dealing with core algorithms, as well as with the methodologies in the use of assertions. While this book primarily focuses on the core techniques, the methodology and usage aspects of assertions are also explored in several instances. The principal set of problems addressed in this book is presented here by means of distinct challenges, to closely relate to the actual way that these interrogations arose throughout the various stages of the research. The solutions, or answers to these challenges constitute the contributions made in this book, and are outlined thereafter. 1. How can PSL and SVA assertions be converted into resource-efficient hardware checker circuits? Can all temporal operators suitable for dynamic verification be supported? If so, how? 2. How can these checkers be enhanced and/or modified to improve the debugging process? 3. Can assertion and a checker generator be used beyond dynamic pre-fabrication verification? Most of the answers to challenge 1 are contained in Chapters 5, 6 and 9, where the automata framework and the algorithms for converting PSL and SVA into automata, and subsequently into circuits, are developed. Over 20 automata algorithms are developed, and over 30 rewrite rules are introduced, all of which are specifically tuned to offer the most appropriate run-time monitoring semantics for hardware assertion checkers. Although a few algorithms and rewrite rules follow from classical

1.3 Overview of the Book

7

automata theory and the PSL/SVA specifications respectively, all are implemented in the context of a dual-layer symbol alphabet and an efficient symbolic encoding for edge labels. Other developments include particular optimizations for minimization, and the introduction of mixed levels of determinism in the automata. The answer to challenge 2 is contained in Section 7.4, where a series of debugging enhancements to assertion checkers is elaborated. New findings such as assertion threading, assertion completion and activity monitors are introduced in the context of automata-based assertion checkers. Challenge 3 is explored in Section 7.5, where checkers are extended to silicon debugging and on-line monitoring scenarios. It is also in that section where the idea of using assertions and a checker generator to automate certain types of circuit design is developed, with an example application in redundancy control. The concept of mixing automata with separate logic gates is introduced in Section 7.3 for implementing a more efficient form of the eventually! operator, when compared to the rewrite rule developed in Chapter 6. The results of all challenges are assessed empirically in Chapter 8 and in Section 9.3. In this work, a checker generator is devised with particular uses in verification, silicon debugging and on-line monitoring. The verification in question can range from hardware emulation and simulation acceleration, to software-only interpretation of assertions as used in traditional simulators, and can even extend into formal verification by allowing certain types of properties to be used in model checkers that do not support PSL and SVA. The techniques used in developing the checker generator can further be applied to areas as diverse as hardware-accelerated protein matching (Subsection 8.4.1) and network intrusion detection, where hardware implementations of regular expression matching can help improve performance. Adding circuit-level assertion checkers to a design invariably affects timing and floor-planning issues. As expected, the integrated circuit must have the necessary silicon area to implement the checkers. When the total size of a set of checkers exceeds the remaining area, methods such as assertion grouping (Subsection 7.5.3) can be used to help manage partitions of checkers in reprogrammable logic. Careful design practices can also be employed to help minimize the impact of adding checkers to a design. The emphasis in this work is placed on the actual checkers that are generated, as opposed to studying their effect on the source design, to which they can (and should) be attached.

1.3 Overview of the Book The book begins by a presentation of relevant background material in Chapter 2. Important terms such as checkers, emulation, silicon debugging, on-line monitoring and assertion-based verification, to name a few, are explained. The existing uses of assertions in simulators, emulators and in silicon debugging are also explored. An overview of related research is presented in Chapter 3. Both the automatabased and modular approaches to checker generation are introduced in the context

8

1 Introduction

of related research on assertion checkers. The use of automata in formal verification, more specifically in model checking, is also surveyed. This chapter also contains an introduction to classical automata theory and regular expressions, and can be very helpful prerequisites to the automata framework and the regular expressions appearing elsewhere in the book. Further related research is presented at the end of that chapter, where other assertion languages are also mentioned. Chapter 4 contains an introduction to PSL and SVA, where the syntax of these languages is formally presented. An informal explanation of both language’s semantics is also given, and was preferred instead of the formal semantics contained in Appendix B in the PSL specification [108] and Appendix E in the SVA specification [107]. Chapters 5 and 6 introduce the core notions to generating assertion checkers in this book. Chapter 5 introduces the automata framework used to symbolically represent assertions. Other important functions that are not specific to assertion automata are developed, such as determinization and minimization. The conversion of automata to circuit-level checkers is also developed at the end of Chapter 5. The automata construction for all PSL assertion operators is introduced in Chapter 6. The presentation starts with the lowest layer in the language structure, namely Boolean expressions, then proceeds gradually to the intermediate language layers consisting of temporal sequences and properties, and concludes with the toplevel verification directives. These two chapters alone represent sufficient material to describe the PSL checker generation process, from start to finish. Enhanced features and uses of checkers are then introduced in Chapter 7. The enhancements range from a more efficient treatment of the eventually! operator to various debugging enhancements related to the checkers. The enhancements can be categorized as either modifications to the behavior of checkers, or as added capabilities in the observability and the reporting of metrics. Chapter 7 also presents a view of how checkers can be used beyond verification by proposing their uses in post-fabrication silicon debugging, as permanent on-line monitors for in-field status assessment, and even for performing high-level circuit design. The checker generator is evaluated empirically in Chapter 8, using a variety of real-world and synthetic assertions in PSL. Themes such as assertion grouping, the choice of a symbol alphabet and the debug enhancements are evaluated. The typical evaluation consists of synthesizing the checkers for FPGA technology, where the resource utilization of the checkers can then be compared. We perform detailed comparisons to the FoCs tool from IBM, and we show that the MBAC checker generator produces smaller and faster circuits that offer the correct assertion behavior while supporting all simple subset operators. Chapter 9 is devoted to checker generation for SystemVerilog assertions. Section 9.2 introduces the construction of automata for SVA operators, and is the equivalent of Chapter 6 where the automata construction for PSL is introduced. Evaluating SVA checkers is performed in Section 9.3, which is similar to Chapter 8 where PSL checkers are evaluated. Although Chapter 9 seems self-contained, many algorithms from the PSL chapter are re-used given the similarities between the two languages.

1.4 External Contributions and Collaborations

9

The typographical conventions used in the book are briefly overviewed next. Symbols appearing in typewriter font are meant to represent directly what is typed by the user, and corresponds to what is input verbatim. Variables such as b and p are meant as placeholders for types of expressions that can appear in their place. For example, the two assertions: assert always b -> p assert always b -> p have very different meanings. The first assertion’s primitives b and p are in typewriter font and are the actual symbols that form the input text for the assertion. Hence, they are interpreted as two single-letter Boolean signals called b and p respectively. In the second assertion, the variables b and p are intended to represent any valid Boolean b and property p, and the assertion is to be understood in a more general sense. For simplicity, when expressions of the type “a occurs” are used, it is understood to mean “when the Boolean expression a evaluates to true”. Likewise, the expression “a is followed by b in the next clock cycle” means “Boolean expression a evaluates to true and Boolean expression b evaluates to true in the next clock cycle”. Unless it is explicitly mentioned, a statement like the preceding one makes no assumptions on the state of the Booleans in other clock cycles, and in the previous example, a can be true or false in the clock cycle where b was mentioned, and b can be true or false in the clock cycle where a was mentioned. As usual, the mathematical notation of the form {s | s ∈ Q, s ∈ I, s ∈ / F} is used to describe a set of elements s such that s is in set Q and s is in set I and s is not an element of the set F. The | has lowest precedence and the commas mean “and”. This notation is used extensively in the automata algorithms throughout the book.

1.4 External Contributions and Collaborations The authors would like to highlight the contributions made by Jean-Samuel Chenard regarding three co-authored publications [26–28]. A very useful partitioning script was developed to automate the individual synthesis of checkers when grouped in a single Verilog module. Another script was developed to automatically extract and convert the synthesis results into LATEX formatted tables. These scripts were used extensively in the publication for which they were developed [27], and also for the majority of the experimental results in Chapter 8 and in Section 9.3. The ideas of assertion grouping and management of checkers in programmable cores was also contributed by Mr. Chenard. Assertion grouping was also mentioned previously [2],

10

1 Introduction

unbeknownst to us at that time. Figures 7.7 and 7.12 appearing in Chapter 7 were originally designed by Mr. Chenard. Jean-Samuel also coded the CPU pipeline and helped work out the related assertion threading example in Section 7.4 (Example 7.4) [28]. The authors would also like to mention the contributions made by this co-author regarding the debug enhancements [26, 28]. Many discussions helped develop and organize the debug enhancements, and in particular, the ideas of monitoring completion, adding counters for assertions and the concept of logging signal dependencies were brought forth by Jean-Samuel. Katell Morin-Allory from the TIMA-VDS group in France has modeled the semantics of PSL in the PVS theorem prover, and has undertaken machine assisted proofs of the rewrite rules presented in Section 6.4. The first author gratefully acknowledges researchers Morin-Allory and Borrione from the TIMA-VDS group for the invitation and the time spent in the VDS laboratory learning about PSL proofs in PVS. One of the results of this exchange is visible in Subsection 6.4.5 where a proof sketch is shown for one of the rewrite rules. The complete results of the rewrite rule proofs are the object of a joint publication that is currently under development. It is during these related exchanges that semantics problems with the never operator were observed, and independently confirmed in the PSL issues list [110]. The message tracing assertion (NOC ASR) used in Section 8.2 was devised in a collaboration with Stephan Bourduas, Jean-Samuel Chenard and Nathaniel Azuelos [47], wherein assertion checkers are explored for debugging hierarchical ring Network-On-Chip (NoC) designs. The first versions of the automaton-based checker generator were developed using an automata library used in speech recognition at the CRIM (Centre de Recherche Informatique de Montr´eal). More specifically, the authors acknowledge Patrick Cardinal for providing the library and helping with interfacing issues, as well as many helpful discussions pertaining to automata. A contribution indirectly comes from IBM; by distributing a freely available version of their PSL/Sugar parser. The parser is used in the front-end of the checker generator and is responsible for creating a data structure representing the syntax tree of the input assertions. Although their results are not contained in this book, the authors would nonetheless like to acknowledge the graduates and undergraduates at McGill University that made use of the checker generator in their projects: • Nathan Kezar and Smaranda Grajdieru, Graphical User Interface for MBAC, ECSE 494 – Design Project Laboratory, McGill University, June 12, 2006 • Alya Al-Dhaher, Course Project – Assertion Test Generation, ECSE 649 – VLSI Testing, McGill University, May 11, 2006 • Alya Al-Dhaher, Automated Test Generation for Automata-based AssertionCheckers, Non-thesis Masters Project, McGill University, August 16, 2006 • Hansel Sosrosaputro and Shiraz Ahmad, Automation of Assertion Signal Monitoring, ECSE 494 – Engineering Design Laboratory, McGill University, April 16, 2007

1.4 External Contributions and Collaborations

11

• Yann Oddos and Jason Tong, Various topics in hardware and software test generation, McGill University, in progress, 2008

Chapter 2

Assertions and the Verification Landscape

Abstract This chapter presents an overview of assertions and their use throughout the product development lifecycle, including hardware verification, debug and monitoring. Assertions use in the areas of simulation, emulation and formal verification are overviewed. Assertion checkers and checker generators, two central themes in this book, are also presented. An introduction to temporal logic is also performed, given the strong foundations of assertion languages in this area. With the origins of assertion residing in the software side, it is only fitting to begin the chapter with a survey of assertions in software.

2.1 Origins of Assertions: Software Checking Assertions have been used in software for many decades. The history of reasoning about programs [114] reveals that the concept of assertions was introduced in 1947 by Herman Heine Goldstine and John von Neumann, where the idea of assertion boxes for capturing the correct effects of programs were introduced. Two years later, in 1949, a paper by Alan Turing mentions adding assertions to a program (reported in [114]): How can one check a routine in the sense of making sure that it is right? In order that the man who checks may not have too difficult a task the programmer should make a number of definite assertions which can be checked individually, and from which the correctness of the whole programme easily follows.

Modern day use of assertions in software is to a large degree attributed to the seminal work by Robert Floyd [71] on proving program correctness by assertions. In his work, Floyd is credited with formalizing assertions and developing the reasoning about programs based on axioms and predicate calculus. Assertions are by now present as a feature of virtually all modern programming languages, whereas earlier they would have been cast as extensions to the languages, or would be present

13

14

2 Assertions and the Verification Landscape

through standalone high-level specification languages. They can be used through several language constructs to describe properties at different places: in the program body, assumptions (preconditions), promises (post-conditions) and constraints on values. For the uses of assertions in software, a reference [153] provides a good overview of the main techniques with assertions. These assertion statements can also be used as primitives in contract-based programming [128] and related paradigms. By now, assertions are widely used in software development. According to another great computer scientist who has extensively dealt with software assertions (C. A. R. Hoare), present-day Microsoft Office software includes over a million assertions in its source code [96] that perform numerous useful functions during the software lifecycle. The most basic forms of assertions in software make use of the generic function call assert(), and are simple statements placed directly in the source code where they are to be evaluated. In the C programming language, for example, a typical assertion can look like this: assert (result >= 0);

(2.1)

In this example, the line above would be placed after a certain computation in a function, whereby the integer result of a given computation should not be negative. In the case of the C language, the assert construct is made available by including the header file , which is part of the C standard library. Given the sequential nature of programs, many types of assertions are only evaluated when they are executed, as opposed to hardware assertions that are constantly monitored. Assertions like the one shown above are a form of executable comment that help to ensure correct program development, as well as help others who will read the code. Assertions should generally not be used to catch invalid function arguments and unhandled bounds in functions, and are not a replacement for robust code with adequate value checking. They are however, a means to instrument the code with non-critical checks that can reveal programming errors during debugging. In most cases, the assertions are not instrumented when a release-mode compilation is performed, so that performance is not adversely affected. Software assertions have evolved along with the programming languages themselves, and a case in point is the assertion capabilities in object oriented languages such as the Java Modeling Language (JML). In this language, assertions can be specified using keywords such as: 1. 2. 3. 4.

invariant: specifies a condition that must hold throughout a function assignable: specifies that a given variable can be changed requires: models a pre-condition of a function ensures: models a post-condition of a function

Assertions in object oriented languages have their share of subtleties, like: should the assertions in a base class apply also to the derived classes? For a survey of assertions in modern software engineering, a prospectus article by Malloy and Voas offers a concise overview on the topic [123].

2.1 Origins of Assertions: Software Checking

15

One particularly challenging area for software verification is the case of concurrent software systems and distributed computing. Multi-threaded code and asynchronous process interleaving, whether on one or multiple machines, can be a nightmare for debugging. Formal reasoning about such concurrent systems can be performed by modeling the systems at a higher abstraction level and proving properties on these models. An example of this is the Promela modeling language and the SPIN model checker [98]. Promela is a process meta language used to model finite state systems. The language allows the dynamic creation of concurrent processes and both the synchronous and asynchronous forms of inter-process communication. The properties used for specifying correctness requirement in SPIN are specified in temporal logic, which is treated further in this chapter. Once specified, the properties can be checked formally by the SPIN model checker. The properties are then either proved or a counterexample is found. Design flaws that can be verified using such formal reasoning techniques over concurrent systems are: deadlocks and livelocks, under-specification (unexpected conditions), over-specification (dead code), and violations of constraints. Among the many interesting applications of formal software verification using SPIN is the verification of many algorithms used in mission critical software such as the Mars exploration rovers and the Deep Space 1 and Deep Impact missions. Model checking is referenced in a few places throughout this book, and is a technique used extensively in the formal verification of both hardware and software systems. A definition of model checking from Clarke and Emerson is in order : Definition 2.1. Model checking is an automated technique that, given a finite-state model of a system and a logical property, systematically checks whether this property holds for (a given initial state in) that model. This definition serves equally well for software models of systems verified in the SPIN model checker [98] for example, and for hardware models of systems verified in the SMV model checker [42], for instance. Among the interesting maxims often cited on the software side is this thought,1 which emphasizes the importance of specifying correctness requirements in the verification task: If a program has not been specified, it cannot be incorrect; it can only be surprising.

Applying this thought-provoking axiom to hardware verification is also quite pertinent. Hardware design languages such as VHDL have long incorporated simple assertions like the example given above in (2.1). In more recent SystemVerilog language, these simple assertions have also been added as “immediate” assertions. As it turns out however, more extensive assertion support is needed for hardware verification, as elaborated next.

1

By Young, Boebert and Kain.

16

2 Assertions and the Verification Landscape

2.2 Uses of Assertions in Hardware Turing’s citation in the previous section is surprisingly topical for hardware verification as well. Indeed, just recently, assertions have begun to be used in hardware design, and are spreading fast. In 2004 the number of hardware engineers using assertions passed the 50% mark (2004 DVCon census [54]). In 2007, the DVCon verification census [55] showed that 68.5% of engineers were using assertions. Since it is widely accepted that between 40% and 70% of the hardware design effort is actually spent on verification and bug-fixing [174], dealing with assertions has by now become a major preoccupation of engineers. With the increasing complexity of integrated circuits, these relatively high numbers are not surprising, and furthermore are not expected to diminish. Design teams nowadays are usually complemented by separate verification teams. Assertions are capable of playing a key role here, as means for describing and communicating the design intent to verification engineers. Assertions are also “understood” by an increasing number of software tools that support the main assertion languages. Further, assertions provide a key service in debugging, by allowing the designers to pinpoint errors closer to the source of failure than any other technique for pass/fail checking. This becomes even more relevant in the post-silicon, or post-fabrication stage debugging. Due to the complexity, and uncertainties of modern processes, the percentage of ICs (Integrated Circuits) that are “first time correct” is decreasing rapidly. According to Collett International Research, less than 30% of designed ICs achieve first silicon success, leading to more than 60% of total project time for an average IC design being spent after the first IC tapeout. Further, among all possible causes in modern Systems-on-Chip (SOCs), logic/functional bugs are found in 70% of failed first silicon devices. In post-fabrication debugging, ICs are debugged under realistic timing conditions. In silicon debugging with assertions, assertion checkers can be purposely left in the fabricated IC for debugging purposes, where they can greatly help in finding the cause of a failure. Data from Intel shows that in 2005, over 20% of total design resources are spent on post-fabrication validation [144], thus assertions can potentially have a large financial impact to help decrease project costs. Looking from this perspective, it is not surprising that in the counterpart software validation problem, companies like Microsoft implant millions of assertions in production software. Assertions are a way of formally capturing the correctness properties (or patterns) of a specification. Many such patterns are recurrent in verification [65], whereas some others need to be customized to a particular application. Hardware assertions are typically written in a Hardware Verification Language (HVL) such as PSL (Property Specification Language [108]) or SVA (SystemVerilog Assertions, part of the SystemVerilog language [107]). PSL is standardized by the Institute of Electrical and Electronics Engineers (IEEE) as the IEEE 1850–2005 standard, and SystemVerilog is standardized as IEEE 1800–2005. This book presents the state-of-the-art techniques for constructing hardware checkers for modern assertion languages. Although the major portion of this book

2.2 Uses of Assertions in Hardware

17

is centered upon PSL assertions, an entire chapter is devoted to SystemVerilog assertions and generating SVA checkers. Even though both languages are based on sequential regular expressions, differences in their property operators are more important. Both languages are suitable for simulation and formal verification; however, PSL does offer a wider variety of operators that are somewhat closer to linear temporal logic languages, whereas SVA is more tightly coupled to a design language and offers action blocks and local variables. The inclusion of added temporal operators is planned for the next revision of SVA and is expected to make both languages more similar to each other. It is safe to say that together, PSL and SVA are the two most accepted and used assertion languages [55]. In verification, assertions express the “golden rules” to which the implementation is compared. Any deviations from these golden rules constitute design errors. Assertions are not only beneficial in the verification process, but also represent an unambiguous way to document a design. For example, the following statement expresses a certain specification that is to be respected by a bus arbiter (the reset signal is active low). When the request signal goes from low to high in two consecutive cycles, then the grant signal must be asserted in at most five cycles and the request signal must remain high until this grant is received, unless a reset occurs.

The same requirement can be expressed much more succinctly using an assertion language: assert always ( {!req; req} |=> {req[*0:4]; gnt} ) abort !rst

(2.2)

In fact, the assertion above is actually more precise than the previous textual statement. Depending on the reader’s point of view, the expression “unless a reset occurs” either only releases the obligation for the request signal remaining high until the grant is received, or it also releases the condition that the grant signal must be asserted within five clock cycles. In other words, it is not clear what portion of the statement the expression “unless a reset occurs” applies to. Furthermore, to what cycle is the expression “in at most five cycles” related? Is it the second or the first of the two consecutive cycles that are mentioned? Notwithstanding these ambiguities that are alleviated by using the formal assertion language, the assertion is also a much more compact form of documentation and specification. The assertion shown in the example above was written in PSL, which will be covered in Section 4.1. The |=> operator is a temporal implication, the [*low:high] operator is a form of repetition with a range, and the semicolon represents temporal concatenation. Assertions are typically bound to a design to be verified, which is called the source design. The ABV methodology is based on the fact that the observation of an assertion failure helps to identify design errors, which are then used as a starting point for the debugging process. The amount of assertions that should be added to the design depends on the amount of coverage desired. One question that arises often with new ABV practitioners is: How many assertions do I need to write? The answer is not

18

2 Assertions and the Verification Landscape

an easy one. Thankfully, assertions can be added incrementally, one at a time. Even a single assertion can help, and is better than having no assertions at all. However, in an ABV simulation, the fact that no assertions failed is not an indication that the design is entirely free of errors. It is merely an indication that the behaviors specified by the set of assertions are respected under the given testbenches. The two main classes of functional verification are dynamic verification and static verification, and are visible in Figure 1.1 on page 4. Static verification is typically associated with formal verification [11,118], and is performed by tools such as automated theorem provers and model checkers. The term static is indicative of the fact that the design under verification does not need to be exercised. Model checkers and theorem provers analyze a model of the design, along with its properties or theorems, and are able to formally prove whether or not these properties or theorems are true. Model checking is integrated in the VIS tool [172], a system for synthesizing, simulating and formally verifying finite state systems. One of the most popular model checkers is SMV [124], pioneered by McMillan. Many formal verification tools such as IBM’s RuleBase and Cadence SMV, are built upon the SMV model checker. One particularly helpful feature in these tools is their ability to parse source designs in Verilog, against which formal properties can be verified. Example applications where RuleBase was used to perform formal property verification include: the verification of a processor bus interface unit [80] and a CoreConnect arbiter [84]; the verification of bus interfaces such as PCI [9, 45] and FutureBus [50]; the verification of an MPEG2 decoder circuit [143], an OC-768 framer [64] and an SHA-1 hashing circuit [46]. Other formal verification systems are based on automated theorem provers, such as PVS [142] and ACL2 [117]. These systems complement their core theorem provers by adding programming languages and sophisticated proof commands. Among other applications, ACL2 was used to verify the floating-point arithmetic of the AMD K5 processor [156], and PVS was used to prove the correctness of a modular construction of checkers for PSL properties [132]. An embedding of PSL for the HOL theorem prover has been performed, and allows the formal reasoning of PSL properties for consistency checking [85, 86, 168]. Formal methods indicate a pass/fail result for the assertions, and in the event of a failure, counterexamples can also be generated. The advantage with formal methods is that stimuli do not need to be provided, and once a decision is reached, the result is proven correct. The disadvantage is that proving properties on complex designs can often be computationally expensive in time and/or processing requirements, or even impractical for large designs. Dynamic verification is the predominant verification approach used in practice, and is most often associated with simulation. In dynamic verification, the design is exercised with a given stimulus, and its output is observed in order to assess the design’s behavior. The disadvantage of dynamic verification is that stimuli must be provided, and covering hard-to-reach corner cases, let alone all cases, is increasingly impractical to achieve.

2.2 Uses of Assertions in Hardware

19

Assertions are also used in dynamic verification. Dynamic verification can be further categorized as pre-fabrication verification or post-fabrication debugging. Hardware verification and design verification are often used to refer to pre-fabrication verification, where simulation and emulation are the principal techniques employed. In verification by simulation, the simulator analyses the execution run and reports on the status of the assertions. The advantage with simulation verification is that it is often easier to setup and does not require the more advanced technical and mathematical skills required to operate model checkers and theorem provers. A minimal skill set is nonetheless required to use assertions in simulation, as the temporal logics of assertion languages have their share of mathematical and formal notions. Assertions can further play an important role in post-fabrication silicon debugging, where assertion checkers are purposely left in the fabricated silicon for in-chip at-speed debugging. The relation between silicon debugging and design verification was shown in Figure 1.1 on page 4, where the separation between the two is the fabrication step. Assertion-checking circuits can even be used for more than verification and debugging, and can also be incorporated into an IC to perform in-field on-line status monitoring (Figure 1.1). In this way a device can automatically assess its operating conditions, whereby the assertion checkers are used as a means of monitoring the device. The items in gray in Figure 1.1 showed the scope of where the checkers developed in this work apply. When assertions are interpreted by verification tools, a pass/fail result is the minimal feedback that a tool must provide. However, by reporting the clock cycle(s) where the assertions have failed, much more insight is gained to help determine the causes of the errors. In dynamic verification with assertions, proper care should also be taken to build a testbench [15] that covers, as most as possible, a meaningful and relevant set of scenarios. If an assertion did not fail because of a lack of proper stimulus, this is not an indication that the design is error-free. Coverage is perhaps the main caveat with dynamic assertion-based verification, or any dynamic verification scenario for that matter. Many simulators such as ModelSim [126] and Synopsys VCS can interpret assertions in order to use ABV in dynamic verification. However, as circuits become more complex, simulation time becomes a bottleneck in dynamic verification. Hardware emulation is becoming an important asset for verification, and is increasingly being used in the industry to alleviate the problem of excessive simulation times [40]. Hardware emulation achieves the traditional dynamic verification goals by loading and executing the design on reprogrammable hardware, typically using programmable logic devices or arrays of processing elements. Once the design is implemented in hardware, the emulator fully exploits the inherent circuit parallelism, as opposed to performing a serial computation in a simulation kernel. Adding checkers to a design can allow assertions to be indirectly processed by simulators that do not support the assertion languages. Even when assertions are supported, in some cases simulating the HDL checkers can be computationally more efficient than the simulator’s own processing of the assertions [7]. Checkers can also be used in formal verification to allow model checkers to indirectly support PSL or

20

2 Assertions and the Verification Landscape

SVA assertions. In model checking with checkers, certain types of assertions can be verified by stipulating a temporal property stating that the checkers will not report any errors. The application of checkers in both of these forms of verification was also illustrated in Figure 1.1 on page 4. To summarize, there is a vast array of scenarios where assertions and assertion checkers play an important role: verification, hardware emulation, post-fabrication debugging, permanent online monitoring, simulation and formal verification. Synthesizing assertion checkers is beneficial and in most of these cases essential, to allow the assertion paradigm to be used in these areas. Assertion checkers, and checker generators are introduced next as a means of enabling assertion usage in this wide ranging and non exhaustive set of applications.

2.3 Assertion Checkers and Checker Generators Assertion languages allow the specification of expressions that do not lend themselves directly to hardware implementations. Such languages allow complex temporal relations between signals to be stated in a compact and elegant form. To allow assertion-based verification to be used in hardware emulation, a checker generator is used to generate hardware assertion checkers from assertion statements [1, 30]. These checkers are typically expressed in a Hardware Description Language (HDL). A checker generator can be seen as a synthesizer of monitor circuits from assertions. An assertion checker (or assertion circuit) is a circuit that captures the behavior of a given assertion, and can be included in the design under verification for in-circuit assertion monitoring. The assertion signal is the result signal of a checker and is the signal that is monitored during execution to identify errors. Figure 2.1 shows a high-level view of the assertion-based verification methodology, and the roles played by the assertions, the checkers and the checker generator. At the left of the figure are the given inputs to the tool, namely the Design Under Verification (DUV) and the assertions. In this example the circuit is described in a HDL and the assertions are specified in PSL. The checker generator produces an assertion circuit (a checker) for each input assertion. In this example, the checkers are transformed from an intermediate representation in automaton form. Automata theory facts will be explained further given that the checker generator developed in this work is automaton based.

Design Under Verification HDL

Assertions

assert

PSL

AssertionCheckers

Checker Generator

Fig. 2.1 Checker generator for hardware verification.

...

HDL Assertion Failure

2.3 Assertion Checkers and Checker Generators

21

The checker generator must also have access to the source design so that the signal dimensions can be known and the proper signals can be declared in the checkers. As is also shown in Figure 2.1, the checkers are connected to the DUV to monitor the proper signals. The output of a checker consists of a single signal, which is normally at logic-0, and becomes asserted (set to logic-1) in the clock cycles where the assertion fails. The checker generator developed here assumes that the designs are synchronous and that a clock signal is always present. To give more insight into the task that must be performed by an assertion checker, the following property is analyzed both through the formal and the run-time verification paradigms. Boolean signals a and b are used, however without loss of generality more complex Boolean expressions can be used as well. As will be observed, the property is handled differently depending on the verification technique; however, the conclusions reached are identical. (2.3)

always a -> next b

The example property above makes use of property implication and the next operator. The property states that: it should always be the case that if signal a is true in a given clock cycle, then signal b must be true in the next cycle. The syntax and semantics of PSL will be explained further in Chapter 4. Figure 2.2 shows how the property is interpreted in both formal and run-time (dynamic) property checking. In formal verification, the property is checked against

a) Formal property checking False in initial state

property does not hold

always a -> next b a -> next b next b b a Initial state

b

a

s1

s2

s3

a,b

b

b

a

s4

s5

s6

s7

Model states

b) Run-time property checking a b

Execution trace

ok

always a -> next b c1

c2

fail c3

c4

Fig. 2.2 Formal vs. run-time property checking example.

c5

c6

c7

22

2 Assertions and the Verification Landscape

a model of the design under verification. This is usually represented by a state transition graph, and in this example, in Figure 2.2a the values inscribed in the states represent the Boolean signals that evaluate to true in those states. This is a simplified example and in reality, the model can be much more complex and may contain branches and cycles. Furthermore, the property shown above employs Linear Temporal Logic (LTL); however, model checking with the branching time logics of CTL (Computation Tree Logic) is also possible. Branching time logics such as CTL are not suitable for the monotonically advancing time of dynamic verification, and do not apply to our assertion checkers. In the top part of Figure 2.2a, the property is decomposed into smaller constituents, and each sub-expression is evaluated in a bottom-up manner. The model checking starts by evaluating the terminals (the Boolean signals), and then gradually evaluates larger sub-expressions up to the full property. For example, a is true in states 2, 4 and 7, and this is represented by a check mark. Boolean b is true in state 4, thus next b will be true in state 3, and so forth. The implication a -> next b is true in any state where a is not true (1, 3, 5, 6, 7), and also in state 4 where both a and next b are true. The sub-property a -> next b does not hold in state 2. In a given state, the always operator evaluates to true when its argument property is true starting in that state and for the remaining states. In this example, state 7 is a terminal state because it has no outgoing transitions. The always property is true in states 3 to 7 because from any of those states, a -> next b is true in all the remaining states. The top-level property fails in states 1 and 2 because the sub-property fails in state 2. Since the property fails in the initial state (state 1), the property does not hold. This is the pass/fail answer (i.e. fail), and two counterexamples can be deduced by observing the sequences starting in state 1 and in state 2. In Figure 2.2b, the context is dynamic verification. In dynamic verification, the model of the design is not required, and an execution trace of the design is instead used. A trace is a waveform of signals showing their instantaneous values in the vertical axis, as a function of time (horizontal axis). The assertion must be checked against this trace, to determine if it passes or if it fails. One solution for performing dynamic verification consists of storing the entire trace and building a model to represent the trace, and then using model checking to verify the property [87]. However, capturing an entire execution trace for long durations or for many signals is not always practical. When connecting a checker to its Device Under Verification (DUV), the execution trace is implicitly applied to the assertion checker in real time, and does not need to be stored. In run-time property checking, the assertion checkers should produce decisions continually in real-time, and the trace-storing solution is not applicable. For optimal debugging, the checkers should provide an output signal of their own, thereby indicating when the property fails. The convention used in the figure is that a property signal is normally low, and is asserted in cycles where the property fails. The example property is interpreted at run-time as shown at the bottom of the figure. The key observation here is that unlike in static verification, in the run-time analysis the future value of a signal can not be known in the current cycle. In state 2 in

2.3 Assertion Checkers and Checker Generators

23

Figure 2.2a it is known that b is not true in the next state and that the property fails in state 2. However, in run-time verification, in clock cycle 2 (c2) the future value for b has not occurred yet, and there is no failure to report. The failure can only be reported once cycle 3 has taken place and the checker observes that b is not true. In the example, the run-time checker identified a failure in clock cycle 3. As a side note, if the always operator was not used in the example property, both methods would report that the property holds, because a -> next b is true in the initial state. One of the goals in this work will be to develop the necessary algorithms to implement circuits that can perform run-time checking of assertions. To conclude the example, both methods reach the same conclusion: the property does not hold. In model checking, counterexamples were produced, and in run-time property checking, the locations of faulty traces (also akin to counterexamples) were identified. It is precisely because of these differences in interpretation of properties that the PSL specification does not dictate the run-time semantics for the interpretation of PSL. This is best explained by the very insightful and evocative remark by Eisner and Fisman [68]: PSL defines whether or not a property holds on a trace – that is all. It says nothing about when a tool, dynamic or static, should report on the results of the analysis.

An important corollary of this fact is that in dynamic verification, two separate tools may produce different behaviors in the output traces of their assertion checkers, while both still being correct. This makes a direct comparison of checkers slightly more troublesome when a cycle-by-cycle comparison is attempted for checkers from two different tools. The example assertion used in (2.3) makes use of the weak temporal operator next, which places no obligation for the next cycle (or state) to take place. In dynamic verification, if a occurs in the last simulation cycle then the property may hold because the next cycle will never occur. If this is an unacceptable condition, the strong version of this operator could instead have been used (i.e. next!), thereby indicating that any antecedent condition has to see its next cycle realize or else the property fails. For example, if the operator next! was used instead of the weak next in (2.3), the dynamic verification scenario in Figure 2.2b would contain an additional failure in clock cycle 7. Also, in the formal verification scenario there would be no check marks in the top row in Figure 2.2a, and many more counterexamples could be reported. The use of strong operators leads to the following interrogation: how does a runtime assertion checker know when the simulation (or execution) is finished? In each clock cycle a decision is taken and the status of the assertion is reported. Nothing stops the user from halting the simulation and running an additional number of steps in the future. In hardware assertion checking, the solution consists of providing a special end-of-simulation signal that is used to inform the checkers that time is considered finished and that no further cycles will be run. The checkers that require this signal utilize it to indicate additional failures when strong obligations are not

24

2 Assertions and the Verification Landscape Checkers in Formal Verification Device Under Verification

Checker

AsrError

Model Check the Property: G !AsrError

Checkers in Dynamic Verification Device Under Verification

Checker

Simulate DUV+Checker: trace

Fig. 2.3 Using checkers in formal and dynamic verification.

met. This technique was developed in the FoCs checker generator [103], and is also employed in the MBAC checker generator. Since in this work the checkers can be used directly in circuits or in emulation platforms, the end-of-simulation signal will be referred to as the End Of Execution (EOE) signal. It is assumed that when this signal is required, the checkers declare it as an input, and the user normally drives it at logic-0, and raises it to logic-1 for at least one clock cycle at the end of execution. The example studied in this section, shown in (2.3) and in Figure 2.2, was analyzed in both the static and dynamic verification approaches. When simulators or model checkers do not support PSL, generating assertion checkers and adding them to the source design is an effective way of allowing the continued use of assertions. In both cases the checkers are connected to the design under verification, as shown in Figure 2.3. In the simulation case, the output signal of the checker can be observed and any violation can be identified in the trace. In the formal verification case, a simple property postulates that the checker output(s) are always (G) false. This is an LTL property that is implicitly checked over all possible execution paths. Using checkers in formal verification is straightforward for safety-type properties (invariants), but would require some adaptation for liveness-type properties, which apply to infinite executions. This book introduces the algorithms to convert PSL and SVA assertions into efficient checker circuits for use in hardware verification, in-circuit monitoring and post-fabrication silicon debugging. The checkers are particularly suited for hardware implementation where circuit speed and resource efficiency are paramount. Assertion circuits should be compact, fast and should interfere as little as possible with the design being verified, with which the checkers share the hardware resources.

2.4 Assertion Support in Simulators and Emulators When assertion-based verification is to be performed dynamically, HDL simulators capable of interpreting PSL are often used. Examples of such tools are Synopsys VCS, Cadence’s Incisive Unified Simulator and Mentor Graphics’ ModelSim. The main task of the simulator is to process the assertions that are either embedded in

2.4 Assertion Support in Simulators and Emulators

25

Fig. 2.4 Example of assertions interpreted by simulators for dynamic verification.

the source code of the design or specified in a separate file, in order to monitor the simulation and to report any circuit behavior that violates the assertions. An example simulation with ModelSim SE version 6.1f is shown in Figure 2.4 for the assertions found in an example from Chapter 4 (Example 4.4). The assertions are interpreted by the simulator during the execution of the testbench. The testbench instantiates the design under verification, which in this case is the up-down counter used in that example. In Figure 2.4, the simulation shows that two assertions failed. The first two assertions did not fail; however, to increase the confidence in the design, more test cases should be executed to improve the coverage of the dynamic verification. The wave section at the top of the figure shows the time points where the assertions failed (downward-pointing triangles), and the transcript at the bottom shows for which start times the assertions actually failed. The analysis pane in the center shows the kind of supplemental information that can be provided by simulators. The tool is able to report the number of times each assertion failed, and is also able to report the number of times each assertion completed successfully. Successful completions are indicated by the lighter upward-pointing triangles in the waveforms. Assertion completion and assertion counters are two of the debug enhancements

26

2 Assertions and the Verification Landscape

that are also implemented in the hardware checkers in this work, and will be introduced in Section 7.4. To continue the discussion on run-time semantics from Section 2.3, it should be emphasized that the PSL specification does not dictate how and when the assertion failures are to be reported in dynamic verification. Some assertions interpreted by simulators only report one failure for a given start condition. For example, the following assertion stipulates that a should never occur followed by 0 or 1 occurrences of b. assert never {a;b[*0:1]}; With this assertion, for every cycle in which a is asserted an error will be reported. However, if the cycle that follows a has b asserted, in ModelSim a supplemental error will not be reported. This is perfectly acceptable given that the run-time semantics of PSL is not specified. If an assertion fails at one or more time points, it has failed globally. One possible reason for this behavior in ModelSim is that the threads that monitor assertions in the simulation kernel are kept as short as possible for performance reasons. In hardware, this is not a concern because the assertion is implemented as a circuit. In the checker generator developed in this work, a failure is reported when a is observed and when a;b is observed (the semicolon indicates a clock cycle separation). In other words, in software it is more computationally efficient to stop monitoring the thread when a has occurred, whereas in hardware it is more resource efficient to let the pattern matching circuit follow its regular flow. As was just observed, interpreting assertions in software is very different than in hardware. In software approaches, one can take advantage of features such as stack-based function calls, recursive functions, threads and event lists, and most importantly, dynamic memory allocation. An example of software-based PSL interpretation is published by Chang et al. [43] where threads and event lists play a central role. When excessive simulation time becomes a bottleneck for dynamic verification, hardware emulation and simulation acceleration are often used. For the ABV methodology to be used in hardware emulation, assertions must be supported in hardware. Traditional emulators are based on reconfigurable logic and FPGAs. To increase flexibility and to ease the debugging process, which requires the ability to instrument assertions, current-generation emulators and simulation accelerators are typically based on an array of processing elements. The Cadence Palladium [41] and the Tharas Hammer [78] are examples of such emulators and simulation accelerators. Mentor Graphics also offers the Veloce accelerator and emulator, with support for transaction level verification [127]. These tools support the use of assertions. The ZeBu FPGA-based emulator family from Eve supports the use of SystemVerilog (but so far not PSL) assertions in hardware in a variety of emulation products [70]. A commonality with the simulators and emulators described in this section is that since they are all commercial products, the implementation details of PSL and/or SVA (or any other assertion language used therein) are not published. Some high-end emulator systems mentioned here are actually priced in the six figures (US dollar values).

2.5 Checkers in Silicon Debugging

27

2.5 Checkers in Silicon Debugging In the emerging Design for Debug (DFD) paradigm, several EDA companies are promoting a variety of solutions. Tools from companies such as Novas support advanced debugging methods to help find the root cause(s) of errors by back-tracing assertion failures in the RTL code [101,165]. Temento’s DiaLite product accepts assertions and provides in-circuit FPGA debugging features. Synopsys’ Identify Pro allows assertions to be synthesized into hardware (FPGA or ASIC), and for these assertions to be used as a triggering mechanism for capturing the state of the design when failures occur. However, as these tools are from commercial ventures, papers seldom disclose their actual inner-working. As increasing transistor counts and smaller process technologies make it difficult to achieve correct silicon, techniques for post-fabrication debugging, known as silicon debugging, are receiving much attention. DAFCA’s ClearBlue solution [2] offers silicon debugging instruments such as signal probe multiplexers, logic analyzer circuitry, and in-circuit trace buffers for capturing signals or supplying test vectors. To ensure flexibility in providing these post-silicon debug instruments, they are implemented in small blocks of additional programmable logic. Assertions can also be instrumented and changed dynamically in the specialized reprogrammable logic cores. The status of the RTL silicon-debug instrumentation that is added to the source design can be read back through the JTAG interface. Special debug circuitry and read-back is also a part of the research on assertion-based debugging presented by Peterson and Savaria [147]. When many assertion checkers are to be used in a modestly-sized programmable logic core, within a System-on-Chip for example, checkers must be managed in groups. The idea of assertion grouping is also mentioned by Abramovici et al. [2], and is explored further in Section 7.5. The debugging instruments also introduced by Abramovici et al. [2] and the checker enhancements presented in Section 7.4 encompass a collection of techniques that share a common goal: to help increase the efficiency of the debugging process with assertions. Recent work has shown that specifying various types of transfer sequences, phases and corner cases in a hierarchical and higher-level manner can be used to more efficiently automate the generation of protocol monitors [134]. Graphical user interfaces are also shown to play a key role in facilitating the debugging process with assertions, and can even be used in the specification of test sequences. Cross-product functional coverage is explored by Ziv [177] to augment the effectiveness of assertions when used to gather coverage metrics. Auxiliary variables are assigned to sub-expressions and are incremented when these sub-expressions are executed. In this way, various combinations of expressions can be reported and a much larger coverage space can be measured. However, the statement made therein that is the most relevant to the checker generator concerns the semantics of the cover operator in PSL. It is stated that expressing a coverage task for an expression e is equivalent to asserting (in LTL notation): F e. In PSL, the previous statement implies that covering a sequence is equivalent to asserting that it must eventually be

28

2 Assertions and the Verification Landscape

observed. This is the basis of the rewrite rule that will be used in Section 6.5 to handle the cover directive.

2.6 Assertions in Static and Dynamic Verification Since assertions are strongly based on temporal logic and temporal properties, it is fitting that such themes from the literature be explained here as a preamble to understanding assertion languages. One of the pioneers of temporal logic is Pnueli, who first applied such formal temporal reasoning to programs [149]. Temporal logic in hardware is based on the same set of operators as in software. For example, temporal logic is used to perform the model checking of concurrent programs using the SPIN tool [98], and is also used to verify hardware designs in the SMV model checker [124]. Depending on the type of verification, whether static or dynamic, temporal properties can have certain differences that are not negligible. The first of such differences concerns the notion of branching time logics. In Linear Temporal Logic (LTL), the temporal operators are devised to specify properties over single execution paths, whereas in Computation Tree Logic (CTL) the operators allow the modeling of behaviors over branching paths of execution. PSL has operators for specifying both types of properties, and are referred to as Foundation Language properties (FL) and Optional Branching Extensions (OBE) [108]; it is expected that LTL operators will be added to SVA. Execution paths are often meant to describe sequences of states in the model of a design, as typically related to model checking and static verification, whereas execution traces are used to describe a sequence of valuations of signals over time, and are typically related to simulation and dynamic verification. Linear temporal logic and its most often used operators are defined next (adapted from Eisner et al. [69]). Although properties and property checking in general is most often associated to model checking and static verification, a concerted effort is made in the presentation below to describe the concepts for dynamic verification as well, given the main application of the checkers developed in this work. For this reason, execution traces, not just paths in the states of a model, will be mentioned. Definition 2.2. If ϕ is an LTL formula, Linear Temporal Logic (LTL) is defined as follows: • • • • • • • •

An atomic proposition is an LTL formula (negation) ¬ϕ ϕ1 ∧ ϕ2 (conjunction) ϕ1 ∨ ϕ2 (disjunction) (next) X! ϕ (until) [ϕ1 U ϕ2 ] (eventually) F ϕ (always) G ϕ

2.6 Assertions in Static and Dynamic Verification

29

The definition of LTL starts with atomic Boolean propositions and builds upon these proposition using a variety of unary and binary temporal operators. The typical logical operators such as negation, conjunction and disjunction are defined. The strong next (X!) is written with an exclamation point to differentiate it from the weak next X, which doesn’t require a next state to be defined. From its given activation state(s), or from the initial state if rooted at the top level of an LTL expression, the X! operator indicates that its argument formula must hold in the next cycle, and that there must be a next cycle. The strong until (U) specifies that the first formula must hold up to but not including the second formula holding, and the second formula must eventually hold. The F and G unary operators specify that their argument formula must eventually hold, or must hold globally (always), respectively. The semantics of LTL is defined over words composed of letters from the alphabet 2P , where P is the set of atomic propositions. Such semantics abound in the literature [69], and are omitted here in preference of an informal explanation of the operators. The activation mentioned above is a way of visualizing how property operators interact when building a more complex expression, and can be used to explain the behavior of each operator. For example, in the LTL property X! X! G b the Boolean proposition b is only expected to always be true starting two states (or cycles in a trace) after the initial state (or cycle). The G receives its activation to start enforcing its argument from the operator in which it is nested, namely the second X!. This activation is delayed by one state or cycle. In turn, this X! receives an activation from the first X! (delayed by one state or cycle), which itself receives in implicit activation in the initial state of the model (or in the first cycle of the trace). The activation scheme described above is not really described as such in the semantics of LTL; however, modular approaches to generating checkers are sometimes based on the propagation of activation signals through the hierarchical levels in the syntax tree of an assertion, and viewing properties through activations will have benefits in the rest of this book. Activations may also help the more circuit-oriented readers to more easily grasp the notions of temporal properties. In the LTL definition (Definition 2.2), not all operators shown are fundamental operators: some can be defined from others, such as these two, for example. F ϕ

def

=

[true U ϕ ]

G ϕ

def

¬F ¬ϕ

=

Since disjunction can be expressed using conjunction and negation

ϕ1 ∨ ϕ2

def

=

¬(¬ϕ1 ∧ ¬ϕ2 )

we are left with only four fundamental operators in LTL: ¬, ∧, X! and U. Other supplemental operators are also defined such as a weak until W, that makes no requirement for the right-side formula to become true. The weak until can be defined

30

2 Assertions and the Verification Landscape

using its strong counterpart, along with the always operator. def

[ϕ1 W ϕ2 ]

=

[ϕ1 U ϕ2 ] ∨ G ϕ1

Additional operators such as the weak until are often called “syntactic sugaring” operators, and assertion languages such as PSL will also be shown to have their fair share of sugaring. In formal verification, LTL expressions are implicitly evaluated over all paths in the model, and as a whole, an LTL property is expected to hold in the initial state of the model. In dynamic verification, LTL expressions are evaluated on a trace, and are expected to hold in the initial cycle of the trace. Examples of properties and satisfying paths are shown in Figure 2.5. Each state is numbered Si and represents a valuation of the signals in the model of the design. In this figure, propositions labeled above the states are true in those states, and false otherwise. When quantifiers over computation paths are added to the formulas of LTL, CTL is formed. CTL is not fully related to the themes in this book, and is only overviewed informally. The two quantifiers added in CTL are: A and E, indicating for all paths and there exists a path. The rules for defining well formed CTL formulas are not developed here; however, two CTL examples are shown in Figure 2.6 for illustration purposes, such that the nuance between linear temporal logic and computation tree logic can be better understood. In the examples in Figure 2.6, the property AF b specifies that for all paths (A) the path expression F b must hold. In other words, in all paths starting at the initial state, b must eventually be true at least once on each path. In the second example in the figure, the property EG b specifies that starting in the initial state there must exist at least one path in the tree that admits G b, i.e. there must exist one path

b LTL1:

b

LTL2: G b

s1

s2

s3

s4

s5

s6

s7

b

b

b

b

b

b

b

s1

s2

s3

s4

s5

s6

s7

b LTL3: F b

s1

s2

LTL4: X! b

s1

s3

s4

s5

s6

s7

s2

s3

s4

s5

s6

s7

b1

b1

b1

b1

b1

b2

s1

s2

s3

s4

s5

s6

b

LTL5: b1 U b2

s7

Fig. 2.5 LTL operators and examples of satisfying paths, where b is a Boolean proposition.

2.6 Assertions in Static and Dynamic Verification

31

CTL1: AF b

b b b

b

CTL2: EG b b b b b

Fig. 2.6 CTL path quantifiers and two examples of satisfying computation trees, where b is a Boolean proposition.

where b is always true. PSL’s OBE operators allow the specification of there types of properties, but because they are not applicable to dynamic verification they are not treated here. Properties are also often categorized as either liveness or safety, or both in some cases. These qualifiers are defined next, inspired by their definitions in the PSL specification [108]. The definition of safety is given first. Definition 2.3. A safety property describes an invariant over the states in a design. A property is qualified as a safety property when its failure in a finite trace or path can not be undone by extending the said trace or path. Once the property has failed, no extension of the trace or path can make it hold again. Informally, the expression “nothing bad ever happens” is often cited to help convey the intention behind this type of property. Checking a safety property entails the search for the “bad” thing, and when/if it does materialize, the property is known to have failed. Liveness, on the other hand, is defined as follows. Definition 2.4. A liveness property describes an unbounded expectation. A property is qualified as a liveness property when there always exists an extension of a path or trace that can satisfy the given property. Informally, the expression “something good eventually happens” is typically cited to evoke the intentions behind this qualifier. In model-based verification, checking a liveness property involves showing that no infinite loop can occur in which the “good” thing does not happen at least once.

32

2 Assertions and the Verification Landscape

Often times the eventuality being specified in a liveness property should be limited for practical reasons. The typical elevator requirement stating that when the button is pressed the elevator will arrive eventually is of no comfort to a user who must stand by patiently for a few hours until the elevator door opens. In such cases, liveness properties with a limit placed on the eventuality in question are described as bounded liveness properties. These liveness and safety qualifiers need not be mutually exclusive and a single property can be both a liveness and a safety property. The conjunction of a safety and a liveness property is the simplest way of building such a property, while some other operators intrinsically have both characteristics. An example of this and other types of properties discussed thus far is shown next. Example 2.1. Using the context of execution traces in simulation, consider the following LTL properties, where b is a Boolean expression. F b G b b1 U b2 X In the first property based on the eventually operator, if b has not yet occurred in a given trace, the trace can always be extended to a point where b might conceivably be true; this is a liveness property. In the second property based on the always operator, if b ceases to be true at some point in a given trace then the property does not hold, and no extension of the trace can make it hold; this is a safety property. The third example makes use of the strong until operator and is both a safety and a liveness property. If b1 ceases to be true when b2 has not yet occurred, then the property fails and can not hold again on any continuation of the trace. The strong until also specifies that the right-side formula must eventually be true. If b2 has not yet occurred in a given trace, then it is foreseeable that a continuation may find b2 asserted, thus satisfying the liveness requirement. The fourth example shows a case of bounded liveness where the extension of a trace in which b is expected to be true can not continue forever, and in this case at most ten next cycles can be used to satisfy the requirement for b to occur. This last example uses yet another sugaring operator to avoid having to write ten X! operators in a row. The number in brackets specifies the next nth state where its argument property must hold. Similar examples are explained further in the next section where the simulation and hardware emulation semantics supported in the checker generator is briefly outlined. Such semantics are applicable to the use of formal properties in the context of run-time verification.

2.7 Supported Simulation and Emulation Semantics

33

2.7 Supported Simulation and Emulation Semantics The terms safety and liveness are typically applied to properties with infinite executions where they are verified against models of a design, whether in hardware or software verification. In the finite traces associated to dynamic verification, liveness can be re-cast as a type of safety requirement by explicitly marking the end of the trace. Liveness properties that have an outstanding eventuality at the end of the trace, whether bounded or unbounded liveness, are reported as failures and do not hold. In the area of assertion checkers, the end of the trace is marked with a special signal that is asserted for one clock cycle at the end of execution. The checkers utilize this signal to report assertion errors, and the use of this signal makes it such that liveness properties are expressed as safety properties in dynamic verification. The idea of translating liveness using safety [157] has also been studied in the area of model checking with LTL [21]. At this point two classifications of operators have already started to appear. The nuance between X and X!, and between W and U is described using the notion of strength. The strength of an operator defines how it behaves on a finite path or trace, when the eventuality, whether bounded or not, can not be fulfilled because of a shortened execution path or trace. Given that property checkers offer an evaluation result at each clock cycle, they are in effect constantly evaluating their property on a finite trace that keeps growing at each clock cycle. In this respect, the trace is considered finished at each clock step, until the next step takes place. In order for strong operators to be evaluated properly in checkers, the end-of-execution signal discussed above can be used to mark the true end of time, such that any unfulfilled eventualities can be reported as errors by the property checkers. Notwithstanding the strength of an operator, a given property can also be said to hold strongly or not on a given path or trace. Using the classification made in PSL for the levels of satisfaction of properties in dynamic verification, the following distinctions can be made (adapted from the PSL specification [108]): 1. A property holds when no bad states have been seen, all future obligations have been met, and when it may or may not hold on any extension of the path or trace. 2. A property holds strongly when the property holds and will also hold on any extension of the path or trace. 3. A property is pending when it has outstanding obligation but no bad states have been seen. 4. A property fails when a bad state has been seen. For example, in dynamic verification, the LTL property (using sugaring) X[10] b is said to hold, but not hold strongly, on a trace lasting five cycles since extending the trace may find b false at the tenth clock cycle. This is sometimes referred to as weak satisfaction. The operator is also known as a weak operator. On a trace 11 cycles long, where b is true in the 10th cycle, the property above does hold strongly

34

2 Assertions and the Verification Landscape

since the property will also hold on every extension of the trace. This is sometimes referred to as strong satisfaction. To continue the example, the LTL property below using the strong “next” X![10] b is pending on a trace five cycles long since there is an outstanding future obligation. Obviously, both properties above can be said to fail on a trace of ten cycles (or more) in length, when b is false in the tenth clock cycle. In the checker generator developed in this work, the result signal is binary and does not render the amount of information described above in the same manner. Some checkers actually provide two result signals to delineate between the above four cases. These will be surveyed in Section 3.2. In the MBAC checker generator, the four cases are in effect mapped to a binary result signal that renders a valid decision at any point in a finite trace. When the trace is considered finished, the EOE signal mentioned previously must be supplied to some assertion checkers. The checkers utilize this signal and can determine the value of their result signal using the criteria shown in Figure 2.7. The only case that can map either way to logic-0 or logic-1 in the checker output is the pending case. When a liveness property, usually caused by the use of a strong operator, has an outstanding obligation and the end of execution is not signaled, then the checker’s output indicates no error (logic-0). When the trace is considered ended, as marked by an asserted EOE signal, any pending eventualities are reported as errors by the checkers. Using checkers in dynamic verification, as opposed to the property checking typically performed by model checkers, does exhibit some differences as witnessed in Section 2.3, where the same property was verified in both contexts of static and dynamic verification ((2.3) and Figure 2.2). As a supplemental example for LTL properties in dynamic verification, consider the following simple properties: LT L2 : G ¬b2

LT L1 : F b1 Property satisfaction level:

Holds Strongly

Checker output: Logic-0 (no error)

Holds, but not Strongly EOE==0 Pending EOE==1 Fail

Logic-1 (error)

Fig. 2.7 Levels of property satisfaction in MBAC checkers, EOE is the End-of-Execution signal (active high).

2.7 Supported Simulation and Emulation Semantics

35 LTL2: G

LTL1: F b1

b2

EOE b1

b2

Chk_LTL1

Chk_LTL2

Fig. 2.8 Example traces showing the run-time failures of a safety and a liveness property, as reported by checkers.

The first property specifies that Boolean b1 should eventually be true, and the second property, known as the never property, specifies that Boolean b2 should never be true. If property checkers are devised for these LTL expressions, the output of the checker for LT L1 remains de-asserted during the entire trace, and only upon signaling the end-of-execution can it become asserted if b1 was not true at least once in the trace. The output of the checker for LT L2 is such that each time b2 is observed to be true, it can signal an error by rising to logic-1 in each of those cycles. The end-of-execution signal is not required for the second checker. The EOE signal is used in liveness properties but is not required for safety properties. Figure 2.8 shows two example scenarios where the safety and liveness properties introduced above are found to fail, in the dynamic verification with checkers. The liveness property triggers a failure at the end of execution since the b1 eventuality was not satisfied, and the safety property triggers multiple failures throughout the execution. In this setup, the LTL checkers are constructed using techniques described further in the book, and are connected to a fictitious design that is being executed on a testbench, for example. The checker outputs are each registered with a flip-flop, and signal their failures with a clock cycle delay. As described above, to be the most helpful for run-time debugging with assertion checkers, a continuous assessment of the assertion should be given in real-time at the checker’s output. This is one of the guiding principles used in the approach developed in this work for creating checkers. To continue a discussion stated in Section 2.3, the second checker could in fact not report anything during the trace and only upon receiving the EOE signal, would a response be given as to the success or failure of the property. The run-time semantics of temporal languages like LTL, PSL and SVA are often not defined and tools are free to evaluate them as seen fit. In this case, we prefer the continuous monitoring since assertion failures are often the starting point in the debugging process.

Chapter 3

Basic Techniques Behind Assertion Checkers

Abstract This chapter presents the main ideas of the existing techniques that are useful for automatically generating checkers from assertions. The first section presents background topics relating to regular expressions and finite automata. The next two sections deal with two fundamentally different approaches to checker generation, namely the modular and automata-based approaches. The former attempts to recursively construct the checker for a given assertion using modules for each operator, while the latter constructs an automata-based recognizer/acceptor.

3.1 Background We now discuss the basic techniques that are the candidates for devising efficient assertion checkers. These techniques were applied in a variety of scenarios related to areas as diverse as protocol controller compilation, database search, network intrusion detection, protein and DNA recognition etc. These applications fall under common underlying algorithmic problems that in the broadest sense can be categorized as sequence matching problems. The sequences used in the PSL and SVA assertion languages are based on regular expressions; regular expressions are first presented in Subsection 3.1.1, along with classical finite automata. In general, this chapter also describes two major approaches to generating checkers. First, there is the method that attempts to recursively compile a checker by concentrating on the sub-expressions forming the assertions and building and interconnecting modules for each operator. This is referred to as the modular technique. The second method is based on constructing an automaton, acting as an acceptor, or recognizer of a sequence. Although automata-based methods are currently used in the checker generator presented in the rest of the book, the modular approach was used throughout the development of the tool, with reasonable success [29]. Formal verification and model checking techniques make heavy use of various types of automata, and these are also surveyed in Subsection 3.1.2. Miscellaneous topics are 37

38

3 Basic Techniques Behind Assertion Checkers

relegated to the final section, where a variety of different languages are also briefly presented.

3.1.1 Regular Expressions and Classical Automata Assertion languages such as PSL and SVA make heavy use of sequences to specify temporal chains of events. Regular Expressions (REs) are the basis upon which PSL’s Sequential-Extended Regular Expressions (SEREs) are built, and are an important preamble. Conventional automata are presented in this subsection as well, and will be used further as a base upon which to define the automata framework used for creating assertion checkers. Although many differences will arise, a comparison to conventional automata will help clarify the presentation of the automata developed for assertions. The themes in this subsection are based on the theory of automata, languages and computation [100]. A string is a sequence of symbols from an alphabet Σ , including an empty string, denoted as ε . A regular expression RE is a pattern that describes a set of strings, or a language of RE, denoted L(RE). For example, if the alphabet consists of the ASCII characters, regular expressions efficiently represent a set of strings that can be searched for in string matching. Definition 3.1. Regular Expressions (REs) and their corresponding languages are described as follows, where r is a regular expression: • • • • •

A symbol α from Σ is a RE; L(α ) = {α } ε and 0/ are REs; L(ε ) = {ε } and L(0) / = 0/ (set union) r1 |r2 is a RE; L(r1 |r2 ) = L(r1 ) ∪ L(r2 ) (set concatenation) r1 r2 is a RE; L(r1 r2 ) = L(r1 )L(r2 ) (Kleene closure) r1 ∗ is a RE; L(r1 ∗) = (L(r1 ))∗

The Kleene closure (Kleene star) is an operator that creates the strings formed by concatenating zero or more strings from a language. Parentheses can also be used for / grouping, and as usual, 0/ denotes the empty set. It should be noted that L(ε ) = L(0), as the former describes a non-empty language formed by the empty string, whereas the latter describes the empty language (called null language in this work). A regular expression’s language can be captured equivalently, in a form suitable for computation, by a finite automaton that accepts the same language. Definition 3.2. A classical Finite Automaton (FA) is described by a quintuple A = (Q, Σ , δ , q0 , F) as follows: • • • • •

Q is a non-empty set of states Σ is the alphabet δ ⊆ Q × {Σ ∪ {ε }} × Q is the transition relation q0 is the initial state F ⊆ Q is the set of final states

3.1 Background

39

The non-empty set Q is a finite set of locations (states). The alphabet Σ is the same alphabet that was described above for regular expressions. A transition (or edge) is represented by an ordered triple (s, σ , d), and the transition relation consists of a subset of triples: {(s, σ , d) | s ∈ Q, σ ∈ {Σ ∪ {ε }}, d ∈ Q} The transition relation is sometimes expressed as the mapping Q × {Σ ∪ {ε }} → 2Q . The transition relation indicates which destination state(s) to activate, for each state and for each input symbol that is received. The transition relation does not need to be complete and a state does not always have to activate other states. Identifiers s and d refer to the source and destination states of an edge, respectively. An edge also carries a symbol σ taken from the alphabet {Σ ∪ {ε }}. If an edge carries the ε symbol, then the state transition is instantaneous. When matching against an input string, no input symbol needs to be processed for an ε transition to take place. For a non-ε edge whose source state is active, a given transition takes place when the input symbol is identical to the edge’s symbol. The automaton has a single initial state. When the pattern matching begins, this is the only active state. A subset of states can also be designated as final states. When a final state is active, the pattern described by the automaton has been matched. Final states are also called accepting states, and they can be seen as accepting the language modeled by the automaton. The automaton represents a pattern matching machine that detects all strings that conform to the language represented by the automaton. In other words: if A is an automaton built from a regular expression r, then L(r) = L(A). More generally, the input string in pattern matching is called a word, and an element of the word is called a letter. The alphabet’s symbols are all mutually exclusive and one and only one letter is processed at a time by the automaton. At each step the automaton transitions into a new set of active states. The convention used in this work is to represent the initial state using a bold circle and final states using double circles. A regular expression is converted into an equivalent automaton in a recursive manner, as shown in Figure 3.1. First, terminal automata are built for the symbols of the regular expression, as shown in part a. The empty automaton and the null automaton are acceptors for the languages L(ε ) and L(0) / respectively, and are shown in parts b and c. Next, these terminal automata are inductively combined according to the operators comprising the given RE. The Kleene closure of an automaton is created by adding ε edges for bypassing the automaton (empty matching), and re-triggering the automaton (multiple consecutive matches); this is illustrated in part d of Figure 3.1. Choice and concatenation of two argument automata involve combining the automata using ε edges, as shown in parts e and f. The construction procedure described above, called the McNaughton-Yamada construction [125], produces a Nondeterministic Finite Automaton (NFA) containing ε transitions. An automaton can be determinized, hence producing a deterministic finite automaton (DFA).

40

3 Basic Techniques Behind Assertion Checkers a) terminal symbol

b) empty

c) null ε

sym

d) Kleene star (A*) ε ε

e) choice (A|B) ε

A

ε ε

ε

A

ε

B

ε

f) concatenation (AB) A

ε

B

Fig. 3.1 Automaton construction steps (McNaughton-Yamada construction).

Definition 3.3. An automaton with a single initial state and no ε transitions, and where no state can simultaneously transition into more than one successor state is a Deterministic Finite Automaton (DFA), otherwise it is a Nondeterministic Finite Automaton (NFA). This definition is broad in nature and will apply equally to the automata introduced in Chapter 5. A corollary to Definition 3.3 can be made for classical automata, where the alphabet symbols are mutually exclusive entities that are received one at a time by the automaton, and thus no two symbols can occur at once. Corollary 3.1. By extension from Definition 3.3, a classical FA is a Deterministic classical Finite Automaton when it has a single initial state and no ε transitions, and when no more than one outgoing edge from a given state carries the same symbol, otherwise it is a Nondeterministic classical Finite Automaton. The definition for DFAs (Definition 3.3) is consistent with Watson’s work [173], but is different than what is proposed by Hopcroft et al. [100]. For some authors, the definition of DFAs is such that every state must transition into precisely one successor state (as opposed to at most one successor state). When every state in a DFA transitions into precisely one next state, the DFA is said to be complete. In this work, determinization does not imply completeness and a separate definition is therefore used. Definition 3.4. A DFA for which every state transitions into precisely one successor state at each step is a complete DFA. The corollary of completeness in the case of classical automata follows naturally. Corollary 3.2. By extension from Definition 3.4, a classical FA in which every state has one outgoing transition for every symbol is said to be a complete classical DFA.

3.1 Background a)

41 b)

b b 1

2 a

b

a

b 3

1

2 a

a 3

a b

a 4

b

Fig. 3.2 Determinization does not imply completeness. (a) DFA for a(b∗)a, (b) complete DFA for a(b∗)a.

The two corollaries above are mainly presented to emphasize a key difference with the automata that will be introduced in Chapter 5. For now, suffice to say that for classical automata, the corollaries have the same effect as their related definitions; however for assertion automata, where the symbol alphabet is not mutually exclusive, the corollaries are not strong enough. It will be assumed that a procedure for transforming a DFA into a complete DFA can be easily devised. In classical automata, this goal can be accomplished by adding a dead state to a non-complete automaton, then adding transitions to the dead state for all unused symbols in each state’s outgoing edges, and then adding loop-back edges to the dead state for all symbols. The following example illustrates the nuances between DFAs and complete DFAs. Example 3.1. The regular expression a(b∗)a describes the pattern of all strings that start with the character a, followed by any number of b s, and finishing with an a. Figure 3.2a shows a DFA corresponding to the given regular expression. This DFA is consistent with Corollary 3.1 for deterministic automata, because no state has two outgoing edges with the same symbol. Figure 3.2b shows a complete DFA that accepts the same language as the DFA in part a). In each state, precisely one outgoing transition always takes place when a character is received. Converting an NFA to a DFA requires that ε transitions be removed. The procedure for removing ε -transitions is based on ε -closure [100, 169]. Since ε transitions will not be used in the automata developed in this work, ε -removal will be not be treated further. An ε -free NFA is converted into an equivalent DFA using the subset construction technique [100, 169]. Subset construction is the central procedure in the determinization algorithm. In a deterministic automaton, at most one outgoing transition must take place in a given state, for a given symbol. In order for multiple outgoing transitions with the same symbol to activate a single destination state, a state in the DFA represents a subset of states of the NFA. This way, the criterion for single destination states is respected. Subset construction yields a DFA that has in the worst case an exponential number of states compared to the original NFA. The following example illustrates the conversion of an NFA with ε transitions into an equivalent DFA. Example 3.2. The starting point for the determinization example is the regular expression (a|ε )b∗b, which describes the pattern consisting of one or more b s

42

3 Basic Techniques Behind Assertion Checkers b) NFA after ε-removal

a) NFA for: (a|ε)b*b b a

b b

1

ε

a b

b

2

3

b

c) Subset construction steps applied to NFA in b) a 1

2

1

a

2,3

a b

1 b

2

b

b

1

2,3

2

b

2,3

b

Fig. 3.3 NFA to DFA example using epsilon removal and subset construction.

optionally preceded by an a (the Kleene star applies only to b). Figure 3.3a shows the NFA corresponding to this regular expression. Figure 3.3b shows the effect of ε removal, which in this case can be accomplished by replicating the outgoing edges of the second state in the first state, and removing the ε edge. Figure 3.3c shows the steps taken by the subset construction technique to determinize the automaton. The algorithm first starts by building the initial state of the DFA, which is directly the initial state of the ε -free NFA. Since there are two outgoing edges with symbol b in that NFA, leading to states 2 and 3, a new state in the DFA is created for this subset, and is labeled “2,3”. The single edge with b in state 1 in the DFA now adheres to the conditions for determinism in Corollary 3.1. State “2,3” is marked as a final state because at least one of the states in the subset is a final state in the ε -free NFA. The single outgoing edge with a is not affected and appears similarly to its ε -free NFA counterpart. In state 2 in the ε -free NFA, b leads to the subset {2, 3} of states, thus in state 2 in the DFA, the edge with b leads to state “2,3”. State “2,3” is handled next: when both states 2 and 3 from the ε -free NFA are considered as a whole, edges with b lead to states 2 and 3. A state for this subset already exists, and the self-loop with b is created. The automaton at the bottom right is therefore the equivalent DFA for the NFA at the top left, and illustrates a simple case of ε -removal and subset construction. An operator that does not usually appear in the definition of REs is complementation. If r is a regular expression and A is the equivalent automaton, and L(A) is the language accepted by the automaton (hence L(r) also), then the complemented automaton A accepts the language L(A), where L = Σ ∗ − L. The full language Σ ∗ represents every possible string that can be formed using the alphabet Σ . The complemented automaton A can be computed from A using the following algorithm: 1. Determinize A 2. Make A complete 3. Complement the final states: F ← Q − F

3.1 Background

43

The determinization and completion of automata are described here without showing full algorithms. These types of algorithms are formally stated and extensively covered in the automata theory used for checkers in Chapter 5. An example showing the effect of the automaton complementation algorithm above is shown next, as a continuation of Example 3.2. Example 3.3. If the NFA in Figure 3.3a is to be complemented, after step one of the complementation algorithm above, the right-most automaton in Figure 3.3c is produced, as was explained in the determinization example (Example 3.2). In step two of the complementation algorithm, the completion adds a dead state (state 3) and the necessary edges so that a complete DFA is produced. This is shown in Figure 3.4a. The last step of the complementation algorithm involves complementing the set of final states such that final states become non-final states and vice versa. The resulting automaton that accepts the language L((a|ε )b∗b) is shown in Figure 3.4b. This corresponds to all the strings except those consisting of one or more b s optionally preceded by an a. Another operator not typically used in regular expressions is intersection. If r1 and r2 are REs, then r1 &&r2 is a RE, where L(r1 &&r2 ) = L(r1 ) ∩ L(r2 ). The ∩ symbol represents set intersection. The double ampersand notation was chosen here to more closely relate to the length matching intersection operator found in PSL. The intersection of two regular expressions corresponds to the strings that are in both languages of the REs. It should be noted that the intersection and complementation of regular languages also yield regular languages. In automaton form, the intersection operation is performed by building a product automaton from both argument automata. This product automaton is built by simultaneously traversing both argument automata and exploring all paths that have common symbols. In the product construction, a state is labeled using an ordered pair (i, j) where i represents a state from the first argument automaton and j is a state in the second automaton. The algorithm starts by creating an initial state that references both initial states in the input automata. From there, all transitions with a given symbol that simultaneously advance both automata are explored and used to construct new states and edges in the product automaton. A new state is a final state only if both referenced states are final states in their respective automata. In the worst case, the product construction can create an automaton with mn states, where m and n are the number of states in both argument automata.

a)

b) a

1 b

0 b

2

a

a a

3 b

a b

1 b

0 b

2

a

a a

3

b

b

Fig. 3.4 Complementation example, as a continuation of Example 3.2. (a) After completion, (b) the resulting complemented automaton.

44

3 Basic Techniques Behind Assertion Checkers

a) NFA for: abc a

b

c

b) NFA for .*abc c b a a

b

c

Fig. 3.5 Continuous matching example. (a) Single match starting in the first input letter, (b) continuous matching.

Some RE specifications, such as POSIX regular expressions, add extra operators to simplify the writing of REs. The “.” is used to match any symbol, the “?” is used to match zero or one instance of a symbol, the “+” matches one or more instances and a range of characters can be easily specified in square brackets such as [0–9], which matches any numeric character. When using automata to perform pattern matching, if the regular expression describes a pattern to be matched anywhere in the input stream, a prefix repetition becomes necessary. For example, Figure 3.5a shows the automaton for the regular expression abc. The automaton’s initial state is deactivated after the first input letter is processed because there are no loop-back edges to re-activate it. The pattern abc will only be checked starting in the first input letter. In order for every occurrence of the pattern to be matched, the regular expression .∗abc should be used, where the “.” matches any symbol in the alphabet Σ . In Figure 3.5b the added prefix “.∗” in effect causes the automaton to be retriggered at every step, and allows the intended expression abc to be matched starting at any point in the input stream. Chapter 4 presents the main features of the PSL and SVA assertion languages. As will be shown, regular expressions play a key role in creating temporal regular expressions over Boolean propositions.

3.1.2 Automata in Model Checking Various types of automata have been used to implement PSL in the context of model checking [51]. Figure 3.6 shows how these different types of automata are related among themselves and to the conventional NFAs and DFAs. Many of these types of automata are used in the context of infinite words (more precisely, they accept omega-regular languages), which differs from the behavior required for dynamic verification. These automata define a set of accepting states and a set of final states. An accepting state (as opposed to a final state) must be visited infinitely often in order for the automaton to accept the infinite run. B¨uchi automata are often used in automata constructions for PSL model checking [39, 48, 166, 175]. Extensions to runtime property monitoring were also explored [121], including the recent notion of testers [175]. The definition of alternating B¨uchi automata reported below is adapted from a document related to the PROSYD project [166]. At the top of the hierarchy

3.1 Background

45

Alternating Büchi Automata

δ: Q × Σ → 2Q

Q is a finite nonempty set of states Σ is the finite nonempty alphabet δ: Q × Σ → B(Q) is the transition function q0 is the initial state F ⊆ Q is the set of final states A ⊆ Q is the set of accepting states A ←∅

Büchi Automata

Alternating Automata >

Universal Automata

>

Existential Automata

NFAs, DFAs

>

B(Q) is the set of Boolean formulas obtained using and on states Q

B(Q) uses only

>

B(Q) uses only

Fig. 3.6 Relations between the types of automata used in formal methods and conventional NFAs/DFAs.

is the Alternating B¨uchi Automaton (ABA), which is a nondeterministic automaton, with the transition function defined using B(Q). The function B(Q) in Figure 3.6 represents the set of all Boolean functions obtained by using conjunction (∧) and disjunction (∨) on the set of states Q. As shown in Figure 3.6, B¨uchi automata are a particular case of ABA where the transition function maps only to subsets of states in the automaton (as opposed to Boolean functions of states). Alternating automata [170] are also a particular type of ABA, and are suitable for finite traces. Alternating automata consequently do not define a set of accepting states, only the set of final states is used. Universal automata are a particular type of alternating automata in which only Boolean conjunction is allowed in B(Q). Universal automata are also used in formal property verification [14, 39, 154] and in dynamic verification [7]. Existential automata are another particular type of alternating automata, and in this case only Boolean disjunction is allowed in B(Q). The NFAs and DFAs introduced in Subsection 3.1.1 fall into this category, as do the automata for assertions developed in Chapter 5. In the transition function Q × Σ → 2Q (as shown in Subsection 3.1.1), the disjunction is implicit between the members in the set of states that appear in the range of the function. Alternating automata are used in the Sugar translator developed by Kargl [116], in further research on dynamic verifiers for PSL [113], and in the VIS tool [167]. In essence, the automata used in model checking compare to the dynamic checkers in a fairly analogous way as CTL relates to LTL. In dynamic verification, where time advances linearly, these types of automata eventually are not explored to their fullest. Further, our belief is that they are not fully suitable for a direct implementation in hardware since they must be de-universalized.

46

3 Basic Techniques Behind Assertion Checkers

Furthermore, although the procedures exist for converting ABA and alternating automata into existential automata [7], the run-time semantics exhibited by the automata developed for model checking do not offer the run-time behavior we wish to support in our checkers for dynamic verification, where assertion errors are to be reported in real time throughout the execution trace. For this purpose, a special algorithm called F IRST FAIL () will be developed in Chapter 6, and an example will be made (Example 6.2 in Chapter 6) showing why automata complementation, as typically used in the automata developed for formal methods, is not ideal for use in our checkers. One aspect of some of the automata used in model checking [14,154] that is also very relevant to the automata developed in Chapter 5, concerns the nuances between semantic and syntactic alphabets. In conventional REs and languages, the symbol alphabet consists of a set of mutually exclusive tokens, and can be referred to as a syntactic alphabet. In SEREs, the syntactic elements are Boolean expressions whose truth values are independent and hence not mutually exclusive. In these cases, the semantic alphabet is different than the syntactic alphabet, and automata algorithms must take this into account. In automata that are based on semantic alphabets, determinization must take into account the fact that different symbols can simultaneously be true (as mentioned by Ruah et al. [154]). In Chapter 5, semantic alphabets are also called symbolic alphabets. The notion of vacuity in model checking is treated by Kupferman and Vardi [120]. An informal definition of vacuity is given next that applies to both static and dynamic verification. Definition 3.5. A property implication is vacuously true (a vacuous success) when the conditions in its antecedent are never satisfied. In static verification, if an antecedent condition can never be true in a model, this indicates either a problem in the model or that the property is irrelevant. In dynamic verification, if an antecedent condition never occurs, this indicates either that the test scenario is not exercising the design sufficiently, or that the property is also irrelevant. Either way, vacuity could imply a poor quality DUV, including that of its specification [8]. Identifying vacuity in circuit-level assertion checkers can be accomplished using two debug enhancements that will be presented in Section 7.4. The notion of vacuous success is associated to properties that make use of property implications. The notion of trivial validity is developed for model checking by Beer et al. [10], and extends the definition of vacuity to cover other cases where properties are trivially true. Examples of vacuity and trivial validity are shown next, with their reasoning. Example 3.4. The following properties are assumed to be relevant to the design being verified: always {a&&b} |=> (p until c) never {{a} && {a;a}}

3.2 Modular Approach to Checker Generation

47

The first property is used to exemplify vacuous success and trivial validity. If signals a and b can never simultaneously be true in the model, then the entire property holds vacuously and is of no use. In simulation, if a and b are never simultaneously true then the effectiveness (and coverage) of the testbench can be questioned. If a and b do occur simultaneously, but c always occurs in the next cycle then the sub-property p is never checked and is deemed trivially valid. The second property is a tautology because the length matching intersection of two different-length SEREs can never hold, and is also trivially valid. A common theme in the automata used in the next two chapters and much of the referenced work [13, 14, 104, 116, 154, 167] is that Boolean expressions are used on automata edges. As will be shown, one particularity in this work concerns the encoding of symbols appearing in automata transitions. The checkers produced by the algorithms in this book exhibit a run-time assertion-monitoring behavior that is well suited for the hardware execution of checkers.

3.2 Modular Approach to Checker Generation In the modular approach to checker generation, each assertion operator is implemented as its own separate sub-module (or sub-circuit), and is connected to other modules to form a checker for a complete assertion. Typically, the modules have a predefined signaling protocol whereby activations and result signals are exchanged. This often consists of a single wire, or a pair of wires. The main feature of this approach is that each sub-module retains its internal integrity and is used as a black box for the operators it implements. The actual content of the black box is transparent to the other modules to which it is connected. The sub-modules are interconnected according to the syntax tree of the assertion, in a recursive process. Once the complete circuit is constructed, a checker is produced and the output signals can be observed during verification for finding errors. The HORUS checker generator is being developed at the TIMA-VDS laboratory in France by researchers Borrione and Morin-Allory, and their associates. Besides generating Verilog or VHDL observation monitors, the tool also generates code for test sequence generation [137]. Although their tool is still under development, a number of publications detail their approach to checker generation. These are briefly overviewed in the next two paragraphs. Implementing SEREs using the modular approach first consists of building a library of sub-modules to represent the different SERE operators, which are then used to build a network according to the syntax tree of the SERE being implemented [131]. The interconnection protocol is based on tokens that are passed from one module to the next. Colored tokens are used when sequences are used as properties (in the consequent of a suffix implication for example). The colored tokens are used to maintain the correspondence between different overlapping activations. Although it is mentioned that all SERE operators are supported, no benchmarks are performed. Furthermore, when multiple concurrent matches are taking

48

3 Basic Techniques Behind Assertion Checkers

place, a large number of colors must be supported in the tokens, which represents a non-negligible hardware overhead in the circuit representation. The token approach shares a commonality with the assertion threading debug enhancement developed in Subsection 7.4.5 because both techniques can help correlate a failure with its given start condition. Although the techniques involved are very different, the parallel between the two is very interesting and was observed by Borrione [22]. Another set of publications from the TIMA group presents a modular implementation of PSL foundation language properties [23, 24, 130, 132]. A pair of interconnect signals is used, and assertions produce a pair of signals that indicate the status of the assertion. The approach consists of developing sub-modules for each property operator and interconnecting the appropriate modules to form a complete checker for an assertion. Moreover, the functional correctness of the methods is proved using formal methods in the PVS proof system. The library of components for property operators is proven correct, and then the interconnection scheme is proven correct, and by induction the checkers that are generated are proven correct. The earlier publications reference Gascard’s work [79] for the implementations of SERE, which is reviewed in the next section. Experimental results are reported [23, 24] for properties, whereby the checkers produced are compared to those produced by FoCs v2.02. Although both strong and weak properties are supported, strong properties are not benchmarked. The checkers are implemented using the Synopsys Design Compiler and the size metric reported is based on two-input NAND gates. Generating interface monitors for verifying proper protocol between design modules is the topic of the research work by Oliveira and Hu [139, 140]. This work is based on conventional regular expressions with an added pipelining operator and storage variables, and does not use PSL nor SVA. The modular scheme is also employed, and activations are passed from one sub-circuit to the next to perform the required pattern matching. Restrictions on pipelining and threading in the monitoring circuits are imposed such that efficient monitors can be built. Experimental results are performed [139] for the AHB and OCP bus protocols, where items from the respective specifications are modeled in the custom language. Only the number of flip-flops is reported in the hardware metrics for the monitor circuits that are produced. The checker generation of SVA (SystemVerilog Assertions) is explored by Das et al. [61]. Sub-modules corresponding to the different sequence1 constituents are interconnected with wires labeled “start” and “match”. Sequence operators are classified into subsets that have different synthesis approaches, and a special subset for sequences containing unbounded repetition operators is declared. An indication that the modular approach has its challenges is exemplified by the fact that the authors mention cases where expressions from the unbounded subset can not be synthesized into a finite amount of hardware resources. As will be shown in the following chapters, this limitation is not present when automata are used. Synopsys Design Compiler is also used to synthesize a set of benchmark assertions, and the Synopsys VCS simulator is used to compare the checkers with OVA checkers (OpenVera 1

SVA also defines sequences, which are similar to PSL SEREs.

3.3 Automata-Based Approach to Checker Generation

49

Assertions [164]). In those results, assertions for the ARM AMBA AHB bus interface are used. Among the interesting findings [61] is the description of the “not” operator for matching sequences in the consequent of suffix implications. Separate rules are given to handle the “not” operator for each sequence operator, however no explanations nor insights into the correctness of the proposed rules are given. The run-time semantics produced by the rules is also not addressed. The only SVA properties that are supported are the two forms of suffix implication. The implementation of SVA checkers is also explored by Pellauer et al. [145]. The “first-match” operator is used as a basis for implementing sequences in the consequent of suffix implications. Checkers are produced in the BlueSpec SystemVerilog language, which is an un-clocked language where models are subsequently translated into sequential hardware. The implementation is not fully modular as such, but does share a similar barrier that was observed in other modular approaches. The sequence matching is performed using FSMs (Finite State Machines), whereby a single FSM is used to implement the antecedent in suffix implications, and multiple FSMs are used in the consequent. Since a finite number of FSMs in the consequent are used to process the matches triggered by the antecedent, unbounded repetition is disallowed in the antecedent FSM. The authors also introduce the concept of statistic-gathering assertions by integrating counters within the checkers. A case study on a cache controller is presented, and hardware synthesis results showing the overhead added to the design are measured, both for the normal functional assertions and the statistic-gathering assertions. Assertion checkers must be able to handle multiple concurrent sequences of events that can overlap temporally. In general, the interconnected module approach shows difficulties for implementing certain operators, especially when dealing with the failure matching of sequences that use unbounded repetitions and intersection (the [*] and && operators). This difficulty was observed in the first version of the checker generator in this work [29]. Using automata-based methods is one possible way around this problem, and the checker generator developed in this work does not have the limitations mentioned throughout this section.

3.3 Automata-Based Approach to Checker Generation Regular Expressions (REs) are used in a temporal manner in assertion languages. As a first step to producing hardware assertion checkers, hardware for the matching of regular expressions is first explored. Although hardware RE matchers are not assertion checkers as such, they can still be considered as checkers in some respect. Among the earliest work in designing custom circuitry for performing hardware RE matching is the compilation REs into integrated circuits by Floyd and Ullman [72]. One of the target applications is the PLA (Programmable Logic Array), which implements logic by interconnecting fixed rows and columns of wires and gates. In another implementation, the circuit’s layout structure is directly guided by the hierarchical NFA construction from REs (as shown in Figure 3.1 in

50

3 Basic Techniques Behind Assertion Checkers

Subsection 3.1.1). The experimental results in their work show that the area of the generated circuits grows linearly with the size of the regular expression. The hierarchical nature of the circuit construction uses signals to interconnect sub-automata, and has similarities to the modular approach; however, the modular implementation of RE intersection (not treated) would likely not be possible given that no simple pictorial representation of NFA intersection exists, as does exist for the conventional RE operators (Figure 3.1). A more modern hardware implementation of regular expression matchers is presented by Sidhu and Prasanna [161] for FPGA technology. This approach is also based on the McNaughton-Yamada construction of NFAs from REs. The surprising theme in their work is that the actual NFA construction can be performed in hardware, and the Self-Reconfigurable Gate Array (SRGA) can be automatically reconfigured in real time to pattern-match a new expression. Many comparisons are performed in the experimental results, one of which is a comparison to softwarebased pattern matching with DFAs. Software pattern matching often makes use of DFAs so that a single state can be tracked more easily, with the disadvantage that the DFA may be exponentially larger than its NFA counterpart. In hardware, simultaneously tracking multiple states is inherently done by the parallel circuitry, thus the smaller NFAs are often preferred. FPGA-accelerated pattern matching is used [163] to perform efficient network intrusion detection based on regular expressions. Both instances of previous work [72, 161] have in common that NFAs are implemented in hardware to performs RE matching, and that ε transitions can be handled. The intersection and complementation operators in regular expressions are not treated. The work by Sidhu and Prasanna [161] is perhaps the most influential for the translation to circuits of the automata developed in the Chapter 5. Other research by by Gheorghita and Grigore [82, 83] deals with the translation of PSL into automata. SERE intersection and fusion are treated, and their fusion algorithm [83] has similarities to the one developed in this work in Chapter 6. The details for the implementation of property operators are not given, with the exception of suffix implication [83]. Although a separate algorithm is used to implement suffix implication, in Chapter 6 it will be shown that suffix implication does not require a separate algorithm and can actually be implemented using the automata fusion algorithm. Moreover, in the most detailed reference [82], only SERE intersection is explained in algorithmic form. Although Boolean expressions are used on the edges of the automata, the implications for conventional automata theory are not developed. The minimization technique that is used consists of a set of ad-hoc rules, and no link is made to conventional DFA minimization. Experimental results show that the automata that are produced have more states compared to the checkers generated by the FoCs tool, which is presented further in this section. PSL has been modeled in higher order logic for the HOL theorem prover by Gordon et al. [87]. Once the semantics of PSL are captured in this formal reasoning tool, various proofs and “sanity checking” experiments can be made. In this framework, the semantics of PSL is said to be executable. HOL can also be used to produce a DFA from a PSL expression. The DFA can then be used to process a simulation

3.3 Automata-Based Approach to Checker Generation

51

trace in HOL to determine whether a given PSL assertion holds. In another application [87], a DFA can be converted to HDL thereby producing an assertion checker. The automata produced in the work by Gheorghita and Grigore [83] and Gordon [87] can be used to check a property during simulation. These types of checkers indicate the status of the property at the end of simulation only, and are not ideal for debugging purposes. It is much more informative to provide a dynamic trace of the assertion and to signal each assertion failure: having a choice of violations to explore eases the debugging process, as some errors may reveal more than others. The time required to generate checkers is larger [83], sometimes significantly so [87] than with FoCs. The tool that compares the most to the one developed in this book is the FoCs checker generator from IBM [1, 60, 103]. Since FoCs is a commercial tool, very few publications disclose its inner-workings. One particular characteristic that can be deduced from the literature [60, 104] is that FoCs also employs automata to generate HDL checkers from PSL assertions. The checkers produced by FoCs utilize an end-of-simulation signal which marks the end of time when strong properties are used. As explained previously, this signal is supplied by the user and is used by the checkers so that any unfulfilled obligations can be reported as errors when no further cycles will be run. The end-of-simulation signal is also used in this work in Chapter 6, and is referred-to as an End-Of-Execution (EOE) signal. At the time of this writing, the current version of FoCs is 2.04. FoCs does not currently support all property operators, and supports very few strong properties. The abort keyword is also not fully supported. In Chapter 8, the checkers produced by FoCs are compared to those produced by the tool developed in this work. The comparison involves generating checkers for a suite of assertions, and then synthesizing the checkers using FPGA implementation tools. The circuit size of the checkers is then compared using the number of flip-flops and combinational logic cells as metrics. Dating back to the early version of the checker generator [29], benchmarking against the FoCs tool has been a driving factor that has actually led to improvements in both tools. The results in Chapter 8 will show that the checker generator developed in this work outperforms FoCs. In the PROSYD work [104], it is stated that the algorithms contained in that document are based on the algorithms implemented in the FoCs tool. The PSL algorithms are introduced in the context of generating checkers for simulation. The conversion of an NFA to a Discrete Transition System (DTS) is presented as the central result. A DTS is a symbolic program that represents an NFA, and is used during simulation for performing the assertion monitoring. The conversion of PSL assertions to NFAs is not developed, and only references other related model checking work [13]. The automata therein are developed for model checking and in the PROSYD document [104] it is not apparent how they are adapted for use in dynamic verification. In the IBM technical report [13] that serves as the basis for the PSL to NFA conversion used in the PROSYD project [104], two important issues are not treated: length-matching intersection of SEREs, and the use of a sequence directly as a property (as the right-hand side of temporal implication, for example). An important

52

3 Basic Techniques Behind Assertion Checkers

characteristic of the automata used is that Boolean expressions are used to form a non-mutually exclusive symbol alphabet, a theme that is central to the automata defined in Chapter 5. Other research was conducted by Gascard [79] on the transformation of SEREs to DFAs. This work is based on derivatives of regular expressions introduced by Brzozowski [37]. The derivative of a regular expression is a way of removing a given prefix in the language described by the regular expression. The result is also a regular expression. When applied repeatedly, this technique can be used to create a DFA from a regular expression. As will be shown in Chapter 6, derivatives are not required to transform SEREs into DFAs. For one, algorithms will be devised to transform SEREs directly to NFAs that can subsequently be determinized when needed. Second, producing DFAs is not a prerequisite for RTL implementations since it was shown that NFAs are perfectly suitable for a circuit-form implementation [161]. It is a common solution to create a symbol encoding which represents the power set of the Boolean primitives, such that one and only one symbol is received at each step during the matching [79, 118]. This is referred to as the power set alphabet in Chapter 5, and allows conventional automata theory to be used over Booleans. The power set alphabet will not be used; however, it is formally defined in Chapter 5 so that it can be compared to the symbolic alphabet. In essence, the power set alphabet maps all the possible valuations of the Booleans to distinct, mutually exclusive symbols, akin to the symbols in pattern and string matching. As will be shown, the disadvantage with the power set method is that an exponential number of edges are required to model a transition for a give Boolean. No benchmarks are performed for the SERE-to-DFA work in Gascard’s publication [79].

3.4 Other Related Research Given the parallels between conventional REs and SEREs over Booleans, the vast literature on converting regular expressions into automata is summarized through a few key references. Berry and Sethi [18] show how to build DFAs from REs using the notion of derivatives of regular expressions [37]. In Raymond’s work [152], although the object of the RE transformations are not automata but rather Boolean dataflow networks, the modularity of the approach has parallels to the modular approaches discussed in Section 3.2. The McNaughton-Yamada construction [125] shows how to produce an NFAs containing ε transitions from REs. The first four chapters in the Hopcroft textbook [100] also present automata, regular expressions and languages, and is the classic reference used for when these topics are introduced to students. Generating monitor circuits from Generalized Symbolic Trajectory Evaluation (GSTE) specifications is researched by Hu et al. [102, 136]. GSTE specifications are represented using assertion graphs, and consist of automata with antecedent and consequent symbols on the edges. Symbolic constants can also be used to allow more general and powerful properties to be specified. The monitor construction is

3.4 Other Related Research

53

based on a modular assembly of sub-circuits corresponding to the structure of the assertion graph. A token-based approach is also used, and is evocative of the tokenbased implementation of SEREs described in Section 3.2. An important topic covered by Hu et al. is the development of a simulation-friendly specification for GSTE to allow efficient monitor circuits to be built. This is not unlike the simple subset guidelines defined for PSL in order for assertions to be more suitable for dynamic verification. Production Based Specification (PBS) developed by Seawright and Brewer, advocates the use syntax productions to perform actual circuit design [158–160]. The language used has many similarities to SEREs, however certain operators do not behave the same way as in PSL. The sequential-and operator consists of performing the Boolean conjunction of the result of sequences (i.e. in their final cycle), and does not equate to the length-matching intersection found in assertion languages. Furthermore, the sequential-not operator does not correspond to the type of negation required to perform sequence-failure detection, as the negation is performed on the result signal of a sequence. An interesting statement by Seawright [160] reveals that using Boolean expressions as tokens allows an efficient symbolic alphabet to be used. Experimental results include the high-level design of a mouse decoder circuit. As its name implies, the SystemVerilog Assertions (SVA) language is an assertion language that is part of SystemVerilog [107]. Many similarities exist between SVA and PSL assertions [92], most notable of which are sequences. Interestingly, SVA defines an operator called first match that is used to report the first match of a sequence. Although this operator has no direct equivalent in PSL, a corresponding algorithm will be devised in Section 7.4 to implement the completion-mode debugging enhancement. Contrary to the sequences in both languages, SVA properties are not as similar to PSL properties. Although SVA properties define suffix implication and an abort operator, LTL constructs are not yet available at this time (they are expected in the next version of SVA). One advantage with SVA assertions is that an action block allows arbitrary HDL code to be executed when a property fails. Currently, there is no provision for this in the PSL specification; however, using the circuit-level checkers to interpret assertions can be a way around this problem. In checkers, assertion signals are regular HDL signals and they can be used for any purpose, including providing feedback to a testbench to guide the stimulus generation in a closed-loop test scenario. Open Vera Assertions (OVA) is an open source assertion language based on LTL and regular expressions [164]. The language also provides features to reuse libraries of pre-built assertions that can be shared across the verification community. The ForSpec language developed by Intel [6] is also based on regular expressions and linear temporal logic, and was actually a candidate along with IBM’s Sugar language for the first version of PSL that was developed by Accellera (incidentally, it was IBM’s language that was selected). Both the OVA and ForSpec languages are suitable for formal and dynamic verification. Many automata-based implementations of LTL are also developed for formal verification, where properties in finite LTL can be implemented in automaton form for simulation purposes [155].

54

3 Basic Techniques Behind Assertion Checkers

In certain scenarios it may be preferable to avoid using assertion languages altogether, and instead rely on a pre-compiled set of checkers. One such library is the Open Verification Library (OVL) [76]. In this methodology, assertion checkers can be parameterized and instantiated in the design under verification, and then connected to the appropriate design signals. The types of properties that can be used range from generic “always”-type properties to complex bus protocol monitors. Some EDA vendors also have proprietary verification IP (Intellectual Property), such as Mentor’s CheckerWare verification IP library. The disadvantage of these libraries is that pre-defined components may not always be found for certain specialized applications. The checker generator developed in this work can be an ideal way to build and maintain a library of pre-compiled checkers. The e-Language [106] is a programming language used to assist in the verification of hardware designs. It is used to create complex testbenches and functional verification environments for stimulating and analyzing a design’s behavior. Many high-level features allow coverage driven verification and constrained random verification to be performed. The language is built upon a variant of linear temporal logic, and also defines temporal expressions that are to some extent similar to PSL sequences. Hardware monitors are somewhat analogous to the observers developed for monitoring properties of distributed software, as modeled in SDL (Specification and Design Language) for example [90]. Generating monitors from visual specifications and timing diagrams has also been explored [77, 138]. Research is also being performed to incorporate assertions into the SystemC modeling environment [60, 88, 89]. Transaction-level assertions [66] and system level assertions [81] are being developed as well, but are outside the scope of this work.

Chapter 4

PSL and SVA Assertion Languages

Abstract This chapter presents the two main assertion languages that are covered throughout this book, namely the Property Specification Language (PSL) and SystemVerilog Assertions (SVA). The explanation is made to be somewhat comparative, such that the readers can easily find similarities and differences between the two languages. The basic language explanation presented here will be complemented by the details of their compilation and use in the rest of the book, including Appendix A.

4.1 The Property Specification Language As mentioned, the standard hardware assertion language known as the Property Specification Language (PSL) is mainly used for presenting material in this book. The checker generation of SVA is covered in Section 4.2, and some of the advantages related to SystemVerilog’s assertion are discussed therein. A few key advantages associated to PSL are listed below to motivate its main consideration in this work: • PSL was the first hardware assertion language to receive IEEE standardization (IEEE 1850–2005) [108]. • With the use of many flavor macros, PSL offers a language–independent means of specifying assertions, and can be used in VHDL, Verilog, SystemVerilog, GDL and SystemC designs. • PSL incorporates many temporal operators found in formal verification and model checking, such as Linear Temporal Logic (LTL) and Computation Tree Logic (CTL), and is therefore well positioned to serve both the formal verification community and dynamic verification scenarios (ex: simulation). • The PSL language is arguably the most complex and expressive of assertion languages.

55

56

4 PSL and SVA Assertion Languages

The Property Specification Language is by now ratified as the IEEE 1850–2005 standard [108], where it is defined formally and thoroughly. Other presentations of PSL also appear in related textbooks [52, 68, 75, 146]. The presentation of PSL contained in this section is based on Appendix A in the PSL specification [108], which describes the formal syntax of the PSL language in BNF (Backus-Naur Form). The semantics of each operator is explained informally in this section, and is formally specified in Appendix B in the PSL specification [108]. The following considerations were made for the PSL used and presented in this work: • The Optional Branching Extensions (OBE) are not suitable for dynamic verification and are omitted from consideration (Subsection 4.4.3 in the PSL specification [108]). • The simple subset guidelines for “simulatable” PSL were taken into account and applied directly to the language definitions herein (from Subsection 4.4.4 in the PSL specification [108]). These guidelines make it such that PSL can be more easily used in dynamic verification, where in a given state (clock cycle) the future values are not known, unlike in static verification. • Expressions appearing in bounds for ranges and numbers are restricted to integers in this work, as opposed to statically computable expressions. Adding support for expressions involves additional features in the parser front-end, and does not affect the algorithms used in the checker generator. • Sequence and property instantiations are omitted for simplicity. In the current version of the checker generator, non-parameterized sequence and property declarations and instantiations are supported. • The two directives that apply to dynamic verification are supported, namely assert and cover. Other directives are intended for formal methods and are not treated, with the exception of assume, which is handled in the same way as assert [75]. • The clocking operator in sequences and properties is omitted since its implementation in the checker generator is beyond the scope of this work. • Although the PSL language defines flavor macros for supporting many HDLs, the Verilog flavor will be used throughout this work, and all necessary operators will be shown in the Verilog language. The Verilog HDL language is used to specify the Boolean expressions that form the core of PSL’s Verilog flavor. A set of commonly used Verilog operators is shown in Table 4.1, in decreasing order of operator precedence1 ; the full BNF syntax is available in standard Verilog textbooks [20]. Constants in Verilog can be specified directly as numbers, with optional prefixes for indicating the base and the size of the constant. For example, the constant 4’b1010 is a four-bit binary number, whereas ’h55 is an un-sized hexadecimal number. Verilog parameters are handled by the checker generator and can even be used to automatically create parameterized assertion checkers. In the pseudo-code algorithms in upcoming chapters, comments are specified in the same way as C and Verilog comments, by using the double forward slash //. 1

Standard arithmetic operators used in Verilog were omitted from the table for conciseness.

4.1 The Property Specification Language

57

Table 4.1 Commonly used Verilog language operators. Operation

Symbol

Logical negation Bitwise negation Logical equality Logical inequality Bitwise conjunction (and) Bitwise disjunction (or) Logical conjunction (and) Logical disjunction (or)

! ∼ == != & | && ||

Verification directives

Verification layer

Commands for verification tools Properties High-level temporal relationships between sequences and Booleans

Temporal layer

Sequences Sequential regular expressions of Booleans Boolean layer

Booleans Base primitives: Boolean expressions

Fig. 4.1 PSL language hierarchy.

PSL is intended for both formal and dynamic verification; however, since it is mostly used for dynamic verification in conjunction with the checker generator, some operators are best explained in the context of run-time verification. The top level PSL directives that are used to express verification intent are presented at the end of this section, while the elements used to define them are defined gradually starting with Booleans, followed by sequences and properties. The Property Specification Language is defined in layers, each of which deals with separate concerns. These layers are: the Boolean layer, the temporal layer, the verification layer and the modeling layer, as illustrated in Figure 4.1. The modeling layer allows the specification of additional signals and variables, as well as the modeling of design inputs for use in formal verification. The modeling layer is not treated in this work since it has no substantial effect on the assertions themselves. The explanation of the PSL and SVA languages to follow concentrates on the language constructs. More detailed examples of the use of these languages will be spread throughout the remaining chapters, as well as in Appendix A, which includes a complete example, with assertions written in both languages.

58

4 PSL and SVA Assertion Languages

4.1.1 PSL Boolean Expressions The Boolean layer in PSL is built around the Boolean expressions of the underlying HDL, which reference a set of Boolean-valued signals (Boolean propositions). PSL Booleans are defined below, where italicized prefixes indicate an additional constraint on a type. Definition 4.1. If “Number” is a nonnegative integer then Booleans are defined as follows in PSL (“Sequence” is defined further in this section): Boolean ::= boolean Expression Expression ::= Verilog Expression | Boolean -> Boolean | Boolean <-> Boolean | true | false | Built-in function Built-in function ::= prev(Expression) | prev(Expression, Number) | rose(bit Expression) | fell(bit Expression) | onehot(bit vector Expression) | onehot0(bit vector Expression) | stable(Expression) | ended(Sequence) Although not formally part of the specification, symbols true and false are used in this work to better understand the notation. These two symbols are defined respectively as 1‘b1 and 1‘b0, in Verilog notation. The Boolean layer in PSL also defines implication -> and equivalence <-> to be used with Booleans. Built-in functions allow the specification of single or multiple cycle conditions, but are not part of PSL’s temporal layer. The prev operator returns the previous value of the expression argument, one cycle or a specified number of clock cycles previous to the current cycle. The rose, fell and stable operators compare the values of their arguments in the current cycle with the previous cycle. The onehot evaluates to true if exactly one bit in the argument is at logic-1; the onehot0 operator evaluates to true if at most one bit is at logic-1. The ended operator evaluates to true every time its sequence argument is matched. Other built-in operators also exist, such as next, isunknown, countones, nondet, nondet vector, but are omitted from Definition 4.1 for a variety of

4.1 The Property Specification Language

59

reasons. The next operator requires future values for evaluation and is not easily handled in dynamic verification. Although it could be supported in the checker generator by time shifting the rest of the signals in the related assertion, the assertion should be re-written to avoid such an operator when possible. The isunknown function is used to report any values that are not at logic-0 or logic-1, and is also not implemented in the checker generator. The countones function could be implemented using a population count algorithm; however, instantiating such complex HDL code could drastically affect the performance of the checker generator, thus the function is purposely not treated. The nondet and nondet vector operators represent a nondeterministic choice of a value within a value set, and are also omitted for hardware implementation reasons.

4.1.2 PSL Sequences and SEREs Sequential-Extended Regular Expressions (SEREs) and Sequences are used to specify temporal chains of events of Boolean expressions, and are at the core of PSL’s temporal layer. Sequences are built upon Booleans, and are a temporal version of regular expressions. In the remainder of the text, the term sequence (not initially capitalized) will be used to refer to all of the items in the definition below, in a general manner; the term Sequence (initially capitalized) will refer to the actual syntax item in the definition. Definition 4.2. If “Number” represents a nonnegative integer, and normal typeface brackets [] represent an optional parameter, then Sequences and SEREs are defined as follows in PSL: Sequence ::= repeated SERE | {SERE} SERE ::= Boolean | Sequence | SERE ; SERE | SERE : SERE | compound SERE compound SERE ::= Sequence | compound SERE | compound SERE | compound SERE & compound SERE | compound SERE && compound SERE | compound SERE within compound SERE repeated SERE ::=

60

4 PSL and SVA Assertion Languages

Boolean[*[Count]]

| Sequence[*[Count]] | [*[Count]] | Boolean[+] | Sequence[+] | [+] | Boolean[= Count] | Boolean[->[positive Count]]

Count ::= Number | Number : Number | Number : inf The operators for sequences and SEREs in the definition above are not listed in order of operator precedence. Subsection 4.2.3.2 in the PSL specification [108] lists the relative precedence, from highest to lowest: [*] and [+] and [->] and [=], within, & and &&, |, :, ;. Some aspects of SERE notation are equivalent to conventional regular expressions: the [*] operator is a repetition of zero or more instances (i.e., Kleene closure), the | operator corresponds to SERE disjunction (choice), and ; represents concatenation. The curly brackets are equivalent to parentheses in regular expressions. In the context of SEREs, the concatenation of two Boolean expressions b1;b2 produces a match when the Boolean expression b1 evaluates to true in one cycle and b2 evaluates to true in the next cycle. Other SERE operators are seldom used, or have no equivalent in conventional REs. The : operator denotes SERE fusion, which is a concatenation in which the last Boolean expression occurring in the first SERE must intersect (i.e. both are true) with the first Boolean primitive occurring in the second SERE. Empty SEREs in either side do not result in a match. The length matching SERE intersection operator && requires that both argument SEREs occur, and that both SEREs start and terminate at the same time. The single & represents non-length matching intersection, whereby SEREs must start at the same time but do not necessarily end at the same time. The matching occurs when the longer of the two SEREs is matched, provided the shorter SERE was matched. The within operator causes a match when a sequence occurs within another sequence. The shorter sequence starts after (or at the same time) and terminates before (or at the same time), compared to the longer one. In repeated SEREs, the [*Count] operator can be used to model a fixed-length repetition or a repetition range. A successful range match occurs when the expression being repeated is matched a number of times contained in the specified interval. The [+] symbol indicates a repetition of one or more instances. When the various forms of [*] repetition or the [+] repetition are used without a Boolean or Sequence, the Boolean true is implicitly assumed. The [->] operator is known as goto repetition, and causes a matching of its Boolean argument at its first occurrence. A fixed-length goto repetition or a range

4.1 The Property Specification Language

61

of goto repetitions can also be specified, whereby the integers used must be greater than zero. The [=] corresponds to nonconsecutive repetition, which is similar to a goto repetition that can cause additional matches for extended cycles where the Boolean remains false. Example 4.1. The following sequence causes a match at the first occurrence (logic-1) of the reset signal, provided that the busy signal is continually asserted. {{busy[*]} && {reset[->]}} Figure 4.2 illustrates how the sequence above causes a match for an arbitrary start condition. This start condition could originate from the left side argument of a concatenation, if the above sequence was used as the right side in the concatenation. Even though the start condition occurs before the reset becomes true, the goto repetition extends the matching as needed. The length matching intersection with the variable-length left side (with busy) was also observed and helped to produce the successful match. In reality, only a subset of the operators in Definition 4.2 are required to completely specify SEREs and sequences. The following equations are derived from the sugaring rules in Appendix B in the PSL specification [108], and help to understand the semantics of the more convoluted operators mentioned in the previous paragraphs (b is a Boolean, i, j are positive integers and k,l are nonnegative integers such that j ≥ i and l ≥ k)2 : b[*k] b[*i: j] b[->] b[->k] b[->k:l] b[=i] b[=i: j]

def

=

def

=

def

b;b; . . . ;b

(k times)

b[*i] | . . . | b[* j]

=

!b[*];b

def

{!b[*];b}[*k]

=

def

=

b[->k] | . . . | b[->l]

def

{!b[*];b}[*i]; !b[*]

=

def

=

b[=i] | . . . | b[= j]

In PSL SEREs, the [*0] operator is known as the empty SERE and is equivalent to the ε expression from conventional REs. The empty SERE is a primitive Matched

Start matching reset busy busy

Fig. 4.2 Sequence matching for {{busy[*]} && {reset[->]}}. 2

The intervals [i] . . . [ j] could also be written as [i], [i + 1], . . . , [ j].

62

4 PSL and SVA Assertion Languages

that spans no clock cycles. When used as a sequence, the empty SERE is also referred to as the empty sequence. Definition 4.2 also allows the specification of a null sequence, but not directly as an operator. For example, the following sequence reduces to the null sequence 0/ because the length matching intersection of two SEREs of different lengths can not produce a match: {{true} && {true[*2]}} In the PSL specification [108], no symbol is introduced for the null sequence (nor for the null SERE) as it can not be specified directly by the user. The null sequence is similar to the 0/ in regular expressions and their languages (Definition 3.1), and the same symbol will be used in the next chapters to describe such a sequence. The null sequence does not match anything, while the empty sequence represents an instantaneous match (an empty match is a match nonetheless). Definition 4.3. The empty sequence and the null sequence that can be specified using the syntax in Definition 4.2, either directly or indirectly, as described in the previous paragraphs, are known as degenerate sequences [107]. The definition of degenerate sequences above is borrowed from the SVA case, and applies to PSL sequences as well.

4.1.3 PSL Properties PSL’s temporal layer also defines properties built on sequences and Booleans. The PSL foundation language properties are shown below in the Verilog flavor, and are presented with the simple subset modifications for dynamic verification [108]. Similarly to SEREs, properties are built from a reasonably compact set of operators to which sugaring operators are also added. However, because the simple subset imposes many modifications to the arguments of properties, the distinction between sugaring and base operators becomes much less relevant and will not be made. Definition 4.4. If “Number” represents a nonnegative integer, and “ident” represents a valid Verilog identifier, then PSL properties and foundation language properties are defined as follows in PSL’s simple subset: Property ::= forall ident in boolean: Property | forall ident in {Range}: Property | FL Property FL Property ::= Boolean | (FL Property) | Sequence !

4.1 The Property Specification Language

63

| Sequence | FL Property abort Boolean | ! Boolean | FL Property && FL Property | Boolean || FL Property | Boolean -> FL Property | Boolean <-> Boolean | always FL Property | never Sequence | next FL Property | next! FL Property | eventually! Sequence | FL Property until! Boolean | FL Property until Boolean | FL Property until! Boolean | FL Property until Boolean | Boolean before! Boolean | Boolean before Boolean | Boolean before! Boolean | Boolean before Boolean | next[Number](FL Property) | next | next a[Range](FL Property) | next a | next e[Range](Boolean) | next e | next event!(Boolean)(FL Property) | next event(Boolean)(FL Property) | next event!(Boolean)[positive Number](FL Property) | next event(Boolean)[positive Number](FL Property) | next event a!(Boolean)[positive Range](FL Property) | next event a(Boolean)[positive Range](FL Property) | next event e!(Boolean)[positive Range](Boolean) | next event e(Boolean)[positive Range](Boolean) | Sequence |-> FL Property | Sequence |=> FL Property

Range ::= Number : Number The term property (not capitalized) will be used to refer to all of the items in the definition, in a general manner. The term Property (capitalized) refers to the actual syntax item in the above definition. Property instantiation and sequence instantiation can be handled in the parser front-end, and are omitted from the presentation because they do not add any computational complexity to checker generation.

64

4 PSL and SVA Assertion Languages

The properties in Definition 4.4 are not listed in order of operator precedence. Subsection 4.2.3.2 in the PSL specification [108] lists the relative precedence, from highest to lowest: abort, the next family and eventually!, the until and before families, |-> and |=>, -> and <->, always and never. The forall operator has more variations than what was shown above; however, the two versions in the definition are used to convey the main idea behind replicated properties. The ident parameter is simply a unique identifier that is used as a variable in the argument property. The forall operator replicates the property with each successive version taking a different value for the ident variable. Each instantiation of the replicated property is expected to hold, thus the replication creates a multiple conjunction of properties. Since a braced SERE is a valid sequence, the foundation language property: {SERE}(FL Property) was not listed, as it is semantically equivalent to the foundation language property shown below: {SERE} |-> FL Property The standard LTL operators X, X!, G, F, U and W are equivalent to the PSL operators next, next!, always, eventually!, until! and until, as follows: X X! G

≡ ≡ ≡

next next! always

F U

≡ ≡

eventually! until!

W

≡

until

For simplicity, the LTL operators were omitted in Definition 4.4. Furthermore, as indicated in the working group issues for PSL [109], the left side arguments of the operators until and until! do not need to be restricted to Boolean expressions in the simple subset [108]. This change is expected to appear in the next revision of the PSL standard. The async abort and the sync abort are treated the same way as abort in the checker generator, and were omitted. The never and eventually! operators also accept a direct Boolean as their arguments, but for simplicity this was omitted from the syntax above. Parentheses around a property are used only for grouping. The definition also shows that Booleans and sequences can be used directly as properties, thereby indicating that the sequence or Boolean expression is expected to be matched, and that a non-occurrence constitutes a failure of the property. The matching is weak, meaning that if the end of execution occurs before the matching is complete, then the property holds. A sequence can be made to be a strong sequence using the ! operator, thereby specifying not only that the sequence should be matched, but that it should be matched before the end of execution.

4.1 The Property Specification Language

65

The abort operator can be used to release an obligation on a property, when a given Boolean condition occurs. This is particularly useful for re-initializing properties when an external reset occurs in the design under verification. This prevents the checker from continuing to monitor a property across a reset event. In the simple subset, negation and equivalency of properties are not defined, and are performed only with Booleans. These operators have the same semantics as in the Boolean layer, and the resulting top-level Boolean is expected to hold as a property. Therefore, if the Boolean is not matched then the property fails. Property implication and property disjunction allow at most one of their arguments to be a property. In the case of the implication operator, the antecedent must be a Boolean. If the antecedent of the implication occurs, then the consequent property is expected to hold. If the antecedent does not occur, the consequent property holds vacuously. A behavior similar to implication also exists for disjunction. If the Boolean is false then the argument property is expected to hold, and if the Boolean is true then the property holds. In the definition of properties, even though the Boolean is shown as the left side argument of ||, permuted arguments are also acceptable. Property conjunction &&, not to be confused with SERE intersection, is used to specify that two properties must both hold. The always operator specifies how its argument property should behave. When the always property receives an activation it will continually activate (retrigger) its argument property, consequently causing it to always be checked. The activation comes from the next outermost expression in the given PSL statement. The retriggering aspect of this temporal operator is analogous to the sliding window [57] used in certain string matching algorithms, where the matching is to be performed at every position afterwards. Example 4.2. This example shows different types of activations and their effect on the always operator. assert f p assert always f p assert b -> (always f p)

(4.1) (4.2) (4.3)

In (4.1), the property f p is only checked starting in the initial clock cycle. The property is only expected to hold starting in that cycle, and depending on its temporal length and the circuit conditions, it may signal an assertion failure at that time, or any amount of clock cycles in the future. In (4.2), the property always f p is itself activated on the initial clock cycle, and proceeds to continually activate the checking of property f p. The property is thus expected to hold starting in all clock cycles. In (4.3), the temporal implication causes the always sub-property to be activated only when the antecedent Boolean b is observed. Hence, once b is observed the property f p is expected to hold in this clock cycle and all cycles to come. The never operator behaves similarly, with the exception that it continually extends the matching of its sequence argument, relative to its activation. Once activated, any future matching of the sequence causes the property to fail. The next

66

4 PSL and SVA Assertion Languages

operator starts a checking of its property argument in the cycle following its own activation. This is a weak property, meaning that if the next cycle does not occur then the property holds. The strong version of this operator, namely next!, does not allow the end of execution to occur in the next cycle. In other words, the next cycle must be a valid execution cycle and the argument property must hold, in order for the next property to hold. Incidentally, next[0]( f p) is equivalent to f p. The eventually! property states that its argument sequence will be observed before the end of execution occurs. Once again, activations affect the behavior of this property, as shown below. assert eventually! {b;c;d}; assert a -> eventually! {b;c;d}; In the first assertion above, the sequence is expected to be observed before the endof-execution. In the second example, once a is observed, the sequence is expected to be observed before the end-of-execution. The end of execution is a special signal that must be provided by the user to indicate that no further clock cycles will occur. This signal is not part of the PSL specification, and, as mentioned in Section 2.7, it is used in dynamic verification tools to handle strong properties. All properties with the ! symbol are temporally strong properties. Weak properties do not require the end of execution signal. The until family of properties in Definition 4.4 cause the continual checking of their argument property until the releasing Boolean occurs. In the overlapped versions (with the ), the argument property is also checked in the clock cycle were the Boolean occurs. In the strong versions (with the !), the Boolean must occur before the end of execution. The before family of operators specify how two Booleans should relate temporally to one another. In the first of such operators in Definition 4.4, the left side Boolean should occur strictly before the right side Boolean, or else the property fails. In the overlapped versions, the left side Boolean may also occur in the same clock cycle as the right side Boolean. In the strong versions, the right side Boolean must occur before the end of execution. The next[]() properties are extensions of the next properties mentioned previously, with a parameter for specifying the n th next cycle. This applies to both the weak and the strong versions. The next a properties cause the checking of the argument property in a range of next cycles (starting in all cycles in the range), specified with a lower and upper bound integer. The next e properties apply only to Booleans, and are used to indicate that the given Boolean must be observed at least once within a specified range of next clock cycles. Up to this point, a total of eight variations of next properties have been encountered. The basic “unit of measurement” that is implied when referring to “next” is the clock cycle. The remaining eight next-type properties in Definition 4.4 are based on a different unit, namely the next event. The next event properties are similar to the next properties, except that the “next” being referred to is not clock cycles but rather the occurrence of a given Boolean. For example, next event a!

4.1 The Property Specification Language

67

is used to specify that an argument property must be true within a range of next occurrences of an argument Boolean, and that all next occurrences of the Booleans specified in the range must occur before the end of execution. A subtlety worth mentioning is that the next event of a Boolean can be in the current cycle. Example 4.3. This example illustrates the behavior of two forms of next properties. next[2](!busy) next event a(flag)[2:4](!busy) The first property makes use of the plain next operator, with a parameter to indicate that the argument property, in this case !busy, must hold in the second next cycle, with respect to when the property is activated. In the example trace in Figure 4.3, the property does not hold because its argument property does not hold in cycle 3 (busy is not false). The second property indicates that its argument property (!busy) must hold in all of the next two to four occurrences of the flag event. In the example trace in Figure 4.3, this property is true because in cycles 6, 7 and 10, busy is false. In these examples the activation would come from the parent operator when the properties are used in more complex expressions. For example, if the two properties above are used in place of p in: always b -> p then the activation being referred to in the figure corresponds to an occurrence of the Boolean b. The two forms of temporal implications (|-> and |=>) are referred to as overlapped and non-overlapped suffix implication respectively. In overlapped suffix implication, for every matching of the antecedent sequence, the consequent property is expected to hold. The property must hold starting in the last cycle of all the antecedent sequence’s matches. In the non-overlapped suffix implication, for each successful matching of the antecedent sequence the consequent property is expected to hold starting in the cycle after the last cycle of the antecedent’s match.

Activation

flag busy 1 2 3 4 5 6 7 8 9 10 11 12

Fig. 4.3 Traces for next properties in Example 4.3.

68

4 PSL and SVA Assertion Languages

4.1.4 PSL Verification Directives and Other Declarations Properties and sequences as such accomplish nothing in most verification tools and have no effect. The verification layer in PSL is used to instruct tools on what to do with these properties and sequences. The two most often used verification directives are shown below. Definition 4.5. PSL verification directives are defined as follows: Verification Directive ::= assert Property ; | cover Sequence ; The assert directive instructs a verification tool to verify that the argument property holds, whether it is checked formally or in run-time verification. The cover directive instructs a tool to verify that the argument sequence must occur at least once during the verification process. Although the word assertion should strictly be used to refer to an assert directive, the term assertion is also used more generally to encompass all verification directives. To specify the clock reference, the default clock must be declared before any verification directive can be used. In this work, the scope of the clock declaration extends to all directives below it, until it is redefined; however, according to the PSL specification, at most one clock declaration can be specified in a vunit. The clock signal used usually corresponds to one of the clock domains in the source design. Definition 4.6. In PSL, the default clock declaration can be specified using either of the following statements: Clock Declaration ::= default clock = (posedge clock signal); | default clock = (negedge clock signal); The items in both preceding definitions are grouped in a vunit when PSL commands are to be specified in a separate file. The vunit’s prototype is used to bind the items to a source design. PSL items can also be declared using comments directly in the source design’s code (in-line assertions). In both cases, all signal names used in the items must be valid signal names from the source design. PSL does not have a formally defined run-time semantics for its interpretation. The language reference manual [108] specifies only the conditions under which properties pass or fail, and the run-time interpretation of PSL as used in a checker generator or a simulator is not imposed. For example, for a given assertion, the semantics of PSL described in the reference manual dictate the conditions under which the assertion holds, but does not mention how/when/where to report failures, and how many failures must be reported. The run-time semantics used in the checker generator are sometimes different than those used in simulators capable of interpreting PSL. Interpreting assertions

4.1 The Property Specification Language

69

by specialized hardware is different than interpreting assertions in a simulation kernel, where processes and dynamic memory allocation are readily available. In both cases, efficiency is a driving factor in design choices for PSL interpreters. The runtime semantics resulting from the automata construction for PSL in Chapter 6 is well suited to hardware checkers. Dynamic property checking semantics can also be derived from the operational semantics presented by Claessen and Martensson [49]. Some operators of sequences and properties will be handled using rewrite rules in Chapter 6. Rewrite rules have the form x → y, where the operator in the left side (x) is syntactically rewritten to the expression in the right side (y). This is normally done in a tool’s front-end to rewrite an operator to another one that is already supported, such that the left side operator does not have to be explicitly implemented in the tool’s kernel. Proper care must be taken when devising a set of rewrite rules, such that the set is terminating [63]. Definition 4.7. A set of rewrite rules is said to be terminating if there is no infinite sequence of application of the rules. To complete the presentation of the PSL language, a summary example illustrates how assertions can be used in practice. The complete code, including both Verilog RTL description and the assertions, are given in Appendix A. Example 4.4. The use of assertions is illustrated in a more complete example, that of a width-parameterized up-down counter. The ports of the counter are visible in Figure 4.4, and are explained next. The counter has a signal to enable counting (en ud), and another signal to control the counter direction (up ndown). The counter can also be loaded with an external value (load), which has higher priority than the counting-enable signal. The load is performed when en load is true, whereby the counter is synchronously loaded with the load value in effect at that time. The loaded value then appears on the counter’s output (cnt) in the next cycle. The Verilog parameter width is used to control the size of the signal vectors cnt and load. The counter is designed in RTL using the clk signal as a reference. The four assertions shown below are used to facilitate the verification, although more assertions could be added to cover different features of the counter. UDCNT ASRa - UDCNT ASRd: assert always {!en_load && !en_ud} |=> stable(cnt); assert always en_load -> next (cnt == prev(load)); assert always !en_load -> next (!(cnt==˜prev(cnt) && cnt[width-1]==cnt[0])); assert never (!en_load && !en_ud)[*10];

The first two assertions are used to ensure the proper operation of the counter. If the counter is not being loaded with a new value and it is not counting, then the output value should not change. In the second assertion the loading process is verified to ensure that the new value takes effect. The third and fourth assertions are not based on properties of the counter as such, instead they describe the way the counter

70

4 PSL and SVA Assertion Languages clk reset en_load en_ud

Up-Down Coutner

cnt

up_ndown load

Fig. 4.4 Signals used in the up-down counter.

is actually used. In this example, the use of the counter is such that rollover should never occur (third assertion), and the environment should be updating the counter periodically (fourth assertion). Assertions can be used to verify the intrinsic operation of a circuit, and also to verify that the circuit is properly used in its intended environment. When considering only the assertions above, the signal dimensions can not be deduced. For example, cnt and load are actually declared with dimensions [width-1:0] in the source design. In order to produce the correct circuit for prev(cnt) for example, the vector width of the cnt signal must be known to the checker generator. It is for these reasons that the checker generator must also have access to the source design when generating assertion checkers, as was illustrated in Figure 2.1. The code for the PSL assertions, the source design and the generated checkers in this example is shown in Appendix A. In Example 4.4, a checker generator would be used to create a monitoring circuit from the assertions for inclusion into hardware emulation, silicon debug or postfabrication diagnosis. Special considerations such as assertion multiplexing and assertion grouping must be made when a large amount of checkers are to be emulated and probed. Although in this example assertions may not be required by experienced designers to help verify such a simple counter, the benefits of assertions are quickly amplified in larger designs.

4.2 SystemVerilog Assertions SystemVerilog Assertions (SVA) are an integral part of the SystemVerilog (SV) language. SystemVerilog [107] (IEEE 1800–2005 Standard) is an evolution of the Verilog hardware description language [20] (IEEE 1364–2005 Standard). System Verilog adds many high level language features useful for testbench design, assertionbased verification, coverage driven verification and architectural level modeling. It is intended as an all-in-one solution for design, specification and verification that extends into both the simulation and formal assertion-based verification domains. Detailed descriptions of SVA appear in related textbooks [53,75,91,146,171].

4.2 SystemVerilog Assertions

71

The Verification Methodology Manual for SystemVerilog [17] also contains detailed information on SV assertions, along with many guidelines for writing effective assertions. The IEEE 1800–2005 SystemVerilog evolved from SystemVerilog 3.1 which was developed by Accellera, a consortium of EDA companies, the same organization that developed PSL 1.1 before it was adopted by IEEE and standardized as IEEE 1850–2005 PSL. As with any new design language, one of the goals is often to allow engineers to design at higher levels of abstraction and to diminish the number of design errors committed, thereby improving the overall EDA process. One key component that contributes to better design practices is the ability to add correctness specifications to a design. As with PSL, SVA allows the specification of complex temporal interactions between the circuit signals. Contrary to PSL, SVA assertions have no flavor macros for supporting multiple HDLs, and are generally tied to SystemVerilog designs. To give an introductory view of how assertions can be specified in SystemVerilog, the bus arbiter assertion from Section 2.2 is re-specified below in SVA. To recall, the requirement was: when the request signal goes from low to high in two consecutive cycles, then the grant signal must be asserted in at most five cycles and the request signal must remain high until this grant is received, unless a reset occurs. assert property (disable iff (!reset) (!req ##1 req) |=> (req[*0:4] ##1 gnt) )

(4.4)

The assertion in (4.4) is the SVA equivalent of the PSL assertion that was introduced in (2.2) in Section 2.2. The clocking operator used to specify the clock signal in the SVA assertion is omitted above; similarly in (2.2) a default clock was assumed to be defined using PSL’s default clock directive. The disable iff operator plays the same role as PSL’s abort operator, and in this example was used to reinitialize the checking of the property when the reset is low. Other than the concatenation operator written using ##1, the second line is almost identical to the PSL version, where both make use of a temporal implication between two sequences. Unless it appears in an initial procedural block, the assert construct has the same effect as PSL’s assert always combination of operators, and enforces the continual checking of a property. Although both SVA and PSL are aimed at enabling the assertion-based verification paradigm, and in a general sense they are similar in nature; there also exist a few differences that are worthwhile to mention [93]. 1. SVA statements are part of the SystemVerilog language, thus assertions need not be specified in a separate file in a vunit, nor embedded in comments in the source code. SystemVerilog assertions are part of the design language and the statements appear as regular SystemVerilog statements in the design’s source code. 2. SystemVerilog assertions have action blocks that allow a direct interaction of an assertion’s pass or fail status with the rest of the HDL code. This feature can even be used to interface assertions to a testbench [16], thereby easily allowing a

72

4 PSL and SVA Assertion Languages

closed loop testing framework where feedback on assertions is used to automatically guide the testing scenario. 3. SVA also allows more integration between HDL function calls and design variables within the assertion statements themselves. Local variables can be assigned and read-back at different points in the matching of a sequence, for example. This can be used for tagging events and ensuring that each event identifier receives its proper completion. In PSL, tagging can often be implemented using the forall operator [68]. 4. Properties in SystemVerilog can be specified in a recursive manner. This can be used to implement various LTL temporal operators such as PSL’s until and always. While this seems somewhat more cumbersome than the direct operators available in PSL, for weak properties, useful in simulation-based schemes, the recursive properties provide expressiveness comparable to LTL operators. Future revisions of SVA are expected to include these types of temporal operators. 5. Because of a tighter integration with simulators, the run-time execution of SVA is defined in more details. For one, a number of actions related to the interpretation of SVA assertions can be done during the elaboration time. Second, SVA has a much more detailed definition of the sampling of variables within event-driven simulators. This level of detail allows the avoidance of race conditions, as well as the asynchronous termination of property evaluations, something that the PSL definition does not allow for. As with the PSL language, SVA defines a linear path temporal logic suitable for verification of simulation traces associated to dynamic verification. SVA is also compatible with static verification thereby allowing a property to be checked mathematically by a formal tool. In such cases, the model and the property are given as the SystemVerilog design code and the related SVA statements respectively, and a model checker or theorem prover carries out the conformance check. The SVA language is built on the Boolean expressions of the underlying language, namely SystemVerilog. These Booleans are used to build regular expressions for describing a set of temporal behaviors, similarly to the regular expressions found in PSL. Properties are where there are more differences between both assertion languages. Currently, PSL defines a much larger variety of property operators and allows the specification of both strong and weak properties as part of its syntax. In SVA, strong, weak and neutral semantics are defined [107], and currently have no direct relation with the operators themselves. The presentation of SVA contained in this section is based on Section 17 in the SV specification [107], which describes the formal syntax of the SVA language in BNF (Backus-Naur Form). The semantics of each operator is explained informally in the current section, and is formally specified in Appendix E in the SV specification [107]. The following considerations were made for the SVA used in this work: • Expressions appearing in bounds for ranges and numbers are restricted to integers in this work, as opposed to statically computable expressions. Adding support for expressions involves additional features in the parser front-end, and does not affect the algorithms used in the checker generator.

4.2 SystemVerilog Assertions

73

• Sequence and property instantiations are omitted for simplicity. In the current version of the checker generator, non-parameterized sequence and property declarations and instantiations are supported. • The two verification statements that apply to dynamic verification are supported, namely assert and cover. The assume verification statement is intended for formal methods and is handled in the same way as assert [75, 107]. • The clocking operator (@) within sequences and properties is omitted since its implementation in the checker generator is beyond the scope of this work. Instead, the clocking operator must be supplied once at the top level of a property in an SVA verification statement, as will be shown in Subsection 4.2.4. • The disable iff operator is restricted to top-level properties in the syntax defined in Section 17.11 in the SV specification [107]. In the current work, the disable iff operator is handled as a regular property operator (i.e. can be nested anywhere in properties) and does not have this restriction. The formal semantics in Appendix E in the SV specification [107] also avoids this restriction. • Local variables and recursive properties are not implemented, and are beyond the scope of this text. • Action blocks are omitted since they have no effect on checker generation, and could be implemented by using the assertion signal produced by the checker as a trigger for external blocks of HDL code. By now, SVA is intended for both formal and dynamic verification; however, since it is mostly used for dynamic verification with the checker generator, the operators are best explained in the context of run-time verification. The elements used to define the assertion are explained first, followed by gradually expanding the description of sequences and then of properties. The top level SVA operators that are used to express verification intent are presented at the end of this section.

4.2.1 SVA Boolean Expressions The Boolean expressions of SystemVerilog are used to form the Boolean expressions in SVA. SystemVerilog’s Boolean expressions can be quite complex and will not be described here; however, without loss of generality, the Boolean expressions of Verilog described in Section 4.1 will be assumed. These consist of identifiers, unsigned numbers, Verilog parameters and the standard arithmetic, logical and bitwise operators. SVA Booleans are defined below, where italicized prefixes indicate an additional constraint on a type. Definition 4.8. If “Number” is a nonnegative integer then Booleans are defined as follows in SVA, where “Sequence” is defined further in this section: Boolean ::= boolean Expression Expression ::=

74

4 PSL and SVA Assertion Languages

SystemVerilog Expression | true | false | System function | Sequence instance.ended

System function ::= $past(Expression) | $past(Expression, Number) | $rose(Expression) | $fell(Expression) | $onehot(Expression) | $onehot0(Expression) | $stable(Expression) The presentation of Booleans above was adapted from different sections in the SVA specification [107]. For example, the .ended, past, rose, fell and stable operators are defined in the section on sequence operations, whereas the onehot operators are defined in the section on system functions. In general, SVA definitions made in this chapter are organized in a similar manner to those of PSL in Section 4.1, and may not fully resemble their SVA specification [107]. A Boolean is defined as any expression that evaluates to a Boolean result. An expression can be composed of SystemVerilog expressions, the true and false keywords, system functions and sequence endpoints. Although not formally part of the specification, symbols true and false are used to simplify the notation in this work, and are defined respectively as 1‘b1 and 1‘b0, in Verilog notation. The .ended operator is used to return the evaluation result of the matching of a sequence. Since it is used directly at its endpoint, the sequence is not truly part of the temporal “layer” in SVA, and is evaluated as a Boolean in any expression where it appears, even though internally the sequence may span multiple clock cycles. This operator applies only to sequence instances, which must be declared using SVA’s sequence declarations. Example 4.5. This example shows how sequences can be declared, and how sequence instances must be used for evaluating the endpoint(s) of a sequence. The operator ##1 is a single clock cycle delay, and will be introduced in the next subsection. The clock specification is omitted for simplicity. sequence seq1; b ##1 c ##1 d; endsequence; assert property ( if (a) seq1.ended ); The first three lines comprise the sequence declaration for seq1. The SVA assertion (fourth line) specifies that whenever a is true, then we should also see the sequence seq1 terminate successfully. When a is false, the property is automatically true in

4.2 SystemVerilog Assertions

75

that clock cycle. It should be noted that the elements in the property are all interpreted as Booleans and at that level, the property argument (i.e. the if statement) is evaluated the same as in the expression “if (a) b”, where a and b are single Boolean signals. The .ended operator is similar to PSL’s ended() built-in function. The remaining SVA system functions in Definition 4.8 are also quite similar to PSL’s built-in functions, and are summarized next. The $past function returns the value of its argument expression in the previous clock cycle. The number of clock cycles in the past can also be specified using an optional second parameter. The $rose operator evaluates to true in a clock cycle when its bit expression argument is true, and was false in the previous clock cycle. The $fell operator has the opposite behavior, and is used to specify a high to low sequence of the argument expression. For these two operators, if a bit vector expression is used as the argument, the $rose and $fell apply only to the least significant bit. The $onehot system function evaluates to true if exactly one bit in the argument is at logic-1; the $onehot0 operator evaluates to true if at most one bit is at logic-1. These two operators are designed to be used with bit vector expressions. Checking the invariance of the state of an expression over two consecutive clock cycles can be performed using the $stable operator, that returns true in a given clock cycle if the argument expression’s state is unchanged from the previous clock cycle. Other system functions such as $sampled() and $isunknown() are also defined; however, these are not treated since the former is redundant [107] (i.e. has no effect), and the later is not synthesizable.

4.2.2 SVA Sequences The Boolean expressions described above, labeled “Boolean” for the remainder of this chapter, are used to form sequences in SVA. As in PSL, SVA sequences are used to specify temporal chains of events of Boolean expressions, and are also a form of temporal regular expressions. Definition 4.9. If “Number” represents a nonnegative integer then sequences are defined as follows in SVA: Sequence ::= Boolean | (Sequence) | Cycle delay Sequence | Sequence Cycle delay Sequence | Boolean[* Count] | Boolean[-> Count] | Boolean[= Count]

76

4 PSL and SVA Assertion Languages | Sequence[* Count] | Sequence and Sequence | Sequence intersect Sequence | Sequence or Sequence | first match( Sequence ) | Boolean throughout Sequence | Sequence within Sequence

Cycle delay ::= ## Number | ##[Range] Count ::= Number | Range Range ::= Number : Number | Number :$ The operators for sequences in the definition above are not listed in order of operator precedence. Subsection 17.7.1 in the SV specification [107] lists the relative precedence, from highest to lowest: [*] and [=] and [->], ##, throughout, within, intersect, and, or. Unlike PSL’s separate concatenation and fusion operators, in SVA, Boolean elements can be assembled to form temporal sequences using an operator called the cycle delay (##). When two Booleans are separated by a cycle delay, the matching of the second Boolean starts a prescribed number of clock cycles after the first Boolean is matched. For example, the simple SVA sequence a ##1 b

(4.5)

produces a match when a is true and in the next cycle b is true. It is equivalent to the PSL SERE a;b. When a cycle delay is used to connect two sequences together, the matching of the second sequence starts a specified number of cycles after the first sequence is matched. In static verification the sequence in (4.5) is said to hold in the cycle where a is true, when b is true in the next cycle; however, in dynamic verification the matching is only observed in the cycle where b is true. The cycle delay can be used to specify a fixed number, or a range of numbers of clock cycles. A Range represents an interval of clock cycles with a low and a high bound separated by a colon. The high bound may also be the $ symbol, which represents the end of simulation (or execution), and is similar to PSL’s inf keyword. A Count is simply a number or a range, and is used to specify various forms of repetitions. In the sequence a ##[1:3] b for example, matches are produced when b is true anywhere between one and three clock cycles after a is observed to be true.

4.2 SystemVerilog Assertions

77

The requirement for ranges is such that the high bound must be greater or equal than the low bound; however, the definition above allows numbers to be zero. In such cases, a behavior similar to PSL’s fusion is created. A null cycle delay ##0 specifies a zero clock cycle separation between its arguments, and has the same effect as PSL’s fusion operator (:). The 0 can also be the low bound in a range cycle delay. When two sequences are separated by 0 clock cycles in a cycle delay, the first Boolean in the right-hand sequence must be true simultaneously with the last occurring Boolean in the left-hand sequence for the matching to be possible. The SVA cycle delay allows a temporal separation between two sequences to be specified directly, whereas in PSL, two concatenation operators are required. The following example illustrates this feature. Example 4.6. Consider the following two equivalent sequences, the first modeled in SVA and the second in PSL: a ##[2:10] b a; true[*1:9]; b When using PSL concatenation, the bounds in the range must be adjusted to take into account the two concatenation actually required, hence the 1:9 range. Although a fusion could be used to keep the original bounds, and the true symbol omitted, the form above was preferred for illustrative purposes. The closest PSL sequence would appear as follows: a:[*2:10];b. When an SVA cycle delay operator is used without a left side sequence, as in “##3 b” for example, the matching of the right side starts the number of cycles indicated after its own activation. The sequence ##3 b will produce a match in three clock cycles provided b evaluates to true, and is equivalent to 1’b1 ##3 b. Various forms of Boolean repetition can be specified using the three operators [*c], [->c] and [=c], where c represents a number x or a range of the form x : y. The [* ] operator represents a consecutive repetition of zero or more instances of its argument Boolean. For example, b[*2:$] will produce a match when two or more consecutive occurrences of b are observed. Goto repetitions are also possible ([->), whereby an arbitrary number of latent cycles can occur between the matching of the Boolean. The example sequence b[->2:$] is similar to the sequence b[*2:$] except that the occurrences of b can be interleaved with any number of consecutive cycles where b is false. The nonconsecutive repetition b[=2:$] is similar to the goto repetition but additionally extends the matching beyond the last Boolean as long as it remains false thereafter (provided it does become false). In other words, the extension of the matching continues up to, but not including, the point where the Boolean becomes true again. Sequences can also be repeated via the consecutive repetition operator. For example, the sequence (a ##1 b)[*1:3] produces a match when the sequence (a ##1 b) is observed anywhere between one and three times. A repeated sequence with a single number such as (seq)[*n] is equivalent to n temporal concatenations of the sequence.

78

4 PSL and SVA Assertion Languages

SVA, like PSL, defines disjunction and conjunction of sequences. Sequence disjunction is modeled using the or operator and is similar to PSL’s | SERE disjunction. A disjunction of two sequences produces a match when either argument sequence produces a match. SVA’s length matching intersection is specified using the intersect operator, and is similar to PSL’s && SERE operator. In such a case, both argument sequences must start and finish at the same time for a match to succeed. A relaxed form of conjunction is also possible using the SVA and operator, similar to with PSL’s & SERE operator. In this case the resulting sequence produces a match when the longer of the two sequences has occurred, provided the other sequence also occurred. This can also be referred to as non-length matching intersection. For a given activation, the first match operator produces a matching when the first occurrence of its sequence argument is matched. This operator has no effect when the sequence models only one pattern. For example, given the trace a ; a∧b ; b the expression first match( a[*1:2] ##1 b] ) produces only one match instead of two if the first match operator was omitted. The throughout operator produces a match when its sequence argument (right side) is matched, provided its Boolean argument (left side) is continually true also during the matching. The within operator produces a match when one sequence occurs within the span of another sequence. For example, s1 within s2 produces a match when the s2 sequence was observed, provided that the sequence s1 was also observed at any time during the matching of s2 . If the s1 sequence is never shorter than the s2 sequence, then no matching is possible. PSL also defines the within operator for SEREs. Only a subset of the operators in Definition 4.2 are actually required to completely specify SVA sequences. The following equations are derived in Appendix E in the SVA specification [107]. In a sense, these are similar to PSL’s sugaring definitions, and help to understand the semantics of a few of the operators mentioned in the previous paragraphs (b is a Boolean, s is a sequence, i is a positive integer and m is a nonnegative integers): s[*i] s[*0:$]

≡

s ##1 s ##1 . . . ##1 s (i times)

≡

( s[*0] or s[1:$] )

b[->m] b[=m] b throughout s

≡ ≡ ≡

(!b[*0:$] ##1 b)[*m] ( b[->m] ##1 !b[*0:$] ) ( b[*0:$] intersect s )

The sequence s[*0] is known as the empty sequence, similarly to PSL’s empty SERE, and represents an instant match that spans no clock cycles. The SVA sequence

4.2 SystemVerilog Assertions

79

true intersect (true[*2]) specifies the null sequence, a sequence that can never produce a match. The null and empty sequences are known as degenerate sequences, and were also defined as such for PSL in Definition 4.3. When used in properties, the empty sequence can never cause a match.

4.2.3 SVA Properties SystemVerilog assertions also define properties built on sequences and Booleans, for added modeling of correctness requirements. SVA properties are shown below. Definition 4.10. SVA properties are defined as follows, where brackets [] represent an optional parameter: Property ::= Sequence | (Property) | not Property | Property or Property | Property and Property | Sequence |-> Property | Sequence |=> Property | if( Boolean ) Property [ else Property ] | disable iff(Boolean) Property Property instantiation and sequence instantiation can be handled in the parser front-end, and are omitted from the presentation because they do not add complexity to checker generation. The properties in Definition 4.10 are not listed in order of operator precedence. Section 17.11 in the SV specification [107] lists the relative precedence, from highest to lowest: not, and, or, if . . . else, |-> and |=>, disable iff. The disable iff is not part of property syntax, but is added here as a property operator with the lowest precedence. Not surprisingly, a sequence can be used directly as a property. When a sequence is used non-negated as a property, the sequence is expected to occur and its nonoccurrence constitutes a failure. When the sequence is used negated, it is not expected to occur and any successful matches indicate an error. As with sequences, parenthesizing properties can be used to improve readability, to force a certain operator precedence, or even to disambiguate precedence when a user is unsure of the formal rules in SVA. Complementing a property is performed using the unary operator not. The operator has the role of reversing the requirement of its argument property to hold, as shown when comparing the following two assertions (the assert verification statement is presented in the next subsection).

80

4 PSL and SVA Assertion Languages

assert property (a ##1 b); assert property not (a ##1 b);

(4.6)

In the first assertion above, a sequence is used directly at the top level of a property. The statement indicates that in every clock cycle, a should be followed by b. In other words, a and b should continually be asserted, with the exception of b that has no requirement in the initial cycle. In the second assertion, the sequence is negated thus the requirement is negated: the sequence should now never occur, and an occurrence of the sequence constitutes a failure of the assertion. The second assertion creates behavior equivalent to using PSL’s never operator: assert never {a ; b}; Although illustrated with a sequence in (4.6), SVA’s not operator can be used to complement full properties also. Two properties can be combined to model property disjunction (or), as well as property conjunction (and). Unlike in PSL’s simple subset, no restrictions are placed on the arguments and two full properties can be used. As expected, the disjunction of two properties implies that at least one of the two argument properties must hold; the conjunction of two properties implies that both argument properties must hold. There is no length-matching requirement in either case, and both property operators can be compared to the sequence or and and operators respectively. The two forms of temporal implications (|-> and |=>) are identical to PSL’s suffix implications. In overlapped suffix implication (|->), for every match of the antecedent sequence, the consequent property is expected to hold. The property must hold starting in the last cycle of all the antecedent sequence’s matches. In the non-overlapped suffix implication (|=>), for each successful matching of the antecedent sequence the consequent property is expected to hold starting in the cycle after the last cycle of the antecedent’s match. The if. . . else mechanism allows the selective enforcing of one or two subproperties, depending on the evaluation state of a given Boolean. In the form if (b) p the argument property is checked only if the Boolean b evaluates to true, else the property as a whole is true. This operator is similar to PSL’s property implication operator b -> p. When employing the form if (b) p1 else p2 one of the two properties is enforced, and depending on the state of the Boolean b, it is either p1 if b is true, or it is p2 if b is false. In Section 17.11 in the SVA specification [107], the disable iff operator is actually defined in a separate BNF definition that is hierarchically above PSL properties. The effect is that the operator can only appear outside a property declaration, and can not be used to abort sub-properties that are nested deeper in a full property.

4.2 SystemVerilog Assertions

81

However, including the operator as a regular property operator adds no additional complexity in the checker generator, thus it is not defined in a separate layer. The operator has the effect of canceling any obligations or matches that are taking place in its argument property, when a certain Boolean condition takes place. It has similar behavior to PSL’s abort operator.

4.2.4 SVA Verification Statements Properties alone accomplish little in most verification tools and have no effect unless verification directives are invoked. In SVA, verification statements are used to instruct tools on what to do with these properties. The two most often used verification directives are shown below, and are also quite similar to PSL verification directives. Definition 4.11. SVA verification statements are defined as follows: Verification Statement ::= assert property (@(Edge clock signal) Property ); | cover property (@(Edge clock signal) Property ); Edge ::= posedge | negedge The assert property directive instructs a verification tool to verify that the argument property holds, whether it is checked formally or in run-time verification. The cover property directive instructs a tool to verify that the argument property must complete successfully at least once during the verification process. An important difference with respect to PSL assertions is that the PSL cover directive applies only to PSL sequences. In SVA, the cover operator can also be applied to properties. As mentioned in the case of PSL, the term assertion can generally be used to refer to all types of verification statements, as opposed to being reserved exclusively for the assert operator. Since un-clocked checkers are not studied in this work, a mandatory clock expression must be specified in the verification statement. The verification statements shown above can be used directly as statements in the body of a Verilog module. As such, the property is continually checked for correctness or coverage throughout the execution. Verification statements can also be declared in procedural blocks such as always and initial. When declared in initial blocks, the verification statement is checked starting only in the initial state of the model (design). Although the property may temporally span further clock cycles, the activation and the enforcing of the property is done only once at the start of execution. In general, dynamic verification tools that interpret SVA, such as simulators for example, are able to report on the status of a property continually throughout the

82

4 PSL and SVA Assertion Languages

execution. As witnessed in Figure 2.4, failure points can be identified at different clock cycles throughout the simulation trace, and can be used effectively for debugging. Coverage statements on the other hand present a meaningful result at the end of execution only, whereby any unfulfilled events can be reported.

Chapter 5

Automata for Assertion Checkers

Abstract This chapter presents the automata framework upon which the checker generator is developed, and also shows how automata can be converted into circuits to implement the assertion checkers. We present first the generic finite automata acceptors, followed by the issues relevant to the assertion checker synthesis, such as handling various modes of non-determinism and the encoding of symbols required for efficient implementations.

5.1 Introduction and Overview The goal of Chapters 5 and 6 is to develop the methods for generating circuit-level assertion checkers from high-level assertion statements. This chapter introduces the automaton framework used for implementing assertion checkers, while the next chapter explains how automata are built for the various syntactic elements of PSL, ranging from Booleans to full verification directives. Utilizing the classical automata-theoretic algorithms for pattern matching over Boolean propositions implies a power set symbol mapping that can impose a high penalty on the number of edges required in the automata. For this reason, a symbolic alphabet will be developed and used as the alphabet. This is not without consequence however, as many of the conventional automata algorithms can not be used with a symbolic alphabet. The problem is that conventional regular expression (RE) pattern matching is defined upon a mutually exclusive symbol alphabet, where one and only one symbol is received at each step. This is not the case with Boolean expressions, which can simultaneously and independently evaluate to true. Modifications to well established automata algorithms will be a recurring theme in Chapters 5 and 6, for operators that are common both to REs and PSL SEREs. For other operators that are not used in SEREs, special algorithms will be devised, also taking under consideration the symbolic alphabet. It is also at the end of the present chapter that the conversion of automata to RTL circuits is performed. 83

84

5 Automata for Assertion Checkers

5.2 Automaton Framework The automaton framework used for creating assertion checkers is formally defined in this section. Of primary importance is the introduction of a dual layer symbolic alphabet, and its effects on conventional automata algorithms such as determinization and minimization. The underlying goal is to generate smaller automata, so that when expressed as a circuit, the generated assertion checkers utilize fewer hardware resources, and are implemented less obtrusively in FPGAs or ASIC hardware.

5.2.1 Automaton Definition and the Symbol Alphabet Contrary to the automata for conventional regular expressions presented in Definition 3.2, the automata for assertion checkers are not defined over a mutually exclusive alphabet. In order to use the defined automaton formalism for the case of Booleans, the power set alphabet is traditionally used [118]. Definition 5.1. The power set alphabet corresponds to all the possible valuations of the Booleans used in an assertion. If there are B Booleans, it follows that the cardinality of the alphabet is |Σ |= 2|B| . When an assertion references many Booleans, the exponential increase in the numbers of symbols and edges make this approach difficult to scale. The advantage of the power set alphabet is that symbols become mutually exclusive, and conventional automata algorithms can be used directly; the framework becomes analogous to conventional string matching where one and only one character is received at a time. In sum, the power set alphabet brings the non-mutually-exclusive Booleans into the realm of the mutually exclusive symbols of traditional pattern matching. The disadvantage is that an exponential number of edges are required to model a transition. To avoid the exponential number of edges required in the power set alphabet, a symbolic alphabet is developed. Definition 5.2. The symbolic alphabet corresponds to a direct mapping of the Booleans used in an assertion, such that each symbol represents a given Boolean directly. Although simple in appearance, this alphabet is not mutually exclusive and requires special modifications to algorithms such as intersection and determinization. In the symbolic alphabet, edge symbols represent complete Boolean-layer expressions that are not mutually exclusive because any number of separate expressions can simultaneously evaluate to true. This creates nondeterminism because a given state may transition to more than one state. While adding inherent nondeterminism in this alphabet, certain determinizations throughout the operations on automata can be avoided, which helps create smaller automata.

5.2 Automaton Framework

85

The alphabet stated above is only partially complete, and may grow as new symbols are required. The following example based on sequence fusion illustrates the fundamental differences between the two alphabet approaches, and the effects on the number of edges required. Example 5.1. The fusion of two sequences defined from Booleans a, b and c follows: {a;b}:{c;a} Table 5.1 shows how the power set alphabet is defined for this example. The symbolic alphabet is also shown; however, before the fusion is actually performed, only the symbols σa , σb and σc exist. In the table ∧ is Boolean conjunction, ∨ is disjunction, T is short for true and F is false. In the power set alphabet (left), only one line (symbol) is active at any given time, thus four symbols (and edges) are required to model a transition for a given Boolean; in the symbolic alphabet, only one symbol is required. For example, to model a transition on Boolean b in the power set alphabet, four edges are required for symbols σ2 , σ3 , σ6 and σ7 . Figure 5.1 illustrates the effect of the choice of symbol alphabets on the automata for the current example. Although the fusion algorithm is presented in the next chapter, the emphasis here is more on the number of edges required than the actual fusion operator. The symbolic approach is more efficient in terms of the number of edges required, and the number of states is unaffected. In general, when n Booleans are used Table 5.1 Power set and symbolic alphabets for Example 5.1.

a) 1

c

b

a

Power set alphabet

Symbolic alphabet

F F F F T T T T

F F T T F F T T

F T F T F T F T

σ0 σ1 σ2 σ3 σ4 σ5 σ6 σ7

σa = a σb = b σc = c σb∧c = b ∧ c

σ1 σ3 σ5 σ7

{a;b} 2

{c;a} σ2 σ3 σ6 σ7

3

:

1

3

:

1

σ4 σ5 σ6 σ7

2

{a;b&c;a} σ1 σ3 σ5 σ7

3

=

1

σ1 σ3 σ5 σ7

2

σ6 σ7

3

σ1 σ3 σ5 σ7

4

b) σa

2

σb

σc

2

σa

3

=

1

σa

2

σb

c

<

1

3

σa

4

Fig. 5.1 Effect of alphabet choice on automata for Example 5.1 using: (a) power set alphabet, and (b) symbolic alphabet.

86

5 Automata for Assertion Checkers

in an assertion, a transition on a given Boolean actually requires 2n−1 edges, whereas only one edge is used in the symbolic alphabet. The symbolic alphabet developed in this work is actually based on a two-layer symbolic alphabet, using primary and extended symbols. Henceforth the expression symbolic alphabet will refer to the actual two layer alphabet described below as part of the formal automaton definition. Definition 5.3. In this work, a Finite Automaton A is described by the six-tuple A = (Q, Π , Σ , δ , I, F), where: • • • •

Q is a nonempty finite set of states Π is a set of primary symbols that represent Booleans Σ is a set of extended symbols defined from Π δ ⊆ Q × Σ × Q is a transition relation consisting of a subset of triples from {(s, σ , d) | s ∈ Q, σ ∈ Σ , d ∈ Q} • I ⊆ Q is a nonempty set of initial states • F ⊆ Q is a set of final (or accepting) states

In contrast, the conventional automaton in Definition 3.2 has a single initial state (as opposed to a set of initial states); the conventional automaton also allows the use of ε transitions, and has a mutually exclusive symbol alphabet, not to mention a single-level alphabet. In Definition 5.3 above, the alphabet is defined by the Π and Σ sets, which represent non-mutually-exclusive Booleans. The Π and Σ sets (defined below) are global symbols that are shared across multiple automata. Henceforth the shortened notation A = (Q, δ , I, F) will be used. The term edge is used to refer to an element of the transition relation δ , and is represented by an ordered triple (s, σ , d), where an edge’s extended symbol is denoted σ , and s and d are used to denote the source and destination states of an edge respectively. The transition relation is not complete, as there is not necessarily a transition for each symbol in each state. Each state also has a label, consisting of either an ordered pair, or a totally ordered set, depending on the application. Labels are an essential part of some of the algorithms appearing further, and will be used to denote sets of states from other automata. In the automaton definition for assertion checkers over Booleans, the language accepted by the automaton actually represents a set of traces. This set of traces violates the behavior given by the assertion, and it is the automaton’s purpose to report such traces. The notation A (x) is used to denote the construction of an automaton from an argument expression x, where x can range from a simple Boolean to a full verification directive based on properties and sequences. The Booleans appearing in sequences and properties are used to form the primary symbols in the automaton’s symbol alphabet, and primary symbols are then used to construct the actual extended symbols that appear on the edges in the automata. Definition 5.4. A primary symbol π represents the HDL code of a Boolean expression appearing in a sequence or property, with any outermost negation(s) removed. The set of primary symbols is denoted Π .

5.2 Automaton Framework

87

Definition 5.5. An extended symbol σ is a single literal, or a conjunction of multiple literals, where a literal is a negated or non-negated primary symbol. A literal has a negative polarity if and only if its corresponding primary symbol has an odd number of outermost negations removed when entered as a primary symbol. The set of extended symbols is denoted Σ . The ε symbol from conventional regular expressions represents the empty match, and when used as an edge’s symbol, ε transitions are in effect instantaneous transitions that do not require an execution step of the automaton. As a result of Definition 5.5 however, ε symbols and transitions are not allowed in the automaton framework for assertion checkers. Disjunction of literals is not handled in the extended symbols because disjunction can be performed by two parallel edges that originate (and terminate) at the same pair of states. When the automaton is constructed for a given assertion, the Boolean primitive true may be added to the set of primary symbols, even when it is not used directly in an assertion. For example, the primitive π = true is required for implementing the always property (as will be shown in an example in Section 5.3), and is eventually added to Π during the construction of the automaton. Example 5.2. To show how Booleans and symbols interact, the following assertion based on a two cycle sequence and the never operator is used: assert never { req && gnt ; !(ack || !gnt) }; The primary and extended symbol sets built from this assertion are, respectively:

Π = {π1 , π2 } Σ = {σ1 , σ2 }

where: π1 = “req && gnt” and π2 = “(ack || !gnt)” where: σ1 = π1 and σ2 = ¬π2

The extended symbols in Example 5.2 require only single literals; however, for further processing in an automaton form, other symbols may be added, some possibly referencing a set of conjoined literals. The set of literals comprising an extended symbol is totally ordered, such that no duplicate symbols are kept for equivalent conjunctions that have a different ordering of literals. In the implementation, the total order relation is that which is produced by sorting the actual data elements that represent literals. For convenience, most often when automata are illustrated, the expressions represented by the extended symbols on each edge are constructed from the two symbol alphabets and are shown above or below their corresponding edges, as opposed to showing extended symbol identifiers σi themselves, which require that the sets Π and Σ be explicitly specified. This way an automaton can be understood quicker and the symbol alphabets do not need to be shown. Example 5.2 can also be used to illustrate how the dual-layer symbols can be assembled in reverse to construct the Boolean expressions of an assertion. An extended symbol can be interpreted with a truth assignment ω over its referenced primary symbols. The truth value of an extended symbol σ , under assignment ω , is denoted (σ )ω , and evaluates to either true or false. For example:

88

5 Automata for Assertion Checkers

σ = π1 ∧ ¬π2 ω ← [π1 = true, π2 = true] (σ )ω = false By definition, if σ = true then (σ )
= true, where
represents any assignment possible. In the symbolic alphabet, any given symbol σ from Σ represents a Boolean expression. A transition on σ takes place when the Boolean expression represented by σ is true and the source state of the transition is active. The output signal of the assertion checker corresponds to a disjunction of all final states. When a final state is active in a given clock cycle, the pattern described by the automaton has been matched. In this light, constructing an automaton for assertions actually means constructing an automaton to detect all faulty traces that do not conform to the behavior dictated by an assertion. The clock does not appear in the automaton definition, but is implicitly used to regulate the transition from one set of active states to another. This is analogous to conventional automata for string matching, where reading a character causes the automaton to transition. The definition of deterministic automata made in Definition 3.3 for conventional automata also applies to the symbolic automata defined in this section. By extension, Corollary 3.1 states that conventional FAs are deterministic (DFA) when they have a single initial state and no more than one outgoing edge from a given state carries the same symbol. Since the Boolean expressions represented by automaton symbols are not mutually exclusive, the corollary does not apply to the symbolic alphabet, and Definition 3.3 must be adhered to. This fundamental difference between both automata models influences many operations, not the least of which is the determinization function. The symbolic automata introduced in this chapter do not have to be complete (Definition 3.4), and in a given state, it may be the case that no outgoing transitions are taken in a given cycle. As illustrated in Example 3.1, a complete DFA accepts the same language as a DFA. Since a complete DFA has more edges (and possibly more states) than a DFA, complete DFAs are avoided when possible. In this work, it was also observed that automata with multiple initial states can be more compact than automata that are restricted to having a single initial state. When automata are expressed in a circuit form, having a set of active states is perfectly acceptable. In such cases the initial states are the only active states when the reset is released. It is for this reason that the automaton definition has a set of initial states, as opposed to the automata with single initial states from Definition 3.2. Figure 5.2 shows an example whereby allowing a set of initial states produces an automaton with fewer edges. The dual symbol alphabet allows the automaton to be “aware” of the polarity of signals and also of more Boolean simplifications when conjunctions of edge symbols occur. Since the intersection, fusion and determinization operations require the intersection of symbols (and also polarity manipulations in determinization), new primary symbols do not have to be declared for a conjunction. For example, in

5.2 Automaton Framework

89

a)

1

a

a

2

b

3

4

b

b)

a

1

a

2

b

3

4

Fig. 5.2 Effects of multiple initial states for the sequence {a[*1:2];b} : a) restricted to a single initial state; b) set of initial states, thus requiring fewer edges.

a

2

1

c

3

(!a) && c

true

b)

b

2 (!a) && a a

3

4

b

>

1

>

true

a)

d

a && d 6

a && c b && c

5

4

b && d

Fig. 5.3 Failure-matching automata for assertion in Example 5.3 using: (a) dual-level symbols, (b) single-level symbols.

Section 4.1 it was shown that a goto repetition a[->] is equivalent to (!a)[*];a. The following example builds on this case and illustrates why the two-layer symbol alphabet is beneficial for reducing the size of the automata. For now, understanding the rewrite rule used and the automaton construction from PSL statements is not required, and will be presented in the next chapter. Example 5.3. The following circuit assertion stipulates that two given subsequences must never simultaneously occur, starting and terminating at the same time. The second assertion’s SERE was modified by a rewrite rule, and is more representative of what is actually seen by the checker generator algorithms. assert never {{a[->];b[*]} && {a;c;d}}; assert never {{{(!a)[*];a};b[*]} && {a;c;d}}; The rewritten assertion is expressed in automaton form, for failure matching, as shown in Figure 5.3a using dual-layer symbols. The never property has the effect of creating the true self-loop in state 1. The automaton has four states, compared to six states when single-layer symbols are used. With only one level of symbols, a new symbol must be created for the string “(!a) && a”, as can be seen in Figure 5.3b in the edge from state 1 to state 2, and the automaton is not “aware” that (!a) and a are related. The automaton approach to checker generation allows many types of optimizations to be performed. The following examples show different cases where a modular approach will generate more RTL checker code for the assertions on the left, even

90

5 Automata for Assertion Checkers

though in dynamic verification the assertions on the left are semantically equivalent to their counterparts on the right. assert always {a[->]}|=> b; assert never {b[*1:2];c};

≡ ≡

assert always {a}|=> b; assert never {b;c};

In the first example above, in the assertion on the left, the goto matching related to a is not required because the always continually retriggers the matching of its argument, thus the extension created by the goto operator is redundant. In the second example above, the never operator also continually triggers the matching of its argument, and in such cases the sequence {b;c} is guaranteed to be matched when the sequence {b;b;c} is matched, hence the first b is redundant in the range repetition. Another type of example appears next, which yields identical five-state automata in both cases, as opposed to the modular approach that would generate much larger code in the first case, where a link between the arguments of next event a is not made (b vs. !b). assert always a -> next event a(b)[1:2]({{!b;c[*200];d}|{e;d}}); =

assert always a -> next event a(b)[1:2]({e;d});

Although synthesis tools can perform the necessary optimizations to reduce circuits like the one in Figure 5.3b, in general, not all sequential reductions can be performed this way. Notwithstanding the synthesis aspect, the automata should also be kept as small as possible because operations such as intersection and determinization have worst case behaviors that are product and exponential, respectively, in the number of states. The dual layer symbol alphabet used in this work is used to perform certain Boolean optimizations when intersection edges are created. The logic optimization is truth-table based since only disjunctions of logic cubes (conjunctions of negated or non-negated primary symbols) is required. Other than an outermost negation that is removed to form primary symbols, no deeper manipulation of the Boolean expressions appearing in an assertion are performed. For this reason, Binary Decision Diagrams [35] and the logic minimization they allow are not required, but could be used nonetheless. If the optimization of entire Boolean expressions appearing in an assertion were to be performed, BDDs would become essential for efficient manipulation and minimization of Boolean functions.

5.2 Automaton Framework

91

5.2.2 Determinization of Automata Classical determinization typically does not consider the possibility that edge symbols represent Boolean expressions, many of which can simultaneously be true. Usual determinization procedures [100] based on the “subset construction” have the effect of creating an automaton that has a single initial state, and for which no state has two outgoing transitions using the same symbol. In conventional automata, this is a sufficient criterion to ensure determinism (Corollary 3.1); however, this is not sufficient given the requirement for determinism that was made in Definition 3.3. Therefore, in this work the usual determinization algorithm is said to create weakly deterministic automata; although strictly speaking the automata produced may in fact not be deterministic. The nondeterminism that is left by weak determinization will be used advantageously in the minimization algorithm in the next subsection to help keep the automata as small as possible. The effect of the W EAK D ETERMINIZE () algorithm is first illustrated in Figure 5.4 using a small example. The top of the figure shows a portion of a NFA and the bottom left shows the weakly determinized version. In general, a new state in the DFA is labeled as “i, j, k, . . .”, where i, j, k, . . . are states of the input NFA. When the NFA at the top of the figure is weakly determinized, only the symbols appearing directly on the edges are considered. In the automaton at the bottom left, no two outgoing edges carry the same symbol. If the symbols were mutually exclusive, as in string matching for example, the weakly determinized automaton would be truly deterministic. Some of the algorithms in the next chapter actually require proper determinization, which is referred to as strong determinization. The effect of this algorithm is also illustrated in Figure 5.4. In the strongly determinized automaton at the bottom right in the figure, no conditions allow state 1 to transition into more than one state. The strong determinization creates new symbols by manipulating polarities of other symbols. During these manipulations, the dual-layer symbol alphabet helps to perform Boolean simplifications not seen by a single layer alphabet. Algorithms 5.1 and 5.2 present the algorithms for creating weakly and strongly deterministic automata respectively, using the symbolic alphabet. Both algorithms

1

s1 s2 s2

s1= p1 s3= p1 ∧ ¬p2 s5= ¬p1 ∧ p2

2 4 3

s2= p2 s4= p1 ∧ p2

STRONGDETERMINIZE()

WEAKDETERMINIZE() s1

2

1

s3

2

s5

3,4

1 s2

3,4

...

Fig. 5.4 Strong vs. weak determinization.

s4

2,3,4 ...

...

92

5 Automata for Assertion Checkers

Algorithm 5.1 Weak determinization algorithm. Differences with the strong determinization in Algorithm 5.2 are highlighted in gray. 1: FUNCTION: W EAK D ETERMINIZE(A ) 2: //a label is a totally ordered set T ⊆ Q 3: apply total order to I // i,e., order the set elements linearly, with no incomparable elements 4: create new state q labeled with I / {q}, 0) / //QD , δD , ID , FD 5: create new automaton AD = ({q}, 0, 6: add q to an initially empty set C //C is “to-construct” 7: while C = 0/ do 8: remove a state r (with its label T ), from C 9: if T ∩ F = 0/ then 10: FD ← FD ∪ {r} 11: create set of extended symbols E = 0/ 12: for each edge (s, σ , d) ∈ δ | s ∈ T do 13: add σ to E 14: for each extended symbol σi in E do 15: create a new label U = 0/ 16: for each edge (s, σ , d) ∈ δ | s ∈ T , σ = σi do 17: U ← U ∪ {d} 18: if U = 0/ then 19: find state u ∈ QD with label U 20: if
u then 21: create new state u ∈ QD labeled with U 22: C ← C ∪ {u} // 23: δD ← δD ∪ {(r, σi , u)} 24: 25: return AD //|ID |=1, as required for I NTERSECT()

are based on the subset construction technique, and although they may appear similar, the main difference between the two concerns the depth of symbols they manipulate. The algorithm for weak determinization only analyses the extended symbols, whereas the strong determinization pushes deeper into the primary symbols. A state in the determinized automaton is labeled by a totally ordered subset of states from the input automaton. In the implementation, the total order relation is produced from the partial order among states by sorting the actual data elements that represent states (state numbers). Both algorithms start by ordering (total order) the set of initial states in their argument automaton (line 3). The first state q in the determinized automaton is created, and labeled with this ordered set of initial states (line 4). The state actually comprises the result automaton’s initial topology, where it is also added to the set of initial states (line 5). This state is then used to initiate the subset construction loop in line 7, whereby the central element is the state creation set C. The subset construction implicitly creates an automaton with a single initial state, a feature that is required by the intersection algorithm’s use of weak determinization. Inside the state creation loops in both algorithms (lines 8 to 24), new states are created to represent subsets of states in the input NFA to be determinized (hence the

5.2 Automaton Framework

93

Algorithm 5.2 Strong determinization algorithm. Differences with the weak determinization in Algorithm 5.1 are highlighted in gray. 1: FUNCTION: S TRONG D ETERMINIZE(A ) 2: //a label is a totally ordered set T ⊆ Q 3: apply total order to I 4: create new state q labeled with I / {q}, 0) / //QD , δD , ID , FD 5: create new automaton AD = ({q}, 0, 6: add q to an initially empty set C //C is “to-construct” 7: while C = 0/ do 8: remove a state r (with its label T ), from C 9: if T ∩ F = 0/ then 10: FD ← FD ∪ {r} 11: create set of primary symbols P = 0/ 12: for each edge (s, σ , d) ∈ δ | s ∈ T do 13: add σ ’s primary symbol(s) to P 14: for each assignment ω of primary symbols in P do 15: create a new label U = 0/ 16: for each edge (s, σ , d) ∈ δ | s ∈ T , (σ )ω = true do 17: U ← U ∪ {d} 18: if U = 0/ then 19: find state u ∈ QD with label U 20: if
u then 21: create new state u ∈ QD labeled with U 22: C ← C ∪ {u} σi ← create or retrieve symbol in Σ for ω 23: 24: δD ← δD ∪ {(r, σi , u)} 25: return AD

name subset construction). When any state in a subset is a final state in the input automaton, the state corresponding to the subset is also a final state (lines 9 and 10). The differences between strong and weak determinization start in line 11 in both algorithms. In weak determinization, lines 11 to 13 build the set of extended symbols that are used in the outgoing edges of the subset of states. The subset being referred to is from the input automaton, and is being used to construct the new state in the determinized automaton. In strong determinization, lines 11 to 13 instead build the set of primary symbols used in the outgoing edges of the subset of states. In both algorithms, if the set P is the empty set, then no edges are created for the state and the for loop in line 14 does not execute its block of statements. In the strong (weak) algorithm, for each unique assignment of primary symbols (for each extended symbol), the set of destination states is built in lines 15 to 17; this becomes the label for the destination of a new edge that is to be created for the given assignment of primary symbols (extended symbol). If this destination state already exists, it is used, else it is created (lines 19 to 21) and is added to the construction set C in line 22. The new edge is created in lines 23 and 24, and the entire process is repeated until there are no more states left to create in C. The algorithms are proven to terminate since only a finite number of states (although exponential) can be added

94

5 Automata for Assertion Checkers

Algorithm 5.3 Automaton reversal algorithm. 1: FUNCTION: R EVERSE(A ) //(Q, δ , I, F) 2: if F = 0/ then / {q1 }, 0) / 3: create new automaton A1 = ({q1 }, 0, 4: else 5: create new automaton A1 = (Q, δ , F, I) 6: for each edge (s, σ , d) ∈ δ1 do 7: (s, σ , d) ← (d, σ , s) 8: return A1

to the construction set. Determinization produces an automaton with O(2n ) states in the worst case, where n is the number of states in the input automaton. In practice, the resulting automaton is often reasonable in size.

5.2.3 Minimization of Automata Procedures exist for minimizing conventional automata, such as Hopcroft’s n log n algorithm [99], and Brzozowski’s algorithm [36, 173], Reverse → Determinize → Reverse → Determinize

(5.1)

called the RDRD algorithm herein. The Hopcroft algorithm applies to complete DFAs, where the transition function δ is completely specified for every symbol at every state, whereas the RDRD algorithm can accept an incomplete NFA (in which δ is a relation as opposed to a function). In both cases, a minimized DFA is produced. As a side note, it is easy to observe that the RDRD algorithm does not modify the language accepted by an automaton, given that the reversal is performed twice, and that determinization itself does not change the language accepted. The R EVERSE () algorithm used in minimization exchanges s with d for all edges (s, σ , d) ∈ δ , and also exchanges the initial and final state sets, as shown in Algorithm 5.3. Since the automaton definition (Definition 5.3) allows the set of final states to be empty, which occurs in the automaton for the null sequence for example, the algorithm treats this case separately in line 3. A subtlety also exists in line 5 in the reversal algorithm, where sets I and F are permuted. In this subsection, the minimization of automata based on the symbolic alphabet is developed. Although conventional DFAs can be provably minimized, no claim is made about the minimalism of the automata used in this work, which can be nondeterministic in some cases. Producing minimized NFAs [112], let alone NFAs with Boolean expressions encoded in the symbols, is a hard problem. The approach used here is more a heuristic for reducing the size of automata with symbolic alphabets. The minimization procedure has the effect of pruning any unconnected or useless connected states which can result from the application of other algorithms. The minimization of symbolic automata is based on an observation that even though

5.2 Automaton Framework

95

Algorithm 5.4 Automaton minimization algorithm. 1: FUNCTION: M INIMIZE(A ) 2: A ← R EVERSE(A ) 3: A ← W EAK D ETERMINIZE(A ) 4: C OLLAPSE F INAL S TATES(A ) 5: A ← R EVERSE(A ) 6: C OLLAPSE F INAL S TATES(A ) 7: A2 ← W EAK D ETERMINIZE(A ) 8: C OLLAPSE F INAL S TATES(A2 ) 9: if |Q2 | < |Q| then 10: A ← A2 11: return A

conventional minimization only applies to DFAs, in many cases the required determinization (worst case exponential) is not a big penalty. In most cases the increase in states is quite modest, and in some cases determinization even produces smaller automata; this behavior is also observed in the weighted automata used in speech recognition [38]. Algorithm 5.4 presents the algorithm used to minimize symbolic automata. The minimization approach is based on the RDRD algorithm from (5.1), which corresponds to lines 2, 3, 5 and 7 in Algorithm 5.4. Weak determinization is employed for the determinization step, as opposed to strong determinization. The guiding principle in minimizing automata is that any form of nondeterminism is tolerated, and even sought when it causes the resulting automaton to be smaller. Because of this principle, the final determinization in the RDRD strategy is only applied if it reduces the number of states (lines 9 and 10). Circuits are well suited for implementing nondeterministic conventional RE pattern matchers [161], and in this respect, the automata used here with Booleans as the alphabet are no different. Surprisingly, the weak determinization used implies that the minimization algorithm, when applied to an NFA, can produce an automaton that in the worst case has an exponential number of states. As will be seen in Chapter 6, when a sequence is used as a property, a strongly deterministic automaton is produced for that sequence. When the minimization algorithm is applied to a property’s automaton that contains a strongly deterministic sub-portion, the weak determinization used in minimization has no effect on that portion of the automaton; however, when other parts of a property automaton that have not undergone strong determinization are minimized, the weak determinization preserves a certain amount of nondeterminism, and helps keep the checkers more compact. Another key factor in the minimization algorithm is the collapsing of final states in presence of self-loop edges with the true symbol (lines 4, 6 and 8 in Algorithm 5.4). The true edge differentiates itself from other edges because it is guaranteed to cause a transition at each cycle in the automaton. Incorporating knowledge of this fact in the minimization algorithm helps to implement another type of optimization, namely the collapsing of final states. The reason there are two calls to this function in the second half of the RDRD strategy is that depending on the outcome

96

5 Automata for Assertion Checkers

Algorithm 5.5 Algorithm for collapsing final states. 1: FUNCTION: C OLLAPSE F INAL S TATES(A ) //(Q, δ , I, F) 2: while ∃ pair of edges (s1 , σ1 , d1 ) and (s2 , σ2 , d2 ) | {s1 , s2 , d1 , d2 } ⊆ F, σ1 = σ2 = true, d1 = s2 = d2 do 3: for each edge (s3 , σ3 , d3 ) | s3 = s1 do δ ← δ − {(s3 , σ3 , d3 )} 4: δ ← δ ∪ {(s1 , σ1 , s1 )} 5: 6: while ∃ pair of edges (s1 , σ1 , d1 ) and (s2 , σ2 , d2 ) | {s2 , d1 , d2 } ⊆ F, s1  F, σ1 = σ2 = true, d1 = s2 = d2 do 7: for each edge (s3 , σ3 , d3 ) | s3 = s1 , σ3 = σ1 , d3 = d1 do δ ← δ − {(s3 , σ3 , d3 )} 8: 9: return A true

true 1

a

2

true

b

3

1

true

2

COLLAPSEFINALSTATES()

Fig. 5.5 Collapsing final states with true edges.

of the comparison in line 9, the algorithm may perform only RDR, and in this case the final reversal should also have a collapsing of final states. These are performed separately after the last reversal and after the last determinization in order for the automata size comparison to be the most meaningful. The C OLLAPSE F INAL S TATES() algorithm used in minimization is presented in Algorithm 5.5. This algorithm removes a subset of states that is closed under the true self-loop. The first part of the algorithm (lines 2 to 5) works by detecting a true transition (s, true, d) between two final states, where state d has a true self-loop. The true self-loop can be safely replicated on the source state because it adds nothing to the language accepted by the automaton (line 5). Any other outgoing edges from this source state can be safely removed in lines 3 and 4 because once a final state becomes active, the true self-loop will perpetually keep it active, and there is no point in triggering other states. The second part of the algorithm in lines 6 to 8 performs another similar type of optimization with regards to the true edge. It is very similar to the first part, with the exception that the first state in the state pair is not a final state. The second optimization works by detecting a true transition (s, true, d) between two states, where state s is non-final and state d is a final state with a true self-loop. In such cases, any other outgoing transitions from state s are pointless because the true transition will activate a perpetually active final state in the next transition, thus the other outgoing transitions can be removed (lines 7 and 8). If any state becomes unconnected during the collapsing of final states, it is removed from the automaton (not shown in the algorithm). The second type of optimization is illustrated in Figure 5.5, where the a edge can be removed given the simultaneous true transition to a perpetually active final state. The first type of optimization is illustrated in a complete example.

5.2 Automaton Framework

97

Example 5.4. The following assertion is used to show the effect of collapsing final states in minimization. assert never {c[*1:2];d}; This example is illustrated in Figures 5.6 and 5.7. The actual steps used to create the automaton require the notions in Chapter 6, and are not topical at this point. The top part of Figure 5.6 shows the automaton as it appears after the first determinization in the minimization algorithm (hence it was also reversed). The true self-loop on state 5, and the true edge from state 3 to 5, combined with the fact that states 3 and 5 are final states implies that once state 3 is reached, the automaton will remain active for the remainder of execution, or until the checker is reset. Since this automaton has undergone a reversal, this is expected in the example; i.e. the loop created by the never operator is now at the end of the automaton. As a result, the transitions to and from state 4 are in effect useless. Consequently, the smaller automaton at the bottom of Figure 5.6 is produced when the collapsing of final states is performed. That automaton shows the state of the computation after line 4 is executed in the minimization algorithm. To show the global effect of collapsing final states in presence of true edges, if it is not performed when minimizing the automaton for the assertion above, the four-state automaton in Figure 5.7a is generated. With the optimization, the smaller three-state automaton in Figure 5.7b is produced. This reduction actually reveals more insight into the run-time semantics of PSL for dynamic verification. If the assertion did not have the never operator, the sequence would only be checked starting in the first cycle of execution, and the full language defined by the sequence {c[*1:2];d} would apply. However, in presence of the never operator, this optimization shows that only the {c;d} portion needs to be detected. In other words, when it is continually triggered, {c;d} temporally subsumes the larger {c;c;d}. true d

1

c

2

true

3 c

5 true

4

COLLAPSEFINALSTATES()

1

true d

c

2

3

Fig. 5.6 Example for collapsing final states. a)

true 1

c

c 2

3 d

b)

d 4

true 1

c

2

d

3

Fig. 5.7 Effect of collapsing final states in minimization, for example 5.4. (a) Without CollapseFinalStates(), (b) with CollapseFinalStates().

98

5 Automata for Assertion Checkers

Algorithm 5.6 Automata negation algorithm. 1: FUNCTION: N EGATE(A ) 2: A ← S TRONG D ETERMINIZE W ITH C OMPLETION(A ) 3: F ← Q − F 4: return A

//Q, δ , I, F

The minimization algorithm will not be called explicitly in the automaton construction for properties and sequences in the next chapter. In the checker generator, minimization is applied to top-level sequences, as opposed to recursively at each level in a sequence’s operators, with one exception. Intersection involves a product automaton construction and it is beneficial to minimize the argument automata beforehand. As will be seen in the automata construction for sequences, all other sequence operators have a linear space complexity, and minimization can be safely relegated to its highest-level point in the sequence’s expression. Minimization is also applied at the property level, but for simplicity will also not explicitly appear in the automata construction for properties. Functionally, minimization could in fact only be called once before the automaton is actually converted to RTL code to form the checker.

5.2.4 Complementation of Automata Complementing (or negating) an automaton corresponds to creating a new automaton that matches the complement language. In the case of symbolic automata over Booleans, the complement language corresponds to all the traces that are not accepted by the original automaton. Algorithm 5.6 presents the algorithm used to complement automata with the symbolic alphabet. This algorithm is also used in an example in the next chapter (Example 6.2). The strong determinization with completion is performed by a separate algorithm that is explained further in this subsection. Although the automata complementation algorithm is not used in the checker generator, it is presented nonetheless so that the automaton framework over Booleans is fully defined for the conventional operators. The N EGATE() algorithm implements the same type of procedure as described in Subsection 3.1.1 for complementing conventional automata. The two steps for determinization and completion are implemented in one function in line 2, and the complementation of final states is performed in line 3. A strong determinization algorithm that produces complete DFAs is presented in Algorithm 5.7. Although lines 28 and 31 can be factored from the if/else block in lines 23 and 30, they are kept redundant in order for the algorithm to appear as similar as possible to the strong determinization algorithm in Algorithm 5.2; only 6 lines were added (shown in light gray) to that algorithm to yield a version which produces complete DFAs for the symbolic alphabet. The algorithm adds a dead state

5.2 Automaton Framework

99

Algorithm 5.7 Algorithm for strong determinization with completion. Additions compared to the strong determinization algorithm in Algorithm 5.2 are highlighted in gray. 1: FUNCTION: S TRONG D ETERMINIZE W ITH C OMPLETION(A ) 2: //a label is a totally ordered set T ⊆ Q 3: apply total order to I 4: create new state q labeled with I //QD , δD , ID , FD 5: create new state f 6: σt ← create or retrieve symbol in Σ for true / 7: create new automaton AD = ({q , f }, {( f , σt , f )} , {q}, 0) 8: add q to an initially empty set C //C is “to-construct” 9: while C = 0/ do 10: remove a state r (with its label T ), from C 11: if T ∩ F = 0/ then 12: FD ← FD ∪ {r} 13: create set of primary symbols P = 0/ 14: for each edge (s, σ , d) ∈ δ | s ∈ T do 15: add σ ’s primary symbol(s) to P 16: if P = 0/ then 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31:

δD ← δD ∪ {(r, σt , f )} else for each assignment ω of primary symbols in P do create a new label U = 0/ for each edge (s, σ , d) ∈ δ | s ∈ T , (σ )ω = true do U ← U ∪ {d} if U = 0/ then find state u ∈ QD with label U if
u then create new state u ∈ QD labeled with U C ← C ∪ {u} σi ← create or retrieve symbol in Σ for ω δD ← δD ∪ {(r, σi , u)} else σi ← create or retrieve symbol in Σ for ω

32: δD ← δD ∪ {(r, σi , f )} 33: return AD

f whereby all Boolean conditions not taken by outgoing edges in a state are routed to this dead state using supplemental edges (lines 31 and 32). The dead state f does not require a label because it does not take part in the subset construction, and is directly added to the resultant automaton (lines 5 and 7). In order for the dead state to also adhere to the requirements of completeness, a self-loop with a true edge is added in line 7. The key to proving that the algorithm produces complete automata is that for every state that is created in the new automaton in the subset construction, the for loop in line 19 combined with the if/else in lines 23 and 30 add the necessary edges for covering all the Boolean possibilities for outgoing transitions in a given state.

100

5 Automata for Assertion Checkers s1= p1 s3= p1 ∧ ¬p2 s5= ¬p1 ∧ p2

s2= p2 s4= p1 ∧ p2 s6= ¬p1 ∧ ¬p2

1

s1 s2 s2

s7 = true

STRONGDETERMINIZEWITHCOMPLETION()

s6 s3

2 4 3

... 2

1

s5

3,4

s4

2,3,4

...

...

Fig. 5.8 Strong determinization with completion.

The only state that is not part of the subset construction is also complete given the self-loop with true that is added at the beginning of the algorithm. Normally the complete-determinization algorithm is not used because the dead state f would get pruned during minimization. It is therefore important that minimization must not be performed between lines 2 and 3 in the N EGATE() algorithm, in order for the complete DFA to remain intact. Figure 5.8 shows how the complete-determinization algorithm operates on a sub-portion of an automaton. The automaton on the left is identical to the one in Figure 5.4 used to illustrate the differences between strong and weak determinization; it is used here to show how a complete strongly deterministic automaton can be produced. As before, only one state is explored in full detail and the remainder of the automaton is not shown. The complete strongly deterministic version is similar to the strongly deterministic one, with the exception that an extra outgoing edge is added to state 1. This edge leads to the dead state, which is not labeled because it does not represent a subset of states of the input automaton. For the two states that are completely defined in the automaton in the right side of the figure, namely the unlabeled state and state 1, it can be verified that a single outgoing transition is taken in each state for any given status of the Boolean primitives; this is consistent with the definition of complete DFAs (Definition 3.4).

5.3 Generating Circuit-Level Checkers from Assertion Automata Even though the algorithms for expressing PSL and SVA assertions in automaton form are treated in Chapters 6 and 9 respectively, the automaton definition and examples contained in this chapter are sufficient prerequisites for introducing the transformation of automata into circuit-level checkers. The main result that must be developed is a procedure for transforming the automaton into a form suitable for in-circuit assertion monitoring. Furthermore, the automata may not be entirely (if at all) strongly deterministic. Circuits composed of combinational and sequential logic represent an ideal implementation for automata because each state’s computations can be performed in parallel. In contrast, traditional software implementations

5.3 Generating Circuit-Level Checkers from Assertion Automata

101

make heavy use of deterministic automata so that the software can easily track a single active state. The procedure described in this section defines the operator H (A ), which represents the creation of HDL code from a given argument, which in this case is an automaton. If b is a PSL Boolean, the notation H (b) is also valid and will be used in the automaton construction for Booleans in the next chapter. The resulting circuit descriptions from H () become the checkers that are responsible for monitoring the behavior expressed by the assertions. Implementing an automaton in RTL is performed using the following encoding strategy for each state: 1. A state signal is defined as a Boolean disjunction of the edge signals that hit a given state. 2. An edge signal is a Boolean conjunction of the expression represented by the edge’s symbol with the sampled state signal from which the edge originates. 3. A state signal is sampled by a flip-flop, and the flip-flop’s output is referred to as the sampled state signal. 4. If a state is an initial state, the flip-flop defined in step 3 is initially set, else it is initially reset. 5. The assertion signal (or checker output) is a Boolean disjunction of the state signals of all the final states. In sum, automata are implemented in hardware using combinational logic and flip-flops. Since an entire automaton is rarely ever strongly deterministic, any subset of its n states can simultaneously be active, thus one flip-flop per state (i.e. n flipflops) is the most efficient encoding. Even if a portion of an automaton is strongly deterministic, multiple activations from other portions could retrigger it (and overlap within it) thus allowing more than one active state, and consequently, disallowing the log2 n flip-flop encoding. It is true however, that if an entire assertion automaton with n states is strongly deterministic, then at most log2 n flip-flops could be used to keep track of the active state; however, this comes at the expense of more combinational logic since the state vector needs to be decoded for use in the edge signals. The flip-flops in the automaton states have the additional property that they can be reset by the global reset signal. This way, when the design under verification is reset, the checkers can also be reset to provide the correct monitoring. Expressing the RTL circuit as HDL code in the desired language, or even in schematic form, follows naturally. The following example shows how automata are converted to circuit form to produce circuit-level assertion checkers. Example 5.5. The following bus arbiter assertion states that when the request (req) signal goes high, the arbiter should give a bus grant (gnt) within at most three cycles, and req must be kept high until (but not including) the cycle where the grant is received. assert always {!req; req} |=> {req[*0:2]; gnt};

102

5 Automata for Assertion Checkers true

1

req && !gnt 5 req && !gnt 4

req

!req 2

3

!gnt !req && !gnt 6

!req && !gnt req && !gnt

!gnt

req && !gnt req !req

D D

D

D D !req && !gnt

Asr. Out

!req && !gnt

Fig. 5.9 Circuit-level checker for assertion in Example 5.5.

The example assertion is compiled into the automaton shown at the top of Figure 5.9. The automaton is then expressed in RTL as the circuit shown in the bottom of the figure. The labels containing Boolean expressions can also be expressed using logic circuits, but are kept in text form for simplicity in this example. The always operator has the effect of creating the self loop on state 1, which continually activates the automaton in search of a faulty trace. This state is optimized away given that it is an initial state and that the true self loop perpetually keeps it active. As was shown in Figure 2.1, such RTL checkers can then be connected to the circuit-under verification to detect functional errors. Figure 5.10 shows the RTL code for the checker, in the Verilog HDL. In this example, s1s is a vector of state signals where each bit corresponds to a state in the automaton, signal s1sq is a vector of sampled state signals and ASR OUT is the assertion signal, as defined previously in this section. The signal s1s[0] is not used given the optimization mentioned previously. The ‘MBACRPS macro is the reset polarity of the checkers, and is defined to be ! by default; consequently the checker in this examples requires an active low reset. With the exception of one state signal that requires a disjunction of three edge signals, all other state signals are directly equivalent to edge signals. Edge signals are not explicitly declared in the checker. The three-input or gate is visible in the HDL code of the checker. By default a flip-flop is added to the assertion signal to improve the frequency performance of the checker (not shown in the example). This is particularly useful when a checker has many final states or when final states have many incoming edges. The flip-flop is also beneficial when the assertion signal is routed to a pin or a register file elsewhere on the circuit being tested. The checker should interfere as little as possible with the source design’s timing, and the flip-flop helps reduce the chance that the assertion signals are on the critical path. The penalty is a one cycle delay in the response of the checker. The FF can be avoided by using the appropriate switch in the checker generator, when desired.

5.3 Generating Circuit-Level Checkers from Assertion Automata wire [5:0] s1s; reg [5:0] s1sq; wire ASR_OUT; //--------------//ASR_1 : assert always {!req ; req} |=> {req[*0:2] ; gnt}; //--------------always @(posedge clk) if (‘MBACRPS reset) s1sq<=6’h1; else s1sq<=s1s; assign s1s={(s1sq[4] && (req && !(gnt))), (s1sq[2] && (req && !(gnt))), (s1sq[2] && (!(req) && !(gnt))) || (s1sq[4] && (!(req) && !(gnt))) || (s1sq[5] && !(gnt)), (s1sq[1] && req), !(req), 1’b1}; assign ASR_OUT = (s1s[3]); Fig. 5.10 HDL code for the checker in Example 5.5.

103

Chapter 6

Construction of PSL Assertion Checkers

Abstract This chapter presents the construction of checkers for PSL assertions, as used in checker generation. The approach is based on finite automata, and builds on the topics introduced in the previous chapter. The core techniques involve automata algorithms and rewrite rules to support the variety of PSL operators, and to then build an automaton for a given assertion.

6.1 Introduction and Overview The automaton framework for checkers was outlined in the previous chapter, where determinization and minimization issues were the two most significant issues treated. The current chapter presents the construction of automata for representing PSL expressions. The four main constituents of the PSL language, namely Booleans, sequences, properties and verification directives are each handled in separate sections. Boolean expressions, sequences and properties alone accomplish nothing in most verification tools, and must be used in verification directives. The bottom-up construction therefore begins with PSL Booleans and ends with verification directives. The underlying expectation is to produce the smallest automata so that when converted to RTL circuits, the checkers utilize fewer hardware resources. Automata for Booleans are constructed by first converting their expressions to HDL code, and then building a simple two-state automaton with the Boolean’s symbol on the edge. Automata for Booleans are the building blocks of sequences, both of which are building blocks of properties. Automata for sequences and properties are constructed directly using a variety of algorithms, or indirectly using rewrite rules. Rewrite rules are a syntactic transformation and are used to avoid the need for explicitly supporting an operator. When no rewrite rules apply, operators are handled with specific algorithms. To provide more useful debug information, the automata algorithms are designed such that the assertion signal does not simply indicate a yes/no answer obtained at 105

106

6 Construction of PSL Assertion Checkers

the end of execution, but rather a continuous and dynamic report of when the assertion has failed throughout the execution run (as discussed in Section 2.3). Although this chapter focuses on automata construction for PSL statements, building the actual checkers requires only the subsequent application of the automaton-to-circuit conversion developed in Section 5.3.

6.2 Automata Construction for Booleans The building blocks of an assertion are Boolean expressions over the signals in the design under verification. Whether in sequences or properties, Booleans are the lowest constituents in the PSL language hierarchy. The goal in this section is to implement all the Boolean items in Definition 4.1 as HDL code, and subsequently to construct automata for Booleans. In the following, H represents a portion of HDL code, and H (x) represents the conversion of an argument x into HDL code, and thus also represents a portion of HDL code. The argument can be a PSL expression or an automaton, depending on the case. The conversion of an automaton to HDL code, denoted H (A ), was already presented in Section 5.3. The construction of an automaton from a never property is used below in the implementation of ended(), but will be presented further in Section 6.4. The default clock declaration is handled in Section 6.5, and for now it is assumed that a global clock string holds the name of the clock signal in effect. To recall, the symbol A is used to represent an arbitrary automaton, as defined in Definition 5.3, and the functional form A (x) represents the construction of an automaton from an argument expression x, and is also an automaton because the return value is an automaton. A superscript, such as in A B (x), represents additional information to indicate what type of construction is desired (in this case Boolean). The other superscripts used are S , P and V for sequences, properties, and verification directives respectively. The resulting automata with superscripts also conform to the definition of automata given in the previous chapter. Implementing the Boolean layer is done in two parts: first the conversion of a Boolean to HDL is presented, and afterwards the expression of an automaton for a Boolean is derived, for use in the automata conversion of sequences and properties. The conversion of Booleans to HDL is presented below in Proposition 6.1, in a manner that resembles the syntax from Definition 4.1 as closely as possible, so that the link between syntax and implementation can be better observed. In the following, non-italicized prefixes separated by an underscore represent an additional type constraint, and do not represent a new type as such. Proposition 6.1. If b is a Boolean, i is a nonnegative integer, e is an Expression, f is a built-in function and s is a Sequence then the HDL conversion of Booleans defined in Definition 4.1 is denoted H (b), and is performed as follows:

6.2 Automata Construction for Booleans

107

H (b) : • H (boolean e) = [defined in next line] H (e) : • H (Verilog e) = e • H (b1 -> b2 ) = (!b1 || b2 ) • H (b1 <-> b2 ) = ( (!b1 || b2 ) && (!b2 || b1 ) ) • H (true) = 1’b1 • H (false) = 1’b0 • H ( f ) = [defined in next line] H (f) : • H (prev(e)) = D FF(e) • H (prev(e, i)) = D FFi (e) • H (rose(bit e)) = (∼D FF(e) & e) • H (fell(bit e)) = (D FF(e) & ∼e) • H (onehot(bit vector e)) = ( ((e-1) & e) == 0 ) • H (onehot0(bit vector e)) = ( H (onehot(e)) || (e ==0) ) • H (stable(e)) = (D FF(e) == e) • H (ended(s)) = H (A P (never s)) The items that have italicized comments in brackets do not actually need to be handled and are only kept to show the correspondence to Definition 4.1. Each item from Proposition 6.1 will be presented and explained below, immediately following its appearance. H (Verilog e) = e In the case where a Verilog expression is used as a Boolean, it is simply returned directly given that the Boolean layer is built upon the underlying HDL, which corresponds to Verilog HDL code in this case. H (b1 -> b2 ) H (b1 <-> b2 )

=

(!b1 || b2 )

=

( (!b1 || b2 ) && (!b2 || b1 ) )

(6.1)

Implication and equivalence are not part of the Verilog language as such, and are added to the definition of Booleans. These operators are expressed in Verilog using their respective Boolean equivalencies, as shown on the right above. H (true)

=

1’b1

H (false)

=

1’b0

Symbols true and false are expressed in HDL as single digit binary constants. The remaining cases from Proposition 6.1 are the built-in functions, described next. H (prev(e)) H (prev(e, i))

= =

D FF(e) D FFi (e)

108

6 Construction of PSL Assertion Checkers

In any given clock cycle n, the prev operator evaluates to the value of the argument expression at cycle n − i. The implementation for this operator is denoted symbolically above using the D FFi (e) function, and in reality corresponds to the instantiation of a register chain (or pipeline) with i stages in depth. The default clock is implicitly used as the clock signal for any flip-flop represented by the D FF() notation; the input of the flip-flop is the argument and the return value of D FF() represents the output of the flip-flop. Thus, the resulting expression of D FFi () evaluates to the signal or vector of the last register(s) in the chain. When the exponent is not specified, i = 1 is assumed. The register pipeline has the same width as the argument expression e. This register chain is created as actual HDL code using Verilog nonblocking assignments and the clock signal that exists in the global clock string at that time. For the case i = 0, no registers are created and the expression is returned directly. It should be noted that the flip-flops generated by D FFi (e) are not reset with the checker’s reset, and even if a built-in function is used under the scope of an abort operator, the abort has no effect on the flip-flops. In other words, these flip-flops are never reset, and are used purely to create a clock cycle delay. It is up to the implementation to determine their initial state. A flip-flop is in an undetermined state until a proper input value can be latched by the flip-flop. H (rose(bit e)) H (fell(bit e)) H (stable(e))

=

(∼D FF(e) & e)

= =

(D FF(e) & ∼e) (D FF(e) == e)

The above functions relate the value of an expression to the value in its previous clock cycle, and also use the HDL flip-flop declaration mentioned above. The rose() and fell() functions operate on single-bit expressions only, whereas bit vectors can be used in stable(). H (onehot(bit vector e)) H (onehot0(bit vector e))

= =

( ((e-1) & e) == 0 ) ( H (onehot(e)) || (e ==0) )

The implementation of the onehot function takes advantage of the arithmetic operators that can be specified in languages such as Verilog. Detecting the cases where a single bit is active in a sequence of bits is performed with the “bit trick” involving decrementation and word-level intersection. The onehot0 function also allows for all-zeros to occur, and is implemented using onehot() with an additional Boolean expression. (6.2) H (ended(s)) = H (A P (never s)) The ended function evaluates to logic-1 every time the argument sequence is matched. This is modeled using the never property, which triggers whenever its sequence argument is detected. The construction of automata for properties is treated further in this chapter, and must unavoidably be assumed at this point.

6.2 Automata Construction for Booleans

109

As shown in the right side in the rule above, the H () operator is used to indicate that a HDL circuit is actually instantiated for the never s part, and the signal returned by the ended operator is simply the signal indicating when the sequence is matched. It is this signal that is evaluated in an assertion, and is thus interpreted as a Boolean signal. It is precisely for this reason that built-in functions which should seemingly be part of the temporal layer of PSL, are actually part of the Boolean layer. The flip-flops comprising the automaton for the ended’s sequence s should be initially reset and not be externally reset afterwards; however, for simplicity in the checker generator they are actually reset when the checker is reset. If the ended function is under the scope of an abort operator, the abort has no effect on the automaton. In general, aborts and resets should have no effect on the temporal logic of builtin functions because the Boolean layer is meant to model expressions that are evaluated in a single clock cycle as seen from a PSL assertion, even though the built-in function’s internal logic may span over several clock cycles. The following example helps illustrate these points. Example 6.1. The following assertions, although very similar in intent, behave differently when the abort condition occurs. assert always ( ({a;b;c} |=> d) abort e ); assert always ( ({ended({a;b;c})} |=> d) abort e ); Given a trace where signals a, b and c are true on consecutive cycles and the abort condition coincides with b, as shown in Figure 6.1, the first assertion above does not fail whereas the second one does. Signal d is perpetually at logic-0, therefore in both assertions an occurrence of the a;b;c sequence should lead to a failure when no aborts are present. In the first assertion, the abort cancels the matching of the sequence, and the failure does not occur. In the second assertion, the abort has no effect on the internals of ended, thus the assertion fails. Had the abort occurred in cycle 5 instead of 4, both assertions would pass because the abort would mask the endpoint of the ended’s sequence.

a b c d e 1

2

3

4

5

6

7

8

Fig. 6.1 Trace for Example 6.1 use to show the effect of abort on the built-in function ended.

110

6 Construction of PSL Assertion Checkers

Algorithm 6.1 Automaton algorithm for HDL Boolean expressions. 1: FUNCTION: BASE C ASE(H ) 2: H ← remove outermost negations from H 3: π ← create or retrieve existing symbol in Π for H 4: if odd number of outermost negations were removed in line 2 then σ ← create or retrieve existing symbol in Σ for ¬π 5: 6: else σ ← create or retrieve existing symbol in Σ for π 7: 8: return new automaton A = ({q1 , q2 }, {(q1 , σ , q2 )}, {q1 }, {q2 }) !req 1

2

≡

σ1 1

2

s1= −p1 p1 = req

Fig. 6.2 Automaton for Boolean !req, denoted A B (!req), using Proposition 6.2. Simplified representation (left) and detailed representation (right).

The items contained in Proposition 6.1 show how any PSL Boolean can be expressed at the HDL level. Constructing an automaton for the matching of a Boolean, as required in sequences and properties, is described next in Proposition 6.2. Proposition 6.2. If b is a Boolean and H (b) represents the HDL expression for b, as presented in Proposition 6.1, then the construction of an automaton for Boolean b, denoted A B (b), is performed as follows: A B (b) : • A B (b) =

BASE C ASE(H (b))

An implicit consequence of the separate results in Proposition 6.1 and Proposition 6.2 is that automata are built only for top-level Booleans as opposed to building automata for arbitrary sub-expressions of a complex Boolean expression. The algorithm for creating an automaton for a Boolean’s HDL expression is described in Algorithm 6.1. This is the base case for the inductive automaton construction procedure for sequences. The algorithm takes an HDL expression as argument, and proceeds to build an extended symbol to represent it. Top-level negations are removed in line 2 and added in line 5 when necessary. The primary symbol alphabet is used in line 3, whereas the extended symbol alphabet is used in lines 5 and 7. This is where the dual-layer symbol alphabet takes form. The automaton that is returned in line 8 has two states, the first is an initial state and the second is a final state. A single edge connects the two in the proper direction. An example is shown in Figure 6.2 for the Boolean !req, where req is a valid signal in the design to be verified. The simplified representation on the left will be used more often; however, the detailed representation shows how the symbol alphabets are actually used.

6.3 Automata Construction for Sequences

111

6.3 Automata Construction for Sequences The recognition of a sequence requires conversion to an equivalent automaton, as shown here in an inductive manner. First, terminal automata are built for the Booleans in a sequence. Next, these automata are recursively combined according to the sequence operators comprising the given expression. Sequences are an important part of the temporal layer in PSL. Automata for representing sequences are constructed using separate automata algorithms, or indirectly using rewrite rules. Although no distinction is made here as to what operators are sugaring rules of PSL and which are the base cases, as will be pointed out further, some of the rewrite rules are based on the sugaring definitions in Appendix B of the PSL specification [108]. Automata for other sequence operators are constructed with specialized algorithms, such as fusion and intersection. These two operators are not often used in automata for conventional regular expressions, and the related algorithms will each be treated in their own subsection. An important factor that must be considered in these and other automata algorithms is the symbolic alphabet used to perform pattern matching over Boolean expressions. The automaton construction of sequences is shown below in Proposition 6.3. Items with an italicized comment in square brackets are part of the BNF syntax specification and were maintained to keep Proposition 6.3 as similar as possible to its related definition (Definition 4.2). Proposition 6.3. If i and j represent nonnegative integers with j ≥ i, and k and l represent positive integers with l ≥ k, b represents a Boolean, s represents a Sequence, r represents a SERE, r r represents a repeated SERE, c r represents a compound SERE, then the automaton construction for sequences, denoted A S (s), is performed as follows: A S (s) : • A S (r r) = [defined below] • A S ({r}) = A S (r) A S (r) : • A S (b) = A B (b) • A S (s) = [defined above] • A S (r1 ; r2 ) = C ONCATENATE(A S (r1 ), A S (r2 )) • A S (r1 : r2 ) = F USE(A S (r1 ), A S (r2 )) • A S (c r) = [defined in next line] A S (c r) : • A S (s) = [defined above] • A S (c r1 | c r2 ) = C HOICE(A S (c r1 ), A S (c r2 )) • A S (c r1 & c r2 ) = A S ({{c r1 }&&{c r2 ;[*]}} | {{c r1 ;[*]}&&{c r2 }}) • A S (c r1 && c r2 ) = I NTERSECT(A S (c r1 ), A S (c r2 )) • A S (c r1 within c r2 ) = A S ({[*];c r1 ;[*]} && {c r2 })

112

6 Construction of PSL Assertion Checkers

A S (r r) : • A S (b[*]) = K LEENE C LOSURE(A B (b)) • A S (b[*i]) = A S (b[*i:i]) • A S (b[*i: j]) = R ANGE R EPEAT(i, j, A B (b)) • A S (b[*i:inf]) = A S (b[*i];b[*]) • A S (s[*]) = K LEENE C LOSURE(A S (s)) • A S (s[*i]) = A S (s[*i:i]) • A S (s[*i: j]) = R ANGE R EPEAT(i, j, A S (s)) • A S (s[*i:inf]) = A S (s[*i];s[*]) • A S ([*]) = A S (true[*]) • A S ([*i]) = A S (true[*i]) • A S ([*i: j]) = A S (true[*i: j]) • A S ([*i:inf]) = A S (true[*i:inf]) • A S (b[+]) = A S (b;b[*]) • A S (s[+]) = A S (s;s[*]) • A S ([+]) = A S (true; true[*]) • A S (b[=i]) = A S (b[=i:i]) • A S (b[=i: j]) = A S ({!b[*];b}[*i: j]; !b[*]) • A S (b[=i:inf]) = A S (b[=i]; [*]) • A S (b[->]) = A S (b[->1]) • A S (b[->k]) = A S (b[->k:k]) • A S (b[->k:l]) = A S ({!b[*];b}[*k:l]) • A S (b[->k:inf]) = A S ({b[->k]}; {[*0]}|{[*];b}) The item A S (b) = A B (b) uses the automata construction for Booleans introduced in Proposition 6.2. All other items fall into two categories, namely those with direct algorithms, and those that based on rewrite rules. Items based on rewrite rules can be easily identified since they have the form A S () = A S (), and will be treated in Subsection 6.3.5.

6.3.1 Conventional Regular Expression Operators The conventional regular expression operators are concatenation, choice and Kleene closure (Kleene star), and are also used in sequences. The Boolean expression symbol alphabet produces nondeterministic automata because from a given state, two distinct symbols can cause simultaneous outgoing transitions when their respective Boolean expressions are both true. The NFA construction for conventional operators that was presented in Figure 3.1 can be reused given that both types of automata are nondeterministic. Since the automata for assertions (Definition 5.3) allow multiple initial states and do not use ε transitions, alternate algorithms for the three conventional operators must be developed. The concatenation of two compound SEREs is performed as follows. A S (r1 ; r2 )

=

C ONCATENATE(A S (r1 ), A S (r2 ))

6.3 Automata Construction for Sequences

113

Algorithm 6.2 Automata concatenation algorithm. 1: FUNCTION: C ONCATENATE(AL , AR ) 2: create new automaton A = (QL ∪ QR , δL ∪ δR , IL , FR ) //Q, δ , I, F 3: for each state fL ∈ FL do 4: for each edge (sR , σR , dR ) ∈ δR | sR ∈ IR do δ ← δ ∪ {( fL , σR , dR )} 5: 6: if sR ∈ FR then 7: F ← F ∪ { fL } 8: return A Algorithm 6.3 Automata choice algorithm. 1: FUNCTION: C HOICE(A1 , A2 ) 2: return new automaton A = (QL ∪ QR , δL ∪ δR , IL ∪ IR , FL ∪ FR )

Algorithm 6.2 presents the algorithm used for the concatenation of two argument automata. In concatenation, for each final state in the left-side automaton, a copy of all edges that originate from the initial states in the right-side automaton is made, whereby the new edges originate from the given final state in the left side (lines 3 to 5). This operation was outlined by a diagram earlier in Figure 3.1f, Chapter 3, and is further detailed in Figure 6.3f. In this manner, each time the left side is matched, the right side is triggered. The final states correspond to the right-side automaton’s final states (line 2). When the right side has an initial state that is also a final state, final states in the left side are kept final so that the left side can also cause a successful match (lines 6 and 7). The disjunction of two compound SEREs is similar to the choice operation of conventional regular expressions, and is performed as follows. A S (c r1 | c r2 )

=

C HOICE(A S (c r1 ), A S (c r2 ))

Automata choice is rather straightforward, given that multiple initial states are permitted by the automaton definition (Definition 5.3). The algorithm for performing automata choice is presented in Algorithm 6.3. With multiple initial states, automata choice amounts to integrating both argument automata into the same result automaton, such that both are disjoint, and the set of states, the set of transitions, the set of initial states and the set of final states are merged (line 2). Two items in Proposition 6.3 make use of Kleene closure: A S (b[*]) A S (s[*])

=

K LEENE C LOSURE(A B (b))

=

K LEENE C LOSURE(A S (s))

The Kleene closure (or star repetition) of a Sequence or Boolean is performed using the K LEENE C LOSURE() algorithm, presented in Algorithm 6.4. Each edge that hits a final state is replicated using the same symbol, whereby the destination states of the new edges correspond to the initial states (lines 3 to 5). In this way, each time a final state is activated, the automaton is also automatically retriggered. In line 7,

114

6 Construction of PSL Assertion Checkers

a) terminal symbol a 1 2 b) empty 1

c) null 1 d) Kleene closure A[*] a

1

e) choice A|B a 1

3

b

2

b

a

b

2

*

|

3 a

1

1

5

2

a

c

b

2

c

4

1

=

2

3

b

d

3

=

3

=

3

d

6

f) concatenation A;B a

1

1

b

2 a

b

2 c

;

3

3

1

4

c

c

2

5

d

d

6

c

Fig. 6.3 Automata examples for conventional RE operators. In the examples, a, b, c and d are Booleans, automaton A matches the sequence {a;b[*0:1]} and automaton B matches the sequence {c;d}. In the concatenation example, the state in light-gray is pruned during minimization.

all the initial states are made final states, such that the empty match is performed as required for Kleene closure. The separate transition relation δ1 used in lines 2, 5 and 6 ensures that the algorithm operates correctly and does not enter a potentially infinite loop. All three algorithms for the concatenation, choice and Kleene closure operators are linear in the size (number of states) of the input automata. An indication that these algorithms are not restricted to automata that use the two-layer symbol

6.3 Automata Construction for Sequences

115

Algorithm 6.4 Automaton Kleene-closure algorithm. 1: FUNCTION: K LEENE C LOSURE(A ) 2: create transition relation δ1 = 0/ 3: for each edge (s, σ , d) ∈ δ | d ∈ F do 4: for each state i ∈ I do δ1 ← δ1 ∪ {(s, σ , i)} 5: 6: δ ← δ ∪ δ1 7: F ← F ∪ I 8: return A

alphabet lies in the observation that no symbol sets (Π nor Σ ) are affected by these algorithms, and they could well be used in the context of conventional regular expressions. Examples for the three conventional operators are shown in Figure 6.3. The automata for the empty and null sequences (Definition 4.3) are also illustrated to show the nuance with how they were defined in Figure 3.1 for conventional NFAs. The automaton for matching the empty sequence consists of a single state which is both an initial state and a final state. This automaton is produced when the sequence [*0] is used. The automaton for matching the null sequence consists of a single initial state with no final states, and is a valid automaton according to Definition 5.3. This automaton is produced when the sequence {[*1]&&[*2]} is used, for example.

6.3.2 Sequence Fusion In Proposition 6.3, the fusion of two SEREs was handled as follows. A S (r1 : r2 )

=

F USE(A S (r1 ), A S (r2 ))

As observed in Section 4.1, SERE fusion corresponds to an overlapped concatenation. The algorithm for performing the fusion of two automata is presented in Algorithm 6.5. The algorithm starts by incorporating both argument automata into a new automaton such that they are disjoint (line 2). From there, intersection edges are created from edges that hit final states in the left-side automaton and edges that leave the initial states in the right-side automaton. The intersection of symbols in line 5 benefits from the polarity that is encoded in the dual layer alphabet, and can detect conditions where Boolean conjunctions simplify to false. In such cases no edge is actually created in line 7 (not shown in the algorithm). The extended symbol created or retrieved in line 5 does not affect the set of primary symbols Π . The condition in line 6 has no effect and is always true in SEREs because the End of Execution (EOE) signal applies only at the property level. This line is required to ensure the proper behavior of certain strong properties that also make use of the fusion algorithm, and is explained in Subsection 6.4.1.

116

6 Construction of PSL Assertion Checkers

Algorithm 6.5 Automata fusion algorithm. 1: FUNCTION: F USE(AL , AR ) 2: create new automaton A = (QL ∪ QR , δL ∪ δR , IL , FR ) //Q, δ , I, F 3: for each edge (sL , σL , dL ) ∈ δL | dL ∈ FL do 4: for each edge (sR , σR , dR ) ∈ δR | sR ∈ IR do σ ← create or retrieve symbol in Σ for σL ∧ σR 5: 6: if EOE signal ∈ / σ ’s primary symbols then δ ← δ ∪ {(sL , σ , dR )} 7: 8: return A b 1

a

2

:

c

1

d

2

=

3

b 1

a a∧c

2

3

c

4

d

5

b∧c

Fig. 6.4 SERE fusion example for {a;b[*]}:{c;d}. The state in light-gray is pruned during minimization.

An illustration of SERE fusion is shown in Figure 6.4 for the SERE {a;b[*]}: {c;d}. SERE fusion produces an automaton that has O(m + n) states, where m and n are the sizes of the input automata. Because empty SEREs on either side do not result in a match, final states in the left-side automaton are not final states in the resulting automaton. Similarly, the initial states in the right-side automaton are not initial states in the resulting automaton (line 2). Thus, if an initial state in the right side is a final state, it will not result in an instant match. The number of edges that are added can be determined by examining the two for loops in the algorithm.

6.3.3 Length-Matching Intersection The length-matching intersection of two compound SEREs was handled as follows in Proposition 6.3. A S (c r1 && c r2 )

=

I NTERSECT(A S (c r1 ), A S (c r2 ))

Typical automata intersection [100], which equates to building a product automaton of both arguments, is incompatible with the symbolic alphabet and can not be used directly in the intersection algorithm. If the traditional intersection procedure is applied to two automata that have no symbol in common (i.e. no syntactically equal symbols), the null automaton results (Figure 3.1). This automaton can obviously not detect the intersection of two SEREs which use disjoint sets of extended symbols. To illustrate, if the intersection of {a;b} and {c;d} is performed using typical automata intersection, the fact that the two sequences have no symbols in

6.3 Automata Construction for Sequences

117

Algorithm 6.6 Automata intersection algorithm. 1: FUNCTION: I NTERSECT(A1 , A2 ) 2: A1 ← W EAK D ETERMINIZE(A1 ); 3: A2 ← W EAK D ETERMINIZE(A2 ); 4: //here |I1 |=|I2 |=1; i.e. I1 = {i1 }, I2 = {i2 } 5: //a label is an ordered pair (u, v) | u ∈ Q1 , v ∈ Q2 6: create new state q labeled with (i1 , i2 ) 7: create new automaton A = ({q}, 0, / {q}, 0) / //Q, δ , I, F 8: add q to an initially empty set C //C is “to-construct” 9: while C = 0/ do 10: remove a state r (with its label (u, v)), from C 11: if u ∈ F1 and v ∈ F2 then 12: F ← F ∪ {r} 13: for each edge (s1 , σ1 , d1 ) ∈ δ1 | s1 = u do 14: for each edge (s2 , σ2 , d2 ) ∈ δ2 | s2 = v do 15: find state t ∈ Q with label (d1 , d2 ) 16: if
t then 17: create new state t ∈ Q labeled with (d1 , d2 ) 18: C ← C ∪ {t} σ ← create or retrieve symbol in Σ for σ1 ∧ σ2 19: 20: δ ← δ ∪ {(r, σ ,t)} 21: return A

common leads to the null automaton (a single initial state with no edges nor final states). Since the symbols used in the sequences are Boolean expressions as opposed to characters in string matching, the automaton should report a match when both a and c are true in one cycle, and b and d are true in the next cycle. To implement the intersection algorithm correctly, the condition on syntactic equality of symbols must be relaxed and the conjunction of symbols must be considered by the algorithm. To consider all relevant pairs of edges, the product automaton is constructed in such a way as to perform Boolean intersection between pairs of edges, where each edge in a pair is from a separate automaton. As shown in the intersection algorithm in Algorithm 6.6, a state in the intersection automaton is labeled by an ordered pair (u, v), where u and v correspond to states from the first and second argument automata respectively. The state creation set (line 8) is the key component in the algorithm, and is initialized to the pair of initial states (line 6) of both argument automata. The two input automata are weakly determinized in lines 2 and 3; a side-effect of this is that each resulting automaton has a single initial state. The automata are made weakly deterministic so that when considering a symbol from an edge in each automaton, σ1 and σ2 for instance, there is one and only one destination state in each automaton, such that a state pair (d1 , d2 ) represents a new state in the intersection automaton. The two for loops in lines 13 and 14 intersect two states, and the while loop together with the set C create the entire intersection automaton. A new state (u, v) is a final state if and only if states u and v are final states in their respective automata. The symbol created or retrieved in line 19 affects only the set of extended symbols Σ .

118

6 Construction of PSL Assertion Checkers a 1

b

2

&&

1

a∧c

1,2

b∧c

2,2

1,1

c a∧d

2

d

3

=

1,3

b∧d 2,3

Fig. 6.5 Sequence intersection example for {a[*];b}&&{c;d}. States in light-gray are pruned.

The algorithm creates new states and edges only for the reachable states of the resulting automaton. The symbol intersection in line 19 also benefits from the polarity encoded in the dual layer alphabet, and can detect conditions where Boolean conjunctions simplify to false. In such cases no edge is created, and the block of statements in lines 15 to 20 is not executed (not shown in the algorithm). An example depicting intersection is shown in Figure 6.5 for {a[*];b}&& {c;d}. Sequence intersection produces an automaton that has in the worst case O(mn) states, where m and n are the number of states in the input automata. The algorithm is proven to terminate because only a finite number of states can be added to the construction set. In the HDL code, the conjunction symbol ∧ is implemented using the Verilog logical conjunction operator &&.

6.3.4 Repetition with a Range Sequence and Boolean repetition with a range is required to handle the following items from Proposition 6.3: A S (b[*i: j]) A S (s[*i: j])

= =

R ANGE R EPEAT(i, j, A B (b)) R ANGE R EPEAT(i, j, A S (s))

The PSL specification indicates that sequence repetition with a range can be defined using sequence disjunction as follows: s[*i: j]

def

=

s[*i] | ...| s[* j]

(6.3)

The above equation could be used to form a rewrite rule in the next section; however, since the actual syntactic size of the expression on the right side is not fixed in size and is a function of the parameters i and j, it is more efficient to develop a particular algorithm for the range repetition, both in the interest of efficient rewriting and for the actual creation of automata. Whether for a Boolean or a sequence, the range repetition of an automaton is performed using the algorithm in Algorithm 6.7.

6.3 Automata Construction for Sequences

119

Algorithm 6.7 Automata range repetition algorithm. 1: FUNCTION: R ANGE R EPEAT(low, high, A ) 2: if high = 0 then //high ≥ low is assumed / {q1 }, {q1 }) //Q1 , δ1 , I1 , F1 3: create new automaton A1 = ({q1 }, 0, 4: else 5: create new automaton A1 = A 6: for i ← 2 to high do 7: A1 ← C ONCATENATE(A1 , A ) 8: if i ≤ (high − low + 1) then 9: I1 ← I1 ∪ {s | s ∈ Q1 , s was in I (in A ) before the concatenation} 10: if low = 0 then 11: F1 ← F1 ∪ I1 12: return A1

The algorithm assumes that the upper bound for the repetition is greater or equal to the lower bound. The special case high = 0 is handled separately in line 3, and produces the empty automaton that was shown in Figure 6.3b. When high > 0, the returned automaton is initially formed as a copy of the argument automaton (line 5). Lines 6 and 7 concatenate additional copies of the argument automaton high − 1 times (line 6: for loop from 2 to high). When high < 2, this block of lines has no effect since no concatenations are needed. Normally, concatenation does not include the initial states of the right-side automaton in the set of initial states of the resulting automaton. Lines 8 and 9 counteract this and are the mechanism by which the repetition range is performed. The first high − low + 1 concatenations’ initial states will remain as initial states for the resulting automaton. This has the effect of triggering the concatenation chain for a certain prefix of copies of the concatenated argument automata, such that different lengths of matching can be produced. This technique is referred to as initial-state prefix triggering. Another technique for performing range repetition consists of instead adding the final states of the left-side automaton in the concatenation step to the set of final states when i ≥ low. This is not optimal as the further concatenations in the loop involve progressively more and more final states from the growing left side automaton, and hence more edges are generated. Even though minimization can reduce the size of the automaton, the algorithm should strive to be the most efficient possible especially when a large range is used. This technique is referred to as final-state suffix signaling. The two range repetition techniques introduced above are illustrated in Figure 6.6. In this figure, the concatenation symbols (the semicolons between the automata) are meant to indicate that concatenations were performed, while for simplicity no edges were actually represented. The focus of this figure is on the initial states and the final states that remain after the concatenations have been performed. The strategy at the top of the figure triggers the automata at varying start points to perform the range matching, whereas the strategy illustrated in the bottom of the figure reports the matches at varying points in the final states to perform the same range matching.

120

6 Construction of PSL Assertion Checkers

a) A

;

A

;

A

;

A

;

A

A

;

A

;

A

;

A

;

A

b)

Fig. 6.6 Range repetition strategies for: (a) initial-state prefix triggering and (b) final-state suffix signaling. The automaton A was repeated with the range low = 2, high = 5.

With both techniques, in this example the resultant automata match anywhere from two to five instances of the argument automaton A. The disadvantage of final-state suffix signaling (at the bottom of the figure) is that concatenations are performed on a left-side automaton that has more and more final states, and a growing number of edges come into play. For example, if a sixth instance of automaton A is to be concatenated at the end of the graphs in Figure 6.6, the concatenation algorithm in Algorithm 6.2 will cause many more edges to be added in part b than in part a. The range repetition algorithm creates an automaton that is linear in size complexity with respect to the size (number of states) of the argument automaton.

6.3.5 Rewrite Rules The items in Proposition 6.3 that have not been treated thus far have a common characteristic: they have the form A S (x) = A S (y). More generally, the link between the arguments can be expressed as a rewrite rule of the form x → y, where x is rewritten to y. Expression rewriting (or term rewriting) is a practical way of allowing the checker generator to handle the large amount of sequence operators, while only requiring algorithms for a much smaller number of operators in the tool’s kernel. The rewrite rules used are either derived from the SERE sugaring definitions in Appendix B in the PSL specification [108] directly, or with small modifications. Although a few of these rewrite rules may appear intuitive, they are nonetheless included for completeness. Each rule is explained immediately following its appearance. {r} → r The above rule is straightforward, given that semantically the curly brackets are used only for grouping and their main effect is instead in the syntax of SEREs. c r1 & c r2

→

{{c r1 }&&{c r2 ;[*]}} | {{c r1 ;[*]}&&{c r2 }}

(6.4)

The preceding rule for non-length-matching SERE intersection attempts to extend the shortest of the two SEREs with a [*] in order to use length-matching intersection. Since the shorter of the two SEREs can not be known a priori, the two

6.3 Automata Construction for Sequences

121

possibilities are modeled and connected with SERE disjunction. c r1 within c r2

→

{[*];c r1 ;[*]} && {c r2 }

(6.5)

When a compound SERE must be matched within the matching of another, the first SERE is made to start at a varying point with respect to the second SERE by concatenating a leading [*]. The SERE is also lengthened with a trailing [*] so that mapping to length-matching intersection can be performed. The within rewrite and the non-length-matching intersection rewrite (&) both follow directly from the PSL specification [108]. b[*i] s[*i]

→ →

b[*i:i] s[*i:i]

The single number repetition, whether for Booleans or sequences, is rewritten to the range repetition given that the range repetition must also be handled. b[*i:inf]

→

s[*i:inf]

→

b[*i];b[*] s[*i];s[*]

(6.6) (6.7)

When the upper bound in a range repetition is infinite, the sequence or Boolean is repeated the minimum number of times, and is subsequently allowed to be matched any additional number of times (including 0 times), hence the concatenated Kleene closure of the sequence or Boolean. [*] [*i] [*i: j]

→ → →

true[*] true[*i] true[*i: j]

[*i:inf]

→

true[*i:inf]

The various forms of [*] repetition that do not specify a sequence or Boolean implicitly apply to the Boolean true, and can be rewritten as such, as shown above. b[+] s[+] [+]

→ → →

b;b[*] s;s[*] true; true[*]

The various forms of [+] repetition above correspond to repetitions of one or more instances, and can be rewritten using [*] repetition. The three previous groups of rewrites follow directly from the PSL specification [108]. b[->] b[->k]

→ →

b[->1] b[->k:k] (6.8)

122

6 Construction of PSL Assertion Checkers

Both forms of goto repetition above are rewritten to more complex forms of goto repetition. The goto repetitions are actually defined differently in the PSL specification [108], as shown below: def

b[->]

=

!b[*];b

def

{!b[*];b}[*k]

=

b[->k]

(6.9) (6.10)

The form chosen in this work is equivalent to the one in the PSL specification, and more closely reflects how those operators are actually handled in the checker generator. In some cases, mapping an operator to a more complex variant of the same operator can be a simpler solution. b[->k:l]

→

{!b[*];b}[*k:l]

(6.11)

The goto repetition with a range is the most complex of goto repetitions, and is rewritten using a different approach than in the PSL specification. In the PSL specification [108], this operator is defined as: b[->k:l]

def

=

b[->k] | . . . | b[->l]

The expression on the right side has the disadvantage that its size depends on the values of k and l. The form chosen in (6.11) is more efficient for term rewriting because of its fixed size. The following proof shows the equivalency of the version in the PSL specification [108] with the version used (6.11):

⇔ ⇔

b[->k] | . . . | b[->l] {!b[*];b}[*k] | . . . | {!b[*];b}[*l] {!b[*];b}[*k:l] //using (6.3)  

//using (6.10)

All rewrite rules developed in this work do not have variable right-hand sizes, and a more static form is preferred for performance reasons and for simplicity of implementation in the checker generator. It should also be stated that when devising rewrite rules, proper care must be taken to ensure that the set of rewrite rules is terminating (Definition 4.7). For example, if the right side in (6.11) was {b[->]}[*k:l], the set would be nonterminating. Here is how the non-terminating, thus incorrect set of goto rules would appear: b[->] b[->k] b[->k:l]

→ → →

b[->1] [->k:k] {b[->]}[*k:l]

In the above rules, there is an infinite loop as the first rule uses the second, the second uses the third, and the third rule uses the first.

6.3 Automata Construction for Sequences

b[->k:inf]

→

123

{b[->k]}; {[*0]}|{[*];b}

(6.12)

Goto repetition with an infinite upper bound is rewritten above in a slightly different manner than the definition in the PSL specification [108]. The PSL specification has the following expression as the right side: b[->k:inf]

def

b[->k] | {b[->k];[*];b}

=

(6.13)

The forms in (6.12) in (6.13) are equivalent because the expression b[->k] can be temporally factored. Temporally factoring a sequence corresponds to removing a common temporal prefix in two subsequences, and concatenating it with the reduced subsequences. In the case used above, the temporal factoring of b[->k] from the disjunction requires the use of the empty SERE, and yields the form in (6.12). The factored form was chosen for efficiency reasons to avoid building an automaton for b[->k] twice. Temporal factoring can also apply to common suffixes in sequences. b[=i]

→

b[=i:i]

(6.14)

The single parameter nonconsecutive repetition shown above is rewritten to a more complex form of the same operator. This operator is defined differently in the PSL specification [108]: def

=

b[=i]

{!b[*];b}[*i];!b

(6.15)

The approach chosen for this operator was also to map it to a more complex version of the same operator. b[=i: j]

→

{!b[*];b}[*i: j]; !b[*]

(6.16)

Nonconsecutive repetition with a range, as shown above, is handled with a rewrite that differs from the PSL specification [108]. The documented definition of nonconsecutive repetition with a range is: b[=i: j]

def

=

b[=i] | . . . | b[= j]

The expression on the right side once again has the disadvantage that its size depends on the values of the parameters. Similarly to the goto repetition case, the form chosen in (6.16) is more efficient for term rewriting because of its fixed size. The following proof shows the equivalency of the definition in the PSL specification [108] with the version used in (6.16):

⇔ ⇔

b[=i] | ...| b[= j] {!b[*];b}[*i];!b | . . . | {!b[*];b}[* j];!b //using (6.15) { {!b[*];b}[*i] | . . . | {!b[*];b}[* j] } ; !b //suffix fact.

⇔

{!b[*];b}[*i: j] ; !b

//using (6.3)  

124

6 Construction of PSL Assertion Checkers

The above derivation is used to create a rewrite rule with a fixed size on the right side. b[=i:inf] = b[=i]; [*] The final rewrite rule left to cover is the goto repetition with an infinite upper bound, which follows directly from its definition in the PSL specification [108]. This concludes the development of rewrite rules for sequences, and together with the algorithms from the previous subsections, automata for recognizing PSL sequences can be constructed. Sequences form an important part of properties, which are treated next. Surprisingly, many algorithms devised for sequence operators are also reused at the property level. Rewrite rules also play a very important role for handling the large amount of property operators.

6.4 Automata Construction for Properties Continuing the bottom-up construction of PSL directives now leads to the construction of automata for PSL properties. The automaton for a property p is denoted A P (p). The superscript P is used to indicate the context of properties. It does not represent a new automaton type, and is used to remove the ambiguity between the automaton for a Boolean used as a property and the automaton for a plain Boolean, from Section 6.2. An automaton A P is defined exactly the same way as an automaton A from the previous chapter, and all automata algorithms from that chapter can be used here with A P automata as arguments. The superscript is particularly important in properties because A P (b) = A B (b) : the left side builds an automaton from a Boolean b appearing as property, whereas the right side builds an automaton for a plain Boolean, appearing in a Sequence for example. The automaton construction for properties is presented below in Proposition 6.4, in a form that resembles the definition of properties (Definition 4.4) as most as possible, so that the link between syntax and automaton construction can be better observed. Proposition 6.4. If i and j represent nonnegative integers with j ≥ i, k and l represent positive integers with l ≥ k, b is a Boolean, s is a Sequence, f p is a FL Property, p is a property, then the automaton construction for properties, denoted A P (p), is performed as follows: A P (p) : • A P (forall ident in boolean: p) = C HOICE(A P ((p)ident←true ), A P ((p)ident←false )) P • A (forall ident in {i: j}: p) = F ORALL R ANGE(i, j, ident, p) • A P ( f p) = [defined in next line] A P ( f p) : • A P (b) = F IRST FAIL(A B (b)) • A P (( f p)) = A P ( f p)

6.4 Automata Construction for Properties

125

• A P (s !) = F IRST FAIL S TRONG(A S (s)) • A P (s) = F IRST FAIL(A S (s)) • A P ( f p abort b) = A DD L ITERAL(A P ( f p), H (!b)) • A P (! b) = F IRST FAIL(A B (!b)) • A P ( f p1 && f p2 ) = C HOICE(A P ( f p1 ), A P ( f p2 )) • A P (b || f p) = A P ({!b} |-> f p) • A P (b -> f p) = A P ({b} |-> f p) • A P (b1 <-> b2 ) = F IRST FAIL(A B (b1 <-> b2 )) • A P (always f p) = A P ({[+]} |-> f p) • A P (never s) = A P ({[+] : s} |-> false) • A P (next f p) = A P (next[1]( f p)) • A P (next! f p) = A P (next) • A P (eventually! s) = A P ({[+] : s}!) • A P ( f p until! b) = A P (( f p until b) && ({b[->]}!)) • A P ( f p until b) = A P ({(!b)[+]} |-> f p) • A P ( f p until! b) = A P (( f p until b) && ({b[->]}!)) • A P ( f p until b) = A P ({ {(!b)[+]} | {b[->]} } |-> f p) • A P (b1 before! b2 ) = A P ({(!b1 &&!b2 )[*] ; (b1 &&!b2 )}!) • A P (b1 before b2 ) = A P ({(!b1 &&!b2 )[*] ; (b1 &&!b2 )}) • A P (b1 before! b2 ) = A P ({(!b1 &&!b2 )[*] ; b1 }!) • A P (b1 before b2 ) = A P ({(!b1 &&!b2 )[*] ; b1 }) • A P (next[i]( f p)) = A P (next event(true)[i+1]( f p)) • A P (next) = A P (next event!(true)[i+1]( f p)) • A P (next a[i: j]( f p)) = A P (next event a(true)[i+1 : j+1]( f p)) P • A (next a) = A P (next event a!(true)[i+1 : j+1]( f p)) P • A (next e[i: j](b)) = A P (next event e(true)[i+1 : j+1](b)) P • A (next e) = A P (next event e!(true)[i+1 : j+1](b)) P • A (next event!(b)( f p)) = A P (next event!(b)[1]( f p)) • A P (next event(b)( f p)) = A P (next event(b)[1]( f p)) • A P (next event!(b)[k]( f p)) = A P (next event a!(b)[k:k]( f p)) P • A (next event(b)[k]( f p)) = A P (next event a(b)[k:k]( f p)) P • A (next event a!(b)[k:l]( f p)) = A P (next event a(b)[k:l]( f p) && {b[->l]}!) P • A (next event a(b)[k:l]( f p)) = A P ({b[->k:l]} |-> f p) • A P (next event e!(b1 )[k:l](b2 )) = A P ({b1 [->k:l] : b2 }!) • A P (next event e(b1 )[k:l](b2 )) = A P ({b1 [->k:l] : b2 }) • A P (s |-> f p) = F USE(A S (s), A P ( f p)) • A P (s |=> f p) = A P ({s ; true} |-> f p)

126

6 Construction of PSL Assertion Checkers

The following example motivates the importance of the superscript symbols in the automata construction formalism. A P (s1 |-> s2 ) In the expression above, s1 and s2 are sequences; however, s2 is used directly as a property whereas s1 is the antecedent of a suffix implication (which must be a sequence proper). After one step of processing using the results above, the property reduces to: F USE(A S (s1 ), A P (s2 )) Here it is apparent that s1 and s2 are not interpreted in the same manner (superscripts). Continuing one step further: F USE(A S (s1 ), F IRST FAIL(A S (s2 ))) Now both sequences can be constructed using the procedures in the previous section. Many properties are handled by either directly expressing them as sequence expressions, or by using the algorithms developed for sequences. In general, the construction of automata for properties falls in two categories: base cases or rewrite rules. In the following subsections, each property will be explained immediately following its appearance.

6.4.1 Base Cases for Properties In this subsection, properties that require separate algorithms are treated. Some properties make direct use of sequence algorithms but can not be expressed as rewrite rules, therefore these properties are also treated here. A P (forall ident in boolean: p) = C HOICE(A P ((p)ident←true ), A P ((p)ident←false )) The forall property replication with a boolean is accomplished by disjoining the automata for two versions of the property, one where the identifier is substituted with true and the other with false. The construction of the automata then proceeds as illustrated in Figure 6.3e. The following rewrite is not a syntactically valid rule, although it appears logical: forall ident in boolean: p

 (p)ident←true && (p)ident←false

Rewrite rules must adhere to the formal definitions of the language, and in the case above, the FL Property conjunction operator && can not be used because forall operates on the type “Property”. As will be explained further, property conjunction is actually performed using automata disjunction. Since two failure matching automata representing

6.4 Automata Construction for Properties

127

Algorithm 6.8 Forall algorithm for property p that uses identifier ident; i and j are nonnegative integers. 1: FUNCTION: F ORALL R ANGE(low, high, ident, p) 2: create new automaton A = A P ( (p)ident←low ) 3: for i ← low + 1 to high do 4: A ← C HOICE(A , A P ( (p)ident←i )) 5: return A

sub-properties must both hold, both automata must be triggered to find any possible failure. This explains why the C HOICE() algorithm was invoked in the first rule in this subsection (forall), while intuitively the forall property operator implies that each replication must hold (i.e. that their conjunction must hold). A P (forall ident in {i: j}: p) =

F ORALL R ANGE(i, j, ident, p)

Supporting the forall operator over a range of integers is performed using the F ORALL R ANGE() algorithm presented in Algorithm 6.8. The algorithm closely resembles the treatment of the Boolean version of forall, with the exception that multiple choice operations are required to handle the range of values required. This is performed by the for loop in line 3. The loop starts at low + 1 because a choice operation is not required for the first instance corresponding to the case ident ← low (line 2). A P (( f p)) = A P ( f p) Parentheses are used only for grouping and can be dropped as shown above. A P (! b)

=

F IRST FAIL(A B (!b))

A P (b1 <-> b2 )

=

F IRST FAIL(A B (b1 <-> b2 ))

Certain properties such as negation and equivalence are relegated to the Boolean layer in the simple subset. The negation and equivalency of properties, as defined in full PSL, create properties that are not easily handled in the context of monotonically advancing time. The F IRST FAIL() algorithm is used when Booleans and sequences are used at the property level, as explained next. A P (b) A P (s)

= =

F IRST FAIL(A B (b)) F IRST FAIL(A S (s))

(6.17)

When Booleans and sequences are used as properties (above), their non-occurrence must be detected. The automata built by the algorithms from the previous sections perform precisely the task of Boolean and sequence matching. When used as properties however, a Boolean or sequence’s non-fulfillment indicates an error. In dynamic verification this can be interpreted as the matching of the first failure. Therefore, a separate procedure is required to transform the matching automaton into a firstfailure matching automaton.

128

6 Construction of PSL Assertion Checkers

The failure algorithm implements a form of negation; however this does not correspond to classical automata negation because for run-time monitoring, it is more practical to report only the first failure for a given activation. The following example shows why negation is not appropriate in dynamic verification. Example 6.2. Consider the following assertion that states that whenever a is true, b must be true in the next two cycles: assert always {a} |=> {b[*2]}; The sequence {b[*2]} is modeled by the automaton A1 = A S ({b[*2]}) and describes the language L(A1 ) = { {b;b} } Since the sequence is used as a property, its non-occurrence must be detected because it is expected to hold. The language desired by this property is modeled by the automaton A2 = F IRST FAIL(A1 ) = A P ({b[*2]}) whose language should intuitively correspond to L(A2 ) = { {!b}, {b;!b} } As will be shown further, the F IRST FAIL() algorithm transforms an automaton to match the first non-occurrence instead. In this example, the first failure occurs when b is false in the first cycle of the right side, or when b is true then followed in the next cycle by a false b. This represents the optimal error reporting behavior desired for run-time debugging using the assertion. The point of the example is to show that negation is not appropriate for this type of failure transformation. Below is the actual language that would be matched if negation was used (the N EGATE() algorithm was described in Subsection 5.2.4): A3 = N EGATE(A1 ) L(A3 ) = L(A1 ) = { {[*0]}, {b}, {!b}, {b;!b}, {!b;b}, {!b;!b}, {b;b;b}, . . . } The problem is that L(A3 ) represents all traces except {b;b}, and thus reports a series of false failures, ranging from a failure in the first cycle of a successful trace, and infinite failures after three cycles or more. For these reasons the first completed failure represents much more appropriate information that should be reported by the automata. In this example L(A2 ) ⊂ L(A3 ). The transformation algorithm used to produce a failure matching automaton from a normal occurrence-matching automaton is shown in Algorithm 6.9. The algorithm

6.4 Automata Construction for Properties

129

Algorithm 6.9 Failure matching algorithm. 1: FUNCTION: F IRST FAIL(A ) //Q, δ , I, F 2: if I ∩ F = 0/ then / {q1 }, 0) / 3: create new automaton A1 = ({q1 }, 0, 4: else 5: A1 ← S TRONG D ETERMINIZE(A ) 6: add a new state q f to Q1 //q f used as the fail state 7: for each state qi ∈ Q1 − {q f } do 8: create set of primary symbols P = 0/ 9: for each edge (s, σ , d) ∈ δ1 | s = qi do 10: add σ ’s primary symbol(s) to P 11: if P = 0/ then 12: for each assignment ω of primary symbols in P do 13: if
(s, σ , d) ∈ δ1 | s = qi , (σ )ω = true then σ ← create or retrieve symbol in Σ for ω 14: 15: δ1 ← δ1 ∪ {(qi , σ , q f )} 16: else σ ← create or retrieve existing symbol in Σ for true 17: δ1 ← δ1 ∪ {(qi , σ , q f )} 18: 19: remove all edges (s j , σ j , d j ) ∈ δ1 for which d j ∈ F1 20: F1 ← {q f } 21: return A1 //|F1 | ≤ 1, as required for F IRST FAIL S TRONG()

first starts by checking for the empty match. If the argument automaton accepts the empty match (i.e. if an initial state is also a final state), then the automaton can never fail, thus the failure automaton that is returned corresponds to the null automaton (line 3). When the input automaton does not admit the empty match, the argument automaton is determinized (line 5) and a special failure state is added (line 6). In the automata used in this work, the term deterministic does not imply completeness, thus an edge does not have to exist for each symbol in each state. To be able to detect only the first failure, the resulting automaton has to have only one active state for a given activation. In order for the automaton to be in only one state, it must be (strongly) deterministic. The F IRST FAIL() algorithm works by identifying the conditions where a state does not activate a successor state. This process is repeated for each state except for the special failure state (line 7). When a state has outgoing edges, the for loop in line 12 and the if statement in line 13 add precisely the Boolean conditions where a given state does not activate a successor state. The failure conditions are incorporated onto an edge leading to the failure state, hence the failure automaton is produced. When a state has no outgoing edges, it fails for every condition therefore it directly activates the final state thru a true edge (lines 17 and 18). Line 19 performs the necessary pruning, given that former final states are no longer true final states. Consequently, former final states become unconnected and in line 13 the special final state that was added in line 6 becomes the true final state. The failure transformation algorithm is exponential (worst case) in the number of states in the argument automaton because of the required strong determinization,

130

6 Construction of PSL Assertion Checkers 1

true

2

Fig. 6.7 Automaton for A B (true) and F IRST FAIL(A B (false)). 1

Fig. 6.8 Automaton for A B (false) and F IRST FAIL(A B (true)). !b && !c

1 b && !c

2

3 !c

Fig. 6.9 Automaton for A S ({b[*0:1] ; c}). !b && !c

1 b && !c

2

3 !c

Fig. 6.10 Automaton for F IRST FAIL(A S ({b[*0:1] ; c})).

although in practice the increase in number of states is manageable. The requirement for beginning in a single state for a given activation does not preclude the automaton from being retriggered at a further clock cycle for another failure matching, or even retriggered while a previous matching is taking place. In automata, multiple succeeding activations can be processed concurrently. This allows failures to be identified in a continual and dynamic manner during execution. Figure 6.7 shows how the true automaton appears using the Boolean construction from Section 6.2. When used as a property, the failure transformation algorithm is applied to the true automaton and the null automaton in Figure 6.8 is produced. No failures can result from a matching for true, hence the null automaton results. Alternately, Figure 6.8 also shows the false automaton (null automaton), and Figure 6.7 shows the result of applying F IRST FAIL () to the null automaton. Since the null automaton does not match anything, it fails directly, hence the true automaton is produced by the failure algorithm. Example 6.3. To illustrate the effects of the F IRST FAIL() algorithm, a sequence that matches the Boolean c optionally preceded by Boolean b is analyzed. {b[*0:1] ; c} Figure 6.9 shows the normal matching automaton for the example sequence. The automaton’s final state is activated when the trace behaves as the sequence indicates. Figure 6.10 shows how the same sequence’s failures are detected, as required when the sequence is used as a property. In this case the automaton’s final state is activated when the trace does not respect the behavior dictated by the sequence.

6.4 Automata Construction for Properties

131 EOE

!b && !c EOE 2 b && !c 1

Fig. 6.11 Automaton for F IRST FAIL S TRONG(A

3 !c

S ({ b[*0:1] ; c})).

Algorithm 6.10 Strong failure matching algorithm. 1: FUNCTION: F IRST FAIL S TRONG(A ) 2: A ← F IRST FAIL(A ) //(Q, δ , I, F) 3: //here |F| ≤ 1 4: if |F| = 1 (i.e. F = { f }) then σn ← create or retrieve symbol in Σ for the EOE signal 5: 6: for each state q ∈ Q do δ ← δ ∪ {(q, σn , f )} 7: 8: return A

A P (s !) =

F IRST FAIL S TRONG(A S (s))

(6.18)

Supporting the strong sequence from Proposition 6.4 also involves constructing a failure automaton, as shown above, but with a slight modification. The F IRST FAIL S TRONG() algorithm calls the F IRST FAIL algorithm, and subsequently adds edges that cause the failure automaton to transition from any active state to the final state when the End-of-Execution (EOE) signal is active (logic-1). If the automaton is processing a sequence when the EOE occurs, an error is detected and the automaton activates a final state. When a sequence completes successfully, no states are active in the failure automaton for the corresponding activation, and the EOE signal has no effect. The semantics of the EOE signal are such that the last valid cycle of execution in the finite trace is the cycle immediately before the EOE is asserted. For example, applying the strong failure algorithm to the automaton in Figure 6.9 yields the automaton in Figure 6.11. The F IRST FAIL S TRONG() algorithm that is presented in Algorithm 6.10 first builds the failure matching automaton by calling the F IRST FAIL() algorithm (Algorithm 6.9). If the failure automaton has no final states, it is returned directly. In such cases the property can not fail, therefore the end of execution is irrelevant and there are no edges to add. If the automaton has one final state (it can have at most one, according to the F IRST FAIL() algorithm), then lines 5 to 7 add an EOE edge from each state to the final state. This way, when the EOE signal is true and a state is active, the automaton indicates a failure by activating its final state. The semantics produced by the algorithm are such that when the end of execution occurs, even if the Boolean conditions are actually satisfying the sequence, an error is signaled nonetheless. For example, in the property always a -> next! b

132

6 Construction of PSL Assertion Checkers

Algorithm 6.11 AddLiteral algorithm. 1: FUNCTION: A DD L ITERAL(A , H ) 2: σl ← create or retrieve symbol in Σ for H 3: for each edge (s, σ , d) ∈ δ do σn ← create or retrieve symbol in Σ for σ ∧ σl 4: 5: (s, σ , d) ← (s, σn , d) 6: return A 1

!b && !c && !a

b && !c && !a

2

3

!c && !a

Fig. 6.12 A DD L ITERAL(F IRST FAIL(A S ({b[*0:1] ; c}) , H (!a))).

if a occurs on the cycle before EOE is asserted, even though b may be true in the EOE cycle, it is too late and the automaton reports an assertion failure because the next cycle for a did not occur. In this case, it was not because b did not manifest itself, but rather because the execution ended before b’s cycle. A P ( f p abort b) =

A DD L ITERAL(A P ( f p), H (!b))

(6.19)

Handling the abort property also involves modifying the automaton of the property argument, as illustrated above. When the abort operator is encountered in the syntax tree, the automaton for the argument property f p is built and a new primary symbol for the negated Boolean of the abort condition is created. The algorithm A DD L ITERAL() then adds a literal (a conjunct) to each edge symbol in the property automaton. The added literal corresponds to the negation of the abort’s Boolean such that when the abort condition becomes true, all edges are inhibited from activating successor states, and the automaton is reset. Since the transformation of properties to automata is also recursive in nature, for a larger property only the portion of the automaton that the abort operator was applied to will have the added literals. Furthermore, when multiple abort operators are nested in a property, each abort will contribute its own additional literal only to the portion of the whole automaton to which it applies. The A DD L ITERAL() algorithm is presented in Algorithm 6.11. The algorithm starts by creating an extended symbol for the HDL expression of the literal to be added (line 2). Then for each edge in the input automaton (line 3), a new symbol is formed with the given edge’s symbol and the added literal’s symbol (line 4). This new symbol replaces the old one on the given edge (line 5). An example showing the effect of the abort operator in automaton form appears in Figure 6.12. Aborting the automaton in Figure 6.10 yields the automaton in Figure 6.12. In the resulting automaton, the abort condition a inhibits all edges from activating their successor states, and the automaton is reset. A P ( f p1 && f p2 ) =

C HOICE(A P ( f p1 ), A P ( f p2 ))

(6.20)

6.4 Automata Construction for Properties

133

Property conjunction, not to be confused with the length matching sequence intersection, is performed using the same algorithm that was used for sequence disjunction, namely C HOICE(). The disjunction is required because a failure by either argument property is a failure for the && property. Both argument automata are simultaneously activated by the parent node’s sub-automaton in the syntax tree, and when either one reaches a final state, a failure has been detected. The discussion on negation made earlier becomes even more relevant here, given that the implementation of property conjunction uses automata disjunction. This is reminiscent of De Morgan’s law where a complemented conjunction becomes a disjunction. This negation theme is very present in implementations of PSL for formal methods, and it should not be surprising to see it here as well. Again, because of the run-time semantics desired in the context of this work, the negation is not ideal. A P (s |-> f p) =

F USE(A S (s), A P ( f p))

(6.21)

Overlapped suffix implication is performed using a sequence matching automaton directly for the antecedent sequence, which is then fused with the automaton for the consequent property, as shown above. When used in the context of properties, the fusion algorithm is the same algorithm that was devised for sequences in the previous section. The fusion algorithm introduced in Algorithm 6.5 avoids building fusion edges containing the EOE primary symbol, such that activations (antecedents) that occur at the end of execution do not cause a failure in strong properties. This was handled by the extra condition in line 6 in the fusion algorithm. Using fusion in properties does not create unwanted side effects, considering that the empty sequence can not cause a match in the antecedent of suffix implication. The fusion in effect ignores the empty match in both sides, which creates an automata behavior that is consistent with the formal semantics of PSL [108]. As an example, when a sequence automaton’s initial state is a final state, and this sequence is used as the antecedent to overlapped suffix implication, the empty match can not cause the consequent to be checked. As was observed previously, the failure transformation algorithms can not produce automata where an initial state is also a final state (i.e. no sequence automaton, when used as a property, can accept the empty match). For these reasons, the fusion has no undesirable side effects for implementing suffix implication. Example 6.4. Fusion allows the proper processing of the following assertions: assert always {a} |-> { {b} && {b;b} }; assert always {b[*0:1]} |-> p; In the first line, the length-matching intersection results in a property automaton for the consequent that is identical to Figure 6.7 (the true automaton). The assertion thus fails whenever a is observed. In the second line, b must be asserted once in order for the consequent to be checked. Items in Proposition 6.4 not treated thus far do not need to be explicitly handled in the checker generator kernel. If such properties can be expressed using

134

6 Construction of PSL Assertion Checkers

other properties or sequences, they are rewritten when they are encountered during checker generation. In such cases, these operators are transparent to the checker generator kernel. The properties that can be handled by rewrite rules all have the form A P (x) = A P (y), and utilize a rewrite rule of the form x → y, similar to what was done for sequences. Using the sugaring definitions for properties from Appendix B in the PSL specification [108] as rewrite rules is generally not feasible because of the restrictions imposed by the simple subset. For this purpose, a set of rewrite rules is introduced that is suitable for the simple subset of PSL, within the context of dynamic verification. The rules are not intended to extend upward to full PSL. The following sugaring definition shows an example of why such definitions can generally not be used as rewrite rules: always p

def

=

¬ eventually! ¬p

def

(G p = ¬ F ¬p [108])

The above definition for always is not appropriate in the simple subset because negating a full property is not defined. Also, the argument of the eventually! operator is restricted to a sequence, and sequences can not be negated. Rewrite rules that are compatible with the simple subset are developed next for the checker generator. In some cases, the easiest way to handle an operator is by rewriting it using a more complex operator. Since the more complex operator has to be handled, particular code for the simpler cases is avoided. For example, rewriting next a using next event a may appear overly complex; however, since the next event a operator already exists and must be supported, it subsumes all simpler forms of this family of operators. The rewrite rules for properties are categorized in three groups and are treated in the following three subsections. Although a few rewrite rules may appear intuitive, they are nonetheless included for completeness. Each will be explained immediately following its appearance.

6.4.2 Rewrite Rules Based on Suffix Implication The rewrite rules in this subsection all have the common characteristic that the right side makes use of the overlapped suffix implication operator defined in properties. Unless specified, the term suffix implication is meant as a short form for overlapped suffix implication (as opposed to non-overlapped suffix implication). As was the case in sequences, proper care must be taken to ensure that the rewrite rules are terminating (Definition 4.7), and that no infinite loop is possible. b || f p

→

{!b} |-> f p

In the simple subset, one of the properties used in disjunction must be Boolean. The rewrite rule is based on the fact that if the Boolean expression is not true, then the

6.4 Automata Construction for Properties

135

property must be true; otherwise the property is automatically true. For simplicity in the presentation of the || operator in Proposition 6.4 (and in Definition 4.4), the Boolean expression is shown as the left argument; an equally acceptable disjunction could have the form f p || b. →

b -> f p

{b} |-> f p

Since a Boolean in curly brackets is a valid sequence, the property implication above can be rewritten using a suffix implication. s |=> f p

→

{s ; true} |-> f p

(6.22)

The rewrite rule for non-overlapped suffix implication above follows from its sugaring definition in Appendix B in the PSL specification [108]. The simple subset does not affect this definition, therefore it can be used directly as a rewrite rule. always f p

→

{[+]} |-> f p

(6.23)

As explained in Chapter 2, suffix implication has a sequence as the antecedent, and a property as a consequent. When a property must always be true, it can be expressed as the consequent of a suffix implication with a perpetually active antecedent ([+] is sugaring for true[+]). never s →

{[+] : s} |-> false

(6.24)

When a sequence must never occur, a property that fails instantly is triggered upon detection of the sequence. Since the sequence must never occur, it is continually activated by the fusion with [+]. The overlapped suffix implication does not have a clock cycle delay between antecedent and consequent thus the rewrites for never and always offer the correct timing. The never operator also accepts a Boolean as its argument but for simplicity was not treated. In that case, the following rewrite rule can be used to express the Boolean as a simple sequence. never b

→

never {b}

It should be noted that the treatment of never described in (6.24) does not respect the semantics defined in the PSL specification [108]. As stated in an issue to be addressed in the next revision of PSL [110], if r is a SERE, “never {r}” behaves in a counter-intuitive manner when a finite trace terminates while r is being matched. Intuitively, it is instead the strong form “never {r}!” that should be specified. The rewrite rule above has been proven to align with the strong never, and thus offers the correct semantics. The proof was conducted by Morin-Allory using the PVS theorem prover [129]. To summarize the problem, the strong never is not part of the simple subset of PSL, yet it is its semantics which are the most appropriate for the run-time behavior of the never operator. f p until b

→ {(!b)[+]} |-> f p

136

6 Construction of PSL Assertion Checkers

The until operator states that the property f p must be true on each cycle, up-to, but not including, the cycle where the Boolean b is true. In the rewrite rule above, the implication has the effect of enforcing the property f p for each cycle of consecutive !b s. In the run-time semantics used in this work for the until operator, the property is allowed to fail for multiple start times when the Boolean b is continuously false. f p until b

→

{ {(!b)[+]} | {b[->]} } |-> f p

The treatment of the overlapped operator until is similar to that of the nonoverlapped until operator with the addition of a condition for enforcing the checking of the property f p, namely that it must also hold for the cycle where the Boolean b is true. next event a(b)[k:l]( f p)

→

{b[->k:l]} |-> f p

The next event a property above states that all occurrences of the next event within the specified range must see the property be true. This can be modeled using a goto repetition with a range as an antecedent to the property. The antecedent triggers the monitoring of the property f p each time b occurs within the specified range. Once more the suffix implication operator was used as a key component in a rewrite rule.

6.4.3 Rewrite Rules Based on Sequences as Properties Some properties in Proposition 6.4 are handled by expressing their semantics using sequences. Since the property is rewritten to a sequence, the sequence takes the place of the property; the sequence is thus interpreted as a property, using the rule in (6.17) that makes use of the F IRST FAIL() algorithm. b1 before b2

→

{(!b1 &&!b2 )[*] ; (b1 &&!b2 )}

The before property above can be modeled by a sequence. When b1 should happen strictly before b2 , it can be expected that b1 will occur simultaneously with !b2 (right side of the concatenation). However, this does not need to happen immediately, therefore the condition can be preceded with an arbitrary number of cycles where both Booleans are false (left side of the concatenation). All other outcomes indicate a violation the expected behavior, and since this sequence is used as a property, the F IRST FAIL() algorithm resulting from (6.17) will detect these violations. b1 before b2

→ {(!b1 &&!b2 )[*] ; b1 }

(6.25)

The overlapped operator before states that b1 must be asserted before or simultaneously with b2 . This rewrite is very similar to the previous rewrite, with the

6.4 Automata Construction for Properties

137

exception that the constraint on b2 is relaxed on the right side of the concatenation. This indicates that when b1 is matched, b2 could have been true also, and the overlapped case is therefore allowed, as required by the property’s semantics. b1 before! b2 b1 before! b2

→ →

{(!b1 &&!b2 )[*] ; (b1 &&!b2 )}! {(!b1 &&!b2 )[*] ; b1 }!

The rewrite rules for the strong versions of the before properties are very similar to the rules for the weak versions presented previously, with the exception that strong sequences are used, thereby indicating that they must complete before the end of execution. Strong sequences are treated in (6.18). next event e(b1 )[k:l](b2 )

→

{b1 [->k:l] : b2 }

The next event e property states that the Boolean b2 should be asserted at least once in the specified range of next events of the Boolean b1 . This behavior is modeled using a goto repetition that is fused with the b2 consequent. Since the sequence is used as a property, once the b2 consequent is observed in the proper range, the sequence has completed successfully and will not indicate a failure. All other conditions will be reported as failures by the use of sequences at the property level in (6.17). next event e!(b1 )[k:l](b2 )

→

{b1 [->k:l] : b2 }!

The strong version of the next event e property is handled similar to its weak counterpart, with the exception that a strong sequence is instead used. eventually! s →

{[+] : s}!

(6.26)

Rewriting the eventually! operator is done by enforcing that the sequence s must complete before the end of execution. The sequence may start at any cycle after the eventually! property is activated, hence the fusion with [+]. For non degenerate sequences s, the semantics of the rewrite are such that if the sequence is not observed when the end of execution occurs, the property fails. For degenerate sequences s, the failure can be reported sooner than at the end of execution. If an empty or null sequence is used for s, the fusion with [+] returns a null automaton (no final state; Figure 6.3). Subsequently, when the F IRSTFAIL S TRONG() algorithm is applied in (6.18), the true automaton is returned. The true automaton was shown in Figure 6.7, and corresponds to a simple two state automaton with the Boolean true as its edge symbol. When a property corresponds to the true automaton (the true property), it fails on the cycles were it is activated. Moreover, if the true property is the top-level argument of an assert directive, the property fails on the first cycle after the reset is released. The eventually! operator also accepts a Boolean as its argument but for simplicity was not treated. In that case, the following rewrite rule can be used to express the Boolean as a sequence.

138

6 Construction of PSL Assertion Checkers

eventually! b

→

eventually! {b}

The following example illustrates the semantics of the eventually! rewrite. Example 6.5. The assertions below are used to illustrate the semantics of the rewrite for eventually!, when degenerate sequences are used. assert eventually! {[*0]}; assert eventually! {{true} && {true[*2]}}; assert always (a-> eventually! {[*0]}); assert always (a-> eventually! {{true} && {true[*2]}}); The first two assertions fail in the cycle immediately after reset is released, and the end of execution signal (EOE) does not have to be monitored. In the last two assertions above, the assertions fail in any cycle where a is true, because it is known that the degenerate sequences will never be matched (the empty sequence is not a valid match at the property level). The EOE signal is also not required in those cases. To put the above examples in context, consider the following assertion. assert always (a -> eventually! {b[*0:1]}); This assertion can only fail when the end of execution occurs, provided a has occurred at least once and that the last occurrence of a has not seen its future occurrence of b. If it is desired that all the failures for the eventually! operator be only reported at the end of execution, whether degenerate or normal sequences are used, an alternate but also valid solution can be devised using the strategy below.
P A ({[+] : s}!) s non-degenerate P (6.27) A (eventually! s) → A P (never {EOE}) otherwise The first case corresponds to the rewrite introduced previously. The second case represents a compact way of building an automaton that triggers every time the end of execution signal (EOE) is activated.

6.4.4 Rewrite Rules Based on Property Variations The rewrite rules in this subsection are based on variations of other properties. f p until! b

→

( f p until b) && ({b[->]}!)

f p until! b

→

( f p until b) && ({b[->]}!)

The strong versions of the until properties are created by using the weak versions and adding a temporal obligation for the releasing condition to occur, namely b.

6.4 Automata Construction for Properties

139

This can be modeled by the strong single-goto of the Boolean condition b. If the end of execution occurs before the releasing condition b occurs, the assertion will trigger even though the weak until may have always held. next f p next! f p

→ →

next[1]( f p) next

next event!(b)( f p) next event(b)( f p)

→ →

next event!(b)[1]( f p) next event(b)[1]( f p)

The rewrites above handle the basic next and next event operators by rewriting them to slightly more complex forms. These rules are based on the fact that when no count is specified, a count of 1 is implicit. Since the right sides of these rules are not terminal, they are subsequently rewritten using other rules, until no more rewrites apply and either sequences, Boolean expressions or base cases of properties are reached. next[i]( f p) next next a[i: j]( f p)

→ → →

next event(true)[i+1]( f p) next event!(true)[i+1]( f p) next event a(true)[i+1 : j+1]( f p)

next a next e[i: j](b)

→ →

next event a!(true)[i+1 : j+1]( f p) next event e(true)[i+1 : j+1](b)

next e

→

next event e!(true)[i+1 : j+1](b)

The family of six rewrite rules above is all based on the fact that next event is a more general case of next. The “+1” adjustment is required to handle the mapping to the Boolean true. When converting a next property to a next event property, there is a slight nuance as to what constitutes the next occurrence of a condition. The next occurrence of a Boolean expression can be in the current cycle, whereas the plain next implicitly refers to the next cycle. Another way of reasoning employs the consistency between operators. For instance, next[0]( f p) could not be modeled without the increment because next event(b)[k]( f p) requires a positive count for k. As can also be noted, the operator next[0]( f p) is equivalent to f p. next event(b)[k]( f p) next event!(b)[k]( f p)

→ →

next event a(b)[k:k]( f p) next event a!(b)[k:k]( f p)

The strategy behind the above rewrite rules is to utilize the most generic form of the next event a operator, and placing identical upper and lower bounds for the range when appropriate. next event a! (b)[k:l]( f p) → next event a(b)[k:l]( f p) && {b[->l]}!

140

6 Construction of PSL Assertion Checkers

The rewrite above handles the next event a! property. Similarly to the rewrite for the until! property, it is rewritten using the weak version, to which a necessary completion criterion is conjoined. The addition of the strong goto sequence with the l bound indicates that all l occurrences of the b event must occur before execution terminates.

6.4.5 Computer-Assisted Correctness Proofs for Rewrite Rules Automated theorem proving can provide effective help in reasoning about the formal semantics of an assertion language. An automated theorem prover can help prove many equivalencies to ensure a consistent and bug-free language. In fact, PSL has been already modeled in high-order logic theorem provers such as HOL and PVS. Mike Gordon has used the HOL theorem prover to help validate the semantics of earlier versions of PSL [85], and Katell Morin-Allory used PVS to prove the functional correctness of the monitors generated in the Horus project [23, 130, 132]. In this section, we provide a brief account of how the PVS verification system can be utilized to prove the correctness of the rewrite rules. This work is based on ongoing research performed by Morin-Allory, whose modeling of PSL in PVS is pivotal to carrying out these proofs. The account rendered here is intended as an overview of a general process by which the proofs are mechanized and carried out. To illustrate this approach, an example proof is explained in a high-level manner, using the rule for the overlapped before operator, namely before . For conciseness, we will simplify the notation wherever possible, so the full details and exact semantics are purposely not adhered to in the remainder of this section. In order for the automated reasoning about PSL rewrite rules to take place, the semantics of the language must be described in the PVS specification language. This language is based on a typed high-order logic allowing quantification over functions, as well as variables. Capturing PSL in PVS consists of specifying the syntax and type specification, as well as the semantics of the language. The syntax and semantics of PSL are given in Appendix A and B respectively in the PSL specification [108]. Once the PSL semantics is specified in PVS, conjectures are given in terms of typical operators of Boolean logic: implication, equivalence, natural numbers, existential and universal quantification, etc., and the functions defining the PSL embedding of course. Launching the proof task for a given conjecture can be done through an interactive session, where inference rules are entered by the user who guides the proof. In interactive proofs, it is important to have some insights as to what exactly is to be proved and what type of proof strategy should be employed. The full specification of PSL in PVS is not treated here and is beyond the scope of this book; however, the framework used in the proofs was developed by MorinAllory, and is very similar to that which was used for proving the functional correctness of Horus monitors [132]. The formal reasoning over the rewrite rules is

6.4 Automata Construction for Properties

141

performed for finite traces (possibly-empty), or infinite traces. All 29 rewrite rules are specified as PVS theorems using the functional embedding of PSL in PVS. The rewrite rule that is to be proved in PVS for the example is recalled below. The proof actually attempts to demonstrate the equivalence of the left and right sides of the rule. Hence, the unidirectional arrow used in the rewrite rule in (6.25) is replaced with equivalence here. b1 before

b2

⇔

{(!b1 &&!b2 )[*] ; b1 }

An important aspect to realize in the rule is that the sequence in the right side replaces the expression on the left. Since the expression on the left is a property, the sequence on the right is seen as a property. To carry out the proof, the semantics of properties, sequences and Booleans are called upon and manipulated by the theorem prover. The inference rules to apply at each step of the proof are selected by the user, who employs the tool interactively to construct the proof. PVS executes each inference step and does have a fair amount of automation, but it remains the user’s responsibility for guiding the proof strategy. For a moderately challenging rule, the proof typically only succeeds when sufficient insight into the proof strategy can be deduced by the user. The example in this section attempts to illustrate this point. An informal outline of the main parts in the proof tree that will follow appears in Figure 6.13. The numbers in parentheses refer to the nodes in the proof tree as elaborated in the derivations below. The proof tree is not complete but is meant to show the general directions taken. The initial state of the proof is the theorem being proved. We state that for all starting points of the trace, whether empty or not, and for any Booleans b1 and b2 , the equivalence holds. |——– ∀ b1 , b2 ,t0 , T :

[t0 ; T ] (b1 before

b2

⇔

{(!b1 &&!b2 )[*] ; b1 })

The formulas above the separator |——– are the antecedents in the sequent (none in this case), and the formulas below are the consequents (one in this case). The conjunction of the antecedents imply the disjunction of the consequents, and to succeed in the proof, one has to show either a contradiction in the antecedents, or that one of the consequents follows trivially from the antecedents. An empty antecedent is true by default, and an empty consequent is false by default. To simplify the notation in the text, the trace bounds on which the property is evaluated are noted in square brackets before each PSL expression. The symbol t0 is a natural number and indicates the starting point in a trace where the property is evaluated, and the symbol T represents the upper bound for finite traces, also a natural number. No trace is actually used since this is a formal proof, and only the bounds are necessary in the specification. Although only finite traces are needed in dynamic verification, for completeness the rules are also proved for infinite traces

(1.2.2): add exists b1

(1.2.1): add always !b1

Semantic expansions and instantiations with k1 (1.2): (!b2 @∀ i < k1) ∧ (b1@k1) ⇒ {(!b1&&!b2)[*] ; b1}

Fig. 6.13 Outline of the proof tree of the rewrite rule for the before operator.

(add : add to antecedent formulas)

(1.1.2): add exists b1

(1.1.1): add always !b1

(2.2): ({(!b1&&!b2)[*]} up to j1−1) ⇒ (!b2@∀i < j1)

(2.1): b1@j1 ⇒ b1@j1

(!b2@∀i < j1) ∧ (b1@j1)

Semantic expansions and instantiations with j1 (2): ({(!b1&&!b2)[*]} up to j1−1) ∧ (b1@j1) ⇒

Sequence matches strongly (2): {(!b1&&!b2)[*] ; b1} ⇒ !b2 until! b1

(2): {(!b1&&!b2)[*] ; b1} ⇒ (always !b2) || (!b2 until! b1)

(2): {(!b1&&!b2)[*] ; b1} ⇒ b1 before_b2

Sequence matches weakly (Not presented)

(1.2): !b2 until! b1 ⇒ {(!b1&&!b2)[*] ; b1}

(1.1): always !b2 ⇒ {(!b1&&!b2)[*] ; b1}

(1): (always !b2) || (!b2 until! b1) ⇒ {(!b1&&!b2)[*] ; b1}

(1): b1 before_ b2 ⇒ {(!b1&&!b2)[*] ; b1}

b1 before_ b2 ⇔ {(!b1&&!b2)[*] ; b1}

142 6 Construction of PSL Assertion Checkers

6.4 Automata Construction for Properties

143

(not shown). Thus t0 , T ∈ N and T ≥ t0 − 1, where the empty trace is modeled with T = t0 − 1. The first step in the proof is to Skolemize the universal quantifier in the consequent. Skolemizing instantiates a quantified variable with a new constant, and applies only to universal quantification in the consequent, and existential quantification in the antecedent. All four quantified variables are instantiated, namely b1 , b2 , t0 and T . New Skolem constants are indicated with a supplemental index in the variables, as shown next (after the Skolemizing). |——– [t0,1 ; T1 ] (b1,1 before

b2,1

⇔

{(!b1,1 &&!b2,1 )[*] ; b1,1 })

The next step is to break the equivalence in two implications, and the proof tree is thus split in two, for each directions of the equivalence. This corresponds to the first branching point in Figure 6.13, and thus splits the proof tree in two. The first part of the tree attempts to prove that the before expression implies the sequence on the right side of the rule. In proof notation, this is written as a sequent, which is the usual name for such statements where the antecedents yield the consequents. In proofs, the consequent is often referred to as a succedent. [t0,1 ; T1 ] b1,1 before b2,1 |——– (1) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } Expanding the formula in the antecedent with semantics of the before operator yields [t0,1 ; T1 ] !b2,1 until b1,1 |——– (1) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } If b1,1 occurs before b2,1 (overlap allowed), then b2,1 is false until b1,1 occurs. The weak until is used, thus b1,1 is not guaranteed to occur. Expanding once more the formula in the antecedent with the semantics of the weak until creates a disjunction in the antecedent formula based on the always and the strong until operators. [t0,1 ; T1 ] (always !b2,1 ) || (!b2,1 until! b1,1 ) |——– (1) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } The two semantics rules used in the previous step, as well as others that will follow, can be consulted in Appendix B in the PSL Specification [108]. In this case the weak until can be specified using the strong version combined with the fact the eventuality may never occur, hence the disjunction with b2,1 remaining always

144

6 Construction of PSL Assertion Checkers

false. Just as the equivalence’s conjunction in the consequent caused a split at the beginning of the proof, a disjunction in an antecedent formula also causes a split in the proof tree. To keep track of the tree structure, additional branch numbers are indicated next to the sequent separator |——–. The branch for the always path corresponds to branch 1.1 (left side of tree in Figure 6.13), as shown next. [t0,1 ; T1 ] always !b2,1 |——– (1.1) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } At this point in the proof, it must be shown that if b2,1 is always false on the trace [t0,1 ; T1 ], then the sequence in the consequent holds on the same trace bounds. As it happens, the consequent is over specified compared to the antecedent: there are conditions on b1,1 in the sequence, and there is no mention of b1,1 in the antecedent. If b2,1 is always false, then if b1,1 is always false before T1 the sequence will match given the Kleene repetition, else b1,1 occurs and the sequence will also match. The proof can only continue if it is split into these two sub cases. For this, the excluded middle lemma in PVS can be invoked. This lemma is based on a tautology over Booleans, as shown below. ∀A : A OR NOT A The lemma is added to the antecedent and is instantiated with the expression below. ∀i ∈ [t0,1 ; T1 ] :

[i; T1 ] !b1,1

This expression states that within the trace bounds, b1,1 is always false. Clearly, adding the expression above directly as a formula is not valid; however, adding it in the context of the tautology is quite valid as adding “true” to the antecedents is correct. In this case we are adding the fact that either b1,1 is always false, or b1,1 occurs at some point in the trace, which is a tautology. In the notation above, the first pair of brackets represent a constraint on the quantified variable, whereas the second brackets pair represents the bounds of the trace on which the Boolean is evaluated. It should be noted that since a Boolean spans one clock cycle, on the trace bounds [i; T1 ] the Boolean b1,1 only has to be true at time i. At this point the sequent appears as shown below. (∀i ∈ [t0,1 ; T1 ] : [i; T1 ] !b1,1 ) OR NOT (∀i ∈ [t0,1 ; T1 ] : [t0,1 ; T1 ] always !b2,1

[i; T1 ] !b1,1 )

|——– (1.1) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } Splitting the proof now yields another branch labeled 1.1.1, where the left side of the OR is assumed true.

6.4 Automata Construction for Properties

145

∀i ∈ [t0,1 ; T1 ] : [i; T1 ] !b1,1 [t0,1 ; T1 ] always !b2,1 |——– (1.1.1) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } The trace bounds shown in the proof reported here are summarized for simplicity – in the actual PVS proof, Skolemization introduces different constants that must be dealt with. The proof for the remainder of this branch consists of showing that if both Booleans are false throughout the trace, then the sequence holds since the Kleene repetition in the consequent’s formula will cause a proper match. The sequence is only expected to hold weakly, so the fact that b1,1 never occurs does not cause a problem for the sequence on the trace [t0,1 ; T1 ]. Completing the proof for this part is omitted, since a similar sub-proof is shown further. Backtracking to the previous split point now yields the sequent NOT ∀i ∈ [t0,1 ; T1 ] : [i; T1 ] !b1,1 [t0,1 ; T1 ] always !b2,1 |——– (1.1.2) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } This corresponds to the case where b1,1 is not always false, or equivalently, that there exists a point where b1,1 is true. Negating a forall quantifier leads to an existential quantifier, as shown next. ∃i ∈ [t0,1 ; T1 ] : [i; T1 ] b1,1 [t0,1 ; T1 ] always !b2,1 |——– (1.1.2) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } Now it must be shown that if b2,1 is always false, and b1,1 is true at some point in the trace, then the sequence in the consequent holds. Although this seems intuitive, and Skolemizing the existential quantifier can yield a point t0,2 upon which to align the b1,1 in the right side of the consequent’s sequence, there is still no guarantee from the antecedent that b1,1 remains false up to point t0,2 . Existentiality does not imply uniqueness. Another lemma is thus introduced to show that if b1,1 is true at some point, then there exists a series of cycles (possibly zero) where it is continually false up to it’s first occurrence, which may not necessarily be at point t0,2 . The lemma was developed by Morin-Allory and was proved separately in PVS. The lemma is then called upon to complete the remainder of the proof tree rooted at this node. Backtracking once more leads to the sequent [t0,1 ; T1 ] !b2,1 until! b1,1 |——– (1.2)

146

6 Construction of PSL Assertion Checkers

[t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } In this part it must be shown that if b2,1 is false until b1,1 occurs, and b1,1 eventually occurs, then the sequence holds. It can be anticipated that the eventual b1,1 in the antecedent should coincide with the b1,1 in the consequent sequence (on the right side of the concatenation). The second exclamation point in the antecedent above is part of the until and denotes the strong version of this operator (i.e. it does not indicate the negation of b1,1 ). Expanding the semantics of until! now leads to the sequent ∃k ∈ [t0,1 ; T1 ] : (([k; T1 ] b1,1 ) AND (∀ j ∈ [t0,1 ; k − 1] : |——– (1.2) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 }

[ j; T1 ] !b2,1 ))

Flattening the AND and Skolemizing the existential quantifier leads to k1 ≥ t0,1 k1 ≤ T1 [k1 ; T1 ] b1,1 ∀ j ∈ [t0,1 ; k1 − 1] :

[ j; T1 ] !b2,1

|——– (1.2) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } Because k1 ≤ T1 , the antecedent guarantees an occurrence of b1,1 in the trace [t0,1 ; T1 ]. Therefore, in the consequent sequence, the sequence can hold strongly and its b1,1 can be made to line up with the antecedent’s b1,1 . The only problem is that the antecedent does not specify that b1,1 is continually false up to the point k1 where it is asserted. Stated otherwise, the antecedent specifies only that b1,1 is true at time k1 , and that before k1 the Boolean b2,1 is false. In the sequence however, there is the requirement that b1,1 must be continually false up to the point where it becomes true. To solve this problem the tautology lemma can be used again. The lemma “A OR NOT A” is instantiated with the notion that b1,1 is continually false up to the point before k1 . This fact is either true or not true, and by adding both in a disjunction, no false statement is added to the axioms. This type of lemma has the effect of splitting the proof into sub cases that are easier to handle, just like breaking a large problem into smaller problems can ease its solution. (∀i ∈ [t0,1 ; k1 − 1] :

[i; T1 ] !b1,1 ) OR NOT (∀i ∈ [t0,1 ; k1 ] :

[i; T1 ] !b1,1 )

The expression above is added as a formula in the antecedents, and leads to the split in the proof tree. In the branch labeled 1.2.1, the left side of the OR is first explored, where b1,1 is assumed continuously false before its occurrence at time k1 . ∀i ∈ [t0,1 ; k1 − 1] :

[i; T1 ] !b1,1

6.4 Automata Construction for Properties Ant. Formula 1

147 !b1,1 !b1,1 !b1,1 !b1,1 b1,1

Ant. Formula 4 Ant. Formula 5

!b2,1 !b2,1 !b2,1 !b2,1 t 01

k1

Fig. 6.14 Example trace showing the antecedent in sequent 1.2.1, where k1 > t0,1 .

k1 ≥ t0,1 k1 ≤ T1 [k1 ; T1 ] b1,1 ∀ j ∈ [t0,1 ; k1 − 1] :

[ j; T1 ] !b2,1

|——– (1.2.1) [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } To help guide the proof, the user must have sufficient insights into the implications that the expressions have on the traces. To help visualize what is actually specified in the antecedent at this point, consider the example trace shown in Figure 6.14 where k1 > t0,1 . From this trace, it can be observed that aligning the end of the consequent’s sequence to k1 allows the antecedent to match with the consequent, and this part of the proof tree can be completed successfully. The proof can be done by expanding the semantics of weak sequences, and then expanding the semantics of concatenation. By omitting the particular details for weak sequence matching, the consequent is roughly developed as follows: ... |——– (1.2.1) ∃ j ∈ [t0,1 ; T1 ] :

[t0,1 ; j] {(!b1,1 &&!b2,1 )[*] ; b1,1 }

Weak sequence matching incorporates a form of masking where the trace is padded with extra true values ( actually [108]) to make the sequence hold strongly. The concatenation is expanded next. ... |——– (1.2.1) ∃ j ∈ [t0,1 ; T1 ] :

([t0,1 ; j − 1] {(!b1,1 &&!b2,1 )[*]}) AND ([ j; j] {b1,1 })

The existential quantifier is then instantiated with k1 . Splitting the AND yields two sub-goals, the first of which is shown next. The antecedent formulas that are irrelevant for the continuation are left hidden. ∀i ∈ [t0,1 ; k1 − 1] :

[i; T1 ] !b1,1

148

6 Construction of PSL Assertion Checkers

... ∀ j ∈ [t0,1 ; k1 − 1] :

[ j; T1 ] !b2,1

|——– (1.2.1.1) [t0,1 ; k1 − 1] {(!b1,1 &&!b2,1 )[*]} The proof task is now to show that if b1,1 and b2,1 are both separately false in the bounds [t0,1 ; k1 − 1], then the Kleene repetition of !b1,1 &&!b2,1 in the consequent also holds on the same bounds, a task that intuitively should be provable. Another lemma (also developed and proved by Morin-Allory) is invoked at this point, to transform the Kleene star sequence into a forall claim. The transformed consequent formula is directly shown next. ∀i ∈ [t0,1 ; k1 − 1] : ... ∀ j ∈ [t0,1 ; k1 − 1] : |——– (1.2.1.1) ∀i ∈ [t0,1 ; k1 − 1] :

[i; T1 ] !b1,1 [ j; T1 ] !b2,1 [i; T1 ] !b1,1 &&!b2,1

Skolemizing the consequent’s formula with the new constant i1 , and then instantiating the two antecedent formulas with i1 yields the sequent [i1 ; T1 ] !b1,1 ... [i1 ; T1 ] !b2,1 |——– (1.2.1.1) [i1 ; T1 ] !b1,1 &&!b2,1 At this point the proof can be easily completed by expanding the Boolean && operator. Backtracking to the previous split point (1.2.1) now leads to the following sequent. Only the relevant antecedent formulas for this part of the proof tree are visible. [k1 ; T1 ] b1,1 ... |——– (1.2.1.2) ∃ j ∈ [t0,1 ; T1 ] : [ j; j] {b1,1 } Here it is stated that b1,1 occurs at time k1 , which is known to be in the bounds of the existential quantifier in the consequent. By instantiating the consequent formula with k1 , the trivial sequent below appears. [k1 ; T1 ] b1,1 ...

6.4 Automata Construction for Properties

149

|——– (1.2.1.2) [k1 ; k1 ] {b1,1 } Another aspect that is not emphasized in this proof sketch concerns the constraints (equalities and inequalities) occasionally resulting from Skolemization and instantiation. One such constraint, namely k1 ≤ T1 , was present in the antecedents and can be used to show that the above sequent is true; however, other constraints are sometimes generated that also continue to split the proof tree (not shown). At this point, backtracking leads back to the first split point, where the equivalence was split in two implications. The proof sketch thus far has shown the structure of the proof in the ⇒ direction, and the left half of the proof tree in Figure 6.13 is complete. The proof in the ⇐ direction is outlined below, where from the sequence it must now be shown that the before expression is true. [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } |——– (2) [t0,1 ; T1 ] b1,1 before

b2,1

Now the before operator is in the consequent, and the sequence is in the antecedent. Expanding the definition of the before operator, as previously shown, yields: [t0,1 ; T1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } |——– (2) [t0,1 ; T1 ] (always !b2,1 ) || (!b2,1 until! b1,1 ) The consequent is a disjunction of formulas, thus the next step is flatten as opposed to split, in the PVS commands. The antecedent sequence is also expanded, as shown previously, to yield the sequent: ∃ j ∈ [t0,1 ; T1 ] : [t0,1 ; j] {(!b1,1 &&!b2,1 )[*] ; b1,1 } |——– (2) [t0,1 ; T1 ] always !b2,1 [t0,1 ; T1 ] !b2,1 until! b1,1 The semantics of weak sequences is actually more complex than the way it is reported above. In the antecedent sequence the trace may end before b1,1 is matched, which in effect masks any future obligations in the sequence. In the full proof tree there is a branch for the case where b1,1 does not occur before T1 , but it will not be shown here. In that branch, the Kleene star in the sequence makes it such that both Booleans are false in the trace [t0,1 ; T1 ], and the first formula in the consequent can be used to complete that sub-proof. In the proof tree shown in Figure 6.13, this branch is cut and is marked “Not presented”.

150

6 Construction of PSL Assertion Checkers

In the other case, the sequence is matched strongly in the trace bounds (b1,1 occurs), and Skolemizing the existential quantifier gives a precise point where b1,1 is true. The first consequent formula is not used in this sub-proof and is hidden. j1 ≥ t0,1 j1 ≤ T1 [t0,1 ; j1 ] {(!b1,1 &&!b2,1 )[*] ; b1,1 } |——– (2) [t0,1 ; T1 ] !b2,1 until! b1,1 Here it must be proved that if b1,1 occurs in the trace bounds, possibly preceded by an arbitrary number of cycles in which both Booleans are false, then b2,1 is indeed false until the occurrence of b1,1 , as specified in the consequent. Expanding both the until! operator and the sequence concatenation, and then flattening the concatenation’s resulting AND, yields the sequent j1 ≥ t0,1 j1 ≤ T1 [t0,1 ; j1 − 1] {(!b1,1 &&!b2,1 )[*]} [ j1 ; j1 ] {b1,1 } |——– (2) ∃k ∈ [t0,1 ; T1 ] :

(([k; T1 ] b1,1 ) AND (∀ j ∈ [t0,1 ; k − 1] :

[ j; T1 ] !b2,1 ))

The cycle where b1,1 occurs is now marked by the constant j1 . Instantiating the consequent formula with j1 aligns the b1,1 Booleans on both sides of the separator |——–, as shown in the next sequent. ... [t0,1 ; j1 − 1] {(!b1,1 &&!b2,1 )[*]} [ j1 ; j1 ] {b1,1 } |——– (2) ([ j1 ; T1 ] b1,1 ) AND (∀ j ∈ [t0,1 ; j1 − 1] :

[ j; T1 ] !b2,1 )

Once more the antecedent over-specifies the consequent (a desirable case), since the left side of the AND specifying that b1,1 is true at time j1 matches an antecedent formula, and the right side of the AND specifying a false b2,1 between bounds t0,1 and j1 − 1 is also part of the antecedent. Splitting the consequent formula yields two sub-goals, the first of which concerns the b1,1 at time j1 (irrelevant formulas are hidden): ... j1 ≤ T1

6.4 Automata Construction for Properties

151

[ j1 ; j1 ] {b1,1 } |——– (2.1) [ j1 ; T1 ] b1,1 This type of sequent was encountered previously and was shown to be true. The second sequent in the split point contains the right side of the AND. ... [t0,1 ; j1 − 1] {(!b1,1 &&!b2,1 )[*]} |——– (2.2) ∀ j ∈ [t0,1 ; j1 − 1] : [ j; T1 ] !b2,1 Using the Kleene star lemma, the antecedent formula can be expressed with universal quantification. ... ∀i ∈ [t0,1 ; j1 − 1] : |——– (2.2) ∀ j ∈ [t0,1 ; j1 − 1] :

[i; T1 ] !b1,1 &&!b2,1 [ j; T1 ] !b2,1

At this point it becomes apparent that the antecedent subsumes the consequent, and the proof can be easily completed. This consists of Skolemizing the consequent formula, thereby introducing a new constant j2 , and by then instantiating the new constant in the antecedent formula. Splitting the Boolean conjunction then leads to a case where a consequent formula is identical to an antecedent formula, and the proof is successful. The proof approach presented in this subsection can also be used to prove the statement given in Subsection 6.4.2 concerning the rewrite rule for never, where it was stated that because of an issue in the PSL semantics, the never operator should implicitly act upon strong sequences in the simple subset. The rule that was given in (6.24) is recalled here. never s

→

{[+] : s} |-> false

This rule creates a correct checker for the never s case; however, to prove the rule a strong sequence must instead be specified in the corresponding PVS theorem. The initial setup of the proof is the theorem stating that for all starting points of the trace, whether empty or not, and for any sequence s, the equivalence holds. |——– ∀ s,t0 , T :

[t0 ; T ] (never s!

⇔

{[+] : s} |-> false)

The equivalence above is proven for both finite and infinite traces. The proof is much smaller than the before proof and can be done using only built-in inference

152

6 Construction of PSL Assertion Checkers

rules and the Kleene star lemma shown previously; it can be completed in less than eighty user-supplied inference steps. In contrast, the proof for the before rule required over four hundred atomic user-specified inference steps. In these cases the inferences are basic steps in PVS, and can sometimes be combined further when more proof automation is desired. In both cases, running the complete proofs in PVS requires approximately four seconds in the never case, and almost forty seconds in the before case. These are wall-clock times (real-time metrics) reported by PVS, as executed on a 2.4 GHz Pentium 4, with 512 MB of RAM, running PVS 4.1. The examples just presented show the type of mechanized formal reasoning that can be performed by theorem provers, and how such techniques can help prove consistency in formal languages such as PSL. In this application, the theorem prover helps to show that the set of rewrite rules presented in this chapter is correct.

6.5 Automata Construction for Verification Directives The automaton construction for the verification directives from Definition 4.5 is presented below in Proposition 6.5. Proposition 6.5. If s is a Sequence, p is a Property and v is a verification directive, then the automaton construction for verification directives, denoted A V (v), is performed as follows: A V (v) : • A V (assert p;) = A P (p) • A V (cover s;) = A V (assert eventually! s;) The assert directive is handled by directly returning the automaton created for its argument property. The property identifies all faulty traces, and nothing more needs to be done for supporting the assert directive. cover s

→

assert eventually! s

The cover directive provides a way to ensure that a given sequence has eventually manifested itself during the verification. It is therefore natural to rewrite the directive using the eventually! property. Although the default clock declaration is not a PSL directive as such, clock declarations and verification directives are the items that are used in verification units (vunit) in the PSL presented in this work. Verification items and default clock declarations are the minimum statements that must be specified by the user to get the verification process up-and-running. An example vunit is shown in Appendix A. To conclude the chapter, a summary example is presented to show the multiple steps required to build an automaton for an assertion.

6.5 Automata Construction for Verification Directives

153

Example 6.6. The following assertion states that whenever !a is followed by a, then in the cycle where a was true the sequence {b[*0:1];c} must occur. This sequence states that c must occur, possibly preceded by b. For simplicity the example assertion uses simple Booleans; however, complex Boolean expressions over real circuit signals can also be used. assert always {!a ; a} |-> {b[*0:1] ; c}; In dynamic verification, the assertion output will trigger in every cycle where a noncompliance to the assertion is observed in the input signals. Figure 6.15 shows six steps for creating the automaton for the assertion above. Each part of the figure is explained below.

a) Terminal Booleans 1

!a

a

1

2

b

1

2

c

1

2

2

b) Sequences (antecedent and consequent) 1

!a

a

2

3

b

1

c) Consequent sequence used as property 1

!a

a

2

2

c

3

!b && !c

3

3

1 b && !c

2

!c

d) Suffix implication a && !b && !c 1

!a

2

a && b && !c

4 3

!c

e) Before suffix implication in “always” rewrite true 1

a && !b && !c

true

!a

1

2

2

a && b && !c

4 3

!c

f) Final result true 1

!a

a && !b && !c 2 a && b && !c

4 3

!c

Fig. 6.15 Complete automaton construction for example assertion: assert always {!a ; a} |-> {b[*0:1] ; c};. Steps a–f show the bottom-up construction starting with terminal Booleans and ending with the resulting automaton.

154

6 Construction of PSL Assertion Checkers

(a) The terminal Boolean automata are built for the Booleans used in the assertion according to the BASE C ASE() algorithm in Algorithm 6.1. (b) The repetition range and concatenation algorithms are used with the Boolean automata in part a) to construct the automata for the two sequences used in the suffix implication. Since these sequences are top-level sequences, minimization was applied. (c) The right side sequence is used as a property therefore the first failure must instead be matched. This transformation is provided by the F IRST FAIL() algorithm according to (6.17). (d) The suffix implication in the assertion is performed using the F USE algorithm, as shown in (6.21). (e) The always operator is rewritten according to (6.23), and becomes a suffix implication using the sequence {[+]} as the left side, and the property that is the argument of always as the right side. The automaton for {[+]} is shown in the left side of part e, and requires a few steps to build (not shown). The suffix implication that is part of the always rewrite is performed with a fusion operation. (f) The fusion mentioned at the end of part e is performed, and after minimization the final resulting automaton for the example assertion is produced. Converting the automaton to RTL can subsequently be performed as explained in Section 5.3. The checker is then ready to be used for in-circuit assertion monitoring.

Chapter 7

Enhanced Features and Uses of PSL Checkers

Abstract This chapter presents enhanced features and uses of checker generators. It first explains the use of alternative compilation techniques for special cases. The main part of this chapter deals with additions to checkers for coverage and introduces a number of debug enhancements. The debug enhancements provide means to pinpoint the failure cause by observing the checker logic, as well as to decouple the effects of multiple, say pipelined, streams of computation in the process of debugging. Finally, the means to pack a near-optimal amount of assertion checkers for on-line monitoring and post-fabrication debug are presented.

7.1 Introduction and Overview The topics contained in Chapters 5 and 6 show how a circuit-level checker can be generated from a PSL assertion for use in the ABV paradigm. In this chapter, a set of enhancements to assertion checkers is introduced. The first enhancement is a more resource-efficient implementation of the eventually! operator, and is presented in Section 7.3. Section 7.4 introduces a multitude of debug enhancements for checkers, which all share a common goal of improving the debugging process through improved observability in the checkers. Finding a failure is only the first step in the bug fixing process, and the exact cause of the failure must be determined before performing subsequent design changes. Specifically, Section 7.4 proposes a set of additions and modifications to the checkers to help identify the causes of errors more easily and to help decrease the time spent debugging a circuit. Assertions themselves are only a “foot in the door” for the debugging process, as engineers still need to invest time to explore the reasons why an assertion failed. Assertions help to find the existence of errors, and with more sophisticated techniques, assertions should also help to identify the true causes of the errors, since the implicit goal is often to fix any errors that are found. For example, knowing that a bus grant was not given in the proper 155

156

7 Enhanced Features and Uses of PSL Checkers

time frame by an arbiter doesn’t directly reveal the actual functional reason for that error. In order for some of these checker enhancements to be possible, a modified recursive compilation strategy must be introduced. This is done in the next section, where the necessary modifications to perform automata splitting (or modularizing) are introduced. Automata splitting is a technique whereby a subset of an automaton is kept isolated from the remainder of an assertion’s automaton. In order for the isolated automaton to be properly triggered, it is given a precondition automaton during compilation, which represents its activations. The use of precondition automata is a prerequisite for automata splitting. Automata splitting is required for the assertion threading and the activity monitoring enhancements, and also for the more efficient form of eventually!. The efficient eventually! implementation described in this chapter is used by default in the checker generator, as opposed to the rewrite rule developed in the previous chapter. The checker generator also has an option to force the use of a single automaton to represent an assertion’s checker. In such cases, the efficient form of eventually! is not used, and the rewrite is applied. Automata threading and activity monitors are also overridden when a single automaton checker is desired. The use of assertion checkers beyond verification purposes is explored in Section 7.5. There, it is shown that assertion checkers also play an important role in post-fabrication silicon debug and on-line monitoring, and that using assertions and a checker generator can even be used for performing certain types of circuit design. Although these themes are not fully checker enhancements as such, they can nonetheless be considered as enhanced applications of checkers.

7.2 Recursive Compilation Strategies The automaton construction for PSL properties in Section 6.4 was presented in functional form, where functions are called with automata as arguments, and the functions each return an automaton. The functional form also applies to the base cases in Subsection 6.4.1, whereas the rewrite rules revert to the bases cases after one or more applications. Functions such as C HOICE(), F USE(), A DD L ITERAL() were used to implement property operators when rewrite rules were not used. This compilation strategy yields the simplest and most direct architecture in the checker generator. However, for many of the enhancements presented in this chapter, this recursive strategy is not appropriate. In certain cases, a node in the recursive compilation may require that its subautomaton be instantiated as a module, and not be merged with it’s parent’s automaton. The most evocative example of this is when monitoring sequence activity is to be performed. In order for a sequence’s activity to be monitored properly, its automaton must retain its structural integrity, and it must not be merged with other automata. In these cases, the parent node has to supply the child with a precondition automaton, such that if the child node decides that its automaton needs to be a

7.2 Recursive Compilation Strategies a)

157 b)

assert

assert void

A4 always

A1'

A3 -> A1 a

A3'

always

A2 {b[*0:2];c}

A1' a

A3' -> A2' A2'

A3' {b[*0:2];c}

Fig. 7.1 Example of recursive compilation strategies: (a) without precondition automata, (b) with precondition automata.

module, the child has everything at its disposal to instantiate its activation automaton. This recursive compilation strategy is also required for implementing the more efficient form of eventually! in Section 7.3, as well as the activity monitors and assertion threading in Subsections 7.4.2 and 7.4.5. The following assertion is used as a running example to illustrate the two recursive compilation strategies. assert always a -> {b[*0:2];c};

(7.1)

When the assertion is compiled using the algorithms presented in the previous chapter, the compilation graph shown in Figure 7.1a applies. This graph is not explicitly stored in memory; it only represents the recursive function calls that are made, as dictated by the syntax structure of the assertion (syntax tree). The compilation strategy is characterized by the fact that a parent sends no information to its children, which are responsible for building an automaton for their sub-properties, and nothing more. The children are not aware of the upper level context and it is the parent that is responsible for building its own property automaton. This strategy is said to be without precondition automata. In the recursive strategy with precondition automata, as shown in Figure 7.1b, a parent node must send each child an automaton representing the child’s activations. If the child does not require its sub-property automaton to be isolated, this automaton is built and the precondition automaton is fused with it (by the child) so that it may be activated properly. Preconditions may be void, in which case the fusion is not required. A void precondition can only be produced by the assert operator, and is equivalent to indicating that the child property must only hold starting in the first cycle of execution. Analyzing more deeply the example without precondition automata in Figure 7.1a, it can be observed that the terminal property elements are the antecedent Boolean and the consequent sequence for the implication. Each of these elements is assembled in an automaton form using the techniques for Booleans and sequences from the previous chapter. The A1 and A2 automata are built as follows: A1 = A B (a)

158

7 Enhanced Features and Uses of PSL Checkers

A2 = A S ({b[*0:2];c}) These automata are returned to the implication node, where the resulting automaton for the implication is built. Using the techniques from the previous chapter, it follows that: A3 = F USE(A1 , F IRST FAIL(A2 )) This automaton is returned to the always node, where it is perpetually activated as a result of the always rewrite: A4 = F USE(A S ({[+]}), A3 ) The resulting automaton is A4 , and is left intact by the assert operator. The same automaton can also be built using the precondition-automata strategy. In Figure 7.1b, the automata indices are not related to those in Figure 7.1a, and are analyzed in detail next. The assert operator implicitly represents an activation for the first cycle only, and does not require a precondition automaton for its child property (hence the void automaton). The always node prepares its precondition automaton as follows, to indicate that its child should be perpetually checked: A1 = A S ({[+]}) Once received by the implication node (->), the precondition automaton A1 is redirected to the antecedent node a. The result automaton from the antecedent child is formed as follows: A2 = F USE(A1 , A B (a)) The result automaton A2 is returned to the implication node, where it is redirected to the other child to serve as its precondition automaton. The right-side child in the syntax tree builds the sequence automaton A3 as follows: A3 = F USE(A2 , F IRST FAIL(A S ({b[*0:2];c}))) An important subtlety is that the child sequence has to be made aware that it is being used as a property, and that its failure matching must be performed. In the approach without precondition automata, the F IRST FAIL() was not performed by the child, but rather by the parent (i.e. the implication). Getting back to the example in Figure 7.1b, now that the consequent node’s automaton is ready, it is returned back to the implication node, that directly returns it to the always node. In this strategy, the child has done the implication’s fusion, and nothing else needs to be done at the -> node. The always node also does not have to do anything, since its continual activation was modeled in the precondition automaton that was sent to its child. Thus A3 is returned as the resulting automaton. Substituting A1 and A2 into A3 , and then substituting the result into A4 yields the following computation for the assertion’s automaton (without using precondition automata):

7.2 Recursive Compilation Strategies

F USE(A S ({[+]}), F USE(A B (a), F IRST FAIL(A S ({b[*0:2];c}))))

159

(7.2)

Performing the same type of substitutions for A3 yields for the precondition automata strategy the following expression : F USE(F USE(A S ({[+]}), A B (a)), F IRST FAIL(A S ({b[*0:2];c}))) Because the fusion operator is associative, the expression above is functionally equivalent to the expression in (7.2). This shows that both recursive compilation strategies are equivalent in this example. Although both strategies have the same effect, the method using precondition automata is more flexible and allows automata to be modularized, as required by some of the enhancements introduced in this chapter. Precondition automata are used only at the property level, and SEREs and Booleans are compiled as implied by the functional notation in the previous chapter. Only a few other property operators from Proposition 6.4 require special treatment for the precondition automaton strategy. For unary operators, a child node incorporates the precondition automaton to its own automaton using automata fusion. The precondition in effect represents the activations of the child node’s expression. In the fusion, the precondition automaton is the left argument, and the right argument is the automaton for the sub-property rooted at the child node. For the binary operators corresponding to overlapped suffix implication and property implication, the strategy consists of: 1. Sending a precondition automaton to the antecedent 2. Using the result automaton from the antecedent as the precondition automaton for the consequent 3. Using the result automaton from the consequent as the result automaton for the implication itself In the compilation strategy with precondition automata, the parent actually tells a child node whether or not it is in normal matching mode (ex: antecedent) or in failure mode (ex: consequent). This nuance was observed when comparing both strategies in the example for the assertion in (7.1), where the F IRST FAIL() for the consequent sequence is applied by the implication node when preconditions are not used, and the F IRST FAIL() is applied in the consequent sequence node when preconditions are used. For the property conjunction operator &&, the node sends its precondition automaton simultaneously to both arguments, and applies the C HOICE() algorithm to the automata returned by its children nodes. The abort operator still uses the A DD L ITERAL() algorithm to reset a sub-automaton, except that the abort is applied by the children nodes before the fusion with the precondition automaton. The abort’s Boolean must be kept in a global string, where nested aborts are added as disjunctions to the global abort string. The abort string starts out as the null string, and grows/shrinks as the recursive traversal in the syntax tree progresses.

160

7 Enhanced Features and Uses of PSL Checkers

To summarize, the essential points of the two recursive compilation strategies are stated below. In both cases, the compilation of a PSL property involves recursively scanning the syntax tree of the PSL expression. 1. Without precondition automata: Each node returns an automaton describing the behavior of the expression rooted at that node. The parent node then builds its own automaton from its children automaton(s), using a variety of transformations and operations. 2. With precondition automata: Each node sends a precondition in automaton form to a child, whereby the child node is responsible for building the sub-automaton (with its activations) and returning it to the parent. If other child nodes exist, the parent forms other precondition automata, possibly using the automata returned by previous child nodes. When finished, the parent returns an automaton formed from the children automata (directly or with modifications) to its parent. The first recursive strategy is implied by the functional form used in the previous chapter, and was initially used in the checker generator. When the debug enhancements were added, the precondition method was implemented, and is currently the technique used in the checker generator. The precondition/result framework has its roots in the first version of the checker generator [29], which implemented properties and sequences modularly using precondition and result signals.

7.3 A Special Case for eventually! In the previous chapter it was stated that rewriting the eventually! operator can be performed with the rewrite rule in (6.27), recalled below:
P A ({[+] : s}!) s non-degenerate P (7.3) A (eventually! s) → A P (never {EOE}) otherwise This strategy has the advantage of preserving the full automaton approach; however, given that the sequence in the right-hand side of the non-degenerate case is used as a property, the F IRST FAIL S TRONG() algorithm has to be applied to the sequence. That algorithm requires a proper determinization, and thus does not represent the most efficient solution. This section details the use of a more efficient procedure for implementing the eventually! property, in cases where automata splitting is allowed and the use of separate logic and wire declarations are permitted. An efficient implementation of eventually! is also important for the cover directive which is rewritten to the eventually! operator in dynamic verification. Although automata optimizations can no longer cross the boundaries of split automata, the improvements brought upon by the split approach outweigh this disadvantage. In the split automata approach, implementing the “eventually! s” property is done with a normal occurrence-matching automaton. After the automaton for the sequence s is built, its initial states are made non-final. At this point, if the sequence automaton has no final states, the sequence can not eventually occur, and

7.3 A Special Case for eventually!

161

the failure must be signaled at the end of execution. In this case the automaton corresponding to A P (never {EOE}) is returned to the parent node in the syntax tree of the assertion, similarly to the degenerate case of the rewrite rule in (7.3). If the sequence automaton is not degenerate, then a more complex algorithm is applied. First, the automaton is weakly determinized such that it has only one initial state. Then, any incoming edges to the initial state are removed, and outgoing edges from the final states are removed. Incoming edges to the initial state are redundant since the state will remain active until the sequence is matched. Outgoing edges of the final states can be safely removed since the first match of the sequence is sufficient to satisfy the eventually!. The automaton must be implemented as a module, for which a result signal is declared. This result signal is then used in complemented form, as the symbol on a self-loop in the initial state. This has the effect of keeping the initial state active until at least one occurrence of the sequence has manifested itself. The actual result signal of the eventually! operator corresponds to the output of the initial state’s flip-flop. In this manner, no extra states (hence flip-flops) are used. The actual result signal is implemented in automaton form before being returned to eventually!’s parent node. This consists of preparing a two-state automaton where the second state is a final state, the initial state has a true self-loop, and an edge from the initial state to the second state carries a symbol corresponding to the result signal. When a precondition automaton is passed to the eventually! node in the recursive compilation, the precondition automaton is implemented as a module, for which a result signal is declared. This signal constitutes the precondition signal for the eventually! automaton. Each time the precondition is asserted, the occurrence matching automaton for eventually! is flushed, with the start and final state’s edges modified as described previously. Automaton flushing consists of deactivating the edges for all states except the initial state. This is accomplished by AND-ing a negated literal of the precondition signal to each outgoing edge symbol of each non-initial state. In this manner, each new precondition guarantees a new complete obligation. The precondition automaton used in this technique implies that the recursive mechanism with precondition automata must be used. Example 7.1. Figure 7.2 shows an example of the efficient eventually! strategy for the following property: always (a -> eventually! {b;c;d}) The property is actually implemented as two automata, and the automaton at the top right in the figure is returned by the always node in the compilation tree. Since the always property is the argument of the assert directive, the returned automaton is directly implemented in RTL. The grey state also serves as the memory state, which is deactivated once the obligation is fulfilled (once the sequence occurred). Automaton flushing is also visible with the added “!s2” literals. If the always property was part of a more complex assertion, the returned automaton would be

162

7 Enhanced Features and Uses of PSL Checkers

true

Precondition automaton “always a ->"

a

Sequence argument automaton “{b;c;d}"

true s2 && b

!s1 b 1

s3q && EOE Returned automaton

wire s2;

s2 && !s1

true

d && !s2

c && !s2 2

reg s3q;

3

4

wire s1;

Fig. 7.2 Efficient implementation of the eventually! assertion in Example 7.1.

used by the parent property to continue to build the complete automaton for the assertion. Automata splitting and the addition of separate logic gates could also be used for performing efficient automata negation by avoiding the determinization step. In hardware, an NFA could be easily negated by adding a not gate to the output signal of the NFA; however, because the not-gate is not part of the automaton formalism, further automaton operations such as concatenation would be undefined.

7.4 Debug Enhancements for Checkers In their default form, assertion checkers provide feedback on violations through the assertion signal (result signal). In this section, different enhancements to checkers are explored, all of which share the goal of improving the debugging process. The debug enhancements introduced for assertion checkers are: 1. 2. 3. 4. 5.

Reporting signal dependencies Monitoring activity Signaling assertion completion Assertion and cover counters Hardware assertion threading

The different techniques range from source-code comments (1) to actual modifications in the response of the checkers (3). Other enhancements constitute hardware additions and thus preserve the behavior of the checker outputs (2, 4 and 5). The overall goal is to increase the observability in the assertion monitoring in order to better assess the causes of a failure, or the causes of suspicious inactivity in a checker.

7.4 Debug Enhancements for Checkers

163

7.4.1 Reporting Signal Dependencies When debugging failed assertions, it is useful to quickly determine which signals and parameters can influence the assertion output. In the generated checkers’ HDL code, all of the signal and parameter dependencies are listed in comments before each assertion circuit. When an assertion fails, the signals that are referenced in an assertion can be automatically added to a wave window and/or extracted from an emulator, in order to provide the necessary visibility for debugging. Dependencies are particularly helpful when complex assertions fail, especially when an assertion references other user-declared sequences and/or properties, as allowed in PSL [108]. In such cases, assertion signal dependencies help to narrow down the causes of an error. Signal dependencies can also help to determine which signals must be stimulated in order to properly exercise an assertion that is found to be trivially true.

7.4.2 Monitoring Activity The Booleans and sequences appearing in assertions can be monitored for activity to provide added feedback on the matching process. Monitoring the activity of a sequence is a quick way of knowing whether the input stimulus is actually exercising a portion of an assertion. The monitoring is performed on the states of the automata that represent the sequences and Booleans. Activity is defined as a disjunction of all states in an automaton. Anytime a state is active, the automaton is considered to be active. A sequence’s automaton can exhibit internal activity when undergoing a matching, even if its output does not trigger. Conversely, if a sequence output triggers, the automaton representing it is guaranteed to show internal activity. Using the appropriate compilation option, the checker generator declares activity signals for each sequence sub-circuit. The only states that are excluded from consideration for activity monitors are: initial states that have a true self-loop, and the final state when a sequence is the antecedent of the |=> operator. The reason for these exceptions is that any initial state with a true self-loop does not represent meaningful activity. Furthermore, when a sequence appears as the antecedent of a non-overlapped suffix implication, it is rewritten to an overlapped implication by concatenating an extra {true} sequence element to the end of the sequence, as shown in Subsection 6.4.2. This added sequence element creates a single final state in the antecedent, which also does not represent meaningful activity. Under normal conditions, each assertion is represented by a single automaton before its transformation to RTL. To implement activity monitors, it is necessary to isolate the automaton of a sequence so that it is not merged with the remainder of the assertion’s automaton during minimization. The automata that are isolated correspond to the sub-expressions that are being monitored, which in turn correspond to top-level sequences or Boolean expressions appearing in properties. Example 7.2. The following assertion is used to illustrate activity monitors.

164

7 Enhanced Features and Uses of PSL Checkers

a) Without activity monitors 0

true a

b

1

!c && !d 4

2

!d c && !d b) With activity monitors always true s1 0

{a;b}

s2

0

1

a && s1

2

true

out_ mbac

{c[*0:1];d} true

|=>

true b

D

3

!c && !d && s2 2

0

3

c && !d && s2

!d 1

cseq_ act. aseq_act.

c) Testbench waveform

Fig. 7.3 Activity signals for assertion: assert always ({a;b} |=> {c[*0:1];d});. The label aseq corresponds to the antecedent sequence, and cseq to the consequent sequence.

assert always ({a;b} |=> {c[*0:1];d}); Figure 7.3a shows how the example assertion normally appears as a single automaton when activity monitors are not desired. In Figure 7.3b activity monitors are produced, whereby the antecedent and consequent sequences must be kept isolated. The shaded OR-gates implement the disjunction of the state signals used to form the activity signals. The two types of exceptions that were stated previously apply in this example, namely that state 3 is not used in the antecedent’s activity and state 0 is not used in the consequent’s activity. It should also be stated that contrary to other signals that connect to the output of a state, the out mbac signal connects to the input of the flip-flop contained in the state, as was also shown in the example in Figure 5.9. An example of activity traces is visible in Figure 7.3c for the example assertion. The activity signals for both sequences are visible, along with the assertion signal (out mbac), and the assertion as interpreted by the ModelSim tool (gold1). As can be observed, the union of both activity signals coincides with ModelSim’s activity indication. Since the checker’s assertion signal is registered by default (not shown), it is asserted on the clock cycle following ModelSim’s failure marker. Monitoring the activity of a Boolean does not revert to monitoring the Boolean itself. In the following property always a -> next b activity on b is conditional to an activation from the antecedent a occurring in the previous clock cycle.

7.4 Debug Enhancements for Checkers

165

Monitoring activity signals eases debugging by improving visibility in assertioncircuit processing. An implication in which the antecedent is never matched is said to pass vacuously (Definition 3.5). When monitoring antecedent activity, a permanently inactive antecedent does indeed indicate vacuity; however, this seldom occurs given that a single Boolean condition is enough to activate a state within the antecedent’s automaton. An example to illustrate this is shown in Figure 7.3b, where state 1 in the antecedent automaton is active every time a is true. In order for activity monitors to be the most effective for vacuity detection, the consequent needs to instead be monitored because an inactive consequent means that the antecedent was never fully detected, and thus never triggered the consequent. If no activity was ever detected in the consequent of a temporal implication, this indicates that the implication is vacuously true. The fact that the antecedent never fully occurred does not mean that there was no activity within it; conversely, activity in the antecedent does not mean that it fully occurred. Activity monitors does not apply to sequences resulting from the application of rewrite rules. The rewrite rules are not implemented in true pre-processor fashion using syntactic replacement, and are implemented in the checker generator’s internal functions. The checker generator actually creates new sub-trees in the syntax tree, corresponding to the rewritten expressions. The tool is therefore able to distinguish user-defined sequences from those resulting from rewrite rules.

7.4.3 Signaling Assertion Completion For a verification scenario to be meaningful, the assertions must be exercised reasonably often. Assertions that do not trigger because the test vectors did not fully exercise them are not very useful for verification or debug. In cases where the assertions are trivially true, the true cause of a non-failure could be overlooked. On the contrary, assertions that are extensively exercised but never trigger offer more assurance that the design is operating as specified. In the checker generator, assertions can be alternatively generated in completion mode to indicate when assertions complete successfully. This alternate assertion behavior can be very useful when assertion coverage is to be monitored, and to determine when assertions are not trivially true; these two factors are important for creating effective test scenarios and testbenches. In general, by signaling successful witnesses, completion mode assertions provides an indication that if an assertion never failed, it was not because of a lack of proper stimulus. Borrowing existing terminology [10], the completion mode identifies interesting witnesses to the success of a property. Vacuity, defined as antecedent non-occurrence in Definition 3.5, is only one possible cause for trivial validity. Completion mode can also be referred to as pass checking, success checking and property coverage. Implementing completion mode requires the development of a first-match transformation algorithm. Creating an automaton that reports the first match, and only the first match of a sequence or a Boolean, for a given activation, requires strong

166

7 Enhanced Features and Uses of PSL Checkers

Algorithm 7.1 First-match transformation algorithm. 1: FUNCTION: F IRST M ATCH(A ) 2: A ← S TRONG D ETERMINIZE(A ) 3: remove all edges (s j , σ j , d j ) ∈ δ for which s j ∈ F 4: return A

determinization. Algorithm 7.1 shows the transformation algorithm used to produce a first-match automaton from a normal matching automaton. The completion mode transformation algorithm first determinizes the automaton such that each activation is represented by only one active state (line 2). From any given state, a deterministic automaton transitions into at most one successor state. The strong determinization algorithm from Algorithm 5.2 must be used, as opposed to the weak determinization algorithm. The determinization step is required so that when the first completion is identified, no other subsequent completions will be reported for the same activation. The second step in the algorithm removes all outgoing edges of the final states, when applicable (line 3). Any unconnected states resulting from this step are removed during minimization. The completion mode affects assertions that place obligations on certain subexpressions, such as in the consequent of temporal implications for example. In temporal implications, for each observed antecedent, the consequent must occur or else the assertion fails. As opposed to indicating the first failure in each consequent, as is usually done, the completion mode assertion indicates the first success in the consequent. The completion mode produces no meaningful checkers for assertions such as assert never s; given that no obligations are placed on any Boolean expressions. This assertion states that the sequence argument s should not be matched in any cycle. Normally, every time the sequence is matched a violation occurs and the assertion output triggers. In completion mode, the null checker is produced, and consists of a signal that is constantly false. The completion mode checker thus never triggers, because there is nothing to complete. The assertion contains only proscribed behavior, and contains no prescribed behavior. In other words, the assertion can only fail, else it continues matching for an infinite amount of clock cycles and thus never completes in any finite execution. The actual elements of PSL that are affected by the completion mode are sequences and Boolean expressions when used directly as properties. More specifically, the completion mode is implemented by using the F IRST M ATCH() algorithm in place of the F IRST FAIL() and F IRST FAIL S TRONG() algorithms appearing throughout Proposition 6.4 (properties). Strong sequences are treated as weak sequences in completion mode because the assertion signal, which now indicates successful completions, should not simultaneously be used to also indicate failures to comply with a strong operator. Implementing a completion mode with strong operators could be done using two separate output signals for assertion checkers,

7.4 Debug Enhancements for Checkers a) 1

true a

167

c && !d && !e

Failure

!d

3

2

4

!c && !d && !e b) 1

true a

c && !d && !e

Completion

d

3

d

2

e

4

Fig. 7.4 (a) Failure and (b) completion mode automata for the assertion in Example 7.3.

one indicating successful completions, and the other indicating failures of strong obligations at the end of execution. Example 7.3. The following assertion is used to illustrate failure and completion mode automata: assert always ({a} |=> {{c[*0:1];d}|{e}}); The assertion is normally compiled as the automaton shown in Figure 7.4a, whereby the output signal (or final state) triggers each time the assertion fails. The completion mode automaton for this example is shown in Figure 7.4b. When creating a completion mode checker, the automaton for the consequent of the implication is modified to detect the completion of the sequence, according to Algorithm 7.1. For a given activation (in this case a), only the first completion is identified by the automaton. The sequence of events a;c;d, makes the completion automaton trigger; however, the failure automaton does not reach a final state given that the sequence conforms to the specification indicated by the assertion. The completion mode can be used with assertion counters to provide more detailed metrics in a test scenario.

7.4.4 Assertion and Cover Counters The checker generator also includes options to automatically create counters on assert and cover statements for counting activity. Counting assertion failures is straightforward, as observed in the top half of Figure 7.5; however, counting the cover directive requires some modifications. In dynamic verification, cover is a strong property that triggers only at the end of execution. In order to count occurrences for coverage metrics, a plain matching (detection) automaton is built for the sequence argument, and a counter is used to count the number of times the sequence is matched. The cover’s result signal only triggers at the end of execution if the counter is at zero, as shown in the lower half of Figure 7.5. If no counters are desired, a one-bit counter is implicitly used. The counters are width parameterized,

168

7 Enhanced Features and Uses of PSL Checkers a)

Assertion signal

assert {~req;req} |-> {[*0:15];gnt}; 0000 0012

b)

cover {req;reset;req};

Assertion count

End-Of-Execution pulse Cover signal =0?

0000 1392

Cover count

Fig. 7.5 Counter circuits for: (a) assertions and (b) covers.

and by threshold arithmetic do not roll-over when the maximal count is reached. The counters are also initialized by a reset of the assertion checker circuit. Counters can be used with the completion mode from Subsection 7.4.3 to construct more detailed coverage metrics for a given test scenario. Knowing how many times an assertion completed successfully can be just as useful as knowing how many times an assertion failed. For example, if a predetermined number of a certain type of bus transaction is initiated, the related assertion should complete successfully the same number of times.

7.4.5 Hardware Assertion Threading Assertion threading is a technique by which multiple copies of a sequence checking circuit are instantiated. Each copy (or thread) is alternately activated one after the other, as the sequence receives activations. This allows a violation’s condition to be separated from the other concurrent activity in the assertion circuit, in order to help visualize the exact start condition that caused a failure. In general, using a single automaton mixes all the temporal checks in the automaton during processing. The advantage with this is that a single automaton can catch all failures; however the disadvantage is that it becomes more difficult to correlate a given failure with its input conditions. The assertion threading in effect separates the concurrent activity to help identify the cause of events leading to an assertion failure. Threading applies to PSL sequences, which are the typical means for specifying complex temporal chains of events. By extension, threading applies to any PSL property in which one or more sequences appear. The threading of Booleans used as properties is not performed given the temporal simplicity of Booleans. The following property is used as a running example to illustrate the mechanisms behind assertion threading: always a -> {b[*0:2];c}

(7.4)

In this property the consequent sequence can last at most three clock cycles, and thus three threads will be used. For very long sequences, or even unbounded sequences

7.4 Debug Enhancements for Checkers

169

Precondition automaton

true

true

“always a ->"

a

Returned automaton

wire s1;

s1

wire s2; s2 D s2 ce

pc[0]

s2 D s2 ce

pc[1]

pc[2]

0

b && !c

:

:

4

2

3

!b && !c

!c 4

b && !c b && !c

:

!c

!b && !c

1

1

3

!b && !c

b && !c b && !c

true pc[2]

2 !b && !c

1

true pc[1]

1

s2 D s2 ce

pc[0]

0

b && !c

true

2

3

!b && !c

!b && !c

!c 4

Fig. 7.6 Assertion threading strategy. Ex: always a -> {b[*0:2];c}.

that use the [*] operator (Kleene star), a larger but finite number of threads can be instantiated. When the number of threads is smaller than the maximum length of the sequence, it may not always be possible to completely separate the activity into different threads. If a thread is undertaking a matching and it receives another activation, identifying the precise cause of a failure becomes more difficult. When the resources allow it, increasing the number of hardware threads can help to properly isolate a sequence. In all cases, it is important to state that no matches can ever be missed, as a single automaton can concurrently handle all activations. The assertion in (7.4) is threaded as shown in Figure 7.6. Although a property implication with a simple Boolean antecedent is used in this example, the sequence could also have been activated by more complex properties, such as a sequence antecedent when suffix implication is used, or complex Boolean events when the next event a property is used, for example. The first step in threading is to separate the sequence automaton from its precondition automaton. In this case the precondition automaton is a simple two state automaton with an edge for the Boolean a. Since a is under the scope of the always operator, it is continually triggered, hence the self-loop with true in the initial state. The second step in threading is to build the dispatcher, shown in the left side of the figure. The hardware dispatcher redirects the activations coming from the precondition to the multiple sequence-checking units in a round-robin manner. The dispatcher flip-flops form a one-hot encoded register such that each activation is sent to only one of the hardware threads. Each signal from the dispatcher (pc[0] to pc[2]) activates its own copy of the sequence by using automata fusion, denoted “:” in Figure 7.6. The fusion is the same algorithm that was devised for SEREs in the previous chapter. The effect of the fusion with the small pc[x] automata

170

7 Enhanced Features and Uses of PSL Checkers

is that each time a precondition signal is true, it will trigger the matching in the sequence automaton for the corresponding thread. The sequence automaton on the right side of fusion corresponds to the sequence that is to be threaded, which in this case is used as a property. The automaton for this sequence corresponds to F IRST FAIL(A ({b[*0:2];c})). An alternate design choice for the dispatcher is also possible, by using a counter and a decoder. The counter requires log2 (n) flip-flops, compared to n flip-flops in the first approach, where n is the number of threads. Although the number of flipflops is reduced in the counter approach, a decoder circuit is required, and for many threads a non-trivial amount of logic would be required. The first approach strikes a good balance between combinational logic and flip-flops, as is visible in the left side of Figure 7.6, and is well suited for FPGA implementations; the absence of decoding logic also improves the maximum operating frequency of the checker. The result signals of the threads are combined in an OR-gate, such that if any thread fails, the property fails as a whole. The automaton that is returned is a small two-state automaton as shown at the top right in the figure. The symbol on the edge between the initial and final states is precisely the result signal from the ORgate. The result signal of a thread’s automaton is formed as shown in the top right portion of Figure 7.3, as a disjunction of incoming edges before the FF in the state. Threading also applies to the plain matching sequence automata, as in the antecedent of a suffix implication for example, as opposed to the failure matching automaton discussed above. Seen from the sub-circuit boundary, a multi-threaded sub-circuit’s behavior is identical to that of a non-threaded sub-circuit. To implement threading, it is necessary to isolate a sub-automaton so that it is not merged with the remainder of the assertion’s automaton during automata optimizations. Threading does not apply to sequences resulting from the application of rewrite rules. As mentioned, rewrite rules are not implemented using syntactic replacement in a pre-processor step and are instead implemented in the checker generator’s internal functions. This way the tool is able to distinguish user-defined sequences from those resulting from rewrite rules. An example scenario where assertion threading is useful is in the verification of highly pipelined circuits such as a CPU (Central Processing Unit) pipeline or a network processor, where temporally complex sequences are modeled by assertions. In such cases, it is desirable to partition sequences into different threads in order to separate a failure sequence from other sequences. Once temporally isolated, the exact cause of a failure can be more easily identified. The following example shows how assertion threading can be used to quickly identify the cause of an execution error in a CPU pipeline. Example 7.4. In this example the design under verification is a simplified CPU execution pipeline, inspired by the DLX RISC CPU [94]. The execution unit has a five-level pipeline and executes instructions that perform memory and register manipulations. In the example, only memory writes and register writes are considered. An error injection mechanism is also incorporated in the instruction decoder, such that errors can be inserted for testing purposes. For a given write instruction only

7.4 Debug Enhancements for Checkers

171

two possible destinations are allowed by the architecture, either the memory or the register file, but not both. The following block of PSL statements form an assertion that can be used to detect a faulty write operation. CPU ASR: default clock = ( posedge Clk ); sequence Swr_instr = {InstrValid && (Instr[31:29]==3’b110 || Instr[31:29]==3’b101)}; //write instruction sequence Smemwr = {[*2]; MemWr; !RegWr}; //memory write only sequence Sregwr = {[*2]; !MemWr; RegWr}; //register write only assert always {Swr_instr} |=> {{Smemwr}|{Sregwr}}; //write works

Three sequences are declared, along with the default clock. The first sequence spans one clock cycle and specifies the Boolean conditions for the issuing of a write instruction. The next two sequences specify the proper behavior of memory and register writes. The assertion states that whenever a write instruction is issued, either a memory-only or register-only write should ensue. When a write instruction is issued, either of these two sequences should hold, hence the use of SERE disjunction in the consequent of the suffix implication. In the memory and register write sequences, it can be observed that memory writes are committed in the fourth stage, and register writes in the fifth stage. The first stage is the issued instruction. The non-overlapping suffix implication and the [*2] prefix in the sequences cause the MemWr signal to be tested in the fourth stage and the RegWr to be tested in the fifth stage, as required. The PSL statements are given to the checker generator to produce an assertion circuit, which is then instantiated in the CPU’s RTL code. The checker runs in parallel with the CPU and monitors its signals for faulty executions. Figure 7.7 shows the resulting simulation trace, as exercised in a testbench. The Faulty instruction signal is used to create an error to illustrate how assertion threading can be used in the debugging process. The AssertFailOut signal triggers at a given time point (at the right in the figure), thereby indicating that a violation occurred in the behavior of the write instruction. Since the assertion signal is registered, the thread that caused the error can be identified in the preceding cycle; in this case the error came from thread number two. Tracing back to the clock cycle where this thread was activated, and knowing that the instruction was issued in the previous cycle, it can be deduced that the faulty instruction occurred in the clock cycle where the cursor is located in the figure (which happens to correspond to the cycle in which the error was injected). Assertion threading can be especially beneficial in more complex pipelines such as in superscalar processors, and even in non-processor designs where a large amount of concurrent activity is taking place.

172

7 Enhanced Features and Uses of PSL Checkers Clk Faulty instruction InstrValid Instr InstType

a00... c00... 005... 006... a00... a00... 020... c10... a10... c10... 010... a00... 022... 000 101

110

000

000

101

110

101

110

000

101

000

2

0

0

1

0

MemWr RegWr AssertFailOut Thread Results

0

0

0

0

[4]

[4]

[3]

[3]

[2]

[2]

[1] Thread Activations

[1] 1

0

2

4

0

8

1

0

2

4

[4]

[4]

[3]

[3]

[2]

[2]

[1]

[1]

8

0

Fig. 7.7 Use of assertion threading in the CPU example. a) Verification in Emulation

b) Silicon Debugging

Device Under Verification

First Silicon

Assertion checkers

Emulator Interface

Assertion checkers

Debug Interface

c) Monitoring and Self-Test In-Field Circuit

Assertion checkers µP/Controller

Fig. 7.8 Usage scenarios for hardware assertion checkers.

7.5 Checkers in Silicon Debug and On-Line Monitoring Circuit-level assertion checkers can be used not only for pre-fabrication functional verification, but also for post-fabrication silicon debugging, as illustrated in Figure 7.8b. Assertion checkers can be purposely left in the fabricated circuit to increase debug visibility during initial testing of the device. Assertions compiled with a checker generator can also be used as on-line circuits for various in-field status monitoring tasks, as shown in Figure 7.8c. Subsection 7.5.1 expands on how assertion checkers can be used beyond the verification stages, and into full silicon debugging. Subsection 7.5.2 shows how assertions, combined with a checker generator, can be used to automatically design certain types of circuits. Example scenarios are shown in self-test and in-field monitoring applications. Subsection 7.5.3 introduces an algorithm for assertion grouping and shows how checkers can be managed in a dedicated reprogrammable logic core.

7.5 Checkers in Silicon Debug and On-Line Monitoring a) Silicon Debug

173

State of Device, Time Assertion Checkers

b) Concurrent Self-Test

Test Seq. 1

T.S.2

T.S.n ...

Chk.1

c) Non-Concurrent Self-Test

Chk.2

Chk.n

n Test Sequences n Assertion Checkers

Fig. 7.9 Debugging and self-test using checkers.

7.5.1 Checkers in Silicon Debugging Assertion checkers produced by the checker generator can not only be used for emulation and simulation verification before fabrication, but can also be used postfabrication, when a set of assertion checkers is purposely left in the design. The goal of the silicon debugging process is to find and possibly correct design errors in a post-fabricated Integrated Circuit (IC), usually referred to as first silicon. The checkers can test for functional faults and timing issues which can not be fully tested pre-fabrication. By connecting the checker outputs to the proper external test equipment or on-board read-back circuits, the user can get immediate feedback on assertion failures in order to undertake the debugging process. A checker generator capable of producing resource-efficient checkers is clearly an advantage when checkers take up valuable silicon area in the device. Assertion-based silicon debug differentiates itself from emulation-based verification because in silicon debug, the design is implemented in its intended technology, as opposed to being implemented in reprogrammable logic during hardware emulation. This allows at-speed debugging under expected operating conditions, and assertion checkers play an important role here as well. Figure 7.9a shows how assertion checkers in silicon are used to monitor the state of the device under test during the entire execution. This monitoring mode is identical to that which is used verification, with the nuance that the checkers exist in permanent silicon and can be used during the lifetime of the device, as opposed to temporary verification checkers that are removed before fabrication.

7.5.2 In-Circuit On-Line Monitoring The checkers for silicon debugging mentioned above serve their purpose, but can ultimately be removed for mass production of the IC. In a more general usage scenario, the expressive power of assertions, combined with a checker generator can be used to actually perform explicit circuit design, going beyond the bounds of verification

174

7 Enhanced Features and Uses of PSL Checkers

and debugging. In this view, any form of monitoring circuit that can be expressed by an assertion, once fed into the checker generator, can produce a complex error-free circuit instantly. These circuit-level checkers are in fact more akin to actual design modules rather than verification modules. A checker generator allows the flexibility of automatically generating custom monitor circuits from any assertion statement. Coding checkers by hand can be a tedious and error-prone task. In certain cases, a single PSL statement can imply tens or even hundreds of lines of RTL code in the corresponding checker. Using assertions and a checker generator can be a very efficient way of automating the design of certain types of circuits. An example where this technique can be utilized is in designing certain portions of self-test circuits. Off-line Built-In Self Test (BIST) techniques are well established [3], and are based on the traditional flow: TPG → CUT → ORA where TPG symbolizes Test Pattern Generation and ORA is the Output Response Analyzer. This architecture is shown in Figure 7.10a. Off-line BIST techniques typically employ a mixture of pseudo-random and deterministic TPG. Assertion checkers can also benefit the implementation of self test circuitry, albeit at a higher level. Test pattern generation is instead referred-to as test sequence generation (TSG). Figure 7.10b shows an assertion-based off-line self-test architecture, whereby test sequences are applied to the input of the Circuit Under Test (CUT), and assertion checkers are used as the response analysis circuit. In this approach the signature can be encoded as one bit, representing success or failure. The offline self-test, when executed prior to device startup is considered non-concurrent, and is illustrated in Figure 7.9c. The use of assertions and a checker generator allows the response analysis circuitry to be designed with greater ease. Checker-based techniques also apply to the design of on-line self-test circuits [4], as shown in Figure 7.9b. In this scenario, the checker generator is used to design the analysis circuits that correspond to the given test sequences. Contrary to silicon debug and the other self-test techniques mentioned previously, a checker for a given test sequence is only used as a response analyzer when the test sequence is being

a) Traditional Offline BIST

TPG

CUT

ORA

Reference signature(s)

b) Assertion-Checker-Based Offline Self-Test

Assertions

TSG

CUT

Signature compare

Pass/ Fail

Check. Gen.

Output Checkers

Pass/ Fail

Fig. 7.10 Traditional BIST vs. self-test using checkers. TPG = Test Pattern Generation, TSG = Test Sequence Generation, ORA = Output Response Analyzer.

7.5 Checkers in Silicon Debug and On-Line Monitoring Assertions

Check. Gen.

Circuit

i0

Assertion Checkers Assertion Checkers Circuit

175

Decision Logic

MUX

i1 s

Fig. 7.11 Run-time status monitoring using assertion checkers for redundancy control.

exercised. In the concurrent self-test model, the device is momentarily interrupted for testing, or alternately, unused resources are concurrently tested during runtime. Using assertions and a checker generator as a means of circuit design poses difficulties when it comes to generation signals; however, the design of many types of monitoring and analysis circuitry can benefit directly from this technique. The highlevel expressiveness of an assertion language combined with a checker generator can be used as a quick method to automatically design circuits. If checkers are incorporated in the final design, in-circuit diagnostic routines that utilize the checker output can be implemented. Assertion checkers can be an integral part of any design that attempts to assess its operating conditions on-line in real time. Run-time assertion monitoring can be performed by the checkers, and the results can be analyzed by an on-board CPU that can then send regular status updates off-chip. Real-time monitoring based on in-circuit checkers can be especially important in mission critical environments. For example, if a multitude of assertion checkers running concurrently with the device were to detect an error, a secondary redundant system could be instantly activated. Figure 7.11 shows an example of how checker generator can be used to design the monitoring circuits for switching in redundant systems. Designing an array of safety-checking circuits can be more easily performed using assertions and a checker generator.

7.5.3 Assertion Grouping With increasing device complexity and the advent of System-on-Chip (SoC) and Network-on-Chip (NoC) designs, small blocks of reprogrammable logic are commonly added to ICs. This allows a certain amount of flexibility for correcting postfabrication defects, and also allows a certain amount of further design modifications to be performed. When a large amount of assertion checkers is to be instantiated in a design, space constraints can limit their applicability. If the device utilization is near maximum capacity, there may not always be room for all the checkers. Furthermore, if the device has the necessary free space for adding a small area of reprogrammable logic (if not already present), and if the logic can be connected to the main signals

176

7 Enhanced Features and Uses of PSL Checkers System-on-Chip CPU

Core 2 Reprogrammable logic core

Debug Intf.

Core 1

Core 3 : Assertion checkers

Fig. 7.12 Fixed and reprogrammable assertion checkers in SoCs.

of interest throughout the device, then in such cases assertion grouping must be performed to manage a large set of checkers. In assertion grouping, the set of checkers is partitioned into groups whereby each group is guaranteed not to exceed the size of the reprogrammable logic area. Ideally, the number of groups should be minimized so that fewer reconfiguration steps are necessary. In SoC designs, some modules are often carried over from a previous design and do not require a detailed verification. Newly designed modules will require greater interoperability with the reprogrammable fabric, in order to perform assertion-based debugging. Protocol monitors may also be required to debug complex interactions between cores. The reprogrammable logic can also be used for assertion checking in offline unit testing before the device is fully operational. Figure 7.12 shows an example scenario where a reprogrammable logic core was added to a SoC. In this example, the CPU and Core 1 were part of a previous design and were known to be bug-free. Consequently, their interconnection with the reprogrammable logic is rather limited. Cores 2 and 3 are newer modules and have more connections to the logic, in the event that circuit corrections need to be performed in the fabricated IC. In the example figure, two assertion checkers are placed in permanent silicon, and four are temporarily programmed in the reprogrammable fabric. The reprogrammable logic core can even be used to perform the assertion-based concurrent BIST described in Figure 7.9c. In this scenario, the CPU can coordinate the instantiation of the proper checkers for each test set in the reprogrammable fabric. Checker groups (also called partitions, or subsets) are instantiated one after the other in the reconfigurable area, corresponding to the set of test sequences being executed. Reprogramming reconfigurable logic on-the-fly for different tasks is known as run-time reconfiguration [148]. The checker generator typically processes a set of PSL statements and transforms them into an RTL module of synthesizable code. In the generated checker, each assertion-circuit’s RTL code is clearly marked. The scripts around MBAC can then extract each assertion circuit from the checker’s RTL module, and automate the individual synthesis of these checkers. This processing facilitates obtaining the circuit-size metrics for each checker. Even further, scripting can facilitate logging of

7.5 Checkers in Silicon Debug and On-Line Monitoring

177

Algorithm 7.2 Assertion circuit partitioning algorithm. 1: FUNCTION: S UBSET-C IRCUIT(set C of circuit metrics (FF, LUT), areaFF , areaLUT ) 2: D ← C 3: while there are circuits left in C do //phase 1 (dominant metric is #FF) 4: sort circuits C according to #FF 5: build dynamic programming table T for subset-sum on #FF 6: search T for best subset S such that ∑si ∈S #LUT (si ) < areaLUT 7: log subset circuits in S as a group in phase 1 results 8: remove circuits S from C 9: while there are circuits left in D do //phase 2 (dominant metric is #LUT) 10: sort circuits D according to #LUT 11: build dynamic programming table T for subset-sum on #LUT 12: search T for best subset S such that ∑si ∈S #FF(si ) < areaFF 13: log subset circuits in S as a group in phase 2 results 14: remove circuits S from D 15: if number of subsets in both phases differs then //analysis 16: return results of phase which has the fewest subsets (groups) 17: else 18: return results of phase for which the subset-sum was performed on metric with smallest freedom

these metrics in a file, which is then used as an input to the partitioning algorithm, described next. FPGA synthesis tools are used in this example scenario. Once the checkers have been individually synthesized and their sizing metrics are obtained, the partitioning algorithm shown in Algorithm 7.2 is used to create subsets of checkers suitable for multiple reconfigurations in the reprogrammable logic area. This algorithm is based on solving the subset-sum problem by dynamic programming [56]. However, because the circuit metrics comprise two variables, namely # of flip-flops (FF) and # of lookup tables (LUT), the typical subset-sum procedure can not be employed directly on its own. A two-phase algorithm is developed, which returns a near-optimal partition. The inputs to the algorithm are the circuit metrics and the size of the reprogrammable area (also specified as # of flip-flops and # of lookup tables). Phase 1 in the algorithm (lines 3 to 8) uses flip-flops as the dominant metric and performs a subset-sum computation on this metric (line 5). The subset-sum algorithm requires that the circuits be sorted in increasing order according to the dominant metric (line 4). A search is then performed for the best subset according to the size limit of this dominant metric, while also respecting the maximum size for the secondary metric (line 6). Once the best subset has been determined, it is logged and removed from the set (lines 7 and 8). This procedure continues until the set of checkers is empty (line 3). The dominant and secondary metrics are interchanged and the same procedure is repeated (lines 9 to 14). A comparison is then made between both phases (lines 15 to 18), and the solution with the fewest subsets is logged. When both phases have the same number of subsets, it was empirically observed that the more balanced partition is the one for which the dominant metric is the most constrained by the area limits (smallest freedom).

178

7 Enhanced Features and Uses of PSL Checkers

It can be shown by counterexample that the algorithm is not guaranteed to create an optimal partition; however, experiments show that it drastically outperforms the brute force approach in computation time. Furthermore, when one of the metrics has a large amount of freedom with respect to its area constraint, the problem tends toward a single variable subset sum for which the algorithm is optimal.

Chapter 8

Evaluating and Verifying PSL Assertion Checkers

Abstract This chapter presents the experimental setup devised to achieve several goals in evaluating the usability, performance and correctness of MBAC. The full verification of comprehensive CAD programs such as MBAC is a challenging task, and we make concerted efforts to ensure its correctness by several orthogonal means. Further, extensive benchmarks were developed to test compilation of all the features of PSL, together with suitable testbenches. The results mainly involve mapping the compiled assertion checkers to concrete FPGAs, as well as a comparison to other assertion checkers and assertion simulators.

8.1 Introduction and Overview In this chapter the assertion checkers produced by the MBAC checker generator are empirically evaluated. The MBAC tool incorporates the techniques introduced in the three previous chapters, and is coded in C++. The tool is a standalone executable invoked at the command line. The experiments performed herein have the goal of evaluating three principal factors associated with assertion checkers: 1. Hardware resource usage and operating frequency of checkers 2. Functional correctness of checkers 3. Support of PSL operators in the checker generator The checkers should utilize the fewest circuit primitives as possible and should run at the highest possible clock speed. Resource efficient checkers are important so that the in-circuit debugging capabilities resulting from the ABV methodology can be performed less obtrusively when checkers are added to a design under verification. The small circuit size of checkers is also beneficial when the checkers are used as permanent status monitors, and more generally when checkers are used as actual design modules. The checkers should also correctly implement the behavior

179

180

8 Evaluating and Verifying PSL Assertion Checkers

specified by their respective assertions, and the checker generator should support all the PSL operators in the simple subset. In the majority of the experimental results, the checkers produced by MBAC are compared to the FoCs checker generator from IBM, which is the only available stand-alone checker generator. The versions of the tools that are the most recent at the time of writing are MBAC version 2.02 and FoCs version 2.04 [103]. When evaluated in hardware, the checkers are synthesized with Xilinx XST 8.1.03i for an XC2V1500-6 FPGA, and the synthesis is optimized for speed (as opposed to area). The number of FFs and lookup tables (LUTs) required by a circuit is of primary interest when assertion circuits are to be used in hardware emulation and silicon debugging. Because speed may also be an issue, the maximum operating frequency (after the synthesis step) is reported for the worst clk-to-clk path. Although in this technology the fundamental metrics are the number of Flip-Flops (FF) and fourinput lookup tables (used for implementing combinational logic), the checkers could also be synthesized in other technologies such as standard cell ASICs (Application Specific Integrated Circuits). When a vunit contains multiple assertions, an HDL module containing the checkers is created. A vector of output signals is declared, where each bit in the output vector corresponds to an assertion signal. For synthesis metrics to be meaningful, each assertion checker must be synthesized individually to avoid any resource sharing at the hardware level. This is accomplished by redefining the output vector as a one-bit signal, and synthesizing the module multiple times, whereby the desired assertion signal is routed to the output. In this way, any unused logic is trimmed. The only exception to this is when groups of assertion checkers are synthesized, as in Section 8.3 for example, where assertion grouping is evaluated. When evaluated in software, the RTL checkers are simulated in the ModelSim simulator from Mentor Graphics (version 6.1f SE) [126], where the behavior of the checkers can be compared to the assertions as interpreted by ModelSim. Functional equivalence of checkers can also be verified formally using model checking. This procedure can be used to assess whether two checkers for the same assertion are actually behaving the same way, and will be used in this chapter both to compare MBAC checkers with FoCs, and to compare two different implementations of checkers for the same assertion in the MBAC tool. The model checking technique for performing sequential equivalence checking is illustrated in Figure 8.1. The model checker used in the experiments is Cadence SMV [42]. The central element is the exclusive-or gate that evaluates to logic-1 when both inputs are not equal. The additional inverter is used because the assertion polarity of FoCs’ circuits is different than with MBAC’s circuits. The outputs of MBAC’s checkers are normally at logic-0 and momentarily rise to logic-1 to signal assertion errors; the opposite polarity is used in FoCs. A testbench instantiates both checkers and postulates that the output of the xor gate is always at logic-0 (i.e. the circuits are equivalent). The assertion statement used to specify the equivalence has the form: assert reset -> !XOR Output;

8.1 Introduction and Overview

181 Equivalence checking by model checking

MBAC

Checker #1 (MBAC) Output

Assertion FoCs

Checker #2 (FoCs) assert A1: (!reset | !Output);

Fig. 8.1 Equivalence checking by model checking.

where the reset signal is active low. The assertion above states that when the reset is not active (i.e. logic-1), then the output of the xor gate should always be at logic-0. In the Cadence SMV model checker, the assert directive, when placed in an always procedural block, specifies a design invariant and is checked in all possible executions. In Figure 8.1, the implication is rewritten using disjunction as shown in (6.1). In essence, this construction extends the traditional miter approach to circuit verification [34]. When the circuits are functionally equivalent, the model checker returns true, otherwise it returns false and produces a counterexample. It should be emphasized that this is a static verification with implicit complete coverage, and no test vectors need to be supplied. In the following two sections, non-synthetic assertions are used to evaluate the checker generator. The term non-synthetic is used to refer to real assertions appearing throughout the literature and related research. This is in contrast to synthetic assertions appearing in the remainder of the chapter. As will be explained further, common real-world assertions are not temporally complex enough to truly benchmark the effectiveness of a checker generator, and a set of hand-designed assertions over plain Booleans will also be devised. In the experiments, the actual source design is not implemented and the emphasis is placed on the actual checkers that are generated from the assertions. For example, in the PCI-read assertion from the book “Assertion-Based Design” [75] (ABD), the PCI interface to which the assertion refers to is not given, and is not required. Incorporating the entire source design in the circuit metrics does not allow the size of the checkers to be discerned properly, and diverts attention from the size of the checkers themselves. Furthermore, the source design could be coded in a variety of ways, some more efficient than others, and would not represent a universal metric. In general, an upper bound on the hardware overhead associated with assertion checkers can be obtained by adding the size metrics of the checkers to the size of the source design. When the checkers are synthesized with the source design however, resource sharing helps to reduce the total circuit size. This resource sharing can occur between the checkers and the source design, or between the checkers themselves.

182

8 Evaluating and Verifying PSL Assertion Checkers

When the source design is not available, all that must be done for the checker generator to function correctly is to define a declaration module containing only the declarations of the signals used in the assertion. This HDL module does not have any actual functionality, and is the minimal requirement for the MBAC and FoCs checker generators to operate properly. The vunit containing the assertions is then bound to the declaration module. In all experiments, the outputs of the checkers are sampled by a flip-flop (FF) sensitive to the rising edge, such that equivalence checks and simulation results are glitch-free. In some cases in equivalence checking, the flip-flop is made to be a monostable flip-flop that perpetually remains in the triggered state once the assertion signal has triggered. This does not affect the validity of the equivalence check and is used when the run-time semantics of two checkers are different, while still both being correct, as discussed in Section 2.3. When the monostable flip-flops are used at the outputs of the checkers, a verified equivalence indicates that both circuits are identical when the pre-FF output does not trigger, and indicates that both find the first error at the same clock cycle, for all possible error traces. Once an assertion has failed, it has failed as a whole, and a checker could in fact stop reporting errors altogether, although this would not be ideal for debugging purposes. The majority of the experimentations compare the checkers produced by MBAC to those produced by the FoCs tool, after synthesis to FPGA technology. Exceptions to this are Sections 8.4 and 8.5. In Section 8.4, the checkers are compared by evaluating the RTL code before synthesis. This reveals insight into the size of the checkers that are generated in HDL, before any of the optimizations brought upon by the synthesis tool are applied. In Section 8.5, the debugging enhancements for hardware assertion checkers that were introduced in the previous chapter are novel and can not be compared to any other tool.

8.2 Non-synthetic Assertions In this section, non-synthetic, or real-world assertions, are used to evaluate the checker generator. The non-synthetic assertions are meant to verify particular aspects of real design modules, and their Boolean layer expressions do not typically consist purely of simple signals. In the majority of test cases, a declaration module is created to represent the CUT, where only the signal declarations are defined. The assertions used in the test cases are shown below, and the synthesis results and the comparisons to the FoCs checkers are presented at the end of the section. The default clock declarations are omitted, and all signals are sensitive to the rising edges of the clock. In all cases an active low reset was used. The vector widths of signals are specified, and all signals that are not mentioned are assumed to be single-bit entities. The first assertion used to evaluate the checker generator is the PCI assertion adapted from page 102 in “Assertion-Based Design” [75]. This assertion models the correct behavior of a read transaction for the PCI bus, and is specified using multiple

8.2 Non-synthetic Assertions

183

sequence declarations. Different phases of the transfer are modeled separately, such as turn-around and the address and data phases. The cbe n signal is three bits wide. PCI ASR: ‘define ‘define ‘define ‘define ‘define --‘define ‘define ‘define ‘define ‘define ‘define ‘define

IO_READ 4’b0010 MEM_READ 4’b0110 CONFIG_RD 4’b1010 MEM_RD_MULTIP 4’b1100 MEM_RD_LINE 4’b1110 data_complete ((!trdy_n || !stop_n) && !irdy_n && !devsel_n) end_of_transaction (‘data_complete && frame_n) adr_turn_around(trdy_n & !irdy_n) data_transfer(!trdy_n && !irdy_n && !devsel_n && !frame_n) wait_state ((trdy_n || irdy_n) && !devsel_n) cbe_stable (cbe_n==prev(cbe_n)) read_cmd ((cbe_n ==‘IO_READ) || (cbe_n == ‘MEM_READ) || (cbe_n == ‘CONFIG_RD) || (cbe_n == ‘MEM_RD_MULTIP) || (cbe_n == ‘MEM_RD_LINE))

--sequence SERE_RD_ADDR_PHASE = {frame_n;!frame_n && ‘read_cmd}; sequence SERE_TURN_AROUND = {‘adr_turn_around}; sequence SERE_DATA_TRANSFER = {{‘wait_state[*]; ‘data_transfer}[+]}; sequence SERE_END_OF_TRANSFER = {‘data_complete && frame_n}; sequence SERE_DATA_PHASE = { {{SERE_DATA_TRANSFER} ; {SERE_END_OF_TRANSFER}} && {‘cbe_stable[*]} }; --property PCI_READ_TRANSACTION = always ({SERE_RD_ADDR_PHASE} |=> {SERE_TURN_AROUND; SERE_DATA_PHASE}) abort !rst_n; assert PCI_READ_TRANSACTION;

The only change done in the assertion above concerns the addition of the [*] repetition in the right side of the intersection (&&) in the SERE DATA PHASE sequence. When the assertion is used as presented in the ABD book [75] (i.e. without the [*]), the checker generator produces a suspiciously small checker where the majority of the Boolean layer signals are not used. This reveals a potential error in the assertion itself, and upon closer inspection, it can be seen that when the ‘cbe stable sequence is not repeated, the length matching intersection in the SERE DATA PHASE can never produce a match. This is because the ‘cbe stable is a sequence that spans one cycle, and the left side of the lengthmatching && spans at least two clock cycles. The corrected version of the assertion is used in the experiment, and the original one likely contained only a typographical error. The next two assertions are used to ensure correctness of the AMBA bus protocol, and are from Chapter 8 in “Using PSL/Sugar for Formal and Dynamic Verification” [52]. Each assertion represents the most temporally complex assertion from

184

8 Evaluating and Verifying PSL Assertion Checkers

the two main AMBA test suites, each comprising a set of 26 assertions. The first assertion, AHB ASR, captures the requirement that a bus transaction must never stall for more than 16 cycles. The hResp signal is a two-bit vector indicating the outcome of the transaction (other outcomes are ERROR, RETRY and SPLIT). AHB ASR: localparam OKAY = 2’b00; --property NeverMoreThan16WaitStates = always ( {(hReady == 1);(hReady == 0)} |=> {{(hReady == 0)[*0:15]};{hReady == 1}} abort (hResp != OKAY)); assert NeverMoreThan16WaitStates;

The second AMBA bus protocol assertion verifies the correct operation of the state machine used to decode a read transaction, as seen from a bus slave interface. The fsm read and hburst vectors are three bits wide, and htrans is two bits wide. The localparam keyword was changed to parameter in the test files used. MemSlave ASR: localparam NONSEQ = 2’b10; localparam SINGLE = 3’b000; localparam FSMR_IDLE = 3’b000; // no ahb activity localparam FSMR_READ_P1 = 3’b001; // ahb in read mode, pipe 1 localparam FSMR_READ_P2 = 3’b010; // ahb in read mode, pipe 2 localparam FSMR_READ_P3 = 3’b011; // ahb in read mode, pipe 3 --sequence qNonSeqReadTransferSingle = {hburst==SINGLE && htrans==NONSEQ && hwrite==1’b0 && hsel_0n==1’b0 && done_xfrn==1’b0}; -property ReadFsmPipelineSingle = always( {qNonSeqReadTransferSingle} |=> {fsm_read==FSMR_READ_P1 && hready==1’b0; fsm_read==FSMR_READ_P2 && hready==1’b0; fsm_read==FSMR_READ_P3 && hready==1’b1; (fsm_read==FSMR_IDLE)}); assert ReadFsmPipelineSingle;

The Open Verification Library (OVL) [76] consists of a set of parameterized HDL assertion checkers, for use in various scenarios from general (ex: always and never checkers) to particular (ex: parity and FIFO checkers). Version 2.0 beta of the OVL was used in the experiments. Here also, the most temporally complex assertions were selected, and in this case four assertions were retained for benchmarking. The test expr2 signal is width bits wide (i.e. [width-1:0]).

8.2 Non-synthetic Assertions

185

OVL ASRa - OVL ASRd: parameter num_cks = 2; parameter max_cks = 2; parameter width = 8; --property ASSERT_FRAME_RESET_ON_START_MAX_CHECK_P = always ( ({(max_cks > 0) && reset_on_new_start && rose(start_event) && !test_expr} |=> {!test_expr[*0:1];(test_expr || rose(start_event))}) abort(!reset)); assert ASSERT_FRAME_RESET_ON_START_MAX_CHECK_P; --property ASSERT_HANDSHAKE_ACK_WITHOUT_REQ_SUBSEQUENT_REQ_P = always (({fell(ack)}|-> {{[*];rose(req);[*]} && {!ack[*];ack}}) abort(!reset)); assert ASSERT_HANDSHAKE_ACK_WITHOUT_REQ_SUBSEQUENT_REQ_P; --property ASSERT_UNCHANGE_RESET_ON_START_P = always ( {(num_cks > 0) && reset_on_new_start && start_event} |=> {(test_expr2 == prev(test_expr2))[*]; !window} abort(!reset)); assert ASSERT_UNCHANGE_RESET_ON_START_P; --property ASSERT_WIN_CHANGE_P = always (({start_event && !window ; stable(test_expr2)[*1:inf]} |-> {!end_event}) abort(!reset) ); assert ASSERT_WIN_CHANGE_P;

Another real-world assertion comes from the area of Network-on-Chip (NoC) applications, where an entire system and its network infrastructure are contained in the same integrated circuit. The test assertion used is from a Network-On-Chip application [47], and is used to ensure that a network message (flit) reaches its intended destination node. The assertion is parameterized through a set of register variables, such that it can be reprogrammed by the on-board CPU to track different flits. The network architecture is a Ring-of-Rings structure [33], comprised of one central ring and four satellite rings. The assertion ensures that a triple of flits is observed in the proper order in an interface. The x SrcGlobal and x SrcLocal signals are four-bit signals, and the x Data signals are 32 bit vectors (x DataValid signals are single-bit). NOC ASR: sequence NR_P1 = {NR_DataIng_p_DataValid == 1 && NR_DataIng_p_SrcGlobalRing == Reg_SrcGlobal1 && NR_DataIng_p_SrcLocalRing == Reg_SrcLocal1 && NR_DataIng_p_Data == Reg_SrcData1}; sequence NR_P2 = {NR_DataIng_p_DataValid == 1 && NR_DataIng_p_SrcGlobalRing == Reg_SrcGlobal2 && NR_DataIng_p_SrcLocalRing == Reg_SrcLocal2 && NR_DataIng_p_Data == Reg_SrcData2}; sequence NR_P3 = {NR_DataIng_p_DataValid == 1

186

8 Evaluating and Verifying PSL Assertion Checkers

&& NR_DataIng_p_SrcGlobalRing == Reg_SrcGlobal3 && NR_DataIng_p_SrcLocalRing == Reg_SrcLocal3 && NR_DataIng_p_Data == Reg_SrcData3}; --assert always {NR_P1} |-> eventually! {NR_P2; [*]; NR_P3};

A large amount of assertions is used in the PROSYD project [105] to verify a data receiver block. The block is connected to a consumer and a producer, and various forms of assertions are explored, some which are equivalent to others. Five of the most temporally complex assertions are reported below and are used in the evaluation. The STATE vector is a 2-bit enumerated type, RESERVED is an 8-bit vector, and DATA IN and DATA OUT are 64-bit vectors. DATARX ASRa - DATARX ASRe: assert never {END; {(!START)[*]; START; true} && {ERROR[=1]}}; --assert { [*]; { rose(ENABLE) && STATE==active1; (rose(ENABLE) && STATE==active1)[->]} && {START[=0]}} |=> {[*0:2] ; START}; --assert always ((STATE==data && DATA_IN[63] && (DATA_IN[7:0] == RESERVED[7:0]) && !STATUS_VALID) -> next_e[1:3](STATUS_VALID && (DATA_OUT[41] || DATA_OUT[34] || DATA_OUT[37]))); --assert {[*]; (REQ && STATUS_VALID)[=3]; STATUS_VALID[->]} |-> {ACK}; --assert {[*]; {READ[=3]} && {WRITE[=2]}} |=> {(!READ && !WRITE)[*]; READY}! ;

Other non-synthetic assertions appearing throughout the previous chapters are also used to evaluate the checker generator. The up-down counter from Example 4.4 on page 69 contains four assertions respectively labeled UDCNT ASRa to UDCNT ASRd. The full HDL and PSL code of this example is given in Appendix A. The default width in the parameter declaration is assumed for the counter’s output and load buses (eight bits). The assertion contained in the CPU-write case study for assertion threading on page 170 (Example 7.4) is used, and is labeled CPU ASR. The arbiter assertion in (2.2) on page 17 is also used, and is labeled ARB ASR. Table 8.1 shows the hardware synthesis results of the checkers for each assertion mentioned in this section, as produced by both the MBAC and FoCs checker generators. It should be noted that for assertions OVL ASRd and UDCNT ASRa, the stable() function is not supported by FoCs and was rewritten as shown in Proposition 6.1. Furthermore, the consequent of the suffix implication in UDCNT ASRa and the argument of never in UDCNT ASRd were braced {. . .}, as FoCs does not seem to support the non-braced versions. In all of these cases, FoCs did not support the original assertions and could have been marked as not supported in the table.

8.2 Non-synthetic Assertions

187

Table 8.1 Benchmarking of non-synthetic assertions. N.S.Y. = Not Supported Yet; ∗ = overlooking the reset of built-in functions in FoCs (explained further).

Assertion

Hardware Metrics MBAC FoCs FF LUT MHz FF LUT MHz

PCI ASR AHB ASR MemSlave ASR OVL ASRa OVL ASRb OVL ASRc OVL ASRd NOC ASR DATARX ASRa DATARX ASRb DATARX ASRc DATARX ASRd DATARX ASRe UDCNT ASRa UDCNT ASRb UDCNT ASRc UDCNT ASRd CPU ASR ARB ASR

9 18 5 4 4 10 11 3 5 6 4 5 13 10 10 10 10 6 7

19 17 16 5 4 8 9 69 5 7 11 5 21 7 6 6 10 4 9

317 611 456 606 474 311 332 559 598 610 667 559 439 348 349 366 667 564 434

9 19 317 18 18 665 5 11 338 4 5 606 4 3 474 10 9 311 11 8 311 N.S.Y. 5 5 598 6 7 610 4 11 667 5 6 441 N.S.Y. 10 7 348 10 6 349 10 7 348 10 10 667 6 4 564 7 9 434

Equivalence Check MBAC ↔ FoCs Pass Fail → CE1 Pass Pass∗ Pass∗ Pass Pass – Pass Pass∗ Pass Pass – Pass Pass Pass Pass Pass Pass

For the AHB ASR assertion, the equivalence check failed and the counterexample below reveals a slight problem with the FoCs checker: CE1 : { hready ∧ (hresp !=OKAY) ; 0[*17]} In this counterexample, signals not listed are assumed to be at logic-0, and in the 17 cycles symbolized by [*17], all signals are at logic-0, including hresp. In the assertion, by operator precedence the abort applies only to the consequent sequence (as opposed to the entire suffix implication). It is likely that in FoCs the abort is erroneously applied to the antecedent also. When simulating the checkers with the counterexample trace, in the FoCs checker the abort condition cancels the hready and the assertion does not trigger. In the MBAC checker the assertion signal triggers (as it should); this was confirmed in simulation where ModelSim’s interpretation of the assertion on the counterexample trace also triggers. For the MemSlave ASR and ARB ASR test cases, the equivalence verification succeeded with the monostable output FF only. As stated in the previous section, the monostable does not affect the validity of the equivalence verification, and only indicates that the checkers have differences in their run-time semantics after the first error is reported. The difference in behavior explains the difference in the LUT metric in the table for this example. The NOC ASR and DATARX ASRe test cases are not supported by FoCs. In the first case, FoCs does not support the use of eventually! in the consequent of the

188

8 Evaluating and Verifying PSL Assertion Checkers

suffix implication, and in the second case it is likely that the strong sequence is the cause. In the second case no output is generated by FoCs even though the assertion is properly recognized in its user interface. The hardware metrics for the NOC ASR assertion are heavily biased towards LUTs because of the many vector comparisons in the sequences. In the remaining test cases in the table, both tools perform very similarly in terms of circuit sizes, and are shown to be functionally equivalent. The results marked “pass∗ ” (i.e. with the additional asterisk), indicate a case where the flip-flops for the built-in functions are reset by the FoCs checkers when the reset signal is activated. These cases actually show counterexamples for FoCs in the equivalence check, since the Boolean layer’s flip-flops should not be reset nor aborted. In the details of Proposition 6.1 in Section 6.2, it was indicated that such flip-flops should only be used to create delayed values for expressions and should not be initialized with the checker’s reset. To illustrate, consider the following assertion based on the rose() built-in function: assert never rose(a); When the checkers’s reset signal is released, it begins evaluating the property. Now consider the trace where a is always true, and the reset (active low in this example) is at logic-0 for the first cycle, and is logic-1 thereafter. This can be summarized in the trace: { a ∧ !reset ; a ∧ reset } If the flip flop that is used in the implementation of rose (Proposition 6.1) is reset by the checker’s reset, in the counterexample’s second cycle, signal a is erroneously interpreted as having risen. This is because in the current cycle it is at logic-1, and in the previous cycle it was registered as being at logic-0 (flip-flop was reset). As it appears in the trace however, signal a was asserted in both cycles and did not rise. These types of counterexamples were observed for the OVL ASRa, OVL ASRb and DATARX ASRb benchmarks in Table 8.1. When ignoring this particular behavior for the built-in functions, the checkers produced by FoCs are equivalent to those produced by MBAC. For further examples of reset in the built-in functions’ flipflops, the source code of the checkers for UDCNT ASRa to UDCNT ASRc can be consulted in Appendix A; the differences between the resetting of the automata flip-flops and the built-in function flip-flops can be compared further.

8.3 Evaluating Assertion Grouping In this section the assertion partitioning algorithm presented in Section 7.5 is evaluated. The MBAC checker generator is used to produce assertion checkers for two suites of assertions. The assertions are used to verify an AMBA slave device and AMBA AHB interface compliance, and are from Chapter 8 in “Using PSL/ Sugar for Formal and Dynamic Verification” [52]. The assertions are not shown since the main interest here is an evaluation of assertion grouping, rather than the actual

8.3 Evaluating Assertion Grouping

189

Table 8.2 Resource usage of assertion checkers for grouping. AHB example: Assertion AHB AHB AHB AHB AHB AHB AHB AHB AHB AHB AHB AHB AHB

FFs LUTs MHz

A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13

2 2 2 2 2 2 2 2 2 1 2 2 2

2 3 3 2 2 2 2 2 2 6 30 18 18

667 611 667 611 667 667 667 667 667 N.A. 667 667 611

Assertion

FFs LUTs MHz

AHB AHB AHB AHB AHB AHB AHB AHB AHB AHB AHB AHB AHB

1 1 2 2 3 3 3 1 1 1 1 1 18

A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26

12 36 20 2 2 3 2 23 21 21 19 6 17

N.A. N.A. 667 611 667 667 667 N.A. N.A. N.A. N.A. N.A. 611

MemSlave example: Assertion MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave

FFs LUTs MHz A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13

1 2 2 2 1 1 1 1 4 5 5 2 2

4 4 2 2 2 7 2 7 9 16 22 3 3

N.A. 667 667 667 N.A. N.A. N.A. N.A. 417 456 469 667 667

Assertion MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave MemSlave

FFs LUTs MHz A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26

2 2 2 1 4 1 1 1 1 2 1 1 1

3 3 7 2 12 5 6 6 1 5 4 3 18

667 667 667 N.A. 442 N.A. N.A. N.A. N.A. 667 N.A. N.A. N.A.

synthesis results of each checker. Because of the temporal nature of the assertions, the checkers utilize more combinational cells than flip-flops. However, the partitioning algorithm can operate on any type of circuits whether they are balanced or biased towards either flip-flops or combinational logic. Table 8.2 shows the individual resource usage of checkers for the assertions in the AHB and MemSlave examples. In the table, N.A. means “Not Applicable”, and occurs for circuits containing only one FF with no feedback path (the MHz is a clk-toclk figure). Table 8.3 shows how the assertion circuits from Table 8.2 are partitioned into a minimal number of sets by the subset-circuit algorithm (Algorithm 7.2), for a target area of 50 FFs and 50 four-input LUTs. In both cases, results of phase two in the algorithm were logged (dominant LUTs). The right-most column lists the sums of the circuit metrics in each group. Table 8.4 shows how the actual resource usage can be slightly diminished when the circuits that form a subset are actually synthesized together. As a general result,

190

8 Evaluating and Verifying PSL Assertion Checkers

Table 8.3 Checker partitions for reprogrammable area. AHB example:

Σ FF, Σ LUT

Subset Assertion circuits in partition #1 #2 #3 #4 #5 #6

{A9, A14, A15} {A8, A22, A23, A25} {A7, A10, A21, A24} {A6, A11, A13} {A1, A2, A3, A4, A5, A12, A16} {A17, A18, A19, A20, A26}

4, 50 5, 50 5, 50 6, 50 14, 50 29, 26 Total:

63, 276

MemSlave example:

Σ FF, Σ LUT

Subset Assertion circuits in partition #1 #2 #3 #4

{A6, A8, A19, A20, A21, A22, A26} {A1, A11, A15, A18, A23, A24} {A2, A3, A5, A7, A9, A10, A14, A16, A17, A25} {A4, A12, A13}

7, 50 15, 50 21, 50 6, 8

Total:

49, 158

Table 8.4 Subset and full-set synthesis of checker groups. AHB example:

MemSlave example:

Subset FFs, LUTs

Subset FFs, LUTs

#1 #2 #3 #4 #5 #6

4, 50 5, 50 5, 49 6, 34 13, 48 29, 26

#1 #2 #3 #4

7, 43 15, 47 21, 47 6, 8

Total:

49, 145

Total:

62, 257

Full-Set (FFs, LUTs)

Full-Set (FFs, LUTs)

60, 250

48, 129

it can be expected that as the number of circuits per subset increases, the resource sharing becomes more important, and the overall metrics for a given subset become smaller. For comparison purposes, Table 8.4 also lists the full-set metrics, which are obtained by synthesizing all checkers as a single module. In both test suites, resource sharing is greater for LUTs than for FFs, and is more prominent in the MemSlave test suite. The end result is an efficient partition of checkers which minimizes the number of times the reprogrammable logic area must be reconfigured. A test procedure can then run a batch of test sequences with a given subset of checkers, then instantiate

8.4 Pre-synthesis Results

191

a new set of checkers, re-run the test sequences, and so forth. Once the verification with checkers is finished, the reprogrammable fabric can be used for the functionality of the intended design.

8.4 Pre-synthesis Results In this section the effects of the alphabet choice on the automata produced are evaluated. The automata metrics that are reported are the number of edges and the number of states. In the tables to follow, the two columns titled “Edges ΣP ” and “Edges ΣS ” represent the number of edges when either the power set or symbolic approaches are used, as defined in Definitions 5.1 and 5.2 respectively. Since the number of states is identical in both approaches, the number of states is reported in one column. After having considered Example 5.1, the power set alphabet can be expected to be worse; however, this section presents broader quantitative data to confirm this. The goal of this section is two-fold: first, the efficiency of the two alphabet approaches is compared, and second, an example of how assertions and a checker generator can be used to create hardware pattern matchers is shown. Although this second case is illustrated using hardware protein matchers as examples, the purpose is not to compare with existing protein matching machines, whether hardware or software, but rather to show that assertions and a checker generator can be used to perform other types of automated circuit design, going beyond the intended task of verification.

8.4.1 Experiments with Hardware Protein Matchers The string matching theme is explored here, with a particular application in protein matching. The checker generator can be used to generate protein matching circuits that could potentially perform the matching faster than software approaches [135] and require less computing infrastructure. The protein sequences that are to be matched are described by regular expressions in a slightly different notation than conventional regular expressions: “–” represents concatenation, “x” represents any symbol, symbols inside “[ ]” denote choice and parentheses represent repetition (with a count or a range). The proteins used in the experiments are from the PROSITE list [97]. The typical task of protein matching software consists of finding a given protein in a longer protein. A protein is a sequence of amino acids, and there are twenty standard amino acids each represented by a single capitalized character. For example, here is the expression for Protein Site (PS) # 00007: PS00007:

[RK] – x(2) – [DE] – x(3) – Y

192

8 Evaluating and Verifying PSL Assertion Checkers

A pattern matcher for this regular expression can be expressed in PSL as the assertion: assert never { {t==’R’}|{t==’K’}; [*2]; {t==’D’}|{t==’E’}; [*3]; t==’Y’ };

(8.1)

The characters in quotes represent ASCII values for the corresponding protein symbols. The assertion in (8.1) postulates that the protein sequence is never matched. When it is matched, the assertion output signal triggers and indicates when the string is detected. Normally, an assertion failure indicates a problem in the device being verified, but in this case the checker is used as a pattern matcher that must report occurrences of a given sequence. It should be noted that the circuit–under–verification need not be completely defined for the checker generator to operate correctly: all that must be done is to bind the assertion to a module that defines an eight–bit signal called t. The actual circuit would be a text reader that scans the database and processes one character (amino acid) per clock cycle. The never property has the effect of continually starting a match for the sequence, such that every time the sequence manifests itself, the assertions output triggers. Table 8.5 shows the automata metrics of the hardware protein matchers generated by MBAC, for a selection of protein sites. Each protein is expressed as an assertion in a similar manner to PS00007 shown in (8.1). As can be observed, the number of edges is noticeably smaller in the symbolic encoding. The hardware string (protein) matching created here runs in O(m) time, where m is the number of characters (amino acids) to be searched. Hardware accelerated protein matching could be used for efficiently searching large protein databases (for example, the TIGR Microbial Database), and could also be adapted to DNA sequence matching, given that a DNA sequence uses only four types of amino acids. Whether for string or protein matching, and even network intrusion detection, the general area of hardware accelerated pattern matching is related to the checker generators used in assertion-based verifications through sequences.

Table 8.5 Hardware protein matching automata generated by MBAC. # Edges Site #

Protein

ΣS

ΣP

# States

PS00007: PS00112: PS00259: PS00328: PS00354: PS00831: PS01088:

[RK]–x(2)–[DE]–x(3)–Y C–P–x(0,1)–[ST]–N–[ILV]–G–T Y–x(0,1)–[GD]–[WH]–M–[DR]–F H–R–H–R–G–H–x(2)–[DE](7) [AT]–x(1,2)–[RK](2)–[GP]–R–G–R–P–[RK]–x G–x–[LIVM](2)–x–R–Q–R–G–x(5)–G [LIVM](2)–x–R–L–[DE]–x(4)–R–L–E

9 10 9 16 14 16 14

60 768 352 152 576 192 320

9 9 8 16 13 16 14

8.4 Pre-synthesis Results

193

8.4.2 Complex Sequences For high performance applications, the technique used in the previous subsection to create a hardware circuit for pattern matching would represent a first step, and could be improved by such measures as pipelining and further parallelism. Handling more than one character per clock is a common solution to improve throughput. The previous experiment nonetheless shows the scope of how assertions and a checker generator can be used to create other kinds of hardware, not only checker hardware for assertion verification. In this section complex sequences are evaluated, and the effect of symbol alphabet choice is compared. As observed in Table 8.2 in the previous section, typical assertions such as most of the assertions used for verifying bus protocols span few clock cycles and do not showcase the full strength the checker generator because they are easily handled. In the remainder of this chapter, synthetic assertions designed to benchmark complex sequences and properties are employed. Because the Boolean layer does not add to the temporal complexity of assertion automata, without loss of generality the Boolean layer is abstracted away using simple signal names a, b, etc. As assertions become more popular and verification engineers become more adept at writing them, checker generators must be able to handle all language features and scale efficiently for temporally complex assertions. Table 8.6 shows a set of test assertions used to evaluate the pre-synthesis metrics of the checkers produced by the MBAC and FoCs tools. The automata metrics for this set of properties, as implemented in RTL code, are presented in Table 8.7. The number of states is inferred by looking at the width of the register vector used to

Table 8.6 Pre-synthesis benchmarking properties. Assertion “assert Px;”, where Px is: P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 P17 P18

never {{a[∗0:1] ; b[∗0:2]} : {c[∗0:1] ; d}} never {{a[∗] ; b[∗1:3]} | {c ; d[∗1:2] ; e}} never {{a[∗]} : {b[∗]}} never {{a | b} ; {{c[∗]} && {d[∗1:3]}} : {e}} never {{a ; b[∗]} : {c[∗] ; d} ; e} never {{{b ; c[∗2:4] ; d}[+]} && {b ; {e[–>2:4]} ; d}} never {{a ; b[∗1:3] ; c[∗0:1]} & {d[∗2:4] ; e[–>]}} never {{a[∗0:1] ; b[∗1:2] ; c[∗]} : {d[∗0:1] ; e[∗2:4]}} never {{a ; b[∗] ; c[∗]} : {d[∗] ; e[∗]} ; f[∗]} never {{a ; b[∗] ; c[∗]} : {d[∗] ; e[∗2:4]} ; f[–>]} never {{a[∗] ; b[∗] ; c[∗]} && {d[∗5:7]}} never {{{a[∗] ; b[∗] ; c[∗]} && {d[∗5:7]}} : {c[–>]}} always {a} |=> {{{c[∗1:3] ; d}[+]} && {{e[–>2:3]} ; d}} always {a} |=> {{{b ; c[∗1:2] ; d}[+]} : {{e[–>]} ; d}} always {a} |=> {{{b ; c[∗1:2] ; d}[+]} : {b ; {e[–>2:3]} ; d}} always {a} |=> {b ; {{c[∗0:2]} ; {d[∗0:2]}}[∗] ; e} always {a} |=> {b ; {c ; d}[∗] ; e ; {f ; b}[+] ; g} always {a} |=> {{b ; c[∗]} : {d[∗] ; e} ; f}

194

8 Evaluating and Verifying PSL Assertion Checkers

Table 8.7 Pre-synthesis benchmark results for checkers generated by MBAC and FoCs (N.O. = No Output). — MBAC — Assertion P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 P17 P18

FoCs

Edges ΣS

Edges ΣP

States

States

6 7 3 7 10 68 26 19 27 33 28 33 90 114 221 7 32 42

40 64 7 50 144 324 320 112 656 800 124 140 296 624 760 96 1,216 480

3 5 2 5 5 27 11 7 6 9 14 15 21 23 66 4 11 10

19 16 6 10 12 98 74 101 69 44 109 736 N.O. N.O. N.O. 8 15 18

encode a given automaton in Verilog. In the other sections in this chapter, hardware metrics are compared after each checker is synthesized for FPGA technology. In this section, results are presented that more closely relate the size of the automata that are actually generated, before any hardware synthesis optimizations. The number of edges using both alphabet approaches in MBAC is shown in the second and third columns. As can be observed, the symbolic alphabet produces a much simpler automaton. In both cases the number of states is identical, as reported in the fourth column. The number of states is reported for the FoCs checker generator in the last column. As stated in the literature, FoCs is also automatabased [60, 104]. A comparison to FoCs was not attempted for the number of edges, given that their automata-to-RTL encoding is not documented, and inaccurate data could be inferred. From the results, it can be observed that the automata produced by MBAC are more compact than those produced by FoCs, and in some cases by more than an order of magnitude. For test cases P13 to P15, no output was produced by FoCs. The actual run times required to compile the assertions are also interesting to compare. To compile the most demanding case fifty times (P13 in the table), FoCs requires approximately 22 seconds, while MBAC requires less than 1/8 of a second. An intermediate test case is P12, where FoCs requires approximately 2 seconds and MBAC takes less than 1/10 of a second (the assertion is also compiled fifty times). These results were obtained on a 2.4 GHz Pentium 4 with 512 MB RAM.

8.5 Benchmarking Debug Enhancements

195

8.5 Benchmarking Debug Enhancements The effects of assertion threading, assertion completion and activity monitors are explored in this section by synthesizing the assertion circuits produced by the checker generator. The signal-dependency logging that was presented in Subsection 7.4.1 does not influence the circuits generated by the checker generator, while the assertion and coverage counters from Subsection 7.4.4 contribute a hardware overhead that is easily determined a priori (i.e. n-bit counter with saturation logic). Some of the assertions used in this section are from books by Cohen et al. [52] and Foster et al. [75], while others were created during the development of MBAC to exercise the checker generator as thoroughly as possible. In the AMBA, PCI and CPU example assertions appearing in the tables in this section, complex Boolean layer expressions are replaced by simplified Boolean symbols (indicated with “” in the table). Synthesizing the full expressions does not change the temporal complexity of the automata because the Boolean layer expressions are not incorporated directly into assertion automata, but rather instantiated separately in HDL, where a result signal is used. Synthesizing assertions with simple Boolean expressions actually emphasizes the logic required for capturing the temporal structure of an assertion, and is the preferred method. Table 8.8 shows a set of test assertions used to benchmark the debugging enhancements that were introduced in Section 7.4. The assertion checkers are synthesized in the normal operating mode of the checker generator; these results are shown in the first column of triples in the top half of Table 8.9. As described in Subsection 7.4.3, assertions can alternately be compiled in completion mode as opposed to the normal failure mode. Synthesis results for the completion mode checkers are shown in the second group of triples in the top half of Table 8.9. From the table, it can be observed that a completion-mode assertion Table 8.8 Test assertions for debugging enhancements ( = Simplified Booleans). Assertion A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15

assert always {a&b} |–> {∼c; {d&∼c}[*0:4]; c&∼d}; assert always ({a} |=> {{c[*0:1];d}|{e}}); assert always ({a;b} |=> {c[*0:1];d}); assert always {a} |=> {{[*2];b;∼c} | {[*2];∼b;c}}; (Example 7.4)  assert always {a} |=> {b;c;d;e}; (AMBA asr. [52])  assert always {a;∼a} |=> {(∼a)[*0:15];a} abort b; (AMBA asr. [52])  assert always {a;b} |=> {c;{{d[*];e}[+];f}&&{g[*]}} abort h; (PCI [75])  assert always {a} |=> {e;d;{b;e}[*2:4];c;d}; assert always {a} |=> {b; {c[*0:2]} | {d[*0:2]} ; e}; assert always {a} |=> {{{c[*1:2];d}[+]} && {{e[–>2:3]};d}}; assert always {a} |=> {{{b;c[*1:2];d}[+]} & {b;{e[–>2:3]};d}}; assert always {a} |=> {{{b;c[*1:2];d}[+]} && {b;{e[–>2:3]};d}}; assert never {a;d;{b;a}[*2:4];c;d}; assert never { {{b;c[*1:2];d}[+]} && {b;{e[–>2:3]};d} }; assert always {a} |=> {{{b;c[*1:2];d}[+]} : {b;{e[–>]};d}};

196

8 Evaluating and Verifying PSL Assertion Checkers

Table 8.9 Resource usage of checkers with debugging enhancements. Normal

Completion

Activity

Assertion

FF LUT MHz

FF LUT MHz

FF LUT MHz

A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15

6 3 4 6 5 18 5 15 7 16 44 35 12 12 26

6 3 4 6 5 18 5 15 7 16 44 35 0 0 26

6 11 3 4 4 5 6 5 5 6 18 23 5 12 15 26 7 14 17 40 44 150 35 128 12 15 13 17 27 87

8 3 3 3 5 17 10 21 12 38 141 118 11 12 80

433 610 611 564 514 611 468 329 333 304 260 251 559 456 246

7 2 3 3 4 17 7 15 8 31 139 100 0 0 79

444 610 553 564 611 502 470 430 412 386 250 281 N.A. N.A. 250

429 610 564 559 509 564 411 312 331 293 259 243 559 452 249

Assertion Threading

A1 A4 A5 A6 A7 A8 A12 A13 A14 A15

2-way

4-way

8-way

FF LUT MHz

FF LUT MHz

FF LUT MHz

15 15 13 39 13 33 73 25 29 57

18 11 16 38 23 44 235 23 35 165

386 442 323 442 297 298 239 564 410 252

29 33 29 20 25 24 77 75 25 39 65 83 145 430 49 46 57 70 113 301

306 362 326 364 287 252 213 433 410 205

57 62 241 not required not required 153 144 297 49 67 235 129 164 235 289 900 186 97 91 408 113 139 408 225 570 177

utilizes slightly less combinational logic (LUTs), and on average runs slightly faster than its normal-mode version (i.e. regular failure matching). Test assertions A13 and A14 have assertion signals that are hardwired to logic-0 in their respective checkers given that no obligations are placed on Booleans in those types of properties (assert never seq), as discussed in Subsection 7.4.3. This explains why such checkers do not require any circuit primitives in the checkers. The activity monitors introduced in Subsection 7.4.2 are used to observe when sequences are undertaking a matching. The third set of triples in the top half of Table 8.9 shows the hardware metrics of the checkers with activity monitors, for the example assertions. Unless specified, the default mode is not completion mode but rather the typical failure mode. Experiments could also be performed for the combination of activity monitors with completion mode. As can be noticed in the table, the maximum operating frequency is slightly diminished compared to the normal checkers, and in some cases, an additional flip-flop is required. The effect of the

8.5 Benchmarking Debug Enhancements

197

OR-gate appearing in the state-signal disjunction that is used to form the activity signal is visible in the slight increase in the LUT metric. The checkers produced in the assertion threading experiments, that are reported in the bottom half of the table, were formally verified by model checking and were proven to be equivalent to their normal counterparts in the top-left column in the table. All equivalence verifications succeeded with the exceptions of the eight-way threading of A8, the four-way and eight-way threading of A15 and all versions of A12, which exceeded the maximum memory capacity of the model checking setup. However, in these exceptions, no counterexample was produced during the run time of the tool. The verification performed here shows that threading preserves the intended functionality of the checker circuit, while increasing the observability in the checking process. The equivalence check also confirms that the dispatcher circuit and the overall threading strategy is correct, on the examples tested. As presented in Subsection 7.4.5, assertion threading replicates sequence circuits in order for the failure conditions to be isolated from other activations. This was shown to ease the debugging process considerably, particularly when temporally complex assertions are used. The lower half of Table 8.9 shows how the resource utilization scales as a function of the number of hardware threads. Because 8-way threading is only useful for sequences that span at least eight clock cycles, the assertions used must have a certain amount of temporal complexity for the results to be meaningful. Since the assertion derived from Example 7.4 in A4 and the AMBA assertion in A5 both contain simple left-sides for the suffix implication, along with right-side sequences that span four clock cycles, these assertions do not benefit from 8-way assertion threading. In the current version of the checker generator, when a sequence is a simple sequence such as {a}, it is still threaded even though doing this is useless. The threading results in the table could be improved if this was detected, and such simple sequences were not threaded. As anticipated, the experimental data shows that the resource utilization scales linearly with the number of hardware threads. Test case A7 corresponds to the PCI ASR test case from Section 8.2 with simple Booleans. The full assertion was shown to require 9 FFs and 20 LUTs, as opposed to 5 FFs and 10 LUTs in Table 8.9. The full PCI assertion exhibits particularly large overhead compared to the simplified one, as some intermediate variables are sequential (e.g., cbe stable). The 4-way threaded assertion circuit as used in the CPU execution example (Example 7.4) with non-simplified Boolean expressions actually synthesizes to 29 FFs and 21 LUTs, with a maximum frequency of 362 MHz. This corresponds to virtually the same metrics as the simplified version used in test case A4. The non-threaded checker for this test case required only one less LUT, compared to the non-simplified version in Section 8.2. Test cases A5 and A6 are based on the MemSlave ASR and AHB ASR test cases from Section 8.2, with simplified Booleans. In the simplified cases, the number of LUTs was reduced from 16 to 5 for the MemSlave ASR checker and remained identical for the AHB ASR checker.

198

8 Evaluating and Verifying PSL Assertion Checkers

8.6 Benchmarking Sequences and Properties In this section the two eventually! approaches, namely the rewrite rule and the automata splitting technique, are compared. The assertion circuits produced by the MBAC checker generator are also compared to those produced by FoCs for complex sequences and properties. In the experiments, simple Boolean expressions are used because the emphasis is placed on the temporal behavior of the checkers. Ideally, the assertion circuits that are produced should be small, fast, should support all simple subset operators and should exhibit the correct behavior.

8.6.1 Comparison of the Two eventually! Approaches Table 8.10 shows the advantages of the split-automata method in the implementation of eventually!, as presented in Section 7.3, compared to the rewrite rule presented in Section 7.3. The split-automata method scales much better because an occurrence-matching automaton can be employed as opposed to a failure-matching automaton, which can be exponentially larger given the required strong determinization. In the test cases, the split-automata method produces faster circuits, and except for a few small examples, requires less hardware. In all eleven test cases, functional equivalence of the checkers was formally verified by model checking. These examples show that in general not all sequential optimizations can be performed by traditional synthesis tools, and efforts to optimize the checkers pre-synthesis should always be made.

Table 8.10 Benchmarking implementations of eventually!. Property (F ≡ eventually!, G ≡ always) eventually! {b;c;d} eventually! {a;b;c;d;e} always (a –> eventually! {b;c;d}) G (a –> eventually! {a;b;c;d;e}) G (a –> eventually! {b[*5:10]}) G (a –> F {b; {c[*0:2]} | {d[*0:2]} ; e}) G (a –> F { {{c[*1:2];d}[+]} | {e[–>2]} }) G (a –> F {{{c[*1:2];d}[+]}:{{e[–>]};d}}) G (a –> F {{{c;d}[*]}&&{∼e[*];e;∼e[*]}}) G ({a;b[*0:2];c} |–> F {d;e[*1:3];f}) G (a –> F { {{b;c[*1:2];d}[+]} && {b;{e[–>2:3]};d} }

Splitting

Rewrite

FF LUT MHz

FF LUT MHz

4 6 4 6 6 6 6 6 4 9 17

5 17 5 17 6 7 5 5 4 10 68

4 6 4 5 6 8 8 7 5 9 27

559 559 559 564 559 444 434 417 474 473 395

11 52 10 44 5 20 9 7 7 17 245

388 237 395 236 548 329 392 395 465 309 207

8.6 Benchmarking Sequences and Properties

199

8.6.2 Occurrence-Matching Sequences The FoCs and MBAC checker generators are evaluated with the set of assertions shown in Table 8.11, and the results appear in Table 8.12. These results illustrate the efficiency of the implementation of occurrence-matching SEREs, with partial emphasis on intersection and fusion operators. In all cases, the circuits produced by MBAC are smaller or equal in size, and in all but three cases have an equal or higher operating frequency. For test cases S15, S16 and S18, the FoCs and MBAC checkers do not have the same behavior. The counterexamples reported by the model checker show that immediately upon releasing the reset, when the sequences CE2 : { !reset ; b ∧ d } CE3 : { !reset ; b ∧ e ; e } CE4 : { !reset ; a ∧ d ; d ; d ; d ; c ∧ d } execute (signals not listed are assumed false), the assertion signals from FoCs fail to report the error. In these cases, the sequences exhibit a violation of the respective properties, and must be detected as such by the assertion checker circuits. The reset signal is active low and is declared as an input to the checkers generated by both tools. As shown in Proposition 6.5 for verification directives, constructing a checker for the cover directive involves a rewrite rule using the eventually! operator. In Section 7.3, a more efficient checker construction was developed to avoid the determinization step implied by the rewrite rule in (6.27), given its usage of a sequence Table 8.11 Occurrence-matching test sequences. Assertions “assert never Sx;”, where Sx is S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17 S18

{ {a[∗];b[∗1:3]} | {c;d[∗1:2];e} } { a;d;{b;a}[∗2:4];c;d } { {a;[∗];b} && {c[∗1:5];d} } { {a|b};{{c[∗]} && {d[∗1:3]}}:{e} } { {a|b};{{c[∗]} && {d[∗1:6]}}:{e} } { a ; {b ; c}[∗] ; d ; {e ; a}[+] ; f } { {e;e} within {c;d;a;b;c} } { {a;b[∗1:3]} & {c[∗2:4]} } { {a;b[∗1:3];c[∗0:1]} & {d[∗2:4];e[–>]} } { {{b;c[∗1:2];d}[+]} && {b;{e[–>2:3]};d} } { {{b;c[∗2:4];d}[+]} && {b;{e[–>2:4]};d} } { {a ; b[∗]} : {c[∗] ; d} ; e } { {a ; b[∗] ; c[∗]} : {d[∗] ; e[∗]} ; f[∗] } { {a ; b[∗] ; c[∗]} : {d[∗] ; e[∗2:4]} ; f[–>] } { {a[∗0:1];b[∗0:2]} : {c[∗0:1];d} } { {a[∗0:1];b[∗1:2];c[∗]} : {d[∗0:1];e[∗2:4]} } { {a[∗];b[∗];c[∗]} && {d[∗5:7]} } { {{a[∗];b[∗];c[∗]} && {d[∗5:7]}} : {c[–>]} }

200

8 Evaluating and Verifying PSL Assertion Checkers

Table 8.12 Benchmarking of occurrence-matching sequences. Hardware metrics

Equivalence check MBAC ↔ FoCs

MBAC

FoCs

Sx

FF LUT MHz

FF LUT MHz

S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17 S18

4 12 6 4 7 6 11 5 10 12 20 4 5 8 2 6 13 14

4 12 6 4 7 6 11 6 10 14 32 5 32 26 6 38 19 65

3 11 6 3 6 6 10 6 16 12 21 5 7 15 2 7 15 16

564 559 667 665 665 564 564 504 325 456 456 418 352 338 665 392 506 445

3 11 6 4 8 6 10 10 21 16 39 6 56 32 7 43 33 127

564 564 559 610 444 564 564 332 331 429 383 469 261 332 395 340 412 257

Pass Pass Pass Pass Pass Pass Pass Pass Pass Pass Pass Pass Pass Pass Fail → CE2 FoCs Fail → CE3 FoCs Pass Fail → CE4 FoCs

directly as a property (F IRST FAIL () algorithm required). Therefore, benchmarking of the cover operator using the occurrence matching sequences in Table 8.11 should reveal coverage checkers that are very similar in size to the related assertion checkers in Table 8.12. These cases are benchmarked and the synthesis results are shown in Table 8.13. The results show that in all but one case, the coverage checkers require one additional flip-flop compared to the related assertion checker. In the S13 case two additional flip-flops are required. On average, the combinational logic required in the case of the coverage checkers is slightly larger then the regular assertion checkers. This can be explained by the additional states and circuits added around the occurrence matching automaton in the efficient eventually! implementation, as observed in Figure 7.2. The cover directive was implemented by rewriting with the eventually! operator in Section 6.5.

8.6.3 Failure-Matching Sequences Both tools are evaluated using sequences that require failure matching, using the assertions shown in Table 8.14. Synthesis results are presented in Table 8.15. In the comparison table, “No Output” denotes the cases when FoCs was not able to generate checkers for given assertions and no code was produced (5 of 18 cases). In more than half of the test cases, large differences in checker behavior were observed between both tools. In such cases the confidence in the correctness of the

8.6 Benchmarking Sequences and Properties

201

Table 8.13 Benchmarking PSL’s coverage verification directive. Sequence. “cover Sx;”, where Sx is S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17 S18

{ {a[∗];b[∗1:3]} | {c;d[∗1:2];e} } { a;d;{b;a}[∗2:4];c;d } { {a;[∗];b} && {c[∗1:5];d} } { {a|b};{{c[∗]} && {d[∗1:3]}}:{e} } { {a|b};{{c[∗]} && {d[∗1:6]}}:{e} } { a ; {b ; c}[∗] ; d ; {e ; a}[+] ; f } { {e;e} within {c;d;a;b;c} } { {a;b[∗1:3]} & {c[∗2:4]} } { {a;b[∗1:3];c[∗0:1]} & {d[∗2:4];e[–>]} } { {{b;c[∗1:2];d}[+]} && {b;{e[–>2:3]};d} } { {{b;c[∗2:4];d}[+]} && {b;{e[–>2:4]};d} } { {a ; b[∗]} : {c[∗] ; d} ; e } { {a ; b[∗] ; c[∗]} : {d[∗] ; e[∗]} ; f[∗] } { {a ; b[∗] ; c[∗]} : {d[∗] ; e[∗2:4]} ; f[–>] } { {a[∗0:1];b[∗0:2]} : {c[∗0:1];d} } { {a[∗0:1];b[∗1:2];c[∗]} : {d[∗0:1];e[∗2:4]} } { {a[∗];b[∗];c[∗]} && {d[∗5:7]} } { {{a[∗];b[∗];c[∗]} && {d[∗5:7]}} : {c[–>]} }

FF LUT MHz 5 13 7 5 8 7 12 6 11 13 21 5 7 9 3 7 14 15

4 12 7 4 7 7 11 7 18 13 22 6 10 16 3 8 16 17

522 522 562 561 561 522 561 417 287 456 456 418 354 338 561 392 443 396

Table 8.14 Failure-matching test sequences. Assertions “assert always {a} |=> Sx;”, where Sx is S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17 S18

{ b;c[∗];d } { {b;c;d} & {e;d;b} } { e;d;{b;e}[∗2:4];c;d } { b ; {c[∗0:4]} & {d} ; e } { b ; {c[∗0:6]} & {d} ; e } { {{c;d}[+]} && {e[–>2]} } { {{c;d}[+]} && {e[–>4]} } { {{c;d}[+]} && {e[–>6]} } { {{c[∗1:2]}[+]} && {e[–>2]} } { {{c[∗1:2];d}[+]} && {e[–>2]} } { {{c[∗1:3];d}[+]} && {{e[–>2:3]};d} } { {{b;c[∗1:2];d}[+]} : {{e[–>]};d} } { {{b;c[∗1:2];d}[+]} : {b;{e[–>2:3]};d} } { b ; {{c[∗0:2]} ; {d[∗0:2]}}[∗] ; e } { {{c[∗1:2];d}[+]} & {e[–>2]} } { {e;e} within {c;d;a;b;c} } { b ; {c ; d}[*] ; e ; {f ; b}[+] ; g } { {b ; c[*]} : {d[*] ; e} ; f }

MBAC checkers is further increased by comparing checker outputs in simulation to ModelSim’s interpretation of PSL. The trace distance is introduced to compare the behavior of two assertion-circuit outputs. For two given traces of assertion signals, the trace distance is defined as

202

8 Evaluating and Verifying PSL Assertion Checkers

Table 8.15 Benchmarking of failure-matching sequences (M.C. = proven equivalent in Model Checking). Hardware metrics MBAC

FoCs

Sx

FF LUT MHz

FF LUT MHz

S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17 S18

3 4 15 7 9 5 9 13 3 9 20 22 65 3 4 12 10 9

3 4 15 7 9 6 10 14 4

4 5 21 9 13 6 13 18 3 22 52 59 222 4 4 16 22 17

514 445 329 441 395 509 326 324 564 311 278 259 250 610 472 386 314 280

3 610 8 393 22 292 10 333 15 283 8 395 14 325 19 324 4 429 No output No output No output No output 7 12 331 No output 17 26 302 14 33 281 17 44 258

Assertion distances MBAC– FoCs

MBAC– MSim

3272 0 (M.C.) 0 (M.C.) 3973 3973 0 (M.C.) 0 (M.C.) 0 (M.C.) 0 (M.C.) – – – – 26 – 236 0 (M.C.) 0 (M.C.)

0 0 0 0 0 0 0 0 0 0 209 0 0 0 r2061 0 270 0 0

the number of clock cycles in which the two signals disagree. The comparison is done at the rising edge of the clock. The assertion signals in question are typically from two different implementations of the same PSL assertion. The discrepancies between MBAC and ModelSim are shown in the right-most column, by measuring the number of cycles in the assertion output traces for which the two differ. For the software metrics to be meaningful, the assertions are made to trigger often during a simulation run. To accomplish this, primary signals supplied by the testbench are pseudo-randomly generated with different probabilities. Regarding the semantics of PSL in dynamic verification, it should be noted that some assertions interpreted by simulators such as ModelSim will only trigger once for any given start condition. For example, in the following assertion, assert never {a;b[*0:1]}; for a given cycle in which a is asserted, the assertion will trigger. However, if the cycle that follows a has b asserted, the assertion will not trigger. This is perfectly acceptable given that the run-time semantics of PSL is not specified. If an assertion fails at one or more time points, it has failed globally. One possible reason for ModelSim’s behavior is that in the simulation kernel, the threads which monitor assertions are kept as short as possible for performance reasons. In hardware this is not a concern; in MBAC the assertion triggers when “a” is observed, and when

8.6 Benchmarking Sequences and Properties

203

“a;b” is observed. Because of this difference, measuring distances between MBAC and ModelSim is more involved. Between MBAC’s assertion circuits and ModelSim, the distance is not incremented when an assertion circuit output triggers and ModelSim’s assertion does not. When such a condition occurs, a residual distance is instead incremented. Residual distances are an indication that MBAC is reporting more failures, which can then be exploited for debugging purposes. Residual distances are noted “r n”. When applicable, the residual distance is well anticipated because of the multiple paths in the corresponding sequence. In all cases, 105 pseudorandom test vectors are supplied by the testbench. The random stimulus comparison to ModelSim is obviously not a proof that the circuits generated by MBAC are correct, however it does offer reasonable assurance given the length of test sequences. The eight test cases with a distance of zero to FoCs were formally verified in model checking and are equivalent to FoCs’ checkers. The two cases of non-zero distances to ModelSim (S11 and S16) occur because MBAC’s circuits are able to identify certain failures earlier than ModelSim. This arises when the automata are able to reach a final state earlier when evaluating a given sequence. The strength of the checker generator becomes apparent when increasing the complexity of sequences. The dual-level symbol tables, and the particularities in the minimization function pertaining to true edges and nondeterminism are the driving factors behind the efficient checkers produced by the tool. In all experiments, checkers are generated instantly by MBAC.

8.6.4 Properties The assertion circuits produced by the MBAC checker generator are also evaluated using various test cases involving a variety of property operators. The FoCs and MBAC checker generators are compared using the set of assertions shown in Table 8.16, and the synthesis results are reported in Table 8.17. Properties P18 and P20-P24 are from a TIMA publication [23]. For cases P1 to P12 and P16, no synthesis results are given because the properties are not supported by FoCs. Property P14 seems to have exceeded the internal limits in FoCs and no output was produced. With the exception of P13, when FoCs is able to produce a checker both tools produce functionally equivalent checkers. Functional equivalence was formally verified using model checking. Test cases P20 and P24 exceeded the maximum memory capacity of the model checking setup, and were compared in simulation instead. The FoCs checkers for those two cases have 309 and 175 state elements respectively in the HDL code, versus 27 and 9 respectively in MBAC’s checkers. Test cases P20 and P24 were compared using a testbench of 105 biased pseudorandom test vectors. For each assertion, the circuits produced by both tools exhibit the same behavior on every clock cycle. In biased random vector generation, signal

204

8 Evaluating and Verifying PSL Assertion Checkers

Table 8.16 Benchmarking of properties. Property (“assert Px;”, where Px is:) P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 P17 P18 P19 P20 P21 P22 P23 P24

always ({a;d} |–> next e[2:4](b)) until c always ({a;b} |–> eventually! {c;d}) abort e always {a;b[*0:2];c} |=> ({d[*2]} |–> next ∼e) always (a –> ( (eventually! b[*5]) abort c) ) abort d always ( (a –> (b before c)) && (c –> eventually! {b;d}) ) abort e always {a;b;c} |=> never {d[*0:3];e} always a –> next a always (a –> {[*0:7];b}) abort ∼c always a –> next e always a –> next event e!(b)[2:4](c) always a –> ({b;c} until! d) always a –> next event a!(b)[5:10](c) always a –> (b until! c) always {a} |–> {{b;c[*]}:{d[*];e;f}} never {a;[*];{b;c}[+]} always (e || (a –> ({b;c} until d))) always a –> (b before! c) always (a –> next event e(b)[1:6](c)) always a –> eventually! b always (a –> next (next a[2:10](next event(b)[10]((next e[1:5](d)) until (c))))) always ((a –> next(next[10](next event(b)((next e[1:5](d)) until (c))))) || e) (always (a –> next(next[10](next event(b)((next e[1:5](d)) until (c)))))) && (always (e –> (next event a(f)[1:4](next((g before h) until (i)))))) always (a –> (next event a(b)[1:4](next((d before e) until (c))))) always (a –> (next event(c)((next event e(d)[2:5](e)) until (b))))

Table 8.17 Benchmarking of properties (P1–P12 are not supported by FoCs yet). MBAC

MBAC

FoCs FF LUT MHz

Px

FF LUT MHz

Px

FF LUT MHz

P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12

6 4 7 6 4 7 5 8 5 5 3 11

P13 P14 P15 P16 P17 P18 P19 P20 P21 P22 P23 P24

2 8 3 3 2 7 2 26 17 23 7 8

5 6 6 9 7 7 2 8 4 6 4 7

611 470 611 460 473 419 445 667 433 456 505 326

3 23 2 5 3 8 2 10 7 11 5 11

612 295 611 469 610 445 564 375 564 513 552 439

3

4 474 No output 4 3 564 Not supported yet 3 4 474 12 12 564 2 2 564 200 106 299 23 13 564 46 43 312 24 24 311 40 40 408

probabilities are adjusted in order for the assertions to trigger reasonably often. This method is not a proof that the circuits are functionally equivalent; however,

8.6 Benchmarking Sequences and Properties

205

combined with the fact that model checking produced no counterexample before reaching its limit, this does offer reasonable assurance. For test case P13, slight differences in behavior were noticed due to the unspecified run-time semantics of “p until b”, where it is up to the tool’s architect to decide whether to flag all failures of p before b occurs, or to flag only the first one. This flexibility is expected in dynamic verification with PSL, and may occur with other operators. With test cases P17 and P19, the behavior of the checkers is identical between both tools, and only a slight difference occurs when the End-Of-Execution (EOE) signal activates. This was circumvented by using a monostable flip-flop on the assertion outputs such that when the assertion triggers, the output remains in the triggered state. The monostable FF was used because the semantics of the checkers does not have to be defined after the EOE occurs. In all test cases where FoCs is able to produce a checker, the circuits produced by MBAC are more resource-efficient than those produced by FoCs. A subset of the test cases contained in Section 8.6 was also evaluated with another synthesis tool for added confidence in the results. Test cases with the greatest differences in metrics between the MBAC and FoCs circuits were selected. The test cases in question are: • The 2nd, 4th, and 11th (last) assertion in Table 8.10 (comparison of the two eventually! approaches) • S11, S13, S14 and S17 in Table 8.11 (occurrence-matching sequences) • S14, S16, S17 and S18 in Table 8.14 (failure-matching sequences) • P18 and P20 to P24 in Table 8.16 (properties) The checkers for the assertions mentioned above were further synthesized using Altera QuartusII, for a StratixII EP2S15F672C3 FPGA. Because the Xilinx and Altera technologies differ, the number of LUTs is not directly comparable; however, qualitatively the results are coherent with the Xilinx metrics. The number of flipflops is directly comparable and in all but two cases was identical in both the Altera and Xilinx experiments. For FoCs’ checkers, test cases S13 and S14 in Table 8.11 synthesize to 15 and 25 FFs respectively in the Altera synthesis tool, compared to 32 and 26 FFs in the Xilinx tool. In both cases though, the checkers produced by MBAC are still three times smaller.

Chapter 9

Checkers for SystemVerilog Assertions

Abstract This chapter presents an economical implementation of SystemVerilog Assertion checkers within the same checker generator framework as the PSL checker generator. The emphasis is placed on finding a way to reuse the basic techniques applied for PSL in previous chapters, but some new techniques and tradeoffs are presented as well. Finally, demonstrated is an application of SVA checkers in formal verification by generic tools that are agnostic to SVA.

9.1 Introduction and Overview In this chapter, we develop the techniques for the generation of SVA checkers. This is a relatively self-contained chapter containing the automata construction methods for the checkers, and experimental results. Automata algorithms developed for PSL are employed in the SVA checker synthesis whenever possible. Since many references to PSL checker generation are made, knowledge of the techniques presented in the PSL chapters is recommended. As with Chapter 6, the goal here is to construct automata for representing the assertion checkers. Subsequently, forming the actual circuit for the checker requires the automaton-to-circuit conversion developed in Chapter 5.

9.2 Checker Generation for SystemVerilog Assertions In Section 4.2 we introduced the SystemVerilog assertion language, in a fashion similar to that of PSL’s presentation in Section 4.1. The automata implementation of SV assertions is now introduced, in a manner that reuses much of the PSL automata constructions in Chapter 6. The presentation begins with Booleans, then treats the cases of SVA sequences and properties, and ends with SVA verification statements. 207

208

9 Checkers for SystemVerilog Assertions

Although the emphasis in this section is the conversion of SVA statements into assertion automata, the subsequent conversion to a circuit form is accomplished using the same technique as for the PSL checkers, namely by employing the automatato-circuit procedure described in Section 5.3. Once converted to automata, SVA checkers are produced similarly to PSL checkers. The notation developed in the PSL chapters is also utilized herein. The symbol A again represents an automaton conforming to Definition 5.3. When used in functional form, A () is used to denote the creation of an automaton from an argument expression. Superscripts are used to describe the type of automaton creation that is desired, where B , S , P and V represent Booleans, sequences, properties, and verification statements respectively. The expression H () is used to describe the creation of HDL code from an argument, which can be an SVA Boolean expression or an automaton A . When the argument is an automaton, the procedure in Section 5.3 is implied, whereas all other forms should now reference the SVA topics contained in this chapter. For example, when the expression A S () is encountered, it references the conversion of SVA sequences to automata described in Subsection 9.2.2, as opposed to the conversion of PSL sequences from Section 6.3. The next four subsections show how to construct automata for SVA Booleans, sequences, properties and verification statements, in this order.

9.2.1 Automata Construction for Booleans Similar to assertion languages belonging to standard programming language definitions, SV assertions reference a set of Boolean expressions appearing in the source SystemVerilog design – they are a part of the language, unlike with PSL. In fact, because of this philosophy of assertion inclusion, SystemVerilog employs two types of assertions: • Immediate assertions • Concurrent assertions Immediate assertions employ simple Boolean operators, similar to the way assertions are used in traditional programming languages. The assertions of interest to us are of the concurrent type. As will be seen, the Booleans declared in the design’s source code are used to construct temporal sequences and properties to adequately model a correctness requirement. The goal of this subsection is two-fold. First, the conversion of SVA Booleans to HDL code is developed, and is denoted H (b), where b represents an SVA Boolean expression. Second, the creation of an automaton to represent a given Boolean is also required. This creation process is denoted as A B (b), and will be used as the basic case upon which automata for sequences are built. The construction of an automaton from a sequence, denoted by A S (s), is used in the derivation to follow (when describing the implementation of .ended in Proposition 9.1), but its detailed implementation will be presented in the next

9.2 Checker Generation for SystemVerilog Assertions

209

subsection. The conversion of an automaton to HDL code, denoted H (A ), was presented in Section 5.3. The verification statements for SVA (presented further) impose the specification of a clock signal for an assertion, and for now it is assumed that a clock string holds the name of the clock signal, for a given statement. The conversion of SVA Booleans to HDL is presented in Proposition 9.1, in a manner that resembles the syntax from Definition 4.8 as closely as possible, such that the link between syntax and implementation can be better observed. In the explanation to follow, non-italicized prefixes separated by an underscore represent an additional type constraint, and do not represent a new type as such. Proposition 9.1. If b is a Boolean, i is a nonnegative integer, e is an Expression, f is a system function and s is a Sequence then the HDL conversion of SVA Booleans defined in Definition 4.8 is denoted H (b), and is performed as follows: H (b) : • H (boolean e) = [defined in next line] H (e) : • H (SystemVerilog e) = e • H (true) = 1’b1 • H (false) = 1’b0 • H ( f ) = [defined below] • H (s.ended) = H (A S (true[*1:$] ##0 s)) H (f) : • H ($past(e)) = D FF(e) • H ($past(e, i)) = D FFi (e) • H ($rose(e)) = (∼D FF(lsb e) & lsb e) • H ($fell(e)) = (D FF(lsb e) & ∼lsb e) • H ($onehot(e)) = ( ((e-1) & e) == 0 ) • H ($onehot0(e)) = ( H (onehot(e)) || (e ==0) ) • H ($stable(e)) = (D FF(e) == e) The items that have italicized comments in brackets do not actually need to be handled and are only kept to show the correspondence to Definition 4.8. Each item from Proposition 9.1 will be presented and explained next, immediately following its appearance. First, we have H (SystemVerilog e) = e In the case where a SystemVerilog expression is used as a Boolean, it is simply returned directly and no transformation is necessary. H (true) H (false)

= =

1’b1 1’b0

Symbols true and false are expressed in HDL as single digit binary constants. The treatment of system functions is described next.

210

9 Checkers for SystemVerilog Assertions

H ($past(e))

=

H ($past(e, i))

=

D FF(e) D FFi (e)

In any given clock cycle n, the $past operator evaluates to the value of the argument expression at cycle n − i. The implementation for this operator is denoted symbolically above using the D FFi (e) function, and in reality corresponds to the instantiation of a register chain (or pipeline) with i stages in depth. The clock expression of the given assertion is implicitly used as the clock signal for any flip-flop represented by the D FF() notation. The input of the flip-flop is the argument and the return value of D FF() represents the output of the flip-flop. Thus, the resulting expression of D FFi () evaluates to the signal or vector of the last register(s) in the chain. When the exponent is not specified, i = 1 is assumed. The register pipeline has the same width as the argument expression e. This register chain is created as actual HDL code using Verilog non-blocking assignments. For the case i = 0, no registers are created and the expression is returned directly. As with PSL’s built-in function, the flip-flops generated by D FFi (e) are not reset with the checker’s reset, and are used purely to create a clock cycle delay. It is up to the implementation to determine their initial state. H ($rose(e)) H ($fell(e)) H ($stable(e))

= = =

(∼D FF(lsb e) & lsb e) (D FF(lsb e) & ∼lsb e) (D FF(e) == e)

The above functions relate the value of an expression to the value in its previous clock cycle, and also use the HDL flip-flop declaration mentioned above. The $rose() and $fell() functions operate on the least significant bit of their argument expressions only, whereas bit vectors can be used in $stable(). In the right side of the first two rules above, the notation “lsb e” is used to represent the extraction of the least significant bit in the case where the expression e is a bit vector. It can be implemented as “e[lsb]”, where lsb is the bit index for the least significant bit of the argument expression, as determined from the parse tree of the source design during checker generation. H ($onehot( e)) H ($onehot0( e))

=

( ((e-1) & e) == 0 )

=

( H ($onehot(e)) || (e ==0) )

The implementation of the $onehot function takes advantage of the arithmetic operators that can be specified in languages such as Verilog. Detecting the cases where a single bit is active in a sequence of bits is performed with the “bit trick” technique involving decrementation and word-level intersection. The $onehot0 function also allows for all-zeros to occur, and is implemented using $onehot() with an additional Boolean expression. The last item from Proposition 6.1 to be explained is the .ended operator. H (s.ended)

=

H (A S (true[*1:$] ##0 s))

9.2 Checker Generation for SystemVerilog Assertions

211

The .ended operator is syntactically specified as a suffix to a sequence instance, and evaluates to logic-1 every time the argument sequence is matched. It is similar to PSL’s built-in function ended(), and is used to evaluate the endpoint(s) of an SVA sequence. The A S () notation describes the creation of an automaton, and in this case creates a pattern matcher for the given sequence. The sequence is extended by a fusion with a perpetually true left side (i.e. the true[*1:$]), thereby continually triggering its matching. This behavior was also modeled for PSL’s ended() operator by using the never property with the sequence s, as shown in (6.2). The construction of automata for SVA sequences appears in the next subsection, and must unavoidably be assumed at this point. As shown in the right side in the rule above, the H () operator is used to indicate that a HDL circuit is actually instantiated for the extended sequence, and the signal returned by the .ended operator is simply the signal indicating when the sequence is matched. It is this signal that is evaluated in an assertion, and is thus interpreted as a Boolean signal. It is precisely for this reason that system functions which should seemingly be part of sequences in SVA, are actually defined in Booleans. The flip-flops comprising the automaton for the .ended’s sequence s should be initially reset and not be externally reset afterwards; however, for simplicity in the checker generator they are actually reset when the checker is reset. The disable iff operator has no effect on the automaton of an .ended sequence, when used in a property. In general, aborts and resets should have no effect on the temporal logic of system functions. These functions are evaluated in a single clock cycle as seen from a SV assertion, even though the system function’s internal logic may span over several clock cycles. Example 6.1 given in the case of PSL built-in functions helps illustrate this point. In that example, a sequence was aborted (disable iff) by an external Boolean condition, while the sequence under the ended operator was not. The items contained in Proposition 9.1 show how any SVA Boolean can be expressed at the HDL level. Constructing an automaton for the matching of a Boolean, as required in SVA sequences and properties, is described next in Proposition 9.2. Proposition 9.2. If b is an SVA Boolean and H (b) represents the HDL expression for b, as presented in Proposition 9.1, then the construction of an automaton for Boolean b, denoted A B (b), is performed as follows: A B (b) : • A B (b) =

BASE C ASE(H (b))

An implicit consequence of the separate results in Propositions 9.1 and 9.2 is that automata are built only for top-level Booleans as opposed to building automata for arbitrary sub-expressions of a complex Boolean expression. The algorithm for creating an automaton for a Boolean’s HDL expression, called BASE C ASE(), is the same algorithm as used in the case of PSL Booleans, and appears in Algorithm 6.1 at the end of Section 6.2. That algorithm creates a simple two state automaton, with one start state and one final state, and with one transition labeled with a symbol corresponding to the top-level Boolean expression.

212

9 Checkers for SystemVerilog Assertions

9.2.2 Automata Construction for Sequences The recognition of an SVA sequence requires a conversion to an equivalent automaton, as shown here in an inductive manner. First, terminal automata are built for the Booleans in a sequence. Next, these automata are recursively combined according to the sequence operators comprising the given expression. Sequences are an important part of SVA properties, and will be used in the automata construction for properties in the next subsection. Automata for representing sequences are constructed using separate automata algorithms, or indirectly using rewrite rules. Although no distinction is made here as to what operators use derived rules and which are the base cases, as will be pointed out further, some of the rewrite rules are based on the derived forms in Appendix E of the SVA specification [107]. Automata for certain sequence operators are constructed with specialized algorithms, such as SVA’s cycle delay operator (##). In other cases, well-established algorithms from Chapter 6 are used, such as C HOICE(), C ONCATENATE(), and K LEENE C LOSURE(), to name a few. As in PSL, the symbolic alphabet also plays a key role in producing compact automata for performing pattern matching over Boolean expressions. The automaton construction of SVA sequences is shown below in Proposition 9.3. Items with an italicized comment in square brackets are part of the BNF syntax specification and were maintained to keep Proposition 9.3 as similar as possible to its related definition (Definition 4.9). Proposition 9.3. If i and j represent nonnegative integers with j ≥ i, b represents a Boolean, s represents a Sequence, then the automaton construction for SVA sequences, denoted A S (s), is performed as follows: A S (s) : • A S (b) = A B (b) • A S ((s)) = A S (s) • A S (##i s) = A S (true ##i s) • A S (##[i: j] s) = A S (true ##[i: j] s) • A S (##[i:$] s) = A S (true ##[i:$] s) • A S (s1 ##i s2 ) = A S (s1 ##[i : i] s2 ) • A S (s1 ##[i: j] s2 ) = C YCLE D ELAY(i, j, A S (s1 ), A S (s2 )) • A S (s1 ##[i:$] s2 ) = C YCLE D ELAY(i, −1, A S (s1 ), A S (s2 )) • A S (b[*i]) = A S (b[*i:i]) • A S (b[*i: j]) = R ANGE R EPEAT(i, j, A B (b)) • A S (b[*i:$]) = C ONCATENATE ( R ANGE R EPEAT(i, i, A B (b)), K LEENE C LOSURE(A B (b)) ) • A S (b[->i]) = A S (b[->i:i]) • A S (b[->i: j]) = A S ((!b[*0:$] ##1 b)[*i: j]) • A S (b[->i:$]) = A S (b[->i] ##1 (1[*0] or (1[*0:$] ##1 b))) • A S (b[=i]) = A S (b[=i:i]) • A S (b[=i: j]) = A S (b[->i: j] ##1 !b[*0:$])

9.2 Checker Generation for SystemVerilog Assertions

213

• A S (b[=i:$]) = A S (b[->i:$] ##1 !b[*0:$]) • A S (s[*i]) = A S (s[*i:i]) • A S (s[*i: j]) = R ANGE R EPEAT(i, j, A S (s)) • A S (s[*i:$]) = C ONCATENATE ( R ANGE R EPEAT(i, i, A S (s)), K LEENE C LOSURE(A S (s)) ) • A S (s1 and s2 ) = A ND(A S (s1 ), A S (s2 )) • A S (s1 intersect s2 ) = I NTERSECT(A S (s1 ), A S (s2 )) • A S (s1 or s2 ) = C HOICE(A S (s1 ), A S (s2 )) • A S (first match(s)) = F IRST M ATCH(A S (s)) • A S (b throughout s) = A S ((b[*0:$]) intersect s1 ) • A S (s1 within s2 ) = A S ((1[*0:$] ##1 s1 ##1 1[*0:$]) intersect s2 ) The item A S (b) = A B (b) uses the automata construction for Booleans introduced in Proposition 6.2. All other items fall into two categories, namely those with direct algorithms, and those that are based on rewrite rules. Items based on rewrite rules can be easily identified since they have the form A S () = A S (), and will be treated in Subsection 9.2.2.2.

9.2.2.1 Automata Algorithms Among the operators that appear in Proposition 9.3, only one of them truly requires the addition of a new algorithm over the PSL automata. That new algorithm implements checkers involving the cycle delay (##). The A ND algorithm, used to implement non-length-matching intersection (as opposed to length-matching intersection, used earlier in PSL), is also introduced as an algorithm so that it can be utilized for properties as well. All remaining algorithms are borrowed from previous chapters and remain identical to their PSL use. A S (s1 ##[i: j] s2 ) A S (s1 ##[i:$] s2 )

= =

C YCLE D ELAY(i, j, A S (s1 ), A S (s2 )) C YCLE D ELAY(i, −1, A S (s1 ), A S (s2 ))

The particular delay operator of SystemVerilog assertions is performed on two argument automata using the C YCLE D ELAY() algorithm, shown in Algorithm 9.1. The algorithm receives two automata upon which to perform the cycle delay, and two integers representing the range of cycles to be used as the delay. The two integers can not be negative, except when high is set to −1 to represent the end of simulation identifier $. Other than this exception, high ≥ low. The algorithm first starts by detecting the requirement for a fusion to take place. A fusion is required when the low bound is equal to 0; the two argument sequences thus overlap. This is actually a separate rule in Appendix E in the SVA semantics [107]: ( s1 ##[0:0] s2 ) ≡ ( s1 ##0 s2 )

214

9 Checkers for SystemVerilog Assertions

Algorithm 9.1 Automaton cycle delay algorithm. 1: FUNCTION: C YCLE D ELAY(low, high, AL , AR ) //high = −1 means $ 2: create new automaton A = (0, / 0, / 0, / 0) / 3: if low = 0 then 4: A ← F USE(AL , AR ) 5: else 6: low ← low − 1 7: if high = 0 then 8: create new automaton A1 9: if high = −1 then 10: A1 ←C ONCATENATE(AL ,C ONCATENATE(A S (true[*low:$]),AR )) 11: else 12: high ← high − 1 13: A1 ←C ONCATENATE(AL ,C ONCATENATE(A S (true[*low:high]),AR )) 14: A ← C HOICE(A , A1 ) 15: return A

The ##0 cycle delay is equivalent to PSL’s fusion operator [92]. The fusion is performed if required, in line 4, else the uninitialized automaton is prepared. The low value is only decremented if it is greater than 0, as performed in lines 5 and 6, to avoid generating a negative value. The second part of the algorithm in lines 7 to 14 handles the case where high is greater than 0 (or equal to −1 for the end of simulation), meaning that one or more concatenations must also be done. The C ONCATENATE(), C HOICE() and F USE() algorithms are presented in Algorithms 6.2, 6.3 and 6.5 respectively. The construction in the second part of the C YCLE D ELAY() algorithm above can be summarized as follows [107]: ( s1 ##1 1[*low − 1 : high − 1] ##1 s2 ) ( s1 ##1 1[*low − 1 :$] ##1 s2 )

when high = −1 when high = −1

The first rule above corresponds to lines 12 and 13 in the algorithm. The high bound must be decremented, whereas the low bound was properly decremented in the first part. The second rule above is implemented in line 10, where the special −1 bound in treated. The final part of the algorithm performs automata disjunction between the two parts’ automata, and returns the resulting automaton. The initialized automaton in line 2 is guaranteed not to be returned because if low is equal to 0, the fusion will take place, else low is greater than 0 and since high ≥ low then high > 0, and the second part of the algorithm will execute. The C HOICE () algorithm performs simple set unions between the constituents (states, transitions, etc.) of its argument automata, and was presented in Algorithm 6.3. A S (b[*i: j]) A S (s[*i: j])

= =

R ANGE R EPEAT(i, j, A B (b)) R ANGE R EPEAT(i, j, A S (s))

9.2 Checker Generation for SystemVerilog Assertions

215

Algorithm 9.2 Automata non-length-matching intersection. 1: FUNCTION: A ND(A1 , A2 ) 2: create new automaton AS = ({q0 }, {(q0 , true, q0 )}, {q0 }, {q0 }) //1[*0:$] 3: create new automaton A = I NTERSECT(C ONCATENATE(A1 ,AS ),A2 ) 4: A = C HOICE( A , I NTERSECT(C ONCATENATE(A2 ,AS ),A1 ) ) 5: return A

The range repetitions above, applied to a Boolean or a sequence argument, are identical to PSL’s range repetition with the similar [*i: j] operator. The range repetition of an automaton is performed using the same algorithm that was developed for PSL, namely R ANGE R EPEAT(), and was presented in Algorithm 6.7. A S (b[*i:$])

=

A S (s[*i:$])

=

C ONCATENATE ( R ANGE R EPEAT(i, i, A B (b)), K LEENE C LOSURE(A B (b)) ) C ONCATENATE ( R ANGE R EPEAT(i, i, A S (s)), K LEENE C LOSURE(A S (s)) )

The range repetitions above have a high bound that extends to the end of simulation ($). In such cases, the Boolean or Sequence is repeated the number of times indicated by the low bound, and then concatenated with zero or more instances, as produced by the K LEENE C LOSURE() algorithm presented in Algorithm 6.4. The rules above are equivalent to their PSL counterparts appearing in (6.6) and (6.7) respectively. A S (s1 and s2 ) = A ND(A S (s1 ), A S (s2 )) The non-length-matching intersection of two sequences, using the and operator in SVA, is performed using the A ND() algorithm shown in Algorithm 9.2. The basis of this algorithm corresponds to the derived operator rule for and, as shown in Appendix E in the SVA specification [107]. It is similar to PSL’s non-lengthmatching sequence intersection operator (&), and is shown below in SVA notation. s1 and s2

≡

((s1 ##1 1[*0:$]) intersect s2 ) or (s1 intersect (s2 ##1 1[*0:$]))

The above rule is the SVA equivalent of the PSL rewrite rule presented in (6.4). The reason it is not included as a rewrite rule in SVA is that a non-length-matching intersection is also required to perform the and operation at the property level. The I NTERSECT() algorithm invoked in the A ND() algorithm above is presented in Algorithm 6.6. A S (s1 intersect s2 ) A S (s1 or s2 )

= =

I NTERSECT(A S (s1 ), A S (s2 )) C HOICE(A S (s1 ), A S (s2 ))

The intersect and or sequence operators are identical to PSL’s && and | SERE operators, and are implemented in the same way, using the I NTERSECT()

216

9 Checkers for SystemVerilog Assertions

and C HOICE() algorithms (Algorithms 6.6 and 6.3 respectively). A S (first match(s))

=

F IRST M ATCH(A S (s))

SVA’s first match operator has no direct equivalent in PSL; however, an appropriate algorithm was already devised for this in Subsection 7.4.3, for the completion mode debugging enhancement. When building an automaton that accepts only the first match of an argument automaton, for a given activation, the F IRST M ATCH() algorithm shown in Algorithm 7.1 can be used directly.

9.2.2.2 Rewrite Rules The items in Proposition 9.3 that have not been treated thus far have a common characteristic: they have the form A S (x) = A S (y). More generally, the link between the arguments can be expressed as a rewrite rule of the form x → y, where x is rewritten to y. Expression rewriting (or term rewriting) is a practical way of allowing the checker generator to handle the large amount of sequence operators, while only requiring algorithms for a much smaller number of operators in the tool’s kernel. The rewrite rules used are either directly from the derived forms in Appendix E in the SVA specification [107], or in some cases were modified to more closely show how they are actually implemented in the tool. Although a few rewrite rules may appear intuitive, they are nonetheless included for completeness. Each rule is explained immediately following its appearance. (s)

→ s

The above rule is straightforward, given that semantically the parentheses are used only for grouping and their main effect is instead in the syntax of sequences. ##i s ##[i: j] s ##[i:$] s

→ → →

true ##i s true ##[i: j] s true ##[i:$] s

The cycle delay operator, when used without a left side sequence argument, can be rewritten to the binary case by assuming that the left side is true. The SVA specification has different but equivalent rules whereby a single concatenation is used (##1) and the repetition number or range is instead applied to the left hand side’s newly added true (or 1 as shown in the specification). s1 ##i s2 b[*i] b[->i] b[=i] s[*i]

→

s1 ##[i : i] s2

→ → → →

b[*i:i] b[->i:i] b[=i:i] s[*i:i]

9.2 Checker Generation for SystemVerilog Assertions

217

The five preceding rules all have one feature in common: a repetition or cycle delay with a single number is rewritten using an equivalent range operator with identical bounds. This strategy is different than the rules proposed in the SVA specification [107], but is actually simpler to implement in the checker generator given that the forms with a range must also be supported. The five rules above handle the cases where a single number is used, respectively, in: a cycle delay, a Boolean and sequence repetition, a goto repetition ([->]) and a non-consecutive repetition ([=]). Ranges of numbers, when used in goto and non-consecutive repetitions, are handled next. b[->i: j]

→

b[->i:$]

→

(!b[*0:$] ##1 b)[*i: j] b[->i] ##1 (1[*0] or (1[*0:$] ##1 b))

The first rule above for the goto repetition with a range is identical to that of the SVA specification, where a single goto repetition is repeated using the same range. In a single goto repetition, a Boolean b is matched when it is preceded by any number of consecutive cycles where b is false. The second rule handles the unbounded case, and is different than the one in the SVA specification. The proof that this rule is correct appears in the discussion related to the PSL equivalent of the above rules, presented in (6.11) and (6.12) respectively. b[=i: j]

→

b[=i:$]

→

b[->i: j] ##1 !b[*0:$] b[->i:$] ##1 !b[*0:$]

The rules for non-consecutive repetition with a range, whether the upper bound is fixed or extends to the end of execution, are implemented as shown in the derived forms in the SVA specification [107]. b throughout s s1 within s2

→ →

(b[*0:$]) intersect s1 (1[*0:$] ##1 s1 ##1 1[*0:$]) intersect s2

The final two rewrite rules apply when a Boolean must remain true throughout the matching of an argument sequence, or when a sequence must occur within the matching of another sequence. The rule for throughout follows from the SVA specification and is based on sequence intersection. Because it is not known how many cycles the sequence will span, the Boolean is repeated an arbitrary number of times, and must be true throughout the matching. The within operator is identical to the PSL operator of the same name, and is implemented the same way in both specifications [107, 108]. The equivalent PSL rewrite rule for the within operator was shown in (6.5).

218

9 Checkers for SystemVerilog Assertions

9.2.3 Automata Construction for Properties The construction of automata for SVA properties makes use of the construction of automata for Booleans and sequences presented thus far in this chapter. In turn, property automata are used to construct automata for SVA verification statements, and will be utilized in Subsection 9.2.4. Two notable differences between SVA and PSL properties are the rules for the or and not operators (|| and ! respectively in PSL). PSL’s simple subset guidelines restrict these operators such that one of the arguments of || and the argument of ! must be a Boolean. This restriction is not present in SVA, where entire properties can be negated or used in a disjunction. This does not render the language unfit for dynamic verification, and checkers can still be produced, but the algorithmic approach must be revised compared to the PSL case. One consequence of the less restrictive or and not SVA operators is that a modular property construction approach, such as described in Section 7.2, is not applicable. Automata splitting, or modularizing the automata used in property construction is not compatible with these operators since their behavior can not be modeled using the precondition automata strategy. For this reason, the debugging enhancements that make use of automata splitting such as assertion threading and activity monitors do not apply, in their current form, to SVA checkers. Automata splitting was also described as the recursive compilation strategy with precondition automata (Section 7.2). The efficient construction for PSL’s eventually! operator, made possible with automata splitting, is not forfeited in the case of SVA since such an operator is not part of the language. As for PSL properties, the construction of an automaton from an SVA property p is denoted as A P (p). However, in order for the construction to profit as much as possible from non-determinism in the automata, a special polarity symbol is introduced in the construction of automata for SVA properties. Use of the polarity mechanism allows for a mode of interpretation to be passed down to its lowest level in properties, namely sequences, where either the failure or occurrence matching of the sequences is performed. In other words, the negation is actually delayed as much as possible throughout the property’s recursive construction, such that the complementation of property automata is not required. Complementation was shown to require strong determinization that can exponentially increase the number of states, which is to be avoided whenever possible. Incidentally, the modes of interpretation mentioned above were actually observed in the first version of the MBAC tool for PSL properties, and were called “conditional mode” and “obligation mode” [29]. For example, given a nondeterministic finite automaton A , it follows that L(A ) = L( N EGATE (N EGATE (A )) ) Although applying the double negation of automata does not change the language accepted by A , the automaton resulting from the two negations will have undergone strong determinizations and is likely to have more states than the NFA on the left. Since the hardware implementation of NFAs is well handled, the NFA is almost

9.2 Checker Generation for SystemVerilog Assertions

219

always preferred to an equivalent DFA so that the generated hardware can be smaller. The N EGATE() algorithm was presented in Algorithm 5.6. The polarity symbol used in the automata construction for properties is the overline bar. A negative polarity is denoted A P (p), and a positive polarity is indicated as usual without the symbol, as in A P (p). Because of the polarity symbol, the automaton construction for properties is actually doubled in the presentation below since both polarities of property operators are handled separately. To be clear, the polarity mentioned here is not directly part of the syntax of SVA properties, and is used exclusively for the automaton construction procedure described in Proposition 9.4. Other than the dual implementation mentioned for the polarity, Proposition 9.4 is kept in a form that resembles the definition of properties (Definition 4.10) as most as possible, such that the link between syntax and automaton construction can be better observed. Proposition 9.4. If b is a Boolean, s is a Sequence, p is a property, then the automaton construction for SVA properties, with a positive or negative polarity, denoted A P (p) and A P (p) respectively, is performed as follows: A P (p) : • A P (s) = A S (s) • A P ((p)) = A P (p) • A P (not p) = A P (p) • A P (p1 or p2 ) = C HOICE(A P (p1 ), A P (p2 )) • A P (p1 and p2 ) = A ND(A P (p1 ), A P (p2 )) • A P (s |-> p) = C HOICE(A P (s), F USE(A S (s), A P (p))) • A P (s |=> p) = A P ((s ##1 true) |-> p) • A P (if (b) p) = A P (b |-> p) • A P (if (b) p1 else p2 ) = A P ((b |-> p1 ) and (!b |-> p2 )) • A P (disable iff(b) p) = A DD L ITERAL(A P (p), H (!b)) A P (p) : • A P (s) = F IRST FAIL(A S (s)) • A P ((p)) = A P (p) • A P (not p) = A P (p) • A P (p1 or p2 ) = A ND(A P (p1 ), A P (p2 )) • A P (p1 and p2 ) = C HOICE(A P (p1 ), A P (p2 )) • A P (s |-> p) = F USE(A S (s), A P (p)) • A P (s |=> p) = A P ((s ##1 true) |-> p) • A P (if (b) p) = A P (b |-> p) • A P (if (b) p1 else p2 ) = A P ((b |-> p1 ) and (!b |-> p2 )) • A P (disable iff(b) p) = A DD L ITERAL(A P (p), H (!b)) The rules in the above proposition are explained next, following their appearance in the text. For a given type of property operator, both polarities are explained together. The first point to notice in Proposition 9.4, apart from the fact that the first

220

9 Checkers for SystemVerilog Assertions

and second halves are very similar, is the first rule in both the positive (first) half and the negative (second) half. A P (s)

=

A S (s)

A P (s)

=

F IRST FAIL(A S (s))

(9.1)

These rules describe how to create an automaton for a sequence when it is used as a property. In the case of a positive polarity, a plain sequence matching automaton is required; this can be obtained using the A S (s) construction covered in Subsection 9.2.2. The negative polarity corresponds to the case where the sequence is expected to occur and its non-occurrence constitutes a prescribed behavior. In this case, the failure matching of the sequence is required, and for each activation of the sequence, its first non-occurrence (first failure) is to be detected. This behavior can be accomplished by utilizing the F IRST FAIL() algorithm (Algorithm 6.9), which was introduced in the construction of automata for PSL properties. The use of the F IRST FAIL() algorithm makes it such that the semantics of sequences in the automata construction follows the weak satisfaction semantics described in Appendix E of the SVA specification [107]. Implementing the strong satisfaction semantics can be accomplished by replacing the call to F IRST FAIL() with a call to F IRST FAIL S TRONG() instead (Algorithm 6.10). The next revision of SVA is expected to add special operators to the language such that the strength of the matching can be specified in the assertion language, and for sequences this will create similar behavior to PSL’s weak and strong sequences. From the discussions above following (9.1), it can be anticipated that the correct context for a sequence, when used directly as a top-level property, is the negated case. This will be visible in Proposition 9.5, which describes the automata construction of SVA verification statements. There is will be shown that the top-level property is actually built starting with a negated property construction A P (). A P ((p))

=

A P (p)

A P ((p))

=

A P (p)

Parentheses are used only for grouping and can be ignored in the automata constructions, as shown above. A P (not p)

=

A P (p)

A P (not p)

=

A P (p)

The not operator is implemented by passing the opposite polarity down to the automaton construction of its argument property p. One of the main reasons for doing this is that in the semantics desired for the checkers, a proper automaton complementation algorithm (such as presented in Subsection 5.2.4) is not used. The F IRST FAIL() algorithm was used to perform a transformation similar to automata negation, but with slight differences particularly tuned for failure detection in runtime assertion monitoring. The following equations illustrate the fact that failure

9.2 Checker Generation for SystemVerilog Assertions

221

detection is not to be used as a general negation operation. A1 = A S (s) A2 = F IRST FAIL(F IRST FAIL(A S (s))) L(A1 ) = L(A2 ) The proof of this inequality can be worked out by counterexample using the sequence s = a[*1:2], where it can be shown that L(A1 ) = { {a}, {a ##1 a} }

L(A2 ) = { {a ##1 a} }

Although it would be possible to utilize proper automata complementation throughout the property layer and apply a transformation for adjusting the run-time semantics of the resulting automata, this approach would have the disadvantage of always creating strongly deterministic automata. Strongly deterministic automata undergo a subset construction that has the potential to exponentially increase the number of states. As it was motivated in the case of PSL checkers, any nondeterminism is actually desired since NFAs are generally smaller that DFAs and pose no problems for a hardware implementation. In the proper complementation approach, certain parts of an assertion might be needlessly strongly determinized, while having kept the original NFA would have been sufficient. This is why the approach reported in this section for SVA properties makes use of the polarity, so that all polarities are pushed down to sequences. When the polarity is such that a failure detection is not required, an NFA is kept as is, in its most compact form. A P (p1 or p2 )

=

C HOICE(A P (p1 ), A P (p2 ))

A P (p1 or p2 )

=

A ND(A P (p1 ), A P (p2 ))

Property disjunction using SVA’s or operator indicates that either of the argument properties must hold. The negated case is constructed by making use of De Morgan’s law. The conjunction (or intersection) required does not need to be of length-matching type, hence the use of the A ND() algorithm. This algorithm was devised for SVA sequences, but is nonetheless a general automata algorithm that can also be used with automata built in the property layer. A P (p1 and p2 )

=

A ND(A P (p1 ), A P (p2 ))

A P (p1 and p2 )

=

C HOICE(A P (p1 ), A P (p2 ))

Property conjunction using SVA’s and operator models the fact that both argument properties must hold. Both properties may complete in different clock cycles, therefore the non-length-matching intersection is used. The negated case is also handled using De Morgan’s law. The similarities with the automaton construction for PSL’s property (&&) operator are interesting to compare, where in (6.20) the C HOICE() algorithm was used to perform property conjunction.

222

9 Checkers for SystemVerilog Assertions

Table 9.1 SVA property implication truth table (: and | represent the fusion and choice operations respectively). s

p

s |-> p

s |-> p

F F F T T F T T Cover:

T T F T s | s:p

F F T F s:p

In PSL’s simple subset, the negation operator can not be applied to properties and as such, properties are always under an implicit negative polarity. For this reason, the negated cases in Proposition 9.4 for SVA properties have similarities to the corresponding PSL automata constructions. Another example of this is the property implication operator in SVA, for which the equivalent PSL suffix implication operator was constructed using a single fusion (as in the negated case below). A P (s |-> p) A

P (s

|-> p)

= =

C HOICE(A P (s), F USE(A S (s), A P (p))) F USE(A

S (s), A P (p))

(9.2) (9.3)

Property implication also has a duality in its construction approach, given a positive or negative polarity. Table 9.1 shows the truth table used to derive the construction rules shown above. The last row in the table shows how the covering of the implication functions, under both polarities, is to be interpreted in the temporal form of sequences and properties. The starting point for this derivation is the typical implication rule for the case of binary expressions: b1 -> b2

↔

b1 | b2

In the case of the property implication s |-> p, both arguments are not necessarily Boolean expressions and they generally span multiple clock cycles. In such cases, the consequent’s pattern matching must begin in the cycle where the antecedent’s pattern produced a match. For this reason, the following implication strategy is employed when used in assertions: s |-> p

↔

s | s: p

The : operator above represents the fusion operation, although automata notation is purposely not used here. This case describes the construction for a positive polarity implication, and covers the three lines in the truth table in Table 9.1 where the implication is true (T). The automata construction in (9.2), which was the source of this explanation, corresponds to the right side of the rule above, rewritten in automaton form using the proper automata algorithms. For the negated property implication, only one line in the truth table must be covered. This corresponds to the case where the matched sequence is followed by

9.2 Checker Generation for SystemVerilog Assertions

223

the negated property. The starting point for this derivation is the negated implication rule for the case of binary expressions: ↔

b1 -> b2

b1 | b2

↔

b1 & b2

In the case of a property implication, the consequent is a property that must begin in the cycle where the antecedent’s pattern produced a match. For this reason, the & is replaced by a fusion when adapting the previous rule for properties and sequences: s |-> p

↔

s: p

The right side of the rule above is then translated into automaton form, thereby yielding the corresponding automaton construction in (9.3). This case also corresponds to the automaton construction for PSL’s suffix implication operator shown in (6.21), without the use of polarities, given PSL’s simpler usage of negation. At this point an interesting pattern is beginning to emerge. The negated cases for property conjunction and implication are handled almost identically to their treatment in PSL’s automata constructions. This indicates that in general, PSL properties behave like SVA properties that have a negative polarity; this observation will be consistent with the construction of automata for SVA verification statements, where the top level SVA property is always started with a negative polarity. Such behavior is expected since an assertion is always in the context of needing to find errors, and the implicit context of properties is the negated case, where the word negated means negated with respect to the normal pattern matching automata. This is consistent with the fact that the pattern matching of failures is what is desired, rather than the successes. When both polarities of the automata construction rules of an operator are identical, a rewrite rule can be used in the checker generator. More specifically, if the two polarities of an operator are such that A P (x) = A P (y) and also A P (x) = A P (y), where x and y are the same in both polarities, then the rewrite rule x → y applies. A P (s |=> p)

=

A P ((s ##1 true) |-> p)

A P (s |=> p)

=

A P ((s ##1 true) |-> p)

The above automata constructions for non-overlapping property implication follow from the rewrite rule: s |=> p

→

(s ##1 true) |-> p

The rewrite rule above is identical to the one used for PSL’s |=> operator, as shown in (6.22). A P (if (b) p)

=

A P (b |-> p)

A P (if (b) p)

=

A P (b |-> p)

224

9 Checkers for SystemVerilog Assertions

The if operator is handled by rewriting it using a property implication with the Boolean b. if (b) p → b |-> p A Boolean is a valid sequence that can be used as the antecedent in the implication. The rewrite above shows that the if operator is only a restricted version of property implication where the triggering condition is simply a Boolean. A P (if (b) p1 else p2 )

=

A P ((b |-> p1 ) and (!b |-> p2 ))

A P (if (b) p1 else p2 )

=

A P ((b |-> p1 ) and (!b |-> p2 ))

The more flexible if...else operator is also based on a rewrite rule: if (b) p1 else p2

→

(b |-> p1 ) and (!b |-> p2 )

This rewrite rule models the fact that only one of the properties must be checked, depending on the state of the Boolean b. When b is true, only the first property is checked and when b is false (i.e. when !b is true), only the second property is checked. Both cases are combined using the and property conjunction operator. The rewrite rules for the |=>, if and if...else operators follow from the SVA specification [107]. A P (disable iff(b) p)

=

A DD L ITERAL(A P (p), H (!b))

A P (disable iff(b) p)

=

A DD L ITERAL(A P (p), H (!b))

The final case in the automaton construction of SVA properties, presented in Proposition 9.4, is the disable iff operator. When this operator is encountered in the syntax tree, the automaton for the argument property is built and a new primary symbol for the negated Boolean of the abort condition is created. The algorithm A DD L ITERAL() then adds a literal (a conjunct) to each edge symbol in the property automaton. The added literal corresponds to the negation of the disable iff’s Boolean such that when the abort condition becomes true, all edges are inhibited from activating successor states, and the automaton is reset. The A DD L ITERAL () algorithm is presented in Algorithm 6.11 and is also used to handle PSL’s abort operator, as shown in (6.19). Since the transformation of properties to automata is also recursive in nature, for a larger property only the portion of the automaton that the disable iff operator was applied to will have the added literals. Furthermore, when multiple disable iff operators are nested in a property, each will contribute its own additional literal only to the portion of the whole automaton to which it applies.

9.2 Checker Generation for SystemVerilog Assertions

225

9.2.4 Automata Construction for Verification Statements The final layer in the SVA language hierarchy is that of verification statements. This is where a property receives its initial polarity for the automaton construction, which is based on the syntax tree of the given assertion. The automaton construction for the verification statements from Definition 4.11 is presented below in Proposition 9.5. Proposition 9.5. If s is a Sequence, p is a Property and v is a verification statement, then the automaton construction for SVA verification statements, denoted A V (v), is performed as follows: A V (v) : • A V (assert property (@(clock expr) p);) = F USE(A S (true[*1:$]), A P (p)) V • A (cover property (@(clock expr) p);) = C OVER(p) The clock expr, although seemingly has no effect above, is automatically stored as the clock string, similar to the default clock of PSL. It is then used whenever flip-flops are instantiated for implementing the automata in circuit form. The entire argument property of the assert or cover is under the scope of this clock, and the checker is constructed using this clock. Building an automaton for the assert verification statement consists of building the automaton of the argument property with a negative polarity, and continually triggering this automaton by fusing it with an automaton that accepts every trace. A S (true[*1:$]) The continually active automaton is built using an SVA sequence as shown above. A V (assert property (p);)

=

F USE(A S (true[*1:$]), A P (p))

The expression above represents the automaton construction for the assertion of a property p; the clock expression was omitted since it is handled as mentioned previously. The fusion is used so that anytime the left side sequence is matched, i.e. at every clock cycle, it activates the property automaton on the right side. This is coherent with the behavior described in Section 4.2, where it was stated that a property appearing directly as a Verilog statement is expected to be checked continually. The negative polarity used when constructing the property’s automaton above, namely A P (p), evokes the core reasoning behind assertion-based verification: the assertion specifies a correct pattern that is to be respected, and it is the failure to comply to the pattern that should be detected and reported. Thus an “anti-pattern matcher” is required. This can not simply be done by adding an inverter to the output of the correct pattern matcher, as the run-time semantics produced would be completely inadequate. Example 6.2 and the discussion leading to it helped motivate this concept for PSL, and also apply here for the SVA case. The following example shows the progression of polarity in the construction of an automaton for a complete SVA statement.

226

9 Checkers for SystemVerilog Assertions

Algorithm 9.3 SVA property cover algorithm. 1: FUNCTION: C OVER(p) 2: create new automaton A1 3: if property p is also a valid sequence s then 4: A1 ←F USE(A S (true[*1:$]), A S (s)) 5: else 6: A1 ←F USE(A S (true[*1:$]), A PC (p)) 7: // A PC is the same as A P but with all calls to F IRST FAIL () replaced by F IRST M ATCH () 8: return A B (EOE && !M ONOSTABLE FF(H (A1 )))

Example 9.1. Consider the following SVA assertions stating that if a given sequence occurs, then another sequence should not occur starting in the next cycle. The clock expression was omitted for simplicity. assert property ((a or b[*2]) |-> (d ##[1:2] e)); The assertion states that whenever either a is true or b is true in two consecutive clock cycles, then in the next cycle d must be true followed in one or two cycles by e. The automaton construction steps are as follows. For simplicity, s1 = (a or b[*2]) and s2 = (d ##[1:2] e). A V ( assert property (s1 |-> s2 ); ) ⇔

F USE( A S (true[*1:$]), A P (s1 |-> s2 ) )

⇔ ⇔

F USE( A S (true[*1:$]), F USE(A S (s1 ), A P (s2 )) ) F USE( A S (true[*1:$]), F USE(A S (s1 ),F IRST FAIL(A S (s2 ))) )

The main point to notice in the last line in the above derivation is that the automaton for the antecedent sequence, A S (s1 ), does not undergo any strong determinization, and any nondeterminism is preserved in the final automaton. Minimization is also applied implicitly (not shown), but contains only weak determinizations. The automaton for the consequent sequence however, does undergo a strong determinization, as witnessed in Algorithm 6.9. In this example, the checker that is generated requires less hardware resources than would be produced by another approach using automata negation throughout the recursive construction of property automata. The second item to be treated in the verification statement in Proposition 9.5 is the cover operator. A V (cover property (@(clock expr) p);)

=

C OVER(p)

The automaton construction of the cover verification statement makes use of the C OVER() algorithm, shown in Algorithm 9.3. The algorithm first begins by checking if the argument property p is also a valid sequence s. If this is the case, the pattern matching NFA built by the sequence construction, namely A S (s), can be utilized directly. This automaton is continually activated by fusing it with a sequence that

9.2 Checker Generation for SystemVerilog Assertions

227

produces a match at every clock cycle, as also used in the case of the assert automaton construction. In the case of the covering of a full SVA property, the fusion with a continually matching left-side is also used. The difference is that the automaton construction of the argument property is performed using a variant of the rules in Proposition 9.5, indicated by the A PC () notation. The supplemental C in the A P construction indicates that the properties must be compiled in completion mode. This is similar to the completion mode debugging enhancement for PSL checkers presented in Subsection 7.4.3. Like the PSL case, constructing automata in completion mode for properties involves replacing all calls made to the F IRST FAIL() algorithm by calls to the F IRST M ATCH() algorithm. In the case of SVA properties, only one such substitution must be made in Proposition 9.5, corresponding to the first of the negated polarity cases, namely A P (s). More precisely, the rule in question was treated in (9.1), and in the completion mode, the change in algorithm calls affects only this rule. The F IRST M ATCH() algorithm is presented in Algorithm 7.1. The verification statements for SVA show that covering of full properties is defined, whereas in PSL the cover operator applies only to sequences. However, with the completion mode debugging enhancement, a form of coverage for PSL properties can also be performed, as shown in Subsection 7.4.3. The last step in the C OVER() algorithm is common to both the sequence and property cases, and consists of the implication below, which is derived to show the exact form used in the algorithm. The symbol completion observed is a Boolean signal, and is used to memorize the fact that the automaton representing the sequence or property produced a successful match at least once during the execution. The EOE signal is normally false, and becomes true for at least one cycle at the end of the execution. !(EOE->(completion observed)) !(!EOE||(completion observed)) EOE&&!(completion observed) The negation in the first case is used to reverse the polarity of the implication result. Since a successful implication is true, successes should be indicated with a normally low signal in the checker’s output. In the second line the implication is rewritten using Boolean disjunction. The third line shows the exact form used in the C OVER algorithm. The completion observed signal is used to represent the completion criterion. completion observed = M ONOSTABLE FF(H (A1 )) The completion criterion is that the automaton representing the sequence or property must have found at least one match during the execution of the design. The successful match is latched and held to the end of execution using a monostable flip-flop that is normally low. The creation of the flip-flop is represented by the M ONOSTABLE FF() function call above, and is similar in notation to the DFF() used in Subsection 9.2.1. Even if the match comes at the last cycle before the EOE,

228

9 Checkers for SystemVerilog Assertions

the flip-flop’s delay will not cause a problem since the result of the flip-flop is tested in the cycle where EOE is asserted, and does not correspond to a valid design cycle in terms of monitoring design signals. The EOE implication was also used in a similar fashion at the top right in Figure 7.2, where the efficient construction of PSL’s eventually! operator was developed. The main reason for handling sequences separately from properties in the the cover() algorithm is so that any amount of non-determinism can be kept in the automata. If a sequence were treated as a property, in the chain of automata algorithms it would be implemented as F IRST M ATCH(A S (s)) instead of A S (s). The major difference is that the F IRST M ATCH algorithm contains a strong determinization, and on average increases the number states compared to the NFAs (or weakly determinized) automaton produced by the A S (s) construction. Because the monostable flip-flip is used, once the first match is latched, any subsequent match has no effect. This type of flip-flop was also employed in the equivalence checking of certain cases in Chapter 8, where slight differences in runtime semantics were present in the checkers, and the monostable flip-flop was used to mask these differences (for example, in the analysis of Table 8.1). M ONOSTABLE(H (A ))

≡

M ONOSTABLE(F IRST M ATCH(H (A )))

The equivalence above is used to show that both circuits are functionally equivalent, even though the circuit on the right may be substantially larger. Avoiding strong determinization and using a monostable latching-type flip-flip was also the basis of the efficient implementation of PSL’s eventually! operator in Section 7.3. The automata construction for SVA verification statements derived thus far applies to the case where the statements are used directly in Verilog modules or within the always procedural block. When the statements are used in an initial procedural block, the checking of the properties is only required to trigger once in the initial state of the design. In this case, the rules given in Proposition 9.5 and the Cover() algorithm must be modified. This can be accomplished by replacing the expressions A S (true[*1:$]) used in the calls to the fusion algorithm with the expression A B (true). Or equivalently, the fusion can be removed altogether and the right sides of the fusions can be used directly. To summarize, the first rule (assert) in Proposition 9.5, and lines 4 and 6 in the Cover() algorithm would appear as follows, respectively: A V (assert property (p);) A1 ← A S (s) A1 ← A PC (p)

=

A P (p)

9.3 Experimental Results for SVA Checkers

229

In the next section, the creation of automata-based SVA checkers is evaluated through benchmarking, where the circuit size and speed metrics of the checkers are reported.

9.3 Experimental Results for SVA Checkers In this section, all the checkers were synthesized with Xilinx XST 8.1.03i for an XC2V1500-6 FPGA, and the synthesis was optimized for speed (as opposed to area). The number of FFs and four-input lookup tables (LUTs) required by a circuit is reported, and serves as an estimate of the hardware complexity of a given checker. The maximum operating frequency after the synthesis step is also reported for the worst clk-to-clk path. Unlike the PSL checkers that were compared to the FoCs checkers, no standalone tool capable of producing SVA checkers was available to make a comparison in this chapter.

9.3.1 Non-synthetic Assertions Similarly to the PSL case in Section 8.2, the non-synthetic, or real-world assertions, are employed to evaluate the checker generator with SystemVerilog assertions. The majority of assertions are taken from the book “A Practical Guide for SystemVerilog Assertions” [171]. The non-synthetic assertions are meant to verify various specifications of real design modules, and their Boolean layer expressions do not typically consist purely of simple signals. In the experimental procedure used here, a declaration module is created to represent the CUT, where only the signal declarations are defined; the actual design itself is not required to generate the checkers. The assertions used in the test cases are shown below, and the synthesis results of the generated checkers are presented at the end of the subsection in a table similar to the PSL experimental results. The vector widths of signals is specified in the text, and all signals that are not mentioned are assumed to be single-bit entities. In all cases an active low reset was used. Furthermore, the clock expression is omitted to simplify the presentation, and all signals are sensitive to the rising edges of the clock. For example, verification directives such as assert property (@(posedge clk) p); are simply written as assert property (p); to keep the assertions easier to read. The first two test cases are assertions that verify the functional correctness of the mask signals in a 64 or 128 bit write operation in a 32 bit SDRAM memory. These assertions are from Chapter 5 in “A Practical Guide for SystemVerilog

230

9 Checkers for SystemVerilog Assertions

Assertions” [171]. The mask bits control the writing of larger data given the internal data bus of 32 bits. The data signal is 32 bits wide, the addr signal is 16 bits wide, dqm is 4 bits wide, burst and size are 3 bits wide and the sel n signal is 2 bits wide. The assertions make use of the system functions $rose, $fell and $past, along with suffix implication and single valued cycle delays. CPU AHBa, CPU AHBb: ‘define WRITE (!cas_n && !we_n && !sel_n[0] && ras_n && \ (burst == 3’b000)) ‘define BURST_WRITE (!cas_n && !we_n && !sel_n[0] && ras_n && \ (burst != 3’b000)) --assert property ( ((size==1) && ((dqm[1:0]==0 && (‘WRITE || ‘BURST_WRITE))) |-> ##2 ($fell(dqm[2] && dqm[3]) && addr==$past(addr,2) && (‘WRITE || ‘BURST_WRITE)) ##1 $rose(dqm[3] && dqm[2])) ); --assert property ( ((size==0) && ((dqm[0]==0 && (‘WRITE || ‘BURST_WRITE))) |-> ##2 ($fell(dqm[1]) && addr==$past(addr,2) && (‘WRITE || ‘BURST_WRITE)) ##1 $rose(dqm[1]) ##1 ($fell(dqm[2]) && addr==$past(addr,2) && (‘WRITE || ‘BURST_WRITE)) ##1 $rose(dqm[2]) ##1 ($fell(dqm[3]) && addr==$past(addr,2) && (‘WRITE || ‘BURST_WRITE)) ##1 $rose(dqm[3])) );

The next set of assertions is used to verify a system with three masters, two targets and a mediator, and are from Chapter 2 in the book “A Practical Guide for SystemVerilog Assertions” [171]. The masters apply for control using the req and gnt signals. The mediator’s state machine is a one-hot encoded vector called state (all zeros is also allowed). In the example used here, the state signal is assumed to be 12 bits wide, trdy is two bits and all data busses are nine bits wide. For convenience in the testing procedure, the last assertion is supposed to be for a single target having only a single bit trdy signal, but was rewritten here to trdy[0] since all nine assertions use the same signal definitions. Various design specifics are verified with the assertions. The most notable two are the first and second assertions. The first assertion specifies that the mediator’s state machine can be in at most one state at a given time, whereas the second assertion specifies that the mediator should grant the bus within two to five cycles of receiving a request from any master. Other assertions specify the correct behavior of control signals such as frame, irdy (initiator ready) and trdy (target ready). Some of the assertions make use of a variable length cycle delay, and consecutive repetition. SAMP SYSa - SAMP SYSi: ‘define FRAME (frame1 && frame2 && frame3) ‘define IRDY (irdy1 && irdy2 && irdy3) ‘define GNT (!gnt1 || !gnt2 || !gnt3)

9.3 Experimental Results for SVA Checkers

231

‘define REQ (!req1 || !req2 || !req3) --assert property ($onehot0(state)); --assert property ($rose(‘REQ) |-> ##[2:5] $rose(‘GNT)); --assert property ($rose(‘GNT) |-> $fell(‘FRAME && ‘IRDY)); --assert property ($rose(‘FRAME && ‘IRDY) |=> $fell(‘GNT)); --assert property (($fell(req) ##[2:5] ($fell(gnt) && r_sel)) |-> (!frame && !irdy) ##3 !trdy[1]); -assert property ($fell(trdy[1]) |->##10 (frame && irdy) ##1 gnt); --assert property (((rsel1 || !rsel1) ##3 ($fell (trdy[1]) || $fell(trdy[0])) ##3 data1[8]) |-> (data == $past(data1))[*7]); --assert property (($fell (trdy[1]) ##4 !data[8]) |-> (dataout1==datao)[*7]); --assert property ($rose(sel_bit) |-> ##1 trdy[0] ##1 !trdy[0]);

Chapter 6 in the aforementioned book [171] contains a suite of SVA assertions for verifying the PCI bus protocol. From these, 19 assertions and one cover statement were retained for benchmarking the checker generator. As in this and the previous test cases, simple assertions are often avoided in our benchmarking since they are trivially handled by the tool. In the last sequence below, labeled schk6, the assertion actually specifies a system level requirement and, for convenience in the test procedure, gntn[2] was instead written as gntn since the other master/target assertions define only a singlebit grant signal. For simplicity, the same signal definitions are used for all the assertions together. In the PCI bus model, the ad signal is 32 bits wide (address/data) and the extended byte enable cxben is eight bits wide. Among the variety of SVA operators used in the PCI test case assertions are the first match, intersect and the throughout sequence operators, as well as the endpoint matching operator .ended. SVA system functions are also shown to play a key role in expressing the PCI correctness requirements. PCIa - PCIt: ‘define DUAL_ADDRCYCLE ($fell(framen) && (cxben[3:0]==4’b1101)) ‘define CONFIG_READ ($fell(framen) && (cxben[3:0]==4’b1010)) ‘define CONFIG_WRITE ($fell(framen) && (cxben[3:0]==4’b1011)) --assert property ($rose(framen) |-> framen[*1:8] ##0 $rose (irdyn && trdyn)); --assert property ($fell(irdyn) ##[0:5] !(devseln) ##0 stopn |-> (!irdyn)[*0:16] ##0 !trdyn);

232

9 Checkers for SystemVerilog Assertions

--assert property ($fell (framen) |-> 1[*1:8] intersect ($fell(framen) ##[1:$] $fell(irdyn))); --assert property ((framen) |-> (##[1:8] ($rose (irdyn && trdyn && devseln)))); --sequence mchk6; $fell(framen) ##1 (devseln)[*5] ##0 framen; endsequence assert property (mchk6.ended |-> ##1 $rose(irdyn)); --assert property (($fell(framen)&&(cxben[3:0]==(4’b0001))) |-> (perrn[*1:$] ##0 ($rose (irdyn && trdyn)) ##1 perrn[*2])); --assert property (‘DUAL_ADDRCYCLE && req64n |=> not $fell(irdyn)); --assert property ($fell (gntn) ##[1:8] $fell (framen) && $fell(req64n) |-> ##[1:5] $fell (ack64n) && $fell(devseln)); --assert property (($fell(stopn) && !framen) |-> !stopn[*1:$] ##0 $rose(framen) ##1 $rose(stopn)); --assert property ($fell(trdyn) |-> (!trdyn && !devseln)[*0:16] ##0 !irdyn); --sequence tchk6a; (!irdyn && !trdyn && !devseln && !framen); endsequence sequence tchk6b; ($fell(stopn) && $rose(trdyn) && !framen); endsequence sequence tchk6c; $rose (framen) ##[0:8] (!irdyn && !stopn); endsequence sequence tchk6; tchk6a.ended ##[1:8] tchk6b; endsequence assert property (tchk6.ended |=> tchk6c); --sequence tchk6_1; (!irdyn && !trdyn && !devseln && !framen) ##[1:8] ($fell(stopn) && trdyn && framen); endsequence assert property (tchk6_1.ended |=> (irdyn && stopn)); --sequence tchk7a; $fell(framen) ##[1:8] $fell(irdyn); endsequence sequence tchk7b; $fell(framen) ##[1:5] $fell(devseln) && $fell(stopn) && trdyn; endsequence sequence tchk7;

9.3 Experimental Results for SVA Checkers

233

first_match(tchk7a and tchk7b); endsequence assert property (tchk7.ended |=> framen); --assert property ($fell(framen) && (cxben[3:0] == 4’b0001) |-> devseln[*1:4] ##0 $rose(framen)); --assert property ((!irdyn && !trdyn && !devseln && !framen) |-> ##[1:8] (!irdyn && (!trdyn || !stopn))); --sequence tchk12a; (‘CONFIG_READ || ‘CONFIG_WRITE) && ((ad[1:0] == 2’b00) || (ad[1:0]==2’b01)) && idsel; endsequence sequence tchk12b; !devseln && stopn; endsequence sequence tchk12; tchk12a ##[1:5] tchk12b; endsequence assert property (first_match(tchk12) |-> ##[0:5] $fell(trdyn)); --sequence tchk13a; (‘CONFIG_READ || ‘CONFIG_WRITE) && ((ad[1:0] == 2’b10) || (ad[1:0]==2’b11)) && idsel; endsequence sequence tchk13b; (devseln && stopn && trdyn) throughout (##[1:5] $rose(framen)); endsequence assert property (tchk13a |-> tchk13b); --cover property ($fell(framen) && (cxben[3:0]==4’b0101) |-> devseln[*1:5] ##0 $rose(framen)); --sequence schk4a; first_match($fell (lockn) ##[0:5] !devseln); endsequence sequence schk4b; framen && !irdyn && (!trdyn || !stopn); endsequence assert property (schk4a |-> !lockn[*1:$] ##0 schk4b); --sequence schk6; first_match($fell(gntn) ##[1:8] $fell(framen) ##1 $fell(lockn)); endsequence assert property (schk6.ended |-> ($past(cxben[1:0])==2’b10));

Other non-synthetic assertions appearing throughout the previous chapters are also used to evaluate the checker generator. The up-down counter from Example 4.4 on page 69 contains four assertions respectively labeled UDCNT ASRa to UDCNT ASRd. These assertions are rewritten in SVA below, and used for benchmarking. The default width in the parameter declaration is assumed for the counter’s

234

9 Checkers for SystemVerilog Assertions

output and load buses (eight bits). The first two assertions specify correct internal behavior of the counter, namely that the counter should not count when not instructed to, and that the loading mechanism works properly. The last two assertions were labeled more “environmental” assertions, and specified the fact that in its intended environment, the counter should not roll over from all ones to all zeros (or vice-versa), and that it should never be inactive for ten or more cycles. UDCNT ASRa - UDCNT ASRd: assert property ((!en_ud && !en_load) |=> stable(cnt)); --assert property ((en_load) |-> ##1 (cnt == $past(load))); --assert property ((!en_load) |-> ##1 (!(cnt == ˜$past(cnt) && cnt[width-1]==cnt[0]))); --assert property (not (!en_load && !en_ud)[*10]);

The SVA arbiter assertion in (4.4) on page 71 is also used, and is labeled ARB ASR. That assertion is similar in purpose to assertion SAMP SYSb introduced previously in this subsection. Table 9.2 shows the hardware synthesis results of the checkers for each assertion mentioned in this section, as produced by the MBAC checker generator. From the table, it can be observed that on average, the checkers are generally well balanced between flip-flops and combinational logic usage. The third assertion, SYMP SYSa, is used to ensure that the vector representing a state machine has at most one active

Table 9.2 Benchmarking of non-synthetic SVA assertions in MBAC. Assertion

FF

LUT

MHz

Assertion

FF

LUT

MHz

CPU AHBa CPU AHBb SAMP SYSa SAMP SYSb SAMP SYSc SAMP SYSd SAMP SYSe SAMP SYSf SAMP SYSg SAMP SYSh SAMP SYSi PCIa PCIb PCIc PCId PCIe PCIf PCIg

21 27 1 8 3 4 11 13 24 12 4 10 22 10 10 9 6 4

33 44 9 8 4 7 6 4 14 13 3 12 28 8 10 7 8 3

287 284 N.A. 599 665 665 444 513 290 582 564 386 307 582 574 611 412 611

PCIh PCIi PCIj PCIk PCIl PCIm PCIn PCIo PCIp PCIq PCIr PCIs PCIt UDCNT ASRa UDCNT ASRb UDCNT ASRc UDCNT ASRd ARB ASR

19 5 17 21 11 22 5 9 13 7 7 8 22 10 10 10 10 7

9 5 23 22 12 24 9 9 13 12 7 9 25 7 6 6 10 9

592 472 326 552 665 326 445 667 505 404 465 444 401 348 349 366 667 434

9.3 Experimental Results for SVA Checkers

235

bit, and has no temporal relations other than the fact that the stated condition is checked at each clock cycle. The single flip-flop is used to sample the assertion signal (as is customary in MBAC). The fact that no clock-to-clock path exists in the checker explains why the maximum speed reported by the synthesis tool is not applicable (N.A. in the table). Some checkers require many flip-flops in their implementation because of the complex temporal relations in their assertions, such as CPU AHBb for example, while others require flip-flops to implement the system functions applied to bit vectors, such as SAMP SYSg. It is also interesting to compare the checkers in the last five test cases, namely the four UDCNT ASR cases and the ARB ASR, to their PSL equivalents in Table 8.1. These experiments show that for the given five assertions, the checkers that are produced are likely identical and are independent of the assertion language used.

9.3.2 Benchmarking Sequences and Properties In this section, the test cases used are generic and were generally not created for verifying a specific design. As mentioned in the similar benchmarks in the case of PSL assertions, plain Booleans are used, such as a, b, c, etc., and are in no way a restriction of the tool. In fact, these simple Booleans allow the measurement of the actual checker complexity, in terms of the temporal logic hardware required to implement such operators. Without loss of generality, any Boolean expression can be used in place of the simple signals mentioned here. In the test cases presented in the tables, only SVA properties are shown and the complete assertion, with its verification statement and clocking operator, can be assembled as follows, where Pi is a given property appearing in the tables. assert property (@(posedge clk) Pi ); The same is done for the cover verification statement, where only the property Pi or sequence Si is shown in the tables. As stated in Subsection 4.2.4, verification statements used directly as SystemVerilog statements, i.e. outside the scope of the initial or always procedural blocks, are checked with the same effect as if included in an always block. A first set of test cases is meant to benchmark checkers for a variety of SVA operators. Table 9.3 shows the hardware synthesis results of the checkers for a set of SVA assertions, as produced by the MBAC checker generator. These 25 test cases are taken from the book “A Practical Guide for SystemVerilog Assertions” [171]; the last test case in the table is from Chapter 5, while the others are from Chapter 1. With the exception of two test cases, namely P9 and P18, the checkers are reasonably compact. The two exceptions, which require over one hundred flip-flops each, are rather large because of the complex sequences appearing in the consequent of their suffix implications. These sequences require failure-matching, and thus their

236

9 Checkers for SystemVerilog Assertions

Table 9.3 Benchmarking of SVA properties in MBAC. Property P1 P2 P3 P4

P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 P17

P18 P19 P20 P21 P22 P23 P24 P25

$rose(a) |–> ##[1:3] $rose(b) (a && b) ##1 c |–> ##2 !d (a && b) |–> ##[1:3] c (a && b) |–> ##[0:2] c sequence s1; a ##1 b; endsequence sequence s2; c ##1 d; endsequence s1 |=> s2 s1.ended |–> ##2 s2.ended (c && d) |–> ($past((a&&b),2) == 1’b1) $rose(c) |–> ##2 ((a ##2 b)[*3]) ##2 d $rose(c) |–> ##2 ((a ##[1:4] b)[*3] $rose(c) |–> ##2 (a[*1:$]) ##1 d $rose(c) |–> ##2 (a[–>3]) ##1 d $rose(c) |–> ##2 (a[=3]) ##1 d ##1 !d (a ##[1:2] b) and (c ##[2:3] d) (a ##[1:2] b) intersect (c ##[2:3] d) (a ##[1:2] b) or (c ##[2:3] d) first match((a ##[1:3] b) or (c ##[2:3] d)) $fell(d) |–> (!d) throughout (##1 (!a&&!b) ##1 (c[–>3]) ##1 (a&&b)) sequence s3; ((!a&&!b) ##1 (c[–>3]) ##1 (a&&b)); endsequence sequence s4; $fell(d) ##[5:10] $rose(d); endsequence $fell(d) |–> s3 within s4 disable iff (e) $rose(d) |=> a[=2] ##1 b[=2] ##1 !d 1[*3:5] intersect (a ##[1:$] b ##[1:$] c) ($fell(a) ##[2:5] $fell(b)) |–> ##1 ($fell(c) && $fell(d)) ##0 (!c&&!d)[*4] ##1 (c&&d) ##1 b $fell(a) |–> ##1 (!b && !c && !d) |–> ##[6:10] (a && b && c && d) $fell(a) ##1 (!b && !c && !d) |–> ##[6:10] (a && b && c && d) ($fell(g) ##1 (a||b)) |–> if(a) (c[–>2] ##1 e) else (d[–>2] ##1 f) a |–> not ##[0:15] b

FF LUT MHz 6 4 4 3

4 3 4 3

4 3 5 2 3 1 14 11 105 177 5 3 7 3 9 6 5 6 3 2 8 8 10 11 7 9

606 611 611 611

564 611 667 375 298 610 611 445 473 667 507 474 414

123 254 318 13 25 331 7 7 444 16 13 13 9 16

14 8 8 11 1

384 611 611 438 667

sub-automata require a strong determinization. Test cases P22 and P23 were shown to be equivalent [171], and it is not surprising that the two checkers utilize the same amount of hardware resources. A second set of test cases is benchmarked next, and appears in Table 9.4. These assertions were developed during the testing of MBAC and place the emphasis on exercising the cycle delay operator as well as a variety of other property operators. It should be noted that according to Section 17 in the SVA specification [107], property P20 is not part of the syntax of SVA since the disable iff operator should only be applied to the top-most level in a property. However, as stated in Section 4.2, and as implemented in Subsection 9.2.3, in this work the operator may be used at any level within the property layer of SVA. The assertions in Table 9.4 are also not overly demanding in terms of the size of the checkers, and it is interesting to note that, like in Table 9.3, the largest checker corresponds to an assertion where the within operator is used in the consequent.

9.3 Experimental Results for SVA Checkers

237

Table 9.4 Benchmarking of SVA properties in MBAC, part 2. Property P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 P17 P18 P19 P20 P21 P22 P23 P24 P25 P26

FF LUT MHz

not first match(a or b[*2] or c[*3]) sequence s1; a ##1 $past(b,2) ##1 c; endsequence not (a ##1 s1.ended ##1 c) sequence s2; a ##1 b ##1 c; endsequence not s2.ended if (a) s2.ended not ( a ##[2:5] b ) disable iff ( a ) (##[1:3] b ##[0:3] c) if ( a ) (##[1:3] b ##[0:3] c) not if (a ) (b ##1 c) else (d ##1 e) if ( a ) (##[1:3] b ##[0:3] c) else (a ##1 b) not (a ##1 b ##1 c)[*2] (e ##1 e) and (c ##1 d ##1 a ##1 b ##1 c) (e ##1 e) or (c ##1 d ##1 a ##1 b ##1 c) (e ##1 e) intersect (c ##1 d ##[0:1] a ##[0:1] b) (e) throughout (c ##1 d ##1 a ##1 b ##1 c) (a ##[1:2] b) within (c ##1 d ##[1:3] e ##[0:2] f) (e ##1 e) within (c ##1 d ##1 a ##1 b ##1 c) ((a ##1 b) |–> (c ##1 d)) and ((e ##3 a) |–> (d ##2 b)) ((a ##1 b) |–> (c ##1 d)) or ((e ##3 a) |–> (d ##2 b)) not ((a ##1 b) |–> (c ##1 d)) or ((e ##3 a) |–> (d ##2 b)) ((a ##1 b) |–> (c ##1 d)) or ((e ##3 a) |–> disable iff(c) (d ##2 b)) ((a ##1 b) within (c ##[2:4] d)) first match(a ##1 b) within (c ##[2:4] d) (a ##[1:4] b) intersect (##[2:4] d) not (a[*1] ##1 b[*1:2] ##1 c[–>1] ##1 d[–>1:2] ##1 e[=1] ##1 f[=1:2])[*1:3] not (a[*1] ##1 b[*1:$] ##1 c[–>1] ##1 d[–>1:$] ##1 e[=1] ##1 f[=1:$])[*1:$] not (a[*1] ##1 d[–>1:$] ##1 f)

5

5

665

5

4

387

3 3 6 10 10 3 10 6 4 7 2 4 34 10 8 7 8 7 11 11 5

2 2 1 13 10 3 11 5 5 10 3 5 77 15 4 7 8 8 14 14 3

611 611 611 473 564 665 473 611 514 418 667 514 259 395 514 611 564 473 414 414 667

10

8

480

9 5

8 4

509 546

The assertions used in Subsections 8.6.2 and 8.6.3 were used to evaluate PSL checkers on relatively larger sequences, and are converted to SVA for further experiments in this section. These test cases were split in two modes according to the two major ways in which sequences can appear in assertions, namely in occurrence matching and failure matching contexts. For example, in an assertion of the form assert property (@(posedge clk) s1 |=> s2 ); the antecedent sequence is in occurrence matching context because every occurrence of s1 must trigger a check for s2 to hold. In s2 , for each activation that is received the sequence must occur, and it is instead in a failure matching context. The PSL occurrence matching sequences from Table 8.11 are evaluated first. The sequences were used in assertions of the form assert never s and were developed to evaluate sequence automata appearing in direct pattern-matching mode (occurrence matching). An equivalent form in SVA is shown below, keeping in mind

238

9 Checkers for SystemVerilog Assertions

Table 9.5 Benchmarking occurrence-matching SVA sequences. Sequence. S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17 S18

“assert property (not Sx);”, where Sx is

(a[∗0:$] ##1 b[∗1:3]) or (c ##1 d[∗1:2] ##1 e) a ##1 d ##1 (b ##1 a)[∗2:4] ##1 c ##1 d (a ##1 1’b1[∗0:$] ##1 b) intersect (c[∗1:5] ##1 d) (a|b) ##1 ((c[∗0:$]) intersect (d[∗1:3])) ##0 e (a|b) ##1 ((c[∗0:$]) intersect (d[∗1:6])) ##0 e a ##1 (b ##1 c)[∗0:$] ##1 d ##1 (e ##1 a)[∗1:$] ##1 f (e ##1 e) within (c ##1 d ##1 a ##1 b ##1 c) (a ##1 b[∗1:3]) and (c[∗2:4]) (a ##1 b[∗1:3] ##1 c[∗0:1]) and (d[∗2:4] ##1 e[–>]) ((b ##1 c[∗1:2] ##1 d)[∗1:$]) intersect (b ##1 (e[–>2:3]) ##1 d) ((b ##1 c[∗2:4] ##1 d)[∗1:$]) intersect (b ##1 (e[–>2:4]) ##1 d) (a ##1 b[∗0:$]) ##0 (c[∗0:$] ##1 d) ##1 e (a ##1 b[∗0:$] ##1 c[∗0:$]) ##0 (d[∗0:$] ##1 e[∗0:$]) ##1 f[∗0:$] (a ##1 b[∗0:$] ##1 c[∗0:$]) ##0 (d[∗0:$] ##1 e[∗2:4]) ##1 f[–>] (a[∗0:1] ##1 b[∗0:2]) ##0 (c[∗0:1] ##1 d) (a[∗0:1] ##1 b[∗1:2] ##1 c[∗0:$]) ##0 (d[∗0:1] ##1 e[∗2:4]) (a[∗0:$] ##1 b[∗0:$] ##1 c[∗0:$]) intersect (d[∗5:7]) ((a[∗0:$] ##1 b[∗0:$] ##1 c[∗0:$]) intersect (d[∗5:7])) ##0 (c[–>])

FF LUT MHz 4 12 6 4 7 6 11 5 10 12 20 4 5 8 2 6 13 14

3 11 6 3 6 6 10 6 16 12 21 5 7 15 2 7 15 16

564 559 667 665 665 564 564 504 325 456 456 418 352 338 665 392 506 445

that assertions appearing directly as verification statements in SystemVerilog are implicitly checked over the entire execution (implicit always, as discussed in Subsection 4.2.4). The PSL statement is on the left, the SVA is on the right. assert never Si ;

≡

assert property (not Si );

The clocking specification is omitted in both cases and is assumed to be of the form (posedge clk). The SVA occurrence matching sequences are shown in Table 9.5, along with the synthesis results for their checkers, as produced by MBAC. The checkers for the SVA assertions in this test set are functionally identical to the checkers for their PSL equivalents, as proved using the Cadence SMV model checker with the equivalence checking approach described in Section 8.1. The experimental results also show that the hardware metrics for the SVA checkers are identical to the PSL checkers, as expected. The checkers are sensitive to the rising edge of the clock signal, and are initialized with an active low reset signal. The failure matching sequences from Table 8.14 are evaluated next. The sequences were used in assertions of the form assert always a |=> s and were developed to evaluate sequence automata appearing in failure-matching mode. An equivalent form in SVA is shown below.

≡

assert always a |=> Sx ; assert property (a |=> Sx );

(PSL) (SVA)

9.3 Experimental Results for SVA Checkers

239

Table 9.6 Benchmarking failure-matching SVA sequences. Sequence. S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17 S18

“assert property (a |=> Sx);”, where Sx is

b ##1 c[∗0:$] ##1 d (b ##1 c ##1 d) and (e ##1 d ##1 b) e ##1 d ##1 (b ##1 e)[∗2:4] ##1 c ##1 d b ##1 ((c[∗0:4]) and (d)) ##1 e b ##1 ((c[∗0:6]) and (d)) ##1 e ((c ##1 d)[∗1:$]) intersect (e[–>2]) ((c ##1 d)[∗1:$]) intersect (e[–>4]) ((c ##1 d)[∗1:$]) intersect (e[–>6]) ((c[∗1:2])[∗1:$]) intersect (e[–>2]) ((c[∗1:2] ##1 d)[∗1:$]) intersect (e[–>2]) ((c[∗1:3] ##1 d)[∗1:$]) intersect ((e[–>2:3]) ##1 d) ((b ##1 c[∗1:2] ##1 d)[∗1:$]) ##0 ((e[–>]) ##1 d) ((b ##1 c[∗1:2] ##1 d)[∗1:$]) ##0 (b ##1 (e[–>2:3]) ##1 d) b ##1 ((c[∗0:2]) ##1 (d[∗0:2]))[∗0:$] ##1 e ((c[∗1:2] ##1 d)[∗1:$]) and (e[–>2]) (e ##1 e) within (c ##1 d ##1 a ##1 b ##1 c) b ##1 (c ##1 d)[∗0:$] ##1 e ##1 (f ##1 b)[∗1:$] ##1 g (b ##1 c[∗0:$]) ##0 (d[∗0:$] ##1 e) ##1 f

FF LUT MHz 3 4 15 7 9 5 9 13 3 9 20 22 65 3 4 12 10 9

4 5 21 9 13 6 13 18 3 22 52 59 222 4 4 16 22 17

514 445 329 441 395 509 326 324 564 311 278 259 250 610 472 386 314 280

The SVA failure matching sequences are shown in Table 9.6, along with the synthesis results. With the exception of S13, the checkers for the SVA assertions were shown to be functionally equivalent to their PSL counterparts, using the formal equivalence checking approach mentioned before. In the case of S13, proving functional equivalence of two checkers with 65 states proved to be too large for the amount of memory available in the machine used (512 MB RAM). The experimental results show that the hardware metrics for the SVA checkers are identical to the PSL checkers, including for the S13 test case, which is an indication that both checkers are likely equivalent. It should be noted that for test cases S4 and S5, an additional set of parentheses was needed to limit the scope of the and operator, which has lower precedence than the cycle delay operator; in PSL the & operator has higher precedence than the concatenation operator ;. To complete the SVA experimental results, a few test assertions are also benchmarked for the cover directive. The properties used in this experiment are taken from the previous result tables in this section so that the difference between assertion checkers and coverage checkers can be observed, in terms of the hardware metrics of the circuits. The assertions and synthesis results are shown in Table 9.7. The results show that in all but three cases, the coverage checkers require one flipflop less than the assertion checker. In the three other cases the number of flip-flops is identical to those reported in the previous tables. On average, the combinational logic required in the case of the coverage checkers is slightly inferior to the regular assertion checkers. In the test cases it should be noted that properties P2 and P12–P17 are actually seen as sequences by the tool, and the separate coverage computation for sequences is employed, as shown in Algorithm 9.3. Also of note are the

240

9 Checkers for SystemVerilog Assertions

Table 9.7 Benchmarking SVA’s coverage verification statement. Sequence. P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 P16 P17 P18

“cover property (Px);”, where Px is

$rose(c) |–> ##2 ((a ##2 b)[*3]) ##2 d first match((a ##[1:3] b) or (c ##[2:3] d)) disable iff (e) $rose(d) |=> a[=2] ##1 b[=2] ##1 !d $fell(a) |–> ##1 (!b && !c && !d) |–> ##[6:10] (a && b && c && d) a |–> not ##[0:15] b disable iff ( a ) (##[1:3] b ##[0:3] c) if ( a ) (##[1:3] b ##[0:3] c) else (a ##1 b) ((a ##1 b) |–> (c ##1 d)) and ((e ##3 a) |–> (d ##2 b)) ((a ##1 b) |–> (c ##1 d)) or ((e ##3 a) |–> (d ##2 b)) not ((a ##1 b) |–> (c ##1 d)) or ((e ##3 a) |–> (d ##2 b)) ((a ##1 b) |–> (c ##1 d)) or ((e ##3 a) |–> disable iff(c) (d ##2 b)) first match(a ##1 b) within (c ##[2:4] d) a ##1 d ##1 (b ##1 a)[∗2:4] ##1 c ##1 d (e ##1 e) within (c ##1 d ##1 a ##1 b ##1 c) (a ##1 b[∗1:3] ##1 c[∗0:1]) and (d[∗2:4] ##1 e[–>]) ((b ##1 c[∗1:2] ##1 d)[∗1:$]) intersect (b ##1 (e[–>2:3]) ##1 d) (a ##1 b[∗0:$] ##1 c[∗0:$]) ##0 (d[∗0:$] ##1 e[∗2:4]) ##1 f[–>] a |=> ( ((b ##1 c[∗1:2] ##1 d)[∗1:$]) ##0 ((e[–>]) ##1 d) )

FF LUT MHz 15 11 14 14 17 11 11 9 7 8 7 12 13 12 11 13 9 23

9 11 27 10 2 17 14 4 6 7 7 9 12 11 18 13 16 57

522 442 329 562 562 348 353 561 522 522 562 561 522 561 287 456 338 250

synthesis results for cases P13 to P17, where the PSL equivalent of these cases were benchmarked in the coverage checkers in Table 8.13 (cases S2, S7, S9, S10 and S14 respectively). The checkers for both cases require identical amounts of circuit primitives, in both the number of flip-flops and logic lookup tables.

9.3.3 Using SVA Checkers with Formal Verification Tools The assertion checkers produced by the checker generator can also be used in formal verification, where a proof of conformance or a counterexample can be derived for each assertion. An important point that we would like to emphasize is that with checkers like ours, no support of SVA (or any other assertion language) is required whatsoever by a formal verification tool. In this section a case study attempts to prove that a design under verification respects a given specification. In the example, the specification concerns a handful of assertions meant to capture the proper behavior of a few key characteristics of the design. The proof mechanism consists of instantiating the checkers in the design and asserting through model checking that their outputs always remain low. If the checkers can be proven to never trigger, then the properties that they represent can be deduced to be true. This is a complete formal verification and does not suffer from the coverage limitations inherent to simulation and dynamic verification. The model checker used in the experiments is Cadence SMV [42]. In this type of experiment,

9.3 Experimental Results for SVA Checkers

241

clk_i

ack_o

rst_i

dat_o[7:0]

cyc_i stb_i adr_i[2:1]

Simple Programmable Interrupt Controller

int_o

we_i dat_i[7:0] irq[7:0]

Fig. 9.1 Interface ports of the programmable interrupt controller.

the checkers are a means of allowing a model checker to indirectly support assertion languages. The design to be verified is the Simple Programmable Interrupt Controller by Richard Herveille [95]. The controller has a relatively simple interface consisting of a few handshaking signals, an eight bit data bus and four control registers. The design is coded in Verilog and consists of approximately fifty lines of code. The interface ports of the Programmable Interrupt Controller (PIC) are shown in the diagram in Figure 9.1. The majority of signals are related to the bus interface, which in this case corresponds to an eight bit Wishbone protocol. The Wishbone bus interface protocol is an open standard maintained by opencores.org, and is used extensively in many projects in the OpenCores database. The interface supports multiple masters and slaves, and is based on a synchronous communication protocol. The PIC is designed as a Wishbone slave [141], and the port signals used are described as follows: • • • • • • • • • • •

clk i: clock signal (input), the design is sensitive to the rising edge rst i: reset signal (input), active low cyc i: cycle signal (input), indicates active cycles during a transaction stb i: strobe signal (input), a slave-select indicating that the transaction is targeted to this particular slave adr i: address bus (input), only two bits are required for accessing four registers in this example we i: write enable signal (input), active high (a low signal corresponds to a read) dat i: data bus (input), data in and out are separate dat o: data bus (output), data in and out are eight bit busses in this example ack o: acknowledge signal (output), used by the slave to indicate that the bus transaction terminated successfully irq: interrupt request signals (input), a four bit vector in this example int o: interrupt (output), interrupt signal from the slave

The last two signals are not part of the Wishbone interface, and are specific the the PIC example. Of note in this type of interface is the separate data in and data out

242

9 Checkers for SystemVerilog Assertions

busses, the strobe and acknowledge signals for simple handshaking, and the main signals of interest for the PIC: the interrupt request input signals and the actual interrupt signal output that is typically connected to the main bus master. The interrupt controller features are as follows: 1. 2. 3. 4.

Each interrupt request line can be edge-sensitive or level-sensitive Each interrupt request line has a programmable polarity Each interrupt line can be masked separately for the handling of priority Each pending interrupt can be cleared separately

In the front end of the interrupt handling is a first sampling of the irq[i] signals by a set of D-type flip-flops, the output of which is the lirq vector. For level sensitive interrupts, this signal is used directly by the further stages in the design. The latched interrupt lines are again sample by flip-flops to produce the delayed interrupt vector called dirq. With positive polarity, an edge is detected for a given interrupt request i with the following expression (9.4)

lirq[i] && !dirq[i]

When the signal goes from low to high in two consecutives cycles, a rising edge has occurred. The expression for negative polarity is similar, with the negation symbol ! placed instead on the left side of the && in the expression above. The edgen register is used to control the edge/level detection, where a onebit represents an edge sensitive interrupt and a zero-bit implies a level sensitive interrupt. For level sensitive interrupts, the polarity register pol is such that a onebit indicates an active-high interrupt and a zero-bit indicates an active-low interrupt request. For edge sensitive interrupts, the behavior discussed above concerning the change in value over two consecutive cycles applies. The mask register can be used to mask any interrupt by setting its corresponding bit to logic-1. When an interrupt occurs, its pending bit is asserted and remains asserted until it is cleared by writing a one-bit in the respective position. All other 0-bits in the vector that is written via the bus interface have no effect on the pending register. These four registers are mapped in the two-bit address space as shown in Figure 9.2. The four control registers are read and written via the eight-bit data bus using the established Wishbone protocol. In this example the four most significant data bits

addr_i[2:1]

3

Register

00

Edge Enable

01

Polarity

10

Mask

11

Pending

0

Fig. 9.2 Register map of the programmable interrupt controller, with four interrupt request inputs.

9.3 Experimental Results for SVA Checkers

243

Flip-flop boundary irq_i

lirq

dirq

Interrupt output pipeline polarity, edgen

Front-end pipeline for interrupt inputs

irq_event dat_i, pending

pending

int_o

mask

Fig. 9.3 Pipelines used in the design of the programmable interrupt controller.

in the read/write transactions have no effect given that the control registers are four bits wide. The functional design of the PIC is essentially pipeline based, as illustrated in Figure 9.3. All arrows in the figure represent signal vectors. From the figure it can be determined that an interrupt on one of the bits in irq has a latency of four clock cycles before it appears at the output int o. When an edge triggered interrupt request is used, the latency is actually five clock cycles from the cycle preceding the actual request signal, given the previous value used in the edge detection (dirq). Another way to measure the pipeline latency is to follow the path starting with irq, leading through lirq and then to the output, where it can be observed that four flip-flop boundaries are crossed. For the edge sensitive interrupts, the path from start to finish passing through the delayed interrupt request dirq crosses five flipflop boundaries. Visualizing the pipelines is particularly important for specifying correct assertions when performing the verification of the PIC. In Figure 9.3, the additional signals below the output pipeline are added in a manner to reveal where they are sampled, and thus when they have an effect on the interrupt result. For example, the mask register is sampled with the pending vector to yield the output value int o at the end of the chain. In the previous flipflop boundary, the pending vector itself is sampled, along with the dat i and irq event vectors to form the pending register. The dat i vector is only sampled when a write is issued to the pending register, in a manner such that it can only reset the bits in that register. As anticipated, the pending register works in a sample-and-hold fashion, thus maintaining the interrupt until it has been cleared by an external agent. The irq event signal is an internal vector wherein each bit position indicates the detection of an interrupt for a given request line, and it has a single clock cycle latency with respect to the sampling of the latched and delayed vectors lirq and dirq. The edgen and pol registers are also used in the logic to build the irq event register, and are also sampled at the same clock edge as the two interrupt vectors. The details of the ack o signal are omitted since this signal is not used in the set of assertions that are studied here. The first two assertions developed in this case study for the verification of the PIC are used to ensure that an interrupt present at an input is guaranteed to cause an

244

9 Checkers for SystemVerilog Assertions

interrupt to be signaled at the int o output. These two SVA assertions are shown below, and are labeled PIC ASRa and PIC ASRb. PIC ASRa, PIC ASRb: assert property ( @(posedge clk_i) ( (($rose(irq[1]) ##1 edgen[1]) or (irq[1] ##1 !edgen[1])) ##0 pol[1] ##2 !mask[1] ) |-> (##1 int_o) ); --assert property ( @(posedge clk_i) ( (($fell(irq[1]) ##1 edgen[1]) or (!irq[1] ##1 !edgen[1])) ##0 !pol[1] ##2 !mask[1] ) |-> (##1 int_o) );

The first assertion models the successful detection of an interrupt on the first request line (irq[1]), when positive polarity is used. The first line in the assertion is the typical assert verification statement with the clocking expression for the assertion. In the second line, the detection of an edge or level sensitive interrupt request is modeled. This consists of a disjunction of two expressions, one for each case. Because of the way the edgen register is used in the assertion, both sides of the or are mutually exclusive and only one side can be true at a given evaluation point. For the level sensitive side, the irq[1] input is directly evaluated; for the edge sensitive side, the $rose() system function is used to detect the behavior shown in (9.4) for a logic-0 to logic-1 succession. The constraint for the choice of edge vs. level sensitivity applies only on the clock cycle following the occurrence of the irq signal, hence the single clock cycle delays used in each side of the or to separate the matching with edgen. The reason for this ##1 cycle delay can be observed by noticing the relative placement of the signals in the pipelines, compared to the flip-flop boundaries, in Figure 9.3. The polarity is also sampled simultaneously with the edgen signal and is thus fused with the first portion of the assertion, using the ##0 cycle delay. For the interrupt to trigger the output, the last remaining constraint is that the corresponding mask bit must be de-asserted. Since the mask intervenes two cycles further in the pipeline, as witnessed in Figure 9.3, the proper delay is inserted in the sequence (##2). At this point all the preconditions to the interrupt being signaled are met, and the antecedent for an implication is formed. If the antecedent is true, then the interrupt must be signaled. This is modeled using a suffix implication. Once more, because of the pipelined nature of the PIC, the int o signal is delayed by one clock with respect to the pending stage in the pipeline. This explains the cycle delay in the consequent, keeping in mind that the implication used was of the overlapping kind. If the non-overlapping implication is used the cycle delay is not required, but was kept here to emphasize the clock cycle timing in the assertion. In short, this assertion says that if an interrupt request is made on channel 1, then the interrupt will be signaled at the output of the PIC. The second assertion models the behavior in the case of a negative interrupt polarity. In the edge sensitive case, the $fell() system function is appropriately called upon, while in the level sensitive case a negation is used (!irq[1]). Although

9.3 Experimental Results for SVA Checkers

245

these two assertions apply only to the first bit in the interrupt request vector, they are repeated for the other bits to ensure that all inputs lead to an interrupt output. The next two assertions are used to model an opposite characteristic in the PIC, namely that under certain conditions the unit should never report an interrupt. These two assertions are shown next, and are labeled PIC ASRc and PIC ASRd. PIC ASRc, PIC ASRd: assert property (@(posedge (irq==4’h0 ##1 pol==4’hF --assert property (@(posedge (irq==4’hF ##1 pol==4’h0

clk_i) ##1 pending==4’h0) |-> (##2 !int_o)); clk_i) ##1 pending==4’h0) |-> (##2 !int_o));

The assertions operate on the full vectors and are not restricted to a single interrupt line. The first assertion (PIC ASRc) indicates that if all request inputs are at logic-0 under a positive polarity, and there are no pending interrupts, then no interrupt should be reported. Once more, the key to understanding the temporal relations in this assertion is the pipeline described in Figure 9.3. The timing between irq and pol was explained in the first two assertions and is identical in this case. The pending vector is sampled in the irq event stage, and although it could be sampled two clocks later in the assertion, sampling it one cycle after the polarity is also valid since the dat i and irq event vectors can not activate it: by design, the former can not set any bit in the pending register, and the latter is supposed to be false since no interrupt requests were made. The interrupt output int o being two stages downstream, the consequent in the suffix implication must be offset by the same amount, hence the cycle delay with ##2. Consequently with the initial verification objective, the consequent indicates that no interrupt should be reported. The second assertion above (PIC ASRd) operates on the same principle, with the exception that active low interrupts are tested. A stronger version of the assertion can be made by allowing for different polarities in different bit positions, and does not assume that the polarity is the same for all inputs. Such an assertion would subsume the previous two assertions, and could be specified as follows: ($past(irq)==∼pol ##1 pending ==4’h0) |-> (##2 !int o)

(9.5)

Since assertions are also meant as a comment for other developers, it is sometimes preferable to use more assertions that are simpler to understand, and this was the reason for leaving the initial two statements in PIC ASRc and PIC ASRd. Following this logic, it could be argued that the first two assertion in PIC ASRa and PIC ASRb could each have been split for separating the edge vs. level sensitive cases, thereby yielding four assertions that could be simpler to understand. An assertion can be devised for stating yet another condition where an interrupt output should never be signaled: if a write is made to the mask register with all ones,

246

9 Checkers for SystemVerilog Assertions

then as long as the mask register is not written to again the PIC should not report any interrupts. PIC ASRe: sequence WR_MASK; we_i && cyc_i && stb_i && adr_i==2’b10; endsequence --assert property (@(posedge clk_i) (WR_MASK && dat_i[4-1:0]==4’hF ##1 !(WR_MASK)[*1:$]) |-> (##1 !int_o));

The assertion first defines the sequence for a write operation to the mask register. Even though the sequence expression is a simple Boolean value and does not contain any temporal operators, declaring separate expressions can greatly simplify the reading of an assertion. The assertion itself then proceeds to specify that if the mask register is set to all ones, and then followed by a series of cycles where the register is not written to again, then the PIC’s interrupt output should remain low. The unbounded repetition [*:$] used makes it such that the consequent is continually triggered throughout consecutive cycles where !(WR MASK) is true. Since the mask value that is written takes effect in the clock cycle following the write transaction from the bus, the proper offset is added to the consequent. The last assertion used in this experiment is used to ensure that when an interrupt was processed and has its pending bit cleared, the bit does indeed get reset in the next cycle. Although trivial in intent, this example reveals that certain obscure behaviors have the tendency of surfacing when using formal verification, where no stone is left unturned. The first assertion below, labeled PIC ASRf, is the first attempt at capturing the requirement for the clearing of the pending bits. In this case, only the assertion corresponding to the first request line is shown. PIC ASRf, PIC ASRg: sequence WR_PENDING; //a write transaction to "pending" register we_i && cyc_i && stb_i && adr_i==2’b11; endsequence --assert property (@(posedge clk_i) (WR_PENDING && dat_i[4-1:0]==4’h1) |-> (##1 !pending[1])); --assert property (@(posedge clk_i) (WR_PENDING && dat_i[4-1:0]==4’h1 && $past(lirq[1]==!pol[1])) |-> (##1 !pending[1]));

The second assertion was written in anticipation that the first would not succeed. The intuition is such that although the pending bit is to be reset, if an interrupt occurs at the right time (or wrong time, depending on the point of view), then the pending

9.3 Experimental Results for SVA Checkers

247

bit could be kept from resetting and the first assertion would fail. The model checker can find this type of counterexample, and the assertion is purposely kept to show an example of an assertion failure. The first assertion’s antecedent models the fact that when a write operation is made to the pending register to clear the bit for the first interrupt input, then the bit does indeed take the value 0 after it is sampled at the clock edge by its flip-flop. The second assertion is similar, and also adds a constraint that no interrupt request was made at the proper time point. The pipeline diagram (Figure 9.3) also shows why it is appropriate to utilize the $past() operator for this condition. With the seven assertions shown thus far, the formal verification can now be undertaken. The set of assertions do not cover all the requirements of the PIC and in no way can guarantee the entire correctness of the design. Suffice to say that as more and more assertions are added and proved, the confidence in the design increases. As indicated, the verification strategy consists of instrumenting the checkers within the design under verification, and then attempting to prove that the outputs of the checkers never report any assertion violations. The entire procedure is as follows: 1. 2. 3. 4.

Write the correctness specifications in the form of assertions Use the checker generator to produce checker circuits from the assertions Instantiate the checkers in the design to be verified Add a model checking property stating that the output of the checkers never trigger 5. Perform the model checking At this point, step 1 above has been performed, and using the MBAC tool the checkers can be readily generated. The assertions are entered directly in the Verilog source code of the PIC, and MBAC generates a checker for each one. The module generated contains seven checkers, with one output vector containing the seven assertion checker outputs (assertion signals). The checker module is added to the PIC’s source code file, and the instantiation code produced by MBAC is pasted in the PIC module’s source code. Step 3 is complete. The model checker used in this case study is Cadence SMV [42], which is freely available from the company website, and which does not support modern assertion languages. To complete step four, separate model checking assertions are added to specify the inactivity of the checker outputs. For the first assertion, this can be done using the expression: assert A1: (!rst i | !pic psl vu1 out[1]); Similar expressions are repeated for the other six assertions. Although the entire assertion signal vector, in this case pic psl vu1 out, can be tested for equivalence to zero, separate model checking assertions avoid having to verify all the checkers simultaneously when a single property is to be re-verified during debugging. Although model checkers typically support LTL properties, which would require the use of the G operator (globally, or always), in Cadence SMV the property above is implicitly tested globally, as opposed to only the first state of the model.

248

9 Checkers for SystemVerilog Assertions Design verification by model checking Design Under Verification (ex: PIC) Assertions Output MBAC

Checkers

assert A1: (!rst_i | !Output);

Fig. 9.4 Verification approach using the assertion checkers in model checking.

The model checking assertions (A1–A7), not to be confused with the SVA verification assertions (PIC ASRa–PIC ASRf), state that when the active low reset is deactivated, then the assertion signals should be at logic-0. The polarity of the assertion signals in the checkers is such that assertion violations are signaled with logic-1 on the checker outputs. Steps 1 to 4 are illustrated in Figure 9.4. Other than the model checking assertions, only a few extra initial statements are added to the design under verification to ensure that the design is initialized in an appropriate reset state. If this precaution is not taken, and since there is no testbench and no simulation scenario to supply, the model checker can often find unrealistic counterexamples by assuming arbitrary initial values. Step 5 consists of performing the model checking for all the properties stated (A1 to A7). Model checking proves all the assertions, including the compacted assertion in (9.5), with the exception of PIC ASRf (as expected). This assertion states that when a write is made to clear the pending bit for a given interrupt request, the bit will indeed take the value logic-0 in the next cycle. The anticipated counterexample is that of an interrupt request being made at precisely the right time, and given its higher priority than the write operation, the pending bit is not cleared. The counterexample reported by the model checker is presented in Figure 9.5, showing only the most relevant signals. The explanation of the counterexample is summarized next. Each number in the enumeration below describes what is sampled in the clock edges in Figure 9.5, in relation to the counterexample. A simulation trace is shown to help visualize the state-based counterexample. 1. Perform reset. 2. Set negative polarity. During the entire trace it should be noted that the interrupt request inputs are kept at logic-0, and setting the polarity to zero makes it such that in the next cycle, irq event will register a valid interrupt. 3. Make irq #1 edge sensitive. This is useless and is just meant to consume a cycle. It is also on this edge that the level sensitive interrupt is seen (the new value for edgen will take effect in the next cycle) 4. Clear pending bit of irq #1 by writing 8’h1 to register 3. The clearing of the related pending bit, pending[1], should take effect in the next cycle.

9.3 Experimental Results for SVA Checkers

249

clk_i rst_i cyc_i stb_i 0

adr_i

1

0

3

0

we_i 00

dat_i irq

0

edgen

0

pol

f

mask

f

pending

0

lirq

0

01

00

1 0

f

dirq

0

irq_event

0

f

e

pic_psl_vu1_out 0

1

2

3

4

5

6

Fig. 9.5 Counterexample trace for PIC ASRf in the programmable interrupt controller.

5. The pending bit is not cleared! On this clock edge (#5) the checker observes the failure and asserts its output signal in the next cycle. To summarize the verification case study, seven assertions were developed for verifying the simple programmable interrupt controller. Checkers were created using the MBAC tool, and were instantiated in the design to be verified. Subsequently, by model checking it was proven that for six of these checkers (hence assertions), the design does meet the specification. For the PIC ASRf case, the model checking failed not because of a design flaw, but because the assertion itself was not properly modeled. This illustrates the point that assertions often require some work to get them right, and it is not always a design flaw that is responsible for a violation. Nevertheless, even such an exercise in which assertions need to be rectified leads to the better understanding of the specification, and sometimes can even have the effect analogous to “mutation testing” [151], by which it can detect additional faults. In this case study, any of the successful assertions could have been shown to fail by injecting various forms of design errors in the PIC’s source code. In general, performing formal verification with checkers is relatively straightforward for safety properties. There is also the case of liveness properties, as well as strong properties (in the PSL language); they are not as straightforward to use in model checking with the assertion checkers developed herein for dynamic verification. The end-of-execution (EOE) signal employed in the MBAC checkers for these types of properties does pose problems in the model checking scenario where liveness is typically associated with infinite traces.

Chapter 10

Conclusions and Future Work

Abstract This chapter concludes and presents a variety of perspectives for future research and for design practices of employing assertion checkers towards quality improvement in IC design, not just through pre-fabrication verification, but throughout the development and life cycle of the products.

10.1 Conclusion As assertion-based design becomes increasingly important in IC design, a tool for generating efficient hardware assertion checkers can find several valuable uses. This book has introduced the methods and algorithms for the generation of hardware assertion checkers, as well as a variety of enhancements to the checkers for improving the debugging process and usability in assertion-based verification. It is also shown how checkers can be used to facilitate the debugging of devices in the postfabrication stage, and also as permanent additions for runtime (on-line) monitoring. A tool called MBAC was created that allows assertions to be converted into circuitlevel checkers. This tool is modular – it can be added to various other tools in the EDA flow, to facilitate easier support assertions there as well. For instance, simulators, FPGA synthesis or various debug tools would instantly be able to deal with assertions if paired with MBAC. Checkers also allow certain types of properties to be easily integrated to formal verification tools that do not support the assertion languages. The implementation of sequences, both in PSL and SVA, required the development of specific algorithms for many operators that are not typically used in conventional regular expressions. Sugaring rules in sequences helped to reduce the number of operators that needed to be supported in the kernel of the checker generator. Although these sugaring rules were used directly as rewrite rules, the same approach was generally not possible for the sugaring operators in properties. The simple subset guidelines restrict the full language of PSL to obtain properties more suitable 251

252

10 Conclusions and Future Work

for dynamic verification, with monotonically advancing time. A set of rewrite rules was devised to implement the majority of PSL’s large array of property operators. This was an important aspect that allowed all of PSL’s simple subset operators to be supported in the tool. A two-level symbol alphabet was devised and is used at the core of the automaton-based approach. Minimization and nondeterminism were also shown to play an important role in producing resource efficient checkers. The nondeterminism brought upon by the symbolic alphabet encoding was also an important point taken into account in the development of the automata algorithms. The semantics of all operator implementations in the checker generator, whether by algorithms or rewrite rules, was particularized for optimal error reporting as required in run-time verification scenarios. In the debugging enhancements portion of the research, multiple additions and modification were proposed to facilitate debugging with checkers. Activity monitors play a key role in observing trivial validity, and completion mode helps to build confidence in the coverage of the test suite. Assertion and cover counters help build more detailed result metrics, and signal dependencies help diagnose the true cause of an assertion failure by indicating the relevant signals used in an assertion. A more efficient implementation of the eventually! operator, compared to the rewrite rule, was also developed and was based on automata splitting and the use of logic gates mixed with automata. Extending the use of checkers beyond pre-fabrication verification was also explored by presenting various on-line and off-line self test scenarios based on the inclusion of assertion checkers. Post-fabricated silicon can benefit from the inclusion of checkers, whereby assertions can be exercised under realistic operating conditions, where timing issues can be truly revealed. The idea of using a checker generator and assertions as a means of performing certain types of circuit design was also put forth, where an example scenario in redundancy control was shown. Many of the themes explored in this work can be applied to other assertion languages as well, not just PSL and SVA. Sequential regular expressions are used in many verification languages, and the automata framework and algorithms devised can apply to those cases as well. The rewrite rules developed for properties can also be used in other verification tools to allow a quick implementation of the majority of operators. This book has shown how to create resource-efficient circuit-level checkers from assertions, for use in hardware verification, silicon debugging and on-line monitoring. Compared to the most widely known checker generator, FoCs, the MBAC checker generator shows important improvements in terms of the resource usage, behavior and capability of the assertion circuits that are produced. The circuit size of checkers is a particularly important parameter when multiple checkers are to be included in valuable silicon area. In general, adding checkers to a Device Under Verification (DUV) can not be done without impacting the timing of the signals in the original circuit. The effects on specific DUV circuits were not explored in this book, as the emphasis was placed on the complexity of checkers that are instrumented within them. When comparing

10.2 Future Work

253

to other tools, smaller assertion checkers lessen the negative impacts on the DUV precisely because of our emphasis on the efficiency of checker circuit generation. An upper bound on the area penalty of checkers in hardware is obtained by assuming that no sharing of common circuit primitives takes place. Since the checkers only monitor the internal circuit signals, the extra loading can at worst add small delays, which can be kept low by following standard design techniques. For instance, for the signals in the critical path that are monitored by an assertion, small buffers can be inserted to minimize the loading of the circuit under debug. As assertions become ubiquitous for improving the quality in areas such as design verification, silicon debugging, on-line monitoring, and also as a potential new way of performing design specification, the ability to synthesize assertions into circuits will continue to grow in importance across the field of electronic design automation. With human ambition constantly pushing back the bounds of design complexity, we should not forget that the task of producing quality electronic designs will also become increasingly more challenging.

10.2 Future Work The research on checker generation that was performed in this work can be extended in a variety of directions. The following lists show examples of particular aspects that can be continued in future research, and are grouped into five themes.

10.2.1 Optimizations and Improvements The efficient implementation of the eventually! operator leads to a few thoughts regarding optimizations in the checker generator, while other proposed optimizations are related to automata and counters. • The fourth assertion in the up-down counter example (Example 4.4) is of the form assert never b[*10];, where b is a Boolean expression. The implementation requires ten states, thus ten flip-flops are used. However, because this assertion is non-overlapping, i.e. there are no activations coming from an arbitrarily occurring antecedent, a four bit counter could be used instead. In this example the counter would count the number of consecutive b s, and if ten or more are seen, an error would be signaled. Such optimizations could be implemented, and were mentioned also in a document pertaining to the PROSYD project [104], where optimizing checkers with non-overlapping instances is proposed. • The more efficient implementation of eventually! required the use of automata splitting, and was shown to be an improvement to the rewrite rule also developed for this operator. However, when a property is specified using the same syntax as the right side of the rewrite rule, namely {[+]:seq}!, the tool could be made to automatically detect this and also switch to the technique using splitting.

254

10 Conclusions and Future Work

• The efficient implementation of eventually! using automata splitting was made possible by the addition of logic gates to the signals in the automata. Further exploration might reveal other instances where breaking up automata and using logic gates and flip-flops around these automata could produce smaller checkers. • Table 8.10 (and many other tables in Chapter 8) revealed that although two different checkers may be proven to be functionally equivalent, the synthesis tools are not always able to reduce both to circuits of the same size. In the examples in Table 8.10, the checkers produced as a result of using the rewrite rule were larger. Logic then dictates that if the checker generator was able to produce one version that yielded a smaller circuit than its equivalent other version, then the checker generator must be doing an optimization that the synthesis tool is not doing. This fact could be the starting point for perhaps more optimizations in synthesis tools. • In general, NFAs are more compact than their equivalent DFAs. Adding a form of DFA to NFA conversion could help produce even smaller checkers; however, converting DFAs to NFAs and minimizing NFAs [115] is not computationally efficient, not to mention a hard problem [112]. A heuristic approach could perhaps allow some form of nondeterminism to be applied even if not complete. DFA to NFA conversion could benefit the automata that undergo weak determinization (in minimization), and also those that undergo strong determinization (in failure matching).

10.2.2 Checkers and Debugging The debug enhancements presented in Section 7.4 can be further extended as proposed below. Another example application of checkers is also proposed, for use in embedded logic analyzers. • The assertion threading enhancement could benefit from more aggressive evaluations in the checker generator where multiple aspects of assertion threading could be automatically controlled. For example, automatically calculating the appropriate number of threads to instantiate could be performed. If sequences are finite, then perfect separation of concurrent activity could be achieved. If infinite sequences are to be threaded, an estimation could be made to tradeoff circuit size with visibility. Currently, the number of threads to be used is controlled via a command line parameter to the tool. • In the same line of thought as the previous point, assertion threading could also be augmented with concurrency detection logic, to show when activity is being overlapped in a thread. For example, if an activation enters a thread that is still processing the previous activation, no guarantees can be made as to the order of the failures, therefore determining the exact cause of a failure is more difficult. • Currently, top-level sequences can be threaded and/or monitored. Activity monitors could be generalized for arbitrary sub-properties and sub-sequences, so that any valid sub-expression in an assertion could be monitored. For example, in

10.2 Future Work

255

properties of the form always a -> p until b, generating an activity signal for property p could allow it to be checked for trivial validity. Generalizing assertion threading in the same manner could also be explored. The difficulty with these types of refinements is that after applying automata operators such as sequence intersection, the argument automata are no longer intact and separable. This makes monitoring arbitrary sub-expressions more challenging. • The checker generator could be a central component in a debugging tool that would automate the instrumentation of embedded logic analyzers into designs under test. The assertion checkers would play the role of implementing the triggering mechanism. In this way, the user could specify triggering conditions using assertions, and the checkers would be instrumented as part of the embedded trace memory and would serve to control the sampling points. • In Subsection 9.2.3 it was mentioned that the debugging enhancements that make use of automata splitting such as assertion threading and activity monitors do not apply to the compilation of SVA checkers since some of the property operators are incompatible with the precondition automata strategy. To make these debug enhancements applicable to SVA, in their current form, a full automata-based implementation that makes no use of extra logic gates would need to be developed. For assertion threading, an automaton based dispatcher would have to be created to send the activations to the replicated argument automata. In this case and for activity monitors, a mechanism for preserving a sub-portion of an automaton would likely be required such that it is kept intact during minimization.

10.2.3 Assertion Language Compilation The assertion languages themselves, whether PSL or SVA, also present some challenges for future developments. • Many designs make use of multiple clock signals, especially in heterogeneous SoC designs. Adding support for the “@” clocking operator would allow the specification of assertions with multiple clock domains [133]. The support of Boolean clocks that are level sensitive, as opposed to edge sensitive, could also be explored, as well as asynchronous assertion checkers. The use of clock control signals for debugging purposes [44] could be explored. • As witnessed in Section 4.1 where the overlapping until was relaxed to allow a full property as its left argument, one can be led to the question of whether simple subset restrictions on other operators can be easily lifted as well, in the guidelines for simulation-friendly PSL. This leads to the idea of developing a stronger derivation of what is and what is not easily simulatable, and what are the precise language bounds that can be placed on PSL while still remaining suitable for dynamic verification. • As witnessed in the SVA automaton implementation of negation and disjunction, these language operators apply to full properties and are not an obstacle in the checker generator. This could lead to a strategy for supporting negation and

256

10 Conclusions and Future Work

disjunction of full properties in the case of PSL. This would likely render the automata splitting strategy inapplicable and would require new techniques for the debug enhancements that utilize this strategy. • The addition of LTL-like operators is planned for future versions of SVA. The algorithms developed in this book for both PSL and SVA offer a good foundation upon which to add these operators to SVA checker generation. Just as many of the algorithms developed for PSL were re-used in the case of SVA, the same is expected to apply to upcoming SVA language extensions. • Local variables in SVA are causing significant concerted efforts to develop efficient compilation strategies for dynamic and formal verification [122]. At the time of writing of this book, the IEEE 1850 PSL Committee is working on adding local variables to PSL sequences [73], so the support for local variables will become an important issue for PSL as well.

10.2.4 Testing the Checkers Test generation and testbenches are essential for dynamic verification, but also to ensure the correctness of the checkers themselves. • It would be important to develop a universally accepted set of benchmark assertions for evaluating the performance of checker generators. The test assertions would be shared between researchers and would be used extensively for benchmarking, analogous to the TPTP library [162] (Thousands of Problems for Theorem Provers), used in the field of automated theorem proving. • When the checkers themselves need to be evaluated in simulation, it is necessary to derive suitable test sequences. When two different checkers for the same assertion are exercised, such as failure-matching sequences in Subsection 8.6.3, we need to exercise checkers well to be able to determine behavioral differences. For the simulation-based comparison, the testbench often performs biased random simulation. Explicit test generation can be designed to reveal interesting test cases with which to exercise the checkers. Further, the vacuity analysis could be used to systematically increase the quality of specifications and testbenches [8]. • Keeping in mind that the quality of the products employing ICs gets impaired by both manufacturing faults and designer errors (or tool errors), further convergence of techniques in verification and manufacturing testing would be useful in getting a hold on quality issues. Many a manager in the industry dreams of being able to resolve both testing and verification headaches by a single unified procedure. The fact is that this has been achieved to a significant degree in some places, so we remain positive on the prospects. We would want to further reuse the testing techniques in verification, akin to [151], and also to improve test practices by the use of assertion checkers. With assertions and their checkers being employed throughout the design cycle, as well as the product lifetime, we feel that more could be achieved towards these goals.

10.2 Future Work

257

• Test generation to exercise assertions will be hampered by difficulties in controlling and observing the signals used in assertions, thus classical ATPG-like techniques would be needed to express the assertion coverage goals in terms of primary inputs and outputs. The use of satisfiability (SAT) for test pattern generation [150] will be explored. Further, the non-standard use of reversibility [176] for improving controllability and observability could be of use. • Using checkers for verifying safety properties in formal verification with model checking was explored in Subsection 9.3.3. For liveness properties, the checkers developed in this work make use of the End-of-Execution (EOE) signal in a way as to transform the liveness requirement into a type of safety requirement. A somewhat similar transformation was studied for formal verification in the model checking of LTL properties [21], and could be a starting point for adapting the strategy for utilizing liveness checkers in formal verification, even though these are tuned to dynamic verification.

10.2.5 Beyond RTL Assertion Languages Applying the concepts in this book beyond RTL (Register Transfer Level) assertion languages also presents opportunities to further enlarge the scope of this research. • The use of PSL/SVA and a checker generator could be explored for use in highlevel synthesis, similar to the Production Based Specification work [160] and the high-level synthesis of synchronous languages such as Esterel [67], or even the concepts applied in the Protocol Compiler. Exploiting the high-level expressiveness of assertion languages and the circuit-synthesis capabilities of the checker generator could lead to new high-level hardware design practices. • As the need to model at higher levels of abstraction is only going to increase, it would be interesting to see how the developments introduced in this book could be applied to create checkers for transaction-level assertions [66], and applied in the development of future complex SoCs/NoCs [47], where the larger scale and the elaborated software components dictate more comprehensive verification and debug strategies. Further, the incorporation of debug methods for software, as well as the software testing techniques [5] will be of significant importance in extending the usability of the hardware assertion-based techniques in system design.

Appendix A

Example for Up-Down Counter

This appendix contains the source files used in the up-down counter studied in Example 4.4, as well as the resulting output produced by MBAC. The counter to be verified is shown below in the Verilog language in the file udcounter.v. The assertions used to verify the counter are coded in PSL in the udcounter.psl file that follows. Additionally, the set of SVA assertions is added inline to the design file. These assertions were used in Subsection 9.3.1 for benchmarking the SVA checkers. MBAC can concurrently process both PSL and SVA assertions that are simultaneously present in the same design. The third file in this example contains the assertion checkers produced by the checker generator (udcounter psl.v). The file contains two Verilog modules with four checkers each, corresponding to SVA assertions and the PSL assertions respectively. The checkers are also expressed in Verilog HDL, and allow the assertions to be embedded in the design under verification during hardware emulation in the verification stages, or in the fabricated integrated circuit for at-speed silicon debugging. The command given to the checker generator in this example is as follows: MBAC udcounter.psl udcounter.v

udcounter.v: //---MBAC example--//This is a simple up-down counter that we want to verify //The PSL assertions for this example are in udcounter.psl //The SVA assertions are in the module below //To produce the checkers run: "mbac udcounter.psl udcounter.v" //The result is udcounter_psl.v, containing two Verilog modules: // one module contains SVA checkers, the other has PSL checkers module udcounter(cnt, load, en_load, en_ud, up_ndown, clk,reset); parameter width = 8;

259

260

A Example for Up-Down Counter

output reg [width-1:0] cnt; input [width-1:0] load; input en_load, en_ud, up_ndown, clk, reset; always @(posedge clk) if (!reset) cnt <= 0; else if (en_load) cnt <= load; else if (en_ud) if (up_ndown) cnt <= cnt+1; else cnt <= cnt-1; //if no count nor load, value should not change assert property (@(posedge clk) (!en_ud && !en_load) |=> stable(cnt)); //ensure load works assert property (@(posedge clk) (en_load) |-> ##1 (cnt == $past(load))); //no roll-over assert property (@(posedge clk) (!en_load) |-> ##1 (!(cnt == ˜$past(cnt) && cnt[width-1]==cnt[0]))); //no inactivity assert property (@(posedge clk) not (!en_load && !en_ud)[*10]); endmodule //udcounter

udcounter.psl: vunit vu1(udcounter){ default clock = (posedge clk); //if no count nor load, value should not change assert always {!en_ud && !en_load} |=> stable(cnt); //ensure load works assert always en_load -> next (cnt == prev(load)); //no roll-over assert always !en_load -> next (!(cnt == ˜prev(cnt) && cnt[width-1]==cnt[0])); //no inactivity assert never (!en_load && !en_ud)[*10]; }

A Example for Up-Down Counter

261

udcounter psl.v: //Generated by MBAC v2.01 //23-3-2008, 22h 13m 19s //-------------------------------------------//RESET_POLARITY_SYMBOL, set to ! (blank) for active low (high) ‘define MBACRPS ! //Assertion circuit for vunit: inline //vunit is bound to module: udcounter module udcounter_psl_inline (udc_inline_out, reset, en_ud, en_load, cnt, clk, load); parameter width = 8; output [4:1] udc_psl_inline_out; input reset, en_ud, en_load, clk; input [width - 1:0] cnt; input [width - 1:0] load; reg [width - 1:0] wire [2:0] s3s; reg [2:0] s3sq; reg [width - 1:0] wire [2:0] s5s; reg [2:0] s5sq; reg [width - 1:0] wire [2:0] s7s; reg [2:0] s7sq; wire [10:0] s8s; reg [10:0] s8sq; wire s2; reg ASR_1, ASR_2,

s1;

s4;

s6;

ASR_3, ASR_4;

assign udc_psl_inline_out={ASR_4, ASR_3, ASR_2, ASR_1}; //--------------//ASR_1 : assert property ( @(posedge clk) // ( ! en_ud && ! en_load ) |=> stable(cnt) ); //--------------always @(posedge clk) s1<=cnt; assign s2 = s1 == cnt; always @(posedge clk) if (‘MBACRPS reset) s3sq<=3’h4; else s3sq<=s3s; assign s3s={1’b1, ((! en_ud) && (! en_load)), (s3sq[1] && !(s2))}; always @(posedge clk) if (‘MBACRPS reset) ASR_1<=0; else ASR_1 <= (s3s[0]); //--------------//ASR_2 : assert property ( @(posedge clk) ( en_load ) |-> ##1 // ( cnt == $past(load) ) ); //---------------

262

A Example for Up-Down Counter

always @(posedge clk) s4<=load; always @(posedge clk) if (‘MBACRPS reset) s5sq<=3’h4; else s5sq<=s5s; assign s5s={1’b1, en_load, (s5sq[1] && !((cnt == s4)))}; always @(posedge clk) if (‘MBACRPS reset) ASR_2<=0; else ASR_2 <= (s5s[0]); //--------------//ASR_3 : assert property ( @(posedge clk) ( !en_load ) |-> ##1 // ( ! ( cnt == ˜$past(cnt) && cnt[width-1] == cnt[0] ) ) ); //--------------always @(posedge clk) s6<=cnt; always @(posedge clk) if (‘MBACRPS reset) s7sq<=3’h4; else s7sq<=s7s; assign s7s={1’b1, !(en_load), (s7sq[1] && ((cnt == (˜ s6)) && (cnt[width-1] == cnt[0])))}; always @(posedge clk) if (‘MBACRPS reset) ASR_3<=0; else ASR_3 <= (s7s[0]); //--------------//ASR_4 : assert property ( @(posedge clk) // not ( ! en_load && ! en_ud )[*10] ); //--------------always @(posedge clk) if (‘MBACRPS reset) s8sq<=11’h400; else s8sq<=s8s; assign s8s={1’b1, ((! en_load) && (! en_ud)), (s8sq[9] && ((! en_load) && (! en_ud))), (s8sq[8] && ((! en_load) && (! en_ud))), (s8sq[7] && ((! en_load) && (! en_ud))), (s8sq[6] && ((! en_load) && (! en_ud))), (s8sq[5] && ((! en_load) && (! en_ud))), (s8sq[4] && ((! en_load) && (! en_ud))), (s8sq[3] && ((! en_load) && (! en_ud))), (s8sq[2] && ((! en_load) && (! en_ud))), (s8sq[1] && ((! en_load) && (! en_ud)))}; always @(posedge clk) if (‘MBACRPS reset) ASR_4<=0; else ASR_4 <= (s8s[0]); endmodule //udcounter_psl_inline /*Instantiation code: udcounter_psl_inline #(width) i_udcounter_psl_inline ( udc_psl_inline_out, reset, en_ud, en_load, cnt, clk, load); */ //End of circuit(s) for vunit: inline

//Assertion circuit for vunit: vu1 //vunit is bound to module: udcounter

A Example for Up-Down Counter

263

module udcounter_psl_vu1 (udcounter_psl_vu1_out, reset, clk, en_ud, en_load, cnt, load); parameter width = 8; output [4:1] udcounter_psl_vu1_out; input reset, clk, en_ud, en_load; input [width - 1:0] cnt; input [width - 1:0] load; reg [width - 1:0] wire [2:0] s3s; reg [2:0] s3sq; reg [width - 1:0] wire [2:0] s5s; reg [2:0] s5sq; reg [width - 1:0] wire [2:0] s7s; reg [2:0] s7sq; wire [10:0] s8s; reg [10:0] s8sq; wire s2; reg ASR_1, ASR_2,

s1;

s4;

s6;

ASR_3, ASR_4;

assign udcounter_psl_vu1_out={ASR_4, ASR_3, ASR_2, ASR_1}; //--------------//ASR_1 : assert always {! en_ud && ! en_load} |=> stable(cnt); //--------------always @(posedge clk) s1<=cnt; assign s2 = s1 == cnt; always @(posedge clk) if (‘MBACRPS reset) s3sq<=3’h4; else s3sq<=s3s; assign s3s={1’b1, ((! en_ud) && (! en_load)), (s3sq[1] && !(s2))}; always @(posedge clk) if (‘MBACRPS reset) ASR_1<=0; else ASR_1 <= (s3s[0]); //--------------//ASR_2 : assert always en_load -> next ( cnt == prev(load) ); //--------------always @(posedge clk) s4<=load; always @(posedge clk) if (‘MBACRPS reset) s5sq<=3’h4; else s5sq<=s5s; assign s5s={1’b1, en_load, (s5sq[1] && !((cnt == s4)))}; always @(posedge clk) if (‘MBACRPS reset) ASR_2<=0; else ASR_2 <= (s5s[0]); //--------------//ASR_3 : assert always !en_load -> next // ( !( cnt == ˜prev(cnt) && cnt[width - 1] == cnt[0] ) );

264

A Example for Up-Down Counter

//--------------always @(posedge clk) s6<=cnt; always @(posedge clk) if (‘MBACRPS reset) s7sq<=3’h4; else s7sq<=s7s; assign s7s={1’b1, !(en_load), (s7sq[1] && ((cnt == (˜ s6)) && (cnt[width-1] == cnt[0])))}; always @(posedge clk) if (‘MBACRPS reset) ASR_3<=0; else ASR_3 <= (s7s[0]); //--------------//ASR_4 : assert never ( ! en_load && ! en_ud )[*10]; //--------------always @(posedge clk) if (‘MBACRPS reset) s8sq<=11’h400; else s8sq<=s8s; assign s8s={1’b1, ((! en_load) && (! en_ud)), (s8sq[9] && ((! en_load) && (! en_ud))), (s8sq[8] && ((! en_load) && (! en_ud))), (s8sq[7] && ((! en_load) && (! en_ud))), (s8sq[6] && ((! en_load) && (! en_ud))), (s8sq[5] && ((! en_load) && (! en_ud))), (s8sq[4] && ((! en_load) && (! en_ud))), (s8sq[3] && ((! en_load) && (! en_ud))), (s8sq[2] && ((! en_load) && (! en_ud))), (s8sq[1] && ((! en_load) && (! en_ud)))}; always @(posedge clk) if (‘MBACRPS reset) ASR_4<=0; else ASR_4 <= (s8s[0]); endmodule //udcounter_psl_vu1 /*Instantiation code: udcounter_psl_vu1 #(width) i_udcounter_psl_vu1 ( udcounter_psl_vu1_out, reset, clk, en_ud, en_load, cnt, load); */ //End of circuit(s) for vunit: vu1

References

1. Yael Abarbanel, Ilan Beer, Leonid Glushovsky, Sharon Keidar, and Yaron Wolfsthal. FoCs: Automatic Generation of Simulation Checkers from Formal Specifications. In Proceedings of the 12th International Conference on Computer Aided Verification (CAV’00), pages 538–542, 2000. 2. Miron Abramovici, Paul Bradley, Kumar Dwarakanath, Peter Levin, Gerard Memmi, and Dave Miller. A Reconfigurable Design-for-Debug Infrastructure for SoCs. In Proceedings of the 43rd Design Automation Conference (43rd DAC), pages 7–12, 2006. 3. Miron Abramovici, Melvin Breuer, and Arthur Friedman. Digital Systems Testing & Testable Design. Computer Science Press, New York, 1990. 4. Hussain Al-Asaad, Brian Murray, and John P. Hayes. Online BIST for Embedded Systems. IEEE Design & Test of Computers, 15(4):17–24, 1998. 5. Paul Ammann and Jeff Coffutt. Introduction to Software Testing. Cambridge University Press, New York, 2008. 6. Roy Armoni, Limor Fix, Alon Flaisher, Rob Gerth, Boris Ginsburg, Tomer Kanza, Avner Landver, Sela Mador-Haim, Eli Singerman, Andreas Tiemeyer, Moshe Y. Vardi, and Yael Zbar. The ForSpec Temporal Logic: A New Temporal Property-Specification Language. In Proceedings of the 2002 International Conference on Tools and Algorithms for Construction and Analysis of Systems (TACAS 2002), pages 296–211, 2002. 7. Roy Armoni, Dmitry Korchemny, Andreas Tiemeyer, Moshe Y. Vardi, and Yael Zbar. Deterministic Dynamic Monitors for Linear-Time Assertions. In Proceedings of the Workshop on Formal Approaches to Testing and Runtime Verification (FATES/RV’06), volume 4262 of Lecture Notes in Computer Science, Springer, pages 163–177, 2006. 8. Thomas Ball and Orna Kupferman. Vacuity in Testing. In Proceedings of the 2nd International Conference on Tests and Proofs, 2008. 9. Ilan Beer, Shoham Ben-David, Cindy Eisner, Yechiel Engel, Raanan Gewirtzman, and Avner Landver. Establishing PCI Compliance Using Formal Verification: a Case Study. In Proceedings of the 14th Annual IEEE International Phoenix Conference on Computers and Communications, pages 373–377, 1995. 10. Ilan Beer, Shoham Ben-David, Cindy Eisner, and Yoav Rodeh. Efficient Detection of Vacuity in Temporal Model Checking. Formal Methods in System Design, 18(2):141–163, 2001. 11. Ilan Beer, Shoham Ben-David, Daniel Geist, Raanan Gewirtzmann, and Michael Yoeli. Methodology and System for Practical Formal Verification of Reactive Hardware. In Proceedings of the 6th International Conference on Computer Aided Verification (CAV’94), pages 182–193, 1994. 12. Boris Beizer. Software Testing Techniques. Van Nostrand Reinhold, New York, second edition, 1990. 13. Shoham Ben-David, Dana Fisman, and Sitvanit Ruah. Automata Construction for Regular Expressions in Model Checking. Technical Report H-0229, IBM, 2004.

265

266

References

14. Shoham Ben-David, Dana Fisman, and Sitvanit Ruah. The Safety Simple Subset. In Proceedings of the 1st International Haifa Verification Conference (HVC’05), pages 14–29, 2005. 15. Janick Bergeron. Writing Testbenches: Functional Verification of HDL Models. Springer, New York, second edition, 2003. 16. Janick Bergeron. Writing Testbenches using SystemVerilog. Springer, New York, 2006. 17. Janick Bergeron, Eduard Cerny, Alan Hunter, and Andy Nightingale. Verification Methodology Manual for SystemVerilog. Springer, New York, 2005. 18. G´erard Berry and Ravi Sethi. From Regular Expressions to Deterministic Automata. Theoretical Computer Science, 48(1):117–126, 1986. 19. Valeria Bertacco. Scalable Hardware Verification with Symbolic Simulation. Springer, New York, 2005. 20. Jayaram Bhasker. A Verilog HDL Primer. Star Galaxy Publishing, Allentown, PA, 1997. 21. Armin Biere, Cyrille Artho, and Viktor Schuppan. Liveness Checking as Safety Checking. In Proceedings of the Seventh International Workshop on Formal Methods for Industrial Critical Systems (FMICS’02), 2002. 22. Dominique Borrione. Personal communications. November, 2006. 23. Dominique Borrione, Miao Liu, Katell Morin-Allory, Pierre Ostier, and Laurent Fesquet. On-Line Assertion-Based Verification with Proven Correct Monitors. In Proceedings of the 3rd ITI International Conference on Information & Communications Technology (ICICT 2005), pages 123–143, 2005. 24. Dominique Borrione, Miao Liu, Pierre Ostier, and Laurent Fesquet. PSL-Based Online Monitoring of Digital Systems. In A. Vachoux, editor, Applications of Specification and Design Languages for SoCs, chapter 1. Springer, Netherlands, 2005. 25. Marc Boul´e. Assertion-Checker Synthesis for Hardware Verification, In-Circuit Debugging and On-Line Monitoring. Ph.D. thesis, McGill University, Montr´eal, Qu´ebec, Canada, 2008. 26. Marc Boul´e, Jean-Samuel Chenard, and Zeljko Zilic. Adding Debug Enhancements to Assertion Checkers for Hardware Emulation and Silicon Debug. In Proceedings of the 24th IEEE International Conference on Computer Design (ICCD’06), pages 294–299, 2006. 27. Marc Boul´e, Jean-Samuel Chenard, and Zeljko Zilic. Checkers in Verification, Silicon Debug and In-Field Diagnosis. In Proceedings of the 8th International Symposium on Quality Electronic Design (ISQED’07), pages 613–618, 2007. 28. Marc Boul´e, Jean-Samuel Chenard, and Zeljko Zilic. Debug Enhancements in AssertionChecker Generation. IET Computers and Digital Techniques – Special Issue on Silicon Debug and Diagnosis, 1(6): 669–677, 2007. 29. Marc Boul´e and Zeljko Zilic. Incorporating Efficient Assertion Checkers into Hardware Emulation. In Proceedings of the 23rd IEEE International Conference on Computer Design (ICCD’05), pages 221–228, 2005. 30. Marc Boul´e and Zeljko Zilic. Efficient Automata-Based Assertion-Checker Synthesis of PSL Properties. In Proceedings of the 2006 IEEE International High Level Design Validation and Test Workshop (HLDVT’06), pages 69–76, 2006. 31. Marc Boul´e and Zeljko Zilic. Efficient Automata-Based Assertion-Checker Synthesis of SEREs for Hardware Emulation. In Proceedings of the 12th Asia and South Pacific Design Automation Conference (ASP-DAC2007), pages 324–329, 2007. 32. Marc Boul´e and Zeljko Zilic. Automata-Based Assertion-Checker Synthesis of PSL Properties. ACM Transactions on Design Automation of Electronic Systems (ACM-TODAES), 13(1):Article 4, January 2008. 33. Stephan Bourduas, Jean-Samuel Chenard, and Zeljko Zilic. A RTL-Level Analysis of a Hierarchical Ring Interconnect for Network-on-Chip Multi-Processors. In Proceedings of the International System-on-a-Chip Design Conference (ISOCC’06), 2006. 34. Daniel Brand. Verification of Large Synthesized Designs. In Proceedings of the International Conference on Computer-Aided Design (ICCAD’93), pages 534–537, 1993. 35. Randal Bryant. Graph-Based Algorithms for Boolean Function Manipulation. IEEE Transactions on Computers, C-35(8):677–691, 1986.

References

267

36. Janusz Brzozowski. Canonical Regular Expressions and Minimal State Graphs for Definite Events. Mathematical Theory of Automata, 12 of MRI Symposia Series, Polytechnic Press, Polytechnic Institute of Brooklyn, N.Y.:529–561, 1962. 37. Janusz Brzozowski. Derivatives of Regular Expressions. Journal of the ACM, 11(4):481–494, 1964. 38. Adam Buchsbaum, Raffaele Giancarlo, and Jeffery Westbrook. On the Determinization of Weighted Finite Automata. Lecture Notes in Computer Science, 1443:482–493, 1998. 39. Doron Bustan, Dana Fisman, and John Havlicek. Automata Construction for PSL. Technical Report MCS05-04, The Weizmann Institute of Science, 2005. 40. Cadence Design Systems. ATI Technologies Selects Cadence Palladium II for Verification of Advanced DTV Chips. www.cadence.com/company/newsroom/press releases/pr.aspx?xml=021505 ati, 2005. 41. Cadence Design Systems. Incisive Palladium Family with Incisive XE Software (Datasheet). www.cadence.com/datasheets/IncisivePalladiumII ds.pdf, 2005. 42. Cadence Design Systems. The Cadence SMV Model Checker. www.cadence.com/ webforms/cbl software/index.aspx, 2007. 43. Kai-Hui Chang, Wei-Ting Tu, Yi-Jong Yeh, and Sy-Yen Kuo. A Simulation-Based Temporal Assertion Checker for PSL. In IEEE International Midwest Symposium on Circuits and Systems (MWSCAS’03), 2003. 44. Atanu Chattopadhyay and Zeljko Zilic. Built-in Clock Skew System for On-line Debug and Repair. In Proceedings of the ACM/IEEE Design Automation and Test in Europe (DATE’08), 6 pages, 2008. 45. Pankaj Chauhan, Edmund M. Clarke, Yuan Lu, and Dong Wang. Verifying IP-Core Based System-On-Chip Designs. IEEE ASIC, September 1999. 46. Cyrille Chavet. Modelisation and Validation of a Chip Embeded Architecture for Secure Applications. Master’s thesis, TIMA Laboratory - VDS Group, Grenoble France, 2003. 47. Jean-Samuel Chenard, Stephan Borduas, Nathaniel Azuelos, Marc Boul´e, and Zeljko Zilic. Hardware Assertion Checkers in On-Line Detection of Faults in a Hierarchical-Ring Network-On-Chip. In Poster Presentation at the Design Automation and Test in Europe (DATE 2007) Workshop on Diagnostic Services in Networks-on-Chips, 2007. 48. Alessandro Cimatti, Marco Roveri, Simone Semprini, and Stefano Tonetta. From PSL to NBA: a Modular Symbolic Encoding. In Proceedings of Formal Methods in Computer Aided Design (FMCAD’06), pages 125–133, 2006. 49. Koen Claessen and Johan Martensson. An Operational Semantics for Weak PSL. In Proceedings of the 5th International Conference on Formal Methods in Computer-Aided Design (FMCAD’04), pages 337–351, 2004. 50. Edmund Clarke, Orna Grumberg, Hiromi Hiraishi, Somesh Jha, David Long, Kenneth McMillan, and Linda Ness. Verification of the Futurebus+ Cache Coherence Protocol. In Proceedings of the 11th International Symposium on Computer Hardware Description Languages and their Applications, pages 5–20, 1993. 51. Edmund Clarke, Orna Grumberg, and Doron Peled. Model Checking. MIT Press, Cambridge, MA, 2000. 52. Ben Cohen, Srinivasan Venkataramanan, and Ajeetha Kumari. Using PSL/ Sugar for Formal and Dynamic Verification. VhdlCohen Publishing, Los Angeles, CA, 2004. 53. Ben Cohen, Srinivasan Venkataramanan, and Ajeetha Kumari. SystemVerilog Assertions Handbook. VhdlCohen Publishing, Los Angeles, CA, 2005. 54. John Cooley. DVCon’04 Trip Report - A Census of 137 Engineers on Design Verification Tool Use. www.deepchip.com/posts/dvcon04.html, 2004. 55. John Cooley. The 2007 DeepChip Verification Census - A Census of 818 Engineers on Design Verification Tool Use. www.deepchip.com/posts/dvcon07.html, 2007. 56. Thomas Cormen, Chaarles Leiserson, and Ronald Rivest. Introduction to Algorithms. McGraw-Hill New York, 1999. 57. Maxime Crochemore, Christophe Hancart, and Thierry Lecroq. Algorithms on Strings. Cambridge University Press, Cambridge, 2007.

268

References

58. Philip Crosby. Quality: The Changing of Minds. www.wppl.org/wphistory/ PhilipCrosby/QualityTheChangingOfMinds.pdf, 1986. 59. Philip Crosby. Quality is Free - If You Understand It. www.wppl.org/wphistory/ PhilipCrosby/QualityIsFreeIfYouUnderstandIt.pdf, 1988. 60. Anat Dahan, Daniel Geist, Leonid Gluhovsky, Dmitry Pidan, Gil Shapir, Yaron Wolfsthal, Lyes Benalycherif, Romain Kamdem, and Younes Lahbib. Combining System Level Modeling with Assertion Based Verification. In Proceedings of the 6th International Symposium on Quality of Electronic Design (ISQED 2005), pages 310–315, 2005. 61. Sayantan Das, Rizi Mohanty, Pallab Dasgupta, and Partha Chakrabarti. Synthesis of System Verilog Assertions. In Proceedings of the 2006 Conference on Design Automation and Test in Europe (DATE’06), pages 70–75, 2006. 62. Kausik Datta and P.P. Das. Assertion Based Verification Using HDVL. In Proceedings of the 17th International Conference on VLSI Design (VLSI Design 2006), pages 319–325, 2004. 63. Nachum Dershowitz and Zohar Manna. Proving Termination with Multiset Orderings. Communications of the ACM, 22(8):465–476, 1979. 64. Christophe Devaucelle. Formal Verification of a Framer OC-768 (40 Gbits/s). Technical Report, IBM Micro-electronics, Essones Labs, Corbeil-Essonnes, France, 2001. 65. Matthew Dwyer, George Avrunin, and James Corbett. Property Specification Patterns for Finite-State Verification. In Proceedings of the 2nd Workshop on Formal Methods in Software Practice (FMSP’98), pages 7–15, 1998. 66. Wolfgang Ecker, Volkan Esen, Thomas Steininger, Michael Velten, and Michael Hull. Specification Language for Transaction Level Assertions. In Proceedings of the 2006 IEEE International High Level Design Validation and Test Workshop (HLDVT’06), pages 77–84, 2006. 67. Stephen Edwards. High-level Synthesis from the Synchronous Language Esterel. In Proceedings of the International Workshop on Logic and Synthesis (IWLS), 2002. 68. Cindy Eisner and Dana Fisman. A Practical Introduction to PSL. Springer, New York, 2006. 69. Cindy Eisner, Dana Fisman, John Havlicek, Yoad Lustig, Anthony McIsaac, and David Van Campenhout. Reasoning with Temporal Logic on Truncated Paths. In Proceedings of the 15th Computer-Aided Verification Conference (CAV’03), pages 27–39, 2003. 70. EVE Team. SystemVerilog-Assertion-Based Verification with ZeBu Hardware-Assisted Platform. Synopsys 15th EDA Interoperability Developers’ Forum, April 7th,Santa Clara, CA 2005. www.synopsys.com/news/events/devforums/2005/apr/ presentations/16 SVA with EVE ZeBu.pdf. 71. Robert Floyd. Assigning Meanings to Programs. Proceedings of American Society on Applied Mathematics, 19:19–31, 1967. 72. Robert Floyd and Jeffrey Ullman. The Compilation of Regular Expressions into Integrated Circuits. Journal of the ACM (JACM), 29(3):603–622, 1982. 73. Harry Foster. Personal communication. March, 2008. 74. Harry Foster and Adam Krolnik. Creating Assertion-Based IP. Springer, New York, 2007. 75. Harry Foster, Adam Krolnik, and David Lacey. Assertion-Based Design. Kluwer, Norwell, MA, second edition, 2004. 76. Harry Foster, Kenneth Larsen, and Mike Turpin. Introducing The New Accellera Open Verification Library Standard. Proceedings of the 2006 Design and Verification Conference (DVCon 2006), 2006. 77. Ambar Gadkari and S. Ramesh. Automated Synthesis of Assertion Monitors using Visual Specifications. In Proceedings of the 2005 Conference on Design Automation and Test in Europe (DATE’05), pages 390–395, 2005. 78. Subbu Ganesan. Supplementing VCS-based Simulations with High-Performance HardwareAssisted Verification. The Synopsys Verification Avenue Technical Bulletin, 4(4), 2004. 79. Eric Gascard. From Sequential Extended Regular Expressions to Deterministic Finite Automata. In Proceedings of the 3rd ITI International Conference on Information and Communications Technology (ICICT 2005), pages 145–157, 2005.

References

269

80. Daniel Geist, Avner Landver, and Bruce Singer. Formal Verification of a Processor’s Bus Interface. Technical Report, IBM, August 8th 1996. 81. Amir M. Gharehbaghi, Benyamin Hamdin Yaran, Shaahin Hessabi, and Maziar Goudarzi. An Assertion-Based Verification Methodology for System-Level Design. Computers and Electrical Engineering, 33(4):269–284, 2007. 82. Stefan-Valentin Gheorghita. The Art of Translating Sugar to an Automata Language. Master’s thesis, Politehnica University of Bucharest, Romania, 2003. 83. Stefan-Valentin Gheorghita and Radu Grigore. Constructing Checkers from PSL Properties. In Proceedings of the 15th International Conference on Control Systems and Computer Science (CSCS15), volume 2, pages 757–762, 2005. 84. Amit Goel and William Lee. Formal Verification of an IBM CoreConnect Processor Local Bus Arbiter Core. In Proceedings of the 37th Design Automation Conference (37th DAC), pages 196–200, 2000. 85. Mike Gordon. Validating the PSL/Sugar Semantics Using Automated Reasoning. Formal Aspects of Computing, 15(4):406–421, 2003. 86. Mike Gordon. PSL Semantics in Higher Order Logic. In Proceedings of the 5th International Workshop on Designing Correct Circuits (DCC’06), 2004. 87. Mike Gordon, Joe Hurd, and Konrad Slind. Executing the Formal Semantics of the Accellera Property Specification Language by Mechanised Theorem Proving. In D. Geist and E. Tronci, editors, Correct Hardware Design and Verification Methods, LNCS 2860, pages 200–215. Springer, Berlin/Heidelberg, Oct. 2003. 88. Daniel Grobe and Rolf Drechsler. Checkers for SystemC Designs. In 2nd ACM & IEEE International Conference on Formal Methods and Models for Co-Design (MEMOCODE 2004), pages 171–178, 2004. 89. Ali Habibi, Amjad Gawanmeh, and Sofiene Tahar. Assertion Based Verification of PSL for SystemC Designs. In Proceedings of the 2004 International Symposium on System-on-Chip, pages 177–180, 2004. 90. Hesham Hallal, Alex Petrenko, Andreas Ulrich, and Sergiy Boroday. Using SDL Tools to Test Properties of Distributed Systems. In Proceeddings of the Formal Approches to Testing of Software (FATES’01), Workshop of the International Conference on Concurrency Theory (CONCUR’01), pages 125–140, 2001. 91. Faisal Haque, Jonathan Michelson, and Khizar Khan. The Art of Verification with SystemVerilog Assertions. Verification Central, 2006. 92. John Havlicek, Dana Fisman, Cindy Eisner, and Erich Marschner. Mapping SVA to PSL. www.eda.org/vfv/docs/mapping.pdf, 2003. 93. John Havlicek and Yaron Wolfsthal. PSL and SVA: Two Standard Assertion Languages Addressing Complimentary Engineering Needs. Proceedings of the 2005 Design and Verification Conference (DVCon 2005), Session 5, Paper 1, 2005. 94. John L. Hennessy and David A. Patterson. Computer Architecture: A Quantitative Approach. The Morgan Kaufmann Series in Computer Architecture and Design, San Francisco, CA, third edition, 2003. 95. Richard Herveille. Simple Programmable Interrupt Controller. www.opencores.org, 2002. 96. C. A. R. Hoare. Assertions: A Personal Perspective. IEEE Annals of the History of Computing, 25(2):14–25, 2003. 97. Kay Hofmann, Philipp Bucher, Laurent Falquet, and Amos Bairoch. The PROSITE Database, its Status in 1999. Nucleic Acids Research, 27(1):215–219, 1999. 98. Gerard Holzmann. The SPIN Model Checker: Primer and Reference Manual. AddisonWesley, Reading, MA, 2000. 99. John Hopcroft. An n log n Algorithm for Minimizing the States in a Finite Automaton. In Z. Kohavi and A. Paz, editors, The Theory of Machines and Computations, pages 189–196. Academic, New York, 1971. 100. John Hopcroft, Rajeev Motwani, and Jeffrey Ullman. Introduction to Automata Theory, Languages and Computation. Addison-Wesley, Reading, MA, second edition, 2000.

270

References

101. Yu-Chin Hsu, Bassam Tabbara, Yimg-An Chen, and Furshing Tsai. Advanced Techniques for RTL Debugging. In Proceedings of the 40th Design Automation Conference (40th DAC), pages 362–367, 2003. 102. Alan Hu, Jeremy Casas, and Jin Yang. Efficient Generation of Monitor Circuits for GSTE Assertion Graphs. In Proceedings of the 2003 IEEE/ACM International Conference on Computer-Aided Design (ICCAD’03), pages 154–159, 2003. 103. IBM AlphaWorks. FoCs Property Checkers Generator, version 2.04. www.alphaworks. ibm.com/tech/FoCs, 2007. 104. Dmitry Pidan, Sharon Keidar-Barner, Mark Moulin and Dana Fisman. Optimized Algorithms for Dynamic Verification. Property Based System Design (PROSYD) - Deliverable 3.2/5, www.prosyd.org/twiki/view/Public/DeliverablePageWP3, 2005. 105. Shoham Ben-David and Avigail Orni. Property-by-Example Guide: a Handbook of PSL/Sugar Examples. Property Based System Design (PROSYD) - Deliverable 1.1/3, www.prosyd.org/twiki/view/Public/DeliverablePageWP1, 2005. 106. IEEE Std. 1647-2006. IEEE Standard for the Functional Verification Language ‘e’. Institute of Electrical and Electronic Engineers, New York, 2006. 107. IEEE Std. 1800-2005. IEEE Standard for SystemVerilog – Unified Hardware Design, Specification, and Verification Language. Institute of Electrical and Electronic Engineers, New York, 2005. 108. IEEE Std. 1850-2005. IEEE Standard for Property Specification Language (PSL). Institute of Electrical and Electronic Engineers, New York, 2005. 109. IEEE Std. 1850-200x Working Group. Simple Subset Issue #99, Group E.1. Issues To Be Addressed in IEEE 1850-200x PSL, 2006. 110. IEEE Std. 1850-200x Working Group. Unaddressed Issue #146. Issues To Be Addressed in IEEE 1850-200x PSL, 2006. 111. ISO 8402:1995. Quality Management and Quality Assurance. International Organization for Standardization, Geneva, Switzerland, 1995. 112. Tao Jiang and B. Ravikumar. Minimal NFA Problems are Hard. SIAM Journal on Computing, 22(6):1117–1141, 1993. 113. Naiyong Jin and Chengjie Shen. Dynamic Verifying The Properties of The Simple Subset of PSL. In Proceedings of the First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering (TASE’07), pages 229–240, 2007. 114. Cliff Jones. The Early Search for Tractable Ways of Reasoning About Programs. IEEE Annals of the History of Computing, 25(2):26–49, 2003. 115. Tsunehiko Kameda and P. Weiner. On the State Minimization of Nondeterministic Finite Automata. IEEE Transactions on Computers, C-19(7):617–627, 1970. 116. Christian Josef Kargl. A Sugar Translator. Master’s thesis, Institut f¨ur Softwaretechnologie, Technische Univesit¨at Graz, Graz, Austria, 2003. 117. Matt Kaufmann, Panagiotis Manolios, and J Strother Moore. Computer-Aided Reasoning: An Approach. Kluwer, Boston, MA, 2000. 118. Thomas Kropf. Introduction to Formal Hardware Verification. Springer, Berlin/Heidelberg, 1999. 119. Thomas Kuhn. The Structure of Scientific Revolutions. University of Chicago Press, Chicago, IL, third edition, 1996. 120. Orna Kupferman and Moshe Y. Vardi. Vacuity Detection in Temporal Model Checking. In Conference on Correct Hardware Design and Verification Methods, pages 82–96, 1999. 121. Orna Kupferman and Moshe Y. Vardi. Model Checking of Safety Properties. Formal Methods in System Design, 19(3):291–314, 2001. 122. Jiang Long and Andrew Seawright. Synthesizing SVA Local Variables for Formal Verification. In Proceedings of the 44th Design Automation Conference (44th DAC), pages 75–80, 2007. 123. Brian Malloy and Jeffrey Voas. Programming with Assertions: A Prospectus. IT Professional, 6(5):53–59, 2004. 124. Kenneth McMillan. Symbolic Model Checking. Springer, Norwell, Massachusetts, 1993.

References

271

125. Robert McNaughton and H. Yamada. Regular Expressions and State Graphs for Automata. IEEE Transactions on Electronic Computers, EC-9(1):39–47, 1960. 126. Mentor Graphics. ModelSim SE 6.1f. www.mentor.com/products/fv/digital verification/modelsim se/index.cfm, 2006. 127. Mentor Graphics. Veloce MHz-Class Accelerator/Emulator. http://www.mentor. com/products/fv/emulation/veloce, 2007. 128. Bertrand Meyer. Applying “Design by Contract”. IEEE Computer, 28(1):40–51, 1992. 129. Katell Morin-Allory. Personal communications. August–November, 2007. 130. Katell Morin-Allory and Dominique Borrione. A Proof of Correctness for the Construction of Property Monitors. In Proceedings of the 2005 IEEE International High Level Design Validation and Test Workshop (HLDVT’05), pages 237–244, 2005. 131. Katell Morin-Allory and Dominique Borrione. On-Line Monitoring of Properties Built on Regular Expression Sequences. Forum on Specification & Design Languages (FDL’06), 2006. 132. Katell Morin-Allory and Dominique Borrione. Proven Correct Monitors from PSL Specifications. In Proceedings of the 2006 Conference on Design Automation and Test in Europe (DATE’06), pages 1246–1251, 2006. 133. Katell Morin-Allory, Laurent Fesquet, and Dominique Borrione. Asynchronous Assertion Monitors for Multi-Clock Domain System Verification. In Proceedings of the Seventeenth IEEE International Workshop on Rapid System Prototyping (RSP’06), pages 98–102, 2006. 134. Anindyasundar Nandi, Bhaskar Pal, Nawang Chhetan, Pallab Dasgupta, and Partha P. Chakrabarti. H-DBUG: A High-level Debugging Framework for Protocol Verification using Assertions. In Proceedings of the 2005 Annual IEEE INDICON Conference, pages 115–118, 2005. 135. Gonzalo Navarro and Mathieu Raffinot. Fast and Simple Character Classes and Bounded Gaps Pattern Matching, With Application to Protein Searching. In Proceedings of the Fifth International Annual Conference on Computational Molecular Biology, pages 231–240, 2001. 136. Kelvin Ng, Alan Hu, and Jin Yang. Generating Monitor Circuits for Simulation-Friendly GSTE Assertion Graphs. In Proceedings of the 22nd IEEE International Conference on Computer Design (ICCD’04), pages 288–492, 2004. 137. Yann Oddos, Katell Morin-Allory, and Dominique Borrione. Prototyping Generators for On-Line Test Vector Generation Based on PSL Properties. In Proceedings of the 10th IEEE Workshop on Design and Diagnostics of Electronic Circuits and Systems (DDECS’07), pages 383–388, 2007. 138. Etienne Ogoubi and Eduard Cerny. Synthesis of Checker EFSMs from Timing Diagram Specifications. In Proceedings of the 1999 IEEE International Symposium on Circuits and Systems, (ISCAS’99), pages 13–18, 1999. 139. Marcio Oliveira. High-Level Specification and Automatic Generation of IP Interface Monitors. Master’s thesis, University of British Columbia, 2003. 140. Marcio Oliveira and Alan Hu. High-Level Specification and Automatic Generation of IP Interface Monitors. In Proceedings of the 39th Design Automation Conference (39th DAC), pages 129–134, 2002. 141. OpenCores Organization. Wishbone System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores. www.opencores.org, 2002. 142. S. Owre, N. Shankar, J. M. Rushby, and D. W. J. Stringer-Calvert. PVS System Guide, version 2.4. SRI International, Computer Science Laboratory, Menlo Park, CA, 2001. 143. Avi Parash. Formal Verification of an MPEG Decoder Chip. Integrated System Design, 12(134):44–55, 2000. 144. Priyadarsan Patra. On the Cusp of a Validation Wall. IEEE Design & Test, 24(2):193–196, 2007. 145. Michael Pellauer, Mieszko Lis, Don Baltus, and Rishiyur Nikhil. Synthesis of Synchronous Assertions with Guarded Atomic Actions. 3rd ACM & IEEE International Conference on Formal Methods and Models for Co-Design (MEMOCODE 2005), pages 15–24, 2005.

272

References

146. Douglas Perry and Harry Foster. Applied Formal Verification. McGraw-Hill, New York, 2005. 147. Kevin Peterson and Yvon Savaria. Assertion-Based On-Line Verification and Debug Environment for Complex Hardware Systems. In Proceedings of the 2004 International Symposium on Circuits and Systems (ISCAS’04), volume 2, pages 685–688, 2004. 148. Marco Platzner. Reconfigurable Computer Architectures - Rekonfigurierbare Rechnerarchitekturen. citeseer.ist.psu.edu/490784.html. 149. Amir Pnueli. The Temporal Logic of Programs. In Proceedings of the 18th Annual Symposium on Foundations of Computer Science (FOCS), pages 46–57, 1977. 150. Katarzyna Radecka. Identifying Redundant Gate Replacements in Verification by Error Modeling. In Proceedings of the International Test Conference (ITC’01), pages 803–912, 2001. 151. Katarzyna Radecka and Zeljko Zilic. Verification by Error Modeling: Using Testing Techniques in Hardware Verification. Kluwer, Boston, MA, 2003. 152. Pascal Raymond. Recognizing Regular Expressions by Means of Dataflow Networks. In Proceedings of the 23rd International Colloquium on Automata, Languages and Programming (ICALP’96), pages 336–347, 1996. 153. David S. Rosenblum. A Practical Approach of Programming with Assertions. IEEE Transactions on Software Engineering, 21(1):19–31, January 2005. 154. Sitvanit Ruah, Dana Fisman, and Shoham Ben-David. Automata Construction for On-TheFly Model Checking PSL Safety Simple Subset. Technical Report H-0234, IBM, 2005. 155. Jurgen Ruf, Dirk Hoffmann, Thomas Kropf, and Wolfgang Rosenstiel. Simulation Guided Property Checking Based on Multi-Valued AR-Automata. In Proceedings of the 2001 Conference on Design Automation and Test in Europe (DATE’01), pages 742–748, 2001. 156. David Russinoff. Formal Verification of Floating-Point RTL at AMD Using the ACL2 Theorem Prover. In IMACS World Congress Scientific Computation, Applied Mathematics and Simulation, Paris, France, July 2005. 157. Viktor Schuppan and Armin Biere. Liveness Checking as Safety Checking for Infinite State Spaces. In Proceedings of the 7th International Workshop on Verification of Infinite-State Systems (INFINITY 2005), pages 79–96, 2006. 158. Andrew Seawright and Forrest Brewer. Synthesis from Production-Based Specification. Proceedings of the 29th Design Automation Conference (29th DAC), pages 194–199, 1992. 159. Andrew Seawright and Forrest Brewer. High-Level Symbolic Construction Techniques for High Performance Sequential Synthesis. In Proceedings of the 30th Design Automation Conference (30th DAC), pages 424–428, 1993. 160. Andrew Seawright and Forrest Brewer. Clairvoyant: A Synthesis System for ProductionBased Specification. IEEE Transactions on VLSI Systems, 2(2):172–185, 1994. 161. Reetinder Sidhu and Viktor Prasanna. Fast Regular Expression Matching using FPGAs. In Proceedings of the 9th IEEE Symposium on Field Programmable Custom Computing Machines (FCCM’01), pages 227–238, 2001. 162. Geoff Sutcliffe and Christian Suttner. The TPTP Problem Library – CNF Release v1.2.1. Journal of Automated Reasoning, 21(2):177–203, 1998. 163. Peter Sutton. Partial Character Decoding for Improved Regular Expression Matching in FPGAs. In Proceedings of the IEEE International Conference on Field-Programmable Technology 2007 (ICFPT’07), pages 25–32, 2004. 164. Synopsys Inc. OpenVera Assertions. http://www.synopsys.com/products/ simulation/ova wp.pdf, 2003. 165. Bassam Tabbara, Yu-Chin Hsu, George Bakewell, and Scott Sandler. Assertion-Based Hardware Debugging. Proceedings of the 2003 Design and Verification Conference (DVCon 2003), Session 1, Paper 2, 2003. 166. Shoham Ben-David, Roderick Bloem, Dana Fisman, Andreas Griesmayer, Ingo Pill and Sitvanit Ruah. Automata Construction Algorithms Optimized for PSL. Property-Based System Design (PROSYD), Deliverable 3.2/4, www.prosyd.org/twiki/view/Public/ DeliverablePageWP3, 2005. 167. Ingo Pill, Andreas Griesmayer and Roderick Bloem. Manual for VIS Tool Port. PropertyBased System Design, Deliverable 3.3/1, www.prosyd.org/twiki/view/Public/ DeliverablePageWP3, 2005.

References

273

168. Thomas Tuerk, Klaus Schneider, and Mike Gordon. Model Checking PSL Using HOL and SMV. In Proceedings of the Second Annual Haifa Verification Conference (HVC’06), pages 1–15, 2006. 169. Gertjan Van Noord. Treatment of ε -Moves in Subset Construction. Computational Linguistics, 26(1):61–76, 2000. 170. Moshe Vardi. Alternating Automata: Unifying Truth and Validity Checking for Temporal Logics. In Proceedings of the 14th International Conference on Automated Deduction (CADE-14), volume 1249, pages 191–206, 1997. 171. Srikanth Vijayaraghavan and Meyyappan Ramanathan. A Practical Guide for SystemVerilog Assertions. Springer, New York, NY, 2005. 172. VIS (The VIS Group). Vis: A system for verification and synthesis. In Proceedings of the 8th International Conference on Computer Aided Verification (CAV’96), pages 428–432, 1996. 173. Bruce Watson. A Taxonomy of Finite Automata Minimization Algorithms. Technical Report – Computing Science Note 93/44, Eindhoven University of Technology, 1993. 174. Bruce Wile, John Goss, and Wolfgang Roesner. Comprehensive Functional Verification: The Complete Industry Cycle. Morgan Kaufmann, Boston, MA, 2005. 175. Aleksandr Zaks and Amir Pnueli. PSL Model Checking and Run-time Verification via Testers. In Proceedings of the 14th International Symposium on Formal Methods (FM’06), pages 573–586, 2006. 176. Zeljko Zilic, Katarzyna Radecka, and Ali Kazampur. Reversible Circuit Technology Mapping from Non-reversible Specifications. In Proceedings of the ACM/IEEE Design Automation and Test in Europe (DATE’07), 6 pages, 2007. 177. Avi Ziv. Cross-Product Functional Coverage Measurement with Temporal Properties-based Assertions. Proceedings of the 2003 Conference on Design Automation and Test in Europe (DATE’03), pages 834–839, 2003.

Index

A abort 65, 132 ABV methodology 17 Accepting state 39 Activations 29, 65, 156, 159, 169 Activity monitoring 163 AddLiteral algorithm 132 Alphabet 38, 46 power set 52, 84 semantic 46 symbolic 84, 86 syntactic 46 Alternating automaton 45 B¨uchi automaton 45 always 65, 81 rewrite rule 135 and see Conjunction of SVA properties, Intersection of SVA sequences assert 14, 68, 81, 152, 225 Assertion 4, 16 -based verification 4 adoption 16 as documentation 17 grouping 27, 176 partitioning algorithm 177 in software 13 signal 20, 101 Automata splitting 156, 218 Automated theorem proving 140 Automaton construction for PSL Booleans 110 for PSL properties 124 for PSL sequences 111 for PSL verification directives 152 for SVA Booleans 211

for SVA properties 219 for SVA sequences 212 for SVA verification statements Automaton flushing 161

225

B B¨uchi automaton 45 BaseCase automata algorithm 110 before family of operators 66 rewrite rules 136, 137 Binary decision diagram 90 Booleans in PSL 58, 106 in SVA 73, 209 Branching time logic 28 Built-in functions 58, 107 C Checker 20 creating from automata 100 generator 20 FoCs 51, 180 MBAC 6 in formal verification 240 output signal 88, 101, 180 Choice automata algorithm 113 of automata 39 of SEREs 60, 113 Clock declaration 255 in PSL 68, 106, 152 in SVA 81, 225 Collapsing final states 95 algorithm 96 Compilation strategies 157, 160

275

276 Complementation of automata 42, 98 algorithm 98 Complete DFA 40 transition relation 86 Completion of assertions 165, 227 Computation tree logic 30 Concatenation automata algorithm 113 of automata 39, 119 of SEREs 60, 112 Concurrent assertions 208 Conjunction of PSL properties 65, 133 of SVA properties 80, 221 Counters for assert 167 for cover 167 countones 59 cover 68, 81, 152, 160, 226 automaton algorithm in SVA 226 Coverage 19, 168 of PSL properties see Completion of assertions Cycle delay in SVA sequences 76, 213 automaton algorithm 214 rewrite rules 216

Index E

ε closure 41 removal 41 symbol 39 transition 39, 87 Edge 39, 86 Empty automaton 39, 115 language 38 sequence 62, 78, 115 SERE 61 Emulation 19, 26 End of execution 24, 33, 51, 66, 115, 131, 161, 227, 249 End of simulation 23, 51 ended 58, 74, 108, 211 Equivalence of Booleans 58, 107 of checkers 180 of PSL properties 65, 127 eventually! 66 more efficient implementation 160 rewrite rules 137, 138, 160 Executable specification 3 Existential automaton 45 Extended symbol 87

D F De Morgan’s law 133, 221 Degenerate sequences 62, 137 Dependencies, reporting signal 163 Deterministic finite automaton 40 Determinization of automata 41 strong 91, 95 algorithm 93 strong with completion 98 algorithm 99 weak 91, 93, 95 algorithm 92 Dff() 108, 210 disable iff 80, 211, 224 Disjunction of automata see Choice of automata of literals 87 of PSL properties 65 rewrite rule 134 of SEREs see Choice of SEREs of SVA properties 80, 221 of SVA sequences 78, 215 Dispatcher circuit 169 Dynamic verification 18

Failure matching 127, 220 algorithm 129 false 58, 74, 107, 209 Fault 3 $fell 75, 210 fell 58, 108 Final state 39 Finite automaton as used in MBAC 86 classical definition 38 first match 78, 216 automaton algorithm 166 forall 64 Fusion automata algorithm 116 of SEREs 60, 115 of SVA sequences 77 G Goto repetition of SEREs 60 rewrite rules 122

Index of SVA sequences 77 rewrite rules 217 H HDL construction for automata 101 for PSL Booleans 106 for SVA Booleans 209 I if / else 80, 224 Immediate assertions 208 Implication in Booleans 58, 107 in PSL properties 65 rewrite rule 135 initial 81, 228 Initial state(s) 39, 86, 88, 101 Inline assertions 259 intersect see Intersection of SVA sequences Intersection automata algorithm 117 of automata 43 of PSL properties see Conjunction of PSL properties of regular expressions 43 of SEREs 60, 116 rewrite rule 120 of SVA properties see Conjunction of SVA properties of SVA sequences 78, 215 automata algorithm 215 isunknown 59 K Kleene closure automaton algorithm 115 of a regular expression 38 of a SERE 60, 113 of an automaton 39

277 Liveness property 31 bounded liveness 32 Local variables 256 in PSL 256 in SVA 72, 256 M Minimization algorithm 95 of automata 94 Miter approach 181 Model checking 15, 44, 180, 240 Monitoring, with checkers 173, 175 N Negation algorithm 98 for failure matching 128 of a PSL property 65, 127 Network on Chip 185, 257 never 65 rewrite rule 135 next! 66 rewrite rule 139 next 59, 65 rewrite rule 139 next (extended forms) 66 rewrite rules 136, 137, 139, 140 Nonconsecutive repetition of SEREs 61 rewrite rules 123 of SVA sequences 77 rewrite rules 217 nondet 59 nondet vector 59 Nondeterminism 84, 95, 221 Nondeterministic finite automaton 40 not 79, 220 Null automaton 39, 115, 130 language 38 sequence 62, 79, 115 SERE 62

L O Label of a state 86, 92 Language 38 Letter 39 Linear temporal logic 28 in PSL 64 in SVA 256 Literal 87

$onehot 75, 210 onehot 58, 108 $onehot0 75, 210 onehot0 58, 108 Open Vera assertions 53 Open verification library 54, 184

278

Index

Order partial 92 total 87, 92 P $past 75, 210 Path 28 Pattern matching 39, 44 Polarity in automata for SVA properties 218, 223, 225 of a literal 87 of checker outputs 180 of signals 88 Post-fabrication debugging 16, 19, 27 with checkers 173 Precedence of PSL property operators 64 of PSL sequence operators 60 of SVA property operators 79 of SVA sequence operators 76 of Verilog operators 56 Precondition automaton 156, 169, 218 prev 58, 108 Primary symbol 86 Product automaton 43, 116 construction 43 Programmable logic 19, 27, 175 Property in PSL 62 in SVA 79 instantiation 63, 79 specification language 55 layers 57 Propositions atomic 29 Q Quality 2 Quality improvement

3

R Range Repetition automaton algorithm see Repetition automaton algorithm RDRD algorithm 94 Recursive compilation strategies see Compilation strategies Redundancy control using checkers 175 Regular expressions 38 derivatives 52

Repetition automaton algorithm 119 of SEREs 60, 118 rewrite rules 121 of SVA sequences 77, 215 Replication of a PSL property 64, 126 automata algorithm 127 Reversal algorithm 94 of an automaton 94 Reversible circuits 257 Rewrite rules 69, 134 $rose 75, 210 rose 58, 108 S Safety property 31 Satisfaction levels of properties 33 Satisfiability 257 Self-test, with checkers 174 Semantics of LTL 29 run time 23, 26, 35, 68, 202, 221 Sequence in PSL 59 in SVA 75 instantiation 63, 79 Sequent 143 SERE 59 Silicon debugging see Post-fabrication debugging Simple subset 56, 218, 255 Simulation 19 acceleration 26 of assertions 25 Skolem constants 143 Skolemizing 143, 145 Software testing 257 Specification 3 $stable 75, 210 stable 58, 108 Static verification 18 Status monitoring 19 Strength of an operator 33 of satisfaction 33 Strong failure matching 131 automata algorithm 131 properties 66 sequence 64, 220

Index Subset -sum 177 construction 41, 91, 93 Suffix implication in PSL 67, 133 rewrite rule 135 in SVA 80, 222, 223 Sugaring in LTL 30 in SEREs 61, 111, 120 in SVA sequences 78, 212 System functions 75, 209 on Chip 16 SystemVerilog 71 SystemVerilog assertions 70 T Temporal logic 28 Terminating (rewrite rule) 69 Test pattern generation 174 sequence generation 174 Testing 2 Threading, of assertions 168 throughout 78 rewrite rule 217 Trace 28, 86, 141 distance 201 Transaction level modeling 257 Transition see Edge relation 39, 86 Trivial validity 46, 165 true 58, 74, 87, 107, 209 automaton 130 Truth assignment ω 87

279 U Unconnected states 94 Universal automaton 45 until family of operators rewrite rules 136, 138 V Vacuity 46, 165 Vacuous success 46 Validation 2 Verification 3 directives (PSL) 68 gap 2 statements (SVA) 81 Verilog arithmetic operators 56 bitwise operators 57 constants 56 language 56 logical operators 57 Void precondition 157 vunit 68, 152, 180 W within 60, 78 PSL rewrite rule 121 rewrite rule 217 Word 39 Z Zero Defects

3

66