Performance

The time it takes to load an application is made up from the times needed to load the DSPs and the FPGAs that are involved. Even though your application may not mention FPGAs explicitly, they are often needed to manage communication between your processors. Lyrtech hardware includes large FPGAs that can take a considerable time to load; as an example, loading a simple application that runs on two DSPs and one FPGA can take over twenty-five seconds on a LX100 board.

Any performance figures quoted for link devices are maxima; the actual rates achieved in practice depend on several things:

•	The size of the transfer. There is a fixed overhead associated with managing any transfer. This overhead becomes negligible when moving large amounts of data, but tends to dominate small transfers.

•

Availability of DMA. When you start a transfer,the kernel attempts to allocate a DMA channel to manage moving the data. The number of DMA channels available is limited to three. There are only four external interrupt lines and one needs to be used to synchronise each DMA transfer. One of these lines must be reserved to act as a fallback for transfers that cannot use DMA and must be managed with CPU interrupts. If all available DMA channels are tied up with concurrent transfers or have been claimed for other uses in the application, the transfer has to use CPU interrupts and achieves a considerably reduced transfer rate.

•

The alignment of the data. The C6000 hardware is unable to maintain coherency between the cache and external memory. When cached external memory is involved, the Diamond kernel has to limit the use of DMA to transfers or sections of transfers that are aligned on a cache-line boundary (addresses which are a multiple of 128) and of a size that is a multiple of the cache-line size (128 bytes). Parts of a transfer that are misaligned or not a multiple of 128 bytes must be handled by CPU interrupts, and this is considerably slower than using DMA.