Simulating program instruction execution and hardware device operation

[0001] 1. Field of the Invention

[0002] This invention relates to the field of data processing systems. More particularly, this invention relates to the simulation of systems including a processor core and a plurality of hardware devices.

[0003] 2. Description of the Prior Art

[0004] The ability to effectively and efficiently test and/or validate designs is becoming increasingly important. Typical data processing system designs are rapidly increasing in complexity and furthermore are including circuit blocks designed by a variety of different sources or companies. So called system-on-chip (SoC) designs that integrate a large number of functional elements on a single integrated circuit have strong advantages in terms of cost and performance, but require significant amounts of validation and testing before the designs can be reliably released for manufacture. This validation and testing requirement is becoming a bottleneck in getting new systems into the market place. Consequently, measures that can improve the efficiency and effectiveness of such validation and testing of designs are strongly advantageous.

[0005] There are currently 3 approaches that can be used to validate a SoC design:

[0006] (a) Build a software model of the design and run the same software when the hardware is complete. The problems here include that the hardware models are not fully represented in software in that there is no hardware feedback loop such that different hardware block models can interact fully.

[0007] (b) Build VHDL and/or Verilog (trickboxes) models to plug into the external interfaces of the SoC blocks to provide external stimulus to the SoC. This approach is commonly used but suffers from the problem that the code is not very re-usable, and a large amount of knowledge is required of the operation of each trickbox to create effective tests.

[0008] (c) Build models of each of the blocks (eVCs) in the SoC using an HVL (hardware verification language) such a Specman to replace existing hardware blocks in turn, such that the modelled blocks can provide stimulus into the system. Here a problem is that the integrity of the system is compromised as existing blocks need to be removed and re-inserted per test.

[0009] The copending U.S. patent application U.S. Ser. No. 09/994,023 filed on Nov. 27, 2001 with the same inventor and Assignee as the current application describes a mechanism for the coordinated validation of hardware devices. The disclosure of this earlier copending application is incorporated herein in its entirety by reference.

[0010] The copending U.S. patent application entitled Software and Hardware Simulation filed on Feb. 22, 2002 describes a mechanism for testing software drivers and their associated hardware. The disclosure of this earlier copending application is incorporated herein in its entirety by reference.

[0011] As well as simulating the behaviour of hardware devices, such as peripherals and interfaces, it is desirable to also be able to simulate and/or validate the behaviour of software executing on a processor core. In normal operation of the real system the program instructions executing on the processor core typically have control and authority over the system as a whole and direct its operation following the program instruction sequence. It is known to provide instruction set simulators which allow execution of program instructions by a processor core to be simulated, but it is currently not practical to bring such instruction execution simulation meaningfully together with hardware device simulation in an efficient manner. Whilst it may be possible to allow an instruction set simulation to steadily simulate execution of a stream of program instructions whilst a hardware simulation operates in parallel to simulate the action of hardware surrounding the processor core, the interaction between the hardware simulation and instruction execution simulation is substantially unmanaged and relies upon quasi-random occurrence of combinations of state in order to test the range of operational state of the system as a whole. This is highly time consuming and in many cases not practical due to the relatively slow speed at which hardware devices may be accurately and reliably simulated.

[0012] Viewed from one aspect the present invention provides apparatus for simulating data processing operations performed by a data processing apparatus, said data processing apparatus including a processor core operable to execute program instructions and a plurality of hardware devices coupled to said processor core, said apparatus comprising:

[0013] a hardware simulator operable to simulate said plurality of said hardware devices, said hardware simulator being responsive to one or more stimulus signals to generate one or more response signals simulating a response of one or more of said plurality of hardware devices to said one or more stimulus signals if applied to one or more of said plurality of hardware devices;

[0014] an instruction set simulator operable to simulate said processor core, said instruction set simulator being responsive to one or more stimulus signals to simulate execution of one or more program instructions by said processor core and to generate one or more response signals simulating a response of said processor core if said one or more program instructions were executed by said processor core;

[0015] a test scenario manager coupled to said hardware simulator and said instruction set simulator and operable to generate said stimulus signals supplied to said hardware simulator and said instruction set simulator such that said test scenario manager acts as a master to command simulation operations performed by said hardware simulator and said instruction set simulator in accordance with predetermined test scenario parameters.

