Trip-T Front End Board Documentation Home

In System Reprogramming

System Overview

Access to the revisions data memory is achieved through the PROM JTAG interface. This is a 4 signal, single master bus, designed originally for the testing of boards. It allows multiple slave devices to be chained together and uses broadcast control signals to shift the state of the slave devices between instruction and data registers.

The PROM manufacturer issues somewhat limited instructions on how to implement ISP for their devices, the usual route being through the implementation a SVF Player. This takes a standard command format (SVF) and interprets it into JTAG bus transactions. This way they can hide the internal workings of their devices. Whilst tantalisingly accessible, this route presents some drawbacks for the TFB.
  1. The SVF format tends to be pretty verbose. This means that a fairly large quantity of to-in and fro-ing would be required over the TFB-RMM link making the reprogramming operation more time consuming.
  2. Somewhat more importantly, the SVF player would give unrestricted access to the PROM programmability.
Ignoring the first point as simply the idiosyncratic musings of somebody who likes a certain amount of elegance present in his systems, let's move on the second point. Unrestricted access means that at some point in the future, when all the TFBs are installed and relatively inaccessible, somebody might decide on a User Firmware change and wish to load it into the PROM. It would be possible, not only to overwrite the Bootloader, but also to change the unique TFB ID, since this is stored in the User Code area of the PROM.

You know it would happen, and you know who you are. The system needs to be "Academic proof".

One could, in principal, implement a SVF Player Watchdog, but this seems counter intuitive - the whole point of the Player would be to give full access to the PROM. Alternatively, a low level system programmer with restricted functionality hard coded in would do the trick, since anything not wanted could just be omitted, and this is what I've done.

Hardware Design Choices

To simplify the JTAG transactions required to access the PROM, the two distinct JTAG busses were placed on the TFB, one connecting the PROM to a programming header and user IO pins on the FPGA, the second connected only to the FPGA JTAG port. These are labeled PL4 and PL5 respectively.

The PROM chosen was a xcf16p. This has two revision areas, each 8 MBits in size. Each revision region is organised internally as 32768 rows, each 256 bits wide.

Required Functions

The system is required to:
  1. Read the User Code from the PROM
  2. Place the PROM in ISP mode
  3. Unlock the PROM
  4. Issue an ERASE command to ONLY Revision area 1
  5. Issue the correct start address for the address counter (0x0100000 for revision 1)
  6. Load 32768 rows of 256 bits
  7. Issue a Program command for each row (and wait for programming to complete between each)
  8. Read back the contents of the PROM revision
  9. Check the status, and abort the operation if an error occurs during the process
  10. Exit from ISP mode
  11. Reset the TAP controller
A lot of the information needed to implement this is not only not documented, but also considered proprietary. A large amount of experimentation was required to arrive at a working implementation.

User Interface

Due to the fixed functionality of the system, it has a fairly simple user interface.
Readback
The possibility exists, at any time providing that the controller is idle, to read back the contents of revision 1. Issuing a configuration readback trigger by writing a 0x40 to register 0x0 will result in the entire contents of the revision memory being serialised line by line as 32768 packets with a payload 16 words long. The first line is emitted first.

Once this process has been started, it waits for no further signals and takes around 8s to complete. The bandwidth of every part of the system is higher than that of the JTAG interface, which is run at about 1Mbit/s. Additionally, the data volume is 1MByte, so this shouldn't cause problems.

Serial packets are emitted from logical pipe id 0x3. Should there be a reason to stop, issuing a hard reset to the TFB will do so.
Reset TAP
At any point, providing the system is idle, the TAP (Test Access Port) controller can be reset by issuing a 0x100 trigger. This process takes about 6μs to complete.
Reload User Firmware
This is the most complex operation, and is initiated by issuing command trigger 0x20. Once started, only a reset will interrupt the process, which proceeds as follows.
  1. The PROM is put into ISP mode, and the unlock command issued.
  2. The ERASE command is issued to revision 1 only. This takes around 35 seconds to complete during which time the ERASING, and BUSY flags in the will be asserted in the JTAG Controller Status Register.
  3. Once the erase is complete, the state machine tries to read data from the Firmware Upload FIFO. This is 32kBytes deep. Once in this phase the JTAG Master FSM operates on the data line by line. The flow control is not implemented more finely grained than that. For this reason, it is not acceptable to upload packets comprising partial lines. This is done for efficiency purposes. The partial full and partial empty flags are provided to allow the uploading and reading process to operate asynchronously in an efficient manner. After each row is loaded, it must be programmed into the PROM data array. This approximately 500μs per row is allowed for this. The minimum time, thus, that the array can be loaded in is just over 16s.
  4. Once the JTAG Master has loaded and programmed the last line, readback begins immediately, and is identical to the process described in the Readback section above.
  5. When Readback has completed, the JTAG Master returns to an idle state. The process may be repeated, or a reload into the newly programmed User Firmware may be attempted. It is the responsibility of the FPN to check that data sent back from the TFB matches that which was uploaded.
Error Handling
Throughout the reloading process, the JTAG Master continuously verifies that the PROM has not asserted any error flags. The moment that an error condition is detected, an error code is set in the least significant 4 bits of the Status Register, and the contents of the PROM status register are latched into the JTAG Controller Error Register.