Automatic resource identification for FPGA-based ...

Please verify that (1) all pages are present, (2) all figures are correct, (3) all fonts and special characters are correct, and (4) all text and figures fit within the red margin lines shown on this review document. Complete formatting information is available at http://SPIE.org/manuscripts Return to the Manage Active Submissions page at http://spie.org/app/submissions/tasks.aspx and approve or disapprove this submission. Your manuscript will not be published without this approval. Please contact [email protected] with any questions or concerns.

Automatic resource identification for FPGA-based reconfigurable measurement and control systems with mezzanines in FMC standard Andrzej Wojenski, Grzegorz Kasprowicz, Krzysztof T. Pozniak, Ryszard Romaniuk Institute of Electronics Systems, ul. Nowowiejska 15/19, 00-665 Warsaw, Poland ABSTRACT The paper describes a concept of automatic resources identification algorithm used in reconfigurable measurement systems. In the paper is also presented a concept of algorithm for automatic generation of HDL codes (firmware) and management of reconfigurable measurement systems. Following sections are described in details: definition of measurement system, FMC installation, automatic FPGA startup configuration, automatic FMC detection and automatic card identification. Reconfigurable measurement systems are using FPGA devices and measurement cards in FMC standard. This work is a part of a wider project for automatic firmware generation and management of reconfigurable systems. Keywords: FPGA, FMC, firmware, measurement system, automatic reconfiguration, automation

1. INTRODUCTION Dynamic evolution of technology requires more precise and faster measurement methods, which process large amounts of data. FPGA devices are widely used in metrology since they offer several capabilities : •

In system, field programmability

•

Ability to implement many advanced communication interfaces

•

Integrated universal and programmable logic, memory and DSP blocks

•

Many independent input/ output lines

•

Can process serial and parallel data in real time

•

Several tens of Gb/s data stream per one lane

•

Determinism in data processing and communication

In case of FPGA devices, modification of communication interface requires only exchange of firmware ( IP blocks [1]), without need of any hardware modifications (like routing new lines on PCB etc.). As mentioned before, FPGAs have many universal I/O ports. Those ports can be connected to standardized sockets, with no need of permanent implementation of communication interfaces. Whole firmware can be dynamically adapted to inserted measurement cards [2]. VITA57 FPGA Mezzanine Card (FMC) standard was developed to provide dedicated connectivity between FPGA on main board and exchangeable digital or analogue I/O, communication or measurement cards. FMC specification standardizes [3][4]: • • • • •

Signal lines electrical standard (LVCMOS or LVDS) Connector type (Low Pin Count or High Pin Count) High speed data links (up to 10Gb/s) Pin assignment in FMC socket Mechanical properties of cards and connectors (single and double module dimensions)

8903 - 13 V. 14 (p.1 of 10) / Color: No / Format: A4 / Date: 7/26/2013 8:33:57 AM SPIE USE: ____ DB Check, ____ Prod Check, Notes:


Functionality of FMC cards is not defined by any standard. Today the most popular are [5]: • • • • •

ADC and DAC converters (i.e. 4DSP FMC176 [6], 4DSP FMC230 [7]) High speed serial links (i.e. Faster Technology FM-S14 [8]) Network interfaces (i.e. Nutaq 2x10GE SPF+ [9]) Digital receivers and transceivers of RF (i.e. Nutaq Radio420X [10]) DSP cards [19]

The cards listed above require carrier platform with high performance for data processing. In this case, performance FPGA devices should be mounted on carrier board working with FMC modules.

high

