Data processing apparatus and data processing method

Abstract

This document relates to apparatus and methods. The apparatus comprises address translation circuitry for accessing translation data; transaction processing circuitry for receiving translation transactions and invalidation transactions, a translation transaction defining an input memory address to be translated to a corresponding output memory address, the circuitry being for controlling the address translation circuitry to provide the output memory address; an invalidation transaction defining at least a part of the translation data to be invalidated; transaction tracking circuitry for associating with each translation transaction and with each invalidation transaction one of a set of invalidation epochs; and invalidation circuitry for storing data defining a given invalidation transaction and for processing, for a translation transaction having the same invalidation epoch as the given invalidation transaction and being processed after the storing of the data, the translation transaction to indicate that the translation transaction is invalidated when the invalidation defined by the given invalidation transaction applies to a translation transaction; the invalidation circuitry being for forwarding at least an acknowledgement of the invalidation transaction for further processing in response to its storing of the data.

Description

Technical Field

[0001] This disclosure relates to data processing. Background Technology

[0002] Memory management allows for the construction of data processing systems with multiple virtual address maps, enabling each application running on the operating system to have its own virtual memory map. Each application resides in a separate address space within physical memory. The MMU uses translation tables to map the memory addresses used by applications—called virtual addresses—to physical addresses in memory. Translation tables can be, for example, tree-like hierarchical data structures created by software in memory.

[0003] MMU hardware typically traverses a translation table to perform virtual address translation. Traversing the translation table may involve performing several memory accesses to read the translation table.

[0004] The source of the transformation information or transformation table is the system that controls and monitors the transformation process. This system can typically be an operating system (OS) or a super-monitor. For various reasons, this monitoring system may occasionally need to invalidate at least a portion of the transformation information. Summary of the Invention

[0005] In one example arrangement, an apparatus is provided, comprising:

[0006] The address translation circuit is configured to access translation data that defines a set of memory address translations;

[0007] A transaction processing circuit is used to receive conversion transactions and invalid transactions. Each conversion transaction defines one or more input memory addresses in the input memory address space, which are to be converted into corresponding output memory addresses in the output memory address space. The transaction processing circuit is configured to control the address translation circuit to provide the output memory address as a conversion response.

[0008] Each invalid transaction is defined as being at least partially invalid to the transformed data;

[0009] Transaction tracking circuitry is used to associate one invalid epoch from a set of at least two invalid epochs with each transformation transaction and with each invalid transaction; and

[0010] An invalidation circuit is used to store data defining a given invalid transaction, and for translation transactions that have the same invalid epoch as the given invalid transaction and are processed by the address translation circuit after the invalidation circuit stores the data defining the given invalid transaction, these translation transactions are processed to indicate that the translation transaction is invalid when the invalidity defined by the given invalid transaction applies to a translation transaction;

[0011] The invalidation circuit is configured to, in response to the storage of the data by the invalidation circuit, at least forward the acknowledgment of the invalid transaction for further processing by other devices.

[0012] In another example arrangement, a method is provided that includes:

[0013] Access translation data that defines a set of memory address translations;

[0014] The system receives conversion transactions and invalid transactions. Each conversion transaction defines one or more input memory addresses in the input memory address space, which are to be converted into respective output memory addresses in the output memory address space. Each invalid transaction defines at least a portion of the converted data as invalid.

[0015] Provide the output memory address as the conversion response;

[0016] Associate one invalid epoch from a set of at least two invalid epochs with each transformation transaction and with each invalid transaction; and

[0017] The system stores data defining a given invalid transaction, and processes transformation transactions that have the same invalid epoch as the given invalid transaction and are processed after the storage of the data defining the given invalid transaction, indicating that the transformation transaction is invalid when the invalidity defined by the given invalid transaction applies to it; and

[0018] In response to an invalid circuit storing the data, at least an acknowledgment of the invalid transaction is forwarded for further processing.

[0019] In another example arrangement, a computer program is provided for controlling a host data processing device to provide an instruction execution environment, including:

[0020] The address translation circuit is configured to access translation data that defines a set of memory address translations;

[0021] A transaction processing circuit is used to receive conversion transactions and invalid transactions. Each conversion transaction defines one or more input memory addresses in the input memory address space, which are to be converted into respective output memory addresses in the output memory address space. The transaction processing circuit is configured to control the address translation circuit to provide output memory addresses as conversion responses.

[0022] Each invalid transaction is defined as being at least partially invalid to the transformed data;

[0023] Transaction tracking circuitry is used to associate one invalid epoch from a set of at least two invalid epochs with each transformation transaction and with each invalid transaction; and

[0024] An invalidation circuit is used to store data defining a given invalid transaction, and for translation transactions that have the same invalid epoch as the given invalid transaction and are processed by the address translation circuit after the invalidation circuit stores the data defining the given invalid transaction, these translation transactions are processed to indicate that the translation transaction is invalid when the invalidity defined by the given invalid transaction applies to a translation transaction;

[0025] The invalidation circuit is configured to, in response to the storage of the data by the invalidation circuit, at least forward an acknowledgment of the invalid transaction for further processing by other devices.

[0026] Further aspects and features of this technology are defined by the appended claims. Attached Figure Description

[0027] The present technology will be further described by way of example only with reference to embodiments of the present technology as shown in the accompanying drawings, in which:

[0028] Figure 1 The diagram illustrates the data processing system.

[0029] Figure 2 The diagram illustrates the memory management unit (MMU).

[0030] Figure 3 It is a schematic flowchart illustrating the method;

