GAIA PDHE Final Report - European Space Agencyemits.sso.esa.int/emits-doc/ASTRIUMLIM/GAIA_VPU/GP... · RD-3 GAIA PDHU Requirements Spec, TL19516 Issue 1D, 10-10-03 RD-4 GAIASYS.SP.00031.T.ASTR,

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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


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


WP 1430 (L)PDHU


Requirements ConsolidationReview

GAIA PDHEPhase 1

DetailedSpecification

Review

FINAL REPORT


Issue: 1



• 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



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



• 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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



The following figure shows the final implementation of the VPU demonstrator.

Figure 7-2: VPU Demonstrator Overview Final Design

FINAL REPORT


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



Figure 7-8: Gaia Stimulator design

FINAL REPORT


Issue: 1



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


Issue: 1



Figure 7-10: Gaia Stimulator stripmap looping principle

FINAL REPORT


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



Figure 7-15: GAIA-Astro-VPU Core-functions

FINAL REPORT


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



f) Selection - Object-based (l54b0)

Figure 7-26: Selection AS1 for l54b0

� Average 10% = 70us (Required TDI cycle-time 736us = 100%)

FINAL REPORT


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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)


l54b0 609000 (fov1) + 181000 (fov2)


baade 3.31 Million (fov1) + 8700 (fov2)


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


Issue: 1



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%


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%


tim

e in

%T

DI

FINAL REPORT


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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


Issue: 1



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.