Experiences Designing a System-on-a-Chip for Small Satellite Data Processing and Control

Experiences Designing a System-on-a-Chip for Small Satellite Data Processing and Control
Experiences Designing a System-on-a-Chip for Small
Satellite Data Processing and Control
Hans Tiggeler, Tanya Vladimirova, Daixun Zheng, Jiri Gaisler✼
Surrey Space Centre, University of Surrey, Guildford, Surrey, GU2 7XH,
email: [email protected], [email protected],
[email protected]
✼
European Space Agency, Spacecraft Control and Data System Division,
email: [email protected]
Abstract
The continuous evolution of communication satellite platforms demands the use of
modern approaches to system design. A system-on-a-chip realising the main functions
of an on-board computer is an important step towards further minituarisation of small
satellites. This paper describes a single-chip implementation of a simplified version of
a Surrey Satellite Technology Limited (SSTL) on-board computer. The specification
of the system and a prototype based on a XILINX Virtex FPGA are discussed.
Synthesis results of the microprocessor and peripheral IP cores are reported.
Keywords : System-on-a-Chip, Satellite, On-Board-Computer, IP Core, Synthesis.
1. Introduction
The knock-on effects of the enduring trend towards ever smaller electronic
components have already brought on significant size reductions in aerospace
technology. Future advances are set to pave the way for a new class of science and
exploration missions. Satellites are generally classified by weight, with standard ones
weighing a ton or more, small satellites coming in between 100 kilograms and a ton,
and microsats considered those that fall between 10 and 100 kilograms. The up-andcoming new wave of smaller satellites currently in the pipeline are so-called
nanosatellites, ranging from 10 kilograms down to 1 kilogram, and picosatellites that
weigh in at less than 1 kilogram. The smallest category envisioned is the femptosat at
less than one-tenth of a kilogram, a satellite that would handle very simple missions
and would be implemented on a single chip, this is why they are also called satelliteson-a chip. The work reported here forms a part of a long-term research programme
codenamed “ChipSat” which aims to build a satellite-on-a-chip.
This paper presents the results of a recent research experiment that targets at
scaling an existing on-board computer (OBC) down to a system-on-a-chip (SoC). As a
reference design is chosen an OBC developed by the Surrey Satellite Technology
Limited (SSTL), a company owned by the University of Surrey in Guildford, UK. The
SoC is prototyped on a single high-density programmable logic array chip using soft
intellectual property (IP) cores. Issues related to operation in space environment
although considered are not included in this paper. Section 2 details the system
1
specification. Section 3 discusses the SoC components. Section 4 comments on the
implementation process, describes an XCV800 prototyping board and presents lessons
learnt from the experiment. Section 5 concludes the paper.
2. System Specification
“SoC design is the next step in the technology evolution that represents the
combined tools and methodology to effectively develop very large complex systems,
on a single silicon substrate, in a very short design cycle. The integration side of SoC
design starts with partitioning of the system around the primarily pre-existing, blocklevel functions and identifying the new or differentiating functions needed” [1].
System-On-a-Chip design is much more than high-level integration of IP cores such as
microprocessors, memory and peripherals. It requires "system expertise" and "system
know-how" in order to maximise the effect of translating system functionality to a
single-chip implementation.
“SoC designs are typically either derivative designs with increased
functionality, or convergence designs where previously separate functions are
integrated” [1]. In this experiment we were dealing with the latter - an existing
microsatellite on-board computer, named OBC386 and developed by SSTL [2], was
used as a reference design. The main goal was to translate the technical capabilities of
the OBC to a single-chip design achieving a cost-effective solution. The
straightforward approach to that would be to purchase commercially available IP cores
compatible with the ICs in the OBC circuit board and to integrate them onto a single
chip. However, this approach was ruled out at the beginning since it was realised that
it would lead to a very expensive product. Also it appeared that a soft IP core of the
386EX micro-controller was not available. We then decided to go for an approach
based on using public domain soft IP cores where possible as well as in-house
peripheral IP core development.
The decision to develop peripheral cores in-house instead of purchasing them
came down to two criteria - cost and complexity. A large number of peripheral cores
are available commercially, however a premium must be paid to obtain the IP core in
commented source form rather than in a target netlist form. Also we found that the
software “bloatware” trend was also applicable to commercial chip development –
manufacturers tend to introduce excessive capabilities in their pursuit for larger
markets. By carefully analysing our own minimum hardware requirements we could
significantly reduce the complexity of the required soft core and indeed this is where
system know-how and expertise come into play in SoC development.
Figure 1 shows the system block-diagram of the SoC. It consists of a SPARC
V8 microprocessor core “LEON” [3,4] connected to a ROM bootstrap loader and a
memory error-detection-and-correction (EDAC) unit via a system bus, an AMBA
AHB bus [5] and a number of peripheral modules. Two of the modules - the LEON
microprocessor core and the HurriCANe CAN - are developed by the European Space
Agency (ESA) and can be downloaded from the Web free of charge. The modules
developed in-house are as follows – EDAC unit, bootstrap loader, HDLC controller,
network interface, true IDE interface, CORDIC mathematical co-processor, peripheral
bus interface modules based on the AMBA bus. The CORDIC co-processor core is
still in a process of development.
2
RX0 CLK
RX1 CLK
RX2 CLK
TX
CLK
CAN
HDLC RX
Controller
HDLC RX
Controller
HDLC RX
Controller
HDLC TX
Controller
FIFO
FIFO
FIFO
FIFO
AMBA AHB
AMBA AHB
AMBA AHB
AMBA AHB
BUS LVDS
CAN
Interface
RESET
Parallel Port
Interface
FIFO
AMBA APB
AMBA AHB
AMBA BUS
AMBA AHB
System Bus
AMBA AHB
AMBA AHB/APB
ROM LUT
(16,8)EDAC
Bootstrap
PIO
DECDED
! " # $% & " & $
Linear
Regulator
LEON Sparc V8
1M*64
UART
CORDIC
CF+ I/F
True IDE
Coprocessor
170Mbyte
SRAM
Microdrive
Figure 1 SoC System block-diagram
The decision on the components and structure of the SoC has been made as a
result of translating the structure and functionality of the reference SSTL on-board
computer system OBC386 into an equivalent organisation consisting of IP blocks.
Figure 2 illustrates the mapping between the original system and the SoC. Labels in
red & non-italic font give the names of the components of the reference system and
labels in blue & italic font give the names of the corresponding SoC elements.
GLUE Logic
FPGA
Bulk Data Storage (128MB)
IBM Microdrive
EDAC
SSTL IP Core
CAN TTC Node
ESA Hurricane IP Core
Program Memory (4MB)
3D+ Stackable SRAM
Bootstrap loader
FPGA LUT
HDLC Controller (4CH)
SSTL IP Core
386EX Processor
ESA LEON IP Core
387SL CoProcessor
SSTL Cordic IP Core
10BASE-2 Network
Bus LVDS
CAN Peripheral
ESA Hurricane IP Core
Figure 2. Mapping of the OBC386 Reference Model
3
3. SoC Components
This section describes each of the individual components of the system-on-achip. The IP cores have been synthesized in isolation using delay optimization. The
presented synthesis results are derived using the synthesis tool Synplify 6.0 from
Synplicity.
3.1 Microprocessor IP Core
The processor core that we have chosen to use in the SoC design is the public
domain IP core LEON [3,4] developed by Jiri Gaisler from the European Space
Agency (ESA). This high quality processor core is binary compatible with the SPARC
V8 integer instruction set architecture [6]. LEON is coded in VHDL and can be
customised for different targets (FPGA/ASIC) and EDA tools. A fault-tolerant
version, targeted primarily at the space segment, is available under license agreement
from ESA. The LEON processor is supported by a full set of GNU based development
tools such as C/C++ compiler GCC, AS assembler and GDB debugger. A real-time
POSIX compliant operating system, RTEMS [7], is also ported to this processor. At
the time of writing this paper a number of people [8] are working on porting the
uClinux kernel [9] to LEON. Standard Linux SPARC port can not be used due to the
lack of a memory management unit.
LEON
Integer Unit
Sparc V8
I-Cache
LEON Processor
Module
CoProc
Interface
AMBA Extention
Module
FPU
Interface
AHB
CONTROL
D-Cache
AMBA AHB BUS
Memory Controller
8/16/32
Memory Bus
Timers
UARTs
IRQ
PIO
AHB
AHB/APB
BRIDGE
APB
AMBA APB BUS
Figure 3 LEON-2.2 Sparc V8 IP Core
3.2 Memory Error Detection and Correction Unit
The program memory on the OBC386 is protected against radiation-induced
bit flips by an Error Detection and Correction (EDAC) unit. In contrast to the faulttolerant LEON version the freely available version does not have an EDAC unit.
Recent studies carried out by SSTL [10] have shown that, although rare,
double bit upsets by a single heavy particle can occur in modern high-density memory
(4 Mbit die). For this reason the EDAC IP core was based on a double-bit correcting
Quasi-Cyclic (16,8) shortened EDAC code [11] rather than the traditional single-bit
correcting Hamming code [12] as supported on the fault-tolerant LEON version. The
core was developed in-house. It consists of a combinatorial circuit that generates
parity during a write cycle and stores it at the same address as the data. During a read
cycle parity is generated again and compared against the stored parity. If the resultant
4
syndrome is not equal to zero than a Look-Up Table (LUT) is used to match the
syndrome word to an error location pattern identifying the flipped bit(s). The data is
then corrected before passing on to the CPU. The core occupied 12% of a XILINX
XCV300 and 24% of an Actel 54SX32 FPGA.
3.3 Bootstrap Loader
A small bootstrap loader IP core, based on a LUT, was developed in-house. It
is functionally identical to the EPROM version in the reference OBC386 design. The
operating system and application software are uploaded after launch into EDAC
protected memory. This way of operating provides the maximum flexibility and
allows for later updates and patches to be easily applied.
The frame format used on the bootstrap loader consists of a CRC protected
header, which contains the load/execute address and the number of bytes followed by
a CRC protected block of data. The CRC protected header prevents loading into an
address that is corrupted by the communication channel.
A Virtex LUT can be configured as a 16 × 1 ROM or 2 LUT’s in a slice as a
ROM32 × 1 module. These ROM modules can be instantiated by adhering to the
synthesis tool ROM coding template or informing the synthesis tool by using
attributes. The LUT module count depends on the used coding style as depicted in
Table 1. A very useful utility named Kompiler [13] developed by NASA was used to
determine the best coding style for the used synthesis tool. As shown in Table 1 the
case coding style resulted in the lowest LUT count.
Table 1 Synthesis results versus coding style
FPGA
Coding Style
Logic 1
Logic 0
bit coding
Case Statement
Constant Array
XCV300-4 (Area Optimised, Synplify 6.0)
LUT
MHz Note
142
147
147
96
128
40.1
40.0
40.0
61.8
61.8
ROM not recognised
ROM not recognised
ROM not recognised
32ROM16x1, 32ROM32x1 Instantiated
64ROM32x1 instantiated
3.4 HDLC Controller
In the reference OBC386 design the communication between the satellite and the
groundstation is based on High-Level Data Link Control (HDLC) frames. These
frames are simple CRC delimited data frames with a two-byte synchronization header
(flag). Zero insertion and deletion is added to prevent the synchronisation bytes to
appear in the data section (bit-stuffing). Most commercial HDLC controllers are
compatible with the Zilog’s 8530 SCC controller. The 8530 supports byte-oriented
protocols such as IBM Bisync and bit synchronous protocols such as SDLC as well as
the required HDLC. It further supports a range of programmable option such as
number of databits, CRC type, data encoding style, frame formats, synchronisation
methods and error management. Supporting all these options would result in a rather
large and complicated IP core. Analysis of the software communication drivers used
on the reference OBC386 shows that only a very small part of the 8530 capabilities
are used. In effect only a fixed format HDLC controller with no clock recovery and a
5
simplified error management was required. This significantly simplified the core
developed and as a result the core was developed in-house over a two-month period.
The requirements of the core can be summarised as follows:
• Flag Generation and Detection
• Abort and CRC Generation and Checking
• Transmit Underrun and Receive Overrun Flags
• Zero Insertion and Deletion
• 32-bit AMBA AHB Bus Interface
• 32-Byte synchronous FIFO to reduce interrupt latency
• Must supports Back-to-Back Transmit and Receive Frames
• Programmable Baudrate Generator
A single channel transmit/receive core requires only 6% of an XCV300 and 36%
of an 54SX32. The estimated clock frequency after place and route was 98 MHz for a
XILINX XCV300-4 and 68 MHz for an Actel 54SX32-3.
3.5 CAN Interface
The reference OBC386 uses a distributed Telecommand and Telemetry system
based on the Controller Area Network (CAN) protocol. CAN, which was originally
developed for the automotive industry, provides very strong error management, fault
isolation and fault tolerance. This is not surprising given that CAN was designed to
handle critical car function such as ABS. The network which is standardised by ISO
11898/11519 is fully deterministic, supports priority and can operate at bit speeds of
1.25Mbps.
Several commercial CAN IP cores are available. However, we chose to use a
CAN controller IP core named HurriCANe that is available free of charge from the
European Space Agency [14]. This HurriCANne CAN core has a standard AMBA
APB bus interface and was therefore easily interfaced to the LEON core. The core can
be synthesised to 51% of a 54SX32 and 11% of a XILINX XCV300.
3.6 Network Interface
The network interface on the reference On-Board Computer is implemented by
a 10BASE-2 Ethernet controller. This network interface is used to transfer images
between the satellite’s cameras and the On-Board Computer Solid State Memory. The
bus 10BASE-2 was selected to allow multiple cameras and the OBC to be connected
to the same network without a hub.
The SoC employs a functionally equivalent network interface in the form of a
Bus LVDS parallel-to-serial converter. This device serializes 8 bits of data into a high
bandwidth (400-600 Mbps) bit stream and supports clock recovery and flow control.
A simple core consisting of an AHB controller with an 8-word FIFO was developed to
communicate with the LVDS bus controller. The core required 3% of a XILINX
XCV300 (278 LUT’s) and 32RAM16x1D cells. Changing the target FPGA to an
Actel 54SX32 resulted in 21% utilisation (262 R-Cells and 494 C-cells). The high
utilisation of the Actel FPGA is caused by the lack of RAM cells.
6
3.7 True IDE Interface
The On-Board Computer supports a maximum of 128 Mbyte of Solid State
Memory (SSM). Although stackable FLASH and DRAM memory provide very high
storage density, it is still not as high as provided by harddisk technology. At the time
of writing this paper harddisk densities of 400 Mbyte/cm3 (2.5inch drive) are common
place. To replace the SSM with a harddisk technology an IBM microdrive [15] was
selected. Apart from the very small form factor (43mm*37mm) and high storage
density (130 Mbyte/cm3) the drive has surpassingly good shock (1500 G1ms) and
vibration 3 G5-500Hz characteristics. These characteristics are vital given the high levels
of shock and vibration endured during launch.
The interface to the microdrive requires nothing more than a fixed length IDE
read-and-write cycle. Direct Memory Access is not supported by the microdrive which
limits the access bandwidth to a maximum of 5 Mbyte/sec but at the same time
significantly simplifies the interface. The interface core that was developed consisted
of an AHB controller with a delayed read-and-write cycle. The interface occupied 3%
of a XILINX XVC300 and 14% of an Actel 54SX32.
3.8 Cordic Co-Processor
The reference OBC386 is equipped with a low power 387SL floating-point coprocessor. This processor is solely used for Attitude Determination and Control
(ADCS) system tasks. A suitable soft core floating point co-processor was not
available within the time constraints and budget of this experiment. However an RTL
model of such a mathematical co-processor core has been developed in Verilog HDL
and has been simulated [16]. The core evaluates the international geomagnetic
reference field (IGRF) model [17] used in satellite attitude determination, as well as
the mathematical operations of multiplication, division and square root and the
trigonometric functions sine and cosine. It has been decided to use the CORDIC
algorithm for the calculation of the mathematical operations and sine and cosine, due
to the effectiveness and simplicity of that algorithm [18]. The full functionality of the
core is as follows:
• Polar Components of the Magnetic Field Br, Bt and Bp (fixed-point format)
• Geocentric Inertial Components of the Magnetic Field Bx, By and Bz, or X, Y and
Z - the North, East and Nadir Components Relative to an Oblate Earth (fixed-point
format)
• Multiplication, Division, Square Root, Sine and Cosine (fixed-point and floatingpoint formats)
The interface between the CORDIC co-processor and the LEON will be a simple
parallel port with register bit handshake mechanism. The CORDIC co-processor is
currently under development.
3.9 Peripheral Bus Interface
One area which required careful attention was the processor-peripheral
interface. A well-defined, well-documented SoC processor bus can significantly
reduce the interface complexity and associated development time. A large number of
SoC busses have been defined and most are well documented and available freely on
the Web. One of those bus protocols which is supported by the LEON processor is the
7
ARM’s AMBA (Advanced Microcontroller Bus Architecture) bus [5]. LEON supports
two out of the three defined AMBA bus protocols. The first supported bus protocol is
the Advanced Peripheral Bus (APB). APB provides a simple interface to low power
peripherals and configuration registers The signals are latched and synchronised to the
system clock. Only the HurriCANe CAN IP core uses this bus. The second supported
bus is the Advanced High Performance (AHB) bus, which is used for interconnecting
processors, DMA controller, memory controller and high performance peripherals.
The last and unsupported bus protocol is the Advanced System Bus (ASB) that
provides similar service as the AHB bus but lacks the high performance features. In
order to reduce the number of bus protocols and to reuse the interface code all inhouse developed IP cores were interfaced to LEON using the AHB bus.
4. Implementation Issues
The SoC project was implemented using PC-based EDA tools. The synthesis
tool was Synplify 6.0 from Synplicity and the Place & Route tool was Xilinx
Foundation 2.1i. Table 2 shows the synthesis results and estimated frequency of the
individual cores and the total flattened SoC module.
Table 2 Synthesis Results, Synplify 6.0, delay optimised
Module\FPGA
LUT
LEON-2.2 core
EDAC
Bootstrap
5152
850
96
HDLC-RX
HDLC-TX
CAN Hurricane
Network Port
IDE
Cordic
SoC
208
207
718
278
198
---6707
XCV300-4
Mem
14 BlockRAM
32*ROM16x1,
32*ROM32x1
32*RAM16, 151 rb
32*RAM16, 123 rb
430 register bits
32*RAM16
116 register bits
18 BlockRAM
MHz
R-Cell
54SX32-3
C-Cell MHz
20.7
45.9
61.6
0
652
43.7
99.3
103
57.6
109
97
285
260
524
262
278
246
216
937
494
278
77.5
69.4
47.2
94
98
Note
1
2
2
3
3
17.4
Notes:
1
Does not fit in an Actel 54SX32 device
2
rb = register bits
3
Not yet implemented
The cores were pre- and post- Place & Route simulated using Modeltech 5.3d.
The design work was carried out on a relative slow PII-300 running under NT4.0 with
256 Mbyte of PC100 SDRAM.
Simulating performance was poor and roughly 54 µsec of simulation time
(equal to 24 SPARC V8 instructions) could be executed per second. This number was
reduced to 1.4 µsec and 0.7 µsec for post Place & Route simulation and post Place &
Route simulation plus SDF back annotated timing respectively.
8
Synthesis was performed quicker than expected. The LEON core took no more
than 14 minutes to synthesise, even with all peripherals added this figure increased
only marginally to 17 minutes. In order to compare the synthesis results obtained with
Synplify two more synthesis tools were tried - FPGA Express 3.0 and Spectrum 2001.
Unfortunately, the VHDL language support of FPGA Express was not sufficient to
handle the LEON core and Leonardo’s Spectrum 2001.a could not extract the
SelectRAM components for the LEON cache memory. It was deemed too complex
and time consuming to modify the LEON core for either synthesis tool. It must be
noted that Leonardo’s Spectrum 1999.x does synthesise the LEON core correctly.
The Place & Route tool within the Xilinx Foundation 2.1i package took most
of the implementation time. Selecting the maximum Place & Route effort and
generating the structural VHDL and associated SDF file took nearly 50 minutes. The
whole cycle from VHDL source file to Virtex bitsream took no more than 70 minutes.
This number was reduced to 40 minutes on a PII-850 with PC100 SDRAM memory.
Finally downloading the design into a XILINX XCV800 using a parallel DLC4 cable
took less than a minute.
4.1 Purpose-Built Prototyping Board
To enable early software development and to get familiar with the LEON
processor core a simple prototyping board was developed. As depicted in Figure 4 the
board consists of a high density Virtex FPGA, a 4 Mbyte SRAM module and a
number of line drivers. The board was developed in-house over a one-month period,
the cost was roughly £1000 pounds for a XILINX Virtex XCV800-4 FPGA based
version. LEON was synthesised, place-and-routed and downloaded into the prototype
board without any modification to the core. Using 70 ns memory with 1 waitstate, 2
Kbyte of internal cache memory and clock frequency of 25 MHz, LEON managed to
produce 37 K Dhrystone/second (ver 2.1). The power consumption was measured at
2.2Watt.
+5v
STATUS
TX1
RX1
2 ch
XCV800
+3.3v
- 6-2 71 . 8 /3 9 044 5: 1
FPGA
HQ240
SW
LVDS
4 ch
LVDS
HDLC
IDC
I/O Port
GCLK2
GCLK3
IDC
GCLK1
GCLK0
+3.3v
SRAM
1M*32
2M*32
+3.3v
CS
RAMSN[1..0]
OE
RAMOEN
WR
RWEN
DBUS
ABUS
82C250
(TJA1050)
CAN
JTAG
3*3
MICRODRIVE
RS232
TX2
RX2
VCCI
D-9M
GCLK0 GCLK1
VCCO
LEON-1 Prototype Board
COM RS232
+5v
NETWORK
J1
DE
F I JG K HL ; > <? @ =A
BC
' ( )* +*
' ( ), +'
RESET
+5v
+3.3v
Figure 4 LEON Prototyping Board
9
4.2 Lessons Learnt
During the implementation stage of this project a number of important lessons were
learnt:
• The XILINX Virtex FPGA is more than suitable for SOC prototyping - the entire
OBC386 SoC fits in half an XCV800 chip.
• Debugging time is mostly spent on glue logic between IP cores and not on the IP
cores development themselves.
• Differences between simulation results and hardware testing were observed. This is
mainly caused by inaccurate modeling of the LEON processor and its interaction
with external bus components.
• Synthesis results depend on coding style.
• Simulation speed is insufficient for application software development.
• Use of ready-made IP cores requires considerable support from the IP developers.
• At the time of writing this paper LEON could only be synthesised on a PC using
Synplify, it was deemed too much effort to modify it for another synthesis tool.
• The implementation of high-performance processor and peripheral IP cores
requires a significant amount of memory blocks on the programmamable logic
device.
• Re-use of an existing core takes considerable design effort.
• Availability of a prototyping FPGA board enables early software development.
5. Conclusions
This SoC experiment has shown that it is possible to implement the
functionality of a small satellite OBC on a single programmable logic chip. A reduced
cost SoC solution can be achieved using public domain IP cores and in-house core
development, however the design effort in reusing existing IP cores can be very high.
When reusing an existing core IP core, it pays off to look around for the right
synthesis tool – the one that provides support for the particular IP core. Design effort
and time can be saved considerably by CAD software vendor assistance, in fact good
customer support by EDA vendors is vital to the success of complex SoC projects.
Main constraint in SoC design is the amount of on-chip memory, this constraint is
equally valid in SoC prototyping using programmable logic. Design work advances
quicker and smoother if a suitable prototyping board is available at an early stage of
the project. The used PC-based EDA tools ModelSim, Synplify and Foundation
Express have shown good performance in handling a complex million-gate design.
The Wold Wide Web becomes an invaluable source of information in SoC
design. The ever increasing number of high quality IP cores available freely on the
Web as well as the exchange of information in specialists mailing lists serve as a
driving force to SoC development targeted at specific needs and applications.
Acknowledgments
This project would have taken significantly longer to develop if it weren't for
the existence of the high-quality free LEON and CAN IP Cores. We would therefore
like to acknowledge the valuable contribution to this project of Luca Stagnaro from
the European Space Agency.
10
References
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Linchpin Technologies and Methodologies for Change, White Paper, 1999,
Cadence Design Systems, Inc.,
http://www.cadence.com/whitepapers/linchpin.pdf
SSTL Services and Satellites,
http://www.sstl.co.uk/services/subpage_services.html
J. Gaisler. A Portable Fault-Tolerant Microprocessor Based on the SPARC V8
Architecture, DASIA99, Lisbon, Portugal, 17-21 May 1999.
LEON Source code: http://www.estec.esa.nl/wsmwww/leon/
AMBA Bus, http://www.arm.com/sitearchitek/armtech.ns4/html/amba
SPARC International, http://www.sparc.org/standards.html
RTEMS, http://www.rtems.com/RTEMS/rtems.html
LEON Mailing List, http://www.egroups.com/group/leon_sparc/
uClinux, http://www.uClinux.org/
C.I. Underwood, R. Ecoffet. Observations of Single-Event Upset and MultipleBit Upset in Non-Hardened High-Density SRAMs in the TOPEX/Poseidon
Orbit, IEEE/NSREC Conference, Snowbird, Utah, USA, Jul, 1993.
M.S. Hodgart, H. Tiggeler. A (16,8) Error Correcting Code (t=2) for Critical
Memory Applications. DASIA2000, Montreal, Canada, 22-26 May 2000.
W.W. Petersen, and E.J. Weldon. Error-correcting Codes, MIT Press. 2nd
edition, 1972, pp 256- 261.
I. Kleyner, R. Katz, H. Tiggeler. System-On-Chip Data Processing and Data
Handling Spaceflight Electronics, MAPLD99, D-2, Laurel, 1999.
HurriCANe IP Core, ftp://ftp.estec.esa.nl/pub/ws/wsd/CAN/can.htm
IBM Microdrive, http://www.storage.ibm.com/hardsoft/diskdrdl/micro/
A. Quddus. FPGA Implementation of a CORDIC Co-Processor for ADCS of a
Satellite, MSc Project Report, School of Electronic Engineering, University of
Surrey, Guidford, UK, 2000.
J. Wertz. Spacecraft Attitude Determination and Control, D.Ridel Publishing
Company, London, 1985.
T. Vladimirova and H.A.B. Tiggeler, FPGA Implementation of Since and
Cosine Generators using the CORDIC Algorithm, Proceedings MAPLD99
Military and Aerospace Applications of Programmable Devices and
Technologies, A-2, Maryland USA, 1999.
11
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement