intel-hard/intel-hard-lab
2
0 Fork 0
mirror of https://github.com/elwrcl/intel-hard-lab.git synced 2026-10-31 07:48:02 +03:00
Code Issues Packages Projects Releases Wiki Activity
Files
0bbe6b34e64751bc6f779829a9e5038cb0924844
intel-hard-lab/docs/ivb_2012/txt/ivb_ihd_os_vol1_part7.txt
T
elwrcl 0bbe6b34e6 first commit
2026-08-23 04:59:41 +03:00

3350 lines
201 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Intel® OpenSource HD Graphics
Programmer’s Reference Manual (PRM)
Volume 1 Part 7: L3$/URB
(Ivy Bridge)
For the 2012 Intel® Core™ Processor Family
May 2012
Revision 1.0
NOTICE:
This document contains information on products in the design phase of development, and Intel
reserves the right to add or remove product features at any time, with or without changes to this
open source documentation.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12
Creative Commons License
You are free to Share — to copy, distribute, display, and perform the work
Under the following conditions:
Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any
way that suggests that they endorse you or your use of the work).
No Derivative Works. You may not alter, transform, or build upon this work.
®
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO
LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL
PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S
TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY
WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO
SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO
FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY
PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly
or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR
ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS
SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND
EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES
AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM
OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH
MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS
NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY
OF ITS PARTS.
Intel may make changes to specifications and product descriptions at any time, without notice. Designers
must not rely on the absence or characteristics of any features or instructions marked "reserved" or
"undefined". Intel reserves these for future definition and shall have no responsibility whatsoever for
conflicts or incompatibilities arising from future changes to them. The information here is subject to
change without notice. Do not finalize a design with this information.
The products described in this document may contain design defects or errors known as errata which
may cause the product to deviate from published specifications. Current characterized errata are
available on request.
Implementations of the I2C bus/protocol may require licenses from various entities, including Philips
Electronics N.V. and North American Philips Corporation.
Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries.
*Other names and brands may be claimed as the property of others.
Copyright © 2012, Intel Corporation. All rights reserved.
2 5/29/2012 Doc Ref #: IHD-OS-V1 Pt 7 – 05 12
Contents
1. L3$/URB.................................................................................................................................................. 5
1.1 Overview .............................................................................................................................................. 5
1.2 L3$ Cache Configuration ..................................................................................................................... 5
1.3 Memory Object Control State on Cacheability ..................................................................................... 6
2. Atomics .................................................................................................................................................. 7
2.1 Atomics in L3 ........................................................................................................................................ 8
2.2 Atomics in SLM .................................................................................................................................... 9
2.3 Atomics in URB .................................................................................................................................... 9
3. L3 Allocation and Programming ........................................................................................................ 10
3.1 Non-SLM mode Allocation ................................................................................................................. 10
3.2 SLM mode Allocation ......................................................................................................................... 11
4. L3 Invalidation and Flush Flows ........................................................................................................ 12
4.1 Read Only Stream Invalidations ........................................................................................................ 12
4.2 Pipelined Flush for Writes .................................................................................................................. 13
4.3 Global Invalidation .............................................................................................................................. 14
5. Shared Local Memory (SLM) .............................................................................................................. 15
5.1 Protocol .............................................................................................................................................. 15
6. Control Field Definition ....................................................................................................................... 17
7. Dynamic Parity Feature for GFX L3 Cache ....................................................................................... 18
7.1 Feature Definition ............................................................................................................................... 18
7.2 Hardware and Software Flows ........................................................................................................... 18
7.2.1 Parity Generation & Detection ...................................................................................................... 18
7.2.2 Correction Using Parity Error data and Redundant Rows ............................................................ 18
7.2.3 Number of Corrections ................................................................................................................. 19
7.2.4 Summary ...................................................................................................................................... 19
7.2.5 Sub-banks with more than two persistent parity error rows ......................................................... 19
7.2.6 Interrupt Enabling ......................................................................................................................... 20
7.2.7 Clearing the Error Reporting Registers ........................................................................................ 20
7.3 Hardware Registers ........................................................................................................................... 20
7.3.1 Error Report Registers .................................................................................................................. 20
7.3.2 Row Replacement Registers ........................................................................................................ 22
8. L3 Register Space (Bspec) ................................................................................................................. 23
8.1 config space for L3 ............................................................................................................................. 23
8.1.1 SARERRST - SARB Error Status ................................................................................................. 24
8.1.2 L3CDERRST2 - L3CD Error Status register 2 ............................................................................. 25
8.1.3 L3SQCREG1 - L3 SQC registers 1 .............................................................................................. 26
8.1.4 L3SQCREG2 - L3 SQC registers 2 .............................................................................................. 30
8.1.5 L3SQCREG3 - L3 SQC registers 3 .............................................................................................. 32
8.1.6 L3CNTLREG1 - L3 Control Register1 .......................................................................................... 36
8.1.7 L3CNTLREG2 - L3 Control Register2 .......................................................................................... 38
8.1.8 L3CNTLREG3 - L3 Control Register3 .......................................................................................... 40
8.1.9 L3SLMREG - L3 SLM Register .................................................................................................... 41
8.1.10 GARBCNTLREG - Arbiter Control Register ............................................................................... 42
8.1.11 L3SQCREG4 - L3 SQC register 4 .............................................................................................. 44
8.1.12 SCRATCH1 - SCRATCH1.......................................................................................................... 45
8.1.13 L3B0REG1 - L3 bank0 reg1 log error ......................................................................................... 46
8.1.14 L3B0REG2 - L3 bank0 reg2 log error ......................................................................................... 47
8.1.15 L3B0REG3 - L3 bank0 reg3 log error ......................................................................................... 48
8.1.16 L3B0REG4 - L3 bank0 reg4 log error ......................................................................................... 49
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 3
8.1.17 L3B0REG5 - L3 bank0 reg5 log error ......................................................................................... 50
8.1.18 L3B0REG6 - L3 bank0 reg6 log error ......................................................................................... 51
8.1.19 L3B0REG7 - L3 bank0 reg7 log error ......................................................................................... 52
8.1.20 L3B1REG0 - L3 bank1 reg0 log error ......................................................................................... 53
8.1.21 L3B1REG1 - L3 bank1 reg1 log error ......................................................................................... 54
8.1.22 L3B1REG2 - L3 bank1 reg2 log error ......................................................................................... 55
8.1.23 L3B1REG3 - L3 bank1 reg3 log error ......................................................................................... 56
8.1.24 L3B1REG4 - L3 bank1 reg4 log error ......................................................................................... 57
8.1.25 L3B1REG5 - L3 bank1 reg5 log error ......................................................................................... 58
8.1.26 L3B1REG6 - L3 bank1 reg6 log error ......................................................................................... 59
8.1.27 L3B1REG7 - L3 bank1 reg7 log error ......................................................................................... 60
8.1.28 L3B2REG0 - L3 bank2 reg0 log error ......................................................................................... 61
8.1.29 L3B2REG1 - L3 bank2 reg1 log error ......................................................................................... 62
8.1.30 L3B2REG2 - L3 bank2 reg2 log error ......................................................................................... 63
8.1.31 L3B2REG3 - L3 bank2 reg3 log error ......................................................................................... 64
8.1.32 L3B2REG4 - L3 bank2 reg4 log error ......................................................................................... 65
8.1.33 L3B2REG5 - L3 bank2 reg5 log error ......................................................................................... 66
8.1.34 L3B2REG6 - L3 bank2 reg6 log error ......................................................................................... 67
8.1.35 L3B2REG7 - L3 bank2 reg7 log error ......................................................................................... 68
8.1.36 L3B3REG0 - L3 bank3 reg0 log error ......................................................................................... 69
8.1.37 L3B3REG1 - L3 bank3 reg1 log error ......................................................................................... 70
8.1.38 L3B3REG2 - L3 bank3 reg2 log error ......................................................................................... 71
8.1.39 L3B3REG3 - L3 bank3 reg3 log error ......................................................................................... 72
8.1.40 L3B3REG4 - L3 bank3 reg4 log error ......................................................................................... 73
8.1.41 L3B3REG5 - L3 bank3 reg5 log error ......................................................................................... 74
8.1.42 L3B3REG6 - L3 bank3 reg6 log error ......................................................................................... 75
8.1.43 L3B3REG7 - L3 bank3 reg7 log error ......................................................................................... 76
8.1.44 SARBCSR - SARB config save msg .......................................................................................... 77
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 4
1. L3$/URB
1.1 Overview
GFX L3 cache is introduced for GFX core as a large storage which backs up various L2/L1 caches on
many clients. It provides a simple way based partitioning option for each or a cluster of clients to get a
dedicated chunk of the cache. It also acts as a GFX URB and can be configured as highly banked
memory for EUs/ROWs.
In order to provide the bandwidth needed L3 has been separated into 4x128KB structures which can be
accessed concurrently. A 2x clocking is introduced to further enhance the bandwidth and cover the
limitations of SRAM (6T) design.
 Formed as 4 (2 for GT1) individual banks each with 128KB in size
 Each logical bank consists of
o Data Array
o Tag Array
o LRU Array (implements a Pseudo Least Recently Used algorithm)
o State Array
o SuperQ Data Buffer
o Atomic Processing Unit
 The rest of the support logic around L3 are
o SuperQ (main scheduler)
o Ingress/Egress queues to L3/SQ (L3 arbiter)
o CAM structures to maintain coherency.
o Crossbars for data routing
 Use of 2x/1x clocking
 L3 operates in GFX coherent domain
 A portion of L3 can be allocated as highly banked memory
1.2 L3$ Cache Configuration
 4x128KB cache, 64 logical ways
 64B Cacheline with a portion capable of highly banked memory (with 16x4B
capability)
 Interface 64B to SQDB for the fill/write path, 64B Read/Evict path to SQDB
 Data Array built via 6T cells
o Data protection via parity
 TAG/LRU/STATE (using gen-ram via RLS flows)
o 32-bit GFX addressing support in TAG
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 5
o 2 bit state
o Intel pseudo-LRU implementation for selecting the line to be replaced
 Repetition rates for each operation
