Second International Conference on Emerging Trends in Engineering and Technology, ICETET-09

Reliable High Speed Data Acquisition System using FPGA

Samrat L. Sabat, Ajay Kumar D, P. Rangababu School of Physics University of Hyderabad Hyderabad, 500046 Email: slssp@uohyd.ernet.in, d.ajay402@gmail.com,p.rangababu@gmail.com

AbstractThis paper presents design and implementation of a Data Acquisition System (DAS) in Field Programmable Gate Arrays (FPGA) using System on Chip (SoC) methodology. To ensure the reliability of data being transmitted over the Channel, a suitable framing interface along with error detection is proposed and interfaced with Xilinx Aurora IP core. The proposed DAS is capable of transmitting the data a 1.25 Gbps over the channel. The main advantage of the proposed DAS is that the conguration and monitoring is done using the in-built PowerPC processor of FPGA through Universal Synchronous Asynchronous Receiver Transmitter (UART). This type of DAS is suitable for multi channel acoustic data acquisition and in Electronics Warfare systems. Keywords-FPGA, SoC, DAS, Aurora

section IV. II. AURORA P ROTOCOL Aurora protocol is a free, lightweight, scalable and linklayer protocol developed by Xilinx to transfer data across point-to-point using serial links. It can be implemented in any silicon device/technology. It has built in capability to frame data packets, procedures for ow control, data striping, and validate high-speed serial links through initialization[2]. Its transparent interface to the physical serial links provides exibility for use in high-speed serial links. This leads to higher connectivity performance while preserving software infrastructure investment. It is an efcient low-latency protocol that uses the least possible amount of logic. It offers a rich, highly congurable feature set. Aurora increases bandwidth through unlimited bonded lanes. It needs little time to integrate with existing user designs. Being lightweight, Aurora is best suited for serial point-topoint connectivity [3]. Figure 1 presents the block diagram of Aurora protocol. Aurora protocol has many features that attracts its use in high speed applications. Some of the important features are High bandwidth transmission limited only by Serializer/Deserializer (SERDES) capability Unlimited bonded lanes for high aggregate bandwidth and future expansion Supports Full Duplex and Simplex channels Unlimited Frame size or exible framing Versatile connectivity between chips, boards, backplanes Builtin Flow control Simple and effective User Interface Although Aurora protocol can be used for high speed data communication but it does not have any mechanism to detect the error caused during communication [4]. The following subsection describes the error detection mechanism interfaced with Aurora for secure data communication. A. CRC In this paper we are using CRC technique for error checking in data transmission through Aurora protocol. Basically CRC is an error detecting code and is used for detecting the accidental alteration of data in an efcient

I. I NTRODUCTION DAS plays a major role in modern electronic instruments. As the technology advances DASs are simplied and made more accurate, versatile, and reliable through electronic equipment. It is always a challenge to design high speed and reliable DAS for acquiring signal from acoustic, radar and sonar signal sources. In recent years FPGA are found signicant applications in these elds. In earlier days FPGAs were used to implement glue logic, carry out signal processing, and even for prototyping a system using SoC. Now a days, due to technology development and huge market demand, FPGA are equippled with many feature such as soft and hard core processors, million of logic gates, dedicated multipliers etc. This leads to use FPGA in many cost effective embedded system design and applications[1]. For high speed data communication Xilinx has developed Aurora protocol which supports the data rate of 1.25Gbps. The existing Aurora protocol does not have error correction mechanism. For applications like Electronics Warfare and Sonar signal processing, error detection is an important factor for reliable data transmission. If any error occurred in data frame then necessary action has to be taken for generating handshaking signals. This paper presents a design and implementation of a data acquisition system that supports error checking mechanism using cyclic redundancy check (CRC) technique. Rest of the paper is organized as follows: Section II briefs about Aurora Protocol and its features. Section III presents design of DAS followed by conclusion and future work in

978-0-7695-3884-6/09 $26.00 2009 IEEE

392

Figure 1.

Aurora Communication Full-Duplex or Simplex

Figure 3.

ADC Controller

Figure 2.

Data Acquisition System (DAS) Block Diagram

manner. An n-bit CRC, applied over an arbitrary length data, will detect any single error burst not longer than n bits. In other words, any single modication that has occurred in nbits of the data will be effectively detected by a n-bit CRC. CRCs are more useful than alternative schemes such as multiple parity checks in data transmission channels, where errors are bursty. Popularly used 32 bit CRC Polynomial such as 0x4C11DB7, 0xEDB88320 [5], are recommended IEEE standards and used by Ethernet, POSIX check sum Utility, etc.In this paper we have used 0x4C11DB7 as a CRC polynomial for error detection. III. DAS D ESIGN The proposed architecture of DAS that we have implemented and tested is shown in Fig. 2. The system acquires data from a four, twenty-four bit; eight channels Analogue to Digital Converter (ADCs), in either of the serial format i.e. Serial Peripheral Interface (SPI),or Frame-Sync format, available in ADC. In SPI Format the data read operation is initiated by DRDY signal of ADC whereas in case of Frame-Sync format the data read operation is initiated by F SY N C signal of ADC controller. Data to be read from the ADC is indicated by the falling edge of DRDY output and the data will be shifted out on the falling edge of the Serial Clock (SCLK ), MSB rst as shown in Fig. 4. Frame-Sync format operates in slave fashion, i.e., the user need to supply the framing signal (F SY N C ) and SCLK . The data comes out after the detection of raising edge on the F SY N C , MSB rst

as shown in Fig. 5. When using Frame-Sync format, the F SY N C and SCLK inputs must be continuously running with the relationships shown in the Frame-Sync Timing diagram Fig. 5. But in SPI format SCLK may be either in free-running mode or active during only in acquiring period. For best performance, the ratio fSCLK /fCLK is set to one among the factors of 1, 1/2, 1/4, 1/8, etc. This factor is decided by the ADC characteristics. It is strongly recommended to keep SCLK as clean as possible to prevent glitches from accidentally shifting the data. The proposed ADC controller is shown in Fig. 3. It receives data in the serial format from the ADC and converts it into parallel format for further processing. It is able to handle both the formats that are available in ADC (i.e. SPI and Frame-Sync). The SCLK and F SY N C signal for the Serial Data transfer formats will be generated from the ADC controller. The value of SCLK is chosen such that fSCLK /fCLK is 1/8. The Data obtained in serial format is given to a Serial in Parallel out (SIPO) module that produces output in twenty four bit parallel format for all eight channels. Control signals for the generation of F SY N C , SCLK and for SIPO are generated by the Control Unit inside the ADC Controller. The congurations of the ADC for mode selection (i.e. High-Speed, High-Resolution, Low-Power, or Low-Speed), Power down of the channels, Test mode selection (i.e. Normal Operation, Boundary Scan test), Clock Divider Control for High Speed, Low power, Low speed, Format selection (i.e. SPI, Frame-Sync), are programmed through the Processor using Control Registers. The status of ADC can be monitored from status registers. The acquired data is fed to Digital Down Converter (DDC) controller, which suppress the samples by a predened factor given by the user. It also increases the bit width to 48 from 24. The data, output from DDC controller is stored into a Memory. In the proposed architecture of DAS, an arbiter will select data from either of the two memories i.e., Data Memory or Response Memory. The arbitration from the data memory to other memory will be carried out based on the availability of the data or response in the respective memory. The data transmission starts from a memory depending on which asserts rst. The data memory is designed in such a way

393

Figure 4.

SPI Format

Figure 6.

Aurora TX Local-Link Interface

width becomes 40 bits [6]. LineRate = U SRCLK DAT AW IDT H = 31.25M Hz 40 = 1.25Gbps The Aurora core can be generated with either a framing or streaming user data interface with suitable ow control options. The framing user interface complies with Xilinx Local-Link Interface specication and generates the core. It comprises the signals necessary for transmitting and receiving framed user data [7]. The core samples data in synchronous with the positive edge of U SER CLK and when both T X DST RDY N and T X SRC RDY N are asserted (Low). The user application can de-assert the signal T X SRC RDY N on any clock cycle; this will cause Aurora to ignore the Local-Link input for that corresponding cycle. If this occurs in the middle of a frame, idle symbols are sent through the Aurora channel, which eventually result to an idle cycles. This idle cycles are discarded automatically in the receiving side. Local-Link data is valid within a frame, and data outside this is ignored. To start a frame, T X SOF N is asserted when the rst word of data is on the T X D port. To end a frame, T X EOF N is asserted when e the last word (or partial word) of data is on the T X D port as shown in Fig. 6. When the Aurora core receives an data frame, data moves into user interface through the RX Local-Link interface after discarding the framing characters, idles, and clock compensation sequences. The RX LL submodule has no built in elastic buffer for user data. The only way for the user application to control the ow of data from an Aurora channel is to use one of the cores optional ow control features. A FIFO is used in the RX data path to ensure no data is lost while ow control messages are in transit. The Aurora core asserts the RX SRC RDY N signal, when the data on its RX Local-Link interface are valid. RX SOF N is asserted concurrently with the rst word of each frame from the Aurora core. RX EOF N is asserted concurrently with the last word or partial word of each frame. The RX REM port indicates the number of valid bytes in the nal word of each frame. It uses

Figure 5.

Frame-Sync Format

that it will not wait for entire memory to get full, but is divided into slices such that whenever one slice is full then the transmission starts. Frame formation and generation of necessary control signals to support the Local-Link interface of the Xilinx is implemented using the tx data framer module as in Fig 2. The control signals for the User ow control (UFC) is also generated in this module. The data to be transmitted is sent through tx crc 32 module, that will perform a 32-bit CRC on the entire frame and will append the computed CRC at the end of frame. The polynomial used in this design is 0x4C11DB7. It also generates the necessary control signals to make compatible CRC frame with Aurora Local-Link Interface. Aurora is used for transmission of the data over the channel at a line rate of 1.25Gbps. The core is generated using Xilinx core generator tool with the following specications.
Aurora Core Generator Specications Silicon Version Aurora Lanes LaneWidth Interface Dataowmode Flow Control Line Rate Reference Clock Frequency : : : : : : : : Engineering Silicon (ES) 1 4 bytes Framing Duplex (UFC) + Immediate Mode - NFC 1.25 Gbps 100MHz

