State Machine Parameter Passing

NOTE: This section has changed drastically since the last draft ! Still being written. 7/12/96

This is a proposal for a generic parameter passing mechanism for stream processors. This mechanism is used to specify the input parameters for function to be executed, regardless of the actual machine implementation of the stream processor.

This mechanism will be used for the State Machine Stream Processor, part of Cheops, and with future architectures. Existing Cheops stream processor software interfaces will probably not be modified to work with this scheme, however suitable.

Parameter Structure

The structure for representing the parameters has several requirements:

It should identify the type of data being passed, to allow for translation between its standard format and the format desired by the stream processor selected for execution.
It should support parameters with large bit sizes (up to 64 bits, at least.)
It should be compact, to minimize transmission latency over slow communications channels.

These requirements strongly suggest the use of a tagged, variable length data word to represent each parameter. To simplify the software task of translating the standard format into the processor specific one, the size of the data word must be a multiple of eight bits (referred to hereafter as a byte.)

Fig. 1: Parameter Word Representation

The first byte of the parameter word is a tag containing both a four bit parameter type field, and four bits indicating the number of bytes of data in the parameter word. The parameter words are located in memory with the byte containing the tag in the lowest memory address, following by the least significant byte of the data word in the next higher address.

Fig. 2: Parameter List Representation

The parameters are passed as a list, started with a size field specifying the number of bytes in the parameter list (not including the size field). The size field utilizes one byte, limiting the parameter list to at most 255 bytes of parameters. This allows up to fifty 32-bit parameters, or fifteen 128-bit parameters, to be specified.

Predefined Parameter Types

The predefined values of the "type" field of a parameter word tag are :

0 - Unsigned Integer: An integer value, with sizes from one to sixteen bytes. This is also used for bit fields.
1 - Signed Integer: A two's complement signed integer value, from one to sixteen bytes.
2 - Floating Point: An IEEE Floating point number, with precision given by the size.
4 - Boolean False
5 - Boolean True: The data is implicitly encoded in the parameter type.
8 - Shared Memory ID: A shared memory id for accessing large or persistent data objects.
9 - Tagged Shared Memory ID: A shared memory id for accessing large or persistent data objects which are aggregates of dissimilar data objects (structures).

Caller Software Interface

To facilitate building a parameter list, a software abstraction is provided, in the form of functions which add a parameter of a particular type to a given parameter list. These are included as part of the State Machine extensions to the Rman interface library.

Passing of Parameters to Software Functions

In order to simplify the software internal to the functions being called, the tagged parameters are translated into a format native to the machine architecture and compiler being used before execution of the function begins. The instructions inside the function access the parameters as if they were passed from a native caller.

This format translation has two tasks. The first is to translate the scalar parameters into the convention of the local machine architecture. The parameters will be placed into registers and/or on a temporary stack provided to the function for internal dynamic variable storage. The second is to resolve the shared memory IDs into physical addresses in the local address space of the executing processor.

A C version of this format translator is available (in /mas/garden/cheops/local/src/diag/param/decode/decode.c ) for compilation, although there are parts which are impossible to express in a high level language which must be added in assembler.

Passing of Parameters to Hardware Functions

There are two candidate mechanisms for implementing parameter passing for function implemented solely in hardware. One is to provide a software function for each standalone hardware function, which does any necessary pre-processing of the input parameters and writes them to the memory-mapped hardware configuration registers. The other is to provide a structure defining the mapping between parameters and hardware configuration registers, and use a generic loader to interpret the mapping in the context of a particular set of parameters.

While I believe the flexibility of the former is a deciding factor, I am testing the latter in this implementation. If it works, it will be easy to build self-configuring special purpose processors.

The loading of the hardware configuration registers takes place before beginning execution of the software component of a function. The software function will receive the function parameter list already used for loading hardware registers.

The parameter_map structure defines the mapping between parameters and hardware registers. It contains a list of write operations, each requiring an address and a pair of indices into the function parameters. In addition, tagged constants (using the same format as the parameters list) are stored in a constant pool, for storing hardware specific configuration values.

Fig. 3: Using a Parameter Map to configure a function

The configuration register writes are to be performed sequentially, and are each described by three values:

An address indicating the destination of the write operation, expressed as an offset from a base local physical address. This base address is dependent on the actual processor being configured and is not determined until the time of execution.
An index into the function parameter list, or the parameter map constant pool. If the parameter being indexed is a shared memory ID, it is resolved into a pointer in the local physical address space to a shared memory object.
An offset into a shared memory object (if one is used in this write), or one of two special values. The offset is in units of whatever data structure the shared memory structure is defined as holding. A PARAMETER_PASS_BY_NAME value for the offset means that the associated shared memory id should be dereferenced into the stream processor address space and passed as the argument. A PARAMETER_SCALAR value means that the associated index value should point to a scalar (non shared memory) parameter.

A C version of the parameter_map structure is provided here, although the definitive version is in ${CHEOPS_BASE}/local/include/sys/params.h.

#define MAX_PARAMETER_WRITES            64
#define PARAMETER_CONSTANT( constant )  (MAX_PARAMETER_WRITES + (constant))
#define PARAMETER_SCALAR                0xFFFE
#define PARAMETER_PASS_BY_NAME          0xFFFF

typedef struct parameter_write {
  unsigned long   address;   /* address to write  */
  unsigned short  index;     /* index of parameter to write */
  unsigned short  offset;    /* offset into aggregate parameters */
} parameter_write;

typedef struct parameter_map {
  int             num_writes;               /* number of register writes  */
  parameter_write write[ MAX_PARAMETER_WRITES ];  /* register write descs */
  parameter_t     constant[ 1 ];            /* common pool of constants   */
} parameter_map;

Additional Considerations

Standardize identification of source and destination buffers in P2, a well as single phase and two phase transfers.

Standardize delay and ok signal passing for each src/dst transfer.

Please send comments regarding this proposal to wad@media.mit.edu

Jump to State Machine Software Overview
Jump to the State Machine Stream Processor
Jump to the Cheops Homepage

cheops-web@media.mit.edu