[0031] Figure 4 The illustration shows the assignment of epochs;

[0032] Figure 5 and Figure 6 The schematic diagram illustrates various aspects of the invalid processor;

[0033] Figures 7-10 It is a schematic flowchart illustrating each method; and

[0034] Figure 11 The illustration shows how the simulator is implemented. Detailed Implementation

[0035] Overview of the device

[0036] Figure 1The schematic illustration depicts a data processing apparatus 100, which includes a requesting device or requester 110, such as a processing element (PE), that generates memory access transactions as part of its operation. The memory access transaction is defined based on an input memory address in an input memory address space, such as a virtual memory address (VA) in a virtual memory address space (VAS). The use of VAs will be discussed further below.

[0037] Figure 1 Also shown is a memory management unit (MMU) 120, which translates one or more addresses associated with memory access transaction 105 from one or more input memory addresses into one or more output memory addresses in the output memory address space, such as one or more physical addresses (PAs) in the physical address space (PAS). The MMU forwards the translated transaction 115 to interconnect circuitry 130, which provides routing 117 for the transaction to reach completer device 140, such as main memory and / or cache memory, and for the transaction response 145 to ultimately return to requester device 110.

[0038] therefore, Figure 1 The basic view of the device is that an upstream device (e.g., requester 110) can access information at a downstream device (e.g., completer 140, optionally via an interconnect such as interconnect 130) via MMU 120 to translate between memory addresses in the address space used at the upstream device and those used in the address space at the downstream device. Access can be, for example, a read access, a write access, an access to detect or change the current consistency state of data stored at the downstream device, or other types of access.

[0039] MMU 120 includes a translation buffer unit (TBU) and a translation control unit (TCU) 126, the TBU may (as described below) include a translation lookaside buffer (TLB) 122.

[0040] As previously described, TBU 124 may utilize Translation Back Buffer (TLB) 122. As part of the processing of the memory access transaction as described above, the VA within the VAS referenced by the requester 110 needs to be translated into the PA in the PAS, based on which the system memory is electrically addressed (e.g., addressed by the completer circuit 140). This translation is performed by TBU 124, and even if TBU 124 is unable to service a particular translation, TBU 124 will obtain the necessary information from TCU 126, as described below.

[0041] The TCU 126 has an interface 132 to the interconnect 130, which the TCU 126 uses to perform activities such as page table walkthroughs and retrieving commands from memory-based queues or buffers (both discussed below).

[0042] Please note that although TLB 122 is in Figure 1 While TLB 122 is shown as part of TBU 124, it may be implemented as part of or associated with requester device 110, or in other embodiments, the functionality of the TLB may be provided at both requester device 110 and TBU 124. In some examples, requester device 110 may be associated with a so-called “micro” TLB local to that requester device, and the MMU may be associated with a “main” TLB.

[0043] MMU 120 can be a single-stage or multi-stage (e.g., two-stage) MMU, which may include, for example, a stage 1 MMU and a stage 2 MMU.

[0044] In a single-stage MMU, VA to PA translation is performed directly using translation information (such as so-called page tables) established and supervised by, for example, an operating system (OS). The OS can be executed by the same PE as the application (e.g., requester device 110) or by a different PE, but typically the OS executes with a higher privilege or security level than the application.

[0045] In the example two-stage MMU, the VA requested by the executing program or other system modules such as requester device 110 is translated into an intermediate physical address (IPA) by the stage 1 MMU. The IPA is then translated into a physical address (PA) by the stage 2 MMU. One reason for using multi-stage translation is for information processing security when individual "virtual machines" running on the same processor can use their own operating systems (OS). A specific OS handles and oversees the VA-to-IPA translation, while only a super-overseer (the software that oversees the execution of the virtual machine) can oversee the stage 2 (IPA-to-PA) translation. Typically, the super-overseer executes with a higher privilege or security level than the OS, which in turn executes with a higher privilege or security level than the application.

[0046] Invalid conversion information

[0047] Memory address translation (whether from VA to PA, or from VA to IPA and back to PA) is performed as described above based on the translation information. This information may be buffered in the TLB or may form part of the page table data (the page table data itself may be buffered, for example, in a so-called wander cache).

[0048] The source of the transformation information is the system that controls and monitors the transformation process, which (as described above) can typically be an operating system or a super-monitor. For various reasons, this monitoring system may occasionally need to invalidate at least a portion of the transformation information.

[0049] Invalidity can be defined, for example, for a portion of the VAS, IPA space, or PAS, and / or according to one or more sources of the memory access transaction (e.g., peripheral devices), and / or according to configuration details regarding MMU operation and / or according to other parameters that can be used to compare with the attributes of the memory access transaction.

[0050] One way to achieve this is by having the monitoring system issue invalid transactions. Such invalid transactions can be provided to the MMU via various routes, such as: (a) being sent to interconnect 130 as a so-called DVM (Distributed Virtual Memory Management) message by the CPU, processing element, or other requester, which interconnect 130 then forwards to the TCU; or (b) being read from a queue or buffer of commands that write invalid transactions into memory by the TCU via interface 132. Typically, once an invalid transaction is initiated by the TCU, it may need to be forwarded to other circuitry (e.g., TBU 124), but before that, the TCU needs to ensure that the invalid transaction is checked against each ongoing memory transaction to determine whether the memory access transaction itself should be marked as invalid. Invalid transactions are not allowed to "go beyond" memory access transactions and propagate to other parts of the system (other circuitry) unless it can be guaranteed that any memory address translations invalidated by the invalid transaction are not allowed to propagate unless they themselves are marked as invalid.