FMC interface specification describes power supply, geographic address lines , reference clocks and fast gigabit links. Each of FMC cards must have mounted EEPROM chip for identification purposes [2]. FMC standard offers up to 160 universal signal lines for user implementation. Signal lines can work in differential or single-ended mode. Development of measurement systems using FMC standard allows building very flexible measurement platforms, because there is no defined protocol between FMC and FPGA[16]. In such systems problem occurs in term of efficient management of mezzanine cards. Each change of mezzanine card in a FMC socket comes with the need of firmware modification in the FPGA. In case of replacement of 4 FMC cards, developer of the system needs to update up to 640 communication ports in FPGA. In addition, update of IP cores with different communication interfaces is often needed. Each system reconfiguration means additional work for a system developer. In many advanced mezzanines specific data must be send to specific card (with unique serial number). It can be needed for example for ADC offset, gain and link delay calibration[17]. In such case developer needs to provide different HDL or firmware versions, based on installed mezzanine cards, with functionality to identify specific cards in system and send required data to specified components. Currently, on market there are no fully automated tools for building HDL-based firmware and management of FPGA based measurement and control systems. There are only few intermediate solutions, like CompactRIO platform [11], and software applications: Hdlmake [12] and Wishbone Slave Generator [13]. None of them allow automatic firmware generation and management of FPGA - FMC systems. Facing those needs, Authors described a concept of automatic resource identification in reconfigurable measurement and control systems. There is also introduced a conceptual scheme, which leads to automatic firmware generation and management of reconfigurable measurement systems based on FPGA devices and mezzanine cards in FMC standard.

2. MODEL OF RECONFIGURABLE MEASUREMENT AND CONTROL SYSTEM On figure 1 is shown conception of main board for four FMC cards, developed by Authors. All FMC slots are connected to FPGA. There are also provided clock signals from “Clock signals distribution” block. FPGA is equipped with two interfaces : • •

INT – communication interface with PC (for example RS-232, USB, PCI-E, Ethernet) JTAG – communication interface for uploading configuration to FPGA device

There are also dedicated ports which provide connection to other FMC carriers (WBLink blocks). Multiple FMC Carriers can be sequentially connected (figure 3). WBLink block can be implemented using standard I/O lines, specialized serial gigabit interfaces or other devices (like PCI Express [18]), which allows data transfer compatible with Wishbone standard [14]. FMC carrier has also power supply section for FPGA and FMC cards.



Figure 1 Construction of FMC carrier (FMC main board with FPGA device)

Figure 2 shows construction of measurement card in FMC standard. The I2C interface for communication with on-board EEPROM chip is also connected to the FMC socket . PRSNT_M2C_L signal informs the system that the card is present in the FMC slot. There are also connected communication lines from on-board integrated circuits. Optionally, on FMC card can also be mounted FPGA, which communicates with system through Wishbone interface.

Figure 2 General construction of FMC measurement card

Measurement & control systems, built up on introduced solution, can be described as system containing n FMC carriers with mounted k FMC slots on each carrier(k ≤ 4 because of FPGA limitation). Figure 3 shows construction of general measurement system. In case when n > 1, Authors assume that the FMC carriers are connected through WBLink blocks. Based on general FMC-based measurement and control system architecture, proposed is methodology to automatically build complete and integrated firmware, HDL and software with minimal user intervention.

Figure 3 General architecture of measurement system, based on presented assumptions



3. METHODOLOGY OF AUTOMATIC HDL FIRMWARE GENERATION FOR RECONFIGURABLE MEASUREMENT SYSTEMS Authors distinguishes following work phases of application which generates firmware and manages reconfigurable measurement and control systems : • • • • • • • • • •

Definition of measurement system architecture Installation of FMC (by user) and system power-up Startup firmware upload to FPGA device (optionally) Searching for available FMCs Identification of FMCs Automatic generation of FPGA firmware HDL files (outside of measurement system) FPGA configuration upload to all devices in the system through the JTAG interface Automatic generation of software drivers Configuration of FMCs registers Launch of the user applications (optionally)

Figure 4 presents the methodology realized by application for firmware generation and management of measurement and control systems. In next chapters all the phases are precisely described. Because automatic firmware generation and automatic system management is complex topic, in following paper Authors describes the stages leading to automatic resource identification . Those stages are base for the methodology of automatic firmware generation and management of reconfigurable measurement and control systems.

Figure 4 Methodology for automatic HDL firmware generation and management of reconfigurable measurement systems