The core was simulated in Modelsim and found that it is working with User clock period of 32.0 ns (31.25 MHz). The core is generated for 4 byte Line width and since Aurora core uses 8b/10b standard for encoding, the effective data

394

Figure 7.

Aurora RX Local-Link Interface

Figure 9.

Chipscope pro triger setup

Figure 8.

Data switching Circuit

IV. I MPLEMENTATION AND R ESULTS The DAS is implemented on V irtex R 5 FXT FPGA ML507 Evaluation Platform board. In this Implementation we have loop backed the data, instead of connecting another FPGA, and inserted Chip Scope-Pro for Debugging. The monitoring and debugging of signal are done through Chipscope-Pro.
Synthesis Results Slices 111085 LUTs 8731 GigabitIOs 1 PPC440 1 Max. Frequency (MHz) 199.988

the same encoding as T X REM and and is valid when RX EOF N is asserted as shown in Fig. 7. To send a UFC message, the user application asserts U F C T X REQ N while driving the U F C T X M S port with the desired code length i.e., 8/16/32 bit. U F C T X REQ N must be high until the Aurora core asserts the U F C T X ACK N signal, indicating that the core is ready to send the UFC message. The data for the UFC message is placed on the T X D port of the data interface, starting on the rst cycle after U F C T X ACK N is asserted. The core de-asserts T X DST RDY N while the T X D port is being used for UFC data as in Fig. 8 [8]. On Receiver side, CRC is performed on the data received from the Aurora over the channel. Upon successful reception of the data the receiver sends the UFC message. That message indicates weather the packet received is having error or not .If there is an error, by seeing the message, transmitter retransmits the entire frame. It will retransmit three times and even if the error persists, transmitter will assume that there is some error in the channel and discards the whole frame and continues with normal data transmission. The received data will be stored into a memory. Another Important component in the design is the on-chip embedded Processor; Power PC 440, which is used to monitor the entire system and for setting the conguration values for ADC controller. If any command is received from the receiver it will send response to the transmitter and will be stored in response memory. The conguration settings of the processor will be given through UART.

To verify the data received properly, the following strategy has been employed. We have checked the condition of CRC error signal to be logical one. If is triggered to 1 then we can conclude that the data received by the designed DAS has an error. For verication purpose approximately 5 Hrs of data frame has been sent and received by the DAS. It is veried from Chipscope Pro, that the DAS is error free as it waits indenitely for detecting the error. To validate this fact, Fig. 9,10 presents a screen shot of Chipscope pro when CRC error signal is triggered. V. C ONCLUSION AND F UTURE WORK In this paper we proposed a DAS of 1.25 Gbps Line rate with CRC error detection option. We investigated the working principle of Aurora core with different user clock frequencies. The proposed DAS has the capability to detect the error and retransmit the data frame incase of any error is detected. The validation of this is done using Modelsim and Chipscope pro tool. The reliability of the system is achieved by 32 bit CRC. Future work will focus on the

395

ACKNOWLEDGEMENT The authors are thankful to Research Center Imarat, Defence Research and Development Organisation, India for providing necessary support to carry out research work. R EFERENCES
[1] J. Gray, Designing a Simple FPGA - Optimized RISC CPU and System-on-a-Chip, Fundamental Science and Apllications, vol. 13, no. 1, pp. 174180, 2006. [2] J. S. Mrinal and H. Puttashamaiah, A High-Speed Serial Connectivity Solution with Aurora IP, Xcell, vol. 621, no. 61, pp. 2629, 2007. [3] S. Trynosky, Serial Backplane Interface to a Shared Memory, Xilinx Inc., Tech. Rep. Xapp648(v1.1), 2004. [4] D. Barker, The Right Stuff : FPGAs Fit EW and ISR System Needs, V METRO, Inc, Tech. Rep. VME 2089, 2007. [5] K. Brayer, Hammond, and J. J, L, Evaluation of Error Detection Polynominal Performance On the AUTOVON Channel, in Proceedings of NationalTelecommunications Conference, New Orleans,La, Institute of Electrical and Electronics Engineers, New York, December. 1975, pp. 2125. [6] Xilinx, Virtex-5 FPGA RocketIO GTX v2.1 User Guide, Xilinx Inc., Tech. Rep. UG198, 2008. [7] M. J. Sarmah. and H. . Puttashamaiah, Point-to-Point Connections for High Speed Serial Connectivity Solutions, Wireless design - Asia, vol. 636, no. 1, pp. 1520., 2008. [8] Xilinx, Virtex-5 FPGA Aurora v3.0 User Guide, Xilinx Inc., Tech. Rep. UG353, 2008.

Figure 10.

Chipscope pro results of DAS

implementation of FFT module in FPGA and according to demand, the DAS will transmit either time domain or frequency domain data. The switching control can be done with a suitable processor in FPGA. This DAS is suitable for applications like Electronic Warfare, Sonar and Radar multi channel data acquisition.

396