Design Issues
One of the principal properties of the CLIP technology is that it only addresses a very specific aspect of the target application (concurrency). More importantly, concurrency issues are factorized out from the rest of the application logic, which therefore facilitates a hybrid development approach. This will probably be familiar to any engineer that has used form designers for instance to develop the GUI part of a previous project. And just as form designers have led some companies to see GUI programming as a specialized activity within their general projects, so CLIP has led some developers to take the same view of concurrency. This is in contrast to the typical approach that would be taken by a team working with conventional threads, because in that case, the processing code and threading logic are generally embroiled, and in order to avoid deadlocks and races, most engineers therefore need to be familiar with threads, locks etc.
In his recent book "Threading Building Blocks", Intel's James Reinders advises developers to consider concurrency at the very earliest stages of design, and this is the approach that seems to have worked best for most of the CLIP projects that have been undertaken to date. In fact the first stage of most CLIP projects is the design of all circuitry, and the details of data objects and processing code are generally considered at a later stage. Of course the processing algorithms themselves must generally be known in advance of the circuitry, otherwise the event flow and synchronization that the circuits capture could not be determined.
Broadly speaking, there have been two types of project that CLIP has been used for. The first have involved the migration of existing (usually sequential) applications to CLIP, and the second, the development of new applications from scratch. The two approaches have been slightly different.
Migrating Legacy Applications
In this case the structure of the application already exists and the the task is generally to take CPU intensive sub-systems (usually data-parallel in nature) and parallelize these in isolation. The 'Connective Logic' section gives several examples of both regular and irregular cases, and explains the process by which data and task parallel equivalents can be realized using CLIP circuitry. These can then be 'called' from the migrated application.
Developing New Applications
New applications are designed from a 'Process' centric perspective, ie what does the system have to do and what are the sequences of processing that are required to do it. Each 'Process' is then described by a circuit (and sub-circuits). Several 'Processes' may require common data, these can be accessed by cross-linking from one circuit to another.
Eg - A typical Passive Sonar (Simple) System Processes
- Data Aquisition - Read data from acoustic hardware, Quality monitoring
- Data Processing - Data filtering, Frequency domain transforms
- Beamforming - Form beamed data
- Pixellation - Generate graphical data
- Display - Display graphical data
- Recording - Record control, raw and processed data to file
- Replay - Replay recorded raw or processed data from file
- System Control - User inputs to configure the system
When analysing the sequences of processing that is required for each process, designers need to consider the inherent independent/parallel aspects of the processing
Eg. In the Sonar system above
- Each Acoustic Hydrophone Channel input can be independently monitored
- Each Channel can be independently transformed
- Each Beam can be independently calculated (requires all or a sub set of the channels)
- Each Beam can be independently pixellated
- Display requires all pixellated data
- Recording requires all channels and all beams. However, Channels and Beams are independent
- Replayed data can be processed independently from live data
As yet we have not considered any specific hardware requirements, the target hardware has been considered to be a single powerful parallel platform. In most cases this is sufficient, the circuitry which forms a logical description of the solution can be run on a single-core, multi-core or network of computers. However, there are aspects of target hardware that we do have to take into account in the design, ie can a single computer handle all of the required inputs and outputs
Eg. In the Sonar system above
- The hydrophone data may require several ATM interface cards (typically max 1 per PC)
- The Display may need to drive several consoles (operators).
These issues can be addressed with the use of Sub-Master and Definitive Slave Circuit Accretion.
For details of the Development Process and hints on Do and Dont's etc see the section The Development Process