Generic Sensor Interface for On-Board Satellite Applications

Generic Sensor Interface for On-Board Satellite Applications L. Fanucci*, A. Renieri, C. Rosadini, C. Sicilia, D. Sicilia *

IEIIT, National Research Council, Pisa, Italy Dept. of Information Engineering, University of Pisa, Pisa, Italy

Abstract Satellite demands in terms of computational power, dimensions, mass, reliability and power consumption related to the electronic circuitry for on-board-processing (both payload and house keeping operations) are nowadays almost covered with integrated solutions: System-on-Chip (SoC) has become a familiar term which identifies a complex heterogeneous system composed by one or more processing units, an application specific block-set and a variable number of general purpose [programmable] peripherals (communication, networking, memories). New design methodologies are required for the design and verification of such a complex SoC in a reasonable time. In this paper we applied the so called platform based approach for the development of a generic digital sensor interface: the interface gathers the data coming from a space qualified sensor and after a proper signal conditioning (offset calibration, linearization, thermal compensation) provides the processed information through a SpaceWire link.

I. INTRODUCTION Satellite earth observation missions call for high data-rate on-board data-handling systems to interface and connect sensors, processing elements, mass-memory units and downlink telemetry sub-systems, etc. In this application field embedded solutions and efficient communication protocols are contributing to implement reliable systems for the given cost, power consumption and development time constraints. From the chip manufacturer side, nowadays technology allows the fabrication of SoC composed by hundred millions of transistors In the space field, where mass and power consumption are key issues, the solution offered by SoC allows useful mass and power reduction, while the computational speed even grows with respect to existing onboard computing; new concepts, such as femptosat [1] (also referred as satellite-on-chip, whose weight ranges from 1 tenth of kg to 1 kg), represent the evolution of satellite size mainly due to the technology scaling. As drawback, the more complex the system, the greater the effort required for the design, the verification and the validation; all these concerns strongly influence a space mission in terms of time, costs and reliability. From the SoC designer side, different techniques, such as the one known as platform-based design [2], have been implemented which, integrated with Electronic Design Automation (EDA) tools, help toward the exploration of the complex SoC design space. From the communication point of view, the European Space Agency recently proposed a new serial data link

standard, named SpaceWire [3], based on two existing commercial standards, IEEE-1355 [4] and LVDS [5] which has been combined and adapted for use on-board to the spacecraft. Serial links are very attractive with respect to bus solutions because they require a reduced number of pins and wires while still providing a high data transfer throughput. These two aspects are integrated together and resumed in this paper, which focuses on the development of a FPGAbased prototyping environment, featuring the platform approach, suited to help the designer in the identification, trimming and verification of a SoC architecture for space applications. Particularly the interest is towards telemetry and attitude control (for navigation and landing), where the realtime processing of the information about alignment, position, speed and inertial acceleration represents a big concern. The concept behind the considered work is to perform all sensor signal conditioning and elaboration in the digital domain and to leave to the analog domain just the basic operations (such as amplification, current/voltage driving); this method results in the following benefits. The first one is cost-reduction since digital circuitry has a production cost lower than the analog one, especially whenever expensive techniques has to be adopted in order to protect the full custom circuitry from radiations. Then more flexibility for different kind of sensors is achieved by integrating in the SoC a set of programmable function-generator blocks whose operating modes and configurations can be easily set via software. Moreover the inclusion in the system of a SpaceWire router switch and peripherals enhances the versatility of the system itself (it can be used as a stand-alone or integrated in a more complex control system, also receiving data from other sensors via SpaceWire link), while reducing the connectivity issues with different electronic equipment provided by third parties. Moreover, since an ASIC chip for space applications has a high unit cost because of the low yield volume, whenever power constraints and signal processing performance demands are not much prominent (as in the case of the mentioned class of sensors) an FPGA qualified for the space environment is preferable with respect to the ASIC solution, even if the risk assessment in still under examination [6]; in this sense the proposed FPGA-based platform is close to the final product and could represent a fast way to evaluate the effective system performance in terms of noise, speed and power consumption. The paper is structured as follows: after this Introduction, Section 2 gives a description of the hardware side of the platform and of the available software tools useful for the hardware configuration and trimming (once the design has been mapped into the FPGA). Section 3 describes the verification methodology adopted to guarantee the correct system behavior, while conclusions are drawn in Section 4.

