Timing diagram of CPX and PCX
Hi, everyone!
I have some questions about figure 3-4 and figure 3-6 of "OpenSPARCT1_Micro_Arch.pdf", the timing diagram about PCX and CPX 's one packet request .
According to the document, "The timing for CPX transfers is similar to PCX transfers with the following difference梩he data ready signal from the CPX is delayed by one cycle before sending the packet to its destination." But why ?
What is the reason of CPX's data ready singal being delayed by one cycle?
Message was edited by:
Seven7
[535 byte] By [
Seven7a] at [2007-11-27 7:39:28]
# 1
Hello Seven7,
> According to the document, "The timing for CPX
> transfers is similar to PCX transfers with the
> following difference梩he data ready signal from the
> CPX is delayed by one cycle before sending the packet
> to its destination." But why ?
>
> What is the reason of CPX's data ready singal being
> delayed by one cycle?
>
Not sure if I really understand your question. The short answer is that th CPX block must conform to the timing requirements of the interfaces on either side. For example, in Figure 3-6, The first three signals are the interface between L2 banks and the CCX block. Here, the requirement is that the request signal must precede the data packet by one cycle. The grant signal is returned to the L2 bank when the arbiter selects the given L2 bank. This could be on the third cycle at the earliest, but could be later if a different source was selected in that cycle.
The last two signals in the timing diagram are on the interface between the CCX and the core. Here the requirement is that the request signal occurs on the same cycle as the data packet. There is no grant from core to CCX, because the core is able to take as many packets as the CCX block can send.
NOTE: We found out the hard way . . . It's debatable whether the CCX->core request is even needed. The Valid bit of the packet cpx_spc0_data_cx2[144] is what determines that the data is accepted by the core. So don't assume that you can just hold the data in the cycles after you sent it, or the core will receive multiple copies of the data packet.
Does this help?
formalGuy
# 2
> Hello Seven7,
>
>
> > According to the document, "The timing for CPX
> > transfers is similar to PCX transfers with the
> > following difference梩he data ready signal from
> the
> > CPX is delayed by one cycle before sending the
> packet
> > to its destination." But why ?
> >
> > What is the reason of CPX's data ready singal
> being
> > delayed by one cycle?
> >
>
> Not sure if I really understand your question. The
> short answer is that th CPX block must conform to the
> timing requirements of the interfaces on either side.
> For example, in Figure 3-6, The first three signals
> are the interface between L2 banks and the CCX
> block. Here, the requirement is that the request
> signal must precede the data packet by one cycle.
> The grant signal is returned to the L2 bank when
> the arbiter selects the given L2 bank. This could
> be on the third cycle at the earliest, but could be
> later if a different source was selected in that
> cycle.
>
> The last two signals in the timing diagram are on the
> interface between the CCX and the core. Here the
> requirement is that the request signal occurs on the
> same cycle as the data packet. There is no grant from
> core to CCX, because the core is able to take as many
> packets as the CCX block can send.
>
> NOTE: We found out the hard way . . . It's
> debatable whether the CCX->core request is even
> needed. The Valid bit of the packet
> cpx_spc0_data_cx2[144] is what determines that the
> data is accepted by the core. So don't assume that
> you can just hold the data in the cycles after you
> sent it, or the core will receive multiple copies of
> the data packet.
>
> Does this help?
>
> formalGuy
Yes, you help me a lot! Thank u!