[0051] The previously proposed arrangement for achieving this level of guarantee involves the TCU checking invalid transactions against each ongoing transition before forwarding them (e.g., to the TBU). This check at the TCU can be expensive in terms of processing resources and / or latency. Specifically, performing the check in parallel at the TCU can be expensive in terms of processing resources because the number of transactions that need to be checked can be large. However, performing the check serially at the TCU can be expensive in terms of latency. Specifically, since the check at the TBU itself can take a long time, it is considered useful to forward invalid transactions to the TBU as early as possible.

[0052] Ineffective opportunity-seeking checks

[0053] The example implementation uses a so-called "sit-and-wait" technique to apply invalidation. In practice, this notation means that in response to an invalid transaction, the TCU can forward the invalid transaction once arrangements are in place that ensure that memory access transactions that should be invalidated cannot leave the TCU without being checked against invalidity and marked as invalid (if any). In other words, the forwarding of invalid transactions can be performed once such measures are in place, even if checks on each ongoing memory access transaction have not yet been performed at that stage.

[0054] In at least many cases, this avoids the need to "traverse" through ongoing transactions and thus potentially reduces the overhead of handling invalid transactions. Additionally, it potentially allows invalid transactions to be forwarded earlier compared to the arrangements previously discussed above.

[0055] These techniques are implemented by an invalidation processor (as an example of invalidation circuitry) in or associated with the TCU 126, as described below.

[0056] Conversion control unit

[0057] Figure 2 The schematic illustration shows at least a portion of the operation of the TCU 126. The arrangement shown pertains to a single-stage MMU, but similar techniques can be used for two-stage or other multi-stage MMUs, where each stage may follow the same arrangement (or alternatively, the ineffective techniques to be discussed may be applied to a subset of stages).

[0058] In such Figure 2 In the form shown, an incoming conversion transaction is received from the TBU at input 200 on the left side of the diagram and a transaction response is provided as output 210 (the response may be buffered by output buffer 212, which is shown in the schematic form) to be returned to the TBU on the right side of the diagram.

[0059] However, incoming conversion transactions and invalid transactions provided by control circuit 295 are interspersed. Control circuit 295 supervises... Figure 2 The operation of the entire arrangement shown is schematically illustrated by diagonal arrow 204, but in the case of invalid input transactions, control circuitry 295 generates these invalid transactions in response to the aforementioned DVM messages and / or memory reads from the instruction queue or buffer. The interleaving of conversion transactions and invalid transactions is implemented by the schematic multiplexer 202. The output 206 of multiplexer 202 thus provides an interleaved stream of conversion and invalid transactions, where there is no predetermined or other requirement regarding how much each type contributes to the stream, nor any requirement regarding when invalid transactions arrive relative to conversion transactions.

[0060] Invalid transactions are passed from schematic connection 208 to invalidation processor 298. Connection 208 allows: (a) passing invalid transactions to invalidation processor 298, (b) invalidation processor 298 to count and monitor transactions at output 206, and (c) providing invalid epochs to be associated with transactions at output 206, as described below.

[0061] Incoming conversion transactions are passed from multiplexer 202 to multiplexer 215 and form a cache lookup in roaming cache 217 (which operates under the control of cache controller 219). Conversion request attributes are also stored in memory 220, thereby associating the identifier with the roaming cache lookup and with the attributes stored in memory 220, so that when response 225 returns from the roaming cache, response 225 is recombined with the attributes stored in memory 220 based on the identifier and passed to cache response processor 230 for processing.

[0062] The walk-through cache stores information derived from previous page table walks. If the required information is stored in the walk-through cache 217, processing by the cache response processor 230 can result in a usable translation response being routed to output 210 via multiplexer 235. Another possibility, schematically represented by route 240, is that the processing triggers another cache lookup (e.g., to the next level page table). Another possibility, represented by route 245, is that the processing triggers the initiation of a so-called page tablewalk (PTW), causing multiplexer 250 to forward the output of the cache response processor as a PTW request 255.

[0063] The attributes of the PTW request are also stored in memory 260 in association with an identifier, so that when the PTW response 265 is received, the PTW response 265 is recombined with its attributes stored in the wander cache 217 according to the identifier and processed by the PTW response processor 270. The result of this processing may lead to a conversion response as represented by route 275, another PTW request as represented by route 280, or actually another cache lookup as represented by route 285.

[0064] These aspects of the MMU's operation, as well as other aspects to be discussed below, are under the overall control of the control circuit 295.

[0065] The invalidation processor 298 is associated with the following four components: an input 200 that provides incoming transactions, a buffered response processor, a PTW response processor, and an output 210 that provides a transition response. Various aspects of the operation of the invalidation processor 298 will be further discussed below.

[0066] Assignment of invalid eras

[0067] Figure 3 This is a schematic flowchart illustrating one aspect of the operation of the invalidation processor 298. This aspect involves the assignment of a so-called invalidation epoch.

[0068] As background, in Figure 2The incoming transactions received at the input of the multiplexer 215 may include: (i) memory access transactions requiring memory address translation, or (ii) invalid transactions. The invalidation processor 298 assigns an "invalid epoch" to each such transaction. The epoch may be a numerical identifier that identifies a group of subsequently received transactions, at least upon first assignment, based on the order in which the transaction is received relative to other transactions.

