-
Notifications
You must be signed in to change notification settings - Fork 10
JTAG Tunnel
The JTAG debug tunnel provides a bridge from PC-based test code to IP running on an Antikernel SoC.
DRAFT OF PROTOCOL
| 1 | 1 | 10 | 10 | 10 | |
|---|---|---|---|---|---|
| ACK | NAK | SEQUENCE | CREDITS | ACK_SEQUENCE | ... |
| 1 | 23 | 8 |
|---|---|---|
| PAYLOAD_PRESENT | RESERVED_23 | HEADER_CHECKSUM |
- ACK (1 bit): Frame contains an acknowledgement
- NAK (1 bit): Frame contains a negative acknowledgement
- SEQUENCE (10 bits): Frame sequence number (0-1023)
- CREDITS (10 bits): Number of 128-bit words left in the receiver's buffer
- ACK_SEQUENCE (10 bits): Frame sequence number being ACKd or NAKd
- PAYLOAD_PRESENT (1 bit): Frame is extended and contains a payload section
- RESERVED_23 (23 bits): Padding to extend the frame to fit in a 32-bit word
- HEADER_CHECKSUM (8 bits): CRC-8 checksum of the frame header (ACK+NAK+SEQUENCE+CREDITS+ACK_SEQUENCE+PAYLOAD_PRESENT+RESERVED_23)
| 1 | 1 | 10 | 10 | 10 | |
|---|---|---|---|---|---|
| ACK | NAK | SEQUENCE | CREDITS | ACK_SEQUENCE | ... |
| 1 | 1 | 1 | 11 | 10 | 8 | |
|---|---|---|---|---|---|---|
| PAYLOAD_PRESENT | RPC | DMA | RESERVED_11 | LENGTH | HEADER_CHECKSUM | ... |
| ... | |
|---|---|
| PAYLOAD | ... |
| 32 |
|---|
| PAYLOAD_CHECKSUM |
- ACK (1 bit): Frame contains an acknowledgement
- NAK (1 bit): Frame contains a negative acknowledgement
- SEQUENCE (10 bits): Frame sequence number (0-1023)
- CREDITS (10 bits): Number of 128-bit words left in the receiver's buffer
- ACK_SEQUENCE (10 bits): Frame sequence number being ACKd or NAKd
- PAYLOAD_PRESENT (1 bit): Frame is extended and contains a payload section
- RPC (1 bit): RPC payload
- DMA (1 bit): DMA payload
- RESERVED_11 (11 bits): Padding to extend the frame to fit in a 32-bit word
- LENGTH (10 bits): Number of 32-bit words in the PAYLOAD section
- HEADER_CHECKSUM (8 bits): CRC-8 checksum of the frame header (ACK+NAK+SEQUENCE+CREDITS+ACK_SEQUENCE+PAYLOAD_PRESENT+RPC+DMA+LENGTH+RESERVED_11)
- PAYLOAD (variable): Packet data
- PAYLOAD_CHECKSUM (32 bits): CRC-32 of the extended section (PAYLOAD)
All integer fields use network byte order (MSB first). Checksums are calculated in network byte order.
Each control frame header consists of the ACK, NAK, SEQUENCE, CREDITS, ACK_SEQUENCE, PAYLOAD_PRESENT, RESERVED_23, and HEADER_CHECKSUM.
Each extended frame consists of the control frame as a header base, and extends it to add the PAYLOAD and PAYLOAD_CHECKSUM sections. It also uses part of the RESERVED_23 section to add RPC, DMA, and LENGTH sections. The RESERVED_11 section is then used in place of the RESERVED_23 section.
The ACK and NAK bits are used in a one-hot configuration. (except for the first frames after link start/reset before the link is established) The ACK bit is set when the ACK_SEQUENCE is acknowledging a properly received frame. The NAK bit is set when the ACK_SEQUENCE is acknowledging an improperly received or missed frame.
The SEQUENCE is used to show which frame in the serial stream it is. This is used to ACK or NAK received frames, and used to check that all frames come in the correct order, and none are missing.
The CREDITS section is used to report how many 128-bit words of free space are left in the receive buffer. This is used to implement a flow control mechanism to buffer frames until the other side has enough free buffer space to receive the next frame.
The ACK_SEQUENCE section is used to identify which frame is being ACKd or NAKd. If this is a frame right after link start/reset (before the link is established) then this is expected to be set to zero.
The PAYLOAD_PRESENT bit is used to indicate if the frame is extended and contains a PAYLOAD and PAYLOAD_CHECKSUM sections. This also means some of the normally RESERVED bits are used for more header information for the PAYLOAD. (RPC, DMA, and LENGTH)
The RESERVED_23 section is used as padding to fill out the control frame to the 32-bit word boundary and is expected to be set to zero. This section is used ONLY in control frames, and is replaced with RESERVED_11 in extended frames.
The RESERVED_11 section is used as padding to fill out the extended frame to the 32-bit word boundary and is expected to be set to zero. This section is used ONLY in extended frames, and is replaced with RESERVED_23 in control frames.
The RPC and DMA bits are used in a one-hot configuration in to indicate what type of packet the PAYLOAD contains. These bits are ONLY used in the extended frames, otherwise they are part of the RESERVED_23 section.
The LENGTH section is used to indicate how many 32-bit words long the PAYLOAD section is. This section is ONLY used in the extended frames, otherwise this section is part of the RESERVED_23 section.
The HEADER_CHECKSUM is the CRC-8 (using the ATM HEC polynomial, x^8 + x^2 + x^1 + 1) of the preceding 56 bits that comprise the frame header.
The PAYLOAD section holds one or more 32-bit aligned words of packet data. This section ONLY exists in extended frames.
The PAYLOAD_CHECKSUM section holds the CRC-32 (using the Ethernet polynomial, x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x^1 + 1) of the PAYLOAD section. This section ONLY exists in extended frames.
The purpose of this protocol is to encapsulate the NoC packets and transmit them over a full duplex serial interface (JTAG/SPI) and preserve data integrity. The protocol also implements retransmission and flow control.
Data integrity is preserved by labeling each frame with a SEQUENCE number and verifying each received frame is in sequential order, as well as verifying the CHECKSUM(s) (HEADER_CHECKSUM and PAYLOAD_CHECKSUM) of each frame. The SEQUENCE number is incremented each frame, starting from 0, up to 1023, and then wrapping back around to 0 again.
When a frame is properly received (in order SEQUENCE and correct CHECKSUM(s)) it is acknowledged in the next transmitted frame by setting the ACK bit and the received frame's SEQUENCE number in the ACK_SEQUENCE section.
If a side received a number of valid frames while it was sending a long frame (thus unable to ACK the received frames) then it can simply ACK the last properly received frame to acknowledge that frame and all previously received and unACKd frames in it's next transmission.
Both sides keep a FIFO buffer of sent frames that have not been ACKd yet. The buffer is used for retransmission when a frame is lost or corrupted. When an ACK is received the frame is removed from the buffer. When a NAK is received, the frame that was NAKd and all frames after it are retransmitted from the buffer.
If a frame with an out of order SEQUENCE number or bad CHECKSUM is received, then all following data frames are ignored, and the next outgoing frame will have it's NAK bit set with the frame SEQUENCE number to start retransmission from set in the ACK_SEQUENCE section.
If a frame's header checksum is incorrect it is considered a critical error and the link must be reset. This is due to the possibility of an unknown length payload frame, and if the header is corrupt then we do not know it's length, and thus can not regain synchronization without a link reset.
The host counts the number of errors in a row received on the link. This includes received NAKs and CRC failures. If the number of errors is above a threshold then the link is considered out of sync, and must be reset.
Each transmitted frame sets the number of 128-bit words left in that side's receive buffer in the CREDITS section of the frame. The other side uses this information along with the ACKd sequence number, and a counter of how many words have been transmitted since that ACK to know how many words of buffer space are available on the other side. This is used to implement flow control, and buffer frames until the receive buffer has enough free space for the next frame.
Control frames are always legal to send regardless of CREDITS state as control frames are not buffered.
If the frame contains packet data then the PAYLOAD_PRESENT bit is set, the RPC or DMA bit is set (depending on which network the packet is for), the number of 32-bit words in the PAYLOAD are set in the LENGTH, the packet data is contained in the PAYLOAD section as 32-bit words, and the PAYLOAD section's CRC-32 checksum is set in the PAYLOAD_CHECKSUM section. It is considered a critical error if both RPC and DMA bits are set/unset (not one-hot) when the PAYLOAD_PRESENT bit is set.
When the link is first started or reset it is not considered to be established until the first frame is received from the other side. During this period neither side has any received frames to ACK or NAK, so both ACK and NAK bits are unset (and ACK_SEQUENCE is zero) until the first frame is received. This is the ONLY time in which both ACK and NAK being unset is valid. After that point if a frame is received with both ACK and NAK unset, it is considered a critical error. It is also considered a critical error if both ACK and NAK are set at any time.
Frames are sent constantly back to back even when there isn't any information to send because the hardware layer is constantly clocked and we need a way of knowing that no data is being sent. We use what we call "idle frames" for this. This is just an ACK control frame without a payload. (or a control frame without ACK or NAK set and ACK_SEQUENCE set to zero for the first frames before the link is established)
If the host side encounters a critical error (such as receiving a frame with both ACK and NAK set) it resets the link. If the DUT side encounters a critical error it rejects the frame by sending a NAK. If the host continues to retransmit the invalid frame the DUT will continue to return NAKs and the host's error counter will trip and reset the link.
If an anomaly occurs and the two sides are out of sync then the link must be reset by the host. (the host is the only side responsible for link reset) This is done out of band, over JTAG: leave SHIFT-DR and return, SPI: deassert CS and then reassert.
Link reset means both sides unACKd FIFO buffers are flushed, receive buffers are flushed, SEQUENCEs set to zero and all other state reset. Any data in the buffers are lost during reset. This may change in a future protocol version.