[0016] The invention recognises that whilst in the real physical device the processor core may generally act as the master and command the rest of the system in its operation, during simulation the hardware simulator and the instruction set simulator may usefully both be treated as slaves to a test scenario manager. In this way, the test scenario manager may command the instruction set simulator to execute particular program instruction sequences or fragments which it is desired to simulate in combination with particular sets of stimulus signals being applied to the plurality of hardware devices that in the real system are coupled to the processor core. Surprisingly, this provides an effective and time efficient test and validation technique whereby the interaction of the processor core executing program instructions with the hardware devices associated with the core may be accurately simulated and the simulation directed at particular coordinated states of circumstances/state of the system. This arrangement reverses the normal situation in which the processor core is the master and instead makes the processor core a slave that is commanded by the test scenario manager.

[0017] In particularly preferred embodiments the test scenario parameters specify an interleaved sequence of stimuli to be applied to the hardware simulator and the instruction set simulator. The ability to interleave simulation signals in such a predetermined manner is highly effective in identifying and diagnosing potential problems with a system design.

[0018] It will be appreciated that the test scenario manager needs some mechanism by which to communicate with the instruction set simulator. In preferred embodiments of the invention a software signal interface controller to provide such a communication mechanism is embodied in the form of software executed by the instruction set simulator itself. This is an efficient and flexible way of achieving communication between the test scenario manager and the instruction set simulator.

[0019] A preferred mechanism for passing information between the test scenario manager and the instruction set simulator is via a shared memory. Such a mechanism is advantageously easy to provide and manage.

[0020] The instruction set simulator may utilise the shared memory in a variety of different ways. Preferred ways in which the instruction set simulator may read the shared memory include the shared memory being one or more of:

[0021] a debug interface register of said processor core simulated by said instruction set simulator;

[0022] a memory location accessible to said processor core simulated by said instruction set simulator;

[0023] an interrupt signal store operable to latch interrupt signals applied to said processor core simulated by said instruction set simulator; and

[0024] a command memory operable to store commands to said instruction set simulator.

[0025] Whilst it will be appreciated that the test scenario parameters could be essentially random parameters seeking to explore a wide span of system state of the system being validated, in preferred embodiments the test scenario parameters are a user specified subset of stimulus signals. In practice, a user of the validation system will often be able to identify ranges of stimulus signals which are likely to be of particular interest and towards which the validation and verification efforts of a product development cycle should be directed. In this context the user may specify the subset of stimulus signals to be applied in a particular set and vary this between sets to explore what are envisaged to be potentially problematic situations.

[0026] One particular type of problematic situation which the present technique is well suited to investigate are ones aimed at simulating time critical real time operational scenarios involving the interaction of the processor core operating under program instruction control with various hardware devices. An example of such a situation would be whether or not a FIFO was being emptied quickly enough by an associated hardware device whilst it was being filled at its maximum rate by software executing on the processing core.

[0027] The present technique is also well suited to allow a user to specify a subset of stimulus signals which can be used to establish performance limitations (e.g. speed, bandwidth etc) of a system under test prior to the real system becoming available.

[0028] The advantages of the coordinated approach to test and validation provided by the present technique and the ability to include within this the processor core executing program instructions are particular evident in circumstances such as when an interaction between a first hardware device and the processor core is being simulated and then an interruption to this interaction is simulated as being generated by a second hardware device. The ability of this system as a whole to cope with such real life potentially problematic situations is important to accurately test whilst at a simulation and validation stage.

[0029] The interaction between a processor core executing program instructions and an associated hardware device is particular important to test in the circumstance of the program instructions forming part of a software driver for the hardware device in question. This type of interaction is particular well suited to the command driven type testing provided by this technique in that the test scenario manager may trigger particular device driver software to be run applying predetermined stimuli to an associated hardware device and checking for an appropriate response.

[0030] The communication provided by use of the shared memory advantageously provides a degree of independence from the particular simulation environment used for the hardware simulation (e.g. the hardware could be simulated in Verilog, VHDL or a mixture thereof).

[0031] Viewed from another aspect the present invention provides a method of simulating data processing operations performed by a data processing apparatus, said data processing apparatus including a processor core operable to execute program instructions and a plurality of hardware devices coupled to said processor core, said method comprising the steps of:

