1. Field of the Invention
This invention relates to the field of data processing systems. More particularly, this invention relates to the field of accessing data within a cache.
2. Description of the Prior Art
Caches within data processors can store large amounts of data. Accessing data within caches can be quite a complicated procedure requiring addresses of a relatively large size. Manipulation of such addresses can therefore require significant amounts of power and time. Caches have been organised in a number of ways in order to reduce power and time overheads involved in accessing storage locations within the caches.
One popular way of configuring a cache is the so-called ‘set associative’ cache. A 16 Kbyte set associative cache is shown in
In order to address data stored in this sort of a cache an address 35 comprising a SET or index portion 37, which indicates which of the sets or lines the address is referring to and a TAG portion 36 indicating which of the four ways it is in is used. Such an address identifies a cache line and a cache way. The line being identified by the set and a comparison and match of TAGs stored in 4 TAG RAMs 25 with the TAGs in the corresponding set of the 4 caches 10 indicating the way. In reality more than one data word may be stored in a cache line within a cache way and thus, the address may contain further information.
When accessing data stored in a cache organised in this way, any virtual address produced by a programming model will need to be converted to a physical address. This can slow the procedure, as the program will produce the virtual address early, but the data cannot be accessed until it is converted to a physical address.
A known way of converting a virtual address to a physical address is by the use of a translation lookaside buffer or TLB.
This is one way in which data identified by a virtual address can be accessed. The initial step in this procedure is conversion of the virtual address to a physical address using a table lookaside buffer. This is not a fast step and thus, having this as the first step in the procedure considerably slows the critical path. An alternative to this is shown in
This is faster than the data access shown in
A first aspect of the present invention provides a data processor operable to process data said data processor being operable to perform a plurality of processes or a plurality of applications on said data, said data processor comprising: a cache, a data storage unit operable to store a process or application identifier defining a process or application that is currently executing on said data processor on said data; wherein a data item storage location within said cache is indicated by an address, and said data processor further comprises: a hash value generator operable to generate a hash value from at least some of said bits of said address and at least some bits of said process or application identifier, said hash value having fewer bits than said address.
An address, be it a virtual or a physical address, indicating a storage location of a data item within a cache can require a relatively large number of bits. This is particularly so if it is to uniquely identify a location within a cache. The present invention addresses this problem by providing a hash value generator which generates a hash value from at least some bits of the address and at least some bits of the process or application identifier and produces a hash value having fewer bits than the address. Although, all of the bits of an address may be required to uniquely identify the storage location of that data item, it may be that a good hint could be provided by far fewer bits. The location within a cache used to store data may depend quite strongly on the process or application that the data processor is performing on that data. Thus, it has been found to be particularly advantageous to use data identifying the process or application being performed in the generation of a hash value along with portions of the address itself. Such a hash value which in effect is a reduced bit address indicator provides in most cases an accurate indication of where the data item is stored allowing access to that data item. Thus a data item location can be accurately indicated in most cases using an address indicator of few bits, which therefore can be manipulated and compared in a shorter time and using less circuit area than a wider value would need. It should be noted that data item refers to data in general and should be interpreted to include instructions.
In some embodiments, said address is a virtual address.
A virtual address is used by a program to indicate the location of a data item. A virtual address used by one process may be the same as that used by another process although it may not relate to the same location. Producing a hash value indicating a storage location that takes account of both the virtual address relating to the data item and the application or process that the processor is performing, is an effective way of reducing any data conflicts that may arise from two processes using the same virtual address to indicate different storage locations.
In embodiments, said cache is divided into a plurality of cache ways, each cache way comprising a plurality of cache sets; said address comprises a tag portion and an index portion, said index portion indicating one of said plurality of cache sets comprising said data item storage location and said tag portion indicating one of said plurality of cache ways comprising said data item storage location; said at least some bits of said address used to generate said hash value comprise bits from said tag portion, said hash value having fewer bits than said tag portion.
A common form of cache is a set associative cache in which you have a plurality of cache ways each having their own individual cache sets. In such an arrangement, the index portion is used to determine which cache set is relevant and then a cache tag directory is used for comparison with the tag portion of the address to indicate the actual data location, i.e. which cache way the data item is located in. This comparison can be slow as the tag portions can have a relatively large number of bits. Thus, it would be advantageous to reduce the size of the tag portion by producing a hash value from it.
In embodiments, said hash value generator is operable to generate said hash value by performing logical operations on said at least some bits of said address and said at least some bits of said process or application identifier.
A suitable hash value generator can be produced by performing logical operations on the bits of the address and processor application identifier. It may be that not all bits of the address or all bits of the process or application identifier need to be used to provide a result that gives a reliable hint as to the data location.
In embodiments, each of said bits of said reduced bit virtual address is generated from a logical operation performed on at least one bit of said process or application identifier and at least two bits of said address.
A hash value which is likely to provide an accurate hint to where the data item is located is produced if each of the bits of the hash value are derived from a logic operation performed on at least one bit of the processor application identifier and some bits of the address.
In some embodiments, said at least two bits of said address are bits separated from each other by a number of bits equal to or approximately equal to the number of bits of said hash value.
By producing individual bits from logical operations performed on bits of the address that are remote from each other rather than on bits that are adjacent, it has been found that a hash value that has a high probability of providing an accurate indication of where a data item is located is produced.
In an embodiment of the invention said hash value generator is operable to generate at least one bit of said hash value by performing two step logical operations on said at least some bits of said address and said at least one bit of said process or application identifier.
Combining the bits of the address and the process or application identifier using logical operations is an effective way of producing the hash value. The number of logical operations performed can increase the number of bits that are used to produce the hash value and thus, possibly increase its accuracy, however it also extends the time required to create the hash values. For these reasons it has been found to be advantageous to use two step logical operations. This is a good compromise between combining several bits while not extending the length of time or circuit area required to produce these values.
In one embodiment, said hash generator is operable to generate at least one bit of said hash value by performing an additional first step comprising performing a logical operation on at least two of said process or application identifier bits.
Although it is advantageous to keep the number of steps of logical operations low it can also be advantageous to combine several bits which require more steps. As the process or application identifier are available before the address, bits of these can be combined in an additional step without impacting on the time taken to produce the hash value. Thus, in some embodiments, some bits of the hash value are produced using a logically combined value of some of the bits of the process or application identifier.
A variety of different logical operations can be used to combine the bits to produce the hash value, for example, in some embodiments said logical operations comprise exclusive OR operations.
A further aspect of the present invention provides a method of processing data comprising: storing a data item within a storage location within a cache, said storage location being indicated by an address; performing a process or an application on said data item said process or application being identified by an application identifier; generating a hash value from at least some of said bits of said address and at least some bits of said process or application identifier, said hash value having fewer bits than said address.
A still further aspect of the present invention provides a means for processing data operable to perform a plurality of processes or a plurality of applications on said data, said means for processing data comprising: a means for storing data operable to store a process or application identifier defining a process or application that is currently executing on said data processor on said data; a data storage means operable to store a data item in a storage location within said data storage means, said storage location being indicated by an address; a means for generating a hash value operable to generate a hash value from at least some of said bits of said address and at least some bits of said process or application identifier, said hash value having fewer bits than said address.
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.
However, as the hash values are not necessarily unique, there is a possibility that the wrong data item has been accessed. Thus, in parallel to this data access a slower and more rigorous identification of the data item storage location is performed. In this case the virtual address 81 is fed to a TLB 30 and the virtual tag portion of the address is converted to a physical tag portion. The virtual index is input to the cache tag directories 40 and the four possible tags may be compared by comparator 60 to the physical tag. A match identifies which of the cache ways the data item is located in. A check can then be made to see if the data access performed in response to the hash value was indeed correct.
It should be noted that although in this embodiment a TLB is still consulted and the tags are compared, this access and comparison is no longer in the cache access path and as such does not slow down the procedure unless a cache miss has occurred. Thus, provided cache misses are rare the procedure is speeded up.
In alternative embodiments (see
In embodiments where there is a single hash buffer, the accessing of only one buffer can save power and time. Furthermore, in all embodiments the comparison of the smaller 6 bit hash values rather than the larger 19 bit tags provides both a time and power saving. However, the cache directories 40 are accessed in parallel to provide a check that the hash value provides the correct data item. Although, this does not increase the time of the cache access (unless there is a cache miss) it does mean that the potential reduction in power may not occur. However, as this cache directory access is not in the critical path it is possible to delay it by a cycle and then when the hash value 82 has produced a match with the hash buffer, the way indicated by the match can be used so that only access to the cache tag directory 40 relating to this way is made. By doing this significant power savings can be made.
The timing of the accesses is shown in
The following table, table 1, compares the number of RAM accesses of the traditional access system compared to the access system of embodiments in cases where a hit and miss occur. As can be seen in the traditional method the four data RAMs of the cache 50 need to be accessed and the four tag RAMs of cache directory 40 need to be accessed in each case. In this embodiment only one of the RAMs of the cache directory needs to be accessed in the case of a cache hit and although all four of the cache data RAMs of the cache 50 are accessed initially only one bank of the sense amplifiers are enabled, the others being turned off in response to the hash value showing that they are not needed. In the case of a cache miss, such that the comparison of the physical tag with the indicated way of the cache tag directory does not give a corresponding hit, then all four of the cache tag directories need to be accessed to determine where the data item is.
In summary by decoupling the TLB/Cache directory path from the data selection path cache access can be speeded up. Furthermore, removing this from the critical path also enables the cache tag directory access to be pushed out further allowing only one cache tag directory RAM to be accessed.
The use of a hash value and a hash value buffer can therefore improve data access times and reduce power consumption in cases where cache hit occurs. It should be noted that the hash value only provides a hint as to the data storage location and in the cases where a cache miss occurs the resulting process is worse than if the hash buffer was not there. It is therefore very important that the number of cache misses are kept low. The number of cache misses occurring depends on the type of logic operations that are performed and the data that is used to form the hash values. It has been found that using bits of the virtual address and bits of the process identifier or application specific identifier produces an algorithm giving an accurate hint as to the data location in most cases.
In the algorithm shown each hash bit is generated from virtual address bits that are separated by approximately the number of hash bits produced, in this case six. These bits are exclusive ORed together. For example hash [0] is generated from virtual address bit [13, 19, 26]. This spreads the bits of the virtual address across the bits of the hash value. The algorithm also spreads the ASID/PID bits across each hash bit. However, since the ASID/PID consists of eight bits and the hash value only consists of six bits in this example three of the ASID/PID bits are XORed together and used to generate hash [0]. It should be noted that as the ASID/PID bits are available earlier than any of the virtual address bits, the extra gates to exclusive OR all these together does not slow down the generation of hash [0] compared to the other hash bits.
It has been found in the running of several benchmarks that although the use hash values producing a subset of the tags instead of the entire tags can result in some performance degradation, in fact this has minimal impact on performance and this slight degradation is more that compensated for by the increase in frequency that is achieved by this implementation.
Although it is desirable to reduce the number of caches misses, they will sometimes occur. For example, when using virtual indexes to access caches, a problem of aliasing a virtual address to the same physical address may arise. This occurs in some caches where a virtual index does not uniquely identify all of the storage locations within that cache. In these cases, an index portion may not be sufficient to uniquely identify each of the cache lines and thus, it may be that one of two lines may be indicated by a particular index value. Data integrity is compromised if this is allowed to occur. This is a normal alias condition and is referred to hereinafter as PC/ALIAS condition and may be present in traditional cache systems where the index portion of the address does not comprise sufficient bits to uniquely identify every line within the cache.
Furthermore, in embodiments, a hash buffer has been created to provide an alternative to the cache directory when accessing cache data. The hash buffer contains reduced bit indications of address locations. As mentioned previously, comparing data within this hash buffer requires less power and less time than comparing full length addresses. However, by its very nature of being reduced bit, the hash values do not provide a unique identification of a storage location within a cache and as such further aliasing may occur. The hashes are generated in such a way as to hopefully provide a good indication of storage location within the cache, however, it is always possible that a hash hit will occur which indicates an incorrect data storage location. In order to avoid incorrect data being accessed and used, a check is made of each data access. Provided, most data accesses are correct, this check should not unduly slow down the processor. However, it is important that the check and in particular, the correction of any false cache hits is done efficiently.
With this is mind, each data access is checked using the physical address derived from the virtual address, the TLB 30 and the cache tag directories 40 (see
In order to do this, the rest of the physical address tags within the line of the cache directory indicated by the virtual address are checked. If a cache hit is not found, then it is concluded that the data is not present in the cache, i.e. there is a hash hit/cache miss and the data needs to be written from memory to the cache. Thus, the storage location indicated by the hash hit is invalidated, or in some cases cleaned and invalidated and then data is retrieved from the memory and written to the storage location indicated by the hash hit. By writing the data to the storage location indicated by the hash hit, a hash value generated from this virtual address in the future should give a correct indication of the storage location. The instruction that caused the replay can then be reissued.
In the case that there is a cache hit, i.e. a physical address match is found in the line of the cache directory indicated by the address, but in a different cache way to that indicated by the hash, the hash buffer itself needs to be amended to avoid having two identical hashes within the same line of the hash buffer. Thus, in such a case as this the hash value within the hash buffer corresponding to the originally indicated storage location is invalidated (and the line potentially evicted if dirty) and the generated hash value is written to the storage location corresponding to the physical address hit. Thus, the hash buffer is repaired and future data accesses to this address should not encounter a false hash hit. The instruction that caused the stall can then be reissued.
If there is a cache hit, then the hash miss was a false miss and the memory access can be cancelled. The hash buffer then needs to be updated and the generated hash value should be written to the location corresponding to the location identified by the cache directory hit. This ensures that next time that data should be accessed there will be a hash hit. The instruction can then be reissued.
A further preferred embodiment is described below:
In a traditional physically tagged way associative data cache, the tag array and data array will have to be fired in parallel with the TLB lookup. Once the TLB generates the physical address, it gets compared with the tag array physical tags which then generate the way hit signal to select the appropriate data array way. There are couple of problems with this approach.
All the data ways have to be fired in parallel which is a lot of power. A system using an embodiment of this invention, hereafter referred to as Tiger will be used in wireless systems where low power consumption (lesser than a watt) is very important. To reduce power, the data array could be fired after the tag array has been fired and tag hits have been determined, but this would make the data cache a slower implementation—longer latency. Going from 2 cycle cache access to a 3 cycle cache access would cause a 5-6% drop in performance. Also, all the way tags have to be fired in parallel.
Secondly, in the traditional implementation, in order to get a fast tag array hit, the TLB has to be made fast which implies that the adder that generates the virtual address has to be fast. Thus, there is a lot of pressure on the adder and TLB implementation.
In the HVAB (hashed virtual address buffer) approach, an array which is smaller than the tag array (in terms of number of bits to be compared) called the HVAB array is looked up first and a hashed virtual address (in Tiger's case 6 bits) is used to compare against this array. Not only is the field to be compared smaller, it also uses virtual address bits rather than physical address bits as is normally used in a traditional design. If there is a hit, only the hitting tag and data way are fired. The physical tag from the tag array is then compared with the TLB's PA to make sure that the hash hit is correct. While the tag validation is going on, the data array that was fired in parallel with the tag array way completes and the data is ready for alignment and forwarding to the various functional units.
The advantages of the HVAB scheme are:
A 4 bit random replacement counter is used when all ways are valid. The random replacement counter shifts left by one bit every clock cycle and is sampled on a miss.
Virtual Hash
The virtual hash is formed from VA (31:13) and Process ID (PID)/Address Space ID (ASID). This is formed by a two level XOR. The reason the PID/ASID are being used is to have a good representation of the various processes in the virtual hash. Various hash schemes were studied—5 bit, 6 bits and 7 bits with various levels of XORs. A 6 bit hash has been chosen that gives almost the same hit rate as using the entire physical tag—there was a 1% degradation in hit rate due to aliasing. There can be aliases due to the following reasons:
Integer Loads
Integer Stores and Neon Accesses
Instruction Accesses
Instruction accesses need not worry about PC Alias. The line can co-exist in two different indices—but care has to be taken to invalidate both locations when invalidate operations are performed.
Cache Pipelines
A simplified pipeline is shown in
The memory pipeline is comprised of three stages:
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.