• the number of FPGA-based custom boards required to meet the MSE Classifier throughput requirements
• the complexity level required for the board control processor
• the partitioning, distribution and granularity of the processing load for the low- and high-resolution MSE processing, and
• the on-board memory requirements.

Cosmos performance models are made up of two major components: a hardware model (network architecture) and a software model (data flowgraph). The hardware and software models are defined independently and to the same level of detail. The independence of the models ensures a hardware architecture can be utilized with various software architectures and vice versa. Modeling both hardware and software at the same level of abstraction ensures that high-fidelity performance models are created and prevents hardware or software from dominating the model. Figure 1 shows how Cosmos' independent hardware and software models are merged, simulated and analyzed as a result of the mapping.

• 30 low resolution image chips per second
• 20 target classes per chip
• 72 pose angle templates per target class; and
• 121 dither locations per pose angle template.

The following low resolution parameters from the test and template data and were used to parameterize the Cosmos performance model:

• Each pose angle template contains 520 bytes (or 6240 bytes per 12 pose angle templates);
• Each image chip requires 2916 bytes; and
• Each group of 12 pose angle templates requires 2.04 milliseconds (or 170 microseconds per pose angle template) to process using the MSE custom logic design.

• 30 high resolution image chips per second
• 5 target classes per chip
• 14 pose angle templates per target class, and
• 49 dither locations per pose angle template.

In this case, the high resolution parameters derived from the test and template data analysis and used to define the Cosmos performance model:

• Each pose angle template contains 4100 bytes (or 49200 bytes per 12 pose angle templates)
• Each image chip requires 5202 bytes, and
• Each group of 12 pose angle templates requires 4.908 milliseconds (409 microseconds per pose angle template) to process using the MSE custom logic design.

To simplify the development effort while ensuring the integrity of the performance model, the following elements were modeled:

• Board Controller,
• Template Storage,
• MSE / MAD Operators,
• Dual-Ported Template and Chip Caches, and
• External VME and RACEway Interfaces.

Cosmos' Hardware Designer enables engineers to capture hardware architectures hierarchically. Figure 3 shows the top-level hardware architecture performance model represented in Cosmos. Previously, Cosmos had predominately been used to model multi-processor systems. However, with only minor adaptations, it was successfully used to rapidly model the SAIP MSE FPGA custom board design.

To accurately capture the behavior of each of the hardware elements, several techniques were developed. The PML library was limited in terms of the number and variety of hardware elements that it supported. For example, the PML library did not support a local "multi-drop" bus structure that is fairly common among board designs. However, standard PML hardware elements were used and adapted to accurately model the desired behavior. For instance, the VME bus bridge library element was used to model the behavior of the "multi-drop" bus. Figure 4 shows how the PML VME bus bridge library elements were adapted and combined to create the local "multi-drop" bus model.

In addition, processor elements were used to model the various memory and storage devices. This was accomplished by devising an approach, as shown in Figure 5, to accurately model the behavior of a dual-ported memory device. Two processor elements were configured in a manner to properly model the behavior of a dual-ported memory device. One processor element was used to model the input port of the device while the other processor was used to model the output port. Using this approach, tokens could be written and read from the device model simultaneously.

Cosmos automatically generates token routing tables based on specifying a software task as the token's destination. A token routing table is a static "lookup" table that defines all of the possible software communication paths throughout the system. This was the primary reason all of the hardware elements, including memory and storage devices, were modeled as processor elements. Using this approach, the communication task could be mapped to the memory and communication elements as software tasks.

The flow of commands and data through the system was very structured and processing flows were divided into two modes, Low and High Resolution. The tables below show, in detail, the flow of commands and data for the low and high resolution modes.