Drift Chamber Firmware Download Description

Transcription

1 Document # Date effective 2 December 2004 Author(s) Pradeep Nagarajan, Ryan Herbst Supersedes Draft Revision 0.02, December Document Title

2 CHANGE HISTORY LOG Revision Effective Date Description of Changes 0./02 12/2/2004 Fixed errors in flow diagram. Page 2

3 1. DEFINITIONS AND ACRONYMS Acronyms Overview System Level Description Control / Status Register Version Tracking Image Size Technical Details Optimizations Status Page 3

4 1. DEFINITIONS AND ACRONYMS The following terms, abbreviations, and acronyms are used in this document: 1.1 Acronyms ADB LVDS ROIB FEA Amplifier Digitizer Board Low Voltage Differential Signaling Readout Interface Board Front End Assembly, Includes ROIBs & ADBs Page 4

5 2. OVERVIEW The proposed system is to make possible, the reprogramming of the configuration PROM on the FEA On-board, so that it is not required to manually replace the configuration PROM every time there is a design revision and there is the comfort of standby prom to test the design revisions. The system works as follows: VHDL CODE with new design revisions XILINX Design Manager Configuration Data Stream for the new firmware As a SVF file C++ PROGRAM Converts SVF file to custom format to program the JTAG interface of the FLASH PROM MAIN PROM Holds a tested correct version of firmware, to fallback in case of errors FLASHPROM Has a JTAG interface over which the FPGA programs it FPGA Buffer space for the chunks of configuration data stream from the DCH ROM used to program the flash prom STATE MACHINE Takes in data from the buffer space and programs the JTAG interface of the flash prom C Link DCH ROM Breaks the configuration bit stream (o/p of C++ file) into chunks and send down C Link Page 5

6 3. SYSTEM LEVEL DESCRIPTION The VHDL code for the new firmware is first compiled on a Xilinx Design Manager which gives a SVF (Serial Vector Format) File, which is an Assembly Language Equivalent of the actual Binary File used to program the PROM. The SVF is a standardized format to interact with a JTAG interface and contains a list a commands to work the TAP controller (state machine) inside the JTAG interface controller. The exact way Xilinx Programs a FLASH prom using parallel jtag cables is proprietary. Hence the procedure adopted here is to read the SVF file generated by Xilinx and convert the file to a convenient protocol, which can then be used to control the Jtag interface controller. For this purpose a C++ file has been written to read in the SVF file and convert it to a binary file of the desired protocol. When it is desired to program the Flash Prom, the DCH ROM sends a command down the C- Link, which triggers the prom-program state machine in the FPGA. The DCH ROM then send a chunk of the configuration bit stream such that the chunk has an integer number of SVF commands, to the FPGA. The reason to break the configuration stream is that, the FPGA does not have enough memory to store the whole data stream. The prom-program state machine in the FPGA on receipt of this data stream, generates the appropriate signals to send down the 4 control pins on the JTAG and it does so at a reduced frequency of 7.5Mhz to program the PROM. The DCH ROM all this while keeps polling a status register through the D-Link, to check if the state machine has finished the programming, and if it has finished it sends down the next chunk of configuration data stream. The prom-program state machine maps every command to a set of control signals on the 4 pins of the JTAG to cause one of the 16 allowed state transitions on the JTAG. The status register also maintains a list of errors, which track the errors of transmission down Page 6

7 the C-link, and errors on write and read back of the same memory location. Between two chunks the of data stream, the clock to the JTAG is held low. There is no loss of functionality in doing so, as the JTAG is only sensitive to the rising edge of the clock and nothing else. 3.1 Control / Status Register The handshake between the ROM software and the FPGA state machine is performed through a control/status register. This register allows the software to monitor the state of the state machine and as well as control its operation. The control/status register contains the following bits. State Machine Start: This control bit forces the state machine into its init state. At this time the state machine is waiting for the first chunk of program data from the ROM software. Done Bit: This bit is asserted once the state machine has processed that last data chunk fro the ROM software. This bit is automatically cleared as soon as the next chunk of data is received. Error Bit: This status bit indicates that the state machine has experienced and error. This can occur during either the program sequence or the verify sequence. Prom Select Bit: This control bit determines which of the two external PROMs is selected for FPGA program. Any time this bit is updated the external D latch will be set. This can also be used as a status bit to determine which PROM the currently running image was loaded from. FPGA Reload Bit. Setting this bit forces the FPGA to reload its configuration using the PROM select with the previously described bit. State Machine Enable: This is an 8 bit vector that must be set to a know value before the state machine will respond to a start bit set of received chunks of data from the ROM. This vector is designed to avoid the possible corruption of the secondary PROM when spurious data is set down the CLINK. In order to program the prom the following sequence must be followed. Page 7

