Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 1
GAIA PDHE GP-ASG-FR-0001
GAIA PDHE Final Report
Document No: GP-ASG-FR-0001
Issue No.: 1
Rev. No.: -
Issue Date: 12.12.2005
Name Date
prepared by Astrium GAIA PDHE Team
12.12.2005
approved by Ulrich Denskat AOE72 12.12.2005
authorized by Ulrich Denskat AOE72 12.12.2005
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 2
GAIA PDHE GP-ASG-FR-0001
CHANGE RECORD
Issue Date Sheet Description of Change Release Reference
draft 28.07.05 all New draft
1.0 28.10.05 First issue
28.10.05 78 Include chapter 7.4.5.9 “Additional Motorola Board Tests”
28.10.05 55 Change chapter caption 7.4.4 to “Data-Rates for Interface VPU / PDHU”
03.11.05 55 Correct numbers of data rates chapter 7.4.4
03.11.05 74 Correct numbers table 7-4 and figure 7-41
03.11.05 71 Correct numbers table 7-3
03.11.05 76 Correct numbers table 7-6 and figure 7-42
04.11.05 80 Change chapter caption 7.5.1 to “Software” and chapter caption 7.5.2 to “Hardware - processor board”
04.11.05 79 Include chapter 7.5.1.1 -7.5.1.3
04.12.05 20 Additional information in chapter 6.4.1 on architecture
04.12.05 26 Additional information in chapter 6.4.5 on performance figures
04.12.05 30 Additional information in chapter 7.1.2 on demonstrator implementations specifics
04.12.05 36 Additional information in chapter 7.1.3 on demonstrator performance
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 3
GAIA PDHE GP-ASG-FR-0001
1 DOCUMENTS...................................................................................................................5
1.1 Applicable Documents..............................................................................................................................................5
1.2 Reference Documents...............................................................................................................................................5
2 SCOPE.............................................................................................................................7
3 ACRONYMS.....................................................................................................................8
4 OVERVIEW AND BRIEF RECALL OF ORIGINAL OBJECTIVES OF TDA ..................11
5 SCOPES OF TDA AS ACTUALLY RUN .......................................................................12
6 PHASE 1 ANALYSIS AND REQUIREMENTS...............................................................15
6.1 Overview Requirements.........................................................................................................................................15
6.2 PDHU Requirements..............................................................................................................................................18
6.3 VPU Requirements.................................................................................................................................................19
6.4 Architecture of VPU...............................................................................................................................................20 6.4.1 Overview....................................................................................................................................... 20
6.4.2 "Baseline" Unit Architecture.......................................................................................................... 20
6.4.3 "High-Performance" Unit Architecture .......................................................................................... 23
6.4.4 Architecture Budget Estimation .................................................................................................... 25
6.4.5 VPU Design Selection .................................................................................................................. 25
7 PHASE 2 - IMPLEMENTATION OF VPU DEMONSTRATOR .......................................27
7.1 Hardware Design and Implementation ................................................................................................................27 7.1.1 Demonstrator Requirements ........................................................................................................ 27
7.1.2 VPU Demonstrator Implementation.............................................................................................. 28
7.1.3 Problems & Solutions ................................................................................................................... 35
7.1.4 VPU Demonstrator Status ............................................................................................................ 36
7.2 Short overview Algorithmic Software PYXIS......................................................................................................37
7.3 Frame software and software implementation aspects .......................................................................................38
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 4
GAIA PDHE GP-ASG-FR-0001
7.3.1 Host VPU Demonstrator GUI........................................................................................................ 39
7.3.2 Gaia-VPU Stimulator Software ..................................................................................................... 41
7.3.3 Gaia-Astro-VPU Software............................................................................................................. 45
7.4 Results from Performance Measurements ...........................................................................................................54 7.4.1 Overview on Data-Sets used........................................................................................................ 54
7.4.2 Test Conditions............................................................................................................................. 54
7.4.3 Validation of Results ..................................................................................................................... 55
7.4.4 Data-Rates for Interface VPU / PDHU.......................................................................................... 55
7.4.5 Time-Mesurements....................................................................................................................... 56
7.5 Recommendations for improvements ...................................................................................................................79 7.5.1 Software........................................................................................................................................ 79
7.5.2 Hardware – Processor board........................................................................................................ 80
8 SCHEDULE OVERVIEW OF TDA AS RUN...................................................................81
9 DELIVERABLES OF TDA..............................................................................................82
9.1 Documentation........................................................................................................................................................82
9.2 Demonstrator Harware and Software ..................................................................................................................84
10 ASSESSMENT OF PERFORMANCE RESULTS W.R.T CRITICAL TECHNOLOGY REQUIREMENTS..................................................................................................................85
11 CRITICAL TECHNOLOGY ITEMS COVERAGE........................................................86
12 PLANNING TO FLIGHT MODEL STATUS ................................................................87
13 CONCLUSION OF VPU DEMONSTRATOR TDA......................................................91
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 5
GAIA PDHE GP-ASG-FR-0001
1 DOCUMENTS
1.1 Applicable Documents
AD-1 GAIA/MMS/TN/037.97 - GAIA Concept & Technology Study, Final Report, Issue 2, 30/03/99, Annex 2
AD-2 GAIA/TADG21/2001 - GAIA Payload Data Handling Electronics, Statement of Work, Issue 1, Rev. B, 09/10/01, incl. Annex 1, Technical Requirements, modified by MoM of PDHS Negotiation Meeting 17/12/02
AD-3 GP-ASG-RS-0002, GAIA PDHS Requirements, Issue 1, 10-03-2004
AD-4 GP-ASG-RS-0003, GAIA PDHS Architectural Design, Issue 1, 24-02-2004
AD-5 GP-ASG-RS-0005, GAIA PDHS Interface Control Document, Issue 1, 02-03-2004
AD-6 GP-ASG-RS-0004, VPU Detailed Specification , Issue 1, 10-03-2004
AD-7 GP-ASG-RS-0006, VPU Software Requirements Document, Issue 1, 10-09-2004
AD-8 GP-ASG-RS-0007, PDHE Demonstrator Testbed Specification, Issue 2, 23-02-2005
AD-9 GP-ASG-SAD-0002, Astro VPU Software Architectural Des. Doc., Draft, 15-04-2005
AD-10 GP-ASG-VP-0001 Validation Procedures, Validation Procedures, Issue 1, 26-09-2005
AD-11 GP-ASG-SAD-0001,VPU Stimulator Software Design Document, 10-03-2005
AD-12 GP-ASG-UM-0002,VPU Host Design Document & GUI User Manual, 11-03-2005
AD-13 GP-ASG-VR-0001 Validation Report, Gaia VPU Validation Report, Issue 1, 26-09-2005
1.2 Reference Documents
RD-1 EF5/FR/PC/038.02 - GAIA System Level Technical Reassessment Study, Final Report, Issue 2, 27/06/02
RD-2 GAIAFPA.NT.00079.T.ASTR - GAIA CCD and Focal Plane Technology Demonstrators, Basic Principles and Main Technical Assumptions, Issue 2, 21-01-03
RD-3 GAIA PDHU Requirements Spec, TL19516 Issue 1D, 10-10-03
RD-4 GAIASYS.SP.00031.T.ASTR, PDHE - FPA Interface Requirements Document, Issue 1, Rev. 1, 13-10-2003
RD-5 GAIASYS.SP.00053.T.ASTR, PDHE - MBP/RVS Spectrometer Focal Plane Interface Requirements Document, Issue 1, Rev. 1, 17-09-2003
RD-6 MSSL/GAIA/SP/ 001.03, GAIA RVS Interface Control Document, 20-11-2003
RD-7 MSSL/GAIA/TN/005.10, GAIA RVS Data Pre-Processing Tasks, 03-09-2003
RD-8 GP-ASG-TN-0002, GDA Implementation Requirements, Issue 2, 28-01-2004
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 6
GAIA PDHE GP-ASG-FR-0001
RD-9 OBD-FC-01, Gaia_Detect description, rev. 1.4, Dec 11, 2002
RD-10 GAIA-CUO-117, Scientific requirements for the on-board processing, March 31, 2003
RD-11 GAIA-JBD-009, PDHE load assumptions: properties of the sky, 31-10-2003
RD-12 GAIA-JBD-011, Windowing and sampling for faint stars in Astro, 17-12-2003
RD-13 GEPI/GAIA-PDH/2000/DD/001.02, Architecture of Pyxis 2.0, 11-02-2005
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 7
GAIA PDHE GP-ASG-FR-0001
2 SCOPE
The present document presents the final report of the Payload Data Handling System (PDHS), sometimes also called Payload Data Handling Electronics (PDHE). The PDHE comprises the Video Processing Unit (VPU) and the Payload Data Handling Unit (PDHU). For the chapters on requirements and overall architecture both parts are covered. Detailed specifications and all breadboarding activities described herein are restricted to the VPU part. Reason for this is twofold: First of all the parties contributing to this TDA are EADS Astrium GmbH as prime contractor with the responsibility for overall requirements, architecture and all VPU related tasks and Alenia Spazio / Laben with the responsibility for the PDHU. Secondly the second TDA phase was largely decoupled between Astrium and Laben (also in time), finally leading to two final reports.
This document is organized as follows; after an overview about the original objectives of the TDA and the scope of the TDA as actually run, the activities of the two phases of the TDA are presented with a presentation of the results. Chapter 6 covers all phase 1 activities from requirements to architecture, chapter 7 the implementation of the VPU demonstrator with the related measurements performed. Included in the latter is the information on the software developed in the frame of the TDA together with a brief overview on the algorithmic software “Pyxis”, as far as needed for understanding of the real time software system developed for the demonstrator. The subsequent chapters give information on the TDA deliverables, critical technology items and the related product lines of possible product candidates, and a short overview on planning to flight model status. The document is closed by our conclusion on the TDA.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 8
GAIA PDHE GP-ASG-FR-0001
3 ACRONYMS
AOCS attitude and orbital control subsystem
ASMx ASTRO sky mapper no. x
AFx astrometric field CCD no. x
APU ASTRO processing unit = VPU0+...+VPU9
ASTRO name of astrometric instrument
BS bright star (coordinate source packet)
BSM bright star mapper
CDMS command & data management system
CDMU command & data management unit
CLK clock
DS differential signal
EOL end of life
FEE front-end electronics (of SPECTRO instrument)
FP focal plane
FPA focal plane assembly
G star magnitude
GST GAIA System Team
HRTF high-rate telemetry formatter
Hz Hertz
I/F interface
IMx (ASTRO PE) Interconnection Module number x (x=0,...,9)
Kb 1000 bits
Kib 1024 bits
LUT look-up table
Mb 1000000 bits
Mib 1048576=1024² bits
MBPx medium-band photometer no. x (x=1,..,15)
Mbps 1000000 bits per sec
MBSM medium-band sky mapper
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 9
GAIA PDHE GP-ASG-FR-0001
Mibps 1048576 bits per sec
MTC master clock
OD object data (source packet)
OF (confirmed) object feature (source packet)
PDHE payload data handling electronics
PDHU payload data handling unit
PDHS payload data handling system
PE proximity electronics
PEM proximity electronics module
PLM payload module
PFS point-spread function
Pyxis name of algorithmic software developed by the Observatoire de Paris-Meudon
REU remote electronics unit (of ASTRO instrument)
RFTU RF-transmission unit
RV RVS line (source packet)
RVS radial velocity spectrometer
RVSM RVS sky mapper
RVSMx RVS sky mapper CCD no. x (x=1,...,8) (t.b.c.)
S/C spacecraft
SBT satellite based time
SM sky mapper: can refer to either ASM or MBSM or RVSM
SP source packet
SPECTRO name of combined MBP and RVS instrument
SPF single point failure
SPU SPECTRO processing unit = VPU10+VPU11+VPU12+VPU13+VPU14+VPU15
SSMM solid state mass memory
SSR solid state recorder
SVM service module
t.b.c. to be confirmed
t.b.d. to be defined
TCA TDI counter for ASTRO
TCS TDI counter for SPECTRO
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 10
GAIA PDHE GP-ASG-FR-0001
TDA Technology Development Activity
TDI time-delayed integration
VPU video processing unit
VPU14 cold-redundant copy of VPU12
VPU15 cold-redundant copy of VPU13
WD window data (source packet)
w.r.t. with respect to
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 11
GAIA PDHE GP-ASG-FR-0001
4 OVERVIEW AND BRIEF RECALL OF ORIGINAL OBJECTIVES OF TDA
The TDA has been started with the ITT for “GAIA Payload Data Handling Electronics” issued in October 2001 (AD-2). Subject of the TDA was to analyse the requirements for the PDHE in detail and elaborate possible architecture solutions (phase 1 activities). Phase 2 subject was the implementation of the selected solutions, VPU and PDHU breadboards, in order to derive performance figures.
In general the main objectives of the TDA were
• to support the GAIA Definition Study teams (two definition studies running in parallel) for investigation and assessment of technology requirements for GAIA science data processing
• to lead to the endorsement of the selected solutions for science data processing.
The purpose of the breadboards were to consolidate „GAIAs“ most critical design issues concerning
• Power Consumption
• Mass
• External Data Interfaces
• Processing Functions
In particular the following engineering objectives have been defined for phase 1:
– "To define a payload data handling and data processing subsystem for GAIA compliant with the overall mission objectives"
– "To review, study and evaluate functions related to the low level data processing algorithms (star background estimation, star detection and discrimination, star centroiding) and related to the star windows management"
– "On the basis of a detailed assessment of the data flows and its variations, to define a payload data handling architecture. Particular attention must be dedicated to worst case conditions in terms e.g. of the number of stars to be detected and/or tracked throughout the instruments focal planes"
– “To study and establish the corresponding tradeoffs related to the definition of data collection and command interfaces”
– “To design a clock generation and distribution mechanism”
– “To define the function to be implemented in the PDHS supervisor and the corresponding interfaces”
– “To dimension the capacity of the storage unit and specify requirements which will have an impact on its internal organisation (e.g. file management support).”
– “To prepare a PDHS requirements consolidation review and to define a set of functions that should be breadboarded.”
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 12
GAIA PDHE GP-ASG-FR-0001
5 SCOPES OF TDA AS ACTUALLY RUN
The TDA was devoted to the design of an overall implementation architecture including
• the VPU´s
• the PDHU
• the interfaces with the other science data chain constituents such as the Focal Plane Assembly (FPA), the Solid State Recorder (SSR) and the High Rate Telemetry Formatter (HRTF).
Following the system partitioning into Video Processing Units (VPU´s) and Payload Data Handling Unit (PDHU) the TDA was proposed and accepted by a team built from
• EADS Astrium GmbH (TDA contractor) working on the overall requirements/architecture and the VPU´s and
• Alenia Spazio S.p.A. - Laben (subcontractor) working on the PDHU
The TDA activity has been split into two contractual phases. The first phase regrouped tasks related to
• the consolidation of requirements
• the definition of the proper architecture for the PDHS
• the development of detailed specifications for subfunctions.
The first phase running from January 2003 to spring 2004 was concluded by the PDHS Requirements Consolidation Review (April 2004). The following figure gives an overview about the structure of phase 1.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 13
GAIA PDHE GP-ASG-FR-0001
Figure 5-1: GAIA Phase 1 Overview
The second phase running from July 2004 to October 2005 (Astrium) and February 2006 (Alenia/Laben) will be finished with the implementation of VPU and PDHU demonstrator breadboards. Therefore the second phase covers the breadboarding of critical PDHS functions identified in phase 1. For the VPU, this is essentially the real-time performance of the complex GAIA algorithms for Astro functions.
Two separate breadboards are being/have been developed and tested, and will be delivered to ESA at the end of the contract:
KICK OFF
WP 1110 (A)Overall & PDHSRequirements/
Interfaces/Algorithms
WP 1120 (L)PDHU
Requirements/Interfaces
WP 1210 (A)PDHS & VPUArch./ Interf./
Clocking
WP 1220 (L)PDHU Arch./Interfaces/Clocking
WP 1310 (A)Detailed Spec.
VPU Functions
WP 1320 (L)Detailed Spec.
PDHU Functions
WP 1410 (A)PDHS Requ.
Update
WP 1420 (A)Overall & VPU
BreadboardDD&V Planning
WP 1430 (L)PDHU
BreadboardDD&V Planning
Requirements ConsolidationReview
GAIA PDHEPhase 1
DetailedSpecification
Review
KICK OFF
WP 1110 (A)Overall & PDHSRequirements/
Interfaces/Algorithms
WP 1120 (L)PDHU
Requirements/Interfaces
WP 1210 (A)PDHS & VPUArch./ Interf./
Clocking
WP 1220 (L)PDHU Arch./Interfaces/Clocking
WP 1310 (A)Detailed Spec.
VPU Functions
WP 1320 (L)Detailed Spec.
PDHU Functions
WP 1410 (A)PDHS Requ.
Update
WP 1420 (A)Overall & VPU
BreadboardDD&V Planning
WP 1430 (L)PDHU
BreadboardDD&V Planning
Requirements ConsolidationReview
GAIA PDHEPhase 1
DetailedSpecification
Review
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 14
GAIA PDHE GP-ASG-FR-0001
• VPU breadboard by Astrium
• PDHU breadboard by Alenia/Laben
The following figure gives an overview about the structure of phase 2.
Figure 5-2: GAIA Phase 2 Overview (tasks shown in dark red color were originally planned, but later on decided to be omitted)
Phase 2 KO
VPU BBdefinition,
procurement,integration
Simulator As troSW Implement.
VPU BBSimulator SW
design
VPU BB HostSW design &
coding
PDHU BB & TEdefinition,
procurement,integrat ion
BB Des ign Review
PDHU BB & TESW design
PDHU BB HWdesign
VPU Astro SWASM Proc.
VPU Astro SWAF1 Proc .
VPU Astro SWAF2-BBP5 Proc.
Simulator RVSSW Implement.
VPU RVS SWImplementation
Test Readiness Review
PDHU TestEquipment Proc.
& Integration
PDHU TE SWIm plementat ion
PDHU BB HWDevelopment
PDHU BB SWDevelopment
VPU Astro SWDebugging &Opt im ization
VPU RVS SWDebugging &Optim ization
PDHU BBIntegration,
Debugging &Optim ization
Study Logic Phase2.vsd
GAIA PDHE Phase 2 StudyLogic
BB Design Review
Test Readiness Review
Test Readiness Review
VPU BB Testing PDHU BBTesting
VPU BBFunctions
Validation &PerformanceAssessment
PDHU BBFunctions
Validation &PerformanceAssessment
Technical Review Board
PDHSDevelopment
Plan
PDHUDevelopment
Plan
Critical Items PDRFinal Presentation
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 15
GAIA PDHE GP-ASG-FR-0001
6 PHASE 1 ANALYSIS AND REQUIREMENTS
6.1 Overview Requirements
One of the driving elements for all further requirements is the GAIA Astro On-Board Data Reduction Concept (AD-1). A conventional unidirectional download of pixel data from the Focal Plane Assembly (FPA) is not feasible because of the very high data rate > 7Gbps resulting from the necessary resolution of the FPA (amount and size of CCD's). Therefore the "Windowing-Concept" has been established for the acquisition of the CCD data. The consequences of this concept are:
• Bidirectional I/F with FPA
• Intelligent real-time astronomical image detection, selection and tracking
For the implementation of this concept the architecture shown in the following functional block diagram at PDHS top level has been defined. Three types of functional interfaces are shown:
1. sequencing (green)
2. command, control, housekeeping (blue)
3. data (white)
The PDHS architecture includes the following units:
• PDHU (Payload Data Handling Unit, including mass memory SSMM)
• APU (ASTRO Processing Unit, consisting of VPU0 + ... + VPU9)
• SPU (SPECTRO Processing Unit, consisting of VPU10 + VPU11 + VPU12 + VPU13 plus cold redundant VPU14+VPU15). For clarity in this functional diagram, the corresponding redundant interfaces with the cold redundant VPU14 and VPU15 are not shown.
The second block diagram displays the rates (in Mibps) of the respective data interfaces.
Because this report deals mainly with the design and implementation of the VPU the focus will be put on this unit further on.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 16
GAIA PDHE GP-ASG-FR-0001
Figure 6-1: PDHS functional interfaces
CDMU PDHU
MBP1PEM
VPU0
D.5.0
VPU1
D.5.1
VPU9
D.5.9
VPU10
D.5
.10
D.3
.10 D
.4.10
D.10
S.1
S.3
C.1
PDHS funct IF.VSD
...
PDHSI/F ID
sequencing
cmd & ctrl & hk
Legend
ASTRO-IM0
D.3.0 D
.4.0
ASTRO-IM1
D.3.1 D
.4.1
ASTRO-IM9
D.3.9 D
.4.9
D.1
.0 D.1
.1 D.1
.9
S.2
D.1.10 D
.5.1
1
VPU11
MBP2PEM
D.3
.11 D
.4.11D
.1.11 D.5
.12
RVSMPEM
D.3
.12
D.1.1 2
D.5
.13
RVSPEM1
RVSPEM2
D.3
.14
D.6.1
D.3
.13
VPU12(VPU14)
VPU13(VPU15)
SSMM
D.1.13
S.3
S.3
S.5 S.5S.5
S.5 S.5
APU
SPU
C.2
C.2
S.4
...
D.2
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 17
GAIA PDHE GP-ASG-FR-0001
Figure 6-2: PDHS data rates
CDMU PDHU
MBP1PEM
VPU0
<20
VPU1
< 20 Mibps
VPU9
OF, W
D <20 M
ibps
VPU10
OF,
WD
< 15
Mib
ps
vide
o da
ta10
Mib
ps
progr. data7 M
ibps
SD, SC <3.6 Mbps
C.1
PDHS funct IF.VSD
...
PDHSsource packetsMibps
sequencing
cmd & ctrl & hk
Legend
ASTRO-IM0
video data 42 Mibps
prog
r. d
ata
16 M
ibps
ASTRO-IM1
42 Mibps 16
Mib
ps
ASTRO-IM9
42 Mibps 16
Mib
ps
<1 <1 M
ibps
BS
<1
Mbp
s
scan rates <<1
OF,
WD
< 15
Mib
ps
VPU11
MBP2PEM
vide
o da
ta10
Mib
ps
progr. data7 M
ibpsscan rates <<1
BS
, SC
< 0.
3 M
ibps
RVSMPEM
vide
o da
ta30
Mib
ps
scan rat es R
V<
4 M
ibps
RVSPEM1
RVSPEM2
vide
o da
ta11
Mib
ps
starx,y <1
vide
o da
ta11
Mib
ps
VPU12(VPU14)
VPU13(VPU15)
SSMM
s can rat es
APU
SPU
C.2
C.2
...
scan rates << 1
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 18
GAIA PDHE GP-ASG-FR-0001
6.2 PDHU Requirements
As mentioned in the last chapter this report deals mainly with the VPU activities of the TDA. Therefore only a short overview about the PDHU functions is given in the following – details may be found in RD-3:
• The PDHU commands and controls the complete PDHS and through it, the instruments.
• Reception of science data: 14 VPUs, 237 Mbps peak.
• SSMM for intermediate buffering and data exchange centre.
• Data are extracted from the SSMM, compressed, and returned to the SSMM
• Compressed data sent to HRTF at 3.6 Mbps. (8 hour/day)
• A SpaceWire network with routers is the communication backbone
• Dynamic memory allocation scheme prevents unnecessary movements of data
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 19
GAIA PDHE GP-ASG-FR-0001
6.3 VPU Requirements
The following general functions has been defined for the Astro/Spectro Processing Units – for details see RD-6:
• Reception of Astro and Spectro Video Data
• Object Detection, Selection and Confirmation
• Transmission of Object Window and Gating Data
• Object Data Datation and Collection
• Generation of HK and Ancillary Data
• Transmission of calculated Scan Rate to PDHU
• Transfer of Object Data to PDHU
Based on the analysis of the Astro algorithms and code (End of 2003) the following VPU Resources for one Logical VPU have been identified:
Type Value No. Remark
Processor Performance
700 MIPS - 187 MIPS Detection(1) 276 MIPS Detection(2), Confirmation, … 240 MIPS I/O Handling
Code Memory < 500 KByte - estimate based on 1 Mbyte code size for non-optimized workstation code
Data Memory 256 MByte -
Power Interface 27 V 1
Astro Interface 57,7 MBit/s 1 Spacewire
PDHU Interface 28,9 MBit/s 1 + 1 Spacewire
Synchronisation Interface
1,36 KHz 1 + 1 TDI / SBT
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 20
GAIA PDHE GP-ASG-FR-0001
6.4 Architecture of VPU
6.4.1 Overview
Based on the requirements for the VPU two possible designs have been identified:
• APU “Baseline” Unit Architecture
• APU „High-Performance“ Unit Architecture
For details see AD-4.
Both designs have some common points but differ mainly in the used processor type. The "Baseline" architecture uses a Quad Leon Processor with about 150 MIPS where the "High-Performance" architecture is based on a Power PC SCS750FX with about 1800 MIPS. Due to the performance requirements the "Baseline" design requires the implementation of some parts of the Gaia Detection Algorithm (GDA) within a FPGA. The "High-Performance" architecture should allow to implements all algorithms in S/W.
Another important difference is that the "Baseline" architecture needs one VPU for each IM interface whereas the "High-Performance" design should be able to handle two IM interfaces with one VPU.
Both architectures are described in detail on the following paragraphs.
Note that the described architectures focus on the VPU´s of the APU because
• the design and the requirements for the SPU has not been settled enough when starting this TDA
• the design of the VPU´s for the SPU is assumed to be identical with the VPU´s for the APU (except one which will be different)
Also note that the used SpaceWire bus proposed for both architectures
• has been identified to be the only bus which is powerful enough for the estimated data rates
• has been successfully used in several space projects (SpaceWire predecessor 1355)
• components are planned to be available in a reasonable time.
6.4.2 "Baseline" Unit Architecture
The following items characterize the "Baseline" architecture:
• 10 Video Processing Units (VPU)
• Direct Link to each IM
• Redundant SpaceWire I/Fs to the PDHU
• Distinct Control I/F for each VPU
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 21
GAIA PDHE GP-ASG-FR-0001
• DC/DC Converter on each VPU
• Architecture based on the Quad-LEON2 Sparc 8 Processor
o 150Mips/25MFlops, 32-bit Integer Unit., 32/64-bit FPt Unit
o EDAC / Watchdog / Real Time Clock / General Purpose Timer
o UART / Interruptcontroller / GPIO
o Clock Generator, BootPROM, SDRAM
o Power On Reset / Secondary Power Supervision
o FPGA for Control Logic, I/F Handling and Pixel Oriented Part of GDA
Figure 6-3: VPU Baseline Architecture Overview
VPU0
Astro-IF
Red
Prim. Power
AstroVPU-IF
VPU0 IF (N)IM-IF 0
VPU0 IF (R)
VPU0 Control IF (N)
DC/DC
VPU1VPU1 IF (N)
IM-IF 1VPU1 IF (R)
VPU1 Control IF (N)
DC/DC
VPU9VPU9 IF (N)
IM-IF 9VPU9 IF (R)
VPU9 Control IF (N)
DC/DC
...
Nom
VPU0 Control IF (R)
VPU1 Control IF (R)
VPU9 Control IF (R)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 22
GAIA PDHE GP-ASG-FR-0001
Figure 6-4: VPU Baseline Architecture Detailed Block Diagram
The block diagram shows clearly the main blocks of this architecture:
• Quad Leon2 CPU
• Interface Control FPGA
• Stripmap Detection FPGA
IMSpaceWire IF
Detection(1)ASM2
Detection(1)ASM1
Detection(1)AF1
RAM
DPRAMSDRAM
BootPROM
PDHUSpaceWire IF
Clock Generation
Quad LEON2CPU
SynchronizationTDI CounterSBT Counter
IntegerUnit
InterruptController
FloatingUnit Timer
MEM CTRL
EDAC
DSU
Power ControlLow VoltageGenerationPON Reset
DPRAM
DPRAM
RAM
RAM
RAM
RAM
Synchronization
Debug Support
PDHU
Astro-IM
Stripmap DetectionFPGA
Stripmap DetectionFPGA
Window DetectionFPGA
Control FPGA
RAM
DC/DC Converter
Power Control
Primary Power
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 23
GAIA PDHE GP-ASG-FR-0001
6.4.3 "High-Performance" Unit Architecture
The following items characterize the "High-Performance" architecture:
• 5 Video Processing Units (VPU), that means one VPU handles to IM interfaces
• Direct Link to each IM
• Redundant SpaceWire I/Fs to the PDHU
• Distinct Control I/F for each VPU
• DC/DC Converter on each VPU
• Proposed Architecture based on the PPC750FX Processor
o 1800Mips @ 800MHz, 32-bit Integer Unit, 32-bit FP Unit
o L1/L2 Cache (32/32KB – 512KB)
o Branch Processing Unit
o Memory Management Unit
o Clock Generator, BootPROM, SDRAM
o Power On Reset / Secondary Power Supervision
o Full GDA SW Implementation
Figure 6-5: VPU High-Performance Architecture Overview
VPU _A
Astro-IF
Red
Prim. Power
AstroVPU-IF
DC/DC
VPU _B
DC/DC
VPU _E
DC/DC
...
Nom
IM-IF 0
IM-IF 2
IM-IF 8
IM-IF 1
IM-IF 3
IM-IF 9
VPU_A IF (N)
VPU_A IF (R)
VPU_A Control IF (N)
VPU_B IF (N)
VPU_B IF (R)
VPU_B Control IF (N)
VPU_E IF (N)
VPU_E IF (R)
VPU_E Control IF (N)
VPU_A Control IF (R)
VPU_B Control IF (R)
VPU_E Control IF (R)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 24
GAIA PDHE GP-ASG-FR-0001
Figure 6-6: VPU High-Performance Architecture Detailed Block Diagram
The main blocks of this architecture are the COTS PPC board (Maxwell SCS750FX) and the separate SpaceWire I/O board with additional circuitry as e.g. DC/DC converter.
TMRProtected
PowerPC
PowerPC
PowerPC
SystemController,
MemoryController,
PCI, Timers,Interrupts,
DMA
SDRAM
FLASH
PCI-Bridge
ClockGeneration
TestInterfaces
PCI Target
SpacewireI/F
SpacewireI/F
Synchroni-zation
TDI CounterSBT Counter
SpacewireI/F
COTS Processor Board
Interface BoardPower ControlLow VoltageGenerationPON Reset
DC/DCConverter
Power Control(N+R)
Synchronization (N+R)
VPU IF (N)
VPU IF (R)
TDI-A(N+R)
TDI-A
IM (n) IF
IM (n+1) IF
Primary Power(N+R)
to A
stro
-IM
s
to P
DH
U
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 25
GAIA PDHE GP-ASG-FR-0001
6.4.4 Architecture Budget Estimation
The following budgets have been estimated for both architectures at the end of phase 1:
• baseline: 10 Astro VPU based on Leon2, Quad-Leon2
• hi-performance: 5 Astro VPU based on SCS750FX
Required Baseline
Architecture
Hi-performance Architecture
Volume [liters]
<66 63 59
Mass [kg] <50 50 46
Primary power [W]
<305 325 <311
6.4.5 VPU Design Selection
At the end of phase 1 both possible architectures have been evaluated and with respect to the demonstrator implementation in phase 2 a decision has been taken for the "High-Performance" architecture based on the COTS Maxwell SCS750 PPC board with an additional I/F board due to the following reasons:
• no processing performance risk / some margin
• no hardwiring implementation risk
• only one VPU board type
• high procurement expense compensated by elimination of development costs for
– complex FPGA or ASIC development
– computer board development & computer board OS adaptation
– reduced risk (SCS750 essentially comes off the shelf)
• vendor rated experienced and reliable
• BB very close to FM
• Implementation of GDA seemed to be not feasible with the performance of the "Baseline" architecture
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 26
GAIA PDHE GP-ASG-FR-0001
The following matrix gives an overview about the topics used for the decision concerning the demonstrator architecture.
Note: The "Single PPC 750FX Board" column contains the values for a self-developed Power PC750FX board instead of using a COTS board. This solution has not been followed up further on due to time and cost constraints. The Maxwell SCS750 board is assumed to have the double performance compared with self-developed board because of it’s processor frequency of 800 MHz (standard SCS750processsor would run with 400 MHz). This assumed performance led to the approach to implement two VPU´s on one Maxwell board.
Quad LEON-2 Single PPC750FX Board Maxwell SCS750
Detection (1) HW SW SW
Detection (2) HW / SW SW SW
Selection a.o. Functions SW SW SW
Required CPU Performance
132 - 300 MIPS 700 MIPS 700 MIPS
CPU Performance 150 MIPS 900 MIPS 1800 MIPS : 2
Performance (-) + +
Hardwiring of GDA - N/A N/A
Modularity - + +
Budgets - + +
Accomodation + + +
Radiation + - +
ESA Standards + + -
Reliability / Redundancy + + -
Availability + + +
Export License + + -
BB Development - + +
FM Development - - +
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 27
GAIA PDHE GP-ASG-FR-0001
7 PHASE 2 - IMPLEMENTATION OF VPU DEMONSTRATOR
7.1 Hardware Design and Implementation
7.1.1 Demonstrator Requirements
The following general requirements have been derived from the VPU requirements defined in phase 1 for the implementation of the VPU Demonstrator:
• Computer system separated into two parts (=two systems)
• Part one = VPU Stimulator/PDHU Simulator System:
– Development of specific application S/W
– Implementation of user I/F
– Provision of stimuli data to the target
– Acquisition of object data via SpaceWire interfaces
– Integration into cPCI system rack.
• Part two = VPU Core Target System
– Maxwell PPC SCS750 board.
– SpaceWire interfaces for stimuli reception & object data transfer
– Integrated in a separate cPCI system rack.
Derived from the data rates given in chapter 6 the VPU demonstrator has to handle the following data rates via the SpaceWire I/F:
out of VPU into VPU range of
packet sizes (net)
max. data rate
range of packet sizes
(net)
max. data rate
SpaceWire 1 (PDHU) 24 - 200 bytes
40 Mbitps small < 1 Mbitps
SpaceWire 2 (IM1) 1470 bytes 16 Mbitps 3860 bytes 42 Mbitps SpaceWire 3 (IM2) 1470 bytes 16 Mbitps 3860 bytes 42 Mbitps
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 28
GAIA PDHE GP-ASG-FR-0001
7.1.2 VPU Demonstrator Implementation
The implementation of the VPU Demonstrator features the following design highlights based on the requirements stated in the last chapter:
• Use of COTS H/W only (especially Maxwell SCS750FX PPC board and cPCI SpaceWire interfaces)
• Use of COTS operating systems (Windows XP for host, VxWorks for target)
• Use of COTS development tools (WindRiver Tornado and Borland C++ GUI Builder)
• Commanding (Setup) of VPU target S/W via TCP/IP socket link
• Transfer of stimuli and object data via 100MBit/s LAN (TCP/IP socket link) and 200MBit/s SpaceWire Link
• Two separate cPCI drawers for host and target system
• All components integrated into one 19’’ rack (9U height)
• CE certification of demonstrator rack
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 29
GAIA PDHE GP-ASG-FR-0001
The following figure gives an overview about the first implementation of the VPU demonstrator with a separate Power PC for generation of the VPU stimuli data and the acquisition of the VPU IM data.
Figure 7-1: VPU Demonstrator Overview First Design
This design was planned to perform real-time VPU target stimulation and control (within TDI cycle of 736us), but thanks to some problems with the brand-new Motorola board (see chapter "Problems & Solutions") the VPU target stimulation and control tasks have been shifted to the PC host running as a separate thread of the GUI S/W. The result is a quasi real-time stimulation with a selectable cycle
MaxwellSCS750
PPC board
MotorolaMCPN905PPC board
PC HostAdlink
cPCI6840PentiumM
Space Wire (PDHU)
Space Wire (IM2)
VPU core
VPU stimulator(PDHU simulator)
GUIStrip map datadevelopment tools
Ethernet
cPCI bus
cPCI bus
Space Wire (IM2)
Space Wire (PDHU)
Space Wire (IM1)
Space Wire (IM1)
Ethernet Board
Ethernet
Ethernet
Ethernet(Site Lan)
RS232C(Terminal)
RS232C(Terminal)
SpaceWire
Ethernet(16Port Fast ETH Switch)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 30
GAIA PDHE GP-ASG-FR-0001
time between 1ms and 10 ms. This solution allows to perform all required functions with the only restriction of increasing the run-time for the test cycles (factor 1.3 - 7). A short summary of this final design is given in the following topics:
• The additional PPC has been removed from the design. The PDHU simulator task is actually performed on the PC host as separate thread.
• This reduces the TDI cycle time to 1 ..10 ms (user selectable timer) which differs from real time 734µs. Nevertheless the 734µs cycle itself is achieved and tested, only the overall test time increases. All Astro algorithm related operations and the necessary I/O (e.g. SpaceWire DMA data transfer will be done in the 734µs cycle (if SCS750 is able to do so, see ch. 7.4 and 13), only the start of the next TDI cycle is limited to a minimum or multiple of one millisecond because of the resolution of the used Windows multi-media timer (1ms).
• From our opinion this compromise still allows evaluation and verfication of the perfomance of the MAXWELL board concerning the GAIA algorithms, the most identifiable influence on the test is the increase of the test time.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 31
GAIA PDHE GP-ASG-FR-0001
The following figure shows the final implementation of the VPU demonstrator.
Figure 7-2: VPU Demonstrator Overview Final Design
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 32
GAIA PDHE GP-ASG-FR-0001
The following tables and figures show the as-built configuration of the VPU demonstrator.
Figure 7-3: VPU Demonstrator Rack Layout
Figure 7-4: VPU Demonstrator Photograph
9HE Cabinet (Schroff comptec 10225-667) 9HE Cabinet
Front View HE Front Sectional View Rear
1 Network Hub 1 1 Network Hub 1
2 2 HE cPCI System (VPU) 1 2 2 HE cPCI System 13 Front 2 3 24 Blind Plate 1 4 Spare 1
5 1 5 16 4HE cPCI System (PDHU) 2 6 4HE cPCI System 27 (cPCI-PC, cPCI-PPC, Mass Storage) 3 7 38 Front 4 8 4
9 AC Mains with Fuse, RCD, Surge Protector, Line Filter (Schroff) 1 9 AC Mains AC Ext. 1
HE Rear View HE1 Blind Plate 12 23 2 HE cPCI System 14 Rear 25 16 4HE cPCI System 27 (cPCI-PC, cPCI-PPC, Mass Storage) 38 Rear 49 AC Mains Extention Lead (Schroff) 1
AC Mains Cable (3m)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 33
GAIA PDHE GP-ASG-FR-0001
The following components have been used for the implementation of the VPU Demonstrator:
Slot Module Description
1 Maxwell SCS750
VPU Core Target:
Maxwell SCS750 PPC board with 400/800MHz, 256MB RAM,
L1 32+32KB, L2 512KB, 2*RS232C, cPCI
OS VxWorks 5.5.1, BSP V1.1/0
2 Spare
3 Ramix CP610/1-6U
Ramix CP610/1-6U cPCI 10/100Mbit Ethernet IF
4 SpaceWire cPCI
Star-Dundee cPCI SpaceWire Board
(three links, each link max. 200MBit/s link speed, VxWorks driver)
Slot Module Description
1 Adlink cPCI6840
Host PC & PDHU Simulator:
COTS cPCI Pentium M single board PC with 1.6GHz,
1GB RAM, 3*ETH, 2*RS232, VGA 1280*1024
OS Windows XP SP2, Tornado SDE V2.2.1, Borland C++ Builder V5
2 Motorola MCPN905
COTS cPCI Motorola PPC 7457 1GHz 1.5 GB RAM board
deleted as PDHU Simulator, used for development and test
3 SpaceWire cPCI
COTS Star-Dundee cPCI SpaceWire Board
(three links, each link max. 200MBit/s link speed, XP driver)
4 Spare
5 Spare
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 34
GAIA PDHE GP-ASG-FR-0001
The overall architecture of the VPU Demonstrator is as follows.
Figure 7-5: VPU Demonstrator S/W Overview
In general the VPU Demonstrator S/W consists of two major parts on each of the computer systems:
Host-PC:
• Operating System Windows XP with drivers, development and supporting tools
• Application Host S/W which deals with commanding, data management, simulation control, VPU stimulation and interface control (TCP/IP and SpaceWire) under the control of one common GUI
Target S/W:
• Operating System VxWorks with drivers and supporting tools
• Application Target S/W which implements the VPU functions and handles the communication via the interfaces (TCP/IP and SpaceWire)
Further details about the Host S/W are given in the S/W implementation chapters of this report.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 35
GAIA PDHE GP-ASG-FR-0001
7.1.3 Problems & Solutions
Some problems had to be solved during the implementation of the VPU Demonstrator H/W. The main problems and its solutions are described in the following.
The Star-Dundee cPCI SpaceWire interface delivery was delayed by one month due to problems of one Star Dundee board supplier with its soldering process. Therefore the adaptation of the VxWorks driver had also been started with a delay.
The Star-Dundee VxWorks SpaceWire driver was only available for a Pentium M target, the porting to the Maxwell PPC target was much more complex than planned:
• Porting by ourselves was not possible without deep knowledge of the SpaceWire H/W & S/W driver philosophy and the Maxwell H/W.
• One week on-site support from Star-Dundee for driver porting has been ordered. This support was only partly successful because of remaining DMA & IRQ problems during SpaceWire transfers.
• Star-Dundee tried to solve the remaining problems via remote support by Maxwell, but the problems remain.
• Maxwell sent one extra SCS750 board to Star-Dundee so that Star-Dundee was able to perform its own test and debugging sessions with the driver in nearly the same configuration as used for the VPU Demonstrator.
• With the help of this board the final full featured VxWorks SpaceWire driver was available for us at 20.06.2005
• Due to the late availability of the driver only time for full SpaceWire integration into demonstrator S/W but not for complete performance testing remains, therefore all performance measurements have been done via TCP/IP socket link over the Ethernet I/F.
The Motorola PPC board (foreseen as real-time VPU Stimulator) came out not to be able to fulfil the requirements due to some reasons:
• The board could not act as PCI bus master for handling of PCI IRQ‘s and DMA‘s although these requirements have been discussed with the supplier. Neither the supplier nor the Motorola normal support was aware that this board has a non-transparent PCI-cPCI bridge which lead to the problem. This fact has been found out after contact with the board developer in the USA.
• Due to requirements (1GHz, 1.5GB RAM) a very new board has been selected, therefore the VxWorks support is still at Motorola and not at WindRiver. In particular this meant that not the final BSP version was available for us.
• Therefore the VPU Stimulator tasks of this board has been shifted to Pentium M XP host with the consequence of a quasi real-time stimulation (selectable 1-10ms stimulation cycle) instead of real-time TDI cycle (736us).
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 36
GAIA PDHE GP-ASG-FR-0001
During the tests we were focussing delays in VxWorks task execution which have to be explained and reduced:
• Delays resulted mainly from network I/F tasking activities
• Could be mostly eliminated by priority boosting of application S/W
• Will not be that problem without connected development environment because the VxWorks Tornado environment produces a lot of network traffic (eg. WindRiver Shell via TCP/IP, Target Server via TCP/IP, debugger via TCP/IP) which is not present when starting the VPU S/W directly from EEPRROM (no additional network traffic) or after download via VxWorks FTP boot server (network traffic only during boot).
• Remaining small delays (approx. 15us) result from IRQ handling during the measurement and have no compromising influence on the measurements.
7.1.4 VPU Demonstrator Status
The integration of all H/W and S/W parts has been successfully finished concerning the final VPU stimulator design, that means quasi real-time provision of stimuli data (1-10ms selectable stimuli rate on host) due to the implementation of the VPU stimulator as thread on the Windows XP host (see “Problems & Solutions”).
The SpaceWire driver has been successfully ported to the Maxwell SCS750 PPC board and integrated into the VPU stimulator and VPU Target S/W.
The link speed of Star-Dundee SpaceWire cPCI board on SCS750 has been tested with a loopback test under VxWorks with the latest driver version (20.06.2005). The measured transfer rate for transfers from link 1 to link 2 was 17MByte/s.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 37
GAIA PDHE GP-ASG-FR-0001
7.2 Short overview Algorithmic Software PYXIS
The Pyxis software is written by the Observatoire de Paris-Meudon/CNES/CNRS and is integrated in the Astro-VPU-Software in version 2.4. Pyxis consists of the main algorithm modules:
• Pre-calibration: is intended to provide control over the errors induced by the detectors’ defects. Hot and dead pixels, heterogeneous sensitivity, aging of the CCD etc. are smoothed out at this level to maintain the quality of input data for the on-board processing tasks – notably connectivity. At each TDI, different instances may work on whole CCD lines or on windows.
• Detection: The so-called Sky Mapper CCD´s at the entrance column of the FPA matrix are completely read out, and the resulting pixel streams received by the PDH are processed with the goal of detecting individual celestial objects. Once an object has been detected and its coordinates in the sky determined, a window around it can be defined for future readout. All CCD after the Sky Mappers are only partially read-out, namely in the windows specified around detected objects.
• Propagation: extrapolates positions of objects or windows determined in a given CCD to another one by taking into account all effects on the apparent movement of sources on the detectors.
• Selection: consists in allocating windows to detected objects for their subsequent observation (windowed read-out). Technical constraints on CCD read-out require science-driven object selection on one hand and determining an optimal positioning of windows on the other hand.
• Confirmation: This module confirms the presence of objects of interest in order to discard false detections associated to cosmic ray hits.
• Read-out command: generate the CCDs' read-out command at each TDI (sample addresses, gates, charge injection)
• Assembly: assemble read-out samples in WD packets
More detailed information about the architecture of Pyxis [RD 13] and about the integration see chapter 7.3.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 38
GAIA PDHE GP-ASG-FR-0001
7.3 Frame software and software implementation aspects
The software of the Gaia-PDHE-Demonstrator consists of three parts (orange boxes in figure 7-6):
• Astro-VPU software
• Astro-VPU-stimulator software
• Host-VPU Demonstrator GUI
Figure 7-6: Gaia-VPU-Demonstrator Overview
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 39
GAIA PDHE GP-ASG-FR-0001
7.3.1 Host VPU Demonstrator GUI
The Host-VPU Demonstrator GUI is a windows-application and runs on a Windows XP operating system. This graphical user interface (GUI) is designed by Borland C-Builder and written in C++. The detailed description is in [AD 12]. The figure below shows a screen shot of the GUI.
Figure 7-7: Host VPU Demonstrator GUI
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 40
GAIA PDHE GP-ASG-FR-0001
The Host-VPU Demonstrator GUI includes different functions for controlling and management of the Gaia VPU simulation:
• ‘Status’ -overview shows the status’ dialog page, which gives an overview about the status of the stimulator and vpu-board. It includes also information about the simulation state.
• ‘Stripmap-data’ -part includes the reading of the .fit image-files and the writing of the stripmap-input files for the stimulation S/W. For each of the 17CCDs exists in the datasets from OBSPM one fits-file with the stripmap-image.
• ‘Parameter’ component prepares the different parameter-sources for Astro-VPU-simulation:
o Pyxis parameter config-file
o Pyxis calibration-data file
o Pyxis AOCS-data file (ASCI file).
• ‘Simulation’ section includes all elements for controlling the simulation-process:
o Start/Stop-button
o Number of TDI-cycles
o TDI cycle time
o Reset and initialization buttons for stimulator and VPU
There are also located the information about the transmitted data-size during the simulation via TCP/IP or SpaceWire
• ‘Analysis’ part contains the download and saving options of simulation results.
• ‘Settings’ consists of four panels.
o ‘Data Locations’ – User can set the directory for the stripmap-, parameter and Output-
data
o ‘Logging’ – All commands and actions will be logged in a logging-file
o ‘TCP/IP-command – Settings for TCP/IP-command link to stimulator and VPU
o ‘TCP/IP-data – Settings for TCP/IP-data-link between stimulator and VPU
o ‘SpaceWire’ – Settings for the SpaceWire-link between stimulator and VPU
• ‘status monitoring’ shows the stimulator- and VPU-S/W internal status as well as status
information send via TCP/IP socket communication process. All activities will be logged in a
window in the GUI and in a logging-file. Every response will have an indication of date and
time of delivery.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 41
GAIA PDHE GP-ASG-FR-0001
7.3.2 Gaia-VPU Stimulator Software
The Gaia-VPU Stimulator Software stimulates the Gaia-Astro VPU software interfaces to the focal plan. The software is written in C++ and runs as a separate thread in the Host-VPU Demonstrator GUI. The software contains 3500 lines of code. The stimulator is designed for one VPU and a maximum of 5000 lines in AL for the stripmap-data. That implies the software needs a working-memory of 650 Mbytes. In the design document [AD 11] includes more information about the Gaia-VPU Stimulator Software.
7.3.2.1 Design and functionality
The Gaia-VPU stimulator needs for initialization for each of the 17 CCDs one stripmap-data file and the special parameter which will be provided in the ‘Stripmap-Data’- and ‘Parameter’-functions of the Host-VPU Demonstrator GUI. Figure 7-8 shows the Gaia-VPU stimulator block diagram with the data-flow during the one TDI cycle. The stimulator works during one TDI-cycle in the following typical steps:
• Wait for the next TDI-Clock signal which is generated by a multimedia timer
• Receive Programming-data from VPU via SpaceWire or TCP/IP and store these in the shared
memory. The shared memory is designed as a FiFo-buffer and simulates the delay-times
between VPU and FPA. (block diagram 7-8 on the very right side)
• Split the Programming-data and extract the information for each CCD
(block diagram 7-8 on the right side next to the programming buffer)
• Compute the video-data for each CCD in an assembly step depends on the programming-data
(block diagram 7-8 the big gray box in the middle)
Therefore it will be used for each CCD a separate StripMap-image
(block diagram 7-8 at the botton the small images of the strimap-images)
• packetize the ASM-StripMap-line and the window-samples form every AF- and BBP-CCD to
the Video-data dataset and store the Video-data in shared memory which is designed as a
double buffer (block diagram 7-8 on the left side next to the Video-buffer)
• Transmit the Video-data to the VPU via SpaceWire or TCP/IP
(block diagram 7-8 on the very left side)
• prepare the stimulator for the next TDI-cycle
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 42
GAIA PDHE GP-ASG-FR-0001
Figure 7-8: Gaia Stimulator design
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 43
GAIA PDHE GP-ASG-FR-0001
7.3.2.2 Stripmap-Data and looping principle
The Stripmap-Data is provided by OBSPM in the different Data Sets. For each of the 17 CCD there exists one separate Stripmap. For ASM1 and ASM2 the StripMap are binned by 2 in AC and AL. A typical stripmap has an integration time of 3,3s or a whole CCD-filed or 4500 lines (2250 lines for ASM). That implies the Data-Set consists of 17 Stripmap images which shows the same slice of the sky in different times or ages concerning to the CCDs and there location on the FP. The first “read-line” is known by the Data-Set parameter and will be used for synchronisation. The next figure shows the Data-Set concerning to the CCD and TDI.
Figure 7-9: Gaia Stimulator StripMap-Data-Set
For the simulation this means that the modules from the Gaia-VPU software will be working one after the other, e.g.:
• during the ASM-Stripmap - detection runs
• during the AF1 Stripmap - confirmation runs but not any longer detection because there is no input for ASM
Hence for a realistic performance measurement where all modules works in parallel the VPU needs stripmap-input of all CCDs. Therefore the Gaia-VPU stimulator loopes the stripmaps for each CCD after the first pass. So after around 80.000 TDI-cycles, where BBP4 is located, the stimulator provides for all CCDs stripmap-data and the first time all modules works in parallel. Figure 7-10 shows the used “looping principle”. For the performance measurements the interesting times are of course those, where all modules work together.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 44
GAIA PDHE GP-ASG-FR-0001
Figure 7-10: Gaia Stimulator stripmap looping principle
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 45
GAIA PDHE GP-ASG-FR-0001
7.3.3 Gaia-Astro-VPU Software
The Astro-VPU Software runs on the VPU and includes all the algorithmic for the detection of objects of interest and their observation during the traversal of the focal plane. The algorithmic is provided by OBSPM as software called Pyxis. The detailed description of the Astro-VPU Software is in [AD 9].
7.3.3.1 Overview
Figure 7-11 shows the Astro-VPU Software context diagram. The communication is realized via TCP/IP-interfaces to the Host-VPU Demonstrator GUI and via separate SpaceWire-links or TCP/IP-links to the Gaia-VPU Stimulator. Furthermore the Astro-VPU Software runs on the operating-system VxWorks and uses some system-functions e.g. for task-synchronisation.
Figure 7-11: Astro-VPU-Software context diagram
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 46
GAIA PDHE GP-ASG-FR-0001
7.3.3.2 Pyxis Integration
In the Astro-VPU Software Pyxis version 2. 4 is integrated finally. Pyxis is provided by OBSPM and designed as a stand-alone application software with consideration for the integration in the Gaia-VPU software. Pyxis comprises a number of modules, which are used by Gaia-VPU software: Detection; Selection; Confirmation; Propagation; Assembly; Read-Out.
Each module consists of one or more C-source files. Pyxis uses the same Data-Sets like the Gaia-VPU Stimulator:
• Stripmap-Data for each of the 17 CCDs
• Parameter - file
• Calibration - file
• AOCS - file
Each module will be compiled to different objects the so called instances of the modules.
Figure 7-12: Typical Pyxis module
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 47
GAIA PDHE GP-ASG-FR-0001
Figure 7-12 shows a typical Pyxis module and the different functions:
• Reading of the argument line
• Initialization of all parameters
• Initialization of all memories, that includes the dynamical allocation of the most memories by using the parameter for sizes
• Main loop:
o “Update_push” function which fetch the inputs in every TDI-cycle
o “Core” function which includes the algorithmic of the module
o “Update_pull” function which stores the output in every TDI-cycle
• “De-Initialization” function which frees the allocated memories
A Pyxis-module uses a global parameter structure and different global memory structures.
The Gaia-VPU software can use only the Core-function from Pyxis but therefore the original source code will be used! All the initialization and the other function have to replace in VPU software.
The Pyxis integration in the Gaia-VPU software can be explained in the following steps:
1. Create instances of each Pyxis module:
• About make-file and Pre-processor-flags
• Several objects from one C-source file - one object file for each C-source for each instance
• Modules: Instances:
precalibration: apc1, apc2, apc3
detection: ad1, ad2
selection: as1, as2, as3, as4
propagation: ap1, ap2, ap3, ap4, ap5 - ap16
confirmation: ac
2. Create parameter structure for each Pyxis instance:
• Global structure for each instance ( 26 parameter structures)
• Function for reading parameter from the Pyxis parameter file
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 48
GAIA PDHE GP-ASG-FR-0001
3. Create memory structures for each instance which will be internal needed by Pyxis:
• all dynamical allocated memories in Pyxis replaced by statical allocations:
1. Analysis of the init_1() functions in the C-source files
2. Replace the sizes of the memories which are given in Pyxis by parameter-file to statical #defines
3. Recreate the memory structures ( partly complex structures and pointer usage by dynamical allocations )
4. Join the interface structures of Pyxis modules:
• Create the global memories (SCLs, FiFo)
• Initialization of the Pyxis interface structures
5. Initialization of the scheduling:
• Initialization of internal and global memories
• Initialization of the offsets for calling the Pyxis core-functions (All Pyxis instances are called in each TDI-cycle but with a different time context due to the focal plan)
6. Create new Instances for Read-Out:
• Replace Pyxis Read-Out instances (ar1, ar2, ar3 – ar15) by „Compile Programming Data“ function
• Design and Coding of the functions
7. Create new Instances for Assembly:
• Replace Pyxis Assembly instances (aa1, aa2, aa3 – aa15) by the own „Assembly“ function
• Design and Coding of the functions
The two new modules Assembly and Compile Programming Data consists each of around 800 lines of code.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 49
GAIA PDHE GP-ASG-FR-0001
7.3.3.3 VxWorks Task-Level Software
The following figure contains an overview of the task-level. The dotted arrows show the communication directions between the task and the systems. The major tasks are:
• AstroVPU – includes all algorithmic function
• VPUControl – controls and manages the whole software
The gray tasks are for the interface-handling and the dotted task present the system task of the operating system VxWorks.
Figure 7-13: GAIA-Astro-VPU task overview
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 50
GAIA PDHE GP-ASG-FR-0001
7.3.3.4 Gaia-VPU Frame Software Design
The Gaia-VPU Frame Software includes Pyxis in version 2.4. All used memory by Pyxis are replaced without exceptions by static allocated memories. The frame software consists of 10500 lines of code without Pyxis. The next figure shows the design of the Gaia-VPU software.
Figure 7-14: GAIA-Astro-VPU overview
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 51
GAIA PDHE GP-ASG-FR-0001
The Gaia-VPU software consists of three major functions:
• Initializations – initialization of all parameter and internal memories used by Pyxis
• Simulation loop – includes all Core-functions
• Get results – write the result-data of time-measurements and validation
Furthermore the instances of Pyxis need some global memory-structures for communication among each other and passing the objects and windows. These memories are FIFO´s and Static Chained List (SCL)-structures. With the SCLs it is possible to store a different number of objects or windows per line without a dynamical allocation. In addition there are function for searching of objects/windows in the SCL-structure and it is also possible to arrange objects/windows in the SCL in the right order.
A typical TDI-cycle includes the following steps:
• Receive the Video-Data for each CCD and store in the shared memory designed as double buffer
• Step through the six main routines (gray S/W modules in the simulation loop box) These routines include the different Pyxis instances which are shown in detail in figure 7-15
• Store the results – Science-Data (OF- and WD-packets) in the Science buffer.
• Transmit the Programming-Data to the FPA (Gaia-VPU stimulator)
Figure 7-15 presents the six major function in detail. All the instances shown have to be called in each TDI-cycle.The green boxes are the different Pyxis instances in total 26 instances and the blue boxes are the coded assembly and compile programming data functions for each 15 instances.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 52
GAIA PDHE GP-ASG-FR-0001
Figure 7-15: GAIA-Astro-VPU Core-functions
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 53
GAIA PDHE GP-ASG-FR-0001
7.3.3.5 Memory budget
All used memory by the Gaia-VPU-Software is statically allocated and has a fixed size. For the operating system VxWorks and drivers are:
• � 8 MByte allocated.
The memory budget for the Gaia-VPU-Software with the Pyxis version 2.4 on the Maxwell board:
• � 125MB
The same compiled source code needs on a commercial PowerPC board from Motorola (technical information in chapter 7.4.5.9).
• � 75MB
In comparison Pyxis 2.3 needs:
• �140MB and �85MB.
The considerable differences between Maxwell and Motorola are caused by the following reasons (explanation given by WindRiver):
• Different memory alignment
• Different handling of global variables, so called “Tentative Definitions”. That implies the size of the variables is determined during the download of the code to the hardware and depends on the board-support-package of the VxWorks-Kernel.
The analysis of the Gaia-VPU-Software shows that the software includes a lot of global variables and “Tentative Definitions”. To avoid these definitions the global variables have to cleared and removed but this is presently not possible with the current Pyxis version. That implies the above mentioned reasons are not confirmed yet by test but very likely.
The normal memory budget for the Gaia-VPU software is estimated to be :
• � 80MB.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 54
GAIA PDHE GP-ASG-FR-0001
7.4 Results from Performance Measurements
7.4.1 Overview on Data-Sets used
For the following time measurements the DataSets as provided by OBSPM were used:
• Design maximum (Requirement) - L54b0: with - 609000 (fov1) + 181000 (fov2) sources/deg², G<=20 and 8 cosmic hits /cm²*s
• galactic plane - L74b0: with 195000 (fov1) + 8700 (fov2) sources/deg², G<=20 and 8 cosmic hits /cm²*s
• system case average sky density - L74b15: with 22500 (fov1) + 8700 (fov2) sources/deg², G<=20 and 8 cosmic hits /cm²*s
• maximum case - Baade Window: with 3.31 Million (fov1) + 8700 (fov2) sources/deg², G<=20 and 8 cosmic hits /cm²*s
• special case vbright-mag2: with 26600 (fov1) + 9600 (fov2) sources/deg², G<=20 and 8 cosmic hits cm²*s
7.4.2 Test Conditions
The measurements were made with the following tools:
• VxWorks system-function - which is using an internal PowerPC-Counter, the resolution of these counter is 0.08us
• WindView: a service tool from WindRiver is used for measurement and test in the task-level of VxWorks and memory analysis
The terms applied during the measurements are:
• All measurements are done for one VPU on the processor board
• Calculation of the algorithms with a very high prioritized task to decrease the influence of VxWorks
• Sequential time-measurement: That implies the times are measured without Data-Transfers. The Data-Transfers in the real case should be work with a DMA-transfer via Space-Wire. These DMA transfers of the data are working and tested functionally in the demonstrator. The required time for the DMA management should be very short in comparison to the time which needed by the algorithm.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 55
GAIA PDHE GP-ASG-FR-0001
7.4.3 Validation of Results
Entire focal plane processing has been verified via examination of the content of interfaces (mainly LUT0 and SCLs). All results (objects and windows) are validated by comparison with original Pyxis results performed by OBSPM. For more details see [AD-13] “Validation Report”.
The analysis of these results shows that a One to One correspondence of results with Pyxis-Algorithm is possible and confirmed!
7.4.4 Data-Rates for Interface VPU / PDHU
The Science-data interface between PDHU and VPU consists of OF-packets and WD-packets. An OF-packet includes the object features and the WD-packets includes the collected window samples from each CCD. (Detailed information in [AD-13] “Validation Report”)
The following data-rates arise from demonstrator measurements:
• L74b15 (system case average sky density) : 0,3 MByte/s
• L74b0 (galactic plane): 1,3 MByte/s
• L54b0 (design maximum): 5,4 MByte/s
• Baade Window (maximum case): 7,3 MByte/s
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 56
GAIA PDHE GP-ASG-FR-0001
7.4.5 Time-Measurements
7.4.5.1 Overview – View about 90000 TDI
For passing the entire focal plane an object needs about �83500TDIs. The following diagram shows an view about 90000 TDI´s and the explained effect from chapter 7.3.2.2, that the input stripmaps for each CCD are received with offset of ca. 4900 TDI´s, is well visible.
Figure 7-16: View about 90000TDIs for l54b0
Stri
pmap
: O
nly
AS
M1
inst
ance
s:
apc
1,ad
1, a
p1 S
tripm
ap:
+ A
SM
2 in
stan
ces:
+
apc
2, a
d2, a
p2
Stri
pmap
: +
AF1
-Dat
a in
stan
ces:
+
as1
, ac,
as2
, ap3
Stri
pmap
: +
AFn
-Dat
a in
stan
ces:
+
ar, a
p, a
a
Stri
pmap
: +
AF1
1-D
ata
inst
ance
s:
+ a
s3, a
p12,
ar1
1,aa
11
Stri
pmap
: +
BB
P1-
Dat
a in
stan
ces:
+
as4
, ap1
3,ar
12,a
a12
Stri
pmap
: +
BB
Pn-
Dat
a in
stan
ces:
+
ar,
ap,
aa
All
inst
ance
s
are
wor
king
in
para
llel!
Non
Per
iodi
cal P
eaks
P
erio
dica
l Pea
ks
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 57
GAIA PDHE GP-ASG-FR-0001
7.4.5.2 Single modules with l54b0
a) Pre-calibration - Pixel-based (l54b0)
Figure 7-17: Pre-calibration APC1 for l54b0
Figure 7-18: Pre-calibration APC1 100TDIs for l54b0
• Average: 8,8% = 65us (Required TDI cycle-time:736us = 100%) (average is computed even when apc1 is not running)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 58
GAIA PDHE GP-ASG-FR-0001
b) Detection - Pixel-based (l54b0)
Figure 7-19: Detection AD1 pixel-based for l54b0
Figure 7-20: Detection AD1 pixel-based 300 TDIs for l54b0
� Average: 16,9% = 120,5us (Required TDI cycle-time 736us = 100%) (average is computed even when ad1 is not running)
The cause of the peaks in figure 7-20 (red cycle) are the background computation every 64 TDI-cycles.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 59
GAIA PDHE GP-ASG-FR-0001
c) Detection - Object-based (l54b0)
Figure 7-21: Detection AD1 object-based for l54b0
Figure 7-22: Detection AD1 object-based 500 TDIs for l54b0
� Average: 4% = 29us (Required TDI cycle-time 736us = 100%) (average is computed even when ad1 is not running)
The diagrams show that the object-based detection in base don’t need much time, but if there are objects than the computation time increases and we get some peaks if there are high number of objects. The very high peak observed is caused by the computation of a bright star.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 60
GAIA PDHE GP-ASG-FR-0001
d) Propagation - Object-based (l54b0)
Figure 7-23: Propagation AP1 for l54b0
Figure 7-24: Propagation AP12 for l54b0
� Average AP1:�0,75% = 5,5us (Required TDI cycle-time 736us = 100%) (average is computed even when ap2 is not running)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 61
GAIA PDHE GP-ASG-FR-0001
e) Pre-calibration – window oriented - Object-based (l54b0)
Figure 7-25: Pre-calibration AP12 for l54b0
� Average AP1:�0,9% = 7us (Required TDI cycle-time 736us = 100%) (average is computed even when ap2 is not running)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 62
GAIA PDHE GP-ASG-FR-0001
f) Selection - Object-based (l54b0)
Figure 7-26: Selection AS1 for l54b0
� Average 10% = 70us (Required TDI cycle-time 736us = 100%)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 63
GAIA PDHE GP-ASG-FR-0001
g) Confirmation - Object- and pixel-based (l54b0)
Figure 7-27: Confirmation AC for l54b0
� Average 12% = 84us (Required TDI cycle-time 736us = 100%)
The confirmation module works only if it gets objects and that is the reason for the values around zero. The one high peak in the diagram above remains unexplained presently.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 64
GAIA PDHE GP-ASG-FR-0001
h) Assembly - Object-based (l54b0)
Figure 7-28: Assembly AA1 for l54b0
Figure 7-29: Assembly AA10 for l54b0
� Average: AA1 3% = 20us (Required TDI cycle-time 736us = 100%)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 65
GAIA PDHE GP-ASG-FR-0001
j) Compile Programming Data - Object-based (l54b0)
Figure 7-30: Compile Programming Data AR1 for l54b0
Figure 7-31: Compile Programming Data AR1 for l54b0
� Average: AR1 1,2% = 8us (Required TDI cycle-time 736us = 100%)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 66
GAIA PDHE GP-ASG-FR-0001
7.4.5.3 All modules at the same time with l54b0
Figure 7-32: All modules for l54b0
Figure 7-33: All modules 400 TDI´s for l54b0
� Average: 220% = 1620us (Required TDI cycle-time 736us = 100%)
The peaks in the diagram are a summary of the peaks which depend on the different instances e.g. objects based detection.
All modules at the same time
0,00%
500,00%
1000,00%
1500,00%
2000,00%
2500,00%
3000,00%
85000 86000 87000 88000 89000 90000
TDI-Number
time
in %
TDI
0,00%
100,00%
200,00%
300,00%
400,00%
500,00%
600,00%
700,00%
88000 88050 88100 88150 88200 88250 88300 88350 88400
TDI-Number
time
in %
TDI
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 67
GAIA PDHE GP-ASG-FR-0001
7.4.5.4 Analysis of the module times
All times for the different instances were measured in two different cases:
• Case 1 – The input stripmap-data will be not looped by the stimulator like figure 7-9 shows. That implies not all instances work at the same time during the measurements, only the instances which have some input. (For some instances means that they work in the same way like Pyxis)
• Case 2 – The stimulator works with looping principle and the input stripmap data looks like in figure 7-10. That implies all module works in the last TDI´s after about 84000 TDI-cycles at the same time like a realistic situation and measurements will be done there
Instances times in case 1 times in case 2 difference
in us In %TDI in us In %TDI
APC1 65 9% 93 13% 30%
AD1 pix. 121 16% 179 24% 32%
AD1 obj. 29 4% 54 7% 46%
AP12 5 1% 7 1% 29%
AP1 6 1% 8 1% 25%
APC3 7 1% 13 2% 46%
AS1 70 10% 122 17% 43%
AS2 56 8% 96 13% 42%
AS3 86 12% 135 18% 36%
AS4 106 14% 117 16% 9%
AC 84 11% 131 18% 36%
AA1 20 3% 21 3% 5%
AR1 8 1% 15 2% 47%
average: ~30%
Table 7-1 Comparison of instance times for each module
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 68
GAIA PDHE GP-ASG-FR-0001
The table before shows that the instances in case 2 influence each other and the time increase in average amounts to 30%.
Some reasons for the time increasing in case 2:
• Bad use of caches for a single module
• Intense use of the global memories (SCL)
• Number of objects increase by some border-effects
The most time will be lost for the first point. It is really important from where the processor gets the input-data, from L1-Cache, L2-Cache or RAM, the L1 is the fastest and the RAM the slowest e.g. APC1 ‘Pre-Calibration’ for ASM1 raw data:
The Pre-Calibration gets in any TDI-cycle 983 raw pixel (x) from the ASM-CCD and realizes in the core a simply function: Ax + B. In case 1 it is possible to hold all the values for (A) and (B) in the processor cache about several TDI-cycles and the RAM accesses are minimized. In case 2 all module use in one TDI-cycle the same cache and the values for (A) and (B) for the Pre-Calibration will be possibly overwritten by another module. In the next TDI-cycle the processor has to access to the slow RAM for the (A) and (B) values. This is one possible reason for the 30% time increasing.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 69
GAIA PDHE GP-ASG-FR-0001
7.4.5.5 Analysis of different Data-Sets
This chapter includes the comparison of the different Data-Sets (see chapter 7.4.1). Table 7-2 shows the number of detected objects during 3,3s integration time, 4500 TDIs or a whole CCD.
Data-Set Sky density Number of objects
per 4500 TDIs
empty 0 (fov1) + 0 (fov2) sources/deg² + 0
cosmic hits /cm²*s 0
l74b15 22500 (fov1) + 8700(fov2)
sources/deg² + 8 cosmic hits /cm²*s 200
l74b0 195000 (fov1) + 8700 (fov2)
sources/deg² + 8 cosmic hits /cm²*s 925
l54b0 609000 (fov1) + 181000 (fov2)
sources/deg² + 8 cosmic hits /cm²*s 3650
baade 3.31 Million (fov1) + 8700 (fov2)
sources/deg² + 8 cosmic hits /cm²*s 4800
Table 7-2: Number of detected objects per 4500 TDI´s
The [AD-13] “Validation Report” includes some more diagrams about the different Data Sets.
a) Pixel-based functions
Figure 7-34: Comparison of the pixel-based functions
The pixel-based pre-calibration are independent of the Data-Set. The pixel-based detection depends slightly on the number, but more on the kind of objects (e.g. bright star) in the Data-Sets.
pixel-based functions
0,00%2,00%4,00%6,00%8,00%
10,00%12,00%14,00%16,00%18,00%
empty l74b15 l74b0 l54b0 baade
time
in %
TDI
precalibration (apc1)detection pixel-based (ad1)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 70
GAIA PDHE GP-ASG-FR-0001
b) Object-based functions
Figure 7-35: Comparison of the object-based functions
All object-based function need more time if the number of objects increase. Confirmation is in the diagram above a mix of pixel- and object-based functions.
c) Summary
Figure 7-36: Comparison of computation time of the different Data-Sets
object-based functions
0,00%2,00%4,00%6,00%8,00%
10,00%12,00%14,00%16,00%18,00%20,00%
empty l74b15 l74b0 l54b0 baade
time
in %
TDI
detection objects based(ad1)propagation (ap1)
selection (as1)
confirmation (pixel- and obj.-based)assembly (aa1)
comp. progr. data (ar1)
0,00%
50,00%
100,00%
150,00%
200,00%
250,00%
300,00%
350,00%
empty l74b15 l74b0 l54b0 baade
tim
e in
%T
DI
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 71
GAIA PDHE GP-ASG-FR-0001
Figure 7-37: Context number of detected objects and computation time
The two diagrams above show an almost linear increasing of the computation time, with the offset of the “Empty” case of 50%, if the number of detected objects rises. More information about the “Empty” case is described in chapter 7.4.5.7.
Module empty sky time in us
l74b15 time in us
l74b0 time in us
l54b0 time in us
baade time in us
Precalibration (apc1) 60 72 76 93 111 Detection pixel-based (ad1) 80 119 131 179 284 Detection object-based (ad1) 8 11 14 54 137 Precalibration (apc3) 0 3 5 13 18 Propagation (ap1) 0 2 5 8 14 Selection (as1) 0 18 40 122 154 Confirmation 0 13 46 131 217 Assembly (aa1) 2 4 9 21 38 Comp. Progr. Data (ar1) 4 9 11 15 28
Total (measured by an extra test!) ~380 ~581 ~806 ~1611 ~2243 Standarddeviation 202 301 265 618 2317
Table 7-3: Summary Comparison computation times of the different Data-Sets
To make sure that all module of the algorithm work together at the same time all the times in table 7-3 are measured between 85000 and 90000 TDI-cycles.
0,00%
50,00%
100,00%
150,00%
200,00%
250,00%
300,00%
350,00%
0 1000 2000 3000 4000 5000 6000
Number of detected objects per 4500 TDIs
time
in %
TDI
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 72
GAIA PDHE GP-ASG-FR-0001
The required TDI-cycle time is 736us. For the system case with an average sky density, the l74b15 field, the total time for one TDI-cycle in average under the required time. But for the required design value, the l54b0 filed, the TDI computation time is in average more than a factor by two. Interesting is that the scientific processing (detection, selection, propagation, confirmation) needs only the half of the whole computation time in the l54b0 field, the rest of the time needs Pre-calibration and the interface-handling routines “Assembly” and “Comp. Progr. Data”.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 73
GAIA PDHE GP-ASG-FR-0001
7.4.5.6 Special case – bright star
Figure 7-38: Bright star AD1 pixel based
Figure 7-39: Bright star AD1 objected based
Figure 7-40: Bright star AS1
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 74
GAIA PDHE GP-ASG-FR-0001
7.4.5.7 “Empty” case
Figure 7-41: “Empty” case, no signal on the sky for l54b0
Table 7-4 Times for “Empty” cases with different processors
board processors time in us %TDI
Maxwell 400 Mhz 471 64%
Maxwell 800 Mhz 380 51%
Motorola 1000 Mhz 115 16%
"Empty" case, no signal on the sky
10,00%
100,00%
1000,00%
5000 5100 5200 5300 5400 5500 5600 5700 5800 5900 6000
TDI-Number
time
in %
TDI
Motorola Maxwell 800 Mhz Maxwell 400 Mhz
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 75
GAIA PDHE GP-ASG-FR-0001
Module time in us
Precalibration apc1 and apc2 120
Detection pixel-based 160
Detection object-based 8
Propagation (16x) 0
Selection 0
Confirmation 0
Assembly (15x) 30
Comp. Progr. Data (15x) 60
Total ~380
Table 7-5 Times for some inctances in the“Empty” for l54b0
The “Empty” case shows that for the Maxwell (800Mhz) board half of the TDI will be needed by a sky without any signals. The peaks in the diagram by 200%TDI are the background computation in the pixel-based detection every 32 TDI-cycles. The comparable Motorola board needs 16% of the TDI cycle. This low time results from different technical values (described in chapter 7.4.5.9).
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 76
GAIA PDHE GP-ASG-FR-0001
7.4.5.8 Analysis of different processor-speeds
Figure 7-42: Comparison processor speeds with Cache enabled
Instance Maxwell
without cache time in us
Maxwell 400 Mhz
time in us
Maxwell 800 Mhz
time in us
Motorola 1000 Mhz time in us
Precalibration (apc1) 1273 62 65 13
Detection pixel-based (ad1) 2727 152 120 52
Detection object-based (ad1) 637 41 29 16
Precalibration (apc3) 184 8 7 3
Propagation (ap1) 31 7 5 2
Selection (as1) 864 90 70 30
Confirmation 1458 107 106 34
Assembly (aa1) 443 28 20 7
Comp. Progr. Data (ar1) 217 11 8 5
Total (not sum of modules above, it is measured by an extra test!) 18820 1870 1611 420
Table 7-6: Comparison times for instances on different processors for l54b0 with partly cache disabled
l54b0
30%
80%
130%
180%
230%
280%
tim
e in
%T
DI
l54b0 255% 243% 237% 233% 230% 144% 57%
Maxw ell 400Mhz
Maxw ell 500Mhz
Maxw ell 600Mhz
Maxw ell 700Mhz
Maxw ell 800Mhz
Motorola 1000Mhz
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 77
GAIA PDHE GP-ASG-FR-0001
The diagram and the table before show the test results with different processor speed settings, between 400 and 800 Mhz, of the Maxwell board. The values of the execution times in the diagram are unique in non-linear context, the double processor speed doesn’t effect a half of the execution time. By the increase of the processor speed of the Maxwell board the algorithm will only slightly faster and achieves a saturation of the maximum possible time. This indicates that the processor have to wait the most time for data from the memory. The additional comparable test with the Motorola PowerPC board with 1000 Mhz processor speed makes clear that the Maxwell board makes more accesses to the RAM and has a slower bus connection between processor and RAM. The following list includes some of the reasons why the Motorola board (details chapter 7.4.5.9) are faster in general:
• modern processor architecture
• additional L3-cache
• faster bus speed between RAM and processor (133 Mhz instead of 50 Mhz)
If the L3-Cache of the Motorola board is disabled (test results in the next chapter) the ratio between Motorola and Maxwell Bus speeds ~2,66 and between the execution times ~2,52 are similar. This testifies the slow bus speed is the most important disadvantage of the Maxwell board.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 78
GAIA PDHE GP-ASG-FR-0001
7.4.5.9 Additional Motorola Board Tests
An additional PowerPC board from Motorola in the demonstrator was tested with the same VPU-Gaia-Algorithm. For this time-measurements test the maximum design case l54b0 was used.
Some basic information about the PowerPC-Board:
o Motorola MCPN905
o Single MPC7457 Processor
o Core Frequency to 1.0 GHz
o Bus Clock Frequency of 133 MHz
o Integrated L1 and L2 cache
o 1MB DDR back side L3 Cache @ 266 MHz
o Up to 1.5GB of DDR266 (133 MHz) SDRAM onboard memory
The following test was made on the Motorola board:
Table 7-7 Times for additional Motorola board tests
Figure 7-43: Motorola Board tests
test time in us %TDI
Motorola board - 1Ghz 420 58%
Motorola board - 1Ghz, without L3-Cache 640 87%
Motorola board - 1Ghz, without L3- and L2-Cache 1320 180%
30,00%
50,00%
70,00%
90,00%
110,00%
130,00%
150,00%
170,00%
190,00%
tim
e in
%T
DI
Reihe1 58,00% 87,00% 180,00%
1 Ghz Without L3 Without L3 and L2
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 79
GAIA PDHE GP-ASG-FR-0001
7.5 Recommendations for improvements
7.5.1 Software
7.5.1.1 Data structures
Pyxis includes a large number of complex data structures with a high use of C-pointers e.g. SCL-structures. One way to improve processing performance is to simplify these structures and use simple indices instead of pointers.
The most multi-dimensional data arrays work with a “pointer” overhead. In Pyxis all of these arrays are allocated dynamically and the Astro-VPU software has to be replaced the dynamical allocation without loss of the functionality.
The global parameter-structures for each instance include also a number of variables which are only used by the original Pyxis and can be removed in the Astro-VPU software.
7.5.1.2 Algorithm optimization
The current Gaia VPU software could be optimised in two points of views:
• Complete system – e.g. The Pyxis integration is done by instance for instance. In the Astro-VPU Software each of these instances work with call of the core functions. In view of one software system it is possible to reduce the function calls for example in the propagation module to merge all of the propagation- instances into one step.
• Single Module – The single modules could be possibly optimised. Thereby the algorithmic of the Gaia VPU Software consist of the following parts:
o Pre-Calibration: 6%
o Detection: 27%
o Selection: 25%
o Confirmation: 8%
o Propagation: 5%
o Assembly: 18%
o Compile Progr.Data: 11%
(The values are for the maximum design case and average values which consist of the different instances in Gaia VPU software of the same module! For other test data these percentages vary.)
The two modules for data formatting of the Gaia-VPU Software the “compile programming data” and “assembly” module need almost 30% of the whole computation time in l54b0. That implies an optimization of these modules promise to be very effective. On the conditions:
• Fixed number and size of windows per line
• Simple window collision rules
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 80
GAIA PDHE GP-ASG-FR-0001
It is possible to replace the current used chains with tables and simplify the functions.
7.5.1.3 Cache use
Chapter 7.4.5.8 shows the essential bottleneck is the 50 MHz bus speed between CPU and RAM on the Maxwell SCS750 board. Also the results of chapter 7.4.5.4 confirm the importance of the cache for optimisation of the computing time of the Gaia VPU Algorithm.
There are two point of views for the optimum performance:
• Direct optimisation of each function in the single modules
• Optimisation has to be considered in context with overall system (chapter 7.4.5.4)
The aware optimisation of code for the optimum cache use is very complex and expensive and should be the last option in the optimisation of the software.
7.5.2 Hardware – Processor board
For the required TDI cycle time of 736us and the current version of the Gaia VPU software a CPU-board like the tested Motorola PowerPC board without L3-cache is sufficient but only for one VPU and without margin. The RAM should be enough with 256Mbyte.
The Maxwell board is built with components which could use for flight hardware. That implies a reduction of performance particularly the bus connection between CPU and memory. The necessary FPGA for the memory controller is not able to work with the full bus speed of 133 MHz. To increase the performance of the CPU board this bus speed and the L1- and L2-cache size should be maximized.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 81
GAIA PDHE GP-ASG-FR-0001
8 SCHEDULE OVERVIEW OF TDA AS RUN
Figure 8-1 shows a Milestone chart of the TDA from Kick-Off in February 2003 to the planned finalisation early 2006.
Figure 8-1: Milestone Chart of the GAIA PDHE TDA
Important milestones during phase 1 have been the Requirements Consolidation Review (PM2) and the Phase 2 Preparation Meeting, where together with the Agency important decisions have been taken on implementation choices for phase 2.
During phase 2 the first important meeting was PM3, where the further procedure for the VPU demonstrator implementation was consolidated and Laben presented its concept for the PDHU demonstrator, which later on was accepted by the Agency, leading to a Phase 2 Laben Kick-Off in the second half of February 2005. PM6 being the TRR for the VPU and the results presentation in July 2005 for the potential GAIA primes at ESTEC have been further highlighted meetings.
Additionally several working meetings with OBSPM have been performed at Astrium premises during the first half of 2005, which had been arranged to get support from the makers of Pyxis for integration of their software into the VPU real time software system.
ID Vorgangsname
1 GAIA PDHE Phase 1 and 2
2 Kick Of f Phase 1
3 PM1
4 PM2
5 Phase 2 Preparation
6 PM3
7 PM4
8 Kick Of f Laben Phase 2
9 PM5 at Astrium premises
10 PM6 VPU TRR
11 GAIA Project Presentation
12 TRB (if requested)
13 Critical Items PDR & Final Rev . Astium
14 Final Presentation Astrium
15 Final Presentation Laben
07.02
21.05
20.11
02.04
20.10
17.01
22.02
07.04
22.06
19.07
27.09
25.10
26.10
27.02
Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 22003 2004 2005 2006
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 82
GAIA PDHE GP-ASG-FR-0001
9 DELIVERABLES OF TDA
9.1 Documentation
The following key documents have been delivered as outcome of the TDA during phase 1 (only Astrium documentation):
Document Title WP Document Number Status Date of Issuance
GAIA PDHU HIGH-LEVEL REQUIREMENTS 1110 GP-ASG-TN-0001 Issue 1 20-02-2003
ANALYSIS OF GAIA STAR DETECTION AND
SELECTION ALGORITHMS FROM
IMPLEMENTATION POINT OF VIEW
1110 GP-ASG-RS-0001 Issue 1 26-03-2003
GDA IMPLEMENTATION REQUIREMENTS 1110 GP-ASG-TN-0002 Issue 2 Rev. 1 20-02-04
GAIA PDHS REQUIREMENTS 1110 GP-ASG-RS-0002 Issue1 Rev1 10-03-04
GAIA PDHS ARCHITECTURAL DESIGN 1210 GP-ASG-RS-0003 Issue1 24-02-04
GAIA PDHS INTERFACE CONTROL DOCUMENT 1210 GP-ASG-RS-0005 Issue1 03-03-04
VPU DETAILED SPECIFICATION 1310 GP-ASG-RS-0004 Issue1 10-03-04
USAGE OF A COTS SINGLE BOARD COMPUTER
FOR THE GAIA PDHE VIDEO PROCESSING UNIT
1310 GP-ASG-TN-0003 Issue1 28-10-03
PDHS BREADBOARD DDV PLAN 1420 GP-ASG-DP-0001 Issue1 10-03-04
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 83
GAIA PDHE GP-ASG-FR-0001
The following key documents have been delivered during phase 2 or will be delivered as outcome of the TDA at the end of phase 2:
Document Title WP Document Number Status Date of Issuance
PDHE Demonstrator Testbed Specification 2110 GP-ASG-RS-007 Issue 2 23.02.05
VPU Demonstrator User Manual 2110 GP-ASG-UM-001 Issue 1 24.03.05
VPU Demonstrator Host Design Document & GUI User
Manual
2120 GP-ASG-UM-002 Issue 1 11.03.05
Astro Stimulator Demonstrator Software Architecture
Document
2130 GP-ASG-SAD-001
Issue 1 10.03.05
Final end Sept. 05
VPU Software Requirements Document 2010 GP-ASG-RS-006 Issue 1 10.09.04
Final end Sept. 05
GAIA Astro VPU Software Architectural Design
Document
2140 GP-ASG-SAD-0002 Draft Draft 15.04.05
Final end Sept. 05
Astro VPU GAIA VPU Test Concept 2140 GP-ASG-TN-011 Issue 1 18.04.05
GAIA VPU Test Report 2160 To be
issued
Sept.05
GAIA VPU Validation Report 2310 To be
issued
Sept.05
FINAL REPORT 2010 To be
issued
Draft end July 05
Final end Sept. 05
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 84
GAIA PDHE GP-ASG-FR-0001
9.2 Demonstrator Hardware and Software
The following H/W and S/W deliverables have been defined as outcome of the TDA at the end of phase 2:
• VPU Demonstrator H/W
– 19’’ rack with all integrated demonstrator components
– 17’’ EIZO TFT Flat Screen, Keyboard and Mouse
• VPU Demonstrator S/W installed on Host
– Host Demonstrator System S/W (Windows XP, Drivers, Tools, EADS Astrium WindRiver Tornado License valid until 11/2005)
– Host Demonstrator Application S/W
• VPU Target S/W downloaded from Host
– VxWorks and SpaceWire driver
– Target Application S/W
• VPU Demonstrator User Manual, Backup DVD
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 85
GAIA PDHE GP-ASG-FR-0001
10 ASSESSMENT OF PERFORMANCE RESULTS W.R.T CRITICAL TECHNOLOGY REQUIREMENTS
In general the processing chain as built in the VPU Demonstrator is functionally working. Also the interface functionality between the Maxwell PPC board and the SpaceWire IF has been demonstrated although some performance tests will be repeated.
Another important point is that the processing power demanded by the Pyxis software as presently implemented is much larger than estimated back in 2003 (also under consideration of the evolution of Pyxis functionality). However, the processing power available is in principle close to the one requested.
Due to our experience some further optimizations are possible to reduce the current processing time of the Pyxis S/W.
• H/W: Additional FPGA taking part of image processing functionality (pixel processing)
• S/W: Optimization for processor structure
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 86
GAIA PDHE GP-ASG-FR-0001
11 CRITICAL TECHNOLOGY ITEMS COVERAGE
The following critical items have been identified for the VPU during the TDA
• The availability of the PPC 750FX chip (or an equivalent type concerning performance)
• The usage of an US distributor (Maxwell) for the core element of the VPU (ITAR problematic)
• The development of a powerful PPC board as an European solution
• The availability of the radiation tolerant Accelerator FPGA from Actel which is used for the implementation of the TMR voting feature, system controller, memory interface, PCI interface, IRQ and DMA handling on the Maxwell board.
• The availability of a powerful FPGA which is possibly needed for the implementation of some parts of the image processing
• The availability of the SMCS SpaceWire ASIC (not yet qualified finally)
• The availability of a PCI Target chip for the PCI implementation on the I/F board (an IP core for FPGA is available)
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 87
GAIA PDHE GP-ASG-FR-0001
12 PLANNING TO FLIGHT MODEL STATUS
The assumption derived from this TDA is that the flight model of the VPU is close to the design as shown in this report, i.e. 2 boards, one Processor board based on PowerPC plus one I/F board for SpaceWire connections including decentralized DC-DC converter, clock generation and possibly low level pixel processing FPGA (necessary because of performance requirements of GDA S/W):
The availability of the main components is listed in the following:
Maxwell SCS750FX PPC board: The development status of the Maxwell PPC board is shown in the following Maxwell roadmap (note that the SCS750 Proto Engineering board has been used for the VPU Demonstrator):
Figure 12-1: Maxwell SCS750 PPC Board Status Overview 1
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 88
GAIA PDHE GP-ASG-FR-0001
Figure 12-2: Maxwell SCS750 PPC Board Status Overview 2 (July 2005)
According to information from Maxwell (dated begin of July 2005) they are progressing along the path to flight. All Maxwell developed parts are on schedule and will be ready for the engineering and flight boards. At the moment Maxwell is in the process of finalizing the SCS750´s mechanical layout. One problem is that Actel´s schedule for the Accelerator FPGA is on hold at the moment. Furthermore Maxwell is optimistic about having the SCS750 removed from the ITAR list (official process started with the US Department of State).
Actel Accelerator FPGA: The qualification is expected for early 2006.
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 89
GAIA PDHE GP-ASG-FR-0001
SpaceWire: The SpaceWire standard ECSS-E-50-12 A is based on the IEEE-1355-1995 standard with bug fixes combined with LVDS signaling. The predecessor IEEE-1355 has been extensively tested across many mission/instrument developments (e.g. on
• ESA missions (Rosetta, MarsExpress, ISS, Cryosat)
• NASA instrument Alphascat
• JAXA spacecraft
• commercial missions (Inmarsat-4, WEST, Argos3, SarSat3).
There are chips, IP, software and development tools available. In the following a short overview is given about the status of available development/EGSE tools and the SpaceWire ASIC itself.
EGSE: Star-Dundee PCI/cPCI board: The board contains
• SMCS-332-SpW implemented in FPGA
– Functionally identical to SMCS-332-SpW ASIC
– 3 SpaceWire ports
– Interface to host computer and/or dual port memory
• PCI Interface device
• Dual Port Memory device
• Power supplies
This board has been successfully tested within the VPU Demonstrator in the cPCI version with Windows XP and VxWorks driver.
SpaceWire ASIC:
• Updated version of SMCS-332 device
• Anomalies fixed
• Now fully SpaceWire compliant
• Includes time-code support
• Radiation tolerant
• Designed by Astrium
• Uses UoD SpaceWire interface design
• Current status: ASIC prototypes tested and fully functional
• Manufactured by Atmel
• Support from STAR-Dundee Ltd
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 90
GAIA PDHE GP-ASG-FR-0001
VxWorks: VxWorks is a COTS real-time and scalable operating system which is available in short time for a broad variety of processor architectures and board manufactures. It provides good technical support from local vendor. It is a mature product, with a strong heritage in embedded aerospace systems, e.g.:
• NASA missions Mars Pathfinder, Deep Space One, Stardust, Mars Odyssey , Mars Exploration Rovers
• ESA missions Rosetta and Proba
• Numerous aircraft and military applications
FINAL REPORT
Doc. No.: GP-ASG-FR-0001
Issue: 1
Date: 12.12.2005 Project: GAIA PDHE Sheet: 91
GAIA PDHE GP-ASG-FR-0001
13 CONCLUSION OF VPU DEMONSTRATOR TDA
The following conclusions can be drawn from the TDA:
• The architecture and design proposed in phase 1 is working. This has been proven by the VPU Demonstrator in phase 2.
• The processing of two VPU´s per PowerPC does not seem to be feasible with the present performance.
• The image processing algorithms today (Pyxis 2.4) are more demanding in terms of processing performance than computed/estimated back in 2003.
• There are some optimizations possible in the S/W compared to the current implementation (details chapter 7.5.1):
o Code adaptation to processor structure (e.g. cache)
o Optimization of algorithms
o Optimization of I/O tasks and data formatting
o Proceed from demonstrator approach of plug – in of Pyxis modules to adapted and streamlined real time software system
• Improvement of processing power by selecting an architecture with a PowerPC plus an additional FPGA for dedicated pixel processing functionality.