Any details about invalidation packets?
Hi All!
MicroArch presents the format of Evict Inv Packet. The data of the Inv packet consist of {INV1 +6(pa) +112(inv)}. But there isn't any details about INV1 and inv.
In sparc_ifu_invctl.v, the Inv Packet(ifd_inv_ifqop_i2) is Muxed as follows:
***************************************************************************
mux4ds #(1) v0p0_mux(.dout (inv_vec0[0]),
.in0(ifd_inv_ifqop_i2[1]),
.in1(ifd_inv_ifqop_i2[9]),
.in2(ifd_inv_ifqop_i2[17]),
.in3(ifd_inv_ifqop_i2[25]),
.sel0 (invcpu21_sel_i2[0]),
.sel1 (invcpu21_sel_i2[1]),
.sel2 (invcpu21_sel_i2[2]),
.sel3 (invcpu21_sel_i2[3]));
***************************************************************************
I am not clear about the function of those bits of ifd_inv_ifqop_i2.
Any hints will be welcome!
Thanks in advance!
[896 byte] By [
openideaa] at [2007-11-27 3:28:26]
# 1
We are working on better documentation for the core/cache crossbar interface. In the mean time, here is what I have been able to dig up on the invalidation vector.
A quick review: The D-cache line size is 16 bytes, while the I-cache line size is 32 bytes.
For the D-cache, bits 5 and 4 of the physical address (PA[5:4]) are the lower two bits of the cache index. For the I-cache, PA[5] is the LSB of the index. (In L2, PA[5:4] are part of the cache line offeset, because the line size in L2 is 64 bytes.
Here is the format for the 112-bit invalidation vector:
Bits 31:0 This is a series of 8 4-bit fields which indicate which way is to be invalidated for D-cache indexes PA[5:4]==00 or I-cache indexes PA[5] ==0.
Bits: 31:28core #7
xx00: no invalidation
ww10: D-cache invalidation of way ww
wwx1: I-cache invalidation of way ww
(It is assumed that there can't be a match in both D-cache and I-cache)
. . .
Bits: 3:0Core #0
xx00: no invalidation
ww10: D-cache invalidation of way ww
wwx1: I-cache invalidation of way ww
(It is assumed that there can't be a match in both D-cache and I-cache)
Bits 55:32 are a series of invalidation bits for D-cache indexes matching the pattern PA[5:4]==01. (Note that I-cache invalidations with PA[5]==0 was handled abov)
Bits: 55:32Core #7
xx0: no invalidation
ww1: D-cache invalidation of way ww
. . .
Bits 34:32Core #0
xx0: no invalidation
ww1: D-cache invalidation of way ww
Bits 87:56 are similar to bits 31:0. They specify invalidations for D-cache indexes with PA[5:4]==10 or I-cache invalidations with PA[5]==1
Bits 111:88 are similar to bits 55:32. They specify invalidations for D-cache indexes with PA[5:4]==11.
Other bits of the invalidation vector:
Bits 117:112: Specify PA[11:6]. These address bits supply the remaining bits of the I-cache or D-cache index to be invalidated. I-cache index is PA[11:5], while D-cache index is PA[10:4]
Bits 120:118: Specifies the CPU ID.
Bits 122:121: Specifies PA[5:4]
Bit: 123: D-cache invalidate all. A packet with this bit set is returned to the core in response to a load request with bit 111 (invalidate). This tells the core to invalidate all ways of the D-cache for the given index.
Bit 124: I-cache invalidate all. Tells the core to invalidate all ways of the cache for the given index.
I hope this helps. We hope to have better documentation of this interface in the next release.
# 2
Hello Again,
In my last post, I had the I-Cache and D-cache invalidation bits reversed in two places in the invalidation vector. The correct bit assignments are shown here.
Bits 31:0 This is a series of 8 4-bit fields which indicate which way is to be invalidated for D-cache indexes PA[5:4]==00 or I-cache indexes PA[5] ==0.
Bits: 31:28 core #7
xx00: no invalidation
ww10: I-cache invalidation of way ww
wwx1: D-cache invalidation of way ww
(It is assumed that there can't be a match in both D-cache and I-cache)
. . .
Bits: 3:0 Core #0
xx00: no invalidation
ww10: I-cache invalidation of way ww
wwx1: D-cache invalidation of way ww
(It is assumed that there can't be a match in both D-cache and I-cache)
Bits 55:32-- These bits were correct in the original post.
Bits 87:56 are similar to bits 31:0. They need the same correction as above.
Hope this helps.