o All operations – 1 every 2x clock
 With b2b restriction for same type of accesses (i.e. read to read or
write to write)
1.3 Memory Object Control State on Cacheability
This 4-bit field is used in various state commands and indirect state objects to define MLC/LLC
cacheability, graphics data type for memory objects.
Bit Description
3 Reserved
2
Graphics Data Type (GFDT)
This field contains the GFDT bit for this surface when writes occur. GFDT can also be set by the
GTT. The effective GFDT is the logical OR of this field with the GFDT from the GTT entry. This
field is ignored for reads.
The GFDT bit is stored in the LLC and selective cache flushing of lines with GFDT set is
supported. It is intended to be set on displayable data, which enables efficient flushing of data to
be displayed after rendering, since display engine does not snoop the rendering caches.
Format = U1
1
LLC Cacheability Control (LLCCC)
This is the field used in GT interface block to determine what type of access need to be
generated to uncore. For the cases where the LLCCC is set, cacheable transaction are
generated to enable LLC usage for particular stream.
0: use cacheability controls from GTT entry
1: Data is cached in LLC
0
L3 Cacheability Control (L3CC)
This field is used to control the L3 cacheability (allocation) of the stream.
0: not cacheable within L3
1: cacheable in L3
Note: even if the surface is not cacheable in L3, it is still kept coherent with L3 content.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 6
2. Atomics
An atomic operation may involve both reading from and then writing to a memory location. Atomic
operations apply only to either u# (Unordered Access Views) or g# (Thread Group Shared Memory). It is
guaranteed that when a thread issues an atomic operation on a memory address, no write to the same
address from outside the current atomic operation by any thread can occur between the atomic read and
write.
If multiple atomic operations from different threads target the same address, the operations are serialized
in an undefined order. This serialization happens outside of the L3 control logic.
Atomic operations do not imply a memory or thread fence. If the program author/compiler does not make
appropriate use of fences, it is not guaranteed that all threads see the result of any given memory
operation at the same time, or in any particular order with respect to updates to other memory addresses.
Atomicity is implemented at 32-bit granularity. If a load or store operation spans more than 32-bits, the
individual 32-bit operations are atomic, but not the whole.
Limitation: Atomic operations on Thread Group Shared Memory are atomic with respect to other atomic
operations, as well as operations that only perform reads (“load”s). However atomic operations on Thread
Group Shared Memory are NOT atomic with respect to operations that perform only writes (“store”s) to
memory. Mixing of atomics and stores on the same Thread Group Shared Memory address without
thread synchronization and memory fencing between them produces undefined results at the address
involved. This limitation arises because some implementations of loads and stores do not honor the
locking semantics for implementing atomics. It turns out this has no impact on loads, since they are
guaranteed to retrieve a value either before or after an atomic (they will not retrieve partially updated
values, given they are all defined at 32-bit quanta). However store operations could find their way into the
middle of an atomic operation and thus have their effect possibly lost.
In L3 or SLM, the atomic operation leads to a read-modify-write operation on the destination location with
the option of returning value back to requester. The table below is defined as a list of atomic operations
needed:
Atomic Description New Return Value
Operation Destination (optional)
Value
Atomic_AND Single component 32-bit bitwise AND of operand src0 “old_dst” AND old_dst
into dst at 32-bit per component address dstAddress, “src0”
performed atomically.
Atomic_OR Single component 32-bit bitwise OR of operand src0 “old_dst” OR old_dst
into dst at 32-bit per component address dstAddress, “src0”
performed atomically.
Atomic_XOR Single component 32-bit bitwise XOR of operand src0 “old_dst” XOR old_dst
into dst at 32-bit per component address dstAddress, “src0”
performed atomically.
Atomic_MOVE Replacement of the dst with src0. “src0” old_dst
Atomic_INC Single component 32-bit integer increment of dst back “old_dst + 1” old_dst
into dst
Atomic_DEC Single component 32-bit integer decrement of dst back “old_dst - 1” old_dst
into dst
Atomic_ADD Single component 32-bit integer add of operand src0 “old_dst +
old_dst
into dst at 32-bit per component address src0”
performed atomically. Insensitive to sign
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 7
Atomic Description New Return Value
Operation Destination (optional)
Value
Atomic_SUB Single component 32-bit integer subtraction of operand “old_dst - src0”
old_dst
src0 into dst at 32-bit per component address
performed atomically. Insensitive to sign
Atomic_RSUB Single component 32-bit integer subtraction of operand “src0 - old_dst”
old_dst
dst from src0 into dst at 32-bit per component
address performed atomically. Insensitive to
sign
Atomic_IMAX Single component 32-bit signed MAX of operand src0 IMAX (old_dst, old_dst
into dst at 32-bit per component address dstAddress, src0)
performed atomically.
Atomic_IMIN Single component 32-bit signed MIN of operand src0 IMIN (old_dst, old_dst
into dst at 32-bit per component address dstAddress, src0)
performed atomically.
Atomic_UMAX Single component 32-bit unsigned MAX of operand UMAX old_dst
src0 into dst at 32-bit per component address (old_dst, src0)
dstAddress, performed atomically.
Atomic_UMIN Single component 32-bit unsigned MIN of operand src0 UMIN (old_dst, old_dst
into dst at 32-bit per component address dstAddress, src0)
performed atomically.
Atomic_CMP/WR old_dst
Single component 32-bit value compare of operand (src0 ==
src0 with dst at 32-bit per component address old_dst)?
dstAddress
src1:
If the compared values are identical, the single-
old_dst
component 32-bit value in src1 is written to destination
memory, else the destination is not changed
The entire compare+write operation is performed
atomically
Atomic_PREDEC Single component 32-bit integer decrement of dst back “old_dst - 1” new_dst
into dst
Atomics for unstructured data types will take place in L3each via a single DW atomics engine. Each L3
bank will have 2 independent atomics engines, one for L3 and one for SLM. Both L3 or SLM atomic
requests are going to be reduced to a single index (1 DW) request by DC before getting pushed to L3. In
L3, a single 32bit atomics engine is suffice to service DC requests.
The DC request for atomic will have the proper DW only byte enables set for the 32 bit of interest. The
address down to bit[2] (dword address) will also be provided to point to correct DW out of 16 lanes in
64Bytes.
The processing of atomics will follow 2 separate pipelines of operation (either SLM or L3) depending on
the destination of the access.
2.1 Atomics in L3
Atomics in L3 are handled separately in each bank, to achieve this function 2 Atomics blocks are
instantiated along with each bank. Each operand being moved to SQ also moves its data (up to 2 DWs)
into an assigned atomics block to be used later on (when he destination data is available).
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 8
A separate credit is given to L3 arbiter for atomics, once an atomic request is moved from L3 arbiter to
SQ – both the SQ credits and Atomics credits need to be deducted to regulate the number of atomic
requests in SQ. For GT2, this process allows upto 8 atomics to be performed in a given clock.
The request interface allows only 1 DW of atomics per request, data from DC will be given on DW0 (also
in DW1 if src1 is given) for all atomic operations regardless of the address of byte enables. Cacheline
address will be provided on the interface with proper Byte Enables singling the DW location of the
destination.
If final data is returned to client (optional), the DW of interest will be given in the same position pointed out
by byte enables (in fact the same DW will be replicated over 16 positions).
2.2 Atomics in SLM
SLM pipeline has a mechanism to handle atomics similar to L3/URB pipeline. There is only 1 ALU per
SLM bank. The protocol between DC and L3 allows one atomics to be performed at a given time, the
SLM controller will stall the interface if needed. Per atomics request from the DC, only ONE DW can be
active on one SLM bank. SLM pipeline can execute b2b atomics request (1 every 1x clock) as long as
b2b operations do not conflict on the same bank. If conflict is detected a single clock of bubble is inserted
into pipeline in order to update the corresponding bank with SLM output before next operation can be
performed (see SLM pipeline details)
Data from DC will be always given on DW0 and DW (if needed) and VALIDs will point to the bank of
interest out of 16 banks of SLM. Correct set of byte enables should be provided which is active for the
valid bank.
DW of interest is returned to DC on the byte enable corresponding lane of the cacheline.
2.3 Atomics in URB
Simple atomics are possible to be processed for URB locations as well. The process should fall out from
the L3 path of the atomics and is restricted similar to L3 atomics.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 9
3. L3 Allocation and Programming
L3 Cache allocation is done on a per way basis which should be consistent across all 4 banks (2 banks
for GT1). The way allocation between URB and any of the L3 clients can only be changed post pipeline
flush where L3 contains no data. This is required for stream based flushes to be dependent on the way
allocation of these corresponding streams. S/W should not be removing ways under a particular stream
and expect a later pipelined stream flush to target all the corresponding locations. The stream based flush
will be performed on the existing way allocation of that stream, there is no history of previous way
allocation tracked in the hardware.
L3 Cache has been divided into following client pools:
 Shared Local Memory: When enabled its size is always fixed to 128KB (64KB for
GT1)
 URB: Local memory space, provides a flexible allocation on per 8KB granularity
 DC: Data Cluster Data type
 Inst/State: Both instructions and state allocation is combined
 Constants: Pull constants for EUs
 Textures: texture allocation to back-up L2$
In addition to these sub-groups, a collection of groups are generated to bundle multiple clients under the
same allocation set:
 All L3 Clients: DC, Inst/State, Constants & Textures
 Read-Only Clients: Inst/State, Constants & Textures
Each of the L3 way allocations are managed via pLRU, hence best performance can be attained via
assigning a power-of-2 number of ways. This is to ensure pLRU to distribute the ways w/o hot spotting
within that client’s group. Even though design provides a flexible (per way basis) programming model for
way allocation for each client following table is given for validation and s/w programming models. The
programming options in the following table represents most likely cases for different operation modes.
For GT1, hardware will retain 2 of the L3 banks hence all following allocations will be reduced half the
size.
3.1 Non-SLM mode Allocation
Normal L3/URB mode (non-SLM mode), uses all 4 banks of L3 equally to distribute cycles. The following
allocation is a suggested programming model. Note all numbers below are given in KBytes.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 10
3.2 SLM mode Allocation
With the existence of Shared Local Memory, a 64KB chunk from each of the 2 L3 banks will be reserved
for SLM usage. The remaining cache space is divided between the remaining clients. SLM allocation is
done via reducing the number of ways on the two banks from 64 to 32.
Given the reduction on the 2 banks for L3, we have a unique problem of how to manage HASH between
4 un-equal size banks. The way to address that issue is to identify “Low Bandwidth” clients and allocate
them into un-even ways of the large banks and handle them via a 2-way HASH. The remaining clients are
allocated between 4 banks with the equal number of ways on each bank. The shaded clients in
corresponding table are supposed to correspond to low bandwidth clients and their total should be
128KB.
Note that, having mixture of 2 hashes need to ensure “there are no coherency requirements between the
high b/w and low b/w clients”. This solution prevents any producer/consumer models cross groups within
L3. When programming the low b/w vs high b/w client profile, the need for coherency with the L3 fabric
has to be considered.
Note that URB needs to be set as low b/w client in SLM mode, else the hash will fail. This is a required
s/w model.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 11
4. L3 Invalidation and Flush Flows
In, L3 fabric will support two different invalidation/flush flows. One for Read only streams and it could be
per stream basis and the other one is the pipelined flush for modified lines in L3.
4.1 Read Only Stream Invalidations
All read-only stream invalidations are done at the TOP of the pipe and communicated to L3 fabric directly
from the main command streamer. Once send to L3, command streamer can kick off the next workload to
re-use the same memory space. There are four type streams that can be covered individually or
overlapped:
 Texture Invalidation
 Instruction Invalidation
 Constant Invalidation
 State Invalidation