[0069] In some examples, an epoch can be part of an ordered set or sequence of epochs, such that the epoch to be assigned to an incoming transaction can be "incremented" (moved to the next in the ordered set or sequence, even if this is not represented by numerical "increment" or by adding one to the epoch identifier). In some examples, the ordered set or sequence can be a cyclic ordered set or sequence, such that the sequence "wraps around" and returns to the initial epoch when an increment is performed from the last epoch in the sequence. In some examples, the number of epochs provided in the ordered set is at least twice the number of epochs that can potentially be "alive" or in use at any given time. More generally, the transaction tracking circuit is configured to associate the current invalid epoch with each received transition transaction and with each received invalid transaction; and the transaction tracking circuit is configured to change the current invalid epoch to another invalid epoch in the set of invalid epochs in response to the association of the current invalid epoch with a received invalid transaction.

[0070] However, the basic requirement is simply that a set of transactions that need (or at least might need) be checked against invalidity can be associated with that invalidity. Therefore, the identifiers do not need to be sequential or cyclical; these characteristics merely make checking multiple invalidities potentially simpler and more straightforward, as they provide an implicit or explicit association with the next invalidity to be checked using the techniques discussed below. However, in other examples, any identifier, even a random or pseudo-random number, can be assigned as an invalid epoch, as long as it is unique relative to any other invalid epoch currently in use within the system. A list can be maintained globally or for each transaction in these invalid epochs that need or might need to be checked against, with entries removed from the list once a specific check is performed.

[0071] Each epoch may have an associated counter that maintains a count of currently unchecked memory access transactions associated with that epoch.

[0072] refer to Figure 3In step 300, the invalidation processor initializer initializes the so-called incoming epoch and its associated counter (e.g., by setting the counter to zero). This incoming epoch is assigned to each incoming transaction until the incoming transaction includes the next received invalidation transaction. For each transformation transaction assigned this invalidation epoch, the counter is incremented. In some examples, the counter is not incremented for transactions that do not require invalidation checks. Examples here may include transactions that have already been marked as invalid by upstream processing, transactions that do not involve cached transformation information at the TBU, or any category of transactions that are architecturally not allowed to be invalidated.

[0073] Therefore, refer to Figure 3 The next transaction is received in step 310 and assigned to the epoch in step 320.

[0074] If, in step 330, the received transaction is actually invalid, control is passed to step 340, where the incoming epoch is incremented or otherwise changed to a new incoming epoch and the counter associated with the new incoming epoch is initialized in step 350, and then control returns to step 310.

[0075] On the other hand, if the received transaction is detected as not being an invalid transaction, the counter associated with the current incoming epoch is incremented in step 360 or otherwise changed and control returns to step 310.

[0076] The purpose of this arrangement is to associate each invalid transaction with a set of transactions that preceded it and a count of how many such transactions there are.

[0077] As mentioned above, the increment of the incoming epoch can be the next epoch in an ordered sequence of invalid epochs (e.g., a cyclic ordered sequence), but as previously stated, the sequence does not actually need to be ordered or cyclic.

[0078] Figure 4 The example series of transactions is illustrated using individual rectangles 400. Figure 3 The process shown, in which the earlier received transaction is in Figure 4 The right side is drawn with transactions received later. Figure 4 The left side is drawn. Epochs (in sequential order) are represented in this example as Epochs A, B, C...

[0079] Assume the incoming epoch is initially initialized as epoch "A" and three transactions are received before invalid transaction 410. Each of these three received transactions 420 is associated with the incoming epoch A, just like invalid transaction 410. A counter is incremented with each non-invalid transaction, and the count values ​​1, 2, and 3 are shown above each corresponding transaction. Therefore, in the final application to epoch A... Figure 3 At step 360, the counter for epoch A reaches value 3.

[0080] In response to invalid transaction 410, the incoming epoch is incremented to epoch "B" in step 340, and the counter associated with epoch B is initialized. Then, as transactions 430 are received, they are associated with the incoming epoch B, and the counter is incremented by 1, 2, and so on. The counter for epoch B reaches the value 2. The next invalid transaction 440 is also associated with epoch B, and the incoming epoch is subsequently incremented to the next epoch "C" in the ordered sequence, and the counter associated with epoch C is reset to 0. Subsequent transactions 450 are associated with invalid epoch C, and the counter is incremented with each transaction.

[0081] The above Figure 3 and Figure 4 This pertains to the allocation of invalid epochs by invalidation processor 298. Further aspects of the operation of invalidation processor 298 concerning invalidation spurious applications will now be described.

[0082] Therefore, the invalidation processor 298 here acts as a transaction tracking circuit, which is configured to associate the current invalid epoch with each received transition transaction and with each received invalid transaction; and in response to the association of the current invalid epoch with the received invalid transaction, to change the current epoch to the next epoch in the ordered sequence of invalid epochs.

[0083] Note that a given transaction is within the range of all invalid epochs that arrive after it. Thus, for example, each of transactions 420 is initially associated with invalid epoch A, but once they have been checked against invalid epoch 410, they are required to be checked against invalid epoch B, and so on. This will be discussed further below regarding the incrementing and decrementing of the counter.

[0084] Further operations of the invalid processor

[0085] As an overview Figure 5 The schematic illustration shows one aspect of the operation of the invalid processor, as it has multiple so-called "slots" 500, 510. Note that in Figure 5 The diagram illustrates two such slots, but different numbers of slots may be available.

[0086] Each slot provides a representation of the processing circuitry to apply individual invalidation based on spurious events.

