The State. (Machine, not “Chicken Sandwich, Carl!”)
Although the SVF file will give an explicit sequence of events, the programmer still needs to know how to properly traverse the TAP state machine, for example to get the chip to the SHIFTIR state where an instruction can even be shifted into the device. And later, to get from SHIFTIR to SHIFTDR where data for that instuction would be shifted in. When a specific path through the state machine is required, the SVF file will contain an explicit STATE x y z… statement. If no specific path is required, then the programmer is assumed to take the shortest path. So we’ve got to implement some shortest-path JTAG TAP walking software, and THEN – we promise you – it’s just a matter of churning data. Let’s take a look at that TAP, shall we?
Fig 1 – State Diagram of the JTAG TAP controller
This be a state diagram. It’s an organizational method for logic design in sequential systems. Get four flip flops together and you can make a 0 to 15 binary counter – neat! On every clock, the next output will be one more than the present output. Totally simple so far. But if you put some logic in between the outputs of those flip flops and their inputs, then you can create different paths through the outputs of the counter. Here: 4 bits, 16 counts. But the paths are obviously a little more complex than just the simple X = X+1 of a binary counter, although they only depend on one additional logic input – TMS – who controls what path we take through the machine. If TMS is high when TCK rises, then we would take a “1″ path. If TMS is low, we’d take a “0″ path. Each state has two possible exits because TMS has two possible states. After that, it’s all up to you – your state machine can be simple, or a tangled monstrosity. You have 16 states and can use them in any way you like. NOTE: Good logic design actually frowns upon transitions between states that differ by more than one bit, but it is not a hard and fast rule. Look up State Machine K-Map for more info.
Now you can make your system even more complicated! By adding logic to make each state perform a different function, you can generate well organized but pretty sophisticated control with just a handful of gates. In the case of the TAP controller, some states send and receive data, some execute previously stored commands, some explicitly skip that execution in hopes of doing it later, and others do nothing. State machines are cool, and for how simple the TAP is it turns out to be quite powerful. Maybe you should consider exploring state machines – take your CPLD and make a couple of state machines for fun sometime. An elevator and a soda machine (complete with making change) are classic examples of simple state machines that are often used in homework assignments. Well, after you’re tired of the reset glitch, maybe.
Back to the diagram. Please note that the red state annotations (0×0 through 0xF) are arbitrary labelling. Other implementations may designate them differently, but for our purposes this simple 0-15 numbering sequence will be fine. The bubbles hold the name of the state, and the 1/0 arrow paths tell you the TMS value to use in order to get from one state to another. So for example: To get from state 3 (Capture DR) to state 5 (Exit1-DR), the user would raise TMS to a logic 1 and give a clock on TCK. If the user wanted to go from 3 to 4, then TMS should be low when you clock TCK. For the states where data is shifted into the device (0×4, 0xB), we take advantage of the TMS=0 loopback to keep the TAP machine held in the present state while we clock in data over many TCK cycles.