FireWire audio platform

description

In 2003, we noticed that off-the-shelf FireWire chips did not meet our requirements. As our market was sophisticated audio solutions for the ambitious musician, we were looking for a lot of channels (more than 16 in total), high sample rates (192kHz), high sample resolutions (24 bits), configurable clocking options, and flexible digital audio interfaces (I2S, IEC958, ADAT, TDIF). What we did not need was a lot of CPU power, as we believed in host-based DSP processing, instead we wanted to have the audio data streamed without CPU intervention.
 
With the good experience we made with the EMI 2|6 and EMI 6|2m, we were convinced that an FPGA-based implementation would be competitive in features and price with the ASSPs existing at that time.
 
< put a block diagram here >
 

hardware

The hardware concept was to move most of the components into a 300k-gate Spartan-IIE FPGA. Pushing the EMI 2|6 concept a little further, this includes the following modules:
 
The FPGA was surrounded by the following external components:
 
It is noted here, that the FireWire Link-Layer would be another candidate to be moved into the FPGA. However, this depends on the availability of suitable core solutions. Since it‘s acquisition of Zayante, Apple does have such a core in its portfolio. Unfortunately this core is not available in the public domain and furthermore, the suitability for FPGA implementation is unknown.
 

firmware

The firmware concept was as follows:
 
The eCos operating system was chosen, as it is royalty-free, with a licensing scheme that is liberal enough to be used in commercial applications. It supports threads, as required by the FireWire stack.
 
The Apple FireWire Reference Platform stack is open source and based on Zayante‘s TNF. It is a small-footprint solution, which can be easily ported to eCos. We chose to use the layers up to the AV/C generic target, but without any further AV/C classes.
 
The proprietary application was based on the AV/C audio/ music protocol, which is natively supported by Mac OS X, so that no additional drivers are required. Additional features not covered by AV/C could be added aside and supported by directly executing FireWire protocol elements from the host CPU‘s application via the user mode API build into Mac OS X.
 
The resulting solution had a memory footprint of less than 256kB total (code + data). This is a very compact solution, especially when compared to other commercial concepts. This helps to keep the cost of the platform low, and allows to use static RAM to store code and data.