[0032] in response to one or more stimulus signals, simulating said plurality of said hardware devices and generating one or more response signals simulating a response of one or more of said plurality of hardware devices to said one or more stimulus signals if applied to one or more of said plurality of hardware devices;

[0033] in response to one or more stimulus signals, simulating execution of one or more program instructions by said processor core and generating one or more response signals simulating a response of said processor core if said one or more program instructions were executed by said processor core;

[0034] using a test scenario manager to generate said stimulus signals such that said test scenario manager acts as a master to command simulation operations to simulate both said plurality of hardware devices and said processor core in accordance with predetermined test scenario parameters.

[0035] The above, and other objects, features and advantages of this invention will be apparent from the following detailed description of illustrative embodiments which is to be read in connection with the accompanying drawings.

[0036] FIG. 1 schematically illustrates a simulation environment including a plurality of hardware devices and an instruction set simulator;

[0037] FIG. 2 schematically illustrates a more complex simulation environment including a plurality of hardware devices and an instruction set simulator;

[0038] FIG. 3 schematically illustrates an instruction set simulator and its communication mechanism with a test scenario manager;

[0039] FIG. 4 schematically illustrates the control flow within the instruction set simulator.

[0040] FIG. 5 schematically illustrates the use of a shared memory for exchanging information between a test scenario manager and an instruction set simulator; and

[0041] FIG. 6 schematically illustrates the architecture of a general purpose computer that may be used to perform the simulation techniques discussed above.

[0042] FIG. 1 schematically illustrates a simulation system comprising a test scenario manager 2 utilising user specified predetermined test scenario parameter data 4 to apply stimulus signals to a plurality of hardware devices 6, 8, 10 via test interfaces 12, 14, 16. Responses of the hardware devices 6, 8, 10 are also returned and observed via the test interfaces 12, 14, 16.

[0043] An instruction set simulator 18 is provided to simulate the operation of a processor core acting under control of program instructions. The instruction set simulator also has a test interface 20 via which it can receive stimulus signals from the test scenario manager 2 and through which it may return results.

[0044] The test scenario manager 2 acts as a master device in this arrangement whereby it issues commands (stimulus signals) to the various hardware devices 6, 8, 10 or the instruction set simulator 18. Details of the messaging mechanisms used for communicating between the test scenario manager 2 and various hardware devices 6, 8, 10 may be found in the copending U.S. patent application Ser. No. 09/994,023 referred to above and incorporated herein by reference. The present technique extends this communication to also encompass the instruction set simulator 18 via its test interface 20. Thus, the instruction set simulator may be commanded by the test scenario manager 2 to execute particular program instructions or sequences of program instructions as required. The instruction set simulator will act to generate appropriate response signals that would be generated by the processor core executing such program instructions and the instruction set simulator can be responsive to the state of one or more of the other hardware devices 6, 8, 10 within the system being simulated.

[0045] FIG. 2 schematically illustrates a more complex system comprising a processor core and a plurality of hardware devices which it is desired to simulate. The simulation system still includes the test scenario manager 2 and the test parameters 4 together with the instruction set simulator 18. Further elements corresponding to hardware devices being simulated and the driving of external busses are also included. It will be seen that the test scenario manager 2 is connected so as to be able to command execution of program instructions by the instruction set simulator 18 as well as being able to apply stimulus signals to the various hardware device simulations and recover response data from both the hardware device simulations and the instruction set simulator. The various hardware device simulations and the instruction set simulator may also exchange data directly between one another as required in accordance with the system being simulated.

[0046] FIG. 3 schematically illustrates the instruction set simulator in more detail. The test scenario manager 2 communicates via its test interfaces with hardware devices 22 as well as with the instruction set simulator 18. A test interface 20/ is provided to identify messages issued by the test scenario manager 2 that are intended for the instruction set simulator 18 and make the appropriate writes to shared memory that can then be read by the instruction set simulator 18. This portion of the test interface 20/ is provided on the simulation environment side as software that is part of the test bench being used. Four different types of shared memory 24, 26, 28, 30 are illustrated in FIG. 3, although in practice these may be common physical memory locations and what differs is the way in which the test interface 20// within the instruction set simulator 18 chooses to interpret the data stored in that shared memory location. The test interface 20// is provided in the form of software which is executed by the instruction set simulator 18 itself and accordingly is loaded into the instruction set simulator as the simulation system is booted up. This test interface 20// together with a cut down version of an operating system that seeks to provide execution support for a plurality of different program instruction code fragments that may execute on the processor core simulation is also provided. If processing resources allow, then a full version of a real operating system could be used, but in practice it is found that a simpler cut down version is all that is required.

