SystemVerilog assertions are inherently synchronous due to the language definition. This makes them difficult to use for checking asynchronous behaviors like resets or communication across clock domains. However, with the proper techniques, SVA can effectively check both synchronous and asynchronous properties. Key techniques include using "disable iff" to terminate assertions when asynchronous signals occur, and delaying input sampling through constructs like program blocks, sequence events, or #0 delays to sample inputs after asynchronous signals have taken effect.
The document discusses asynchronous programming in JavaScript using promises. It begins by explaining how JavaScript executes code synchronously before introducing callbacks and asynchronous code. It then covers promises as a cleaner way to write asynchronous code. Key points include: promises allow asynchronous code to be written similarly to synchronous code; promises can be chained to handle multiple asynchronous operations in sequence; and the async/await keywords allow promises to be written even more cleanly like synchronous code.
This document discusses reusing C tests and UVM sequences when integrating IP blocks into an SoC verification environment. It proposes a three-layer structure with an application layer, transaction layer, and physical layer. The transaction layer uses TLM2 to isolate C tests from changes to the bus protocol, allowing full reuse. It also discusses reusing register sequences by accessing registers through a common name, and reusing interrupt sequences by replacing the interrupt monitor and reusing service sequences. This approach makes the IP UVM environment active in the SoC and allows reuse of IP verification assets.
The document describes a system with 4 IP models connected through an interface bus. It contains blocks for the system address map, an environment adaptor, and interfaces for the bus, sequencer and driver. The document also mentions using sequences for register writes, reads, resets and generating transactions from the IP models or from a RALF file.
The document discusses the UVM register model, which provides an object-oriented shadow model for registers and memories in a DUT. It includes components like fields, registers, register files, memory, and blocks. The register model allows verification of register access and provides a standardized way to build reusable verification components.
The document provides an overview of the UVM configuration database and how it is used to store and access configuration data throughout the verification environment hierarchy. Key points include: the configuration database mirrors the testbench topology; it uses a string-based key system to store and retrieve entries in a hierarchical and scope-controlled manner; and the automatic configuration process retrieves entries during the build phase and configures component fields.
Notes: Verilog Part 4- Behavioural ModellingJay Baxi
This is the 4th part of the Verilog HDL notes prepared from Verilog HDL by Samir Palnitkar .
It contains a broad view on behavioural modelling the second most frequently used level of abstraction needed for designing of sequential circuits.
The document discusses asynchronous programming in C# and Visual Basic. It describes the limitations of callback-based asynchronous programming models and how they disrupt control flow and program structure. The document then introduces a new approach using tasks and async/await that aims to make asynchronous code look similar to synchronous code while still handling asynchronous situations appropriately. This new approach proposed in the Async CTP aims to improve the asynchronous programming experience.
This document provides an overview of iterative and recursive algorithms. It begins with defining iterative algorithms as executing steps in iterations to find successive approximations of a solution. Key aspects of iterative algorithms discussed include loop invariants, typical errors, and different types of iterative methods. Recursion is then introduced as algorithms that call themselves with smaller inputs and solve larger cases based on smaller cases. Examples of recursive algorithms are provided for computing even numbers, powers of 2, sequential search, and testing natural numbers. In summary, the document covers the basic concepts and structures of iterative and recursive algorithms through definitions, examples, and comparisons between the two approaches.
The document discusses asynchronous programming in JavaScript using promises. It begins by explaining how JavaScript executes code synchronously before introducing callbacks and asynchronous code. It then covers promises as a cleaner way to write asynchronous code. Key points include: promises allow asynchronous code to be written similarly to synchronous code; promises can be chained to handle multiple asynchronous operations in sequence; and the async/await keywords allow promises to be written even more cleanly like synchronous code.
This document discusses reusing C tests and UVM sequences when integrating IP blocks into an SoC verification environment. It proposes a three-layer structure with an application layer, transaction layer, and physical layer. The transaction layer uses TLM2 to isolate C tests from changes to the bus protocol, allowing full reuse. It also discusses reusing register sequences by accessing registers through a common name, and reusing interrupt sequences by replacing the interrupt monitor and reusing service sequences. This approach makes the IP UVM environment active in the SoC and allows reuse of IP verification assets.
The document describes a system with 4 IP models connected through an interface bus. It contains blocks for the system address map, an environment adaptor, and interfaces for the bus, sequencer and driver. The document also mentions using sequences for register writes, reads, resets and generating transactions from the IP models or from a RALF file.
The document discusses the UVM register model, which provides an object-oriented shadow model for registers and memories in a DUT. It includes components like fields, registers, register files, memory, and blocks. The register model allows verification of register access and provides a standardized way to build reusable verification components.
The document provides an overview of the UVM configuration database and how it is used to store and access configuration data throughout the verification environment hierarchy. Key points include: the configuration database mirrors the testbench topology; it uses a string-based key system to store and retrieve entries in a hierarchical and scope-controlled manner; and the automatic configuration process retrieves entries during the build phase and configures component fields.
Notes: Verilog Part 4- Behavioural ModellingJay Baxi
This is the 4th part of the Verilog HDL notes prepared from Verilog HDL by Samir Palnitkar .
It contains a broad view on behavioural modelling the second most frequently used level of abstraction needed for designing of sequential circuits.
The document discusses asynchronous programming in C# and Visual Basic. It describes the limitations of callback-based asynchronous programming models and how they disrupt control flow and program structure. The document then introduces a new approach using tasks and async/await that aims to make asynchronous code look similar to synchronous code while still handling asynchronous situations appropriately. This new approach proposed in the Async CTP aims to improve the asynchronous programming experience.
This document provides an overview of iterative and recursive algorithms. It begins with defining iterative algorithms as executing steps in iterations to find successive approximations of a solution. Key aspects of iterative algorithms discussed include loop invariants, typical errors, and different types of iterative methods. Recursion is then introduced as algorithms that call themselves with smaller inputs and solve larger cases based on smaller cases. Examples of recursive algorithms are provided for computing even numbers, powers of 2, sequential search, and testing natural numbers. In summary, the document covers the basic concepts and structures of iterative and recursive algorithms through definitions, examples, and comparisons between the two approaches.
One of JavaScript’s strengths is how it handles asynchronous code. Async is one of the most important and often misunderstood part of Javascript or any other language. Async is hard because we, as human beings, can’t do two conscious actions at once and think about both of them at the same moment. In this talk we will see how asynchronous JavaScript evolved over the years. It all started with callbacks… and it landed on generators!
System Verilog is a hardware description and verification language that combines features of HDLs like Verilog and VHDL with features from specialized hardware verification languages and object-oriented languages like C++. It became an official IEEE standard in 2005. Verification is the process of ensuring a hardware design works as expected by catching defects early in the design process to save costs. System Verilog is well-suited for verification through features like assertion-based verification, functional coverage, object-oriented programming, and constrained randomization. Assertions allow verifying that expressions or properties hold true during simulation through immediate and concurrent assertions.
Android Application Development - Level 3Isham Rashik
Final level of the Android Application Development series. With this tutorial documentation, this will enable mobile developers to gain complete basic knowledge of Android Development. After completing all 3 of the levels, the developers can proceed with intermediary and advanced concepts.
Re usable continuous-time analog sva assertionsRégis SANTONJA
This paper shows how SystemVerilog Assertions (SVA) modules can be bound to analog IP blocks, shall they be at behavioral or transistor-level, enabling the assertions to become a true IP deliverable that can be reused at SoC level. It also highlights how DPIs can fix analog assertions specificities, such as getting rid of hierarchical paths, especially when probing currents. This paper also demonstrates how to flawlessly switch models between digital (wreal) and analog models without breaking the assertions. Finally, it demonstrates how one can generate an adaptive clock to continuously assert analog properties whose stability over time is critical, such as current or voltage references or supplies.
This document provides an introduction to verification and the Universal Verification Methodology (UVM). It discusses different types of verification including simulation, functional coverage, and code coverage. It describes how simulators work and their limitations in approximating physical hardware. It also covers topics like event-driven simulation, cycle-based simulation, co-simulation, and different types of coverage metrics used to ensure a design is fully tested.
The document explains three Verilog system tasks: $display, $monitor, and $strobe.
$display prints information to the console immediately when executed. $monitor continuously prints variable changes throughout simulation until turned off with $monitoroff. $strobe displays information like $display but postpones printing until the end of the current simulation time unit.
An example monitors a counter value with $monitor and displays start/end messages with $display and final value each time step with $strobe.
Task Scheduler is a Windows component that allows scheduling programs and scripts to launch at predefined times or intervals. It was introduced in Windows 95 and renamed to Task Scheduler in Windows 98. There are different types of task schedulers that vary in how tasks are executed and how devices are handled, from simple endless loops to more complex priority-based preemptive schedulers that can handle interrupts. Precise timing of task execution is a limitation of cyclic executives where tasks must complete before the next starts.
The document discusses process synchronization and solutions to the critical section problem. It introduces the producer-consumer problem as an example that requires synchronization. The critical section problem aims to ensure that only one process at a time can be executing shared code or accessing shared data. Peterson's algorithm provides a solution for two processes using shared variables. Hardware synchronization methods like mutex locks and semaphores provide atomic primitives to synchronize processes. Semaphores use wait() and signal() operations to control access to shared resources without busy waiting.
The document discusses metric driven formal verification and observation coverage analysis. It describes OneSpin Solutions, a company that provides formal verification tools, and their tool OneSpin 360. The tool allows for observation coverage analysis to measure verification progress. It provides unique features like assertion debugging and formal scoreboarding. The document outlines that a progress metric is needed for formal verification to measure coverage and determine when verification is complete. It proposes combining control coverage, which measures stimulus quality, and observation coverage, which measures checker quality. Observation coverage is demonstrated on an example using the Quantify MDV metric to check how design modifications impact property proofs. Merging observation coverage with control coverage provides a fuller picture of verification progress.
A promise represents the result of an asynchronous operation. It provides methods to handle callbacks from async operations. Using promises allows returning results from functions instead of injecting callbacks into low-level code, which provides more control, flexibility, and readable code. Promises get resolved once the async operation occurs and can be fulfilled successfully or rejected. Common promise methods include then(), catch(), and done().
Senthilkanth,MCA..
The following ppt's full topic covers Operating System for BSc CS, BCA, MSc CS, MCA students..
1.Introduction
2.OS Structures
3.Process
4.Threads
5.CPU Scheduling
6.Process Synchronization
7.Dead Locks
8.Memory Management
9.Virtual Memory
10.File system Interface
11.File system implementation
12.Mass Storage System
13.IO Systems
14.Protection
15.Security
16.Distributed System Structure
17.Distributed File System
18.Distributed Co Ordination
19.Real Time System
20.Multimedia Systems
21.Linux
22.Windows
This document summarizes a presentation on verification challenges and technologies. It discusses the basics of verification, verification methodologies, and skills needed for verification jobs. It covers simulation-based verification techniques like testbenches, and limitations of simulation like lack of timing information. It also discusses functional coverage to track whether test plans have been fully executed.
What is test-driven Infrastructure ? How you can test your ops side ? What is chaos monkey and how Sony is using it ? What is testinfra ? How to write acceptance tests in Infrastructure ?
The document discusses transaction processing and workflow management. It defines workflow as long-lived executions involving programs, databases, sensors and humans. It examines how transactional concepts like atomicity, consistency, isolation and durability apply at different levels in a workflow system. Transaction processing can be used at the workflow engine level and step level, but compensation and invariants are needed to define correctness at the long-lived script level. Resource managers and persistent storage need extensions to support the transactional needs of workflow systems.
This document summarizes key topics from Chapter 5 of a book on designing embedded systems with PIC microcontrollers, including:
- Visualizing programs with flow diagrams and state diagrams
- Using program branching, subroutines, and delays
- Implementing logical instructions and look-up tables
- Optimizing assembler code and using advanced simulator features like breakpoints and timing measurements
The document describes a SystemVerilog verification methodology that includes assertion-based verification, coverage-driven verification, constrained random verification, and use of scoreboards and checkers. It outlines the verification flow from design specifications through testbench development, integration and simulation, and discusses techniques like self-checking test cases, top-level and block-level environments, and maintaining bug reports.
This document provides an overview of reactive programming with RxJava. It begins with introductions to reactive programming and RxJava. It then discusses operators like map, filter, and flatMap that allow transforming and combining observable streams. It covers topics like error handling, threading with schedulers, subscriptions, and backpressure. The document includes examples of how to use various RxJava operators and concepts like transforming streams, handling errors, and improving performance with techniques like throttling.
The document contains interview questions and answers related to sections, control identification, modules, actions, parameters, and other concepts in Tosca automation testing. Key points include the different section types in Tosca, methods for identifying controls, types of modules, actions like verify and buffer, parameters like TCP and business parameters, and concepts like synchronization, libraries, and recovery scenarios.
UNIT 2-UNDERSTANDING THE SYNCHRONIZATION PROCESS.pptxLeahRachael
The document discusses process synchronization and solutions to critical section problems in operating systems. It covers topics like race conditions, critical sections, mutual exclusion, solutions using semaphores and monitors. It also discusses classic synchronization problems like the dining philosophers problem and readers-writers problem. Solutions presented ensure only one process can access shared resources at a time through techniques like disabling interrupts, atomic instructions, and turning variables.
Programming in Java: Control Flow. Last delivered in 2016. All educational material listed or linked to on these pages in relation to King's College London may be provided for reference only, and therefore does not necessarily reflect the current course content.
The document describes Cisco's Base Environment methodology for digital verification. It aims to standardize the verification process, promote reuse, and improve predictability. The methodology defines a common testbench topology and infrastructure that is vertically scalable from unit to system level and horizontally scalable across projects. It provides templates, scripts, verification IP and documentation to help teams set up verification environments quickly and leverage existing best practices. The standardized approach facilitates extensive code and test reuse and delivers benefits such as faster ramp-up times, improved planning, and higher return on verification IP development.
This document discusses the challenges of pre-silicon validation for Intel Xeon processors. It notes that Xeon validation teams have relatively small sizes compared to the scope of validation required. Key challenges include reusing design components from previous projects, managing cross-site teams, and dealing with ever-growing design complexity that strains simulation and formal verification methods. Specific issues involve integrating disparate design tools and environments, understanding the original intent when reusing unfinished code, minimizing duplicated stimulus code, managing the overhead of coverage instrumentation, and ensuring tests are portable between pre-silicon and post-silicon validation.
One of JavaScript’s strengths is how it handles asynchronous code. Async is one of the most important and often misunderstood part of Javascript or any other language. Async is hard because we, as human beings, can’t do two conscious actions at once and think about both of them at the same moment. In this talk we will see how asynchronous JavaScript evolved over the years. It all started with callbacks… and it landed on generators!
System Verilog is a hardware description and verification language that combines features of HDLs like Verilog and VHDL with features from specialized hardware verification languages and object-oriented languages like C++. It became an official IEEE standard in 2005. Verification is the process of ensuring a hardware design works as expected by catching defects early in the design process to save costs. System Verilog is well-suited for verification through features like assertion-based verification, functional coverage, object-oriented programming, and constrained randomization. Assertions allow verifying that expressions or properties hold true during simulation through immediate and concurrent assertions.
Android Application Development - Level 3Isham Rashik
Final level of the Android Application Development series. With this tutorial documentation, this will enable mobile developers to gain complete basic knowledge of Android Development. After completing all 3 of the levels, the developers can proceed with intermediary and advanced concepts.
Re usable continuous-time analog sva assertionsRégis SANTONJA
This paper shows how SystemVerilog Assertions (SVA) modules can be bound to analog IP blocks, shall they be at behavioral or transistor-level, enabling the assertions to become a true IP deliverable that can be reused at SoC level. It also highlights how DPIs can fix analog assertions specificities, such as getting rid of hierarchical paths, especially when probing currents. This paper also demonstrates how to flawlessly switch models between digital (wreal) and analog models without breaking the assertions. Finally, it demonstrates how one can generate an adaptive clock to continuously assert analog properties whose stability over time is critical, such as current or voltage references or supplies.
This document provides an introduction to verification and the Universal Verification Methodology (UVM). It discusses different types of verification including simulation, functional coverage, and code coverage. It describes how simulators work and their limitations in approximating physical hardware. It also covers topics like event-driven simulation, cycle-based simulation, co-simulation, and different types of coverage metrics used to ensure a design is fully tested.
The document explains three Verilog system tasks: $display, $monitor, and $strobe.
$display prints information to the console immediately when executed. $monitor continuously prints variable changes throughout simulation until turned off with $monitoroff. $strobe displays information like $display but postpones printing until the end of the current simulation time unit.
An example monitors a counter value with $monitor and displays start/end messages with $display and final value each time step with $strobe.
Task Scheduler is a Windows component that allows scheduling programs and scripts to launch at predefined times or intervals. It was introduced in Windows 95 and renamed to Task Scheduler in Windows 98. There are different types of task schedulers that vary in how tasks are executed and how devices are handled, from simple endless loops to more complex priority-based preemptive schedulers that can handle interrupts. Precise timing of task execution is a limitation of cyclic executives where tasks must complete before the next starts.
The document discusses process synchronization and solutions to the critical section problem. It introduces the producer-consumer problem as an example that requires synchronization. The critical section problem aims to ensure that only one process at a time can be executing shared code or accessing shared data. Peterson's algorithm provides a solution for two processes using shared variables. Hardware synchronization methods like mutex locks and semaphores provide atomic primitives to synchronize processes. Semaphores use wait() and signal() operations to control access to shared resources without busy waiting.
The document discusses metric driven formal verification and observation coverage analysis. It describes OneSpin Solutions, a company that provides formal verification tools, and their tool OneSpin 360. The tool allows for observation coverage analysis to measure verification progress. It provides unique features like assertion debugging and formal scoreboarding. The document outlines that a progress metric is needed for formal verification to measure coverage and determine when verification is complete. It proposes combining control coverage, which measures stimulus quality, and observation coverage, which measures checker quality. Observation coverage is demonstrated on an example using the Quantify MDV metric to check how design modifications impact property proofs. Merging observation coverage with control coverage provides a fuller picture of verification progress.
A promise represents the result of an asynchronous operation. It provides methods to handle callbacks from async operations. Using promises allows returning results from functions instead of injecting callbacks into low-level code, which provides more control, flexibility, and readable code. Promises get resolved once the async operation occurs and can be fulfilled successfully or rejected. Common promise methods include then(), catch(), and done().
Senthilkanth,MCA..
The following ppt's full topic covers Operating System for BSc CS, BCA, MSc CS, MCA students..
1.Introduction
2.OS Structures
3.Process
4.Threads
5.CPU Scheduling
6.Process Synchronization
7.Dead Locks
8.Memory Management
9.Virtual Memory
10.File system Interface
11.File system implementation
12.Mass Storage System
13.IO Systems
14.Protection
15.Security
16.Distributed System Structure
17.Distributed File System
18.Distributed Co Ordination
19.Real Time System
20.Multimedia Systems
21.Linux
22.Windows
This document summarizes a presentation on verification challenges and technologies. It discusses the basics of verification, verification methodologies, and skills needed for verification jobs. It covers simulation-based verification techniques like testbenches, and limitations of simulation like lack of timing information. It also discusses functional coverage to track whether test plans have been fully executed.
What is test-driven Infrastructure ? How you can test your ops side ? What is chaos monkey and how Sony is using it ? What is testinfra ? How to write acceptance tests in Infrastructure ?
The document discusses transaction processing and workflow management. It defines workflow as long-lived executions involving programs, databases, sensors and humans. It examines how transactional concepts like atomicity, consistency, isolation and durability apply at different levels in a workflow system. Transaction processing can be used at the workflow engine level and step level, but compensation and invariants are needed to define correctness at the long-lived script level. Resource managers and persistent storage need extensions to support the transactional needs of workflow systems.
This document summarizes key topics from Chapter 5 of a book on designing embedded systems with PIC microcontrollers, including:
- Visualizing programs with flow diagrams and state diagrams
- Using program branching, subroutines, and delays
- Implementing logical instructions and look-up tables
- Optimizing assembler code and using advanced simulator features like breakpoints and timing measurements
The document describes a SystemVerilog verification methodology that includes assertion-based verification, coverage-driven verification, constrained random verification, and use of scoreboards and checkers. It outlines the verification flow from design specifications through testbench development, integration and simulation, and discusses techniques like self-checking test cases, top-level and block-level environments, and maintaining bug reports.
This document provides an overview of reactive programming with RxJava. It begins with introductions to reactive programming and RxJava. It then discusses operators like map, filter, and flatMap that allow transforming and combining observable streams. It covers topics like error handling, threading with schedulers, subscriptions, and backpressure. The document includes examples of how to use various RxJava operators and concepts like transforming streams, handling errors, and improving performance with techniques like throttling.
The document contains interview questions and answers related to sections, control identification, modules, actions, parameters, and other concepts in Tosca automation testing. Key points include the different section types in Tosca, methods for identifying controls, types of modules, actions like verify and buffer, parameters like TCP and business parameters, and concepts like synchronization, libraries, and recovery scenarios.
UNIT 2-UNDERSTANDING THE SYNCHRONIZATION PROCESS.pptxLeahRachael
The document discusses process synchronization and solutions to critical section problems in operating systems. It covers topics like race conditions, critical sections, mutual exclusion, solutions using semaphores and monitors. It also discusses classic synchronization problems like the dining philosophers problem and readers-writers problem. Solutions presented ensure only one process can access shared resources at a time through techniques like disabling interrupts, atomic instructions, and turning variables.
Programming in Java: Control Flow. Last delivered in 2016. All educational material listed or linked to on these pages in relation to King's College London may be provided for reference only, and therefore does not necessarily reflect the current course content.
The document describes Cisco's Base Environment methodology for digital verification. It aims to standardize the verification process, promote reuse, and improve predictability. The methodology defines a common testbench topology and infrastructure that is vertically scalable from unit to system level and horizontally scalable across projects. It provides templates, scripts, verification IP and documentation to help teams set up verification environments quickly and leverage existing best practices. The standardized approach facilitates extensive code and test reuse and delivers benefits such as faster ramp-up times, improved planning, and higher return on verification IP development.
This document discusses the challenges of pre-silicon validation for Intel Xeon processors. It notes that Xeon validation teams have relatively small sizes compared to the scope of validation required. Key challenges include reusing design components from previous projects, managing cross-site teams, and dealing with ever-growing design complexity that strains simulation and formal verification methods. Specific issues involve integrating disparate design tools and environments, understanding the original intent when reusing unfinished code, minimizing duplicated stimulus code, managing the overhead of coverage instrumentation, and ensuring tests are portable between pre-silicon and post-silicon validation.
The document discusses how shaders are created and validated for graphics processing units (GPUs). Shaders are created by applications and sent to the GPU through graphics APIs and drivers. They are then executed by the GPU's shader processors. The validation process uses layered testbenches at the sub-block, block, and system levels for maximum controllability and observability. It also employs a reference model methodology using C++ models and hardware emulation to debug designs faster than simulation alone. This methodology helps improve the schedule and find bugs earlier in the development cycle.
The document is a presentation on verification of graphics ASICs given by Shaw Yang and Gary Greenstein of AMD. The presentation covers an overview of AMD, GPU systems, 3D graphics basics including vertices, polygons, pixels and textures, verification challenges related to size and complexity, and approaches used including layered code and testbenches, hardware emulation, and functional coverage.
The document discusses the importance of using verification metrics to predict the functional closure of a CPU design project and discusses challenges in relying solely on metrics. It outlines two key types of metrics - verification test plan based metrics that track testing progress and health of the design metrics that assess bug rates and stability. Examples are provided on using bug rate data and breaking bugs down by design unit to help evaluate the progress and health of a verification effort.
The document discusses efficient verification methodology. It recommends defining a conceptual framework or methodology to standardize some aspects while allowing diversity. The methodology should define interfaces and transactions upfront using an interface definition language to generate verification components and reusable assertions. It also recommends modeling systems at the transaction level using executable specifications to frontload the verification schedule.
The document discusses the challenges of validating next generation CPUs. It notes that validation is increasingly critical for product success but requires constant innovation. Design complexity is growing exponentially, requiring up to 70% of resources for functional validation. The number of pre-silicon logic bugs found per generation has also increased significantly. Shorter timelines and cross-site development further complicate the validation process.
The document discusses validation and design in small teams with limited resources. It proposes constraining designs to a single clock rate, using FIFO interfaces between blocks, and separating algorithm from IO verification to simplify validation. This approach allows designs to be completed more quickly with fewer verification engineers through standardized, repeatable validation methods at the cost of optimal performance.
Verification challenges have increased with the globalization of chip design. Time zone differences and documentation issues can reduce efficiency, but greater collaboration across sites can also lead to new ideas. AMD addresses these challenges through a Verification Center of Expertise (COE) that coordinates methodologies across multiple sites. The COE develops tools and techniques while partnering with project teams to jointly improve processes over time through continuous review and rotation of engineers between the COE and projects.
Greg Tierney of Avid presented on their experiences using SystemC for design verification. SystemC provides hardware constructs and simulation capabilities in C++. Avid chose SystemC to enhance their existing C++ verification code and take advantage of its industry acceptance and built-in verification features. SystemC helped Avid solve issues like crossing language boundaries between HDL modules and testbenches, connecting ports and channels, implementing randomization, using multi-threaded processes, and defining module hierarchies. However, Avid also encountered issues with SystemC like slow compile/link times and limitations in its foreign language interface.
Bob Colwell documented notes from a meeting discussing the need for better software visualization tools to help localize bugs, diagnose problems, and monitor software behavior. The notes also reflect on important words in science according to Isaac Newton and reference a book about creative analogies. Finally, they caution against agreeing to sign a document just because a product is shipping.
The document outlines the verification strategy for a PCI-Express presenter device. It discusses the PCI-Express protocol overview including terminology, hierarchy and functions at various layers. It emphasizes the importance of design-for-verification using techniques like modular architectures, standardized interfaces and reference models to aid in functional verification closure and compliance testing. Performance verification is also highlighted as critical given the real-time requirements of the standard.
The document discusses verification strategies for PCI-Express. It outlines the PCI-Express protocol and highlights challenges in verifying chips that implement open standards. The verification paradigm focuses on functionality, performance, interoperability, reusability, scalability, and comprehensiveness using techniques like constrained-random testing, assertions, reference models, emulation, and compliance checkers. The goal is to deliver compliant and high-performing chips with zero bugs through an effective verification methodology.
The document discusses methodologies for improving verification efficiency at Cisco. It advocates separating testbench creation into three stages: component design, testbench integration, and testcase creation. It also recommends using standardized methodologies like testflow to synchronize component behavior, reusing unit-level component models and checkers, linking transactions between checkers, and generating common testbench infrastructure from templates to reduce duplication of effort. The key is pushing reusable behavior into components and standardizing common elements to maximize efficiency.
This document discusses the importance of pre-silicon verification for post-silicon validation. It notes that post-silicon validation schedules are growing due to increasing design complexity, while pre-silicon verification investment and methodologies have not kept pace. The document highlights mixed-signal verification, power-on/reset verification, and design-for-testability verification as key focus areas needed to improve pre-silicon verification and enable faster post-silicon validation. It provides examples of mixed-signal and power-on bugs that were found post-silicon due to insufficient pre-silicon verification of these areas. The document argues that pre-silicon verification must move beyond just functional verification and own mixed-signal effects
This document discusses challenges in low-power design and verification. It addresses why low-power is now a priority given trends in mobile applications. Key challenges include increased leakage due to process scaling, accounting for active leakage, and handling process variations. The document also discusses low-power design methodologies, including multiple power domains, voltage scaling, and clock gating. Verification challenges are presented, such as needing good test patterns and coordination across design domains. Overall power analysis is more complex than timing analysis due to its pattern dependence and need to optimize for performance per watt.
Verilog-AMS allows for mixed-signal modeling and simulation in a single language. It provides benefits like simplified mixed-signal modeling, decreased simulation time, and improved mixed-signal verification. Previous solutions involved using two simulators or approximating analog circuits, which caused issues like slow simulation and lack of analog results. Verilog-AMS uses constructs from Verilog and Verilog-A to model both analog and digital content together. This avoids issues with interface elements between domains.
This document discusses the verification of Intel's Atom processor. It describes the key verification challenges, methodology used, and results. The main challenges were verifying a new microarchitecture with aggressive schedules and limited resources. The methodology involved cluster-level validation, functional coverage, architectural validation, and formal verification. Metrics like coverage, bug rates, and a "health of model" indicator were used. The results showed a successful pre-silicon verification with few escapes and debug/survivability features working as intended. Key learnings included the importance of keeping the full-chip design healthy early and putting equal focus on testability features.
The document discusses verification strategies based on Sun Tzu's classic book "The Art of War". Some key points:
1. Sun Tzu emphasized understanding the objective conditions and subjective opinions of competitors to determine strategic positioning. This relates to verification where it is important to understand the design and "Murphy the Designer".
2. Sun Tzu's 13 chapters provide guidance on tactics like laying plans, attacking weaknesses, maneuvering, and using intelligence sources. These lessons can help verification engineers successfully navigate different stages of a competitive campaign against bugs and errors.
3. Effective verification requires knowing the design, understanding one's own verification process, preparing appropriate tools, and using feedback to improve. Coverage metrics alone do
Here are the key challenges faced in low power design without a common power format:
1. Domain definitions, level shifters, isolation cells, and other low power techniques are specified differently in each tool using tool-specific commands files and languages. This makes cross-tool consistency and validation difficult.
2. Power functionality cannot be easily verified at the RTL level without changing the RTL code, since power domains and low power techniques are not represented. This limits verification coverage.
3. Iteration between design creation and verification is difficult, since changes to the low power implementation require updates to multiple tool-specific specification files rather than a single cross-tool definition. This impacts design schedule and risks inconsistencies.
4.
1. The SystemVerilog Assertion (SVA) language offers a very powerful way to
describe design properties and temporal behaviors; however, they are innately
synchronous due to how they are defined by the SystemVerilog standard.
Unfortunately, this makes them especially hard to use for checking asynchronous
events and behaviors. Notwithstanding, armed with the proper techniques, SVA can
be used to effectively describe and check both synchronous and asynchronous
assertions.
1
2. First, let’s start our discussion by having a look at asynchronous behaviors and the
challenges that they present.
2
3. Asynchronous behaviors typically come in two forms: (1) asynchronous control
signals, and (2) asynchronous communication. Most designs have some kind of
asynchronous event like an asynchronous reset, enable, non-maskable interrupt, etc.
Even if these events are synchronized within to a clock, they may occur at any time,
preempting the current operation of the design, and should immediately trigger an
assertion to check that the design properly responds to the event.
The second form of asynchronous behavior is asynchronous communication. This is
seen with communication across clock domains or on interfaces that use some kind
of asynchronous handshaking. See the following paper for details on handling these
behaviors:
Doug Smith. “Asynchronous Behaviors Meet Their Match with SVA,”
DVCon Proceedings, San Jose, February 2010.
This paper is also available from www.doulos.com.
3
4. Let’s have a look at the first type of behavior—asynchronous control signals. To
understand the difficulties, we’ll start by having a look at a simple up-down counter.
The table here shows the proper behavior of this counter. The asynchronous control
is the reset that causes the design to immediately change to 0.
4
5. If we were to write assertions for this counter, they might look something like this.
These assertions are rather straightforward since checking always happens on the
rising edge of the clock. But what about the asynchronous reset? How do we
incorporate that into our assertions?
5
6. A common mistake would be to add Reset into our assertion precondition as shown
here. While this looks like it would work, we might actually encounter false failures
from this. As you can see, when reset occurs, the value of Q immediate resets to 0.
On the next clock cycle when the precondition is evaluated, the asserted Reset will
stop the precondition from spawning a thread and the check from occurring just as
we intended.
The problem lies with the cycle before Reset occurs. The cycle before, the
precondition is met, an assertion thread is spawned, and the checker waits to check
the condition on the next clock edge. Before the check is evaluated, the Reset signal
asserts, changing the actual value of Q from the expected and the assertion throws a
false failure.
6
7. What we really need is some way to not only stop the evaluation of an assertion
when Reset occurs, but also kill any threads waiting to check when the reset asserts.
The “disable iff” abort terminator allows us to do just that. As soon as the Reset
signal occurs, the level-sensitive abort terminator stops both the evaluation of the
assertion and kills any processing threads. As a general rule of thumb, all assertion
sensitive to an asynchronous signal should use a “disable iff” qualifying expression.
7
8. Disable iff handles terminating our assertions, but what about checking that the
RTL does the correct thing when the asynchronous reset occurs? To write such an
assertion, we might write something as shown here---when the Reset goes high, then
check that Q goes to 0.
At first glance, this looks like it would do what we expect, but unfortunately it does
not. In fact, the assertion never even evaluates!!
8
9. To understand why, we need to understand how the SystemVerilog simulation
scheduler evaluates assertions, which we will look at in the next section.
9
10. A Verilog or SystemVerilog simulator has different scheduling regions where events
are scheduled and subsequently evaluated. All event evaluations occur in the
scheduler’s Active region. Events are scheduled in the Inactive region by using a #0
delay, and the Non-Blocking Assignment (NBA) region by using a non-blocking
assign. Once all the events in the Active region are exhausted, the Inactive region
events are promoted to the Active region and evaluated. Likewise, once those events
are evaluated, the non-blocking events are promoted to the Active region and
evaluated. As simulation progresses, events are scheduled and evaluated until all
events for a particular time step are evaluated and simulation can move forward.
The traditional Verilog scheduling semantics have been extended from including an
Active, Inactive, and NBA regions to also include some special regions just for
assertions. The Preponed region has been added in SystemVerilog in order to
sample all of a concurrent assertion’s inputs, and the Observed region is used for
their evaluation. Events such as clock or asynchronous signals are generated using
blocking or non-blocking assignments from initial or always blocks, which means
that they occur in the Active or subsequent regions. Since concurrent assertion
inputs are sampled in the Preponed region before any clock or reset events are
generated, assertions ALWAYS sample their input values before the sampling event
occurs. This is why when we write synchronous assertions we always need to go 1
clock cycle into future and then look into the past with $past() in order to see what
happened on the last clock edge.
In addition to the Preponed and Observed regions, SystemVerilog also includes a
Reactive region where program blocks can schedule their events after the design has
finished evaluating in the Active/Inactive/NBA regions. The idea for this is to avoid
race conditions between the testbench and the design.
10
11. Now that we understand the scheduling semantics, let’s take a look at why the
asynchronous reset assertion failed. On the left-hand side, you can see what the
values of Reset and Q are in their respective regions. In the top assertion, when the
posedge of Reset occurs, the precondition evaluates whether Reset is true (non-
zero). As you can see, in the Preponed region, Reset == 0 so this assertion’s
precondition ALWAYS evaluates to false and the assertion never performs any
checking (this is hard to detect in simulation because it looks like the assertion is
always working and evaluating to true!)
In the bottom assertion, we set the precondition to always evaluate true (i.e., non-
zero) so that the assertion check occurs, but the value sampled for Q in the Preponed
region is 3, not 0. So this assertion always fails except for the case when Q was
already 0 before reset.
Where we need to check the value of Q is sometime after the design has updated Q
in the NBA region. To do so, we need to move the sampling of the assertion inputs
to either the Observed, Reactive, or later regions.
11
12. Let’s have a look at some simple methods we could use to delay the sampling of our
assertion inputs.
12
13. The most common way of handling asynchronous checking is to simply check the
signal synchronously. Either the clock or a fast clock usually suffices to give the
design enough time to update so when the assertion evaluates it samples the correct
input values. For most people this is adequate and it handles any timing delays in
the design, but it also leaves you wondering if the design really did immediately
react to the asynchronous control signal since the actual checking is delayed.
13
14. Alternatively, immediate assertions can be used to check the asynchronous behavior
immediately at the appropriate time. Immediate (or procedural) assertions are
placed inside of procedural blocks of code (initial, always) and sample their inputs
at the time they are evaluated, which is based on their context. By placing the
immediate assertions in the right context, the sampling of their inputs can be delayed
to check the asynchronous behavior.
There are several simple methods that can be used to delay the input sampling,
which will be discuss in the following slides.
14
15. The first method to delay input sampling is to use a program block. Program blocks
sample their inputs in the Observed region and schedule their events in the Reactive
region. By placing the assertion in a program block, the value of Q can be sampled
AFTER the non-blocking assignment is made to it by the RTL when Reset occurs.
Now, when Reset occurs, its results can be immediately observed and checked.
One drawback to using a program block is that not all simulators support nested
programs inside of modules, which means that hierarchical references would be
needed to access the RTL signals. To work around this, a program could be bound
(using bind) into the design unit.
15
16. Sequence events are another way to delay assertion input sampling. The
SystemVerilog standard states that sequence events set their end-point (i.e., when
they are matched) in the Observed region, and that a process resumes it execution
following the Observed region in which the end-point is detected (see IEEE
1800-2005, Section 10.10.1, p. 142).
A sequence event is created by defining a named sequence and then waiting on it as
shown above. The assertion is placed after the sequence event so that its inputs are
sampled after the Observed region. The latest versions of most simulators have
good support for sequence events.
16
17. The expect statement is another useful SystemVerilog construct for delaying input
sampling. The SystemVerilog standard states, “The statement following the expect
is scheduled to execute after processing the Observe region in which the property
completes its evaluation” (IEEE 1800-2005, Section 17.6, p. 299). The advantage of
using expect over just assert is that expect can evaluate temporal expressions and
properties; whereas, assert cannot. Unfortunately, not all simulators delay the
evaluation of expect so a program block can be used as seen before.
17
18. Since the RTL updates using non-blocking assignments, trying to delay sampling to
the NBA region could pose a possible race condition. However, if done correctly, an
immediate assertion can be also be delayed to right after the RTL has finished its
updating. This can be accomplished by using a combination of a non-blocking
event, such as the non-blocking trigger shown above, and the use of a #0 delay.
The non-blocking trigger above will delay the assertion evaluation until at least the
NBA region; however, System/Verilog does not guarantee the order that the always
blocks will evaluate and schedule their events. In order to further delay the assertion
evaluation until after the RTL schedules its update to Q, a #0 delay can be used to
delay the assertion further to the Inactive region as illustrated in this slide. Using
the #0 delay, the order that the non-blocking events no longer matters and the
assertion can be guaranteed to always sample its inputs and evaluate at the correct
moment in simulation time.
For older simulators that do not implement the non-blocking trigger construct, the
following could also be used:
always @(posedge Reset)
myReset <= Reset;"
always @(posedge myReset)
#0 assert( Q == 0 );"
18
19. Clocking blocks can also be used for delaying immediate assertion input sampling.
When an “input #0” is specified in a clocking block, the inputs are sampled in the
Observed region. Using the clocking block then means that the inputs are always
sampled after the design has finished updating.
Unfortunately, clocking blocks do not give the same results in all simulators the first
time Reset occurs. Since System/Verilog indeterminately executes processes, a race
condition may exist between when the assertion reads the clocking block variable
and when it gets updated, resulting in an X for Q the first time Reset occurs. To
solve this, it is usually adequate to wait on the clocking block.
19
20. Immediate assertions generally do not allow us to use the SVA temporal syntax that
we get with concurrent assertions. Concurrent assertions are limited by the standard
on when they can sample their inputs---inputs must be sampled in the Preponed
region. However, there are 2 workarounds that we can consider.
20
21. The first way to make a concurrent assertion work is to delay the sampling event. A
simple concurrent assignment with a #1 delay is adequate enough to delay the input
sampling long enough for the asynchronous assertion to evaluate correctly. Of
course, some might object that this is not much different than sampling with a clock
because there is a possibility of glitches between the asynchronous event and the
actual check. However, a #1 delay should be small enough to not worry too much
about this. While not exactly standard, some simulators support using #1step in an
assignment, which essentially delays the assertion evaluation to the Postponed
region and removes the possibility of missing any glitches. One major simulator
(Modelsim/Questasim) supports #step instead.
21
22. Another way to delay input sampling is by calling a task or function in a concurrent
assertion. The SystemVerilog standard states that subroutines called in a sequence
are to be evaluated in the Reactive region. By using a ref on a task argument, the
current value is sampled in the Reactive region. Unfortunately, not all simulators
treat functions the same as tasks so a workaround is to not pass the thing to be
sampled as a function argument but to simply sample it within its declarative scope
inside the function. Since the signal is not an argument, it is not an assertion input
and not sampled in the Preponed region but in the Reactive region---the region of its
evaluating context.
22
23. Delaying the input sampling for assertions works great for RTL simulation, but what
happens when timing delays are inserted in a gate-level simulation? Now of these
assertions would work because the RTL does not change on the same time step as
the asynchronous event.
Instead, our assertions need to wait for the asynchronous event and then watch for
the design to change before checking. We could use a multi-clocked sequence as
shown above to wait for the design to update.
However, what if Q was already 0 so @Q never evaluates because there was no
value change? It could be qualified using a conditional statement, but there still
exists 2 problems: (1) there is the same sampling issue of Q when @Q occurs since
the input is sampled in the Preponed region, and (2) how can it guaranteed that Q
changed because of Reset event that triggered it? What if Q did not change from
Reset but when the counter started counting again? Even if it is qualified with Reset
being high, Q might not change until a future Reset event and not the current one.
23
24. The best solution to this problem is probably a compromise using a multi-clocked
sequence with Reset and the Clock. The assertion will trigger asynchronously when
the Reset event occurs, but then Q is sampled using the Clock to ensure that it
eventually updates while under Reset given a window of time specified by some
timeout constant. This makes it easy to change the assertion to compensate for gate-
delays with the gate-level netlist, to ensure that Q changes within an acceptable
window of time, and that Q actually responses to the corresponding Reset event.
24
26. Here are some guidelines to follow when handing asynchronous behaviors with
SVA …
26
27. For more information on writing asynchronous assertions, please see the following
paper:
Doug Smith. “Asynchronous Behaviors Meet Their Match with SVA,”
DVCon Proceedings, February 2010.
This paper describes in detailed what is presented here, plus discusses how to handle
asynchronous communication using multi-clocked sequences. The full paper can be
downloaded from the Doulos website (www.doulos.com).
27