| |
 |
|
|
|
|
|
 |
| STEP 1: Define Application Functionality |
 |
Gedae’s editor is designed to make it easy to build application models. The developer adds functional blocks and parameters to the canvas then wires outputs to inputs to complete the functional definition. See figure 1. We call these flow graphs. The developer can also create hierarchical components as well – a perfect way to make applications easy to read. If you ask a systems, electrical or software engineer to describe their application they are likely to put pen to paper and draw a block diagram that looks much like a Gedae graph. Any time during the development the developer can run the application to test components under development using data collected during field trials or simulated data generated using a Gedae flow graph. Once the developer is satisfied with the functionality s/he is ready to build an application for the target hardware. |
 |
|
| STEP 2: Define Implementation Specification |
 |
Once the application functionality is developed, or indeed during the course of development, is it straight forward to run it on the target system. Figure 2 shows the dialog for partitioning the functionality. Gedae provides tools to make it easy even when there are in excess of 10,000 boxes. At this point the developer simply pushes the run button and Gedae compiles the application as specified to produce and start the necessary executables. Typically the developer will collect the trace information to determine if the target hardware is effectively loaded and if the performance requirements – throughput and latency – are being met. The developer can easily identify which components in the system are taking the most compute time and focus on optimizing those components. The developer can also identify situations that are limiting concurrent execution. |
|
|
| STEP 3: Optimize Application Execution |
 |
The developer has accessible a variety of tools for analyzing and optimizing the execution of the application on the target hardware. Figure 3 illustrates one such optimization. In this case the developer has noticed that during the corner turn operation all processors are idle at one time or another waiting for the other processor. Surmising that there is a way to let all progress uniformly the developers continues the analysis and discovers that there is a serialization of the exchange of data among the processors and optimizes the IPC settings to eliminate the blocking and achieve a much higher density of execution. In addition to partitioning memory and functionality there is an opportunity to set many other implementation parameters such as the IPC type and parameters, granularity, queue sizes, function priority, thread priority and thread scheduling policy. In addition the developer can specify other optimizations such as strip mining. |
|
|
|
|
| |
|
|
|
|
|
|
|
|
