Dear Supporter,
In IHI0098A chi c2c spec Chapter B2.1, message transfer structure from CHI interface to chip pins can be formed of the following layer:
• Protocol layer• Packetization layer• Link layer• Physical layer
There are some question about the handshake releate signal.
1. When the Protocol layer prepare to initiate a state change request (Active -> Low Power), Accroding to the UCIe arch, Since the state reqeust initiated, during the chi-c2c dapapath in Packetization layer and the Link layer will be stalled.
So I wish to know the recommended behavior of the following CHI interface when state change into Low Power:
LINKACTIVEREQ, LINKACTIVEACK
SYSCOREQ, SYSCOACK
2. Also when the Protocol layer prepare to initiate a state change request (Active -> Inactive status) ,such as disable/linkreset/linkerror in UCIe. since such a state request initiated, the datapath will be flushed and reset,
So similarly, I wish to know the recommended behavior for the above signal when state change into Inactive
From my understanding now, i thought it's safe for all the necessary handshake to be completed before the state request change from Active, so during the state change period, the handshake signal releated c2c message will have no risk to be stalled or flushed in local die, and the handshake signal should not change during the state changing period. When the state change done, the handshake signal can be changed again with no risk.
I wish to know your opinions.
Best Regards
Hi Lingfang,
This is not currently an area where there are specific requirements from the C2C specification perspective.
Based on my understanding of the UCIe requirements, I would agree with what you say below for the requirements on the protocol layer for PM entry and other states like LinkError/LinkReset/Disabled.
In terms of the CHI link activation and coherency/DVM states, I would also agree that the cleanest scenario to think about would be for an orderly sequencing of the various handshakes, e.g. when doing PM entry, make sure to disconnect coherency/DVM first, and then deactivate the link.
However, focussing for example on the PM entry/exit case, depending on the specific use case that one implementation intends to support (e.g. a simpler "link sleep" case versus a complete device power down), I believe in some circumstances it may also make sense to not disconnect coherency/DVM, include some storage at the gateway and then relying on the ability to exit PM if/when there is protocol traffic to be transmitted.
Similarly, for things like LinkError states it may not always be possible to prepare the protocol layer in advance of the event, in which case other procedures to flush/reset the protocol layer state may be necessary.
Maybe not the most helpful of replies, but hopefully it conveys the message that there is a range of possibilities and use cases to consider.
Best Regards,
Simone