This section describes the software system supporting the State Machine Stream processor, part of the Cheops image processing system. It is divided into two sections, one for using existing State Machine functions in an application, and the second for developing new State Machine functions.
The use of a resource manager to dynamically schedule the processing tasks across multiple processors does not allow an application to determine which stream processor will be used to execute an operation. The sole means of providing parameters to a function executing on a stream processor, therefore, is by linking them to the function request structure. A machine independent parameter passing mechanism is defined to facilitate this. This mechanism supports functions executing completely in hardware as well as those incorporating software running on a general purpose processor.
In order to represent data objects which are either persistent across multiple function invocations or larger than is possible to reasonably include in the parameter structure, a shared memory mechanism is supported by the resource manager. This shared memory mechanism supports the automatic migration of data structures between processors.
The application interface most commonly used to program an application using a stream processor is the Rman Library. This library aids in the construction of data structures describing a dataflow algorithm, and their execution by the resource manager. A few State Machine Rman Routines are provided to support it. Using this interface, an application need not know how many state machines are actually in a system, nor deal with loading code and data, or scheduling.
The responsibility for loading the code resources required for a
function, irrespective of type, into the application's memory on a
Cheops P2 processor is delegated to the user application. This is
true even when using the Rman interface, although a function is provided to perform the task.
There are three classes of function implementations on the State
Machine. Depending on the implementation class, a stream processor
function definition contains either or both a software and hardware
(FPGA configuration) component. Indeed, even if a software only
approach is desired, the hardware will be used for rapid data transfer
to/from main memory.
These are probably the simplest applications that the State Machine
will perform. The PC603 does not contribute to this computation. Computations
are performed by the programmable logic within the FPGAs (e.g. bit swapping,
simple filtering) and the SRAM Look-Up Tables (LUTs). (The LUTs are to be
pre-programmed under the control of the resource manager).
The State Machine supports more complex FPGA applications, or
those where more I/O streams are required, using the
Boswell and Johnson FPGAs working together. The two FPGAs can communicate
to each other directly via a 40-bit Boswell-Johnson data bus. In addition, each
FPGA has the ability to drive the address bus of the other FPGAs SRAM.
The simplest case of this application is when the PowerPC603 is
the only device which performs actual computations on the stream data.
Here, the FPGAs act merely as stream I/O controllers, and serve only
to flood data into and out of the Boswell/Johnson SRAMs. Other Type
III applications will have the FPGAs performing operations on the
stream data in addition to flooding it into SRAM.
For further information :
The following are low level interfaces which are used exclusively
by the resource manager to manage resources and execute functions on
the State Machine processors. User applications should never need to
use these interfaces...
Developing New Functions
Type I: FPGA only functions
Type II: Both FPGAs in tandem
Type III: PC603 with FPGAs
Low Level Interface
Jump to the State Machine Stream Processor
Jump to Cheops Software
Jump to the Cheops Homepage
cheops-web@media.mit.edu
This is a "fix it yourself" page, located at
${CHEOPS_BASE}/WWW/statemac/software/index.html