[0087] Invalid transactions 520 are provided to one of the slots (500), and depending on the characteristics of the operation discussed below, invalid transactions previously stored in slot 500 may be provided to slot 510. Each slot is associated with comparison circuitry and other circuitry to enable the detection of transaction attributes and the writing of invalid flags, tags, or other data associated with these transactions.

[0088] Figure 6 The schematic diagram illustrates the relationship with Figure 5 Example layout related to one of slots 500 and 510. Multiple such slots (e.g., more than two) can be provided because the additional processing overhead associated with each additional slot is relatively low.

[0089] Invalid epoch storage device 600 stores the invalid epoch currently being processed by this slot. Counter 610 is initialized to... Figure 3 The count generated in step 360 is, in other words, initialized to the value of the counter when an invalid transaction that resets the count and increments the incoming epoch is received. Therefore, counter 610 is initialized to the total number of previously received transactions to which the invalid epoch can be applied.

[0090] While still providing the aforementioned guarantees, transaction checks can be performed at a relatively limited number of locations (relative to the MMU circuitry). For this circuitry, these locations may be, for example, locations where architecturally specified behavior can be observed, such as at the outputs of the following (generally shown as output 630): buffer 212, cache response processor 230, and PTW response processor 270. The use of "architecturally specified" locations indicates where transactions within the circuitry can be observed (this is the significance of architectural specification). This feature is potentially important because it has the effect that invalidation processor 298 can interact with transactions at these locations without necessarily requiring additional memory read or write operations or additional latency. This, in turn, can mean that the performance impact (or cost) on transaction processing operations is very low or zero.

[0091] Detector 620 detects the attributes of a transaction at output 630. Invalidity detection circuitry 640 is arranged to selectively associate an invalidity flag 650 with the transaction, depending on whether an invalidity (or whatever parameter associated with invalidity as described above) is detected applied to the transaction at output 630. As described below, the checks (a) are performed at the output of buffer 212, and also (b) at the outputs of cache response processor 230 and PTW response processor 270.

[0092] Once a transaction has been checked, regardless of whether an invalidation flag has been applied, the following two things are performed: (a) the counter associated with the invalid epoch is decremented to indicate that one less transaction remains to be checked in that invalid epoch; and (b) the invalid epoch associated with the newly checked transaction is changed to a replacement epoch. This replacement epoch can be an invalid epoch in an ordered sequence that is no earlier than the epoch just checked (or, for unordered epochs, an invalid epoch assigned no earlier than the epoch just checked), for which the invalidation circuit currently does not store data defining the associated invalid transaction. Therefore, for example, in the case of a two-slot invalidation processor, the check on a transaction causes its invalid epoch to be changed to the next epoch later than both of the two slots, or in other words, to an invalid epoch for which the invalidation processor currently does not store data defining the associated invalid transaction. More generally, the replacement epoch can be an epoch associated with the current epoch, which, for those received transactions, is no earlier than the invalid epoch associated with the given invalid transaction.

[0093] Regarding the general representation of output 630, this arrangement provides an example where the address translation circuitry includes one or more (or two or more in this example) successive processing sections (e.g., 230, 270); and the invalidation processor is configured to process translation transactions in response to each of the one or more successive processing sections, for example, where the invalidation circuitry is configured to process translation transactions in response to each of the one or more successive processing sections outputting a translation transaction.

[0094] The wander controller 660, in the context discussed below, is configured to traverse each ongoing transaction being processed by the MMU (or at least by the cached response processor and the PTW response processor) and detect whether any of them should be invalidated. The operation of the wander controller 660 and the context in which its operation is initiated will be further discussed below.

[0095] Figure 6 The arrangement is under the control of the control circuit 670.

[0096] Therefore, operate as discussed above. Figure 1 , Figure 5 and Figure 6 The device provides an example of a device comprising:

[0097] Address translation circuit 120 is configured to access translation data that defines a set of memory address translations;

[0098] A transaction processing circuit (implemented as 120, 215) is used to receive conversion transactions and invalid transactions. Each conversion transaction defines one or more input memory addresses in the input memory address space, which are to be converted into corresponding output memory addresses in the output memory address space. The transaction processing circuit is configured to control the address translation circuit to provide the output memory address as a conversion response.

[0099] Each invalid transaction is defined as being at least partially invalid to the transformed data;

[0100] Transaction tracking circuitry is used to associate one invalid epoch from a set of at least two invalid epochs with each transformation transaction and with each invalid transaction; and

[0101] An invalidation circuit is used to store data defining a given invalid transaction, and for translation transactions that have the same invalid epoch as the given invalid transaction and are processed by the address translation circuit after the invalidation circuit stores the data defining the given invalid transaction, these translation transactions are processed to indicate that the translation transaction is invalid when the invalidity defined by the given invalid transaction applies to a translation transaction;

[0102] The invalidation circuit is configured to: in response to the storage of the data by the invalidation circuit, at least forward an acknowledgment of the invalid transaction for further processing by other devices.

[0103] Output buffer check

[0104] Checking transactions at the output of the cached response processor and the PTW response processor may not be sufficient to provide the aforementioned guarantees in some cases. To enable the forwarding of invalid transactions and ensure that this guarantee applies, in some examples, it is also appropriate to confirm that transactions that at least need to be checked against invalidity are not currently being buffered for output. This can also be achieved by detector 620 according to the following... Figure 7 The technology is used to execute it.

