Generating and verifying hardware instruction traces including memory data contents
Embodiments of the present invention are directed to a computer-implemented method for generating and verifying hardware instruction traces including memory data contents. The method includes initiating an in-memory trace (IMT) data capture for a processor, the IMT data being an instruction trace collected while instructions flow through an execution pipeline of the processor. The method further includes capturing contents of architected registers of the processor by: storing the contents of the architected registers to a predetermined memory location, and causing a load-store unit (LSU) to read contents of the predetermined memory location.
Latest IBM Patents:
- AUTO-DETECTION OF OBSERVABLES AND AUTO-DISPOSITION OF ALERTS IN AN ENDPOINT DETECTION AND RESPONSE (EDR) SYSTEM USING MACHINE LEARNING
- OPTIMIZING SOURCE CODE USING CALLABLE UNIT MATCHING
- Low thermal conductivity support system for cryogenic environments
- Partial loading of media based on context
- Recast repetitive messages
The present invention relates generally to computer system performance modeling, and more particularly to providing improved trace data.
Data processing systems which use virtual addressing in multiple virtual address spaces are well known. Many data processing systems include, for example, a central processing unit (CPU) and a main storage. The CPU contains the sequencing and processing facilities for instruction execution, interruption action, timing functions, initial program loading and other machine related functions. The main storage is directly addressable and provides for high-speed processing of data by the CPU. The main storage may be either physically integrated with the CPU or constructed in stand-alone units.
In general, address spaces reside in main storage wherein an address space is a consecutive sequence of integer numbers (or virtual addresses), together with the specific transformation parameters which allow each number to be associated with a byte location in storage. The sequence starts at zero and proceeds left to right.
When a virtual address is used by a CPU to access main storage, it is first converted, by means of dynamic address translation (DAT), to a real address, and then, by means of prefixing, to an absolute address. DAT uses various levels of tables as transformation parameters and translates a virtual address of a computer system to a real address by means of translation tables. The designation (in the past, including origin and length) of a table is found for use by DAT in a control register or as specified by an access register.
Tracing assists in determining whether problems exist in the data processing system by providing an ongoing record in storage of significant events, or benchmarks. An example of a tracing system is the Console Monitoring System (CMS) Adjunct Tracing System (CATS), which consists of a coherent, sequential and generally contiguous set of architected instruction records which are captured while processing instructions through a data processing system.
SUMMARYEmbodiments of the present invention are directed to a computer-implemented method for generating and verifying hardware instruction traces including memory data contents. The method includes initiating an in-memory trace (IMT) data capture for a processor, the IMT data being an instruction trace collected while instructions flow through an execution pipeline of the processor. The method further includes capturing contents of architected registers of the processor by storing the contents of the architected registers to a predetermined memory location and causing a load-store unit (LSU) to read contents of the predetermined memory location.
In one or more examples, causing the LSU to read the contents of the predetermined memory location includes generating a memory fetch control record and a memory fetch data record in the IMT data capture. In one or more examples, a structure of the memory fetch control record is based on a type of the processor.
In one or more examples, the contents of the operands of the instruction are captured in response to a breakpoint. For example, the breakpoint is a fetch instruction from a time-dependent store location. For example, the breakpoint is an input-output type instruction. For example, the breakpoint is an external interrupt.
In one or more examples, the contents of the architected registers are captured in response to the IMT data capture being initialized in extended-IMT mode. Further, in one or more examples, in the extended IMT-mode, the IMT data capture also includes values of operands in the instructions being executed. The values of the operands are captured using memory fetch control and memory fetch data records, and their addresses are captured using source operand records and/or destination operand records.
In one or more examples, the contents of the architected registers are captured after every predetermined number of instructions are executed by the processor.
In one or more examples, the processor is a first processor, and the method further includes executing, using a second processor, the instruction traced by the first processor using the IMT capture data.
In one or more examples, the method further includes executing, using a simulated processor, the instruction traced by the processor using the IMT capture data.
In one or more examples, the contents of the operands are captured in response to the IMT data capture is initiated in extended-IMT mode. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.
Further, in one or more examples, the method further includes, prior to capturing the IMT data, verifying IMT data records. The verification is performed by generating a pseudo IMT capture using a first AVP file, generating a second AVP file using the pseudo IMT, and comparing the first AVP file and the second AVP file.
Embodiments of the present invention are directed to a system for generating and verifying hardware instruction traces including memory data contents. A non-limiting example of the system includes a memory and a processor coupled with each other. The processor receives a request to initiate an in-memory trace (IMT) data capture, the IMT data being an instruction trace collected while instructions flow through an execution pipeline of the processor. The processor captures content of architected registers of the processor in the IMT data by storing the contents of the architected registers to a predetermined memory location and causing a load-store unit (LSU) to read contents of the predetermined memory location.
Embodiments of the invention are directed to a computer program product for generating and verifying hardware instruction traces including memory data contents. The computer program product includes a computer-readable storage medium having program instructions embodied therewith. The program instructions are executable by a processor to cause the processor to perform a method. A non-limiting example of the method includes initiating an in-memory trace (IMT) data capture for a processor, the IMT data being an instruction trace collected while instructions flow through an execution pipeline of the processor. The method further includes capturing contents of architected registers of the processor by storing the contents of the architected registers to a predetermined memory location and causing a load-store unit (LSU) to read contents of the predetermined memory location.
Further, embodiments of the present invention include an apparatus for testing a processor. The apparatus may be a testing system. The apparatus receives a request to initiate an in-memory trace (IMT) data capture for a processor, the IMT data being an instruction trace collected while instructions flow through an execution pipeline of the processor. The apparatus captures content of architected registers in the IMT data by storing the contents of the architected registers to a predetermined memory location; and causing a load-store unit (LSU) to read contents of the predetermined memory location. The apparatus further generates a test sequence using the captured IMT data, the test sequence including the instruction and the contents of the architected registers from the captured IMT data. The apparatus further executes the test sequence using a second processor.
Further yet, embodiments of the present invention include a computer-implemented method for testing a processor, the method including initiating an in-memory trace (IMT) data capture for a processor, the IMT data being an instruction trace collected while instructions flow through an execution pipeline of the processor. The method further includes, in response to the IMT data captured initiated in an extended mode, capturing contents of architected registers of the processor in the IMT data by storing the contents of the architected registers to a predetermined memory location; and causing a load-store unit (LSU) to read contents of the predetermined memory location. The computer-implemented method also includes generating a test sequence using the captured IMT data, the test sequence including the instruction and the content of the architected registers from the captured IMT data. The computer-implemented method also includes executing the test sequence using a second processor.
Additional technical features and benefits are realized through the techniques of the present invention. Embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, refer to the detailed description and to the drawings.
The specifics of the exclusive rights described herein are particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other features and advantages of the embodiments of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
The diagrams depicted herein are illustrative. There can be many variations to the diagram or the operations described therein without departing from the spirit of the invention. For instance, the actions can be performed in a differing order or actions can be added, deleted or modified. Also, the term “coupled” and variations thereof describes having a communications path between two elements and does not imply a direct connection between the elements with no intervening elements/connections between them. All of these variations are considered a part of the specification.
In the accompanying figures and following detailed description of the disclosed embodiments, the various elements illustrated in the figures are provided with two or three digit reference numbers. With minor exceptions, the leftmost digit(s) of each reference number correspond to the figure in which its element is first illustrated.
DETAILED DESCRIPTIONVarious embodiments of the invention are described herein with reference to the related drawings. Alternative embodiments of the invention can be devised without departing from the scope of this invention. Various connections and positional relationships (e.g., over, below, adjacent, etc.) are set forth between elements in the following description and in the drawings. These connections and/or positional relationships, unless specified otherwise, can be direct or indirect, and the present invention is not intended to be limiting in this respect. Accordingly, a coupling of entities can refer to either a direct or an indirect coupling, and a positional relationship between entities can be a direct or indirect positional relationship. Moreover, the various tasks and process steps described herein can be incorporated into a more comprehensive procedure or process having additional steps or functionality not described in detail herein.
The following definitions and abbreviations are to be used for the interpretation of the claims and the specification. As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” “contains” or “containing,” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a composition, a mixture, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but can include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.
Additionally, the term “exemplary” is used herein to mean “serving as an example, instance or illustration.” Any embodiment or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms “at least one” and “one or more” may be understood to include any integer number greater than or equal to one, i.e. one, two, three, four, etc. The terms “a plurality” may be understood to include any integer number greater than or equal to two, i.e. two, three, four, five, etc. The term “connection” may include both an indirect “connection” and a direct “connection.”
The terms “about,” “substantially,” “approximately,” and variations thereof, are intended to include the degree of error associated with measurement of the particular quantity based upon the equipment available at the time of filing the application. For example, “about” can include a range of ±8% or 5%, or 2% of a given value.
For the sake of brevity, conventional techniques related to making and using aspects of the invention may or may not be described in detail herein. In particular, various aspects of computing systems and specific computer programs to implement the various technical features described herein are well known. Accordingly, in the interest of brevity, many conventional implementation details are only mentioned briefly herein or are omitted entirely without providing the well-known system and/or process details.
Turning now to an overview of technologies that are more specifically relevant to aspects of the invention, a data processing system, such as computer server, capture in-memory trace (IMT) data that includes an instruction trace collected by hardware while instructions flow through an execution pipeline. For example, data processing systems such as z Systems® processor cores, include a function of capturing hardware instruction traces as IMT data. Capturing the IMT data have addressed and resolved the technical challenges of conventional tracing methodology using CMS Adjunct Tracing System (CATS) by enabling capture of traces with millicode instructions for complex workloads. Typically, such capture requires a highly skilled engineer and replication of the complex workload environment is performed in a virtual machine to capture the CATS traces. Previously such data were unable to be traced using CATS or had required a highly skilled engineer to replicate a complex workload environment in a virtual machine to capture CATS traces. However, unlike CATS traces, IMT traces do not provide memory data contents, which are used for reverse engineering data flow that enables the generation of CAP sequence test cases, via a controlled testing suite, such as a Complete Automation Package (CAP) testcase suite. CAP test cases have been used for performance verification of new processor cores by measuring/comparing infinite CPI (cycles per instructions) on core performance model, core hardware description language (e.g. VHDL) simulator, and actual hardware. Such a lack of data contents in IMT trace prevents reflecting new customer workloads using new instruction sets for performance verification, which is crucial for developing next-generation processor cores.
Turning now to an overview of the aspects of the invention, one or more embodiments of the invention address the above-described technical challenges by facilitating generating and verifying hardware instruction traces including memory data contents in IMT. The technical features herein further facilitate generating CAP test cases from IMT traces using existing infrastructures and tools. Further, the technical features facilitate verifying the memory data contents.
Turning now to a more detailed description of aspects of the present invention, referring to
Typically the instruction fetch unit 110 (IFU) is employed to fetch instructions on behalf of the processor 105. The IFU 110 either fetches “next sequential instructions”, target instructions of branch taken instructions, or first instructions of a program following a context switch. In one or more examples, IFU 110 employ prefetch techniques to speculatively prefetch instructions based on the likelihood that the prefetched instructions might be used. For example, the IFU 110 fetches 16 bytes of instruction that includes the next sequential instruction and additional bytes of further sequential instructions.
The fetched instructions are then executed by the processor 105. In one or more examples, the fetched instruction(s) are passed to a dispatch unit of the IFU 110. The dispatch unit decodes the instruction(s) and forwards information about the decoded instruction(s) to appropriate units of the processor 105. For example, the processor 105 includes an execution unit 112 that receives information about decoded arithmetic instructions from the IFU 110 and performs arithmetic operations on operands according to the opcode of the instruction. Operands are provided to the execution unit 112 preferably either from memory 115, architected registers of the processor 105, and/or from an immediate field of the instruction being executed. Results of the execution, when stored, are stored either in memory 115, architected registers, and/or in other machine hardware (such as control registers, PSW registers and the like).
The processor 105 also includes a load/store unit 114 (LSU). The processor 105 accesses storage using the LSU 114. The LSU 114 performs a load operation by obtaining the address of the target operand in memory and loading the operand in a register or another memory location, or performs a store operation by obtaining the address of the target operand in memory and storing data obtained from a register or another memory location in the target operand location in memory. In one or more examples, the LSU 114 is speculative and may access memory in a sequence that is out-of-order relative to instruction sequence, however the LSU 114 is to maintain the appearance to programs that instructions were executed in order. The LSU 114 communicates with components of the processor 105, such as IFU 110, execution unit 112, registers, decode/dispatch unit, cache/memory interface or other elements of the processor 105 and comprises various register circuits, ALUs and control logic to calculate storage addresses and to provide pipeline sequencing to keep operations in-order. Some operations may be out of order but the load/store unit provides functionality to make the out of order operations to appear to the program as having been performed in order, as is well known in the art.
Typically, addresses that an application program “sees” are often referred to as virtual addresses. Virtual addresses are sometimes referred to as “logical addresses” and “effective addresses”. These virtual addresses are virtual in that they are redirected to physical memory location by one of a variety of dynamic address translation (DAT) technologies including, but not limited to, simply prefixing a virtual address with an offset value, translating the virtual address via one or more translation tables, the translation tables preferably comprising at least a segment table and a page table alone or in combination, preferably, the segment table having an entry pointing to the page table. For example, in some processors, a hierarchy of translation is provided including a region first table, a region second table, a region third table, a segment table and an optional page table. The performance of the address translation is often improved by utilizing a translation lookaside buffer (TLB), which comprises entries mapping a virtual address to an associated physical memory location. The entries are created when the DAT translates a virtual address using the translation tables. Subsequent use of the virtual address can then utilize the entry of the fast TLB rather than the slow sequential translation table accesses. TLB content may be managed by a variety of replacement algorithms including LRU (Least Recently used).
In the case where the processor 105 is a processor of a multi-processor system, each processor has responsibility to keep shared resources, such as I/O, caches, TLBs and memory, interlocked for coherency. Typically, “snoop” technologies are utilized in maintaining cache coherency. In a snoop environment, each cache line may be marked as being in any one of a shared state, an exclusive state, a changed state, an invalid state and the like in order to facilitate sharing.
The processor 105 may be coupled in communication with a number of TLBs, which are cache memories that generally hold only translation table mappings. On every reference, the TLB is used to look up a virtual page number for the reference. If there is a hit, a physical page number is used to form the address, and the corresponding reference bit is turned on. If a miss in the TLB occurs, and if the referenced page exists in memory, the translation can be loaded from the page table in the memory 115 into the TLB and the reference can be tried again. If the page is not present in the memory 115, a page fault has occurred and the CPU must be notified with an exception.
In one embodiment, the TLBs include a first level TLB 120 or “TLB1”, and a second level TLB 125 or “TLB2” that supports the TLB1. In one embodiment, the TLB1 includes an instruction cache (I-cache) 130 corresponding to an instruction TLB or “ITLB” and a data cache (D-cache) 135 corresponding to a data TLB or “DTLB.”
The TLBs are described herein, without limitation, as an embodiment adapted to z Systems® architecture. This architecture uses TLB combined region-and-segment-table entries (CRSTE) connected to TLB page-table entries (PTE), where first regions, then segments and thereafter pages is the order in which address translation takes place.
It should be noted that examples herein are described in conjunction to architecture of z Systems®, however the system 100 can be used in conjunction with any suitable computer architecture in other examples.
The system 100 described herein is merely exemplary. The system may include any additional components as necessary to provide for processing of data. Exemplary components include, without limitation, storage, memory, input devices, output devices and the like. As these components are known to those skilled in the art, these are not depicted in any detail herein.
In one or more examples, the IMT is captured as a trace segment table, including a variety of record types. As used herein, “table” refers to a collection of trace segments, which may take any suitable form, such as a virtual or memory page. One or more record types may make up one or more trace record segments and may be referred to as Translations Instructions Addresses, or “TrInA”, record segments. These records may be created by different units, such as the CPU 105, and may be stored, for example, in memory 115 or other suitable location. It should be noted that for an instruction executed, a group of IMT records are collected. The number and type of records are dependent on the instruction type. For example, a memory instruction that results in fetching/storing operand results in the IMT including SRCOP and/or DESTOP records (depending on the number of operands). If either instruction fetch or data fetch misses TLB1 then, all of some of translation records (Virtual address . . . PTO records) are written depending on the CRSTE/PTE hit and level of translation table required for the address translation.
Referring to
an instruction record 300 for each instruction (from fetched instruction, which is the instruction being processed/executed);
an instruction Address (IA) and Time of Day (TOD) record 400 (i.e., IA+TOD) (from fetched instruction);
an Instruction Translation Lookaside Buffer (ITLB) record 500 (from TLB1); and
operand records as necessary (from fetched instruction), such as source operand record 600 and destination operand record 700. Depending on the instruction type, zero or more operand records may be generated.
In one or more examples, the trace segment table 200 may also include a Primary Address Space Number (PASN) record 800 (from fetched instruction).
Alternatively, if the system area is accessed, the ITLB and operand records may include:
an ITLB System Area record 900 (from TLB1); and
operand system area records (from fetched instruction) as necessary, such as source operand (system area) record 1000 and a destination operand (system area) record 1100.
In the situations where a TLB miss occurs, various translation records may be generated. Multiple layers of translation are supported and may be encoded in these translation records. Dependent upon the types of record segments passed, and the specific bit values, the type of translation miss or hit may be determined, and where the system the translation activity took place may also be determined, e.g. where in the PTE/CRSTE. Examples of such translation records include:
a virtual address record 1200 (from TLB1 and/or TLB2);
an absolute address record 1300 (from TLB1 and/or TLB2);
an address space control element (ASCE) record 1400 (from TLB1 and/or TLB2);
a region second table origin (RSTO) record 1500 (from TLB2);
a region third table origin (RTTO) record 1600 (from TLB2);
a segment table origin (STO) record 1700 (from TLB2); and
a page table origin (PTO) record 1800 (from TLB2).
In one or more examples, a comment record 2000 may also be included in the trace segment table 200. The comment record may be added during post-processing.
There is provided a method for generating trace segments, generating traces from the trace segments and validating generation results. The method includes one or more of the following stages. Note that the method need not include every stage described herein, and is not limited to the order in which the stages are presented. The method is described herein in conjunction with the system 100, although the method may be performed in conjunction with any type, number and configuration of processors or processing systems.
In a first stage, a minimum number of trace segments is determined. For example, if a TLB miss occurs, translation information may be loaded into the TLB1, for example, and translation records such as the virtual address, absolute address and ASCE records may be generated as trace segments. In another example, operand information from an instruction may be used to determine whether operand record segments should be generated.
In a second stage, various trace segments as described above may be generated. Information for the trace segments may be taken from any needed storage areas and may utilize various pages such as the instruction, PSW, ASCE, etc.
Referring to
In one embodiment, a C (or other programming language) program is created to generate the trace record segments, which will allow users to determine how much data to be put out in various environments. The program may also be used to prepare for processing the actual record segments.
Referring to
In one embodiment, a C (or other programming language) program is written to process the record segments 305 and generate the CATS sub-trace 315. The same C program may be later used to process the record segments 305 generated by a system hardware.
Referring to
Referring to
It should be noted that in one or more examples, pseudo-IMT is generated before a VHDL simulator of a processor that is being tested/evaluated is available. For example, the pseudo-IMT is generated from a core model, (CPI analysis tool in
It should be noted that the method described herein is just an example. There may be many variations to the stages (or operations) described therein without departing from the spirit of the invention. For instance, the stages may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.
However, one of the technical limitations of the IMT captured using the existing techniques is depicted in
The technical solutions described herein for capturing the IMT address such technical challenges. For example, in addition to the records above, the technical solutions described herein facilitate the collection of information to build initial contents of all architected registers and memory accessed by instructions in testcase, so that a CMD or AVP file can be created from the captured IMT. A CMD file is a file containing initial contents of all architected registers and memory accessed by instructions in testcase, which can run on test systems, such as on IMT testing systems, such as proprietary internal systems. An AVP file is file containing initial contents of all architected registers and memory accessed by instructions in testcase, which can run on VHDL core simulator.
To facilitate the above scenario, of using the IMT trace with memory data contents 520 to directly generate the sequence testcases 480, the system 100 collects all necessary information in IMT 520 to enable instruction execution (such as for z Systems®) in VHDL sim or real hardware. In one or more examples, because collecting the memory data contents causes additional slowdown, the system 100 can be run in two different modes, a normal-IMT mode and an extended-IMT mode. Normal IMT mode generates instruction traces without the memory data contents, and thus with traces that are enough to drive core performance model, like in
Instead, if the extended-IMT mode is selected, the processor captures the memory data content for generating the sequence testcases, as shown at 615. In one or more examples, in the case of the extended-IMT mode, the processor 105 uses the LSU 114 to write MFC (memory fetch control) and MFD (memory fetch data) records for all instructions whose operand fetches data from memory.
For example, as depicted in
The processor 105 continues the IMT capture until a condition for capturing contents of the architected registers occurs, as shown at 640. In response to the condition, the processor captures the contents of the architected registers by forcing a memory write and read of architected registers to capture contents in the IMT using the LSU 114, as shown at 645. Any memory data that is fetched by one of the instructions being executed is captured by LSU as MFC and MFD records (described herein). IMT operand records (SRCOP/DESTOP) and the data records (MFC/MFD) can be parsed to determine address and data of the operands of the instruction, respectively. For example, MFC record has only part of operand address. The OPC count and the partial address in the MFC record are used to find corresponding SRCOP/DESTOP to get full operand address. In addition, in response to triggering the breakpoint, writing/reading predefined memory (645) is performed for capturing the contents of all the architected registers after breakpoint (similar to the initiation of the IMT). By using the LSU to read/write the contents of the architected registers, the technical solutions can generate write operand records and data records that can in turn be parsed to determine register types and contents by looking the operand address and data of the predefined memory in the MFC and MFD records. Because, the contents of the architected registers are written in a predefined manner, parsing the MFD record in the same predefined manner identifies which architected register contents are stored at which location in the MFD record that is read.
In one or more examples, in the IMT-extended mode, until the condition that initiates capturing the architected register contents the IMT capture continues to include the data that the instruction accesses from memory. For example, the opcode of the instruction may be used to determine if the instruction access data from the memory 115. For example, instructions opcode from a predetermined subset are identified as instructions that access memory contents. Alternatively, or in addition, the operands of the instructions are used to determine if the memory contents are being accessed. For example, if the operands include memory addresses, the instruction may be deemed to access memory contents. It should be noted that the above are a few examples, and that in other embodiments of the present invention, the processor 105 may determine that the instruction being traced accesses memory contents in a different manner. The operand data is captured by the IMT using the MFC and MFD records, and the addresses of the operands are captured using SRCOP and/or DESTOP records. The MFC record contains the information that is used to parse the operand values from the MFD record.
Alternatively, or in addition, the condition that initiates the architected register contents to be captured includes that a predetermined number of instructions have been executed since the most recent architected register content capture. For example, in order to allow multiple CAP testcases to be generated from the captured IMT trace, writing and reading architected registers is forced to occur every K number of instructions completed, K being configurable. For example, the initialization request includes a value to use for K. Thus, once a testcase needs to be stopped at a breakpoint, next testcase can start again at any point where IMT provides a snapshot of all architectural registers. The breakpoint in the CAP testcase can include an instruction of specific type. For example, the breakpoint can include a fetch from a time dependent store location, an IO instruction, an external interrupt, an instruction not providing enough information for testcase generation, among others and/or a combination thereof.
The processor 105 further checks if the IMT capture is complete, as shown at 650. For example, the IMT capture can complete in response to the currently executing program is complete, a specific IMT capture complete request is received, a manual interruption of the IMT capture, and a combination thereof among other operations to stop the IMT capture. If the IMT capture has not completed, the processor continues to monitor next instruction to capture IMT records depending on the IMT-mode. In the extended IMT-mode, the processor also monitors for an occurrence of the condition to capture architected register contents. Else, if the IMT capture is completed, the processor stops capturing the IMT until further initialization requests, as shown at 655.
In the example depicted that MFC record has 64 bits and includes the fields as depicted in
Further, the MFC record 700 includes an operand count field 725 that indicates with which operand in the instruction the first memory data is associated. For example, if the first memory data is associated with a first operand in the instruction, the operand count field 725 has a first value, such as 0, and instead, if the first memory data is associated with a second operand in the instruction, the operand count field 725 has a second value, such as 1. The MFC record 700 further contains a first memory data information fields 730 that include information about the first memory data such as alignment, length, among others. The MFC record 700 further contains a first address field 735 that includes the memory address of the first memory data. In one or more examples, the field 735 includes only a few predetermined bits of the memory address, such as the last 8 bits, last 9 bits. This address and OPC1 are used to determine/validate full operand address from operand records (DESTOP/SRCOP), which are separate records having full operand addresses.
It should be noted that the depicted MFC record 700 has information for two operands to work in case of an instruction having two fetch operands. If an instruction has only one operand, the MFC record 700 has only one valid operand information. For example, for a RISC processor, the MFC record 700 only has one operand information.
In this case, the MFC record 700 further includes similar fields corresponding to the second memory data. For example, the MFC record 700 includes a validity indicator field 720 indicating validity of the second operand, and an operand count field 745 that indicates with which operand in the instruction the second memory data is associated. For example, if the second memory data is associated with a first operand in the instruction, the operand count field 725 has a first value, such as 0, and instead, if the first memory data is associated with a second operand in the instruction, the operand count field 745 has a second value, such as 1. The MFC record 700 further contains a second memory data information fields 750 that include information about the first memory data such as alignment, length, among others. The MFC record 700 further contains a second address field 755 that includes the memory address of the second memory data. In one or more examples, the field 755 includes only a few predetermined bits of the memory address, such as the last 8 bits, last 9 bits.
If an operand fetches more than 8 bytes, multiple MFC records are written. For example, in z Systems® an operand can fetch up to 256 bytes, which requires 32 MFC/MFD records as depicted above. If an instruction fetches two operands, there can be 32 MFC records (covering both operands) followed by 64 MFD records.
In one or more examples, all MFC records for the same operand are written consecutively. How an MFD record is identified from an MFC record depends on the implementation. In one or more examples, all MFC records are written consecutively and followed by all MFD records and the MFD records are interleaved when MFC record has two valid operands. The total number of valid operand information should be the same as the number of MFD records. Once a corresponding MFD record is identified, the actual data in the MFD record is determined using alignment and data length information in the corresponding MFC record. Depending on the arrangement of the MFC and MFD records, parsing and determining the information can vary in other implementations.
Thus, the IMT data captured includes trace data related to a system event. In one or more examples, the processor 105 receives an instruction relating to the system event from a location in the processor 105, such as a TLB, a IFU, an execution unit, etc. Generating the IMT data further includes determining a minimum number of trace segment records required to record instruction information. The processor 105 creates a trace segment table including the number of trace segment records, the number of trace segment records including at least one instruction record. In one or more examples, the processor 105 further generates a sub-trace from the trace segment records, the sub-trace having a fewer number of data records than a trace generated for the instruction. Additional details of generating the IMT data is provided in U.S. Pat. No. 7,975,182, contents of which are incorporated herein.
Further, the technical solutions herein facilitate validating the trace segment table by generating the trace and a first instance of the trace segments via a controlled testing suite, generating a second instance of the trace segments from the trace, and comparing the first instance and the second instance.
For example, referring back to
The technical solutions further include a method of verifying memory data contents captured by the IMT capture techniques described herein.
In one or more examples, the pseudo-IMT 490 is generated using the extended-IMT mode. The core simulator is a model that simulates the processor 105 and/or hardware components being tested, for example, a VHDL simulated model. The IMT captured by the simulator is referred to as the pseudo IMT 490. Further, the method includes generating a new AVP file from the pseudo IMT 490 through the post processing program. The method further includes comparing the original and new AVP files to see any mismatch on register/memory contents. For example, for comparing the AVP files, both AVP files are executed on the core simulator and the responses from both executions are compared. The pre-existing AVP file and the new AVP file generated using the pseudo IMT 490 are executed in the core simulator in non-IMT mode to compare them. In one or more examples, a CMD file 510 is generated from the pseudo IMT 490 and run on IMT testing systems, such as proprietary internal systems or any other test suite to debug any problem that may not be debugged with the AVP comparison or core simulator.
Referring to
Referring to
Thus, the technical solutions herein facilitate a processor to improve capturing IMT. IMT is a hardware-generated trace containing detailed information about the instructions executed by a processor core, such as the z Systems® core. IMT is used to drive performance models or simulation models that help predict and verify the performance of future systems. IMT can provide trace for multiple tier and multiple partition benchmarks which cannot be simulated with an IMT testing system, such as proprietary internal system. By implementing the technical solutions described herein, the captured IMT is improved and provides register contents and referenced memory data which are required to drive sequence testcases.
In an ideal scenario, IMT capture is stopped at every break point and started again by capturing initial contents of architected registers. However, such an IMT capture is costly to implement because it requires hardware to monitor/decode instruction to identify potential instruction(s) causing breakpoint(s). The technical solutions described herein address such a technical problem by capturing the initial contents of architected registers on every K number of instructions. In this way, if a breakpoint is identified in the IMT during parsing the IMT, generating a testcase can be stopped and a next testcase can be started at a next point in the IMT that provides a snapshot of the architectural registers.
The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instruction by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments described herein.
Claims
1. A system comprising:
- a memory; and
- a processor coupled with the memory, the processor configured to:
- receive a request to initiate an in-memory trace (IMT) data capture, the IMT data being an instruction trace collected while instructions flow through an execution pipeline of the processor; and
- capture contents of architected registers of the processors in the IMT data by: storing the contents of architected registers to a predetermined memory location; and causing a load-store unit (LSU) to read contents of the predetermined memory location; and
- a simulated processor configured to execute the instruction traced by the processor using the IMT data by accessing the contents of architected registers from the IMT data.
2. The system of claim 1, wherein causing the LSU to read the contents of the predetermined memory location comprises: generating a memory fetch control record and a memory fetch data record in the captured IMT data.
3. The system of claim 1, wherein the contents of the architected registers are captured in response to a breakpoint.
4. The system of claim 1, wherein the contents of architected registers are captured in response to the IMT data capture being initialized in extended-IMT mode.
5. The system of claim 4, wherein the IMT data capture includes values of operands of the instructions.
6. The system of claim 5, wherein a value of an operand is captured using a memory fetch control record and a memory fetch data record, and an address of the operand is captured using a source operand record or a destination operand record.
7. The system of claim 1, the processor being a first processor, and the system further comprising:
- a second processor configured to execute the instruction traced by the first processor using the IMT data by accessing the contents of architected registers from the IMT data.
8. A computer program product for testing a processor, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processing circuit to cause the processing circuit to implement a method comprising:
- initiating an in-memory trace (IMT) data capture for a processor, the IMT data being an instruction trace collected while instructions flow through an execution pipeline of the processor; and
- capturing contents of architected registers of the processor in the IMT data capture by: storing the contents of architected registers to a predetermined memory location;
- causing a load-store unit (LSU) to read contents of the predetermined memory location; and
- executing the instruction traced using the IMT data by accessing the contents of architected registers from the IMT data.
9. The computer program product of claim 8, wherein causing the LSU to read the contents of the predetermined memory location comprises: generating a memory fetch control record and a memory fetch data record in the IMT data capture.
10. The computer program product of claim 8, wherein the contents of architected registers are captured after every predetermined number of instructions are executed by the processor.
11. The computer program product of claim 8, the processor being a first processor, and the method further comprising:
- executing, using a second processor, the instruction traced by the first processor using the IMT capture data by accessing the contents of architected registers from the IMT capture data.
12. An apparatus for testing a processor, the apparatus configured to:
- receive a request to initiate an in-memory trace (IMT) data capture for a processor, the IMT data being an instruction trace collected while instructions flow through an execution pipeline of the processor;
- capture contents of architected registers of the processor in the IMT data by: storing the contents of the architected registers to a predetermined memory location; and causing a load-store unit (LSU) to read contents of the predetermined memory location;
- generate a test sequence using the captured IMT data, the test sequence including the instruction and the contents of the architected registers from the captured IMT data; and
- execute the test sequence using a second processor.
| 5838692 | November 17, 1998 | Tobin |
| 6094729 | July 25, 2000 | Mann |
| 6173395 | January 9, 2001 | Wisor |
| 6530076 | March 4, 2003 | Ryan |
| 7383428 | June 3, 2008 | Bottemiller |
| 7987342 | July 26, 2011 | Thaik |
| 8527959 | September 3, 2013 | Chung et al. |
| 9124481 | September 1, 2015 | Mann et al. |
| 9372947 | June 21, 2016 | Elmufdi et al. |
| 20030135719 | July 17, 2003 | Dewitt, Jr. et al. |
| 20030154028 | August 14, 2003 | Swaine |
| 20040019886 | January 29, 2004 | Berent |
| 20040139305 | July 15, 2004 | Arimilli et al. |
| 20060184836 | August 17, 2006 | Al-Omari |
| 20070214341 | September 13, 2007 | Das |
| 20070234016 | October 4, 2007 | Davis et al. |
| 20080082801 | April 3, 2008 | Edgar |
| 20090024878 | January 22, 2009 | Al-Omari et al. |
| 20090249302 | October 1, 2009 | Xu |
| 20100287417 | November 11, 2010 | Moyer |
| 20130132699 | May 23, 2013 | Vaishampayan et al. |
| 20170052876 | February 23, 2017 | Svensson et al. |
| 102789401 | November 2018 | CN |
| 1039377 | September 2006 | EP |
- Jane H. Bartik et al.“Generating and Verifying Hardware Instruction Traces Including Memory Data Contents”, U.S. Appl. No. 15/817,622, filed Nov. 20, 2017.
- List of IBM Patents or Patent Applications Treated as Related; (Appendix P), Filed Nov. 20, 2017; 2 pages.
- International Search Report; International Application No. PCT/IB2018/05; Internation Filing Date: May 21, 2018; dated Sep. 19, 2018; 10 pages.
Type: Grant
Filed: May 23, 2017
Date of Patent: Jun 25, 2019
Patent Publication Number: 20180341480
Assignee: INTERNATIONAL BUSINESS MACHINES CORPORATION (Armonk, NY)
Inventors: Jane H. Bartik (Poughkeepsie, NY), Christian Jacobi (West Park, NY), David Lee (Poughkeepsie, NY), Jang-Soo Lee (Poughkeepsie, NY), Anthony Saporito (Highland, NY), Christian Zoellin (Weinstadt)
Primary Examiner: Eric Coleman
Application Number: 15/602,618
International Classification: G06F 9/30 (20180101); G06F 9/38 (20180101);
