CPX Packet ID

Hi,

we are interested in understanding the logic that generates the Packet ID that is returned to the SPARC Core through the CPX packet. At the beginning we supposed that the Packet ID in the CPX return packet was equal to the Packet ID of the corresponding PCX request packet, but this supposition was wrong.

Actually if we look at the first fetch operations performed by the SPARC Core when it wakes up we can see the following (obviously PA = Physical Address):

- fetch from I/O region, PA 0xFFF0000020, PacketID=3

- the return packet has PacketID=1

- fetch from I/O region, PA 0xFFF0000024, PacketID=1

- the return packet has PacketID=1

- fetch from I/O region, PA 0xFFF0000028, PacketID=1

- the return packet has PacketID=1

- fetch from I/O region, PA 0xFFF000002C, PacketID=2

- the return packet has PacketID=1

- fetch from I/O region, PA 0xFFF0000030, PacketID=2

- the return packet has PacketID=1

- fetch from I/O region, PA 0xFFF0000034, PacketID=1

- the return packet has PacketID=1

- fetch from I/O region, PA 0xFFF0000038, PacketID=3

- the return packet has PacketID=1

- fetch from I/O region, PA 0xFFF000003C, PacketID=0

- the return packet has PacketID=1

- fetch from RAM Bank 3, PA 0x00000400C0, PacketID=1

- the return packets have PacketID={0,0}

- fetch from RAM Bank 3, PA 0x00000400C0 (again), PacketID=2

- the return packets have PacketID={0,0}

- fetch from RAM Bank 3, PA 0x00000400C0 (once again), PacketID=0

- the return packets have PacketID={0,0}

- and so on

Could you please explain which CPX Packet ID the SPARC Core is expecting in the returning packet?

Many thanks,

Fabrizio

[1778 byte] By [fabrizio.fazzino] at [2007-11-26 10:35:08]
# 1
Which bits are you printing out in the PCX/CPX packets that correspond to "PacketID"?
t1eval at 2007-7-7 2:45:20 > top of Java-index,Open Source Technologies,OpenSPARC...
# 2

As in iop.h, PCX PacketID is in bits [108:107] and CPX PacketID in bits [131:130]:

`define PCX_P_HI108 //PCX packet ID, 1st STQ - 10, 2nd - 01

`define PCX_P_LO107

`define CPX_P_HI131 //CPX packet ID, 1st STQ - 10, 2nd - 01

`define CPX_P_LO130

The CPX packet in the same bits can also carry the following informations:

`define CPX_WY_HI132 //CPX replaced I$/D$ way

`define CPX_WY_LO131

`define CPX_BF_HI130 //CPX buffer ID field - 3 bits

`define CPX_BF_LO128

so it can be that I'm printing out the wrong information: anyway I need to understand the logic behind the generation of the bits in these positions, so some hint will be greatly appreciated!

Many thanks in advance,

Fabrizio

fabriziofazzino at 2007-7-7 2:45:20 > top of Java-index,Open Source Technologies,OpenSPARC...
# 3

Looks like iop.h comments are bogus

for PCX, 108:107 is actually the L1 "way" information that the directory needs.

You can see the description in 3.1.5 of this document:

OpenSPARCT1 Microarchitecture Specification August 2006

Many of the fields are not well defined in that document though.. I'm going through the RTL to answer some questions myself.

t1eval at 2007-7-7 2:45:20 > top of Java-index,Open Source Technologies,OpenSPARC...
# 4
Packet ID as defined in iop.h is not used in thecurrent design, earlier design was using it, but iop.h was not updated to reflect the design change. So please ignore packet ID definitions in PCX/CPXin the iop.h.
OpenSparc at 2007-7-7 2:45:20 > top of Java-index,Open Source Technologies,OpenSPARC...
# 5

So is it possible to have a clear description of the fields used in the PCX/CPX packets?

We do not need all the possible packets (13+15) but only the field description for the three following PCX/CPX couples:

IMISS_RQ / IFILL_RET

LOAD_RQ / LOAD_RET

STORE_RQ / ST_ACK

Many thanks,

Fabrizio

fabriziofazzino at 2007-7-7 2:45:20 > top of Java-index,Open Source Technologies,OpenSPARC...