For all types of invalidations the flows are the same from L3 arbiter perspective: first invalidation will
directly come from the command streamer and the “state invalidation” is sent via state arbiter unit.
L3 arbiter will propagate the invalidation only after the corresponding streams’ requests are retired to
superQs. Once a particular invalidation is received, L3 arbiter will put a marker where all the existing
requests from that stream. This will allow the already existing requests to be sent to superQ while
accepting new requests, however new requests should never be sent to SuperQ until the existing
invalidation is complete. Once all existing (marked requests) moved to SQ, L3 arbiter will propagate the
invalidation request to SuperQ and keep the corresponding ingress FIFOs blocked.
Note: There may be two sources of the corresponding stream (i.e. Textures from either half-slice
arbiters…). L3 arbiter needs to ensure both streams are serviced before propagating the “invalidation to
SuperQ”.
Once SuperQ receives the invalidation, it will start monitoring particular streams transactions that could
be still in SuperQ and wait for them to retire. If there is no such requests, this process would be
immediate. The invalidation will be forwarded to L3 as SuperQ ensures there is no more requests in its
slots with the matching clientID assignment.
Once L3 cache receives the invalidation, it is guaranteed that none of its requests in the TAG pipeline
belongs to OLD marked requests from the stream getting the invalidation. SuperQ already guarantees
this process by waiting for the retirement of the marked requests. TAG pipeline controller will stall the
operations and wait for the TAG pipeline to clear than send the indication to STATE Array controller. For
the ways that are corresponding to invalidation type, all ways for matching stream type will be updated in
one shot. Once invalidation is complete, each L3 bank will send the indication to Pixel Arbiter (GAP). Note
that multiple invalidations will be serialized in L3.
GAP will collect all invalidation requests from 4 banks (2 banks for GT1) and make sure all are complete
before sending this completion back to corresponding L3 arbiters. L3 arbiters will ungate the ingress
FIFOs of the completed invalidation as they complete the last step required.
This is exception part of the Read-Only Stream invalidations where state arbiter needs to stop sending
new requests to L3 arbiters and ensure all pre-committed requests already sent to L3 arbiters:
 Stop and discard any prefetch requests that may be ongoing
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 12
 Finish any state requests with the length fields.
Once above conditions are satisfied the “state invalidation” will be forwarded to L3 arbiters and state
arbiter will stop sending processing any other state requests while processing the invalidation. The
ingress FIFOs will be kept blocked towards the arbiter until L3 arbiters send an indicator (all 4 of them) to
state arbiter for the completion of the state invalidation. Note that this is an extra step for L3 arbiters only
for the case of state invalidation within Read-Only streams.
Note that state arbiter needs to accumulate any new state requests that falls behind the invalidation event
and not process them until the state invalidation complete indicator is seen from GAP. It needs to ensure
old state data is cleared before sending the new state requests from clients.
There is a possibility where multiple invalidations could exist for a given stream. This is where L3 arbiters
need to co-ordinate the when the invalidation requests would be processed. As L3 arbiter receives a
particular invalidation to the time response is received from GAP, there could be yet another invalidation
for the same stream. However since the ingress FIFOs are blocked, new invalidation request should not
be processed before the prior request is complete. When L3 arbiter receives the completion from GAP, it
will start processing the new invalidation as if it was received right at the same cycle.
Same rules apply for state arbiter as well where while the completion for a prior invalidation is pending,
there may be another invalidation request from the main command streamer. State arbiter will hold off the
execution of the newer invalidation until the completions are seen from the L3 arbiters.
Note that there could be third, forth invalidations while the very invalidation is being processed. All
invalidations for a given stream could be collapsed while the prior one is being processed.
4.2 Pipelined Flush for Writes
Pipelined flush for data cluster writes will be propagated from DC directly to L3 arbiters as their buffers
are flushed. L3 arbiters will be getting a flush indicator from each DC independently, there is no point of
acting on the first flush indicator, it is easier to wait for both DCs to send their flush request and process
them together. Once both flush indicators are seen, L3 arbiter will flush all its ingress FIFOs and block
outlet of them being processed. L3 arbiter should not be sending any other requests to SuperQs until a
completion is seen.
SuperQ as a response to Write Flush will wait for all its slots to retire, this is to prevent any boundary
cases and ensure all writes are retired to L3 (if any). Once emptied, SQ will start accumulating “Flush”
requests to the defined sets and ways (defined as data cluster reserved ways) and walk through each
entry of the L3. These flush requests are to invalidate and evict any modified lines that may be present in
L3s.
After all defined ways are walked with FLUSH requests, SuperQ should wait for empty indicator once
again. This is to make sure all evicted data is retired towards GAP.
As GAP receives the flush complete indicator from each bank of L3 (4 for GT2 and 2 for GT1), it will
ensure the eviction path is retired towards GAM, Once all done, it will send an indicator to PSD units in
each half-slice. Same signal will be received by all L3 arbiters and used to un-block their interfaces
towards SuperQ.
Note that SuperQ should not release any credits to L3 arbiter when retiring an internally generated flush
request.
Similar to RO invalidations, the status of the write flush can also be tracked via register space. The
indication of each bank will be reported via its corresponding L3 arbiter to a register space.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 13
4.3 Global Invalidation
Once written a global indicator will be sent to L3 arbiters and state arbiter which will kick-off all
invalidations at once. The same register space will collect all completion from L3 arbiters and state arbiter
to clear the same bit.
Register bit can be polled by s/w to track to completion of all invalidations.
Default
Bit Access Value Description
0 RW/C 0 L3 Global Invalidations: Once written it will kick off a global invalidation for L3
both on RO and WR streams. S/W is expected to write logic1 to kick-off the
invalidation and H/W will clear the bit once all invalidations are complete.
Meanwhile S/W can poll the bit to track the completion of invalidation.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 14
5. Shared Local Memory (SLM)
Shared local memory (aka highly-banked memory) is a portion of L3 which will be dedicated to EUs as a
local memory when enabled. The accesses are only possible through data cluster with the destination
flag set as SLM. In order to support a highly banked design, 2 of the L3 banks are structured to have
16x4KB portion which could be accessed independently per clock. This part of the L3 can support 16 dw
size accesses (per SLM) in a given clock cycle.
These 16 banks can either be used as L3/URB or used as shared local memory with parallel accesses to
all banks. The choice of enabling SLM mode is done through MMIO programming
Default
Bit Access Value Description
0 RW/C 0 Enable Shared Local Memory: When set, it enables the use of 2 banks of L3 as
shared local memory which allows 64KB of L3 to be banked as 16x4KB and
allows independent accesses to all banks within the same clock cycle.
Note: This mode can only be enabled once L3 content is completely flushed.
In, SLM is structured as 64KB per half slice (6 EUs) and each 64KB allow up to 16 accesses to a
particular 4KB bank. Each 4KB bank is addressed separately where their requests are placed on a 160bit
address bus where each 10-bit correspond to a bank sequentially. Each bank gets addressed with 10bits
and provides 4B access with a total of 4KB per bank. When SLM mode is not enabled, SLM banks are
considered a part of L3 and used for cache or URB.
SLM requests are forked around the L3 arbiter, post ingress FIFOs for DC. L3 arbiter delivers
request/data to SLM controller upon the availability of credits. Request will be crossed to 2x clock domain
routed to corresponding banks. Individual bank controls are managed via SLM controller which are
muxed with L3/URB accesses. Note that SLM accesses do carry byte enables and needs to be honored
towards the banks. If the request has atomic requirements, SLM controller will provide the data to ALU
along with the atomic type. Output data is again managed with SLM controller towards the output cross
bars.
5.1 Protocol
The interface to access the Shared Local Memory is very similar to DC accesses to L3/URB with some
additional fields:
 Bank Valids: A 16bit vector that points to which request in each bank’s lane being
active. DC is required to set the corresponding valid bit to perform a read or write
operation for a corresponding bank.
 Bank DW offsets: 10-bit address is provided per bank basis. Each bank can be
accessed with a different address within the same clock cycle
 Byte Enables could be set for any format or combination
The protocol also restricts some of the capabilities
 In a given clock cycle same type of command have to be used for all banks. This
allows to read or write but not to combine different cycle operation within the same
clock.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 15
 Only 1 valid could be set if the SLM access requires atomics.
 In case of atomics, the data is provided always on the lower DW lanes (src0=DW0
and src1=DW1). The read return from SLM will have the DW of interest in the
natural aligned location within 64B
SLM requests are routed through the same L3/URB arbiter using the protocol credits that are available
between DC and L3, however right after the ingress queues SLM packets are routed to SLM controller
w/o going through the arbitration.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 16
6. Control Field Definition
For the state control fields are re-defined to comprehend L3 addition as following:
Bit[2] GFDT GFDT flag to color the displayable surfaces in LLC. This field is later used by GT
to poll the LLC during query/flush mechanism and used to push the data to
DRAM prior to Display Accesses
Bit[1:0] Cacheability
Control for LLC and L3 cacheabiltiy fields
Controls
Bit[1]: LLC cacheability
Bit[0]: L3 cacehability
0: Access is NOT cacheable
1: Access is cacheable
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 17
7. Dynamic Parity Feature for GFX L3
Cache
This document is meant to outline and describe dynamic parity detection function in the graphics L3
cache.
7.1 Feature Definition
The concept of DPF is to provide a run-time protection for graphics L3 cache via parity detection and
redundant rows. Parity errors are considered to be an extremely rare occurrence, but this mechanism
provides a means to address them should they occur.
In order to mitigate error detection needs of graphics L3 cache, parity detection capability has been
added to each sub-bank of the L3. A sub-bank is defined as a 16KB entity of the total 512KB cache. This
would translate into 32 independent sub-banks which all have 2 independent redundant rows for a total of
64 possible replacement rows. Redundant rows can be activated to replace a row with identified parity
errors via writing the address of the parity error row into hardware registers.
DPF allows the HW to notify SW (driver) when any single bit graphics L3 parity error has occurred and
also provide a mechanism to allow SW to fix persistent bit errors where a susceptible bit fails multiple
times.
In order to support robust GPGPU / compute workloads on graphics, Intel recommends that driver
developers implement this suggested DPF flow. Regardless, all usages of the graphics L3 cache can
benefit from the added parity protection.
7.2 Hardware and Software Flows
7.2.1 Parity Generation & Detection
The graphics L3 cache will generate 1-bit parity as data is stored in the cache. The parity bit will be
written along with data for future verification. As the same content is accessed later in time, HW re-
calculates the parity based on read content and compares with the stored parity value.
Once a mismatch is detected, HW generates a parity interrupt for the graphics driver to service.
Meanwhile, HW continues forward progress in execution. There is no implicit halt or execution stopping
for the IVB / Gen7 HW.
Along with the interrupt, the HW will update a set of registers to indicate which bank/sub-bank/row in
which the error has been detected.
7.2.2 Correction Using Parity Error data and Redundant Rows
Each sub-bank contains 2 redundant rows which could be used to replace the rows with reported parity
errors. The graphics driver, once servicing the parity interrupt, will access the reporting registers and
record the bank/sub-bank/row information. This information should be stored in a permanent (non-volatile
memory: ie: disk, registry or similar) location for future use by the graphics driver.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 18
The graphics driver will then reset the render engine (i.e. render specific reset) to prevent propagation of
the data with the parity error. Even though the graphics driver will terminate the context via resetting the
GPU upon a parity interrupt, there is a possibility that the parity interrupt may be observed by the driver
after the graphics context is complete or about to switch to a new context. For non-graphics workloads
that require high data integrity, such as GPGPU computing, the driver should prevent this possible
boundary case by polling the error reporting registers when a context completion or context switch
interrupt is registered by the driver. Upon identifying that the error reporting registers are active, the driver
should follow the same steps as servicing a parity interrupt.
Post any reset event (graphics reset, power up, etc..), the graphics driver retrieve the parity failure row
information from non-volatile storage. It will then program the parity failure row information into
corresponding bank/sub-bank registers and start normal graphics operation. Parity failure rows would
then be effectively replaced with the extra redundant rows until next system reset.
In the extremely rare probability that redundant rows themselves have a parity errors, the parity error will
be reported as the row they have replaced. SW drivers should recognize the use of redundant row and
skip the replacement.
7.2.3 Number of Corrections
Given DPF is designed to deal with persistent errors, graphics drivers need to be able to identify which
sub-bank rows are producing the most number of errors. Hence, the driver should keep a list of the
reported parity error rows and record the number of times each row reports a parity error. If there are
more than 2 parity error rows identified for a given sub-bank, the driver should replace the top two rows
first (decided by historical error count). This will force rows with consistent parity errors to bubble up to the
top of the list to be replaced.
SW driver tracking of parity error rows should be saved in non-volatile memory, so the driver can keep
track of parity failure rows across reboot/reset.
7.2.4 Summary
Basic Algorithm:
 Each sub-bank has two redundant rows. (By HW design)
 Driver SW keeps track of each sub-bank’s parity failure rows and keeps a count of failures of each