II. PLATFORM DESCRIPTION The platform is based on a hardware section, a software block-set and a verification methodology. Particularly the hardware side is composed by an analog front-end module (for sensor signal acquisition) and by an FPGA device, where a 32-bit RISC processor plugged in an AMBA-based system and a configurable digital signal processing chain perform all operations required by the desired application (such as filtering, functions generation, signal mixing and then communications, memory transfers, networking). The AMBA bus accomplishes at the same time the need of highperformance and high-clock-frequency (AHB-bus) as well as low-power and reduced-interface peripherals (APB-bus). The software block-set includes a hardware configuration tool and a graphical user interface (GUI), suited to trim the system in the real environment once it is interfaced to the desired sensor. Finally a suited verification methodology is applied to the SoC architecture after the design phase in order to guarantee the overall system behavior before final implementation in the target space qualified technology.

easier the system level validation, increasing the independence from the digital architecture and giving transparency to the software designers. At the time being, the analog module provided with the board is seen by the digital system as an APB peripheral, with own control (for reference and sample-rate settings), status and data registers. 2) The LEON sub-system The sub-system AMBA core processor and peripherals are represented by the LEON distribution [7], developed by the European Space Agency and freely distributed under LGPL license. The processor is based on a 32-bit RISC SPARC-V8 compliant architecture and acts directly on the AMBA AHB bus. Additional AMBA APB peripherals such as UARTs, Timers/Watchdog, parallel I/O port and Interrupt Controller are provided.

A. Hardware overview The hardware side of the platform, whose conceptual scheme is depicted in Fig. 1, is based on an Insight MicroBlaze™ fast prototyping board and is composed by an analog section (holding the basic sensor interface circuitry) and by a Virtex-II FPGA device, where a configurable digital module performs the most of signal processing operations required by a certain sensor. ANALOG MODULE

OSC

VREF D/A BRIDGE

DAC ADC

A/D BRIDGE

DAC - ADC

S

DIGITAL MODULE

EMBEDDED CORE

DSP

SW LINK

Figure 2: Digital section block diagram.

3) The configurable DSP chain Figure 1: Platform block diagram.

1) Analog section and related digital interface At present the considered analog circuitry is represented by an analog expansion module provided with the fast prototyping board and constituted by two 165 Msps digital-toanalog and two 53 Msps analog-to-digital converters (DAC and ADC), both with a resolution of 12 bits. External clock and voltage references can be used. This module is useful to interface the chosen sensor, given that the sensor signal range does not exceed the converter dynamics; in that case, discrete components such as instrument amplifiers and current/voltage drivers has to be considered. The next platform generation will be composed by a unique analog chip, holding DACs, ADCs, digitally controlled amplifiers and current/voltage drivers; the chip will also include an analog-to-digital bridge in order to connect the chip itself to the digital section by minimizing the number of external connections. This solution will allow the analog section to be seen as a digital black box, thus making

The configurable DSP chain is a set of connected blocks designed to receive, elaborate and condition the sensor information provided by the analog section via the bridge. The configurability is achieved by means of a parametric VHDL source code and a suitable software tool (which will be described in the next section): each block can be separately instantiated in the design or discarded if not necessary; in this case a direct connection between blocks or an open line takes its place. The same block is not inferred also if the same functionality can be carried out by the processor by means of a software routine. In this case interrupt requests are used to control the data flow. This configurability allows several architectures to be implemented and this intents to address most of sensors required by space applications. Each node connecting two contiguous blocks is accessible by the processor via dedicated register; this allows the node to be used as a watchpoint or as a source (destination) register in

case the following (previous) adjacent block is implemented via software. Each multiplier tap can be configured in order to receive the coefficient either from a register or from a digital PLL (the latter allowing modulation/demodulation operations). When configured to receive data from the register, the processor can set a constant value in order to implement an amplifier/attenuator function; otherwise the processor can store into the register itself the instant value of whatever waveform slope (produced by software algorithms) thus acting as a function generator. In PLL configuration, the PLL can be locked to one channel and it allows either closed-loop or single-loop configuration of the whole chain. IIR as well as FIR filters can be implemented in the filtering block, with selectable functionality (high and low pass) and order. 4) SpaceWire link The SpaceWire [3] routing switch (Fig. 3) acts as an APB peripheral from the LEON side and as a normal routing switch from the rest of the surrounding external circuitry; it is composed by a switching matrix, which contains the routing tables and the arbitration logic, connected to the external world via SpaceWire interfaces. The routing switch is controlled by the LEON processor: the configuration commands can be originated either by an external configuration unit or by the LEON itself. In the former case the packets are sent to the address 0x0 of the routing switch, as specified by the standard, and read by LEON which performs the requested operations.

port, to route the packet to, by checking the destination address. If the requested output port is free then the whole packet is immediately routed to that port. The port is considered busy until the last character of the packet has passed through the switch; if the requested output port is busy then the input halts the incoming packet until the output port becomes free. This is achieved by the input port ceasing to send flow control tokens to the source node. SpaceWire packets are composed of characters: a character is a group of 10 bits for data characters or 4 bits for control characters. A packet comprises a destination address, a cargo and an end of packet marker (see Fig. 4). The destination address consists in a list of zero or more destination identifiers each of them composed of one data character. The cargo comprises one or more data characters that have to be transferred from the source to the destination. The end of packet marker is a control character indicating the end of packet and that the next received data character will be a destination identifier.

