text: fig1 is a block diagram schematically illustrating a test system ( also referred to herein as a software model ) used to replicate the function of an smp data processing apparatus , such an smp data processing apparatus having a plurality of processing units operable to share access to a memory system . as shown in fig1 , the test system includes first and second simulators 10 , 20 . the first simulator 10 includes a core simulator 30 for simulating the operations of the processor core of the processing unit simulated by the simulator 10 , a memory management unit ( mmu ) simulator 35 for simulating the operations of an mmu provided within the processing unit being simulated , and data cache 60 and instruction cache 65 simulators for simulating the operations of a data cache and instruction cache , respectively , of the processing unit being simulated . the second simulator 20 likewise includes a core simulator 70 , an mmu simulator 75 and data cache 85 and instruction cache 90 simulators . each of the simulators 10 , 20 are coupled via a bus 95 to memory 100 . it will be appreciated that in the context of the test system the element 95 is actually a simulation of the bus of the data processing apparatus being modelled by the test system , and likewise the element 100 is actually a simulation of the memory to be provided in such a data processing apparatus . however , for simplicity , these elements will be referred to herein as the bus 95 and the memory 100 . further , the test system includes a checker 105 which incorporates a master image 110 of the memory 100 , this - master image of memory also being referred to herein as master memory or a reference image of memory . it should be noted that the checker 105 and master memory 110 are provided solely in the test system , and do not have any equivalent in the data processing apparatus being modelled by the test system . each of the mmu simulators 35 , 75 have a similar structure , and in particular include translation lookaside buffers ( tlbs ) 55 , 80 . for simplicity in the figures , the detail of the mmu simulators 35 , 75 has only been shown in relation to the mmu simulator 35 of the first simulator 10 . when the core simulator 30 requires access to a data value , it will issue an access request . if the access request pertains to data to be processed by the core simulator 30 , then a data address ( da ) will be issued to the mmu simulator 35 . this data address will typically be in the form of a virtual address which will be translated into a physical address by the translation function 40 within the mmu simulator 35 . as will be appreciated by those skilled in the art , an mmu will normally perform further access control functions in addition to virtual to physical address translation , such as review of access permission rights , analysis of region attributes , etc . such functions will also be replicated by the mmu simulator 35 , but for simplicity the functionality used to perform those other access control functions is omitted from the figures . to enable the required access control procedures to be performed by the mmu simulator 35 , one or more page tables will be defined in memory 100 , each page table including a number of descriptors and each descriptor identifying , for a particular address range , associated access control information . if a particular descriptor needs to be accessed from memory 100 , then the translation function 40 can initiate the access by accessing the translation table base ( ttb ) 45 to identify a base address for the relevant page table , and then using that information , along with the data address provided by the core simulator 30 , to instruct the page table walk function 50 to output a page table address ( pta ) to the memory 100 in order to cause the required descriptor in the form of page table data ( ptd ) to be returned via the page table walk function 50 to the translation function 40 . as page table descriptors are retrieved , they are temporarily stored in the tlb 55 , so that if they are subsequently required again the translation function 40 can access that descriptor information without needing to again access the memory 100 . it will be appreciated that in some embodiments one page table walk may cause multiple memory accesses to be performed , for example when using two - level page tables . once the translation function 40 has performed the necessary virtual to physical address translation with respect to the relevant descriptor &# 39 ; s access control information , then it outputs a data physical address ( dpa ) to the data cache simulator 60 , which then uses that information to determine whether the data the subject of the access request is already stored in the data cache simulator 60 . if so , then the data value ( dd ) the subject of the access request can then be returned to the core simulator 30 in the event of a read access request , or written into the data cache simulator 60 in the event of a write access request . if the data value in question relates to a write back region of memory , then the data cache simulator 60 will not typically output the data value for storage in memory 100 as soon as that data value is written into the data cache 60 from the core simulator 30 , whereas if the data value relates to a write through region of memory , then the data cache simulator 60 will output that data value to memory 100 as soon as it is updated in the data cache simulator 60 . if a cache miss occurs in the data cache simulator 60 , then the data physical address will be propagated via the bus 95 to memory 100 , such that the data access is performed with respect to memory 100 . it should be noted that a write buffer simulator ( not shown in fig1 ) may be located between the data cache simulator 60 and the bus 95 to model any write buffer provided at the corresponding point in the data processing apparatus being modelled . the instruction cache simulator 65 works in a similar way to the data cache simulator 60 , but it should be noted that the instruction cache simulator 65 only responds to read requests . in particular , if a new instruction is created by the core simulator 30 , it will at that time be treated as data and routed via the data cache simulator 60 to memory 100 . when a read access request pertaining to an instruction is issued by the core simulator 30 , then an instruction address ( ia ) will be issued to the mmu simulator 35 , where the translation function 40 will then perform the required virtual to physical address translation using the earlier described techniques . this will result in the issuance of an instruction physical address ( ipa ) to the instruction cache simulator 65 . if a hit then occurs in the instruction cache simulator 65 , the instruction data ( id ) will be returned directly to the core simulator 30 from the instruction cache simulator 65 , whereas in the event of a cache miss , the instruction physical address ( ipa ) will be output on to the bus 95 to cause the instruction data to be retrieved from memory 100 into the instruction cache simulator 65 , from where it is then provided to the core simulator 30 . the second simulator 20 operates in an analogous manner to that described above in relation to the first simulator 10 . in fig1 , the data cache simulators and instruction cache simulators model physically addressed caches . however , in an alternative embodiment , such simulators may model virtually addressed caches , in which event the virtual address ( da or ia ) will be used to index the cache simulators and the physical address ( dpa or ipa ) will only be used in the event of a cache miss . in accordance with embodiments of the present invention , at initiation time , the master memory 110 is arranged to store a complete copy of the data stored in the memory 100 . then , each time a write access request is issued by the core simulators 30 , 70 of each simulator 10 , 20 , the data value the subject of that write access request is provided directly to the checker 105 where it is stored within the master memory 110 , thus ensuring that the master memory 110 maintains an up - to - date version of all data . the updated data values are only committed to master memory 110 once it has been determined that the write access request can proceed , as discussed earlier this determination typically being made by the respective mmu simulator 35 , 75 . by such an approach , it can be seen that the master memory 110 can be updated instantly on any write operation , bypassing write buffers , caches , etc that may be provided within the data processing apparatus , and hence modelled within the test system . by employing such a system , the checker 105 can then perform a check for each data access operation of an access request to ensure that data accessed from any temporary storage simulator in the test system when handling such a data access operation is up - to - date . as is apparent from the example of fig1 , data may be retrieved from the data cache simulator 60 , tlb 55 and instruction cache simulator 65 when performing various data access operations resulting from an access request issued by the core simulator 30 . similarly , considering the second simulator 20 , data may be accessed from the data cache simulator 85 , the tlb 80 , or the instruction cache simulator 90 when processing data access operations of an access request issued by the core simulator 70 . for each such data access operation , the data accessed can be checked by the checker 105 against the corresponding data found in the master memory 110 in order to determine whether there is a match . if there is a match , then this means that the data accessed from the temporary storage simulators is up - to - date . however , if there is any discrepancy , then this indicates that the data accessed from the relevant temporary storage simulator 60 , 55 , 65 , 85 , 80 , 90 is out - of - date , and accordingly a discrepancy log can be produced to flag that discrepancy to a user of the test system . this will be discussed further with reference to fig2 and 3 . as shown in fig2 , the checker 105 incorporates first and second checking routines 200 , 210 provided in respect of the first and second simulators 10 , 20 . each checking routine is arranged to receive from its associated simulator any virtual addresses , physical addresses , data values and ttb values produced within the associated simulator so that it can then perform any required checks against data stored in the master memory 110 . hence , by way of example , each checking routine can determine whether any data values ( id or dd values ) retrieved from temporary storage simulators match the corresponding values stored within the master memory 110 . further , each checking routine can use the virtual address and corresponding physical address produced within the simulators by their associated mmu simulators to determine whether the same correspondence between virtual and physical address would have been determined using the page table descriptor data ( ptd ) stored within the master memory 110 . the other access control information of the page table descriptor can also be checked against the corresponding data stored in the master memory 110 . in such checks , the ttb value is also used to ensure that the appropriate page table descriptor is referenced in the master memory 110 . wherever any discrepancy is determined to exist , an entry is made in a discrepancy log 220 , this discrepancy log being shown in more detail in fig3 . fig3 illustrates one example of the type of information that may be stored within each entry in the discrepancy log . in the example illustrated in fig3 , five pieces of information are stored in any entry , including the physical address 310 of the data for which a discrepancy was found . as discussed earlier , this data may be instruction data , data processed by a core simulator , or page table descriptor data used in performing access control functions . in addition to this address information 310 , the wrong data 320 is stored ( i . e . the data retrieved from the relevant temporary storage simulator ), along with an indication 330 of the origin of that wrong data , for example an indication as to which temporary storage simulator produced that wrong data . further , additional information is stored in the entry of the discrepancy logic identifying the right data 340 and an indication 350 of the origin of that right data , i . e . where the right data 340 in the master memory 110 was written from . hence , in an smp system , such an indication 350 may identify the processor that issued the right data . fig4 is a flow diagram illustrating in more detail the process performed by each mmu simulator 35 , 75 in accordance with one embodiment of the present invention , along with the associated checking process performed by the checker 105 . at step 400 , a virtual address ( da or ia ) is received , whereafter at step 405 the mmu simulator determines whether there is a hit in the tlb of that mmu simulator . if not , then a page table walk process is performed at step 410 to access the required page table descriptor data from memory 100 , whereafter that page table data is then written into the tlb at step 415 . thereafter , at step 420 the mmu generates a physical address and any other access attributes required in association with the access request , for example identifying whether the associated data value is cacheable , bufferable , etc . it will be noted that the process will proceed directly from step 405 to 420 in the event that a hit is determined in the tlb , since in that event the required page table descriptor data will already be stored within the mmu simulator . at step 425 , a page table walk process is performed in the master memory 110 by the checker 105 in order to identify the relevant page table descriptor data as stored in the master memory . thereafter , at step 430 , the checker will use that information accessed in the master memory in order to generate a comparison physical address and other access attributes , which at step 435 are then compared with the physical address and other access attributes produced by the relevant mmu simulator at step 420 , in order to determine whether there is a match . if there is a complete match between the physical address and other access attributes produced by the mmu simulator and the comparison physical address and other access attributes produced by the checker with reference to the master memory 110 , then the physical address and other access attributes produced by the mmu simulator are merely output at step 445 . however , if there is any discrepancy , then that discrepancy is logged at step 440 prior to the physical address and other access attributes generated by the mmu simulator being output at step 445 . fig5 is a flow diagram illustrating the process performed when reading a data value from either the data cache simulator or the instruction cache simulator of either the simulator 10 or the simulator 20 , along with the associated checking procedure performed by the checker 105 . at step 500 , an address is received by the cache simulator , in the fig1 embodiment this being a physical address . thereafter , it is determined at step 505 whether that address is found in the tag ram of the cache simulator ( i . e . that part of the cache simulator used to hold the addresses associated with each of the data entries in the cache simulator ) and if not this means that there is a cache miss . accordingly , in the event of a cache miss , the required data value is loaded from memory at step 510 , whereafter at step 515 that data value is written into the cache simulator . it will be appreciated by those skilled in the art that there are a variety of cache eviction policies that may be used in order to free up space in the cache simulator for the storage of any such data . following step 515 , or directly following step 505 in the event of a cache hit , the required data value is obtained from the data ram of the cache simulator at step 520 . at step 525 , the checker 105 is arranged to perform a lookup process in the master memory 110 in order to obtain a comparison data value found at the address received at step 500 . then , at step 530 , the data value read from the cache simulator is compared with the comparison data value , and if they match the data value produced by the cache simulator is output at step 540 . however , if they do not match , the discrepancy is logged at step 535 , whereafter the data value read from the cache simulator is output at step 540 . fig6 is a flow diagram illustrating the process performed when performing a write access request to the data cache simulator 60 , 85 of either simulator 10 , 20 . as mentioned previously , in the embodiment of fig1 the instruction cache simulators are not arranged to receive write access requests . at step 600 , the address and data value to be written are received by the data cache simulator , whereafter at step 605 a lookup procedure is performed in the tag ram of the cache simulator in order to determine whether the address is found in that tag ram . if not , then a cache miss has occurred and accordingly a line of data is loaded from memory , that line of data including data at the address the subject of the write access request . thereafter that line of data is written into the cache simulator at step 615 . following step 615 , or directly following step 605 in the event of a cache hit , the data value the subject of the write access request is updated in the cache simulator at step 620 . in addition , the checker 105 will include a monitoring function which , in response to the write access request , will also update at step 625 the data value in master memory 110 . this monitoring function can be considered to be incorporated as part of the first and second checking routines 200 , 210 of fig2 . it will be appreciated that when performing a write access request such as described with reference to fig6 , there is no need for any comparison to be performed with respect to master memory , since part of the writing process involves the update of the master memory . it should be noted that fig6 illustrates the process performed for an “ allocate on write ” cache . if the cache were instead arranged as an “ allocate on read ” cache , then in the event of a cache miss steps 610 and 615 would not be performed , and instead the updated data value would merely be output to memory at step 620 rather than being stored in the cache . from the above description of an embodiment of the present invention , it will be appreciated that the test system of embodiments of the present invention maintains a separate master image of physical memory which is maintained by the test model and in particular is updated instantly on any write operation , bypassing any write buffers , caches , etc that may be being modelled by the test system . whenever hits occur in cache simulators and tlb simulators , the master image is checked to verify that correct data is being returned . if there is a discrepancy , the model can alert the user , for example by creating an entry in a discrepancy log . this process is found to be extremely useful when developing and verifying certain pieces of software , for example operating system software , since an operating system must maintain the caches and tlbs , cleaning and / or invalidating entries when necessary . if the operating system is not performing these functions correctly , it can be difficult to track down the source of the resulting errors , but the test system of embodiments of the present invention significantly eases this task through the identification and logging of the sources of such errors as they occur . the above techniques may be used in test systems used to model a data processing apparatus having only a single processor . in addition , the same techniques can be used to test software intended for use in a data processing apparatus having multiple processors , for example in an smp system , where multiple cpus may have to co - operate to make sure all stale data is flushed from caches and tlbs . although a particular embodiment of the invention has been described herein , it will be apparent that the invention is not limited thereto , and that many modifications and additions may be made within the scope of the invention . for example , various combinations of the features of the following dependent claims could be made with the features of the independent claims without departing from the scope of the present invention .