Close

TAP summary & protocol

A project log for YGREC8

A byte-wide stripped-down version of the YGREC16 architecture

Yann Guidon / YGDESYann Guidon / YGDES 07/29/2020 at 15:340 Comments

First, here are the logs that describe the design of the Test Access Port :

4. The YGREC debug system contains the first high-level description, the principle applies equally for any technology/implementation.
16. Inspect and control the core
24. Synchronous Serial Debugging
25. MUX trees
109. Gray counter (reboot of the low-level design)
110. The art of large MUXes
111. The first half of the TAP
112. Design of a TAP : the SIPO Controller
113. The TAP's bits counter
114. The TAP selector
115. The TAP is coming together
118. The TAP's eXecute module
119. The TAP crosses 3 clock domains !
.


This log summarises the high-level view from the debugger's perspective. The TAP is "just" a low-level port, a few pins that serialise data in and out of the core, and could be implemented in whatever way (the current TAP is serial but could be made in byte-parallel for the relay version for example).

This TAP is obviously byte-oriented and designed for SPI mode 0 : this eases programming a lot because most CPUs have a byte-oriented SPI controller. Using variable sized framing would operate slower on platforms such as the Raspberry Pi for example. JTAG often handles sequences of bits in groups other than 8...


Timing

The diagram below shows the typical timing with only one transmitted byte shown:

The TAP works as 2 phases in half-duplex, so Din and Dout may share a tristate pin for example. The /WR pin controls the phase and things happen during these transitions.


The MUX

For practical reasons, the Y8 has a selection of 64 bits to provide a (partial but sufficient) snapshot of the core's state. Instead of reading all the registers, only 4 byte values are available (SND, SRI, Result & PC), which already amounts to 32 bits. The remaining bits are further halved by providing the current instruction (16 bits). The rest is shared by the Status Flags (C, S, Z : 3 bits), the FSM status and a free byte (possibly multiplexed with the scan chain for a loopback test).

In a sense, the order matters little because the bits are scrambled anyway. With the serial TAP, the user must stream 64 bits every time to get everything (this is not the case though for the scan chains and this saves some time). However it's "good" that they fit with the structure of the tree, so it helps with place&route. "Just in case" I placed the fields in increasing order of granularity and relevance to the debugger (in case a byte-wide, or non-scrambled, interface is developed).

TAP/MUX64 allocation of the inputs :
8 bits : Status (Flags & FSM)
8 bits : (undefined, variable, switchable, maybe the selector address ?)
16 bits : Current Instruction being decoded
8 bits : PC
8 bits : RES
8 bits : SRI
8 bits : SND

Notes:


The scan chains

The previous logs have already defined a number of messages :


More messages will appear later, for example for the trap mechanism.


Init sequence

The TAP can be initialised by writing to registers that have no /RESET input (most).

  1. NULL command
  2. "1S" command -> strobe the TAP internal RESET signal tied to register bit 1.
  3. NULL command (again : end of strobe)
  4. Send NOP to Execute : 000'X' (clear the instruction register and ongoing commands)

Here is how it looks with Wavedrom:

And the last part :

.
.

.
.

Discussions