Transport triggered architecture

In computer architecture, a transport triggered architecture (TTA) is a kind of processor design in which programs directly control 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 a computation. This is similar to what happens in a systolic array. Due to its modular structure, TTA is an ideal processor template for application-specific instruction set processors (''ASIP'') with customized datapath but without the inflexibility and design cost of fixed function hardware accelerators.

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 processors based on it built, and the only one that has processors based on it sold commercially.

Benefits in comparison to VLIW architectures

TTAs can be seen as "exposed datapath" VLIW architectures. While VLIW is programmed using operations, TTA splits the operation execution to multiple ''move'' operations. The
low level programming model enables several benefits in comparison to the standard VLIW. For example, a TTA architecture can provide more parallelism with simpler register files than with VLIW. As the programmer is in control of the timing of the operand and result data transports, the complexity (the number of input and output ports) of the register file (RF) need not be scaled according to the worst case issue/completion scenario of the multiple parallel instructions.

An important unique software optimization enabled by the transport programming is called ''software bypassing''. In case of software bypassing, the programmer bypasses the register file write back by moving data directly to the next functional unit's operand ports. When this optimization is applied aggressively, the original move that transports the result to the register file can be eliminated completely, thus reducing both the register file port pressure and freeing a general purpose register for other temporary variables. The reduced register pressure, in addition to simplifying the required complexity of the RF hardware, can lead to significant CPU energy savings, an important benefit especially in mobile embedded systems.V. Guzma, P. Jääskeläinen, P. Kellomäki, and J. Takala, “Impact of Software Bypassing on Instruction Level Parallelism and Register File Traffic”

Johan Janssen
"Compiler Strategies for Transport Triggered Architectures"

2001.
p. 168.

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 application-specific 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

Some TTA implementations support conditional execution.

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.

Branches

All processors, including TTA processors, include control flow instructions that alter the program counter, which are used to implement subroutines, if-then-else, for-loop, etc. The assembly language for TTA processors typically includes control flow instructions such as unconditional branches (JUMP), conditional relative branches (BNZ), subroutine call (CALL), conditional return (RETNZ), etc. that look the same as the corresponding assembly language instructions for other processors.

Like all other operations on a TTA machine, these instructions are implemented as "move" instructions to a special function unit.

TTA implementations that support conditional execution, such as the sTTAck and the first MOVE prototype, can implement most of these control flow instructions as a conditional move to the program counter.

TTA implementations that only support unconditional data transports, such as the Maxim Integrated MAXQ, typically have a special function unit tightly connected to the program counter that responds to a variety of destination addresses.
Each such address, when used as the destination of a "move", has a different effect on the program counter—each "relative branch <condition>" instruction has a different destination address for each condition; and other destination addresses are used CALL, RETNZ, etc.

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 in
register 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 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. This makes the result of addition available in the output port 'result' after the execution latency of the 'add'.

The ports associated with the ALU may act as an accumulator, allowing creation of macro instructions that abstract away the underlying TTA:

lda r1 ; "load ALU": move value to ALU operand 1
add r2 ; add: move value to add trigger
sta r3 ; "store ALU": move value from ALU result

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 delay slots, the programmer visible operation latency of the function units. Timing is completely the responsibility of the 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. Consider, for example, an architecture that 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 unread result in the output port.

Due to the abundance of programmer-visible processor context which practically includes, in addition to register 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 from Maxim Integrated, the only commercially available microcontroller built upon transport triggered architecture, is an OISC or "one-instruction set computer". It offers a single though flexible MOVE instruction, which can then function as various virtual instructions by moving values directly to the program counter.
* Th
"move project"
has designed and fabricated several experimental TTA microprocessors.
* OpenASIP is an open source application-specific instruction set toolset utilizing TTA as the processor template.
* The architecture of the Amiga Copper has all the basic features of a transport triggered architecture.
* Th
Able
processor developed by New England Digital.
* The WireWorld base
computer


Dr. Dobb's
published One-Der, a 32-bit TTA in Verilog with a matching cross assembler and Forth compiler.Web site with more details on the Dr. Dobb's CPU

* Mali (200/400) vertex processor, uses a 128-bit instruction word single precision floating-point scalar TTA.

See also

* Application-specific instruction-set processor (ASIP)
* Very long instruction word (VLIW)
* Explicitly parallel instruction computing (EPIC)
* Dataflow architecture

References

External links

MOVE project: Automatic Synthesis of Application Specific Processors (accessible through the wayback machine)

{{DEFAULTSORT:Transport Triggered Architecture
Computer architecture
Instruction processing