Search Results
Filters
Advanced Search
2183 Results
-
UVM Monitor
Chapter - Mar 30, 2014 by Verification Methodology Team
The first task of the analysis portion of the testbench is to monitor activity on the DUT. A Monitor, like a Driver, is a constituent of an agent.
-
UVM Factory
Chapter - Mar 27, 2014 by Verification Methodology Team
The purpose of the UVM factory is to enable an object of one type to be substituted with an object of a derived type without changing the testbench structure or even the testbench code.
-
Post-Run Phases
Chapter - Mar 27, 2014 by Verification Methodology Team
Many analysis components perform their analysis on an ongoing basis during the simulation run.
-
Backdoor Accesses
Chapter - Mar 27, 2014 by Verification Methodology Team
The UVM register model facilitates access to hardware registers in the DUT either through front door accesses or back door accesses.
-
Package Organization
Chapter - Mar 27, 2014 by Verification Methodology Team
UVM organizes all of its base classes into a SystemVerilog Package.
-
UVM Verification Component
Chapter - Mar 27, 2014 by Verification Methodology Team
A UVC ( U VM V erification C omponent) is a Verification Component designed for use in UVM. It is a multi-faceted definition and has different layers of meaning in different contexts.
-
UVM Connect
Chapter - Mar 26, 2014 by Adam Erickson
Learn about how to use UVM Connect to link UVM and SystemC using TLM.
-
UVMC Connections
Chapter - Mar 26, 2014 by Adam Erickson
To communicate, verification components must agree on the data they are exchanging and the interface used to exchange that data.
-
UVMC Conversion
Chapter - Mar 26, 2014 by Adam Erickson
Object transfer requires converters to translate between the two types when crossing the SC-SV language boundary.
-
UVMC Command API
Chapter - Mar 26, 2014 by Adam Erickson
The UVM Connect Command API gives SystemC users access to key UVM features in SystemVerilog.
-
Are You Really Confident That You Are Getting the Very Best From Your Verification Resources?
Paper - Mar 06, 2014 by Darron May
Getting the very best from your verification resources requires a regression system that understands the verification process and is tightly integrated with Workload Management and Distributed Resource Management software. Both requirements depend on visibility into available software and hardware resources and by combining their strengths, users can massively improve productivity by reducing unnecessary verification cycles.
-
Are You Really Confident That You are Getting the Very Best From Your Verification Resources?
Resource (Paper (.PDF)) - Mar 06, 2014 by Darron May
Getting the very best from your verification resources requires a regression system that understands the verification process and is tightly integrated with Workload Management and Distributed Resource Management software.
-
Bringing Regression Systems into the 21st Century
Paper - Mar 03, 2014 by Thomas Ellis
Today's verification projects are responsible for verifying some of the largest and most complex designs we have ever seen. Accordingly, the gathering and tracking of development and verification metrics, including coverage and test results, is more important than ever to project success. From figuring out what files are necessary in building a DUT (Design Under Test) and Testbench to knowing what development and verification metrics need to be gathered and tracked, the task can be significant.
-
Bringing Regression Systems into the 21st Century
Resource (Paper (.PDF)) - Mar 03, 2014 by Thomas Ellis
This paper will focus on an infrastructure created at Cypress to abstract away file list and metric gathering by providing a uniform front-end shell and back-end database, boosting predictability of testbench creation and metric tracking across multiple projects. Additionally, this paper will discuss various metrics collected and the use of Verification Run Manager (VRM) toolset in gathering metrics, tracking coverage and reducing test suites to quickly and efficiently obtain coverage goals.
-
Questa Verification IP, More than just a BFM
Webinar - Feb 12, 2014 by Tom Fitzpatrick
Today’s advanced UVM environments require more than a standard BFM to support environment reuse, randomized stimulus, generation of traffic scenarios, coverage collection, etc.
-
UART Example (.tgz)
Resource (Tarball) - Dec 04, 2013 by Verification Methodology Team
Most of the functional coverage can be derived from content of the registers which are used to control and monitor the behavior of the device. The register interface may also serve the data path. There may be scope for using assertions on signal interfaces.
-
Specification to Test Plan
Chapter - Dec 04, 2013 by Harry Foster
The goal in creating a coverage model spreadsheet or testplan is to capture a subset of the design intent and behavior that is targeted for functional coverage.
-
UART Example Test Plan
Chapter - Dec 04, 2013 by Harry Foster
As part of the verification planning process, a test plan should be drawn up to list all the design features to be tested and to help identify the type of functional coverage required to check that all the tests have been run for all conditions.
-
Executable Test Plan Format
Chapter - Dec 04, 2013 by Harry Foster
A testplan is a document which captures the important features of a design and how they will be verified.
-
Cookbook Code Examples
Chapter - Dec 04, 2013 by Verification Methodology Team
The UVM Cookbook has a number of UVM code examples which are designed to help illustrate the various topics discussed. The link to each example also appears on the appropriate cookbook page.
-
UART Reference
Resource (Reference Documentation) - Dec 04, 2013 by Verification Methodology Team
The Siemens EDA UART is a soft design IP core. It has been designed to be generally compatible with the industry standard 16550A UART, but there are a small number of differences.
-
Block Level Functional Coverage Example
Chapter - Dec 04, 2013 by Harry Foster
Block level functional verification can take full advantage of the the fact that all the block interfaces are exposed and can be stimulated separately with complete freedom.
-
Testplan to Functional Coverage
Chapter - Dec 04, 2013 by Harry Foster
Arriving at functional coverage closure is a process that starts with the functional specification for the design, which is analyzed to determine: What features need to be tested Under what conditions the features need to be tested What testbench infrastructure is required to drive and monitor the design's interfaces How the testbench will check that the features work
-
Bus Protocol Coverage
Chapter - Dec 04, 2013 by Harry Foster
A bus protocol defines how data is transferred between master and slave devices on the bus. The protocol specifies which signals are used to qualify when the master is making a request and when the slave is ready to respond to that request.
-
UART Example Covergroups
Chapter - Dec 04, 2013 by Harry Foster
The covergroup examples on this page are implementations of the functional coverage descriptions on the Block Level Functional Coverage Example page.