[0047] More particularly, FIG. 3 shows the proposed structure for the software XTI interface (external test interface). On the testbench side the XTSM 2 interfaces with an e language XVC (external verification controller) stub. This provides an XVC id which is then used to communicate through the software XTI to the nominated software XVC. The software XTI can be configured to use any one of the proposed communication technologies.

[0048] On the software side, the C half of the software XTI communicates with the software XVCs through a Task Manager.

[0049] The Task Manager's main responsibility is the scheduling of the software XVCs. This could be a simple pre-emptive scheduler with fixed time-slots and stacks for each of the XVCs. Interrupts and driver call-backs could be implemented as system events that can trigger other XVC actions.

[0050] XTI Command Interface

[0051] References 3 to 6 below give background information regarding each of the XTI communications channels that may be available to pass data from the hardware (RTL) environment into the software domain. Data is passed to and from the software domain using these channels. The data is formatted in such a way as to facilitate the following command set from and to the XTSM XTI interface. An XVC overview including the XTI can be found in ISB02-GENC-000365 (Reference 1):

[0052] This XTI interface holds state and control information about the external model, and is responsible for receiving and executing action requests from the XTSM. This interface component initiates and monitors the execution progress of the current action, and informs the external model scenario manager that it is ready for the next action. Command packets received from the XTSM would have a format similar to that shown below:

	1.Action Count
	1a.Action ID
	2a.Action Parameter Data Block	{close oversize brace}	Repeated for ea
	3a.Action Trigger Event ID

[0053] The action parameter data block above in field 2a. of the above will take the form of a linked list of structures, each structure containing a scalar value of relevance to its associated Action ID to be processed. Return status information from the XTI is encoded in a single status structure:

	1. Device ID
	2. Current Action ID
	3. Current Action Status
	4. Action Trigger Event ID
	5. Last Error code
	6. Message text

[0054] The XTI is also responsible for receiving action synchronisation events, and generating status events such that the status structure can be read from the XTSM. Some typical events passed in and out of the software domain XTI are listed in the table below:

Event	Direction	Comments
Trigger event ID fired	In	A system event has been detected,
		XTI to Check ID
Stop Run	In	Suspend action processing
Action Complete	Out	Current Action completed XTSM to
		read status
Action Sequence	Out	Current list of Actions completed
Complete		XTSM to read status
Device Error Detected	Out	I/O Error/Timeout detected XTSM to
		read status
Message Waiting	Out	Annotation text available XTSM to
		read status

[0055] References

[0056] 1 Andy Nightingale PrimeXsys Validation Architecture ISB02-GENC-000365

[0057] 2 Alistair Bruce, John Goodenough Re-useable Hardware/Software Co-verification of IP Blocks 14^th IEEE ASIC/SOC Conference, September 2001.

[0058] 3 RDI 1.5 Implementation: ARM document references for the remote debug interface (RDI) applications programming interface (API) are as follows:

[0059] RDI-0003-CUST-ESPC-B RDI 1.5

[0060] RDI-0005-CUST-ESPC-B RDI 1.5 terms and abbreviations

[0061] RDI-0008-CUST-ESPC-B RDI 1.5/1.0 Protocol converter

[0062] RDI-0013-CUST-ESPC-B RDI 1.5.1 changes from 1.5

[0063] RDI-0014-CUST-ESPC-A Remote_A RDI usage

[0064] RDI-0015-CUST-ESPC-A Multi-ICE RDI usage

[0065] RDI-0016-CUST-ESPC-A ARMulator RDI usage

[0066] RDI-0044-PRIV-ESPC-A01 RDI for NDI

[0067] RDI-0047-PRIV-ESPC-A02 RDI Self describing modules