3.1. Definition of measurement system construction In order to automatically generate HDL firmware for the FPGA devices (mounted on FMC carriers), the information need to be provided about architecture of the system. Application need to know how many FMC carriers are available in the system, and how many FMC slots contains each carriers. Provided information describe which specific FPGA lines are connected to which FMC connector pins. To have coherent structure, value pairs (FPGA pin = FMC pin) are defined. FMC lines naming is the same as in FMC specification [3] [4]. Those information are included in the mapping file. Geographical address of each of the FMC slots is needed in order to determine addresses of EEPROM memory chips and other ICs available on the FMC cards. Listing 1 shows model of mapping file implementation. CARRIER = 1 FMC_SLOT = 1 GA0 = 0 GA1 = 1 FMC_LINE = LA02_P FPGA_LINE = AA01 FMC_LINE = LA02_N FPGA_LINE = AB04 FMC_SLOT = 2 GA0 = 1 GA1 = 0 FMC_LINE = LA02_P FPGA_LINE = BB01 FMC_LINE = LA02_N FPGA_LINE = CC05 Listing 1 Mapping file of FMC carrier

Additionally in the mapping file information about FPGA lines is included , which are for: • •

Implementation of WBLink (Wishbone Link) blocks (with proper IP core which need to be implemented) Handling clock and reset signal (with proper IP core which need to be implemented)

For the FMC carrier, which is the master carrier , in mapping file special information is included about IP core which converts INT interface to Wishbone . The master carrier can be pointed i.e. by installation of specific FMC card or dedicated interface. 3.2 Installation of the FMC cards and powering-up the system On this stage user installs in the FMC slots (on FMC carriers) FMC boards (in any order) and then powers-up the system. 3.3 Startup firmware upload to FPGA device (optional) After turning the system on it may occur that FPGA is needed to be configured with the startup firmware in order to do basic system identification (like communication with EEPROM chips). For example, due to specific hardware construction of the FMC carrier, signals like PRSNT_M2C_L or I2C interface are not be available directly for control application and those signals are connected to the FPGA device. In such situation, the control application uploads startup firmware (for specific FMC carrier) to the FPGA device, which implements I2C interface and PRSNT_M2C_L signals handling. Signals are available through the INT interface (like USB or RS232). This stage of algorithm extends flexibility of application, because it takes into account different hardware architectures of the FMC carriers and ways of communicating with the system.



3.4 Identification of available FMC mezzanines Next step for the application is to check in which slots are installed FMC cards. Software reads state of PRSNT_M2C_L signal, for each of the FMC slots (figure 2) in order to detect presence of the mezzanine. When application detects available FMC card, it reads the contents of its EEPROM memory through the I2C interface. In the EEPROM memory the information is written , which identifies the FMC card. If the data read is incorrect, system considers such card as unavailable. 3.5 Identification of the FMCs After reading the EEPROM content, application checks for availability of hardware drivers. Hardware drivers term is used to specify set of files, which describe the FMC construction and communication interfaces supported by the card. If no hardware drivers were detected, that card will not be processed by the application. Authors had assigned set of the most important data fields, which describe uniquely the FMC cards: • • •

FMC name – the application searches for the hardware driver with same name as provided in this field Card serial number – unique in the whole system (globally). Using this information, the application can identify the location of certain FMC cards . It is also important for the systems, which have many FMC cards of same type installed. Additional information – shown as text, for example this field can be used as brief description of the mezzanine

After verification of the cards installed in the system, the application displays report with listed available FMCs and corresponding hardware drivers. The EEPROM memory is filled with XML data[15] which is easy to interpret. The user or developer can add additional information, and there is no need for special processing of the.. Also, there is no need of the EEPROM memory organization definition. The pointer to the beginning of XML file is sufficient. The memory file can be edited in every common text editor and its validation can be done in a web browser. Listing 2 shows an example file in the XML standard, which describes the card compatible with the guidelines introduced.

sn="card1"

Listing 2 Example XML file uploaded to EEPROM memory

Available fields in XML are shown in table 1. Attribute name name version

Example value FmcAdc100M8b16cha v1.9.0

id

fmcadc100m8b16cha_v1_9_0

sn description

12345 FMC ADC 16 channels, 8 bits, 100MSPS, onboard FPGA

Description Name of the FMC card Card version (for example PCB version) Card ID, upon this filed application searches for hardware driver for FMC card Serial number of a card Short functionality description

Table 1 Available Fields in XML file uploaded to EEPROM memory



