Transport triggered architecture

The transport triggered architecture (TTA) is an application-specific instruction-set processor ("ASIP") architecture template that allows easy customization of microprocessor designs. The basic idea of transport triggering is to allow programs to have complete control over the internal transport buses of a processor. Computation happens as a side-effect of data transports: writing data into a "triggering port" of a functional unit triggers the functional unit to start computation. This is similar to what happens in a systolic array.

Typically a transport triggered processor has multiple transport buses and multiple functional units connected to the buses, which provides opportunities for instruction level parallelism. The parallelism is statically defined by the programmer. In this respect (and obviously due to the large instruction word width), the TTA architecture resembles the Very Long Instruction Word (VLIW) architecture. A TTA instruction word is composed of multiple slots, one slot per bus, and each slot determines the data transport that takes place on the corresponding bus. The fine-grained control allows some optimizations that are not possible in a conventional processor. For example, software can transfer data directly between functional units without using registers.

Transport triggering exposes some microarchitectural details that are normally hidden from programmers. This greatly simplifies the control logic of a processor, because many decisions normally done at run time are fixed at compile time. However, it also means that a binary compiled for one TTA processor will not run on another one without recompilation if there is even a small difference in the architecture between the two. The binary incompatibility problem, in addition to the complexity of implementing a full context switch, makes TTAs more suitable for embedded systems than for general purpose computing.

Of all the one instruction set computer architectures, the TTA architecture is one of the few that has had CPUs based on it built, and the only one that has CPUs based on it sold commercially.

Structure

TTA processors are built of independent "function units" and register files, which are connected with "transport buses" and "sockets".

Function unit

Each function unit implements one or more operations, which implement functionality ranging from a simple addition of integers to a complex and arbitrary user-defined computation. Operands for operations are transferred through function unit "ports".

Each function unit may have an independent pipeline. In case a function unit is fully pipelined, a new operation that takes multiple clock cycles to finish can be started in every clock cycle. On the other hand, a pipeline can be such that it does not always accept new operation start requests while an old one is still executing.

Data memory access and communication to outside of the processor is handled by using special function units. Function units that implement memory accessing operations and connect to a memory module are often called load/store units.

Control unit

"Control unit" is a special case of function units which controls execution of programs. Control unit has access to the instruction memory in order to fetch the instructions to be executed. In order to allow the executed programs to transfer the execution (jump) to an arbitrary position in the executed program, control unit provides control flow operations. A control unit usually has an instruction pipeline, which consists of stages for fetching, decoding and executing program instructions.

Register files

Register files contain general purpose registers, which are used to store variables in programs. Like function units, also register files have input and output ports. The number of read and write ports, that is, the capability of being able to read and write multiple registers in a same clock cycle, can vary in each register file.

Transport buses and sockets

Interconnect architecture consists of transport buses which are connected to function unit ports by means of "sockets". Due to expense of connectivity, it is usual to reduce the number of connections between units (function units and register files). A TTA is said to be "fully connected" in case there is a path from each unit output port to every unit's input ports.

Sockets provide means for programming TTA processors by allowing to select which bus-to-port connections of the socket are enabled at any time instant. Thus, data transports taking place in a clock cycle can be programmed by defining the source and destination socket/port connection to be enabled for each bus.

Conditional execution is implemented with the aid of "guards". Each data transport can be conditionalized by a guard, which is connected to a register (often a 1-bit conditional register) and to a bus. In case the value of the guarded register evaluates to false (zero), the data transport programmed for the bus the guard is connected to is "squashed", that is, not written to its destination. "Unconditional" data transports are not connected to any guard and are always executed.

TTA customization

Customization being one motivation for developing TTA processorsFact|date=March 2008, a new TTA processor can be created by defining function units, operations implemented in each function unit, register files, count of registers in each register files, count of buses, and connections between units.

Programming

In more traditional processor architectures, a processor is usually programmed by defining the executed operations and their operands. For example, an addition instruction in a RISC architecture could look like the following.

add r3, r1, r2

This example operation adds the values of general-purpose registers r1 and r2 and stores the result inregister r3. Coarsely, the execution of the instruction in the processor probably results in translating the instruction to control signals which control the interconnection network connections and function units. The interconnection network is used to transfer the current values of registers r1 and r2 to the function unit that is capable of executing the add operation, often called ALU as in Arithmetic-Logic Unit. Finally, a control signal selects and triggers the addition operation in ALU, of which result is transferred back to the register r3.

TTA programs do not define the operations, but only the data transports needed to write and read the operand values. Operation itself is triggered by writing data to a "triggering operand" of an operation. Thus, an operation is executed as a side effect of the triggering data transport. Therefore, executing an addition operation in TTA requires three data transport definitions, also called "moves". A move defines endpoints for a data transport taking place in a transport bus. For instance, a move can state that a data transport from function unit F, port 1, to register file R, register index 2, should take place in bus B1. In case there are multiple buses in the target processor, each bus can be utilized in parallel in the same clock cycle. Thus, it is possible to exploit data transport level level parallelism by scheduling several data transports in the same instruction.

An addition operation can be executed in a TTA processor as follows:

r1 -> ALU.operand1

r2 -> ALU.add.trigger

ALU.result -> r3

The second move, a write to the second operand of the function unit called ALU, triggers the addition operation, which makes result of addition available in the output port 'result' after the execution latency of the 'add'.

Customizable operation set

One of the customization points for TTA is the operation set. It is possible for the designer to add a new operation to the target processor which implements arbitrary functionality. This allows, for example, to convert longer chains of operations to a single custom operation execution.

A short example might clarify this idea. Let us assume than an algorithm includes lots of subtractions and additions of same input operands, thus the sequential code would include sequences like this:

r1 -> sub.1

r2 -> sub.2

sub.3 -> r3

r1 -> add.1

r2 -> add.2

add.3 -> r4

Now, the designer of the TTA system sees that a piece of code including a sequence like this is ranked high in the profiling data, that is, a major part of the execution time is spent running the code. Therefore, he decides to create a new custom operation, "addsub", which computes both the sum and the difference of the operands it receives and places the difference in the first output and the sum in the second output. The new custom operation can be used to convert the previous code to the following:

r1 -> addsub.1

r2 -> addsub.2

addsub.3 -> r3

addsub.4 -> r4

Getting rid of the two moves might not seem much, but it might provide bigger savings in the long run if the sequence is executed in a tight loop with only a few instructions. Furthermore, the same optimization strategy of converting sequences of operations into a single custom operation can be applied to chains of operations of virtually arbitrary length.

Programmer visible operation latency

The leading philosophy of TTAs is to move complexity from hardware to software. Due to this, several additional hazards are introduced to the programmer. One of them is the programmer visible operation latency of the function units. Timing is completely a responsibility of programmer. The programmer has to schedule the instructions such that the result is neither read too early nor too late. There is no hardware detection to lock up the processor in case a result is read too early. For example, let us say that an architecture has an operation "add" with latency of 1, and operation "mul" with latency of 3. When triggering the "add" operation, it is possible to read the result in the next instruction (next clock cycle), but in case of "mul", one has to wait for two instructions before the result can be read. The result is ready for the 3rd instruction after the triggering instruction.

Reading a result too early results in reading the result of a previously triggered operation, or in case no operation was triggered previously in the function unit, the read value is undefined. On the other hand, result must be read early enough to make sure the next operation result does not overwrite the yet unreadresult in the output port.

Due to the abundance of programmer-visible processor context which practically includes, in addition toregister file contents, also function unit pipeline register contents and/or function unit input and output ports, context saves required for external interrupt support can become complex and expensive to implement in a TTA processor. Therefore, interrupts are usually not supported by TTA processors, but their task is delegated to an external hardware (e.g., an I/O processor) or their need is avoided by using an alternative synchronization/communication mechanism such as polling.

Implementations

*MAXQ:Currently, the only [OISC#MAXQ| [*] commercially available microcontroller built upon (though not "featuring") Transport Triggered Architecture is from Dallas Semiconductor. However, it is an OISC or "One instruction set computer", offering but a single though flexible MOVE instruction, which can then function as various virtual instructions by MOVEing values directly to the program counter.

* The [http://ce.et.tudelft.nl/MOVE/ "move project"] has designed and fabricated several experimental TTA microprocessors.

ee also

*Very long instruction word (VLIW)
*Explicitly parallel instruction computing (EPIC)
*Dataflow architecture

External links

* [http://ce-serv.et.tudelft.nl/MOVE/ MOVE project: Automatic Synthesis of Application Specific Processors]
** [http://ce-serv.et.tudelft.nl/MOVE/section3.3.html Advantages of transport-triggered architectures]
* [http://www.ics.ele.tue.nl/~heco/documents/TTAbook/TTAbook.html Microprocessor Architectures from VLIW to TTA]
* [http://tce.cs.tut.fi TTA Codesign Environment. Upcoming toolset for design of application specific TTA processors.]
* [http://www.byte.com/art/9502/sec13/art1.htm BYTE overview article]