Fig. 4. SpaceWire packet

The SpaceWire routing switch implements the following packet-addressing schemes: - Hardware addressing The destination address is specified as a sequence of router output port numbers used to drive the packet across the network. At each routing switch a destination identifier (port identifier) is stripped off so that the following routing device takes the routing decision upon the second destination identifier. - Logical addressing (interval labeling) Each destination has a unique logical address and each routing switch needs a routing table binding each logical address with a physical port.

Fig. 3. SpaceWire routing switch

The LEON Processor can also send data via the SpaceWire Interfaces by means of properly formed packets to the I/O port of the APB/Switch Bridge, which act as a SpaceWire interface from the point of view of the switching matrix. Each interface has a set of flags to allow the router control unit to program and to check the status of each interface. Two key features of the router are the ability to send the status of each interface on the SpaceWire network whenever a status flag changes and the packet distribution as specified in the SpaceWire standard. The SpaceWire routing switch is based on wormhole routing [8,9]. In wormhole routing each packet contains a header holding the address of the destination node. As soon as a packet header is received, the switch determines the output

- Regional logical addressing This scheme is based on logical addressing in conjunction with header deletion. Header deletion is a simple technique allowing packet transfer across an arbitrary sized network. The first data character (destination identifier) of a packet is used to determine the router output port. It is then deleted so that the next destination identifier (now the first destination identifier) is used for subsequent routing. - Group adaptive routing This is a means of routing packets to a requested destination over different paths through a network. Two or more output ports can be grouped together so that, if a link is busy or unavailable due to hardware failure a packet is sent through the next available link in that group.

B. Software support. 1) Hardware configuration tool. The hardware configuration tool represents the mean to

define a platform instance for the digital section, allowing the customization of a specific LEON implementation and of desired DSP chain architecture. Particularly it is based on a graphical software tool already available for the LEON distribution and customarily modified in order to include the configurable DSP chain along the design flow (as shown in Fig. 5).

defines a communication protocol which regulates the information flow between the target prototyping board and host PC.

III. VERIFICATION METHODOLOGY. Once the architecture has been identified, a suitable verification approach [10] allows for fast debugging and gives the platform additional quality degree. This phase is done by inspections (by means of self-checking VHDL simulations) of all hierarchy levels of the platform, by starting with the lowest one (single IP) and terminating with the highest one (system); the latter requires a behavioral model to be developed for the analog section (sensor included). Particularly the verification process is composed by four steps in ascending hierarchy order: block-level, bus-level, system-level simulations and hardware emulation.

block-level TEST #n IP#1

DUT

Figure 5: Hardware configuration tool snapshot. IP#2

As far as the DSP chain is concerned, the possible configuration has been examined in the previous section; however it has to be noted that whenever a hardware block is replaced by a software routine, it’s a designer’s task to define the handler responsible of the routine execution, in order to guarantee the correct data flow through the DSP chain. 2) Graphical User Interface. After the desired architecture suitable to interface the given sensor has been identified, verified and mapped onto the prototyping board, is usually necessary to tune a posteriori several parameters such as path gains, filter coefficients and so in order to correctly elaborate and condition the signal coming from the sensor. Moreover it could be useful to display the internal signal values in order to verify whether, for example, a signal is occupying the full data path dynamic range or whether it is saturated. The Graphical User Interface (GUI) is a graphical representation of the DSP chain and allows interactive communication with the prototyping board; by means of a GUI, the designer can read the value of a certain register located in whatever point of the DSP chain, modify it and check the related consequences. This can be done independently from the nature of the task being executed (whether by dedicated hardware or by software routine), since the presence of watchpoint registers at each node gives accessibility to the data on the considered bus, and hides the particular hardware software partition. The GUI is structured in 3 layers. The first layer creates the graphical snapshot of the DSP chain, where the designer can navigate, modify or just check what it is happening on the entire platform side. The second layer converts the designer actions in word streams ready to be sent to the platform processor; in this layer all information related to the DSP architecture are well defined, in order to address the right register or block. The last one, also called the transport layer,

3

2

bus-level TEST #m

1

DSP block-set B R I D G E

system-level TEST #p

IP#4

µP IP#3

memory

software pattern #p

4

Figure 6: Verification flow.