[0105] This provides an example in which the MMU includes one or more instances of output buffer circuitry 212 to store translation transactions processed by the address translation circuitry; wherein the invalidation processor is configured to detect, before the invalidation circuitry forwards at least an acknowledgment of the invalid transaction, that a translation transaction with the same invalid epoch as the given invalid transaction does not exist in the output buffer circuitry.

[0106] Please note that when a transaction leaves the TCU at output 210, the counter for all invalid epochs that still include the transaction or are still potentially associated with it is decremented—this includes invalid epochs that caused the scramble invalidation, invalid epochs waiting for slots, and “incoming” epochs that are not yet associated with invalid transactions.

[0107] Initiation of a wait-and-see approach that fails

[0108] Figure 7 This is a schematic flowchart illustrating the operation for the next invalid transaction to be processed.

[0109] In response to the next invalid transaction 700—which may be saved in memory 521 associated with the invalidation circuit (before these steps) and used to store a queue of one or more invalid transactions to be processed by the invalidation circuit—an attempt is made in step 720 to create an invalid slot for the invalid transaction, that is, as described above, the invalid transaction is stored in an empty slot in the invalidation processor 298.

[0110] When this succeeds (detected at step 730), control is passed to step 710, where it is checked that no transaction remains in output buffer(s) 212 for the invalidation to be applied. This is done by detector 620 checking that any transaction being output at output 210 has an invalidation epoch later than the current epoch being checked (or detector 620 waiting for such a case). When step 710 is complete, MMU 120 is in a state where it is certain that the transaction for which the invalidation should be applied will not leave the MMU without being invalidated. Thus, although invalidation is not necessarily completed at this stage, a so-called lazy or wait-and-see detection and invalidation system has been established to the extent that no transaction can leave the MMU without being properly processed. Therefore, at this stage, the invalidation can be forwarded to other circuitry, such as TBU, for processing in step 740.

[0111] However, if the result at step 730 is negative because the invalidation processor 298 has no free slots available, control is passed to step 760, where a so-called walk is performed to free up the slots. This involves the walk controller 660 sequentially checking each ongoing transaction at the cache response processor and the PTW response processor and selectively applying invalidation to that transaction. Each time, the count associated with the invalidation is decremented, and when it reaches 0, the invalidation currently occupying the slot can be retired and the slot is freed up for a new transaction. In other words, the invalidation processor is configured to retire the invalid transaction in response to a count value of the invalidation epoch associated with the invalidation transaction indicating that there are no remaining transition transactions associated with that invalidation epoch that have not yet been processed by the invalidation circuitry.

[0112] Step 760 provides an example of such an operation, wherein the invalidation processor is configured to selectively complete the processing of invalid transactions for which the invalidation circuit currently stores data, so as to allow the invalidation circuit to accept the next invalid transaction from the queue by detecting each translation transaction currently being processed by the address translation circuit when the count value indicates that it is greater than zero, and decrementing the count value and selectively applying invalidation to the translation transaction when the currently ongoing translation transaction has the same invalidation epoch as the invalid transaction to be completed.

[0113] Step 770 is repeated as necessary (and when detected at step 770) until a free slot becomes available.

[0114] Please note that when an invalid transaction is waiting for an available slot, it is not checked against the transaction, but its counter can be changed while it is waiting in the queue.

[0115] Figure 8 The schematic diagram illustrates various aspects of step 710, for example, for output 210.

[0116] In step 800, the invalidation processor 298 detects an invalid epoch of the current transaction at output 210. If, in step 810, this is a later epoch than the invalid epoch currently being considered, then step 710 is considered to have completed in step 820, because there are unlikely to be any related transactions still stored in the output buffer, etc., that need to be checked against the current invalidity. However, if not, control returns to step 800.

[0117] Figure 9 Schematic representation Figure 6 The operation of the apparatus relates to the output of cache response processor 230 and / or PTW response processor 270. Note that these steps may be performed in parallel for each slot of the invalid processor or otherwise.

[0118] This output is detected at step 900 and checked at step 910 to determine if it has the same invalid epoch as the current invalid epoch stored in storage device 600. If the answer is yes, control is passed to step 920. If no, control returns to step 900 for the next transaction to be checked at that output.

[0119] In other words, the invalidation processor is configured to store data defining two or more invalid transactions and process transformation transactions that have the same invalid epoch as any of the two or more invalid transactions.

[0120] Step 920 involves decrementing the counter used for the invalid epoch, and then step 930 checks whether invalidity applies to the transaction. If the answer is yes, the transaction is marked as invalid in step 940. The negative result of step 930 or the output of step 940 passes control to step 950, where the invalid epoch of the transaction is changed to the oldest currently unchecked invalid epoch, as described above.

[0121] Please note that for step 920, in the case of an invalid processor with multiple slots (like... Figure 5 As in the example, transactions are processed in parallel against multiple potential invalid epochs. The counter for each of these checked invalid epochs is thus decremented and the transaction leaves each of these invalid epochs. At step 960, if the counter associated with the current invalid epoch has reached 0, the invalidity is deactivated at step 970, and at step 980, the associated slot becomes available for reassignment to another invalidity. If the result at step 960 is negative, control is passed back to step 900 to receive the next output from the associated circuitry.

[0122] Summary of methods

[0123] Figure 10 This is a schematic flowchart illustrating a method, which includes:

[0124] (In step 1000) Access translation data that defines a set of memory address translations;

[0125] (In step 1010) Receive conversion transactions and receive invalid transactions, each conversion transaction defining one or more input memory addresses in the input memory address space, which are to be converted into corresponding output memory addresses in the output memory address space, wherein each invalid transaction defines at least a portion of the converted data as invalid;

[0126] (In step 1020) The output memory address is provided as the conversion response;

[0127] (In step 1030) Associate one invalid epoch from a set of at least two invalid epochs with each transformation transaction and with each invalid transaction; and

[0128] (In step 1040) Store the data defining a given invalid transaction, and for transformation transactions having the same invalid epoch as the given invalid transaction and processed after the storage of the data defining the given invalid transaction, process these transformation transactions to indicate that the transformation transaction is invalid when the invalidity defined by the given invalid transaction applies to it; and

[0129] (In step 1050) In response to the invalid circuit's storage of the data, at least an acknowledgment of the invalid transaction is forwarded for further processing.

[0130] Emulator Implementation

[0131] Figure 11 The illustrations depict various emulator implementations that can be used. While the previously described embodiments implement the invention with respect to means and methods for operating specific processing hardware supporting the technology of interest, an instruction execution environment, implemented using a computer program, can also be provided according to the embodiments described herein. Such a computer program is often referred to as an emulator because it provides a software-based implementation of the hardware architecture. Variations of emulator computer programs include simulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, the emulator implementation can run on a host processor 1130, which optionally runs a host operating system 1120 supporting the emulator program 1110. In some arrangements, there can be multiple layers of emulation between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide emulator implementations that execute at a reasonable speed, but this approach may be justified in certain situations, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, simulator implementations can provide an instruction execution environment with additional functionality not supported by the host processor hardware, or an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques,” Robert Bedichek, Winter 1990 USENIX Conference, pp. 53–63.

[0132] With respect to embodiments previously described with reference to specific hardware configurations or features, equivalent functionality may be provided by appropriate software configurations or features in simulated embodiments. For example, specific circuitry may be implemented as computer program logic in a simulated embodiment. Similarly, memory hardware, such as registers or caches, may be implemented as software data structures in a simulated embodiment. In some simulated embodiments, one or more of the hardware elements mentioned in the previously described embodiments are present on the host hardware (e.g., host processor 1130), and the host hardware may be utilized where appropriate in the arrangement.

[0133] Emulator program 1110 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to target code 1100 (which may include applications, operating systems, and super-supervisors), which may be the same as the interface of the hardware architecture modeled by emulator program 1110. Thus, the program instructions of target code 1100, including the features described above, can be executed from within the instruction execution environment using emulator program 1110, enabling host computer 1130, which does not actually possess the hardware features of the devices discussed above, to simulate these features.

[0134] Figure 11 The arrangement thus provides an example of a computer program for controlling a host data processing device to provide an instruction execution environment, including:

[0135] The address translation circuit is configured to access translation data that defines a set of memory address translations;

[0136] A transaction processing circuit is used to receive conversion transactions and invalid transactions. Each conversion transaction defines one or more input memory addresses in the input memory address space, which are to be converted into respective output memory addresses in the output memory address space. The transaction processing circuit is configured to control the address translation circuit to provide output memory addresses as conversion responses.

[0137] Each invalid transaction is defined as being at least partially invalid to the transformed data;

[0138] A transaction tracking circuit is used to associate one invalid epoch from a set of at least two invalid epochs with each transition transaction and with each invalid transaction; and

[0139] An invalidation circuit is used to store data defining a given invalid transaction, and to process translation transactions that have the same invalid epoch as the given invalid transaction and are processed by the address translation circuit after the invalidation circuit stores the data defining the given invalid transaction, to indicate that the translation transaction is invalid when the invalidity defined by the given invalid transaction applies to a translation transaction;

[0140] The invalidation circuit is configured to: in response to the storage of the data by the invalidation circuit, at least forward an acknowledgment of the invalid transaction for further processing by other devices.

[0141] In this application, the term "configured as" is used to mean that the elements of the device are configured to perform defined operations. In this context, "configuration" refers to the arrangement or interconnection of hardware or software. For example, the device may have dedicated hardware that provides defined operations, or a processor or other processing device may be programmed to perform that function. In this case, the software or program instructions used to perform that function, and the medium used to provide (e.g., store) such software or program instructions (e.g., a non-transitory machine-readable medium), are considered to represent embodiments of this disclosure. "Configured as" does not mean that the elements of the device need to be changed in any way in order to provide the defined operations.

[0142] While illustrative embodiments of the present technology have been described in detail herein with reference to the accompanying drawings, it is to be understood that the present technology is not limited to these specific embodiments, and various changes, additions, and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the present technology as defined by the appended claims. For example, features of the dependent claims may be combined with features of the independent claims in various ways without departing from the scope of the present technology.

Claims

1. A data processing apparatus, comprising: The address translation circuit is configured to access translation data that defines a set of memory address translations; A transaction processing circuit is used to receive conversion transactions and invalid transactions. Each conversion transaction defines one or more input memory addresses in the input memory address space, which are to be converted into corresponding output memory addresses in the output memory address space. The transaction processing circuit is configured to control the address translation circuit to provide the output memory address as a conversion response. Each invalid transaction is defined as being at least partially invalid to the transformed data; A transaction tracking circuit is used to associate one invalid epoch from a set of at least two invalid epochs with each transformation transaction and with each invalid transaction. as well as An invalidation circuit is used to store data defining a given invalid transaction, and for translation transactions that have the same invalid epoch as the given invalid transaction and are processed by the address translation circuit after the invalidation circuit stores the data defining the given invalid transaction, these translation transactions are processed to indicate that the translation transaction is invalid when the invalidity defined by the given invalid transaction applies to a translation transaction; The invalidation circuit is configured to: in response to the storage of the data by the invalidation circuit, at least forward an acknowledgment of the invalid transaction for further processing by other devices.

2. The apparatus of claim 1, wherein: The transaction tracking circuit is configured to associate the current invalid epoch with each received transition transaction and with each received invalid transaction; and The transaction tracking circuit is configured to change the current invalid epoch to another epoch in a set of invalid epochs in response to the association between the current invalid epoch and a received invalid transaction.

3. The apparatus of claim 2, wherein: A set of at least two invalid epochs consists of an ordered sequence of invalid epochs; and The transaction tracking circuit is configured to, in response to the association between the current invalid epoch and a received invalid transaction, change the current invalid epoch to the next epoch in an ordered sequence of invalid epochs.

4. The apparatus of claim 3, wherein the ordered sequence of epochs is a cyclic ordered sequence of epochs.

5. The apparatus of claim 1, wherein: The invalidation circuit is configured to generate a count value indicating the number of transition transactions associated with each invalidation epoch; and The invalidation circuit is configured to decrement the count value in response to the address translation circuit's processing of a translation transaction having the same invalid epoch as the given invalid transaction.

6. The apparatus of claim 5, wherein: The invalidation circuit is configured to terminate the invalid transaction in response to a count value of the invalid epoch associated with the invalid transaction indicating that there are no remaining conversion transactions associated with the invalid epoch that have not yet been processed by the invalidation circuit.

7. The apparatus of claim 2, wherein the invalidation circuit is configured to: in response to processing a conversion transaction, associate the conversion transaction with a replacement epoch associated with the current epoch, wherein, for a received transaction, the replacement epoch is not earlier than the invalid epoch associated with the given invalid transaction.

8. The apparatus of claim 7, wherein the replacement epoch is an invalid epoch in which the invalid circuit currently does not store data defining the associated invalid transaction.

9. The apparatus of claim 1, comprising: One or more instances of an output buffer circuit are used to store translation transactions processed by the address translation circuit. The invalidation circuit is configured to detect that there is no transition transaction with the same invalid epoch as the given invalid transaction in the output buffer circuit before the invalidation circuit forwards at least the acknowledgment of the invalid transaction.

10. The apparatus of claim 1, wherein: The address translation circuit includes one or more successive processing sections; The invalidation circuit is configured to process the conversion transactions in response to each of the one or more successive processing portions.

11. The apparatus of claim 10, wherein the invalidation circuit is configured to process the conversion transactions in response to each of the one or more successive processing portions outputting the conversion transaction.

12. The apparatus of claim 10, wherein the address translation circuit comprises two or more successive processing sections.

13. The apparatus of claim 11, wherein the invalidation circuitry is used to store data defining two or more invalid transactions and to process conversion transactions having the same invalid epoch as any one of the two or more invalid transactions.

14. The apparatus of claim 5, further comprising a memory associated with the invalidation circuit for storing queues of one or more invalid transactions to be processed by the invalidation circuit.

15. The apparatus of claim 14, wherein the invalidation circuit is configured to selectively complete the processing of invalid transactions for which the invalidation circuit currently stores data, to allow the invalidation circuit to accept the next invalid transaction from the queue, by detecting each translation transaction currently being processed by the address translation circuit when the count value indicates a value greater than zero, and decrementing the count value and selectively applying invalidation to the translation transaction when the currently ongoing translation transaction has the same invalidation epoch as the invalid transaction to be completed.

16. A data processing method, comprising: Access translation data that defines a set of memory address translations; The system receives conversion transactions and invalid transactions. Each conversion transaction defines one or more input memory addresses in the input memory address space, which are to be converted into corresponding output memory addresses in the output memory address space. Each invalid transaction defines at least a portion of the converted data as invalid. Provide the output memory address as the conversion response; Associate one invalid epoch from a set of at least two invalid epochs with each transformation transaction and with each invalid transaction; and Store the data that defines a given invalid transaction, and process transformation transactions that have the same invalid epoch as the given invalid transaction and are processed after the storage of the data that defines the given invalid transaction, to indicate that the transformation transaction is invalid when the invalidity defined by the given invalid transaction applies to a transformation transaction; and In response to the storage of the data, at least an acknowledgment of invalid transactions is forwarded for further processing.

17. A computer program product comprising instructions, which, when executed by a host data processing device, cause the host data processing device to provide an instruction execution environment, comprising: The address translation program logic is configured to access translation data that defines a set of memory address translations; A transaction processing program logic is used to receive transformation transactions and invalid transactions. Each transformation transaction defines one or more input memory addresses in the input memory address space, which are to be translated into corresponding output memory addresses in the output memory address space. The transaction processing program logic is configured to control the address translation program logic to provide the output memory address as a translation response. Each invalid transaction is defined as being at least partially invalid to the transformed data; The transaction tracking logic is used to associate one invalid epoch from a set of at least two invalid epochs with each transformation transaction and with each invalid transaction. as well as Invalidation logic is used to store data defining a given invalid transaction, and for translation transactions that have the same invalid epoch as the given invalid transaction and are processed by the address translation logic after the invalidation logic stores the data defining the given invalid transaction, these translation transactions are processed to indicate that the translation transaction is invalid when the invalidity defined by the given invalid transaction applies to a translation transaction; The invalidation procedure logic is configured to: in response to the storage of the data by the invalidation procedure logic, at least forward the acknowledgment of the invalid transaction for further processing by other devices.

Images