[0068] The basic XTI data passing mechanism for RDI would be to monitor the XTSM/XTI interface for commands and generate a SWI on the core for external communications events. Data is passed back from the task manager via another SWI which is handled by the RDI/XTI interface and passed back to the XTSM/XTI. The SWI handlers would manage the data passing between interfaces.

[0069] 4 Tube/Internal Memory Implementation: As specified in ARM Document

[0070] ARM DDI 0243A-01 ARM ADK Technical Reference Manual

[0071] Section 5.4 describes the basic TUBE model. This implementation would require an enhancement such that the TUBE register could be written to via an external source and hence by the software task manager itself. Another variant on the TUBE that would not require modification would be the Internal Memory (IntMem) block documented in section 5.2 of ARM DDI 0243A-01. Both mechanisms would access as bidirectional data passing registers for XTI communication.

[0072] 5 VIC Implementation: The PrimeCell vectored interrupt controller (VIC) PL190 ARM document reference number is:

[0073] ARM DDI 0181C ARM PrimeCell PL190 Technical Reference Guide

[0074] Essentially command sequences using this implementation would be presented via the 32 external interrupt lines from the XTSM/XTI and would be read and translated via the task manager. Being unidirectional however, feedback would be required by some other mechanism such as reference 4 above.

[0075] 6 ARMulator plug-in implementation: ARM document references for the ARMulator applications programming interface (API) are as follows:

[0076] ARM DAI 0032E Application note 32: The ARMulator

[0077] appnote32_RevE.zip: Example ARMulator custom models

[0078] Using a similar mechanism to that of the RDI above, an ARMulator plug-in would be developed to interface to the XTSM/XTI and pass communications down through an ARMulator plug-in XTI to the software task manager. Communications would be driven by the use of SWI calls. The SWI handlers would manage the data passing between interfaces. The model used would be that of an operating system interface, documented in section 2.4 of the above application note document.

[0079] The above mentioned references are documents that are all publicly available, e.g. from ARM Limited, Cambridge, England.

[0080] FIG. 4 is a diagram showing the expanded software driver test coordinating process which waits for commands received via the system test control interface. On initialisation the action control loop 1 calls the scheduler implemented as a set of method calls in a CValTools to create a set of action tasks. The number and type of action tasks are defined by the user. Each action task has its own command loop and executes on a tick call basis. In one allocated tick, it must process any commands in its command queue before returning from the call back.

[0081] The tick for each task is driven by the CValTools class that operates under a timer interrupt. The CValTools also provides a set of methods such as:

[0082] Each of the above commands will have use of appropriate structures.

[0083] FIG. 5 is a schematic illustration of the way in which data may be passed from the test scenario manager 2 to the instruction set simulator 18 via a shared memory 32. On the test scenario manager side the verification code includes a plurality of client stubs which serve to write data values into the shared memory 32 as commanded by the test scenario manager 2. A polling loop operable on the software side for the instruction set simulator 18 polls the shared memory 32 and reads the data written therein passing this to the appropriate server stub code within the instruction set simulator and then onto the appropriate routine that will service the stimulus that has been specified by the data passed. The shared memory 32 may correspond to any of the elements 24, 26, 28 or 30 from FIG. 3.

[0084] FIG. 6 schematically illustrates a general purpose computer 200 of the type that may be used to implement the above described techniques. The general purpose computer 200 includes a central processing unit 202, a random access memory 204, a read only memory 206, a network interface card 208, a hard disk drive 210, a display driver 212 and monitor 214 and a user input/output circuit 216 with a keyboard 218 and mouse 220 all connected via a common bus 222. In operation the central processing unit 202 will execute computer program instructions that may be stored in one or more of the random access memory 204, the read only memory 206 and the hard disk drive 210 or dynamically downloaded via the network interface card 208. The results of the processing performed may be displayed to a user via the display driver 212 and the monitor 214. User inputs for controlling the operation of the general purpose computer 200 may be received via the user input output circuit 216 from the keyboard 218 or the mouse 220. It will be appreciated that the computer program could be written in a variety of different computer languages. The computer program may be stored and distributed on a recording medium or dynamically downloaded to the general purpose computer 200. When operating under control of an appropriate computer program, the general purpose computer 200 can perform the above described techniques and can be considered to form an apparatus for performing the above described technique. The architecture of the general purpose computer 200 could vary considerably and FIG. 6 is only one example.

[0085] Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims.