Parameterized diagnostic module implemented in FPGA structures

Transcription

1 Parameterized diagnostic module implemented in FPGA structures Agnieszka Zagoździńska, Krzysztof T. Poźniak, Ryszard S. Romaniuk Institute of Electronic Systems, Warsaw University of Technology, Poland ABSTRACT In the contemporary electronic systems there is a possibility of creating a large number of modules implemented in the PLD structures. There is a requirement to use diagnostic methods in these blocks. Some of the methods are insufficient in some, more complex cases. This paper contains specification of the universal diagnostic module dedicated to supervise and diagnose the complex functional blocks implemented in FPGA structures. This diagnostic module can be extended and adjusted to the needs of many more complex projects. Its size and parameters depend on the designer s need. The module can possess independent structure or it can share some resources with the analyzed project. The designer can use already prepared blocks, expand them or create his own functional blocks. The specified tool gives the opportunity to design more effectively and independently more complex structures from a selected FPGA family. Keywords: Parameterization of electronic circuits, diagnostics, testing, reconfigurable systems, VHDL, FPPGA, object oriented approach to photonics and electronics design 1. INTRODUCTION Contemporary complex electronic systems are designed with the use of a lot of modules. These are interlinked with data transmitting lines. Development of programmable logic device technology and CAD software created wide possibilities for implementation of the devices possessing complex functionality. As a result, the previous diagnostic methods like computer simulation (eg. ModelSim DE Deluxe by Mentor Graphics [1]) and internal signals analysis (eg. Chip Scope Pro by Xilinx [2], Signal Tap II Embedded Logic Analyzer by Altera [3]) became insufficient. Increasingly frequently there is a need to monitor proper working of the routines in the real-time. In particular there is a necessity of the detection of exceptions and their sources, as well as the system diagnosis. There are some relevant references available describing the logic state analyzers built in FPGA structures enabling some level of control [4-6]. Described structures are dedicated to particular applications with limited possibilities of reconfiguration. This paper discusses an universal diagnostic module dedicated to supervise and diagnose complex functional blocks implemented in FPGA structures. This module is parameterized, and there is a possibility of adaptation to particular design solutions. Its complication level and FPGA resources usage depends on the designer. This module can have an independent structure but it can share some resources with the main design, eg. microcontroller unit dedicated to interface service. There is a possibility to use predefined data analysis blocks or the own ones. This diagnostic module can be implemented with any types and series of FPGA structures. The second chapter discusses the architecture of diagnostic module with exemplary solutions. The third chapter contains an example of the structure usage in the real FPGA. 2. UNIVERSAL DIAGNOSTIC MODULE Parameterized diagnostic module allows for internal data analysis in real-time. There is a possibility of triggered data registration and transmitting to the PC computer. Fig.1 presents a general idea of the module architecture. There are diagnosed selected signals from the sets designed by the system users. The analysis and buffering of the data is realized by a parameterized trigger block. There is implemented configuration of the block. Functionality of the block is dependent on the user needs. If the trigger condition is realized, the data is saved. Data registration is realized by a memory block. Data is rewritten into the internal memory of the microcontroller. During these operations, the trigger block is disabled. The microcontroller block realizes data presentation and communication with the user.

2 The trigger block and memory block are completely autonomic structures, while the microcontroller block is able to realize dual functions. It can cooperate with the diagnostic module and at the same time it can be integral part of the user s design. The SPI interface block and other communication interfaces can also be integrated with the user s design and with the diagnostic module in the same structure. Fig. 1: Architecture of the data acquisition module 2.1. Memory block Memory block is realized with the use of basic RAM blocks of constant (static) size. These basic blocks are available as the library components with the producer software. The basic blocks can be changed to be compatible with a particular family and type of FPGA circuit. With the use of parameterization techniques, a memory array is automatically instantiated. Its values of parameters are defined by the user. The use of parameterization technique provides the possibility of automatically instantiation of memory array with the user defined parameters. Some part of data acquisition module is memory controller that suspend data acquisition until the trigger signal is inactive. It also interprets microcontroller signals, that allows faultless data transmission Trigger block The Trigger block contains programmable trigger part with internal RAM memory. It is an autonomic block with the open architecture, that can be modified according to the user needs. The use of programmable trigger allows to alert the system to the faults. There is a possibility of registration the data before and after an exceptional situation. Fig.2 presents architecture of the trigger block. It contains two elements: data registration block, where FIFO memory is implemented. Depth of the memory is dependable on values of the parameters. These parameters define the length of the sequence to be registered. Each configuration of data analysis block implement different value of the delay. To prevent the differences, the length of FIFO memory is expanded to the value of L, that is adjust to each configuration. data analysis block, that analyzes the input data and activates trigger signal in the case of trigger condition fulfill. Active trigger signal runs the data registration. Trigger condition is defined by the user and send to the data analysis block from the computer level. There is a possibility of the user to trigger the configuration implementation, or the

3 use of predefined solutions. There are two kind of configuration: "analog trigger" and "digital trigger". The first one is to analyze the signal level. Trigger signal is activated after the input data exceeds the user defined level. In the second one, the data is interpreted as the bit stream. Some states or sequences of each data stream bits are searched. The trigger condition is dependable on the parameters and the user configuration. This solution allows to register signal sequence that caused some errors. Registered data can be used as the simulation data. It makes the process for error search and finding the causes for errors much easier. Fig.2.Architecture of the trigger block 2.3. Soft-core microcontroller block Data registered already in the acquisition block (trigger block with the memory block) is received by microcontroller block, and then transmitted to the computer. This signal path is presented in fig.3. Moreover, the microcontroller block assures the service for user interface. At the same time, it can be a part of the acquisition system and of the user design. There is a possibility of implementation of the user algorithms. Fig.2: Data flow and control signals flow between the data acquisition module and the user Communication with the computer is realized with UART interface. With the use of USB-RS232 converter maximum speed of communication is bod. Transmitting speed is limited by the microcontroller efficiency. Communication with LCD screen is realized by the SPI interface. The status of the diagnostic module (eg. working mode) is presented on the screen. Screen data presentation is nondependent on the PC communication.

4 The microcontroller is configured with the use of TSK51A core, which is available with Altium Designer environment as the library module "Ip Core". The microcontroller core is equipped with UART interface and it is consistent with instruction of ASM51 by Intel [10-11]. Moreover, TSK51A microcontroller uses a relatively small part of FPGA resources [12], address space is not arbitrarily limited, and there are C language compilers available (eg. TASKING C by Altium, Keil Microvision by Keil) that generate effective executive code SPI interfacer block Apart from the LCD screen, the module communicates with microcontroller with the use of the SPI interface. It is the SPI interface master side block implemented, which is put in microcontroller In/Out ports. On the screen, there is presented information about the diagnostic module state, and optionally data from tested designed which is prepared by the microcontroller block. A dual function of the SPI interface and microcontroller block is to save the FPGA resources. General method of building the diagnostic module in the user application is presented in fig. 4. Fig 3: User application structure 2.5. Integration of the diagnostic module with the user design In the data analysis part of the trigger, a specialized block can be linked with the design to different data processing. It can be input data (A), output data (B), or internal data stream (B).There is a possibility of using of different sources of data analysis or data registration. The microcontroller block allows for the user configuration of the trigger. It is realized as the data transmission from the PC level. Commands with the arguments are formed by the user. Retransmission of the registered data to the computer is automatically launched after the trigger signal interrupts the microcontroller. The design structure allows the designer to adjust the predefined trigger block to the tested design needs. There is a possibility of creating own trigger blocks with the use of the existing structure frame. In the implementation, the user can remove user interface blocks as the LCD screen block with the SPI interface blocs, or adjust the interface to his own needs. This action has no influence on the trigger and memory block working, and

5 decrease the resource usage. In this way, the user interface is not necessary for diagnostic module, but increases the user control level over the design Real time clock module 3. EXAMPLE OF THE USER PROJECT DIAGNOSIS In this chapter there is a description of the real-time clock module as an example of independent user design. This module generates the clock and calendar data. Its architecture is presented in fig.5 There are two main groups of functional blocks: Buttons u1 u3 blocks where is implemented a button service with debugging routines, Calendar and clock generation blocks. Each block contains the universal counter. It is realized as the parameterized library component. It can be adjust to particular design needs: it can realize up counting or down counting to the user defined limits, it can realize asynchronous or synchronous initialization, work in a loop mode, etc. The counter has implemented state outputs: counter start, counting time, last value, and the end of counting. All parent counters of the basic counter are signified on the scheme with the L letter with proper index. On this basis, the clock module is defined with the use of parameterization methods. There is a possibility of bus length change and the clock frequency change. For the implementation, there is a possibility of the range change of all counted values, and for the month counter the possibility of month value and number of leap year change. Fig5: Structure of the real time clock block

6 3.2. Configuration of the diagnostic module blocks for the real-time clock design Activation of the diagnostic module demands first the configuration of the trigger module. If the first configuration is active and the input signal exceeds the user defined signal level, the trigger signal is activated. If the other configuration is active, the trigger block is sensitive to each bit value. Bit value analysis is realized as a pattern comparison, and the result masking. The trigger block functionality for the single bit is presented in fig. 5. a) b) Fig. 5. Signal propagation in the one bit data analysis block a) detection of the proper value b) insensitivity to data and pattern for the mask bit equal zero Each input data bit and represented pattern bit are on the inputs of the XOR gate. If there is a state consistency (fig. 6a), the output gets the value 0. In the next step it is processed with the NAND gate with the appropriate mask bit. Mask value of 1 output negated the result of XOR operation. If the result of these operations is equal to 1 it means the data bit and pattern bit consistency, and the trigger signal changes to high level (active). If the mask bit is changed to 0, the result of data bit and pattern bit values comparison is in the low state. It means that independently on the pattern and data similarity, the result is ignored, and the trigger signal is inactive. With the use of this procedure, all bits of the input data are analyzed. A general functionality for 8-bit data is presented in fig. 7. a) b) Fig.6. Propagation of the 8-bit data signal through the trigger block In fig. 7a, the input data is different to pattern on positions nr. 5 and 7. Because mask bits from 7 to 4 are zeros, the detection of the data and pattern difference has no influence on the result of the operation (compare fig 6b). In fig. 7b, the input data is different to pattern, additionally on position nr. 0. Because mask bits from 3 to 0 are ones, these bits of the result are unmasked and the trigger signal changes its value to 1. Fig 8. presents data flow structure through the trigger block in case of analysis of the registered data stream.

7 Fig. 4: Structure of the data stream flow through the trigger module The use of pattern and mask arrays allows the comparison of single bits of the data stream. On the scheme, there is presented an example of the data analysis registered during 8 clocks. Each clock period means the registration of a new data sequence. In this way, in each clock period the trigger signal is calculated, which changes its value to 1 in case of improper data sequence of the trigger. Fig.5: Registered data analysis in the trigger module Rows and columns of the resulting array Result 2 are added, and the result bit is negated and interpreted as the trigger signal.

8 The example patterns and masks are presented in fig.8. The pattern array allows detection of an assigned bit state sequence. In the presented example XOR function compares 8 successive vectors of the data stream with the pattern array: {8,8,8,8,8,9,9,9}. In the next step, the results are masked with the use of a mask array and AND function. The resulting array contains value 1 on the positions appropriate to positively verified bits. The final result is 1 because one of the unmasked bits is not equal to the pattern bit. In the next clock period the final result will be 0, because the analyzed array will contain values: {8,8,8,8,9,9,9,9}, that is equal to the unmasked part of the pattern Diagnostic module integration with the user design Recommended procedure of diagnostic module and data bus link is presented in fig.9. a) b) c) Fig. 6: Recommended methods of connecting data acquisition module to the diagnosed project: a) data analysis on the entrance bus b) internal data analysis c) external data registration caused by the internal data analysis Diagnostic module allows: a) output data analysis of the design (fig. 10a) - output data is linked with the trigger block input (marked with T letter). In the next step, it is transmitted to memory block and to the multiplexer directly linking the design with the microcontroller; b) module link to the internal design data bus (fig. 10b) - trigger module is built in one of clock block; c) input data sequence analysis, which e.g. caused an error inside the diagnosed module (fig. 10c) exceptional situation is triggered on the basis of internal data analysis. The trigger block is built in one of clock block. Both, the actual and the earlier input data are registered. That allows analysis of the data that cause exception. In table 1 there is presented the level of the resource usage in the FPGA structure (Virtex-5, Xilinx). There is implemented a diagnostic module with tested design in the example configuration that was presented above. Table 1: Resources used by test design with implemented diagnostic module Design with the diagnostic module (simultaneous analysis and registration of 8 clocks, 2048 memory addresses) Maximum path latency ns 18k Block RAM 46 LUT [%] 7,00% 4. APPLICATIONS The paper shows certain standardized design path of electronic functional blocks. These ones are then used for building much more complex electronic and photonic systems, for example for building of measurement, diagnostic and control systems of high energy physics experiments and free electron lasers. Some of the usages of this design approach are described elsewhere [15-50].

9 5. CONCLUSIONS The aim of this design was to prepare a universal diagnostic tool as the parameterized and programmable data analysis and acquisition module. Parameterization methods give to the user the possibility of modification of diagnostic blocks, to the design requirements. The example possibilities of complex trigger and memory structures building are described. Its size is parameterized, and the builder use the producer basic library components. Designed diagnostic module can be modified flexibly. There is a possibility of memory arrays reconfiguration, trigger block modification and adjustment, and also microcontroller change. The interesting future extend possibility is the use of volatile memory (eg. FLASH memory) or FRAM memory. This enables this solution to work as the structure independent on the PC computer. The use of the processor gives the possibility of developing a system with advanced communication interface eg. Ethernet or data transmission interface using GSM network. REFERENCES [1] Web site [2] Web site [3] Web site [4] Chao Lu, Zhaoqian Chen, LingliWang, Xiaofang Zhou, An Innovative Embedded Logic Analyzer Based SoC Verification Platform, Proc. on ICSICT '06, Konferencja IEEE, str , 2006 [5] G. Knittel, S. Mayer, C. Rothlaender, Integrating Logic Analyzer Functionality into VHDL Designs, Proc. on ReConFig '08, Konferencja IEEE, str , 2008 [6] Lauri Ehrenpreis, Peeter Ellervee, Kalle Tammemae, Open Source On-Chip Logic Analyzer for FPGA's, Baltic Electronics IEEE Conference, str , 2006 [7] Web site [8] Web site [9] Web site [10] 80C51 Besed 8-Bit Microcontrollers DATA HANDBOOK IC20, Philips Semiconductors, March 1995 [11] TSK51xMCU Core Reference v.2.0, CR0115, Altium Limited, March 13,2008 [12] FPGA Processors Resource Usage v.1.11, CR0140, Altium Limited, July 17,2008 [13] AT91 ARM Thumb-based Microcontrollers, 6175I ATARM 24-Dec-08, Atmel Corporation [14] Virtex-5 Libraries Guide for HDL Designs ISE 10.1, Xilinx Inc [15] W.Ackerman, et al., Operation of a free electron laser from the extreme UV to the water window, Nature Photonics, 1 (6), 2007, pp [16] A.Burd, at al., Pi of the sky, all-sky, real-time search for fast optical transients, New Astronomy 10 (5), 2005, pp [17] S.Chatrchyan, et al., The CMS experiment at the CERN LHC, Journ. Instrumentation 3 (8), 2008, art no S08004 [18] W.Giergusiewicz et al., Low latency control board for LLRF system Simcon 3.1, Proc. SPIE 5948, 2005, art no 59482C, pp.1-6 [19] T.Czarski et al., Tesla cavity modeling and digital implementation in FPGA technology for control system development, Nucl. Instrum and Meth. In Physics, A: 556 (2), 2006, pp [20] K.Pozniak et al., FPFA and optical network based LLRF distributed control system for TESLA-XFEL linear accelerator, Proc. SPIE 5775, 2005, art no08, pp [21] T.Czarski et al., Cavity parameters identification for TESLA control system development, Nucl. Instrum and Meth, in Physics A: 548 (3), 2006, pp [22] K.Pozniak, et al., FPGA based cavity simulator and controller for TESLA Test Facility, Proc.SPIE 5775, 2005, art no.02, pp.9-21 [23] K.Pozniak, et al., Functional analysis of DSP blocks in FPGA chips for application in TESLA LLRF system, Proc.SPIE 5484, 2004, pp [24] W.Zabolotny et al., Distributed embedded PC based control and data acquisition system for TESLA cavity contyroller and simulator, Proc.SPIE 5484, 2004, pp [25] T.Czarski et al., Superconducting cavity driving with FPGA controller, Nucl.Instrum. and Meth. In Physics Res. A: 568 (2), 2006, pp [26] P.Pucyk, et al., DOOCS server and client application for FPGA based TESLA cavity controller and simulator, Proc.SPIE 5775, 2005, art bo. 06, pp [27] T.Czarski et al., Cavity control system advanced modeling and simulations for TESLA linear accelerator and free electron laser, Proc.SPIE 5484, 2004, pp [28] T.Filipek, et al., Fast synchronous distributed network of data streams for RPC muon Trigger in C<S experiment, Proc.SPIE 5775, 2005, art no 15, pp [29] T.Czarski et al., TESLA cavity modeling and digital implementation with FPGA technology solution for control system development, Proc.SPIE 5484, 2004, pp [30] K.Perkuszewski, et al., FPGA based multichannel optical concentrator Simcon 4.0 for TESLA cavities LLRF control system,

10 Proc.SPIE 6347, 2006, art no [31] A.Burd et al., Pi of the sky robotic search for cosmic flashes, Proc.SPIE 6159, 2006, art. No H [32] W.Giergusiewicz, et al., Modular version of SIMCON, FPGA based, DSP integrated, LLRF control system for TESLA FEL, part II: Measurements of Simcon 3.0 DSP daughterboard, Proc. SPIE 6159, 2006, art no [33] D.Rybka et al., Investigation of irradiation effects on electronic components to be used in VUV-FEL and X-FEL facilities at DESY, Proc.SPIE 5948, 2005, art no.59480j, pp.1-12 [34] W.Giergusiewicz, et al., FPGA based LLRF control module for X-ray Free Electron Laser and TESLA feedback system, Proc.SPIE 5775, 2005, art no 07, pp [35] P.Rutkowski et al., FPGA based TESLA cavity SIMCON DOOCS server design, implementation and application, Proc.SPIE 5484, 2004, pp [36] T.Czarski, et al., Cavity control system optimization methods for single cavity driving and envelope detection, Proc.SPIE 5484, 2004, pp [37] T.Czarski et al., Cavity digital control testing system by Simulink step operation method for TESLA linear accelerator and free electron laser, Proc.SPIE 5484, 2004, pp [38] M.Kwiatkowski et al., Advanced camera image data acquisition system for Pi of the sky, Proc.SPIE 7124, 2008, art no.7124of [39] L.Dymanowski, et al., Data acquisition module implemented on PCI Mezzanine card, Proc.SPIE 6937, 2008, art no. 6937oK [40] P.Strzałkowski, et al, Versatile LLRF platform for FLASH Laser, Proc.SPIE 6937, 2008, art no 69370I [41] A.Brandt, et al. Measurement and control of field in RF Gun at FLASH, Proc.SPIE6937, 2008, art no F [42] P.Fafara et al., FPGA-based implementation of a cavity field controller for FLASH and X-FEL, Measurement Science and Technology 18 (8), 2007, art no.010, pp [43] R.S.Romaniuk, K.T.Pozniak, Metrological aspects of accelerator technology and high energy physics experiments, Measurement Science and Technology, 18 (8), 2007, art no E01 [44] R.Pietrasik, et al., Measurement of Simcon 3.1. LLRF cvontrol signal processing quality for VUV Free Electron Laser FLASH, Proc.SPIE 6347, 2006, art no [45] R.Graczyk et al., FPFA based, modular, configurable controller with fast synchronous optical network, Proc.SPIE 6347, 2006, art no [46] K.T.Pozniak, et al., Data transmission optical link for LLRF TESLA project, Part II : Application for BER measurement, Proc.SPIE 6159, 2006, art no [47] K.Lewandowski et al., FPGA based PCI mezzanine card with digital interfaces, Proc.SPIE 6937, 2008, art no J [48] T.Czardki et al., Multi-cavity complex controller with vector simulator for TESLA technology linear accelerator, Proc.SPIE 6937, 2008, art no H [49] R.Graczyk et al., FPGA systems development based on universal controller module, Proc.SPIE 6937, 2008, art no.69370m [50] J.Szewiński et al., Implementation of adaptive feed forward algorithm on embedded Power PC405 processor for FLASH accelerator, IEEE Conference Press, EUROCON 2007 The International Conference on Computer as a Tool, 2007, IEEE explore, art no , pp