The application searches for the hardware driver based on the id field of XML file (read from the EEPROM memory) for each FMC. The figure 5 shows identification method of the hardware drivers.

Figure 5 Method for discovering of the hardware drivers for certain FMC.

Hardware driver is an IP block, which communicates with the application through Wishbone interface. Main task of the hardware driver is implementation of IPs block communication interfaces. In order to have high flexibility among different projects, there was developed special database for the communication interfaces (like SPI, I2C, LVDS), which is shown in figure 5. The hardware drivers point to the communication interfaces database, defining which interfaces are used by specific FMC. By this, different cards can use the same IP cores for their communication interfaces. The hardware drivers must be provided with the information about the FMC connections, on which the communication interfaces are implemented and their voltage standard. The information about timing constraints of the interface lines may be included in the driver file. Two cases can be distinguished: • •

Transmit clock signal – the developer must provide signal frequency and duty cycle Transmit data signal – the developer must provide the setup and hold time of the data, name of the clock signal and port direction (input or output)

In the case the FMC has integrated circuits, with which application can communicate directly through the I2C interface, the information about the circuit addressing needs to be provided. The addresses may vary depending on the FMC position (geographic address). Each hardware driver consist of two sets of files: 1. 2.

Files with the HLD code containing the IP blocks with implemented communication interfaces and additional functionality, like conversion of the differential signals to single-ended. File that defines the communication interfaces used on the FMC, with signals assignments to the FMC socket (information file). Signal names are the same as in the FMC standard specification. In this file voltage standards and timing constraints for used lines can also be added

Complete hardware driver structure is shown in figure 6. Thanks to the solution described above, the hardware drivers can work on different platforms. Also already written interface drivers can be easily used in other drivers of the FMCs. Hardware driver of the card can be developed in short time by combining different communication interfaces. The driver file must also include the information about the



position of the interface lines in the FMC connector. Such architecture of the hardware driver allows quick and convenient implementation on the FPGA devices.

Figure 6 Complete hardware driver of FMC measurement card

The FMC signals are mapped to the FPGA pins through the mapping file of the FMC carrier. The mapping file is specific to the FMC carrier board used in certain system. Figure 7 shows the signals assignments from the FMC connector to the FPGA device.

Figure 7 Method of signals assignment from the FMC connector to the FPGA, based on example shown in figure 5

After completion of the identification stage, the system has complete information about available mezzanine cards, and their communication interfaces. This information will be used in further HDL firmware generation for all the FPGA devices. Figure 8 shows map of the system, created as a result of application presented in this section. All the hardware drivers are connected to shared Wishbone bus. All implemented interfaces are managed by the master Wishbone controller.



Figure 8 Map of the system after card identification

4. SUMMARY The paper presents method for automatic management of reconfigurable measurement and control systems based on the FMC standard. There are also described steps that allow automatic identification of the resources used by the reconfigurable systems. Authors described in details effective way of FMC cards identification . The paper also describes interpretation of data contained by FMCs, in order to prepare the resources for further automatic generation of the HDL codes and management of the system. After completion of the steps described, the user obtains information on: • • •

List of installed FMC boards in the system List of used hardware drivers for FMCs with their communication interfaces The precise system map, with information about position of each FMC card in the whole system

Based on acquired information, the HDL codes for the FPGA devices can be automatically generated. Software stores all the necessary data about the hardware drivers of each cards and used communication interfaces. It makes possible to exchange the data with other FMCs. The system can be automatically configured by additional software, based on received information about system architecture.



