Method for verifying intermediate results of a randomly generated testcase of Processor Functional Validation Exerciser.
Publication Date: 2015-Oct-16
The IP.com Prior Art Database
Disclosed is a device for verification of intermediate results of complex, random testcases generated by a Processor Functional Validation Exerciser. The technique enables both checking of interim results generated during execution of test stream and faster debug of long and complex test streams. It provides finer controls that allow user to enable its use at architected register level for isolation of the fails. The technique is based on tracking of interim test results including architectural interrupt state through use of predictable interrupts which are naturally generated in testcase as part of validation. The signatures of interim test results are saved at every interrupt and are compared at the end of the test. A mismatch indicates a functional error during execution of the instruction stream.
Page 01 of 9
Method for verifying intermediate results of a randomly generated testcase of Processor Functional Validation Exerciser .
Modern microprocessors have become extremely complicated, involving superscalar pipelines, out-of-order instruction execution, and new generation of architected
instructions and registers. This complexity increases the demand for fast but reliable validation and debug methods to ensure timely delivery of new chips to the market with as
few errors as possible. As a result, processor validation exerciser focuses on generation of long, complex test streams (aka testcases) to cover maximum possible test combinations
in minimal time. In order to verify intermediate results meaning contents of architected registers and test storage at various instances during execution of such testcases,
different types of techniques are adopted by validation exerciser in general.
These are known traditional methods used for verification of intermediate results of a testcase:
1. Use special instructions to observe intermediate results by storing registers into designated READ-ONLY portion of testcase memory before they get overwritten
in the testcase. This method requires special allocation of memory locations in test storage for holding the intermediate content of architected registers that get modified in the testcase. Also, special store instructions needs to be built as part of the testcase to save the register content. This can possibly degrade quality of the testcase due to insertion of
"forced" stores in instruction stream for observation of interim values affecting random nature of the testcase. This approach only takes care of verification of interim values
in registers and does NOT enable verification of intermediate testcase memory content.
2. Split long testcase into (say) 4 blocks of back to back testcases. Each block is followed by instructions to save ALL architected registers modified
in the block into designated memory before proceeding to execution of next block of instruction stream. Then, compare results of individual blocks of instructions
at the end of entire testcase. This approach requires pre-generation of observable stores in the testcase without giving user flexibility to enable / disable such stores on the fly.
For example, even if user wants to store interim results only at the time of debug of a fail, the sequence of observable stores will still be pre-generated and executed in the testcase. This becomes an inefficient way of saving and checking of intermediate results. Also, it does
NOT address the problem of shorter instruction streams which target limited
number of registers in the testcase and thus, the interim results are NOT saved and verified.
3. Build shorter instruction streams such that intermediate results do NOT get overwritten in the testcase. The shorter instruction streams restrict overall test coverage.
This involves overhead of re-generation of instruction streams, initialization...