When I read "3.1.5 CPX and PCX Packet Formats" in OpenSPARCT1_Micro_Arch.pdf,
I can not find details about the usage of the CPX or PCX packets such as "Load","I$fill (1) L2,IOB","Fwd req" and so on.
I think they are different from sparc instructions, but looks a little like instructions.
Can anyone help me and tell me the usage of these PACKET?
Thanks.
> When I read "3.1.5 CPX and PCX Packet Formats" in
> OpenSPARCT1_Micro_Arch.pdf,
> I can not find details about the usage of the CPX or
> PCX packets such as "Load","I$fill (1) L2,IOB","Fwd
> req" and so on.
> I think they are different from sparc instructions,
> but looks a little like instructions.
> Can anyone help me and tell me the usage of these
> PACKET?
> Thanks.
Where do you find such packets "Load","I$fill (1) L2,IOB","Fwd req" ?
I can't find them in 3.1.5.
Would you please show more details about your question?
I find them in the document--"OpenSPARC T1 Microarchitecture Specification"
in the chapter--"CPU-Cache-Crossbar"
The orign content is :
" 3.1.5 CPX and PCX Packet Formats
TABLE?-1 and TABLE?-2 define the CPX packet format, and TABLE?-3 and TABLE?-4 define thePCX packet format."
You can find these tables by the key word "Rtntyp" . And in these tables'
title are the pkt type
And my question is what cause these pkt formed, and what these pkt aim to.
For example, I know "Store Ack" is formed by L2$ and aimed to notify L1D$ to update.
But what about others pkt?
Any suggestion is welcome.
The documentation of the Core/CCX interface is really not complete, especially for people who intend to use a single core, and design their own surrounding logic. I have been working on a supplement to chapter 3 which covers everything a designer would need to know to interface to a core. I'll try to get it posted in the next couple days.
In the mean time, here are a few quick examples of how the different packet formats are used:
1. When the instruction fetch unit misses in the I-cache, the core will send an Ifill PCX packet to load the proper cache line. If the address is non-cacheable, the system will return a single CPX Ifill response packet. If the address is cacheable, the system will
return two CPX Ifill response packets, to fill the entire cache line.
2. When a load or prefetch instruction misses in the data cache, a PCX load request packet will be sent out. The system will respond with a CPX load response packet, which contains the proper cache-line data.
3. Any store instruction causes the store data to be placed in the store queue. Then the core sends a PCX store request to L2. The L2 will then update data in L2 if it is cacheable, and will return a CPX store-ack packet. If the data is seen in an I-cache
or D-cache in a different core, the L2 instructs the other core to invalidate its copy. If the data is found in the D-cache of the core that sent the request, the L2 instructs it to update the D-cache.
4. If any floating-point instruction is executed that is not handled within the floating-point front-end block (FFU), then a floating-point request signal is sent to the floating-point block (shared by all 8 cores). The FP block will complete the operation, and send results back via the CPX FP packet.
These are just some examples. Let me know if you have more questions
formalGuy
The Fwd req, and Fwd reply packets are mostly used for testing. The JTAG port of the OpenSPARCT1 ties in with the input/output bridge (IOB), but the IOB does not have direct access to the L2 banks. Therefore, to enable debugging, the IOB is able to access the L2 banks through the CCX interface. Here's how it works (I think). The IOB sends a Fwd req CPX packet to one of the cores. The core then forwards the packet to an L2 bank by sending a Fwd req PCX packet. The L2 Bank then responds to the request by sending a Fwd reply CPX packet back to a core, and the core then forwards the response back to the IOB by sending a Fwd reply PCX packet.
The CAS(1) and CAS(2) packets are sent in response to a CAS (compare and swap) instruction. Compare and Swap is an atomic operation in which data is compared against a value in memory and if the values are equal, another piece of data is written to memory. The value in memory is returned regardless of the compare result.
The core sends two packets for a CAS operation; the first contains the compare data, the second contains the swap data. The L2 will first load the line and return a CAS return packet (identical to a load return) on the CPX. It will then compare the data and make a second pass through the L2 pipe. If the compare was true, the data from the second packet will be stored. If the compare was false, memory will be unchanged. Regardless of the compare result, the L2 will send a CAS ack (identical to a store ack) on the CPX. If the compare was true and the store occurred, the directories must be checked as on a block init store (i.e., any hit causes invalidation). It is implementation dependent whether the directories are checked and invalidated in the case where the compare was false.
Swap/Ldstub (ldstub is simply a byte sized swap where the new data is always 0xff) work similarly to the CAS operation except that the memory write is unconditional. Only a single PCX packet is required for this operation.
Evict Inv is an instruction to a core to invalidate a line in either its I-cache or D-cache. This occurs when the corresponding line is being evicted from L2. Since all lines in I cache or D cache must be included in L2, any eviction of a line from L2 must also invalidate any copies of that line in the level 1 caches.
Hope this helps