row.
 Error count row information is saved to non-volatile memory, so it persists across reboot and
graphics resets.
 At all times, the two redundant sub-bank rows are used to replace the highest count parity failure
rows.
 SW always forces reset (graphics render reset is sufficient) on L3 errors.
 SW programs all necessary replacement rows after any reset.
7.2.5 Sub-banks with more than two persistent parity error rows
While not expected during normal lifetime operation, a problematic case could occur when the HW
reports more than 2 rows on a particular sub-bank are causing parity errors. For this case, the graphics
driver should keep replacing the rows, always selecting the two rows with the highest parity error failure
count.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 19
7.2.6 Interrupt Enabling
In order to enable proper DPF notification, the graphics driver must enable the correct interrupt paths
from render command streamer (x20A8) as well as rest of the interrupt structures around GTISR
(x44010), GTIMR (x44014), GTIIR (x44018), GTIER (x4401C). Bit5 has been selected for L3 parity
interrupts. Please refer to the appropriate register sections for generic graphics interrupt enabling details.
7.2.7 Clearing the Error Reporting Registers
Clearing error status registers for the L3 cache should be done by writing to L3CD Error Status Register
bit[13] with a logical value of “1”. This should be done after an error is reported and a row has been
replaced. The graphics driver can do this in two different ways:
1. Via batch buffer executed in HW (via LRI or LRM mechanisms)
2. Direct writes to graphics HW MMIO space
Direct reads and writes using graphics MMIO (for both error log and status registers) requires DOP level
clock gating to be turned off as HW might have finished execution, which will result in a hang when
accessing the L3 parity registers. This requires graphics MISCCPCTL bit 0 (x9424[0]) to be cleared prior
to register updates. It must be set again post register updates. Do not leave the DOP clock gating bit
cleared. Doing so will significantly affect graphics power.
Note that the HW parity registers will clear with any reset, hence error and row replacement registers will
have to be re-programmed any time the driver performs a HW reset or driver is re-loaded.
7.3 Hardware Registers
Various registers are used to report and contain the parity error failing row information:
7.3.1 Error Report Registers
This is the lead section for this topic and will be updated over time with introductory comments and links
to related information.
Use the “Next Topic” (right arrow) button above to proceed to the first detail section.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 20
7.3.1.1 L3CDERRST1 - L3CD Error Status register 1
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B008-B00Bh
Default Value: 00000000h
Access: RW; RO; WO;
Size: 32 bits
Bit Access Default RST/PWR Description
Value
31:25 RO 0000000b Core
Reserved (RSVD):
Reserved
24:14 RWC 00000000000b Core
Parity row address error (PRTYROWNUM):
Data array address which has parity B1:
Report the data array address which has the Error
ltcd_sarb_parity_err_rownum[10:0]
Once set by HW, it can be cleared only by MMIO Write of 1 to this register
bit 13 .
13 RWC 0b Core
Parity Error Valid (PRTYERRVLD):
Parity Error valid
Report the Parity Error
ltcd_sarb_parity_err_valid
Once set by HW, it can be cleared only by MMIO Write of 1 to this register
bit 13 .
12:11 RWC 00b Core
Parity error bank number (PRTYBNKNUM):
bank number which has parity error
Report the bank no. which has the Error
ltcd_sarb_parity_err_banknum[1:0]
Once set by HW, it can be cleared only by MMIO Write of 1 to this register
bit 13 .
10:8 RWC 000b Core
Parity Error sub-bank no (PRTYSBNKNUM):
Parity Error in sub bank:
ltcd0_sarb_parity_err_subanknum[2:0]
Once set by HW, it can be cleared only by MMIO Write of 1 to this register
bit 13 .
7 RW 1b Core
Parity report enable (LCPRTYRPTEN):
sarbcf_csr_lc_parity_report_en
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 21
this is the parity reporting enable, by default it is enabled.
When enabled parity will be reported by ltcd to sarb.
When disabled by driver, ltcd should not send out any parity error to
SARB.
6:0 RO 00h Core Reserved (RSVD):
7.3.2 Row Replacement Registers
The range of row replacement registers is addresses xB070 (bank0/sub-bank0) to xB0EC (bank3/sub-
bank7). Only the first register format is given below - all registers have the same format.
7.3.2.1 L3B0REG0 - L3 bank0 reg0 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B070-B073h
Default Value: 00000000h
Access: RW; RO
Size: 32 bits
The log error registers of the L3 will maintain the bad row information for each of the 16KB sub-bank
groups. The log should be programmed by the driver before any workloads are submitted if it is
necessary to replace parity failing rows. The contents of the log register are included in any context save
and restore by HW for RC6 power events.
All L3 error registers are put as part of HW context which could lead the same error to be reported
multiple times (i.e. when context gets reloaded).
Bit Access Default RST/PWR Description
Value
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has
been detected. The number of rows vary between 4K vs 8K/16K subbanks
which requires 10bits vs 11bits respectively. This field contains the row# with
the error.
20:17 RO 0000b Core Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical
16KB group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has
been detected. The number of rows vary between 4K vs 8K/16K subbanks
which requires 10bits vs 11bits respectively. This field contains the row# with
the error.
4:1 RO 0000b Core Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical
16KB group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 22
8. L3 Register Space (Bspec)
8.1 config space for L3
Register Name Register Symbol Register Start Register End Default Value Access
SARB Error Status SARERRST B004 B007 00000000h RO;
L3CD Error Status register 1 L3CDERRST1 B008 B00B 00000080h RW; RO;
L3CD Error Status register 2 L3CDERRST2 B00C B00F 00000000h RO;
L3 SQC registers 1 L3SQCREG1 B010 B013 01730000h RW; RO;
L3 SQC registers 2 L3SQCREG2 B014 B017 00004567h RO; RW;
L3 SQC registers 3 L3SQCREG3 B018 B01B 00001ABFh RO; RW;
L3 Control Register1 L3CNTLREG1 B01C B01F 8C47FF80h RW; RO;
L3 Control Register2 L3CNTLREG2 B020 B023 00080040h RW; RO;
L3 Control Register3 L3CNTLREG3 B024 B027 00000000h RO; RW;
L3 SLM Register L3SLMREG B028 B02B 40000000h RO; RW;
Arbiter Control Register GARBCNTLREG B02C B02F 29000000h RO; RW;
L3 SQC register 4 L3SQCREG4 B034 B037 88000000h RW; RO;
L3 bank0 reg0 log error L3B0REG0 B070 B073 00000000h RW; RO;
L3 bank0 reg1 log error L3B0REG1 B074 B077 00000000h RW; RO;
L3 bank0 reg2 log error L3B0REG2 B078 B07B 00000000h RW; RO;
L3 bank0 reg3 log error L3B0REG3 B07C B07F 00000000h RW; RO;
L3 bank0 reg4 log error L3B0REG4 B080 B083 00000000h RW; RO;
L3 bank0 reg5 log error L3B0REG5 B084 B087 00000000h RW; RO;
L3 bank0 reg6 log error L3B0REG6 B088 B08B 00000000h RW; RO;
L3 bank0 reg7 log error L3B0REG7 B08C B08F 00000000h RW; RO;
L3 bank1 reg0 log error L3B1REG0 B090 B093 00000000h RW; RO;
L3 bank1 reg1 log error L3B1REG1 B094 B097 00000000h RW; RO;
L3 bank1 reg2 log error L3B1REG2 B098 B09B 00000000h RW; RO;
L3 bank1 reg3 log error L3B1REG3 B09C B09F 00000000h RW; RO;
L3 bank1 reg4 log error L3B1REG4 B0A0 B0A3 00000000h RW; RO;
L3 bank1 reg5 log error L3B1REG5 B0A4 B0A7 00000000h RW; RO;
L3 bank1 reg6 log error L3B1REG6 B0A8 B0AB 00000000h RW; RO;
L3 bank1 reg7 log error L3B1REG7 B0AC B0AF 00000000h RW; RO;
L3 bank2 reg0 log error L3B2REG0 B0B0 B0B3 00000000h RW; RO;
L3 bank2 reg1 log error L3B2REG1 B0B4 B0B7 00000000h RW; RO;
L3 bank2 reg2 log error L3B2REG2 B0B8 B0BB 00000000h RW; RO;
L3 bank2 reg3 log error L3B2REG3 B0BC B0BF 00000000h RW; RO;
L3 bank2 reg4 log error L3B2REG4 B0C0 B0C3 00000000h RW; RO;
L3 bank2 reg5 log error L3B2REG5 B0C4 B0C7 00000000h RW; RO;
L3 bank2 reg6 log error L3B2REG6 B0C8 B0CB 00000000h RW; RO;
L3 bank2 reg7 log error L3B2REG7 B0CC B0CF 00000000h RW; RO;
L3 bank3 reg0 log error L3B3REG0 B0D0 B0D3 00000000h RW; RO;
L3 bank3 reg1 log error L3B3REG1 B0D4 B0D7 00000000h RW; RO;
L3 bank3 reg2 log error L3B3REG2 B0D8 B0DB 00000000h RW; RO;
L3 bank3 reg3 log error L3B3REG3 B0DC B0DF 00000000h RW; RO;
L3 bank3 reg4 log error L3B3REG4 B0E0 B0E3 00000000h RW; RO;
L3 bank3 reg5 log error L3B3REG5 B0E4 B0E7 00000000h RW; RO;
L3 bank3 reg6 log error L3B3REG6 B0E8 B0EB 00000000h RW; RO;
L3 bank3 reg7 log error L3B3REG7 B0EC B0EF 00000000h RW; RO;
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 23
Register Name Register Symbol Register Start Register End Default Value Access
SARB config save msg SARBCSR B1FC B1FF 00000000h RWHC; RO;
8.1.1 SARERRST - SARB Error Status
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B004-B007h
Default Value: 00000000h
Access: RO
Size: 32 bits
Reports the error if any has occurred for certain sarb features.
Bit Access Default Value RST/PWR Description
31 RO 0b Core Error if general bound is zero (ERRGENBDZO):
Error if general bound is zero set by sarbunit
1: general bound address is 0
sarbcf_csr_gen_bnd_zero_err
30 RO 0b Core Error if dynamic bound is zero (ERRDYDNZO):
Error if dynamic bound is zero- set by sarbunit
0:no error
1: dynamic address is 0
sarbcf_csr_dyn_bnd_zero_err
29 RO 0b Core Reserved (RSVD):
28 RO 0b Core General Bound Check Overflow Error (GENBNDOVF):
General Bound Check Overflow Error - set by sarbunit
1: overflow for general bound check
sarbcf_csr_gen_bnd_ovflw_err
27 RO 0b Core Dynamic Bound Check Overflow Error (DYNBDOVF):
Dynamic Bound Check Overflow Error -set by sarbunit
1: overflow for dynamic bound check
sarbcf_csr_dyn_bnd_ovflw_err
26 RO 0b Core Lower Bound Check Overflow Error (LWRBDOVF):
Lower Bound Check Overflow Error-set by sarbunit
lower bound overflow
sarbcf_csr_lower_bnd_err
25:21 RO 00000b Core INVALIDATION FLUSH STATUS REPORTING (INVSTRPT):
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 24
invalidation status for l3 is reported in this register.
20:18 RO 000b Core SARB invalidation Status reporting (SARBINVSTRPT):
invalidation status of sarb is reported in this register.
17:0 RO 00000h Core Reserved (RSVD):
Reserved
8.1.2 L3CDERRST2 - L3CD Error Status register 2
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B00C-B00Fh
Default Value: 00000000h
Access: RO; RWC;
Size: 32 bits
Default
Bit Access Value RST/PWR Description
31:29 RO 000b Core
Reserved (RSVD):
reserved
28 RWC 0b Core
URB High Limit Error on B3 (URBHLB3):
URB High Limit Error on B3:
Report the URB High Limit Error- Address Bound check
Once set, it can be cleared only by MMIO Write to this register. A write of value
1 will clear it
( LTCC generates a Pulse to SARB Config , Sarb Config sets and reflect it in
the MMIO as Error status. This can be only cleared by MMIO Write to that Bit. )
ltcc3_sarb_urboff_error
27 RWC 0b Core
URB High Limit Error on B2 (URBHLB2):
URB High Limit Error on B2:
Report the URB High Limit Error- Address Bound check
Once set, it can be cleared only by MMIO Write to this register.
( LTCC generates a Pulse to SARB Config , Sarb Config sets and reflect it in
the MMIO as Error status. This can be only cleared by MMIO Write to that Bit. )
ltcc2_sarb_urboff_error
26 RWC 0b Core
URB High Limit Error on B1 (URBHLB1):
URB High Limit Error on B1:
Report the URB High Limit Error - Address Bound check
Once set, it can be cleared only by MMIO Write to this register.
( LTCC generates a Pulse to SARB Config , Sarb Config sets and reflect it in
the MMIO as Error status. This can be only cleared by MMIO Write to that Bit. )
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 25
Default
Bit Access Value RST/PWR Description
ltcc1_sarb_urboff_error
25 RWC 0b Core
URB High Limit Error on B0 (URBHLB0):
URB High Limit Error on B0 :
Report the URB High Limit Error - Address Bound check
Once set, it can be cleared only by MMIO Write to this register.
( LTCC generates a Pulse to SARB Config , Sarb Config sets and reflect it in
the MMIO as Error status. This can be only cleared by MMIO Write to that Bit. )
ltcc0_sarb_urboff_error
24:0 RO 0000000h Core
Reserved (RSVD):
8.1.3 L3SQCREG1 - L3 SQC registers 1
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B010-B013h
Default Value: 01730000h
Access: RW; RO;
Size: 32 bits
Acces Default RST/PW
Bit s Value R Description
31:2 RO 0000b Core Reserved (RSVD):
8
Reserved
27 RW 0b Core Convert L3 cycle for texture to uncachable (CON4TXTUNC):
Convert L3 cycle for texture to uncachable
1: texture has no way allocation in L3
0: texture has atleast 1 way allocated in L3 (default)
sarbcf_csr_lsqc_cnvt_txt_unchble
This bit should be set/cleared according to L3 configuration in registers at offset
0xB020 and 0xB024
26 RW 0b Core Convert L3 cycle for constant to uncachable (CON4CONSUNC):
Convert L3 cycle for constant to uncachable
1: constant has no way allocation in L3
0: constant has atleast 1 way allocated in L3 (default)
sarbcf_csr_lsqc_cnvt_const_unchble
This bit should be set/cleared according to L3 configuration in registers at offset
0xB020 and 0xB024
25 RW 0b Core Convert L3 cycle for Inst/State to uncachable (CON4INSSTUNC):
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 26
Acces Default RST/PW
Bit s Value R Description
Convert L3 cycle for Inst/State to uncachable
1: Inst/State has no way allocation in L3
0: Inst/State has atleast 1 way allocated in L3 (default)
sarbcf_csr_lsqc_cnvt_ins_st_unchble
This bit should be set/cleared according to L3 configuration in registers at offset
0xB020 and 0xB024
24 RW 1b Core Convert L3 cycle for DC to uncachable (CON4DCUNC):
Convert L3 cycle for DC to uncachable
1: DC has no way allocation in L3 (default)
0: DC has atleast 1 way allocated in L3 sarbcf_csr_lsqc_cnvt_dc_unchble
This bit should be set/cleared according to L3 configuration in registers at offset
0xB020 and 0xB024
If 0xB020[26:21] (DC Way Assignment) field is 000000, this bits needs to be
set (1). For all other values of 0xB020[26:21], this bit needs to be cleared (0)
23:1 RW 01110011 Core L3SQ General / High Priority Credit Initialization (SQGHPCI):
6 b
L3SQ General / High Priority Credit Initialization (SQGHPCI)Number of general
and high priority credits that SQ presents to L3 Arbiter blocks. This inherently
also determines the depth of the SQ; reduce the number of credits and SQ will
use fewer slots.Any value not listed here, is considered Reserved.
Value # General Credits # High Pri Credits SQ depth
00010000 2 0 2
00010001 2 2 4
00100000 4 0 4
00100001 4 2 6
00100010 4 4 8
00110000 6 0 6
00110001 6 2 8
00110010 6 4 10
00110011 6 6 12
01000000 8 0 8
01000001 8 2 10
01000010 8 4 12
01000011 8 6 14
01000100 8 8 16
01010000 12 0 12
01010001 12 2 14
01010010 12 4 16
01010011 12 6 18
01010100 12 8 20
01010101 12 12 24
01100000 16 0 16
01100001 16 2 18
01100010 16 4 20
01100011 16 6 22
01100100 16 8 24
01110000 18 0 18
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 27
Acces Default RST/PW
Bit s Value R Description
01110001 18 2 20
01110010 18 4 22
01110011 18 6 24(default)
10000000 20 0 20
10000001 20 2 22
10000010 20 4 24
10010000 22 0 22
10010001 22 2 24
10100000 24 0 24
sarbcf_csr_lsqc_hp_gen_credit_init[7:0]
15:14 RO 00b Core
Reserved (RSVD):
Reserved
13:12 RW 00b Core
L3SQ Atomics Credit Initialization (SQACI):
L3SQ Atomics Credit Initialization (SQACI)Number of atomics credits that SQ
presents to L3 Arbiter blocks.
00 = 2 Credits (default)
01 = 1 Credit1X = Reserved
sarbcf_csr_lsqc_atom_credit_init[1:0]
11:10 RW 00b Core
L3SQ Data Credit Initialization (SQDCI):
L3SQ Data Credit Initialization (SQDCI)Number of data credits that SQ presents
to L3 Arbiter blocks.
00 = 4 Credits (default)
01 = 1 Credit
10 = 2 Credits
11 = 3 Credits
sarbcf_csr_lsqc_data_credit_init[1:0]
9 RW 0b Core
L3SQ Read Once Enable for Sampler Client (SQROE):
L3SQ Read Once Enable for Sampler Client (SQROE): Enables Read Once
indications to L3 Cache from SQ. Once enabled, any reads from Sampler client
(MT) will be sent as Read Once
0 = Reads from Sampler clients issue Read to L3 Cache (default)
1 = Reads from Sampler clients issue Read Once to L3 Cache
sarbcf_csr_sampler_readonce_en
8:6 RW 000b Core
L3SQ Outstanding GAP Reads (SQOUTSGAP):
L3SQ Outstanding GAP Reads (SQOUTSGAP): Identifies the number of Pixel
Arbiter Reads that can be outstanding before SQ throttles the puts to GAP. This
is not an exact limit, but instead it is used as a threshold to throttling; once the
read count is greater than or equal to the threshold, then no reads will be issued
until data returns are received to bring the outstanding count back below the
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 28
Acces Default RST/PW
Bit s Value R Description
threshold.
000 = No limit (default)
001 = 1 read 010 = 2 reads
011 = 4 reads100 = 8 reads
101 = 16 reads11X = Reserved
sarbcf_csr_lsqc_outs_gaprd[2:0]
5:3 RW 000b Core
L3SQ Outstanding L3 Fills (SQOUTSL3F):
L3SQ Outstanding L3 Fills (SQOUTSL3F): Identifies the number of L3 Fills that
can be outstanding before SQ throttles the fill requests to L3 Cache. This is not
an exact limit, but instead it is used as a threshold to throttling; once the fill count
is greater than or equal to the threshold, then no fills will be issued until the fill
responses are received to bring the outstanding count back below the threshold.
000 = No limit (default)
001 = 1 fill
010 = 2 fills
011 = 4 fills
100 = 8 fills
101 = 16 fills
11X = Reserved
sarbcf_csr_lsqc_outs_fill[2:0]
2:0 RW 000b Core
L3SQ Outstanding L3 Lookups (SQOUTSL3L):
L3SQ Outstanding L3 Lookups (SQOUTSL3L): Identifies the number of L3
lookups that can be outstanding before SQ throttles the lookup requests to L3
Cache. This is not an exact limit, but instead it is used as a threshold to throttling;
once the lookup count is greater than or equal to the threshold, then no lookups
will be issued until the lookup responses are received to bring the outstanding
count back below the threshold.
000 = No limit (default)
001 = 1 lookup
010 = 2 lookups
011 = 4 lookups
100 = 8 lookups
101 = 16 lookups
11X = Reserved
sarbcf_csr_lsqc_outs_lookup[2:0]
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 29
8.1.4 L3SQCREG2 - L3 SQC registers 2
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B014-B017h
Default Value: 00004567h
Access: RO; RW;
Size: 32 bits
Bit Access Default Value RST/PWR Description
31:17 RO 000000000000000b Core
Reserved (RSVD):
Reserved
16 RW 0b Core
L3SQ Priority Selection Disable (SQPRIDIS):
L3SQ Priority Selection Disable (SQPRIDIS)Enables the use of priority
selection based on client ID decodes. If disabled, all cycles in SQ will
be treated as same priority
0 = Priority selection is enabled (default)
1 = Priority selection is disabled
sarbcf_csr_priority_cnt_disable
15 RW 0b Core
L3SQ Priority 3 Pool Count Disable (SQPRI3CNTDIS):
L3SQ Priority 3 Pool Count Disable (SQPRI3CNTDIS): When set,
priority3 pool becomes unlimited. And priority3 pool count value should
not be used in reset of the remaining counters.
0 = Priority 3 pool count is enabled (default)
1 = Priority 3 pool count is disabled
sarbcf_csr_priority3_cnt_disable
14:12 RW 100b Core
L3SQ Priority 3 Pool Counter (SQPRI3CNT):
L3SQ Priority 3 Pool Counter (SQPRI3CNT): The count of cycles will
be selected from priority3 pool before switching to other priority pools.
Count is used as the power of 2.
000 = 1 request
001 = 2 requests
010 = 4 requests
011 = 8 requests
..
111 = 128 requests
sarbcf_csr_priority3_cnt[2:0]
11 RW 0b Core
L3SQ Priority 2 Pool Count Disable (SQPRI2CNTDIS):
L3SQ Priority 2 Pool Count Disable (SQPRI2CNTDIS): When set,
priority2 pool becomes unlimited. And priority2 pool count value should
not be used in reset of the remaining counters.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 30
Bit Access Default Value RST/PWR Description
0 = Priority 2 pool count is enabled (default)
1 = Priority 2 pool count is disabled
sarbcf_csr_priority2_cnt_disable
10:8 RW 101b Core
L3SQ Priority 2 Pool Counter (SQPRI2CNT):
L3SQ Priority 2 Pool Counter (SQPRI2CNT): The count of cycles will
be selected from priority2 pool before switching to other priority pools.
Count is used as the power of 2.
000 = 1 request
001 = 2 requests
010 = 4 requests
011 = 8 requests
..
111 = 128 requests
sarbcf_csr_priority2_cnt[2:0]
7 RW 0b Core
L3SQ Priority 1 Pool Count Disable (SQPRI1CNTDIS):
L3SQ Priority 1 Pool Count Disable (SQPRI1CNTDIS): When set,
priority1 pool becomes unlimited. And priority1 pool count value should
not be used in reset of the remaining counters.
0 = Priority 1 pool count is enabled (default)
1 = Priority 1 pool count is disabled
sarbcf_csr_priority1_cnt_disable
6:4 RW 110b Core
L3SQ Priority 1 Pool Counter (SQPRI1CNT):
L3SQ Priority 1 Pool Counter (SQPRI1CNT): The count of cycles will
be selected from priority1 pool before switching to other priority pools.
Count is used as the power of 2.
000 = 1 request
001 = 2 requests
010 = 4 requests
011 = 8 requests
..
111 = 128 requests
sarbcf_csr_priority1_cnt[2:0]
3 RW 0b Core
L3SQ Priority 0 Pool Count Disable (SQPRI0CNTDIS):
L3SQ Priority 0 Pool Count Disable (SQPRI0CNTDIS): When set,
priority0 pool becomes unlimited. And priority0 pool count value should
not be used in reset of the remaining counters.
0 = Priority 0 pool count is enabled (default)
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 31
Bit Access Default Value RST/PWR Description
1 = Priority 0 pool count is disabled
sarbcf_csr_priority0_cnt_disable
2:0 RW 111b Core
L3SQ Priority 0 Pool Counter (SQPRI0CNT):
L3SQ Priority 0 Pool Counter (SQPRI0CNT): The count of cycles will
be selected from priority0 pool before switching to other priority pools.
Count is used as the power of 2.
000 = 1 request
001 = 2 requests
010 = 4 requests
011 = 8 requests
..
111 = 128 requests (default)
sarbcf_csr_priority0_cnt[2:0]
8.1.5 L3SQCREG3 - L3 SQC registers 3
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B018-B01Bh
Default Value: 00001ABFh
Access: RO; RW;
Size: 32 bits
Default
Bit Access Value RST/PWR Description
31:30 RO 00b Core
Reserved (RSVD):
Reserved
29:28 RW 00b Core
SOLunit Priority Value (SQSOLPRIVAL):
SOLunit Priority Value (SQSOLPRIVAL): Identifies the priority value for all cycles
that are initiated by SOLunit. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0 (default)
01 = Priority 1
10 = Priority 2
11 = Priority 3
sarbcf_csr_sol_priority[1:0]
27:26 RW 00b Core
GSunit Priority Value (SQGSPRIVAL):
GSunit Priority Value (SQGSPRIVAL): Identifies the priority value for all cycles
that are initiated by GSunit. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0 (default)
01 = Priority 1
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 32
Default
Bit Access Value RST/PWR Description
10 = Priority 2
11 = Priority 3
sarbcf_csr_gs_priority[1:0]
25:24 RW 00b Core
TEunit Priority Value (SQTEPRIVAL):
TEunit Priority Value (SQTEPRIVAL): Identifies the priority value for all cycles
that are initiated by TEunit. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0 (default)
01 = Priority 1
10 = Priority 2
11 = Priority 3
sarbcf_csr_te_priority[1:0]
23:22 RW 00b Core
CLunit Priority Value (SQCLPRIVAL):
CLunit Priority Value (SQCLPRIVAL): Identifies the priority value for all cycles
that are initiated by CLunit. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0 (default)
01 = Priority 110 = Priority 2
11 = Priority 3
sarbcf_csr_cl_priority[1:0]
21:20 RW 00b Core
TSunit Priority Value (SQTSPRIVAL):
TSunit Priority Value (SQTSPRIVAL): Identifies the priority value for all cycles
that are initiated by TSunit. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0 (default)
01 = Priority 1
10 = Priority 2
11 = Priority 3
sarbcf_csr_ts_priority[1:0]
19:18 RW 00b Core
SFunit Priority Value (SQSFPRIVAL):
SFunit Priority Value (SQSFPRIVAL): Identifies the priority value for all cycles
that are initiated by SFunit. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0 (default)
01 = Priority 1
10 = Priority 2
11 = Priority 3
sarbcf_csr_sf_priority[1:0]
17:16 RW 00b Core
SVSM Priority Value (SQSVSMPRIVAL):
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 33
Default
Bit Access Value RST/PWR Description
SVSM Priority Value (SQSVSMPRIVAL): Identifies the priority value for all cycles
that are initiated by SVSM. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0 (default)
01 = Priority 1
10 = Priority 2
11 = Priority 3
sarbcf_csr_svsm_priority[1:0]
15:14 RW 00b Core
SARB Priority Value (SQSARBPRIVAL):
SARB Priority Value (SQSARBPRIVAL): Identifies the priority value for all cycles
that are initiated by State Arbiter (SARB). Priority is used in the L3 Super Queue
(L3SQ).
00 = Priority 0 (default)
01 = Priority 1
10 = Priority 2
11 = Priority 3
sarbcf_csr_sarb_priority[1:0]
13:12 RW 01b Core
SBE Priority Value (SQSBEPRIVAL):
SBE Priority Value (SQSBEPRIVAL): Identifies the priority value for all cycles that
are initiated by SBE. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0
01 = Priority 1 (default)
10 = Priority 2
11 = Priority 3
sarbcf_csr_sbe_priority[1:0]
11:10 RW 10b Core
IC$ Priority Value (SQICPRIVAL):
IC$ Priority Value (SQICPRIVAL): Identifies the priority value for all cycles that
are initiated by Instruction Cache (IC$). Priority is used in the L3 Super Queue
(L3SQ).
00 = Priority 0
01 = Priority 1
10 = Priority 2 (default)
11 = Priority 3
sarbcf_csr_ic_priority[1:0]
9:8 RW 10b Core
TDL Priority Value (SQTDLPRIVAL):
TDL Priority Value (SQTDLPRIVAL): Identifies the priority value for all cycles that
are initiated by TDL. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 34
Default
Bit Access Value RST/PWR Description
01 = Priority 1
10 = Priority 2 (default)
11 = Priority 3
sarbcf_csr_tdl_priority[1:0]
7:6 RW 10b Core
DCunit Priority Value (SQDCPRIVAL):
DCunit Priority Value (SQDCPRIVAL): Identifies the priority value for all cycles
that are initiated by DC. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0
01 = Priority 1
10 = Priority 2 (default)
11 = Priority 3
sarbcf_csr_dc_priority[1:0]
5:4 RW 11b Core
DAPR Priority Value (SQDAPRPRIVAL):
DAPR Priority Value (SQDAPRPRIVAL): Identifies the priority value for all cycles
that are initiated by DAPR. Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0
01 = Priority 1
10 = Priority 2
11 = Priority 3 (default)
sarbcf_csr_dapr_priority[1:0]
3:2 RW 11b Core
MTunit Priority Value (SQMTPRIVAL):
MTunit Priority Value (SQMTPRIVAL): Identifies the priority value for all cycles
that are initiated by Sampler (MT). Priority is used in the L3 Super Queue (L3SQ).
00 = Priority 0
01 = Priority 1
10 = Priority 2
11 = Priority 3 (default)
sarbcf_csr_mt_priority[1:0]
1:0 RW 11b Core
LSQCunit Priority Value (SQPRIVAL):
LSQCunit Priority Value (SQPRIVAL): Identifies the priority value for all cycles
that are initiated by Super Queue (L3 Evictions). Priority is used in the L3 Super
Queue (L3SQ).
00 = Priority 0
01 = Priority 1
10 = Priority 2
11 = Priority 3 (default)
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 35
Default
Bit Access Value RST/PWR Description
sarbcf_csr_lsqc_priority[1:0]
8.1.6 L3CNTLREG1 - L3 Control Register1
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B01C-B01Fh
Default Value: 8C47FF80h
Access: RW; RO;
Size: 32 bits
Default
Bit Access Value RST/PWR Description
31:28 RW 1000b Core
Data Fifo Depth Control (DFIFODC):
Data Fifo Depth Control (TS mode)
Stall Control: POR is 1000b. Flexing for Hitting the stall
Validation scenarios
Maximum available setting for h/w is "1000"
sarbcf_csr_lc_datafifo_depth[3:0]
Due to w/a of bug#3665919, the depth has to be set to
“0011”
27:24 RW 1100b Core
Data Clock off time (DCLKOFFT):
Data Clock off time (DATACLKOFF): Data Clock off time -
Data block is shut off after these many number of clocks
programmed in this register bits.
sarbcf_csr_lc_dataclkoff_time[3:0]
23:20 RW 0100b Core
TAG CLK OFF TIME (TAGCLKOFF):
TAG CLK OFF TIME (TAGCLKOFF): TAG Clock Off time.
This is the time, which Clock gating Logic check before it
turn off the clock.
sarbcf_csr_lc_tagclkoff_time[3:0]
19 RW 0b Core
L3 Aging Disable Bit (L3AGDIS):
L3 Aging Disable Bit (L3AGDIS): Aging Disable
sarbcf_csr_lc_agingdis
18:15 RW 1111b Core
Fill aging (L3AGF):
Fill aging (L3AGF): Aging Counter for Fill
sarbcf_csr_lc_fill_aging_cnt[3:0]
14:11 RW 1111b Core
Aging Counter for Read 1 Port (L3AGR1):
Aging Counter for Read 1 Port (L3AGR1): Aging Counter
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 36
Default
Bit Access Value RST/PWR Description
for Read 1 Port
sarbcf_csr_lc_rd1_aging_cnt[3:0]
10:7 RW 1111b Core
L3 Aging Counter for R0 (L3AGR0):
L3 Aging Counter for R0 (L3AGR0): Aging Counter for R0
Port
sarbcf_csr_lc_rd0_aging_cnt[3:0]
6:3 RW 0000b Core
Number of NOPs (L3NOP):
Number of NOPs (L3NOP): Number of NOPs to be inserted
between the Tag commands.
sarbcf_csr_lc_num_nop[3:0]
Due to w/a of bug#3665919, the depth has to be set to
“0001”
2 RW 0b Core
OP0/OP1 Disable (L3OPDIS):
OP0/OP1 Disable (L3OPDIS): This bit is used to enable the
feature of inserting the number of cycles between the tag
pipeline operation.
sarbcf_csr_lc_op0op1_disable
Due to w/a of bug#3665919, the OP1 has to be set to “1”
1 RW 0b Core
L3 OP1 Disable Mode (L3OP1DIS):
L3 OP1 Disable Mode (L3OP1DIS):
OP1 in L3 can be disabled which means there will be one
Command transferred to the Tag pipeline in 1X Domain
sarbcf_csr_lc_op1_disable
Note: If this bit is set Aging mode needs to be disabled as
well.
0 RO 0b Core
Reserved (RSVD):
Reserved
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 37
8.1.7 L3CNTLREG2 - L3 Control Register2
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B020-B023h
Default Value: 00080040h
Access: RW; RO;
Size: 32 bits
Default
Bit Access Value RST/PWR Description
31:28 RO 0000b Core
Reserved (RSVD):
27 RW 0b Core
DC way assignment SLM Behavior (DCWASLMB):
DC way assignment SLM Behavior: In shared local memory mode DC is
assigned into low b/w mode which requires it to be assigned non-matched ways
of bigger banks and it will be hashed to 2 banks.
sarbcf_csr_dc_slm_lowbw
26:21 RW 000000b Core
DC Way Assignment (DCWASS):
DC Way Assignment: Number of ways allocated for DC. Note this allocation is
only for DC data types. 000000: 0KB000001: 8KB (4KB for GT1) 000010: 16KB
(8KB for GT1) 111111: 504KB (252KB for GT1)Note: This field must be 0KB is All
L3 Client Pool is non-zero.
sarbcf_csr_dc_size[5:0]
20 RW 0b Core
RO Client Pool SLM Behavior (ROCPSLMB):
RO Client Pool SLM Behavior: In shared local memory mode Read Only Clients
are assigned into low b/w mode which requires it to be assigned non-matched
ways of bigger banks and it will be hashed to 2 banks.
sarbcf_csr_ro_slm_lowbw
19:14 RW 100000b Core
Read Only Client Pool (RDOCPL):
Read Only Client Pool: Number of ways allocated for ROnly L3 clients. This is a
combined pool for all RO clients.
000000: 0KB
000001: 8KB (4KB for GT1)
000010: 16KB (8KB for GT1)
111111: 504KB (252KB for GT1)
Note: If all ROClient pool is non-zero, than Inst/state, Const and Texture client
allocation should have 0KB allocation.
sarbcf_csr_ro_size[5:0]
13:8 RW 000000b Core
All L3 Client Pool (ALL3CLPL):
All L3 Client Pool: Number of ways allocated for all L3 clients. This is a combined
pool for all L3 clients.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 38
Default
Bit Access Value RST/PWR Description
000000: 0KB
000001: 8KB (4KB for GT1)
000010: 16KB (8KB for GT1)
111111: 504KB (252KB for GT1)
Note: If all L3 Client pool is non-zero, than all L3 client pools should have 0KB
allocation.
sarbcf_csr_l3_size[5:0]
7 RW 0b Core
URB SLM Behavior (URBSLMB):
URB SLM Behavior: In shared local memory mode URB is assigned into low b/w
mode which requires it to be assigned non-matched ways of bigger banks and it
will be hashed to 2 banks.
sarbcf_csr_urb_slm_lowbw
6:1 RW 100000b Core
URB Allocation (URBALL):
URB Allocation: Number of ways allocated for URB usage
000000: 0KB
000001: 8KB (4KB for GT1)
000010: 16KB (8KB for GT1)
111111: 504KB (252KB for GT1)
sarbcf_csr_urb_size[5:0]
0 RW 0b Core
SLM Mode Enable (SLMMENB):
SLM Mode Enable: When enabled, a 128KB region of L3 is reserved for SLM.
This allocation is done on 2 banks with 64KB per half-slice.
0: SLM is disabled
1: SLM is enabled
Note: For GT1, there is only one 64KB allocation for single half-slice.
sarbcf_csr_slm_mode
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 39
8.1.8 L3CNTLREG3 - L3 Control Register3
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B024-B027h
Default Value: 00000000h
Access: RO; RW;
Size: 32 bits
Default
Bit Access Value RST/PWR Description
31:22 RO 0000000000b Core
Reserved (RSVD):
21 RW 0b Core
Textures Way Allocation SLM Behavior (TWALSLMB):
Textures Way Allocation SLM Behavior: In shared local memory mode
Textures is assigned into low b/w mode which requires it to be assigned non-
matched ways of bigger banks and it will be hashed to 2 banks.
sarbcf_csr_tex_slm_lowbw
20:15 RW 000000b Core
Textures Way Allocation (TXWYALL):
Textures Way Allocation: Number of ways allocated for Textures.
000000: 0KB
000001: 8KB (4KB for GT1)
000010: 16KB (8KB for GT1)
111111: 504KB (252KB for GT1)
Note: This field must be 0KB is All L3 Client Pool or Read-Only Client Pool is
non-zero.
sarbcf_csr_tex_size[5:0]
14 RW 0b Core
Constants Way Allocation SLM Behavior (CWASLMB):
Constants Way Allocation SLM Behavior: In shared local memory mode
Instruction/state is assigned into low b/w mode which requires it to be
assigned non-matched ways of bigger banks and it will be hashed to 2 banks.
sarbcf_csr_const_slm_lowbw
13:8 RW 000000b Core
Constants Way Allocation (CTWALL):
Constants Way Allocation: Number of ways allocated for Constants.
000000: 0KB
000001: 8KB (4KB for GT1)
000010: 16KB (8KB for GT1)
111111: 504KB (252KB for GT1)
Note: This field must be 0KB is All L3 Client Pool or Read-Only Client Pool is
non-zero.
sarbcf_csr_const_size[5:0]
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 40
Default
Bit Access Value RST/PWR Description
7 RW 0b Core
Instruction/State Way Allocation SLM Behavior (ISWASLMB):
Instruction/State Way Allocation SLM Behavior: In shared local memory mode
Instruction/state is assigned into low b/w mode which requires it to be
assigned non-matched ways of bigger banks and it will be hashed to 2 banks.
sarbcf_csr_is_slm_lowbw
6:1 RW 000000b Core
Instruction/State Way Allocation (ISWYALL):
Instruction/State Way Allocation: Number of ways allocated for
Instruction/State usage
000000: 0KB
000001: 8KB (4KB for GT1)
000010: 16KB (8KB for GT1)
111111: 504KB (252KB for GT1)
Note: This field must be 0KB is All L3 Client Pool or Read-Only Client Pool is
non-zero.
sarbcf_csr_is_size[5:0]
0 RO 0b Core
Reserved (RSVD):
Reserved
8.1.9 L3SLMREG - L3 SLM Register
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B028-B02Bh
Default Value: 40000000h
Access: RO; RW;
Size: 32 bits
Default
Bit Access Value RST/PWR Description
31 RW 0b Core
Disable Periodic SLM/SQ slot allocation (DPSLMALL):
Disable Periodic SLM/SQ slot allocation: When cfg_lslm_livelock_fairarb_dis=1
lslm unit will always have the higher priority and lslm_lsqc_block to lsqcunit is
asserted as long as there are requests in SLM FIFO
sarbcf_csr_lslm_livelock_fairarb_dis
30:27 RW 1000b Core
LSLM_SQ_PENDING_MAX (LSLMSQPEND):
If lslmunit has read data to be sent to lcbrunit this cfg register specifies the
maximum number of clocks for which LSLMunit can block SQ request from
being sent to lcbrunit
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 41
Default
Bit Access Value RST/PWR Description
Default value = 8
sarbcf_csr_lslm_sqpend_max[3:0]
26:0 RO 0000000h Core
Reserved (RSVD):
8.1.10 GARBCNTLREG - Arbiter Control Register
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B02C-B02Fh
Default Value: 29000000h
Access: RO; RW;
Size: 32 bits
Default
Bit Access Value RST/PWR Description
31
30 RW 0b Core
Disables hashing function (DISHHF):
Disables hashing function to generate bank_id[1:0] for L3$ bank accessing, and
forces the use of address[7:6] for bank_id[1:0].
0 : (default) Hash function enabled to generate L3$ bank IDs.
1 : L3$ address[7:6] used as L3$ bank IDs.
sarbcf_csr_l3bankidhashdis
29:28 RW 10b Core
Arbitration priority order between RCC and MSC (APORM):
Arbitration priority order between RCC and MSC.
00/11: Invalid; default setting used
10 : Default setting; RCC < MSC (i.e., MSC has higher priority)
01: RCC > MSC (i.e., RCC has higher priority)
sarbcf_csr_rcc_msc_pri[1:0]
27:22 RW 100100b Core
Arbitration priority order between RCZ, STC, and HIZ (APORSH):
Arbitration priority order between RCZ, STC, and HIZ.
100100 : Default setting; RCZ < STC < HIZ (i.e., RCZ has lowest
priority; HIZ has highest priority)
100001 : RCZ < HIZ < STC0
11000 : STC < RCZ < HIZ0
10010 : STC < HIZ < RCZ
001001 : HIZ < RCZ < STC
000110 : HIZ < STC < RCZ
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 42
Default
Bit Access Value RST/PWR Description
Note: Others settings are invalid, and result in use of default.
sarbcf_csr_rcz_stc_hiz_pri[5:0]
21:19 RW 000b Core
Write data port arbitration priority between Z client writes and L3$
evictions (WDPAGAPZ):
Write data port arbitration priority between Z client writes and L3$ evictions.
000 : L3:Z=1:0 - i.e., L3$ evictions > Z writes; Fixed priority; Default setting.
001 : L3:Z=1:1 - i.e., L3$ evictions = Z writes; Round-robin priority
010 : L3:Z=2:1 - i.e., Z writes will have higher priority after 2 L3$ evictions have
been continuously granted earlier
011 : L3:Z=3:1 - i.e., Z writes will have higher priority after 3 L3$ evictions have
been continuously granted earlier
...
111 : L3:Z=7:1 - i.e., Z writes will have higher priority after 7 L3$ evictions have
been continuously granted
sarbcf_csr_wdpagapz[2:0]
18:16 RW 000b Core
Write data port arbitration priority between C client writes and Z/L3$
writes/evictions (WDPAGAPC):
Write data port arbitration priority between C client writes and Z/L3$
writes/evictions.
000 : L3:Z=1:0 – i.e., Z/L3$ writes/evictions > C writes; Fixed priority; Default
setting.
001 : L3:Z=1:1 – i.e., Z/L3$ writes/evictions = C writes; Round-robin priority
010 : L3:Z=2:1 – i.e., C writes will have higher priority after 2 Z/L3$
writes/evictions have been continuously granted earlier
011 : L3:Z=3:1 – i.e., C writes will have higher priority after 3 Z/L3$
writes/evictions have been continuously granted earlier
...
111 : L3:Z=7:1 – i.e., C writes will have higher priority after 7 Z/L3$
writes/evictions have been continuously granted earlier
sarbcf_csr_wdpagapc[2:0]
15:0 RO 0000h Core
Reserved (RSVD):
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 43
8.1.11 L3SQCREG4 - L3 SQC register 4
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B034-B037h
Default Value: 08000000h
Access: RWHC; RO; RW;
Size: 32 bits
Default
Bit Access Value RST/PWR Description
31 RO 0b Core
Reserved (RSVD):
30 RW 0b Core
L3SQ Mode select for FF32 cycles on Crossbar 0/2 (SQFF32MODE):
L3SQ Mode select for FF32 cycles on Crossbar 0/2 (SQFF32MODE):
Selects the mode in which SQ arbitrates FF32 cycles versus Half slice clients
during Crossbar 2 arbitration. Qualified with the assertion of the crossbar 0/2
enable (SQFF32EN).
In mode 0, crossbar 0/2 arbitration operates normally, and is determined strictly
by the priority bits assigned by client (SQ*PRIVAL).
In mode 1, FF32 priority values are determined by the FF32 priority override
(SQFF32PRIOVER) when an indication is observed from GAFS (greater than 32
FF cycles are pending)
1 = all FF32 cycles will receive the overridden value instead of the default client
priority value when indicated by GAFS counter
0 = all FF32 cycles will receive normal priority values (default)
29:28 RW 00b Core
L3SQ Priority Override for FF32 cycles on Crossbar 0/2 (SQFF32PRIOVER):
L3SQ Priority Override for FF32 cycles on Crossbar 0/2 (SQFF32PRIOVER):
Identifies the priority value for all FF32 cycles that are initiated by GAL3. Priority is
used in the L3 Super Queue (L3SQ). Qualified with the assertion of the crossbar
0/2 enable (SQFF32EN) and the assertion of ff32 mode select (SQFF32MODE).
00 = Priority 0 (default)
01 = Priority 1
10 = Priority 2
11 = Priority 3
27 RW 1b Core
L3SQ URB Read CAM Match Disable (SQURBRDCAMDIS):
L3SQ URB Read CAM Match Disable (SQURBRDCAMDIS):
Disables the L3SQ Cam Match ability for URB Reads. By disabling, this allows a
performance mode where URB reads are not dependent upon one another but
only on any previous URB writes to the same address. This allows many URB
reads to the same cacheline at any given time instead of serializing the requests.
1 = URB Read CAM matching is disabled; multiple URB reads to the same
cacheline are allowed to be concurrent(default)
0 = URB Read CAM matching is enabled; multiple URB reads to the same
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 44
Default
Bit Access Value RST/PWR Description
cacheline are serialized
26 RWHC 0b Core
LSQC reset fcount (LSQCRFCNT):
self clearing register bit - Write to this register generates 1 clock pulse
sarbcf_csr_lsqc_rst_fcount to lsqc and also used to clear the register
sarbcf_csr_lsqc_rst_fcount_lvl is output of configdb.
25 RWHC 0b Core
LSLM1 reset fcount (LSLM1RFCNT):
self clearing register bit - Write to this register generates 1 clock pulse
sarbcf_csr_lslm1_rst_fcount goes to lslm1 and also used to clear this register bit
sarbcf_csr_lslm1_rst_fcount_lvl is ouput of configdb
24 RWHC 0b Core
LSLM3 reset fcount (LSLM3RFCNT):
self clearing register bit - Write to this register generates 1 clock pulse
sarbcf_csr_lslm3_rst_fcount goes to lslm3 and used to clear this register too
sarbcf_csr_lslm1_rst_fcount_lvl is output of configdb.
23:0 RO 000000h Core
reserved (RSVD):
8.1.12 SCRATCH1 - SCRATCH1
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B038-B03Bh
Default Value: 00000000h
Access: RWHC; RO; RW;
Size: 32 bits
Bit Access Default Value RST/PWR Description
31:1 RW 00000000h Core
SCRATCH (SCRATCH):
0 RW 0b Core
L3 Starvation Limit:
sarbcf_csr_hs_l3starvlimit -
0 : GAHS* could get starved if HDC reads are streaming
1 : GAHS* arbitrated at higher priority than HDC* read reqs
serviced in 7 clocks
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 45
8.1.13 L3B0REG1 - L3 bank0 reg1 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B074-B077h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error.
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error.
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 46
8.1.14 L3B0REG2 - L3 bank0 reg2 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B078-B07Bh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error.
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error.
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 47
8.1.15 L3B0REG3 - L3 bank0 reg3 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B07C-B07Fh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 48
8.1.16 L3B0REG4 - L3 bank0 reg4 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B080-B083h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 49
8.1.17 L3B0REG5 - L3 bank0 reg5 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B084-B087h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 50
8.1.18 L3B0REG6 - L3 bank0 reg6 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B088-B08Bh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 51
8.1.19 L3B0REG7 - L3 bank0 reg7 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B08C-B08Fh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 52
8.1.20 L3B1REG0 - L3 bank1 reg0 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B090-B093h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 53
8.1.21 L3B1REG1 - L3 bank1 reg1 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B094-B097h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 54
8.1.22 L3B1REG2 - L3 bank1 reg2 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B098-B09Bh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 55
8.1.23 L3B1REG3 - L3 bank1 reg3 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B09C-B09Fh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 56
8.1.24 L3B1REG4 - L3 bank1 reg4 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0A0-B0A3h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 57
8.1.25 L3B1REG5 - L3 bank1 reg5 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0A4-B0A7h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 58
8.1.26 L3B1REG6 - L3 bank1 reg6 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0A8-B0ABh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 59
8.1.27 L3B1REG7 - L3 bank1 reg7 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0AC-B0AFh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 60
8.1.28 L3B2REG0 - L3 bank2 reg0 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0B0-B0B3h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 61
8.1.29 L3B2REG1 - L3 bank2 reg1 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0B4-B0B7h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 62
8.1.30 L3B2REG2 - L3 bank2 reg2 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0B8-B0BBh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 63
8.1.31 L3B2REG3 - L3 bank2 reg3 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0BC-B0BFh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 64
8.1.32 L3B2REG4 - L3 bank2 reg4 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0C0-B0C3h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 65
8.1.33 L3B2REG5 - L3 bank2 reg5 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0C4-B0C7h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 66
8.1.34 L3B2REG6 - L3 bank2 reg6 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0C8-B0CBh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 67
8.1.35 L3B2REG7 - L3 bank2 reg7 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0CC-B0CFh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 68
8.1.36 L3B3REG0 - L3 bank3 reg0 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0D0-B0D3h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 69
8.1.37 L3B3REG1 - L3 bank3 reg1 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0D4-B0D7h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 70
8.1.38 L3B3REG2 - L3 bank3 reg2 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0D8-B0DBh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 71
8.1.39 L3B3REG3 - L3 bank3 reg3 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0DC-B0DFh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 72
8.1.40 L3B3REG4 - L3 bank3 reg4 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0E0-B0E3h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 73
8.1.41 L3B3REG5 - L3 bank3 reg5 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0E4-B0E7h
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 74
8.1.42 L3B3REG6 - L3 bank3 reg6 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0E8-B0EBh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 75
8.1.43 L3B3REG7 - L3 bank3 reg7 log error
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B0EC-B0EFh
Default Value: 00000000h
Access: RW; RO;
Size: 32 bits
The ERROR LOG registers of L3 will maintain the bad row information for each of the 16KB subbank
groups. The LOG will be programmed by driver before any workloads are submitted. The contents of the
LOG register will be context Save&Restored by h/w around rc6 events.
Default
Bit Access Value RST/PWR Description
31:21 RW 000h Core
Row Number for Error1 (RNUMERR1):
Row Number for Error1: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
20:17 RO 0000b Core
Reserved (RSVD):
16 RW 0b Core
Valid Error 1 (VLDERR1):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
15:5 RW 000h Core
Row Number for Error0 (RNUMERR0):
Row Number for Error0: The physical row number where the parity error has been
detected. The number of rows vary between 4K vs 8K/16K subbanks which
requires 10bits vs 11bits respectively. This field contains the row# with the error
4:1 RO 0000b Core
Reserved (RSVD):
0 RW 0b Core
Valid Error 0 (VLDERR0):
Valid Error: The error located in field 15:5 is valid and corresponding logical 16KB
group should bypass this row.
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 76
8.1.44 SARBCSR - SARB config save msg
B/D/F/Type: 0/0/0/SARBunit_Config
Address Offset: B1FC-B1FFh
Default Value: 00000000h
Access: RWHC; RO;
Size: 32 bits
This register is not context saved
Default
Bit Access Value RST/PWR Description
31:2 RO 00000000h Core
Reserved (RSVD):
1 RWHC 0b Core
Context restore ack (CTXRSTRACK):
A write from cs to this bit along with mask bit 17 will prompt sarb to ack ctx
restore ack .
sarb_ctx_restore - ctx restore from cs
clr_sarb_ctx_restore - sarb clr this bit.
0 RWHC 0b Core
Context save bit (SARBCS):
A write from cs to this bit along with mask bit 16 will prompt sarb to start
context save to cs.
sarb_ctx_save - ctx save from cs
clr_sarb_ctx_save - sarb clr this bit once ctx save sm kicks in .
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 77
Revision History
Revision Number Description Revision Date
1.0 First 2012 OpenSource edition May 2012
§§
Doc Ref #: IHD-OS-V1 Pt 7 – 05 12 5/31/2012 78
Reference in new issue View Git Blame Copy Permalink