The block-level simulation (Fig. 6 – step 1) aims to verify the IP functionality when it is considered as stand alone. The checks are related to the reset condition (signals and register values), to the register read/write accesses and to the IP behavior while performing its functionality. A code coverage threshold of 95% has been assumed during each IP simulation. The effort required to perform this phase gives the device under test (DUT) a notably degree of re-usability [9] and allows easy IP check-in when involved in different projects. The bus-level simulation (Fig. 6 – step 2) phase aims to guarantee the absence of conflicts between the DUT and other peripherals either sharing the same bus or included in the same sub-system. The checks are related to the register read/write accesses (for peripheral connected to a bus) and/or to the finite arithmetic representation of data exchanged between the DUT and the adjacent IPs. The system-level simulation (Fig. 6 – step 3) phase aims to verify the correct IP behavior once it is plugged on the whole system. The main difference with respect to the previous phases is that in this environment the processor is used to perform all operations needed to verify the IP. This means that software patterns need to be written; the most suitable

language is Assembly, for the close correspondence between the actions to be done and what is really performed by the processor. The checks are related to the reset condition (register values), to the register read/write accesses and to the IP functionality. Since this simulation involves the system as a whole, all possible interactions between the DUT and the other IPs have to be tested. In the hardware emulation phase (Fig. 6 – step 4), the system is being mapped onto the prototyping board and all software patterns written for the system-level simulations are compiled and loaded in the board memory; each test becomes a program that runs on the board and produces a positive result in case the test passes, or negative result otherwise. This phase allows useful timing verification, since the IP can be verified at system level in the real hardware environment. Additional system-level verification is performed during this phase, since it is possible to execute the desired application under practical working conditions, further increasing the level of reliability. Finally early performance evaluations can be obtained by means of noise, linearity and bandwidth measures under diverse working conditions.

IV. CONCLUSIONS At the time being, the DSP chain is being tuned with an application case represented by angular rate measurement by means of a gyro sensor, while the SpaceWire routing switch [3] has been adapted to be compliant with the final issue of the standard and it is being modified to be connected to the AMBA APB bus. The intention is to prototype the overall system on a MicroBlaze fast prototyping board, featuring a Virtex XC2V1000 plus an analog front-end. The LEON has been already synthesized on the same device and successfully verified for the following configuration: 16X16 multiplier, 2 kB for both data and instruction caches, 32 kB AHB RAM, debug support unit (DSU) and it requires around 5000 LUTs. As far as the SpaceWire routing switch subsystem is concerned, the design has been developed [11] as VHDL Intellectual Property (IP) with a parametric and technology-independent description refined up to a register transfer level (RTL). The IP VHDL macrocell has been parameterized in terms of number of ports (P) and number of characters in the FIFO (C). Preliminary synthesis results for the example case of P=4 and C=16 shows a hardware complexity about 5500 LUTs for a 50 Mbps maximum datarate.

REFERENCES [1] H. Tiggeler, T. Vladimirova, D. Zheng and J. Gaisler, “Experiences Designing a System-on-a-Chip for Small Satellite Data Processing and Control”, MAPLD 2000 Conf., Sep. 2000 [2] Keutzer, K.; Newton, A.R.; Rabaey, J.M.; SangiovanniVincentelli, A. “System-level design: orthogonalization of concerns and platform-based design” - IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Volume 19 Issue 12 , Dec. 2000 Page(s): 1523 1543 [3] S. M. Parkes, “SpaceWire: Serial Point-to-Point links”, ECSS-E-50-12A, November 2002. [4] IEEE Computer Society, “IEEE Standard for Heterogeneous Interconnect”, Standard 1355-1995, June 1996. [5] S.M. Parkes, “High-Speed, Low-Power, Excellent EMC: LVDS for On-Board Data Handling”, Proc. of DSP’98, WPP-144, paper P16, Noordwijk, The Netherlands, Sept. 1998. [6] A. Fernández-León, A. Pouponnot and S. Habinc, “ESA FPGA Task Force: Lessons Learned”, MAPLD 2002 Conf., Sep. 2002 [7] http://www.gaisler.com. Gaisler Research Website. [8] M.D. May, P.W. Thompson, P.H. Welch, “Networks, Routers & Transputers: Function, Performance and Application”, IOS Press, ISBN 90 5199 129 0, 1993. [9] P. Thompson, Jones, Davis, “Network Designers Handbook”, IOS Press, ISBN 9051993803, 1997 [10] L. Fanucci, A. Giambastiani, C. Rosadini, “VLSI Design and Verification Methodologies for Automotive Embedded Systems”, Proc. Int. Symposium on Signals, Circuits & Systems, pp. 261-264, Iasi, Romania, July 1011, 2003. [11] L. Fanucci, A. Renieri and P. Terreni – “VLSI design of a routing switch for the SpaceWire serial link standard” – IEEE Proc. of ICECS2002, vol.3, pp. 1103 -1106.