1. Implementation for Air Traffic Control on ClearSpeed CSX600
Mike Yuan
Advisor: Prof. Johnnie Baker
Parallel and Associative Computing Group
Department of Computer Science
Kent State University

2. Outline Overview of ClearSpeed CSX600 Introduction to ATC
Shell of ATC on CSX600
- Task scheduling
- Transfer data from host to board
- Data transfer within the board
Future work
References

3. ClearSpeed CSX600 Accelerator Board
A PCI-X card equipped with two ClearSpeed CSX600 coprocessors

4. Performance specifications of CSX600
Sustained double-precision performance of 25 GFLOPS on DGEMM
10 W max power consumption
250 MHz clock speed
Transfer speed of internal memory: 96 Gbyes/s
Transfer speed of external memory: 3.2 Gbytes/s

5. Multi-threaded Array Processing (MTAP) architecture of CSX600
Mono execution unit
-process non-parallel data
-handle program flow control
Poly execution unit
-96 PEs
-6KB SRAM
-dual 64-bit FPU
-integer ALU
-32/64-bit floating-point multiplier and an adder
-128B register files
-I/O

6. Cn language Similar to standard C Main difference is poly variables
Example code:
#include <stdiop.h> // Output support
#include <lib_ext.h> // Extra functions to support features of hardware
int main() {
poly int n;
n = get_penum(); // individual PE number
printfp("PE number: %d\n", n); // Output different message per PE return 0; }
poly short get_penum(): number of current PE
mono short get_num_pes(): number of PEs on CSX processor

7. ATC Fundamental Needs
The best estimate of position, speed and heading of every aircraft in the environment at all times.
To satisfy the informational needs of all airline, commercial and general aviation users.
Some of these needs are:
Conflict detection and alert
Conflict resolution
Terrain avoidance
Automatic VFR voice advisory
Free flight
Final approach spacing
Cockpit display

8. ATC real-time database
Collision avoidance
Radar
GPS
Flight plans update
Radar
Conflict resolution
Track data
Controller displays
Restriction avoidance
Real time database
Autovoice advisory
Terrain avoidance
Weather status
Pilot
Terminal conditions
Aircraft data

9. Some ATC facilities Air Route Traffic Control Centers 20
Terminal Radar Control Systems 186
Air Traffic Control Towers 300
The first two facility types are supplied with radar from about 630 radar systems.

10. ATC worst case environment
Controlled IFR flights ,000
IFR means “instrument flight rules”
Other flights ,000
Uncontrolled VFR flights
“visual flight rules”
IFR flights in adjacent sectors
Total tracked flights ,000
Controllers
Radar Reports per Second ,000

11. Static schedule of tasks
Task period Proc
Time
Report Correlation & Tracking
Cockpit Display (750 /sec)
Controller Display Update (7500/sec)
Aperiodic Requests (200 /sec)
Automatic Voice Advisory (600 /sec)
Terrain Avoidance
Conflict Detection & Resolution
Final Approach (100 runways)
Summation of Task Times in an 8 second period

12. Shell of ATC on CSX600 Task scheduling
Transfer data from host to board
Data transfer within the board

13. Task scheduling
The host (.c program) schedules the tasks and the tasks are implemented on the board (.cn program)
- Tasks wait for sem_wait()
- Trigger correct tasks by calling CSAPI_semaphore_signal at the appropriate time, e.g.:
Run tasks 1, 2, 3, 4 in the first 0.5 second period
Run tasks 1, 5 in the second 0.5 period
- Tasks use get_cycles() for processing time

14. A Static Schedule for ATC Tasks
.5 sec sec sec 8 sec
T T2, T3, T4
T T5 T1
T T6
T T7
T T5
T T8 T1

15. Issues of Task scheduling
Tasks need to be implemented not only logically correctly but also within deadline

16. Transfer data from host to board
Data preparation
- Track[14000]: predicted positional data of established tracks for the aircraft
- Report[4000]: aircraft data from radar reports
- Created on host because boards do not support input directly

17. Transfer data from host to board (cont)
Use CSAPI_write_mono_memory() to fill buffers with Track[] and Report[]
CSAPIErrno CSAPI_write_mono_memory(struct CSAPIState* const s, struct CSAPITransferParam* tp, CSAPIMemoryAddress address, CSAPIMemorySize size, const void* data_in );
Copies data from a buffer on the host pointed to by data_in, to a location in mono memory (DRAM or ESRAM) given by address
s: State created by CSAPI_new
tp: Transfer parameters. For example CSAPI_TRANSFER_PARAMS_SAFE
address: Address of mono memory (DRAM or ESRAM) to start writing to
size: Number of bytes to copy from data_in (on host) to address (on card)
data_in: Address on host to start copying data from (used to identify processor)

18. Transfer data from host to board (cont)
Transfer Track[] and Report[] from host to mono memory
- .c program signals the semaphore to start processing and wait for the processing to complete
- .cn program waits for the host to fill buffers
- Signals the start semaphore
- Transfers data into mono

19. Issues of transfer data from host to mono
External bandwidth: 3.2 Gbytes/s
Bottleneck, reduce times to transfer or put data in a format that is best efficient for CSX600

20. Data transfer within the board
Transfer Track[] on mono to PEs in parallel
-void memcpym2p(poly void *mono s1, const mono void * poly s2,mono int n)
-copies n bytes per PE from mono memory pointed to by s2 into poly memory pointed to by s1 no restrictions
-void async_memcpym2p(unsigned short sem, poly void * mono s1, const mono void * poly s2, mono unsigned short n)
-copies n bytes per PE from mono memory pointed to by s2 into poly memory pointed to by s1
-s2 is a poly pointer: each PE can point to a different mono memory address, supporting gather/scatter
-s1 is a mono pointer: each PE has to copy into the same PE memory location

21. Data transfer within the board (cont)
Task 1: Report correlation and tracking
- Broadcast Report[0] to [4000] to all PEs
- Compare Report[i] to all Track[] records and compute in parallel

22. Issues of data transfer within the board
Internal bandwidth: 96Gbps
Asynchronous is better than synchronous
Bottleneck because of limited memory space on the PEs: each PE has its own SRAM-based local memory of 6k bytes
Improvement by hardware or software adjustment

23. Future work Empirical data for air crafts Implement actual tasks
Load balancing

24. References
M.R. Garey and D. S. Johnson, Computers and Intractability: a Guide to the Theory of NP-completeness, W.H. Freeman, New York, 1979, pp.65-66, pp
M.Jin, J. Baker, and K. Batcher, Timings of Associative Operations on the MASC model, Proceedings of the International Parallel and Distributed Symposium (IPDPS’01), WMPP workshop, San Francisco, CA, April, (Unofficial version at under “papers”).
Will Meilander, Johnnie Baker, and Mingxian Jin, Predictable Real-Time Scheduling for Air Traffic Control, Proc. of the 15th International Conference of Systems Engineering, presented at Las Vegas, NV, August 2002, pp (Unofficial version at under “papers”).
Will C. Meilander, Mingxian Jin, and Johnnie W. Baker, Tractable Real-Time Air Traffic Control Automation, Proc. of the 14th IASTED International Conference on Parallel and Distributed Computing and Systems (PDCS 2002), presented at Cambridge, MA, November 2002, pp (Unofficial version at under “papers”).

25. References (cont)
Will Meilander, Johnnie Baker, and Mingxian Jin, Importance of SIMD Computation Reconsidered, in Proc. of the 17th International Parallel and Distributed Processing Symposium (IEEE Workshop on Massively Parallel Processing), abstract on page 266, full text on CDROM , presented at Nice, France, April (Unofficial version at under “papers”).
Stewart Reddaway, Will Meilander, Johnnie Baker, and Justin Kidman, Overview of Air Traffic Control Using an SIMD COTS System, Proc. of the International Parallel and Distributed Processing Symposium (IPDPS’05), Denver, 9 pages, April (Unofficial version at under “papers”).
J.A.Stankovic, M. Spuri, K. Ramamamritham and G.C. Buttazzo, Deadline Scheduling for Real-time Systems, Kluwer Academic Publishers, 1998.