SPRUI30H November 2015 – May 2024 DRA745 , DRA746 , DRA750 , DRA756
The TILER requires a 4-GiB addressing space to map its 128-MiB physical container in four modes and eight orientations. Because its addressing space alone fills the 4-GiB global system address map, the TILER addressing space cannot enter as-is into the system address map. Besides, putting in place a register-based mechanism per initiator to specify the orientation of the following accesses and then reducing the TILER addressing space to a single 512-MiB view is not an option; this is because most of the bandwidth-hungry initiators require simultaneous accesses to the TILER container in different views.
As a result, 32 bits are not enough to address all these requests, because the TILER port must convey not only virtually addressed requests to the "oriented" TILER containers but also physically addressed requests to the attached SDRCs. A thirty-third address bit is necessary to distinguish the two separated address maps, as shown in Figure 15-37.
Still, having separated systems and TILER-specific address maps is not sufficient. In a system many existing and external IP blocks still rely on a 32-bit address and would then be limited to one or the other 4-GiB addressing space. To overcome this limitation, one 512-MiB view is aliased in the system address map as (see Table 15-14 and Figure 15-38).
Start Address (hex) | End Address (hex) | Size |
---|---|---|
0x6000_0000 | 0x7FFF_FFFF | 512 MiB |
From all incoming requests, TILER requests are filtered as having an address that fits one of the following:
Other requests are forwarded directly to the SDRC in TILER bypass mode.
32 | 31 | 30 | 29 | 28 | 27 | 26 ... 4 | 3 ... 0 |
---|---|---|---|---|---|---|---|
T | Orientation | Mode | Virtual address | ||||
1 | S | Y | X | M1 | M0 | A26 ... A4 | 0 |
32 | 31 | 30 | 29 | 28 | 27 | 26 ... 4 | 3 ... 0 |
---|---|---|---|---|---|---|---|
T | TILER aliasing | Mode | Virtual address | ||||
0 | 0 | 1 | 1 | M1 | M0 | A26 ... A4 | 0 |
In these address formats:
The orientation of the aliased TILER view is extracted from an initiator-indexed LUT, as shown in Figure 15-38.
As shown in Figure 15-38, an internal initiator-indexed LUT stores the current orientation of the aliased view for each initiator.
When an interconnect request hits the TILER aliased view in the system address map, the request initiator orientation is extracted from the LUT and the request address is translated according to this orientation: the T bit is set and bits [31:29] are replaced with the orientation.
Regarding the dimensioning of this LUT, given that initiators simultaneously accessing multiple views use the TILER-specific address map, and many initiators do not need to access any view or can be restricted to accessing only the natural view, only a limited number of initiators are likely to dynamically modify the orientation of its aliased TILER view.
The orientation LUT is limited to 16 entries. These 16 orientation entries are mapped on the two 32-bit DMM_TILER_OR0 and DMM_TILER_OR1 registers.
The first eight entries of the LUT are mapped in the DMM_TILER_OR0 register, and the last eight entries are mapped in the DMM_TILER_OR1 register. Therefore, given an index x, the orientation related to this index is given in the ORx field.
Each of these registers is split into eight 4-bit fields, each field mapping an entry of the LUT with:
The registers fields that correspond to initiators that do not need any dynamic configuration of their aliased view orientation must be specified as reserved fields, and only written with zeros.
The W bit allows the modification of a single entry without requiring a read-modify-write sequence. This approach is then more accommodating:
Still, the W bit is active-low to keep the compatibility with the usual read-modify-write sequence. When reading an aliased view orientation register, because all its W bits are read as 0, if these bits are untouched by the modification—as they should be—writing back the modified register updates all orientation fields of the register.