A Networked Control/Data Acquisition System Based On The ColdFire Microprocessor. Abstract Nose Cone Colorimeter Control (N3C) is a highly dynamic system used for slow data acquisition (DAQ), remote system control, and environmental monitoring. The N3C project utilizes an embedded ColdFire processor with the Quadros real time operating system (RTOS) which acts as a bridge between an array of hardware devices and remote-controlling machines over the TCP/IP network protocol. The requirements of this project were to build a network capable device to program field-programmable gate array (FPGA) devices such as Xilinx and Altera. While such network-FPGA-programmers are available on the market they all only do one task, our specification called for a way to interface with other buses of the system and DAQ. ColdFire microprocessor N3C utilizes the feature rich ColdFire microprocessor which allows for easy access to a number of buses such as I 2 C, QSPI, UART, JTAG and GPIO. With the help of the N3C software one can quickly develop custom tools to remotely interface with devices via these buses Application In the case of the Nose Cone Colorimeter, N3C is used to interface with most of the buses supported by ColdFire, JTAG is utilized for FPGA configuration and the systems slow control, I 2 C as a bridge to a Dallas 1-Wire bus which in turn is used for environmental monitoring and control, QSPI for slow DAQ read out. The N3C system is controlled via a simple control protocol over TCP and DAQ is transferred over UDP to reduce the network overhead at the cost of reliability. FPGA Implementation ● n3c: ColdFire EVB M5235 from Freescale ● 32-bit RISC CPU ● 144 MIPS, 150 Mhz ● 16MB SDRAM ● 2MB flash ● Board size: 3.5”x2.2” ● OS: Quadros RTXC/ss (12KB) ● TCP, UDP: optimized OpenTCP stack ● Development tools: gcc m68k cross-compiler stack under Linux ● Debugging tools: BDM port interfaces directly with GDB ● JTAG players:based on open source codes (XSVF player from XILINX and JAM/STAPL player from ALTERA) N3C System Performance: ● Network ● TCP 1.5MBytes/s ● UDP 2.2MBytes/s ● FPGA configuration (1M-gate XC2V1000): ● XSVF player: 2.2s ● STAPL player: 8.5s ● Data/control transfer speed ● JTAG between host and FPGA on a PCB, 100Kbyte/ ● Monitoring data transfer using SPI from FPGA to host: 2MByte/s 1-Wire Bus As part of the environment monitoring subsystem we've implemented an easy way to interact with 1-Wire devices using the DS2482 bridge. Using a single 1- Wire bus one can connect many 1-Wire devices using only one signal line and a ground, this allows for easy integration of sensors, switches and other devices into PCB designs. Up to four DS bridges can be connected to one I 2 C line without the need of a switch. If more 1-Wire chains are needed it would be trivial to either install a switch or move to the DS master which allows to have up to eight masters per I 2 C line and eight 1-Wire chains per master, for a total of thirty-six 1-Wire chains using one un-switched I 2 C line. Four our application, we've written drivers for the following devices: ● 1-W master/I2C Bridge (DS2482) ● Thermometer (DS18B20[x]) ● ADC (DS2450) ● Potentiometer (DS2890) ● PIO Switch (DS2413) ● Adding new ones is trivial Real World Application: NCC, Silicon-Tungsten Calorimeter for PHENIX Forward Upgrade at RHIC Collider ● Slow control and test readout of stripixel detectors. 86K channels ● Slow control and test readout of silicon pad detectors. 72K channels ColdFire MCF523X Features During the course of this project we've optimized Quadros RTOS supplied TCP/IP stack (a modified OpenTCP implementation) for our applications resulting in a ten-times performance increase. This optimization makes it feasible to use N3C as a slow (2MBytes/s) DAQ system. Built with flexibility in mind, N3C was developed to work on two versions of the ColdFire processor, the MCF5282 and MCF523x. Such flexibility allows for easy integration of new features and utilization of this system in projects other than the Nose Cone Colorimeter Upgrade. Compression For further improvement we plan to implement a compression schema into our DAQ system. While we have only tested compression a desktop machine the results are promising. Utilizing a variant of Hashemian coding described in the paper entitled “Condensed Table of Huffman coding, a New Approach to Efficient Decoding” by Reza Hashemian, it is possible to compress data just as well as with Huffman coding but decompression requires less memory and time. The trick lies in a clever assignment of compression codes. After the computation of symbol code lengths the symbols are sorted by code lengths, and the code word can be calculated by this simple formula: code=(lastCode + 1 ) << ( lastCodeLen - codeLen). For decompression, the bitsream is matched against a table (CHT) containing only the locations of where lengths of codes change and its respective code, and code length. This yields in a lot fewer comparisons as that of plain Huffman coding where one needs codeLength comparisons to match a symbol. For example, decoding the string “this is an example of a Huffman tree” from Hashemians compression requires anywhere from 1 to 3 comparisons per symbol and a total of 63 while in plain Huffman it requires from 3 to 5 comparisons per symbol and total of 135. During the decompression procedure for Hashemian based coding, one systematically compares maximum code length bits of the bit stream against successive code word in CHT while the bitstream is greater than the code word. The the index of the symbol is computed by subtracting the CHT code word from Code Length bits of the bitstream. Acknowledgments I would like to express my deepest gratitude to Andrei Sukhanov and Edward Kistenev who have taken me on board for this project. Also, extend my thanks to Department Of Energy as well as Office of Educational Programs for their support and care. DAQ PCB JTAG to LVDSN3C Huffman based tree Compressed Huffman Table (CHT) Look up table of symbols Hashemian Based tree