|Publication number||US7039756 B2|
|Application number||US 10/424,236|
|Publication date||May 2, 2006|
|Filing date||Apr 28, 2003|
|Priority date||Apr 28, 2003|
|Also published as||US7257673, US20040215893, US20060117143|
|Publication number||10424236, 424236, US 7039756 B2, US 7039756B2, US-B2-7039756, US7039756 B2, US7039756B2|
|Inventors||Steven M. Emerson, Balraj Singh|
|Original Assignee||Lsi Logic Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (7), Non-Patent Citations (1), Referenced by (12), Classifications (10), Legal Events (8)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present application relates to co-pending applications (i) Ser. No. 10/262,180 filed Oct. 1, 2002, now U.S. Pat. No. 6,799,304, (ii) Ser. No. 10/323,521 filed Dec. 18, 2002 and (iii) Ser. No. 10/325,383 filed Dec. 20, 2002 which are hereby incorporated by reference in their entirety.
The present invention relates to caching policies generally and, more particularly, to a method for using a ternary content addressable memory to implement software programmable cache policies.
Conventional cache policies have been implemented in a number of different ways such as hard-coded as part of a design, adjustable via configuration pins and adjustable via memory protection or memory management units for tightly coupled caches. A tightly coupled cache is commonly directly connected to a central processor unit (CPU) and does not have a bus protocol implemented in a data path between the CPU and the cache. In the absence of a bus protocol, the cache policy to be used can be easily communicated to the cache controller as a direct output from a memory protection circuit or a memory management unit for the CPU.
If cache policies are hard-coded (i.e., fixed in the cache hardware), the cache policies can be too restrictive to be of use to a system programmer. Poor system performance or even incorrect operation can result from hard-coded policies. Configuration pins typically are used to define a limited set of options and are not normally used to define the cache policies by address region. Some existing processors define large blocks of fixed-size memory regions with a particular set of cache policies to be used for each block, but the granularity of the address regions or the cache policies are not always sufficiently flexible.
The present invention concerns a method of operating a circuit. The method generally comprises the steps of (A) generating a particular policy of a plurality of policies by a lookup operation on a first transaction request received by the circuit, (B) generating a second transaction request for use by a memory external to the circuit based upon the first transaction request and the particular policy in response to a first cache signal of the first transaction request having a non-cacheable state and (C) searching a plurality of address tags for cache data cached within the circuit for a match with the first transaction request in response to the first cache signal having a cacheable state.
The objects, features and advantages of the present invention include providing a method and/or architecture for software programmable cache policies that may provide (i) a flexible method to determine cache policies for de-coupled caches, (ii) a cache policy determination that may be done dynamically using an address region match, (iii) variable size address pages, (iv) use of bus based cache where the bus may provide limited support for a cache policy determination and/or (v) a multi-ported cache where individual input ports coming into the cache may have different bus protocol types without conflicting cache policy determination support.
These and other objects, features and advantages of the present invention will be apparent from the following detailed description and the appended claims and drawings in which:
The present invention generally concerns a software programmable method and architecture for specifying cache policies by memory region (e.g., address range). Specific cache policies may be implemented such that a bus protocol between a processor and a bus-based cache module has no or little impact on cache policy determination. Each of the memory regions may be variable in size and a number of regions that may be supported may be determined by a size of a content addressable memory (CAM). A policy is generally determined for every cacheable type transaction request by using an address generated by a processor to retrieve a particular policy to be implemented for that transaction request using CAM lookup methods. In one embodiment, a ternary CAM implementation may determine the cache policy which may be enforced for a particular memory address region.
The block 104 may be used with multiple processors 102 a–c or with a mix of processors 102 a–c and other master devices (e.g., hardware masters and software masters). The block 104 generally provides an inline cache subsystem or module to improve system latency for high performance processors 102 a–c. A variety of system topologies may exist which could benefit from the block 104.
The block 104 may be implemented as an inline level 1 or level 2 (L2) cache circuit also referred to as a multiport cache block. The multiport cache block 104 is generally designed to support a wide range of cache policies. The support of the cache policy options or parameters may be implemented in a variety of ways depending on the options to be supported. The options may be supported using the following methods, software programmable based upon an address rage of transaction requests or commands, software programmable base on a mode, compile-time switches and/or strap pins.
Each bus 106 a–c, 110 and 116 may be implemented as an Advanced High-Performance Bus (AHB) defined in an “Advanced Microcontroller Bus Architecture (AMBA) Specification”, revision 2.0, 1999, published by ARM Limited, Cambridge, England and hereby incorporated by reference in its entirety. Each bus may be implemented with a different native width and/or a different subset of protocols to accommodate different types of processors 102 a–c, port widths, endianess, and/or clock frequencies. Other bus standards may be implemented to meet a design criteria of a particular application.
The configurable multiport cache block 104 may be operational as a fully featured cache controller with multiple on-chip AMBA AHB ports 108 a–c, 112 and 118. The multiport cache block 104 generally supports from one to eight ports 108 a–c using a compile time parameter. In addition, a wide variety of cache controller configurations and cache policies may be supported via software, compile-time options and strap pins.
An example range of configuration options may include, but are not limited to, associativity (e.g., 4, 8, 16-way), set size (e.g. 16 kilobytes (KB) to 64 KB), write back versus write-through, write allocate/no-write-allocate, line widths (e.g., 256/512-bit lines), line replacement policy (e.g., modified line replacement unit (LRU) or random), cacheability via an AHB signal (e.g., HPROT), bufferability via the signal HPROT, cache flush and/or cache enable. The multiport cache block 104 may also provide parity protection with an option for error correction coding, fully synchronous operation, fully static operation, flexible AHB bus 108 a–c, 110 and 116 clocking that may allow for synchronous but integer related clock frequencies, configurable line sizes, cache coherency checks and/or changeable cache policies. The cacheability and bufferability of the multiport cache block 104 may be determined by AHB signal HPROT bits which may driven by the processors 102 a–c and other masters (not shown). Fully featured processors 102 a–c will generally have an memory management unit or other memory protection blocks that may define the cacheability and bufferability attributes.
Address ranges from transaction requests received by the multiport cache block 104 may be used to control some cache policies, including write-back versus write through and write allocate/no-write-allocate. The address ranges for each particular policy may be programmed ahead of time via the interface configuration block 130. Once programmed, an address compare may be performed in parallel and substantially simultaneously or contemporaneously with a tag lookup operation to determine an appropriate cache policy to implement. Having multiple different cache policies across an address space may provide several benefits. For example, software programmers may have control over code location during object linking compilation step. Data that may behave better in an L2 cache using a write-back policy may be located accordingly and be controlled in the L2 cache by programming the address range registers appropriately. Instruction code may be located outside the address ranges of the customized policies and thus may adhere to a background policy that may also be programmed by software. Two address ranges and thus two different policies may overlap each other. Priority may be given to the policy associated with the address range having the most number of bits matching an address in the transaction request being considered.
Several line replacement options may be supported using programmable mode bits within cache control registers. The line replacement policy for the entire cache may be determined by a mode setting in the cache control registers. The policy may be uniform across the cache and should not be changed after startup. The line replacement policies supported may include, but are not limited to, modified-LRU replacement and random replacement. The cache mode may be changed after the cache has been flushed and before re-enabled.
The multiport cache block 104 generally supports a number of associativity options as well as set size per way using both compile-time as well as strap pin (not shown) options. Therefore, a user may integrate a range of associativity and set size options and make the options adjustable using strap pins. Once the behavior of the application under various associativity and set size options is generally understood, the user may either recompile a specific option or set of options to save silicon area. Alternatively, for re-programmable systems, the user may continue to support a range of options. For multiple processors 102 a–c and/or multiple software threads, the increased associativity generally helps increase overall cache effectiveness with a tradeoff as to total cache size. The range of associativity supported may be 4, 8 or 16-way with set sizes of 16 KB, 32 KB or 64 KB per set. The ranges generally result in a total supportable cache size of 64 KB to 1 megabytes. Other ranges of associativity and set sizes may be implemented to meet the criteria of a particular application. The options may be summarized in Table I as follows:
Total Cache Size
The multiport cache block 104 generally comprises a plurality of line buffer circuits or blocks 120 a–c, an arbiter circuit or block 122, a cache controller circuit or block 124, a cache memory circuit or block 126, a line buffer circuit or block 128 and an interface configuration circuit or block 130. Each line buffer block 120 a–c may be connected to one of the busses 106 a–c, respectively. Further details for the line buffer block 120 a–c may be found in the related application Ser. No. 10/323,521 entitled, “AMBA Slave Modular Bus Interfaces”.
The arbiter block 122 may be operational to control access to the controller block 124 through the line buffer blocks 120 a–c. The arbiter block 122 generally performs a prioritization and ordering of AHB Line Cache requests for the cache controller block 124. The arbitration process may be both a fixed and Time Division Multiplexor (TDM) based scheme with lookahead that may help to allocate priority appropriately while preventing a port from starving other ports. Both the programming of the arbitration scheme and TDM slot assignments is generally done under program control through the interface configuration block 130. The lookahead feature may ensure assigned timeslots do not go unused. Further details for the arbiter block 122 may be found in the related application Ser. No. 10/262,180 entitled, “Arbitration Within a Multiport AMBA Slave”. The arbiter block 122 may provide exclusive access among the line buffer blocks 120 a–c to the controller block 124 through a multiplexer (not shown) at any given time.
The controller block 124 may be operational to control cache operations within the multiport cache block 104. The controller block 124 may also be operational to control cache policies of transaction requests held in the line buffer blocks 120 a–c based on one or more address ranges associated with the policies. Details for the controller block 124 will be provided later.
The cache memory block 126 may be configured to store address tags, cache data and the cache policies. The cache memory block 126 is generally controlled by the controller block 124. Details for the cache memory block 126 will be provided below.
The interface configuration block 130 may be operational to program and configure the other blocks within the multiport cache block 104. The interface configuration block 130 may be used to setup the programmable cache policies in the cache memory block 126 and read the programmed polices from the cache memory block 126. In one embodiment, the interface configuration block 130 may be implemented as a 32-bit AHB-Lite port that generally allows access to control and status registers for each of the major sub-blocks of the multiport cache block 104. The interface configuration block 130 may be connected to one of the same AHB busses 106 a–c as the line buffer blocks 120 a–c but is generally independent of the line buffer blocks 120 a–c to enable high performance by reducing address decoding and data multiplexing. Further details of the interface configuration block 130 may be found in the related application Ser. No. 10/323,521 entitled, “AMBA Slave Modular Bus Interfaces”.
The block 142 may be implemented as a memory block. In one embodiment, the memory block 142 may be a double data rate (DDR) memory array. In other embodiments, the memory block 142 may be configured as a random access memory (RAM), a read-only memory (ROM), or the like. In still another embodiment (not shown), the memory block 142 may be disposed within the block 144.
The block 144 may be implemented as a multiport cache with an integrated memory controller, also referred to as a multiport cache-memory controller block. The multiport cache-memory controller block 144 generally comprises the line buffer blocks 120 a–c, the arbiter block 122, the controller block 124, the cache memory block 126, the interface configuration block 130 and a circuit or block 150. The block 150 may be implemented as a memory controller block. In one embodiment, the block 150 may be implemented as a DDR memory controller block.
The addition of the DDR memory controller block 150 generally provides a further level of integration by including a high performance DDR SDRAM memory subsystem. By including the cache capability of the controller block 124 and the cache memory block 126 as part of a multiported DDR memory subsystem, potential cache incoherency problems due to “write-behind” situations may be avoided while at the same time generally improving a latency the processors 102 a–c would otherwise see. The integrated DDR memory controller block 150 generally supports data widths of 32-bits or 64-bits, along with a single 32-bit AHB-Lite width for control/status information. Other widths may be implemented to meet the criteria of a particular application. The DDR memory controller block 150 may be configured from the interface configuration block 130. Further details for the DDR memory controller block 150 and the DDR memory block 142 may be found in the related application Ser. No. 10/325,383 entitled, “AMBA Modular Memory Controller”.
The block 182 may be implemented as a local interface block connectable to the busses 106 a–c. The local interface block 182 generally comprises one or more bus interface sub-modules or blocks 190 a–c, one or more cache control interface sub-modules or blocks 192 a–c, and a plurality of queues 194 a–c. The local interface block 182 may convey transaction requests received on the busses 106 a–c to the controller block 124. The queues 194 a–c may buffer transaction requests while the cache controller block 124 is servicing a particular transaction request.
The controller block 124 generally comprises a cache control circuit or block 200, a control registers circuit or block 202, a buffer circuit or block 204 having multiple line buffers 206 a–c, a test circuit or block 208, an allocate-and-lock circuit or block 210, a miscellaneous control circuit or block 212 and a policy content addressable memory (CAM) circuit or block 214. The policy CAM block 214 may also be referred to as a lookup circuit or block. The policy CAM block 214 may be implemented as a ternary CAM. The cache memory block 126 generally comprises multiple tag random access memory (RAM) circuits or block 220 a–d, multiple data RAM circuits or blocks 222 a–d and multiple optional scratchpad RAM circuits or blocks 226 a–c.
The line buffer block 184 a may be referred to as a system bus interface block connectable to the system level AHB bus 188 a. The line buffer block 184 b may be referred to a maintenance bus interface block connectable to the maintenance AHB bus 188 b. The system and maintenance interface blocks 184 a–b may be the interfaces to lower levels of a memory hierarchy in which the multiport cache block 180 resides. The system and maintenance buses 188 a–b are generally split between maintenance and system bus functions with an expectation that within a system, the maintenance bus 188 b would generally be a slower, narrower and more global in scope than the system bus 188 a. The system bus 188 a generally establishes a much higher performance interconnect to a main memory 216. The separate buses 188 a–b may also allow simultaneous operations to occur for concurrent transaction requests.
The local interface block 182 generally attaches directly to the bus interfaces 108 a–c for communicating with the processors 102 a–c (
The control registers block 202 generally contains the actual control and status registers for the multiport cache block 180. The control registers block 202 may include registers (e.g., fields) for the policy CAM block 214 as described below. The control registers block 202 may also decode read and write type transaction requests to the registers from the local bus interface block 182.
The buffer block 204 generally includes the Write Miss Buffer 206 a, the Read Miss Buffer 206 b and the Allocate/Lock Buffer 206 c. The buffers 206 a–c may be a cache line in width and may be used for temporary line storage during a particular operation or state in a transaction request. As an example, the Write Miss Buffer 206 a may be used to store data coming back from the main memory 216 via bus 188 b after a write miss has occurred and a write allocation has been initiated. The Write Miss Buffer 206 a may hold data until the line of data may be written into a cache data RAM block 222 a–d and the corresponding tag RAM block 220 a–d is updated.
The cache RAM blocks generally comprise multiple monolithic RAMs for the cache data RAM blocks 222 a–d and the tag RAM blocks 220 a–d. The data RAM blocks 222 a–d and the tag RAM block 220 a–d set memories may be implemented with standard 6-transistor static RAM cell based memory compilers using single port synchronous configurations. Custom cache data/set memories may be avoided so the same memory compiler technology, as is used in the rest of the system, may be used.
The data RAM blocks 222 a–d and tag RAM blocks 220 a–d may be organized as an N-way (e.g., 4-way) set associative arrangement with set size of 32 KB. The 4-way set and 32 KB set size generally provide a total cache size of 128 KB. Larger RAMs or more sets may be implemented to change the associativity and/or total cache size. The data RAM blocks 222 a–d may also be organized as a full line wide to enable high bandwidth reads/writes from/into the cache RAMs. The cache line width may be 256 or 512 bits. Other cache line widths may be implemented to meet the criteria of a particular application.
The scratchpad RAM blocks 226 a–c generally comprise large blocks of RAMs that effectively function as a separate set having a very large line size. The scratchpad RAM blocks 226 a–c may be variable in size but would typically be 8 KB to 32 KB. Other sizes may be implemented to meet the criteria of a particular application. The cache architecture of
The control block 200 generally interfaces between the local interface block 182 and the line buffer blocks 184 a–b by handling cacheable transition requests into the cache tag blocks 220 a–d and the data RAM blocks 222 a–d. The control block 200 may first probe the policy CAM block 214 to determine the policy bits to be used for the received transaction. A performance enhancement of the present invention may include a substantially simultaneous lookup into all of tags in the cache tags RAM blocks 220 a–d to determine if the associated cached data may be resident in the data RAM blocks 222 a–d. A non-cacheable request may be passed onto either the line buffer block 184 a or the line buffer block 184 b as appropriate and properly sequenced for read or write until the transaction request may be completed. Upon receipt of a cacheable request, the cache controller block 200 may probe the tag RAM blocks 220 a–d to see if the data may be resident in the data RAM blocks 222 a–d. The cached data may be returned upon a cache hit, or the read transaction request may be passed to the appropriate line buffer block 184 a or 184 b upon a cache miss. In either case of a cache hit or a cache miss, the transaction request may be properly sequenced according to the policy bits active for a memory region identified by the transaction request.
The policy CAM block 214 may receive information from the control registers block 202 (
Each comparison block 244 a–d may generate a signal (e.g., TAG_x_HIT, where x is an integer from 0 to d). Each comparison block 246 a–c may generate a signal (e.g., SPy_HIT, where y is an integer from 0 to c). The hit detection block 250 may generate a signal (e.g., MISS) if the signals TAG_x_HIT and the signals SPy_HIT indicate a cache miss. The hit detection block 250 may generate an enable signal (e.g., EN) if the signals TAG_x_HIT and the signals SPy_HIT indicate a cache hit.
The logical block 254 may generate a signal (e.g., DATARAMEN[6:0]) that may enable a particular data RAM block 222 a–d holding the cache data triggering the hit. The set select block 252 may generate a signal (e.g., SEL) addressing the particular data RAM block 222 a–d and scratchpad RAM block 226 a–c holding the cache data triggering the hit. The multiplexer 258 may route the cache data causing the hit to the output data buffer block 256 based upon the signal SEL.
The second address tag buffer block 260 may generate and address signal (e.g., ADD). The address signal ADD may identify where within the data RAM blocks 222 a–d and the scratchpad PAM blocks 226 a–c incoming data held in the input data buffer block 262 may be stored.
The cache policy block 214 is generally implemented using a ternary CAM architecture that may enable quick hardware lookups of incoming addresses. Upon finding one or more matches, the policy CAM block 214 presents the corresponding cache policy bits active for the current transaction request. The policy CAM block 214 may store all or the active cache policy entries including fields for the cache policy addresses, the cache policy address masks, and the cache policy bits (e.g., bits within the signal POLICY_BITS)
As a point of reference, conventional binary CAM entries compare incoming logical zero and logical one bits exactly during a lookup phase for a match to occur. The ternary CAM generally allow matching operations on a bit-by-bit basis during the lookup to be 0, 1, or X (e.g., don't care). Since the matching CAM entry is an address, the ternary CAM function effectively allows a programmable match width that allows policy bits to be active over a variable page size. Variable page sizes may be useful in implementing virtual address machines. The policy CAM block 214 may also be implemented with fixed page sizes that a conventional CAM would implement. However, a useful implementation using conventional CAMs would include too many entries to be practical. Because the range of addresses for each entry of a ternary CAM may be variable, the ternary CAM function generally works well in the lookup operation of the policy CAM block 214.
The policy CAM block 214 may be initially written with cache policy entries including the cache policy addresses, the cache policy address masks, and the cache policy bits at startup or any time thereafter. The policy CAM block 214 may be loaded through an interface to the control registers block 202 using a same mechanism as other internal status and control registers. Therefore, the various fields within the policy CAM block 214 may appear the same as any other program addressable location to software or code.
During the lookup phase, the ternary CAM performs a substantially simultaneous search of all entries for a longest prefix match. The prefix may be the upper bits of an address received in a transaction request masked with an appropriate mask programmed in the ternary CAM. The entry which has the longest sequence of matching bits according to the incoming match field, the match field for each entry, and the corresponding match field mask for each entry may be generated as the correct policy. Upon a match, the policy bits from the active policy may be returned and passed onto the cache control block 200 to be used throughout the remaining duration of that transaction request.
The Cache Policy Page Address registers are generally used to set the page address which, when combined with the corresponding Cache Policy Page Address Mask and Cache Policy registers, defines the cache policy for that page. There may be 32 registers that make up the Cache Policy Page Address registers, one for each address region. Other numbers of Cache Policy Page Address registers may be implemented to meet a design criteria for a particular application.
The variable C may be implemented as a one-bit variable determining either a cacheable state (e.g., a logical one state or condition) or a non-cacheable state (e.g., a logical zero state or condition) for a respective policy of an address region. The variable C may have a reset value of zero (e.g., cacheable) Access to the variable C may be read and write.
The variable B may be implemented as a one-bit variable determining either a bufferable state (e.g., a logical one state or condition) or a non-bufferable state (e.g., a logical zero state or condition) for a respective policy of an address region. The variable B may have a reset value of zero (e.g., non-bufferable). Access to the variable B may be read and write.
The variable WA may be implemented as a one-bit variable determining either a write-allocate state (e.g., a logical one state or condition) or a no-write-allocate state (e.g., a logical zero state or condition) for a respective policy of an address region. The variable WA may have a reset value of zero (e.g., no-write-allocate). Access to the variable WA may be read and write.
The variable WB may be implemented as a one-bit variable determining either a write-back state (e.g., a logical one state or condition) or a write-thru state (e.g., a logical zero state or condition) for a respective policy of an address region. The variable WB may have a reset value of zero (e.g., write-thru). Access to the variable WB may be read and write.
The variable MWA may be implemented as a one-bit variable determining either a minimum write-allocate-on-burst state (e.g., a logical one state or condition) or a minimum write-allocate-on-any state (e.g., a logical zero state or condition) for a respective policy of an address region. The variable MWA may have a reset value of zero (e.g., minimum write-allocate-on-any). Access to the variable MWA may be read and write.
The MWA bit is generally used to determine a minimum request size for a write-allocate enable region that may trigger a write-allocate during a write miss. Requests smaller than the size, even if enabled for write-allocate, may not trigger a write-allocate to occur. Requests equal to or larger than the size, if enabled for write-allocate, may trigger a write-allocate operation to occur.
Several variations may be implemented in a design of the block and circuit without departing from the sprite of the present invention. For example, instead of using a monolithic ternary CAM for the address compare, mask and policy determination, a discrete implementation of registers, masks and comparators may be implemented. In another example, a number and type of cache policies that may be determined may extend beyond the above disclosed examples. Generally, any number of memory regions and cache policies may be implemented. Furthermore, the address size may be larger or smaller than that shown for the Cache Policy Address/Mask registers.
The present invention generally provides a user with an ability to program cache polices by memory region. The programmable cache policies may be useful in a variety of implementations such as the multiport cache controller block 104 and the multiport cache-memory controller block 144 with an integral DDR memory controller. The architecture of the inline cache may be independent of the type of processors 102 a–c implemented. Large multi-way set arrangements may include options for 4, 8 or 16 sets. Multiple busses 106 a–c may be accommodated. Arbitration among the busses 106 a–c may include time division multiplex arbitration with lookahead and/or programmable slot assignment to guarantee minimum and/or maximum bandwidth allocated among the bus ports 120 a–c. The AMBA 2.0 AHB-Lite configuration may be supported. A configuration port 130 may be included for programming control registers with user determined options. Parity protection may be implemented with an option for error correction code support. Operations may be fully synchronous with a fully static design. Flexible AHB bus clocking generally allows synchronous bu integer related clock frequencies. The line size may be user configurable (e.g., 256-bit or 512-bit) Cache coherency checks may be done as part of an AHB line cache. The arbiter block 122 generally supports the AHB HLOCK operation. Cache policies may be programmed for write-back versus write-through and write-allocate.
The ternary CAM entry with masks generally determines the memory address regions to which policies may be applied. Corresponding matched CAM entries may determine cache policy bits to be used for the particular transaction request. Multiple (e.g., 32) separate address regions may be implemented, each with a unique policy. Each policy may establish a write-allocate versus no-write-allocate condition, a write-back versus write-thru condition, a cacheable versus non-cacheable condition, a bufferable versus non-bufferable condition, a minimum write-allocate size (e.g., burst/no-burst) and other conditions. A size of each region may be independent of other regions since each ternary CAM entry generally has a separate address mask.
The monolithic ternary CAM implementation may be suitable for high performance designs. For example, the ternary CAM may provide a cache function with multiple heterogeneous processors or systems interconnected with bus protocols that don't support signals for cache policy determination. Therefore, a cache policy may be generated without being signaled as part of a transaction request generated by the processors and/or masters.
The various signals of the present invention are generally “on” (e.g., a digital HIGH, or 1) or “off” (e.g., a digital LOW, or 0). However, the particular polarities of the on (e.g., asserted) and off (e.g., de-asserted) states of the signals may be adjusted (e.g., reversed) accordingly to meet the design criteria of a particular implementation. Additionally, inverters may be added to change a particular polarity of the signals. As used herein, the term “simultaneously” is meant to describe events that share some common time period but the term is not meant to be limited to events that begin at the same point in time, end at the same point in time, or have the same duration.
While the invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the spirit and scope of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4860192 *||Oct 3, 1986||Aug 22, 1989||Intergraph Corporation||Quadword boundary cache system|
|US5263140 *||Jan 23, 1991||Nov 16, 1993||Silicon Graphics, Inc.||Variable page size per entry translation look-aside buffer|
|US5615349 *||Jun 5, 1995||Mar 25, 1997||Mitsubishi Denki Kabushiki Kaisha||Data processing system capable of execution of plural instructions in parallel|
|US5710905 *||Dec 21, 1995||Jan 20, 1998||Cypress Semiconductor Corp.||Cache controller for a non-symetric cache system|
|US5724549 *||Oct 1, 1993||Mar 3, 1998||Cyrix Corporation||Cache coherency without bus master arbitration signals|
|US5913228 *||Mar 12, 1997||Jun 15, 1999||Vlsi Technology, Inc.||Method and apparatus for caching discontiguous address spaces with short cache tags|
|US6373846||Mar 9, 1998||Apr 16, 2002||Lsi Logic Corporation||Single chip networking device with enhanced memory access co-processor|
|1||"AMBA(TM) Specification", (Rev. 2.0), ARM Limited 1999, pp. 1-1 through 6-38 (230 pages).|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7574564 *||May 11, 2006||Aug 11, 2009||Freescale Semiconductor, Inc.||Replacement pointer control for set associative cache and method|
|US7882302||Feb 1, 2011||International Business Machines Corporation||Method and system for implementing prioritized refresh of DRAM based cache|
|US7962695||Dec 4, 2007||Jun 14, 2011||International Business Machines Corporation||Method and system for integrating SRAM and DRAM architecture in set associative cache|
|US8024513||Dec 4, 2007||Sep 20, 2011||International Business Machines Corporation||Method and system for implementing dynamic refresh protocols for DRAM based cache|
|US8108609||May 23, 2008||Jan 31, 2012||International Business Machines Corporation||Structure for implementing dynamic refresh protocols for DRAM based cache|
|US20070266207 *||May 11, 2006||Nov 15, 2007||Moyer William C||Replacement pointer control for set associative cache and method|
|US20090144491 *||Dec 4, 2007||Jun 4, 2009||Faucher Marc R||Method and system for implementing prioritized refresh of dram based cache|
|US20090144492 *||May 23, 2008||Jun 4, 2009||International Business Machines Corporation||Structure for implementing dynamic refresh protocols for dram based cache|
|US20090144503 *||Dec 4, 2007||Jun 4, 2009||Faucher Marc R||Method and system for integrating sram and dram architecture in set associative cache|
|US20090144504 *||May 7, 2008||Jun 4, 2009||International Business Machines Corporation||STRUCTURE FOR IMPLEMENTING REFRESHLESS SINGLE TRANSISTOR CELL eDRAM FOR HIGH PERFORMANCE MEMORY APPLICATIONS|
|US20090144506 *||Dec 4, 2007||Jun 4, 2009||Barth Jr John E||Method and system for implementing dynamic refresh protocols for dram based cache|
|US20090144507 *||Dec 4, 2007||Jun 4, 2009||International Business Machines Corporation||APPARATUS AND METHOD FOR IMPLEMENTING REFRESHLESS SINGLE TRANSISTOR CELL eDRAM FOR HIGH PERFORMANCE MEMORY APPLICATIONS|
|U.S. Classification||711/108, 711/E12.017, 711/E12.021|
|International Classification||G06F12/00, G06F12/08|
|Cooperative Classification||G06F2212/601, G06F12/0888, G06F12/0802|
|European Classification||G06F12/08B18, G06F12/08B|
|Apr 28, 2003||AS||Assignment|
Owner name: LSI LOGIC CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:EMERSON, STEVEN M.;SINGH, BELRAJ;REEL/FRAME:014017/0295;SIGNING DATES FROM 20030423 TO 20030424
|Nov 2, 2009||FPAY||Fee payment|
Year of fee payment: 4
|Oct 2, 2013||FPAY||Fee payment|
Year of fee payment: 8
|May 8, 2014||AS||Assignment|
Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AG
Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:LSI CORPORATION;AGERE SYSTEMS LLC;REEL/FRAME:032856/0031
Effective date: 20140506
|Jun 6, 2014||AS||Assignment|
Owner name: LSI CORPORATION, CALIFORNIA
Free format text: CHANGE OF NAME;ASSIGNOR:LSI LOGIC CORPORATION;REEL/FRAME:033102/0270
Effective date: 20070406
|Apr 3, 2015||AS||Assignment|
Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LSI CORPORATION;REEL/FRAME:035390/0388
Effective date: 20140814
|Feb 2, 2016||AS||Assignment|
Owner name: LSI CORPORATION, CALIFORNIA
Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039
Effective date: 20160201
Owner name: AGERE SYSTEMS LLC, PENNSYLVANIA
Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039
Effective date: 20160201
|Feb 11, 2016||AS||Assignment|
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH
Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001
Effective date: 20160201