Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Implementation Verification Program Format Definition for Processor Verification

IP.com Disclosure Number: IPCOM000036846D
Original Publication Date: 1989-Nov-01
Included in the Prior Art Database: 2005-Jan-29
Document File: 3 page(s) / 94K

Publishing Venue

IBM

Related People

Moore, CR: AUTHOR

Abstract

A simulation environment has been developed for verification of complicated processor designs. The environment uses a cycle simulator with a user exit facility installed in the VM nucleus. A sophisticated simulation control program called RTX acts as an interface between all testcases and the actual simulation model. RTX has been developed to accept both Architecture Verification Programs (AVPs) and Implementation Verification Programs (IVPs). This article addresses the format of the IVPs and their interface to RTX which allows the required flexibility demanded by the IVPs while keeping the data management problem associated with large-scale system verification under control.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Implementation Verification Program Format Definition for Processor Verification

A simulation environment has been developed for verification of complicated processor designs. The environment uses a cycle simulator with a user exit facility installed in the VM nucleus. A sophisticated simulation control program called RTX acts as an interface between all testcases and the actual simulation model. RTX has been developed to accept both Architecture Verification Programs (AVPs) and Implementation Verification Programs (IVPs). This article addresses the format of the IVPs and their interface to RTX which allows the required flexibility demanded by the IVPs while keeping the data management problem associated with large-scale system verification under control.

Each AVP has an initialization section, an instruction section (the architected function to be tested) and a results-checking section. The scope of the AVP verification is, as the name implies, limited to architecture-related features of the system. The scope of overall verification is much larger than architected instruction verification and often requires that stimulus be applied to the model in ways that cannot be accommodated by instructions alone and at times that are somewhat variable. These diverse requirements drove development of the concept of an IVP. The IVP is characterized by an AVP section and some associated control code that serves to provide the 'asynchronous' stimulus to the model under test.

There are several points in the execution of an AVP that a testcase writer may want to apply some 'asynchronous' stimulus. First, after the AVP has been initialized, the IVP writer may want to initialize model facilities that are not accessible from architected instructions or, for example, the IVP writer may want to inject ECC errors into a memory location that was previously initialized by the AVP section. Next, as the simulation progresses, the IVP writer may want to detect a condition and then act on upon it. For example, the writer may want to detect that a particular address has appeared on a bus...