REFERENCES [1] Hajduk, Z., [Wprowadzenie do języka Verilog], Wydawnictwo BTC, Legionowo, 2009 [2] Seelam, R., "I/O Design Flexibility with the FPGA Mezzanine Card (FMC)", Xilinx White Paper WP315, 2009 [3] VMEbus International Trade Association (VITA), http://www.vita.com/fmc.html [4] ANSI/VITA, "ANSI/VITA 57.1 FPGA Mezzanine Card (FMC) Standard" [5] ANSI/VITA, "FMC Products", VITA, http://www.vita.com/home/MarketingAlliances/fmc/fmc_supplier_matrix.pdf [6] 4DSP FMC176, http://www.4dsp.com/FMC176.php [7] 4DSP FMC230, http://www.4dsp.com/FMC230.php [8] Faster Technology FM-S14, http://www.fastertechnology.com/products/fmc/fm-s14.html [9] Nutaq 2x10GE SPF+, http://nutaq.com/en/products/view/+nutaq-210ge-sfp [10] Nutaq Radio420X, http://nutaq.com/en/products/view/+nutaq-radio420x [11] National Instruments CompactRIO, http://sine.ni.com/np/app/main/p/ap/global/lang/pl/pg/1/sn/n24:cRIO/fmid/102/ [12] HDLmake application website, http://www.ohwr.org/projects/hdl-make [13] Wbgen2 (Wishbone Slave Generator) application website, http://www.ohwr.org/projects/wishbone-gen [14] OpenCores Organization, “Wishbone B4, Wishbone System-on-chip (SoC) Interconnection Architecture for Portable IP Cores”, 2010, OpenCores Organization, http://opencores.org/opencores,wishbone [15] XML standard, http://www.w3.org/XML/ [16] Kasprowicz, G. H., Czarski, T., Chernyshova M. and others, “Fast ADC Based Multichannel Acquisition System for the GEM Detector”, Proc. SPIE 8454, Photonics Applications in Astronomy, Communications, Industry, and HighEnergy Physics Experiments 2012 / Romaniuk Ryszard (red.), 2012, SPIE, 84540M-1-84540M-8, DOI:10.1117/12.2000211 [17] Kasprowicz, G. H., Czarski T., Chernyshova M. and others, “Fast ADC Based Multichannel Acquisition System for the GEM Detector”, Proc. SPIE 8454, Photonics Applications in Astronomy, Communications, Industry, and High-Energy Physics Experiments 2012 / Romaniuk Ryszard (red.), 2012, SPIE, 84540M-1-84540M-8, DOI:10.1117/12.2000211 [18] Byszuk, A., Kołodziejski, J., Kasprowicz, G. H. and others, “Implementation of PCI Express bus communication for FPGA-based data acquisition system”, Proc. SPIE 8454, Photonics Applications in Astronomy, Communications, Industry, and High-Energy Physics Experiments 2012 / Romaniuk Ryszard (red.), 2012, SPIE, 84540N-1-84540N-6, DOI:10.1117/12.2000232 [19] Janicki, T., Poźniak, K., Romaniuk, R., “Integration of multi-interface conversion channel using FPGA for Modular Photonic Network”, Photonics Applications in Astronomy, Communications, Industry, and High-Energy Physics Experiments 2010 / Romaniuk Ryszard, Kulpa Krzysztof (red.), vol. 7745, 2010, ISBN 9780819472358, 7745-1H-1-7745-1H-9, DOI:10.1117/12.873314


Automatic resource identification for FPGA-based ...

Automatic resource identification for FPGA-based ...

Suggest Documents

FPGAbased educational platform for realtime image processing ...

An FPGAbased integrated environment for computer architecture

Automatic Resource and Service Management for ... - CiteSeerX

Automatic Web Resource Discovery for Subject Gateways

Automatic Diacritic Restoration for Resource ... - Semantic Scholar

Automatic Resource and Service Management for ... - CiteSeerX

Exploiting Social Annotation for Automatic Resource Discovery

AUTOMATIC LANGUAGE IDENTIFICATION - Technomathematics ...

Automatic Identification System - maritech.com.vn

Automatic Identification System

Automatic Car Identification System

Automatic Native Language Identification

Credential Management for Automatic Identification ... - TU Ilmenau

Using Encyclopedic Knowledge for Automatic Topic Identification

A Framework for the Automatic Identification and

Multiobjective Model for Locating Automatic Vehicle Identification ...

Automatic Identification of Quasi-Experimental Designs for ...

a numerical study for automatic battery identification

Automatic Writer Identification Framework for Online Handwritten ...

a manual for system identification - Automatic Control

An Adaptive Questionnaire for Automatic Identification

Statistical Analysis for Automatic Identification of

Automatic Topics Identification For Reviewer ... - Semantic Scholar

Automatic Rhythm Modeling for Language Identification - International ...