Language Issues of Compiling Ada to Hardware

Michael Ward

Real-Time Systems Group

University of York

michael.ward@cs.york.ac.uk

Overview

• Real-Time background

• Compiler Background

• Hardware Ada Issues– Representation Clauses

– Fine Grain Parallelism

– Others

• Future work

• Conclusions

Real-Time Systems

• Real-Time systems typically have high cost of failure - need to be proved correct.

• Both functional and timing correctness need to be proved.

• Processor based implementations are hard to analyse for timing.

• Hardware implementations of RTSs provide the accuracy of timing.

• Current hardware implementations of high-level languages do not provide for RTS.

Hardware Compiler Review

• Hardware Ada compiler attempts to provide a RTS capable language in hardware.

• Uses SPARK and Ravenscar subsets of the Ada 95 language to give static, analysable subset.

• Generates circuits from Ada program using a template instantiation approach.

• Gives a much lower rate of pessimism than a conventional implementation of the same program

Timing Analysis of Compiler

procedure trisum (n : in integer;

sum : out integer) is

tri : integer;

begin

sum := 0;

for i in 1..n loop

tri := 0;

for j in 1..i loop

tri := tri + j;

end loop;

sum := sum + tri;

end loop;

end trisum;

Clock Cycles Time (ms) Normalised TimeFPGA CPU FPGA CPU FPGA CPU

Naive 1,302 341,666 0.065 0.683 1.00 10.51Model 1,302 77,766 0.065 0.155 1.00 2.38Path 732 44,602 0.037 0.089 1.00 2.41

Expected 732 13,122 0.037 0.026 1.00 0.70

Ada Issues

• Ada definition is processor biased.

• Always assumes von-Nuemann based implementations.

• Causes no problems with the hardware implementation of the sequential language.

• Affects the concurrent and system integration parts:– Representation clauses

– Priorities, queueing and blocking

• Does not allow for some capabilities of the implementation– Fine-grain parallelism

Representation Clauses

• Allow the representation and location of a variable to be declared in the program.

• Location is specified as an address– FPGAs have no address bus, therefore no addresses.

• Possible Solutions:– Include a memory map in the circuit.

– Attach each variable to a set of device pins.

– Include many small memory maps.

• Also need a method of naming the pins to use for attachment.

Representation Example

port_1 : fpga.port(8);

for port_1’pins use fpga.pins_to_port(p1,p3,p2,p5,p9,p8,p7,p10);

port_2 : fpga.port(2);

LCD_port : fpga.port(4);

debug : integer range 0..15;

for debug’port use LCD_port;

-- reg1 to reg4 defined as for a processor based application

for reg1’data_port use port_1;

for reg1’addr_port use fpga.address_port’(port2, 0);

for reg2’data_port use port_1;

for reg2’addr_port use fpga.address_port’(port2, 1);

Representation Cont.

Fine-grain Parallelism

• Concurrent tasks can be implemented in parallel on FPGAs.

• More (fine-grained) parallelism is available in the sequential parts of the programs.

• Semantic analysis can detect this parallelism but has problems:– Not all parallelism can be found.

– Some necessarily sequential code will be parallelised.

Parallelism Solutions• Use a pragma ‘Parallel’

– Indicates sections to be parallelised.

– No comment on the rest of the code.

» Can miss more parallelism which hasn’t been indicated.

• Use two pragmas ‘Parallel’ and ‘Sequence’– Indicates sections to parallelise, and those to leave sequential

» Compiler can attempt to parallelise all unindicated sections.

• Change Ada syntax to include a PARALLEL statement.– Requires changes to the rest of the specification of the

sequential part of the language.

» Static semantics will change.

Parallelism Example

Other Issues

• Interrupts.– Much greater range of interrupt signals possible.

– Need to consider alternative means of naming interrupt sources.

• Specific protected types (e.g. Buffers, stacks)– Allow more efficient implementations of the protected

objects.

– Reduce code (and therefore potential error.

• Specific communication types :– Destructive / non-destructive write.

– Destructive / non-destructive read.

Further Work

• Can be split into 3 parts :

• Compiler– Multiple concurrent tasks.

– Intertask communication.

– System Integration.

• Timing Analysis.– Can only cope with flat sequential code.

– Needs extension to cope with sub-programs.

– Concurrency and task interference needs to be analysed.

• Ada Language– More issues need to be addressed, and others will no

doubt appear.

Conclusions

• Shown the benefits to timing analysis of hardware implementations of Ada.

• Problems with the Ada specification have been identified.

• Solutions to some of these have been discussed.