8 o Set proper vector to State Machine Enable bits in control register. o Set start bit in State Machine control register, can t be done in the same write as the vector itself. o Send initialization sequence to the state machine address. o Send chunks of data to the state machine address. Verify Error Address: This value contains the address of the byte that failed in the last chunk of data. The byte address is the offset within the last chunk of data. This error occurs when the SDRMASK, SIRMASK, SDRMASK1 or SIRMASK1 commands are sent. Verify Error Data: This value contains the actual data read when the verify error occurred. Can be used in debugging to determine the source of the error. 3.2 Version Tracking With the ability to download new firmware comes the headache of tracking which firmware is currently running. A version register is available which indicates to software information about the image that is currently running. The details of this version register or contained in another document. 3.3 Image Size The actual image store in the configuration PROM is roughly 5Mbits in size. The data send down the CLINK to program and verify this image will be slightly larger due to the protocol overhead. The estimated image program / verify time is on the order of 5seconds. The limiting factor in this time is the slow JTAG clock that is used to write data into the PROM. IN some case it may take about 10seconds to perform the initial erase of the PROM before the download sequence is started. The command file is broken into chunks that are no more than 32Kbits. This size is limited by the ROM implementation. The actual size sent down the link will depend on the format of the generated command file. Commands will never be split into two chunks. Page 8

9 4. TECHNICAL DETAILS Following are the list of commands in the protocol. SDR: Equivalent to the SDR command of SVF format without any check on the out coming bits on the TDO line Format: (0000 xxxx) (xxxxxxxx ) (xxxxxxxx xxxxxxxx ) In the first part the first 4 bits signify the type of command, the next 4 bits specify the end stable state for that command. The 2 nd part specifies the size of payload following it. It can be max of 32 bits The 3 rd part is the actual payload of size given by the 2 nd part SDRMASK: Equivalent to the SDR command of SVF format with check on the out coming bits on the TDO line with a given mask Format: (0001 xxxx) (xxxxxxxx ) (xxxxxxxx.) (xxxxxxxx ) (xxxxxxxx..) In the first part the first 4 bits signify the type of command, the next 4 bits specify the end stable state for that command. The 2 nd part specifies the size of payload following it. It can be max of 32 bits The 3 rd part is the actual payload of size given by the 2 nd part. The 4 th part is the check bits of tdo line of size given by 2 nd part. The 5 th part is the mask bits to signify which bits to check on tdo of size given by 2 nd part. SDRMASK1: Equivalent to the SDR command of SVF format with check on the out coming bits on the TDO line assuming a mask of all 1 s.this command is used to optimize the fact that 99% of the time the mask is all 1 s. Format: (0010 xxxx) (xxxxxxxx ) (xxxxxxxx.) (xxxxxxxx ) In the first part the first 4 bits signify the type of command, the next 4 bits specify the end stable state for that command. The 2 nd part specifies the size of payload following it. It can be max of 32 bits. The 3 rd part is the actual payload of size given by the 2 nd part. The 4 th part is the check bits of tdo line of size given by 2 nd part Page 9

10 Similarly The corresponding commands for the SIR command in SVF are SIR: Equivalent to the SDR command of SVF format without any check on the out coming bits on the TDO line. Format: (1000 xxxx) (xxxxxxxx ) (xxxxxxxx xxxxxxxx ) SIRMASK: Equivalent to the SDR command of SVF format with check on the out coming bits on the TDO line with a given mask. Format: (1001 xxxx) (xxxxxxxx ) (xxxxxxxx.) (xxxxxxxx ) (xxxxxxxx..) SIRMASK1: Equivalent to the SDR command of SVF format with check on the out coming bits on the TDO line assuming a mask of all 1 s.this command is used to optimize the fact that 99% of the time the mask is all 1 s Format: (1010 xxxx) (xxxxxxxx ) (xxxxxxxx.) (xxxxxxxx ) STATE: Equivalent to the STATE cmd in the SVF but has only one stable state as payload.any other complex STATE cmd can be broken into the above simple STATE cmd. Format: (0100) (one of 4 valid stable states rep. In 4 bits) RUNTEST: Equivalent to the RUNTEST cmd but specifies only in terms of TCK Format: (1100) (one of 4 valid stable states rep. In 4 bits) (payload of max of 32 bits) Page 10

11 5. OPTIMIZATIONS To optimize the fact that for the payload size, less than 32 bits are enough, the minimum number of bits required as calculated by the C++ program are passed as parameters by the data stream to the prom-program state machine in FPGA. ENDDR, ENDIR Cmd in SVF format are integrated along with the end states of the SDR/SIR Cmd. TIR, TDR, HIR, HDR Cmds of the SVF format are not supported since we do not program proms, which are connected in chains. It is always a single PROM. Page 11

12 6. STATUS The current status of the firmware download implementation is as follows: The C++ code to convert the SVF file into a custom command set has been completed. Some minor enhancements still need to be added. The VHDL coding is mostly complete. A few minor issues are still being worked out. The on board testing is expected to start within a week or two of the publishing of this document. The goal is to have the firmware well tested before the prototype board is installed in the running system which may occur at the end of January. Page 12