Configuring an Application

Top  Previous  Next

Once an application has been designed and written as a collection of communicating tasks, how do you get it running on a physical network of processors?

 

First, you build each individual task to create task image files:


You build a CPU task by compiling all the source files with a C compiler and then using the linker to combine the resulting object files with the necessary modules from the run-time library. Repeating this for every task in your application results in a number of separate task image files.

You build an FPGA task using the standard Xilinx tools (although can also supply FPGA tasks as pre-built netlists).

Once you have built the task image files, you must combine them to form a single executable application file. The 3L utility that does this is called the configurer. You create a textual configuration file and this drives the configurer by specifying:


your hardware structure:
o the available processors
o explicit wires connecting the processors

your software structure:
o the tasks to be used
o the channel connections between your tasks

how to map the software onto the hardware by placing tasks on processors

You can write the configuration file yourself or you can allow the Diamond IDE to create it for you.

 

The configurer allocates memory for CPU tasks and builds bitstreams for FPGA tasks. It then combines your tasks and any implied system tasks into a single application file that can be loaded into the specified hardware network and executed using the IDE or the Diamond command, 3L X. Note that loading extracts components from the application file and puts them onto the appropriate processors; processors receive only those components that they need.

 

To change the way in which tasks are connected together or the processors on which they are to execute, it is not necessary to change your source code or even to recompile or re-link the tasks themselves (unless you move the task from one type of processor to a different type). This means, for example, that it is possible to develop an application while running all the tasks on one processor, and then reconfigure it, without any other change, to run on a network of processors.

 

Physical channels may be transparently substituted for virtual ones in a similar way where there is a direct wire available between the processors involved.