Mars Student Climate Lander
“Inspiration”
Command and Data Handling Subsystem
Proof of Concept
Brandon Gilles
Zheng Guo
Jeffrey Krinsky
October 26th 2006
I
Introduction
The Mars Student Climate Lander (MSCL) mission proposal is supported by NASA's Jet
Propulsion Laboratory and the National Space Grant Student Satellite Program under the
National Space Grant Consortia. The first student-designed student-built mission to Mars,
MSCL is a low-mass, low-volume, self-sufficient payload that will travel to Mars as a
supplement to the Jet Propulsion Laboratory's proposed Astrobiology Field Laboratory
rover (AFL). AFL will deliver MSCL to the Martian surface, thereby removing the
challenges of launch, cruise, entry, descent, and landing. Once AFL establishes itself on
the surface, it drops MSCL and continues its own mission. The MSCL mission will
conduct high-priority Mars science and use the national network of Space
Grant institutions to educate and inspire a generation of students over the mission's 10year development. The designers of MSCL have named the mission Inspiration to
embody its goals of education and workforce development. The goal of this MSCL study
is to demonstrate that a small, self-sufficient payload designed and built by university
students can support an aggressive suite of instruments to conduct novel and meaningful
science on the surface of Mars. Throughout this mission’s development, the team strived
to create dynamic models of each subsystem so that the payload can quickly and easily
adapt to different instrument suites that are representative of the current goals of the Mars
Program. ~Brian Schratz, MSCL Team Lead
II
Background
At the University of Colorado Boulder, a team of three electrical engineering
students is leading the development of a prototype for the MSCL Command and Data
Handling (C&DH) system. We are starting the development of the prototype Command
and Data Handling system earlier then the development of the other subsystems in the
hopes that the Command and Data Handling prototype will be fully functional by the
time other systems get to the prototyping stage.
Since this development is so preliminary, we will design the prototype to meet the
most common demands from the payload, while filtering out outlier interfaces that may
be likely to change by the time of launch, or even by the time of science instrument
prototyping/ testing. Below we go through the requirements on the Command and Data
Handling Subsystem as of the Design Study and compare these requirements with the
requirements that the prototype will fulfill.
III
Subsystem Requirements as of 2006 Conceptual Design Study
These subsystem requirements are a summary of the requirements listed in the 2006
“Inspiration: Mars Student Climate Lander” Design Study.
1. Compatibility with the requirements from the Science Instruments, Housekeeping
(Telemetry), the communications subsystem, and deployable control.
-Figure 1 and Table 1 summarize the requirements placed on the C&DH
subsystem.
Science
Atmospheric
Temperature
Deployables
Housekeeping
Solar Panels
MET Boom
Thermisters
Ground
Temperature
Wind Velocity
& Direction
Thermal
TLS
Heaters
C&DH
Subsystem
Primary
Battery
Voltage
Secondary
Battery
Radiation
Camera
Current
Power
Controls
Pressure
Power
Distribution
Solar Array
Micro
Transceiver
UV
Proximity-1
Space Link
Protocol
IR
Comm
Dust Opacity
Figure 1 - Subsystem Connections
Table 1 - Interface Summary
System
Connection
Science
Instruments
50 Analog, 20 Analog Freq,
8 Digital (SPI, RS422)
Telemetry
Deployments and
Control
Communications
(x2)
45 Analog
Total
30 Digital
36 Digital
95 Analog, 20 Analog Freq1,
74 Digital
2. Radiation Tolerant to an acceptable error and risk level
-Actel exhibits 10-10 SEU/day (without Triple Module Redundancy)
-Xilinx exhibits up to 10-6 SEU/day with Triple Module Redundancy
3. Fits within the confines of the Warm Electronics Box constraints
-Fits within a 27 x 12 x 4.5cm3 enclosure
-Survive planetary protection (bake at 110 Celsius)
-Fully Operational to -55 Celsius
4. Low power use
-The summer design study required C&DH to use a maximum of 2 Watts total
power for the payload to meet its power margins.
5. Science Operations reprogrammable from ground
-Main science operations code must be stored in a reprogrammable media
(necessitating redundancy on storage)
6. Ability to store Science Data for multiple communication intervals
-Meet at least the memory required for a 200% margin, as listed in Table 2.
Table 2 - Summary of Memory and Processor Requirements
Totals
Storage
(Flash):
Required
5070
200%
Margin
10140
Units
KB
Memory
(RAM):
Boot Storage
(ROM):
Processing
Power
1517
3034
KB
158
316
KB
2.25
4.5
MIPS
IV
Derived Goals for Current Development
Listed below are the requirements that we see suitable to try to meet in this early
prototype.
1. Compatibility with the requirements from the Science Instruments, Housekeeping
(Telemetry), the communications subsystem, and deployable control.
-Our prototype should be capable of handling all of the inputs listed in Table 1
and outlined in Figure 1.
-The Xilinx XUPV2p development board comes with an impressive array of offboard headers making plenty of digital IO available to meet the digital
requirements listed in Table 1. We will therefore only need to come up with a
design to handle the 95 analog voltage readings, and 20 analog frequency reading
specified in Table 11.
2. Radiation Tolerant to an acceptable error and risk level
-Since this prototype is so far from launch (~2016), we are not yet prototyping
with space-rated hardware.
3. Fits within the confines of the Warm Electronics Box constraints
-Again, since we are so far from launch, we are not worrying about flighthardware size constraints
4. Low power use
-Same launch date argument here as above.
5. Science Operations reprogrammable from ground
-Ability to program the FPGA from (both VHDL and C-code) from a 512 MB
CompactFlash card we have available to us at Space Grant.
6. Ability to store Science Data for multiple communication intervals
-Since we are using the Digilent XUP V2P development board with 256 MByte
DDR memory and a 512 MB CompactFlash card, the hardware will easily meet
and exceed the memory requirements set forth by the summer design.
Additional Goals and Requirements:
Software
Since the summer design specified using either a Microblaze soft processor core
or a Leon (Sparc V8 architecture) soft processor. We would like to get both
processors up to the point at which they can run C-code on the Virtex-II.
Optimally, we would like to install a RTOS on both and get them both
1
The difference between analog lines and analog frequency lines as defined in this document and the
MSCL summer design study lies in the frequency of the incoming signal. We refer to analog lines as those
that have a very large fundamental period (T~>1) and most if not all of the information is contained in the
instantaneous voltage. We refer to analog frequency lines as those where not only does the instantaneous
voltage matter, but the frequency content of the signal matters, these signals are expected to be up around
25 kHz (Sonic Anemometer frequency, one of the higher frequency devices). In the other words, analog
frequency lines are those whose signal is destined to go through an FFT or require DSP.
communicate with the sensor board. We are not sure if this second task will be
possible to accomplish due to the time constraints of this semester.
-ability for this board to connect w/ various different Xilinx development boards
Sensor Board
The sensor board we are developing this semester may prove extremely useful in
testing and debugging not only MSCL hardware, but projects in general at the
Colorado Space Grant. To try to make the board as useful as possible for projects
outside of the MSCL prototype, we will design the board to work with as many
Xilinx boards as possible. That being said, the board of which we want to make
sure our sensor board is compatible is the Digilent Spartan 3 starter board, one of
the other popular student FPGA boards that is readily available at the Colorado
Space Grant.
V
Current Development
The design team this semester is working with the Leon3 and the Microblaze soft
processor cores to do a proof-of-concept of the Command and Data Handling subsystem
as outlined in the summer design document. The design team is also developing a sensor
board for this proof of concept.
The goal of implementing the Leon3 is to determine the degree of difficulty of
configuring and installing the Leon3 from scratch on a specific architecture. By doing
this, the design team will get an idea of the feasibility of writing code for the Leon3 on
Xilinx hardware and the porting the code for the Leon3 on Actel Hardware. The reason
for wanting to be able to transition from development on Xilinx to flight with Actel is
that Actel FPGAs use less power and have a much higher Single Event Upset tolerance
than the Xilinx counterparts, making them better for deep-space applications, as
mentioned in the MSCL summer design document. Although the Actel chips are better
suited for deep-space applications than the radiation tolerant Xilinx FPGA, the Xilinx
FPGAs are far better for development, since they are SRAM based and therefore actively
reprogrammable.
The goal of the sensor board is to allow the Leon3 and the MicroBlaze soft processor
cores to be tested with real-world signals and interfaces similar to required by the final
MSCL Command and Data Handling System.
1. Issues and discussion point
i.
FPGA: We need radiation tolerant FPGA for space use. Based on research
in the summer, Actel is the best for tolerance, and no need for TMR. But it is
one time programmable, which is not favorable for student development.
XQR2V3000 has pretty good tolerance also. It is SRAM-based, so easy to
change the design, which saves our cost.
We decided this was the best for our design now. (We are keeping the option
of going back to Actel later on when we have fully verified our design).
Since we have X2V30P (Virtext-2 Pro), which has the similar FPGA chip as
(actually more power full than) XQR2V3000, we decided to work on this first
so we don’t have to purchase a new board now. But later we might need to
purchase a QR2V FPGA.
ii.
CPU core: Since we are going to use an FPGA to run the C&DH system. Soft
core written in HDL is the best solution for us, since hardware processor will
cause a higher total power usage.
Xilinx MicroBlaze is a mature product, it has great performance in terms of
DMIPS/slice. Furthermore, tool support for the MicroBlaze is quite mature
and has a large support base. But it is not compatible third party FPGA,
which denies our option to go back to Actel. In this setting, we decided to
work on Leon 2/3, a open source RISC processor in parallel. Compared to
MicroBlaze, it takes more area, which would be a problem for further TMR.
Also tool support is not as good as MicroBlaze.
iii.
EDK uses a modified cygwin called xygwin, which seems to be problematic
to co-exist with cygwin (especially after you modify some default cygwin
settings). Check the environment variables, mount points, and the version of
make. There might be an article how to patch EDK to use cygwin. (So later
we started to use Linux to avoid the confliction)
2. Work during the semester
1. Got Started: Worked out a plan for this semester with Brandon and Jeff. Based on the
importance level of the blocks, our time, experience and utilities at hand(software,
hardware, funds), we will do the following (some may be done in parallel).
i. Soft processor core – brain of the system
ii. A/D sensor PCB board
iii. Glue logic and test
2. Research and Implementation of Leon processor
i. Research on its architecture and instruction set.
ii. Got xgrlib from http://www.gaisler.com which is a good support of
implementation
iii. Tried to implement the design onto board – because the lack of support, we have
to manually run synthesis and implementation including modification of UCF
files where we got stuck.
iv. Contacted Jiri Gaisler from Gaisler research org. for a solution.
3. Implementation and configuration of MicroBlaze core
i. Did research on the architecture and working flow of MB processor
ii. Created a basic LED sequencing system based on SoC hardware and software codesign concept.
Bitstream was generated and downloaded to the board. It
worked fine.
VI
Results (Meeting the Derived Requirements)
-Sensor PCB successfully designed, manufactured, and components soldered on.
-passes signal continuity tests, power (2.5V, 3.3V, 5.0V) and ground checks
-XUP signals are successfully getting to the ADC (U7)
-ADC (U7) is not responding, possibly due to FPGA signaling at 2.5V instead of
the required 3.3V
Figure 2 - Completed Sensor Board
-Notice that the two 50-pin and one 26-pin connectors are left unpopulated.
These champ type connectors are commonly used to connect PCBs that have a lot
of IO. The purpose of these connectors is to allow later connector boards, maybe
even bread-boards to be hooked the sensor board for easier access to the large
amount of analog inputs. Currently it is easier to just input individual channels
into the holes of the unpopulated connectors.
-Leon3 successfully synthesized and communicating to grmon on the PC.
-Capable of downloading executables to the processor
-Capable of running downloaded code, but did not have time to run anything of
importance
-Have not written any in house C-code to compile and run on the Leon 3.
-Have not started the necessary code to communicate with the sensor board
-We were trying to get MicroBlaze to communicate with it first
The process of actually getting the Leon3 processor was quite grueling for us. The setup
that finally worked for us was Xilinx ISE 8.2 and Ubuntu Linux (Breezy Badger) using
the most up-to-date version of grlib from Gaisler research. The entire process is
documented and available on request: contact the author.
-MicroBlaze successfully set up and capable not only of running code, but outputting the
correct SCLK, CS_bar, and DOUT
- Tried to implement ucLinux, an operating system on MicroBlaze. Hardware
bitstream was generated and downloaded, while source code from the web has
some error which can’t be fixed with our knowledge, so can’t generate
applications on it.
VII Future work
1. Continue work on Leon (Gaisler.com)
i. Test and debug writing C code, compiling and running
ii. Install and RTOS, get it running
iii. Install and run applications on the RTOS
2. Debug the Sensor PCB
i. By any means necessary get the AD7490 to produce and output on DOUT
-change the output voltage to 3.3V for the FPGA DOUT signal (slave DIN)
-recommendations online are to write “bit-bang” SPI code first of all, not using
the complex included libraries, but just using GPIO and software, to try to get an
output
4. Install an RTOS and applications on MicroBlaze.
VIII
Conclusion
The use of a soft processor core in tandem with radiation mitigation techniques
can provide a very powerful, scalable solution to current low-cost, high risk student
satellites. However, as this paper points out, using the soft-processor core adds a level of
complexity to the design that necessitates a longer development cycle: up front time is
required to make the soft-processor functional.
VIV
Lists of Resources Found
//aquarius/Mars JPL/documents
Virtex-II datasheet.pdf
Virtex-II pro datasheet.pdf
leon2-1.0.30-xst.pdf
Leon-tutorial-Altera.pdf
Leon-tutorial-Xilinx.pdf
(Virtex2)
microblaze_ref_guide.pdf
uclinx-xupv2p_rev_1_2.zip
Leon 2 user manual
Leon implementation tutorial on Altera Board
Leon implementation tutorial on Xilinx Board
MicroBlaze processor reference guide
ucLinux system EDK files
uc-MicroBlaze.pdf
ucLinux system implementation tutorial with MicroBlaze
AltiumDesignTutorial.pdf
Altium PCB design tutorial
Evaluation_of_synthesizable_CPU_cores.pdf
Evaluation and comparison between
3 kinds of soft processors
SEUtestonVirtex2.pdf
SEU Mitigation Testing of Xilinx Virtex II FPGAs
Web Resources:
http://www.gaisler.com/
-- Leon processor source code and document
http://www.xilinx.com/univ/xupv2p.html -- Xilinx XUP Virtex II Pro Development
System