Browse Prior Art Database

Utilizing Extraneous Random Instructions Driving and Then Removing Redundant Transactions From Instruction Pipelines To Verify Execute and Subject of EXecute Instructions In A Unit Simulation Environment For Mainframe Processor

IP.com Disclosure Number: IPCOM000196353D
Publication Date: 2010-Jun-01
Document File: 3 page(s) / 63K

Publishing Venue

The IP.com Prior Art Database

Abstract

This publication relates to a simulation method for verifying Execute and SOE (Subject of Execute) instructions in a unit simulation environment for mainframe processors. In a typical unit simulation environment, the decode and dispatching of the Execute and Subject of Execute instructions are being verified in a instruction decode unit (IDU). The simulation environment involves drivers from instruction fetch units (IFU), instruction issue unit (ISU) and execution unit (FXU) and a transactional pipeline monitor to monitor the decode/dispatching logic of Execute and SOE. In this particular simulation model, random instructions with EX instructions are driven into the IDU together with random register values from FXU and random rescind signals from ISU. Random instructions are continuously driven into the IDU until IDU raised ready to accept SOE signal and at that point, SOE is marked in the transactional pipelines and with the register value from FXU to generate new modified SOE in the pipeline. The outcome of this SOE is then compared to the hardware's SOE. The simulation has to accurately predict the SOE in the transactional pipeline and remove redundant instructions after the Execute are being accepted into IDU , and capture the right register value from FXU for modifying the SOE. And this article has disclosed the method to accomplish all these.

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 52% of the total text.

Page 1 of 3

Utilizing Extraneous Random Instructions Driving and Then Removing Redundant Transactions From Instruction Pipelines To Verify Execute and Subject of EXecute Instructions In A Unit Simulation Environment For Mainframe Processor

The definition of the execute instruction is that the single instruction at the second-operand address is modified by the contents of general register R1, and the resulting instruction, called the target instruction, is executed. In this latest zEnterprise 196 processor design, Execute instruction in this design involves multiple units services before it is being executed completely. The units involved will be the instruction fetch unit (IFU), instruction decode unit (IDU), instruction execution unit (FXU), load and store unit (LSU) and instruction issue unit (ISU). This invention is about the solution of verifying this complex design of the execute instruction at both unit and core level simulation. The major challenge for the verification will be to predict the correct SOE coming into the pipeline and to compare it to the actual SOE generated from hardware to verify the decode and dispatch logic of the design. At unit level simulation, at which we only verify the decode and dispatch logic at IDU, it is important that we covered the spectrum of the incoming signals. And at both unit and core level simulation, monitors will be set up to verify the various sequences of decode and dispatch events. In the past, the EXecute is always the last instruction sent over from IFU to IDU before SOE
is sent. There is no overhead of verifying the internal kills from IDU to the subsequent instructions after EXecute. But when there are extra instructions sent after Execute, we will catch bugs like unexpected decode is seen during the wait period for SOE or decode is out of sequence and caused wrong results for execution. In this simulation model, we stressed the drivers and monitors to ensure the correct design of the Execute instruction. The simulation task is to come up with drivers that mimic IFU,ISU and FXU units and then the monitor to monitor the outcome of the decode and dispatching events. There are three drivers and 2 monitors in the IDU...