This next series of posts was heavily informed by the post by Chris at http://idle-logic.com/2014/07/12/virtual-com-port-connection-de0-nano-vj-uart/
In my drafting for the next in this series, I was toying with the idea of doing some simple comms; maybe with a humorous title like “BeUARTiful” or “I2C what you did there”. I didn’t just drop those ideas because of the terrible puns, but because other people have tackled UART, and while I will loop back for it at some point, there’s a more urgent subject we can wrestle with. As you may have inferred from the title, I am referring to the wondrously named “Joint Test Action Group”. I have to admit, the acronym bothers me as it appears to be used variously to describe the people who defined the standard, the mechanism, and the tooling used – BUT importantly, not a connector standard.
A lot of focus has been turned onto JTAG of late, especially in it’s capacity as a potential attack vector for embedded devices, and that tends to increase the amount of chaff around a subject as people talk loosely of “JTAGGING” a device – but on the other end of the scale you’ll find that when attempting to explain JTAG they’ll just point you to a state machine diagram that you can stare at for a fair while wondering at what point it’s supposed to make sense.
In the spirit of finding the middle ground then, we’re going to focus first on what we are going to be using JTAG to do, then build out from there. In essence, we’re going to be using the mechanisms that JTAG provides to read and write some simple state data from an FPGA design for the purpose of debugging – and for this we’re going to go back to our very first design, the counter. Our revised specification is going to look like this:
The device described will be a one digit second timer. On power on, it will display zero seconds indicated by a zero in the left-hand segments. Each second, the number of seconds displayed will be incremented until it reaches 9 – at the 10th second the count will return to zero.
In addition, the device will support interfacing through JTAG to provide the following debugging functionality:
- A method of setting the current time value
- A method by which to pause the counter
- A method to run the counter
- A method to reset the counter
- A mechanism by which to report the current time value
- A method to toggle the counter direction
Not too daunting, and in fact all but the last of those items could be easily implemented by wiring off some push buttons and tying up the appropriate logic, but having to add and remove hardware and all its associated de-bouncing, pin assignments and so on is a lot of effort to go to when we’ve already got a JTAG connection running to our board. Also, rather than manually prodding buttons we’re going to be able to set up specific scripts that we can use to automate the testing of our unit, making tests nicely repeatable. The eagle-eyed reader will already have noticed that we’ve got a bit of a regression in functionality here. The original counter was capable of driving two digits of display – why have we gone down to one? To keep this series as cheap as possible for someone to follow along with, I’ve made this design fit into the same MAXII board we used for the first counter; the Altera JTAG components take a significant amount of space on the chip.
Next post, we’ll be tackling the physical and logical layers of JTAG, and starting out on the implementation of our counter: until then!