To understand why customization is important, consider the following three examples where a reference design can be used as a starting point, but the designer might want to make changes to the design, even at a late stage:

1. A design implements part of a communications stack (for example, USB audio), but the hardware interface on the audio side can be customized to communicate with a specific type of codec such as I2S master or slave S/PDIF, or it can be customized with an extra control endpoint.
2. An industrial controller implements one of the many standard protocols; for example, a vendor of industrial motors might want to include an Ethernet PHY, but defers the decision whether to run EtherCAT or any other real-time Ethernet stack.
3. An embedded Web server can be used to configure either of the previous examples, provided that the designer can implement the control logic inside the Web server.

The ease with which designs can be customized depends on the technology used to implement the core of the design. Did it use an ASIC, an FPGA, or a real-time processor?

If the design is implemented as an ASIC, then the only feasible way to customize it is to modify parameters built into the ASIC. Considering the first example, a USB audio ASIC will have a method to set the product name of the USB device and might provide a choice between left- and right-aligned I2S. However, it might not offer the options to add an extra control endpoint or to use S/PDIF as an output interface. Indeed, it is not possible to develop an ASIC that supports all plausible interfaces, and it is not economical to develop a family of ASICs that supports well-chosen, small sets of interfaces.

If the design is implemented in an FPGA then, in theory, customization can be as extreme as the user wants it to be. However, a hardware design flow might make customization a not-so-straightforward process. Implementing an additional interface such as S/PDIF is not difficult for hardware designers, but implementing an extra control endpoint requires software to be re-implemented as a piece of hardware. Furthermore, the result must be synthesized, and until the customized design is completely synthesized, placed, and routed it is not clear as to whether the original timing constraints are all still met.

The third option is to implement the design entirely as software. This is often considered difficult to accomplish because of the many conflicting real-time requirements involved. However, a software implementation can be perfectly manageable, provided that the programmer can split the problem into a set of independent real-time tasks that run on a bucket of independent real-time processors.

This gives the designer the flexibility to implement a hardware protocol simply as a software task by dedicating one of the real-time processors to implementing that hardware protocol. For example, one can implement I2S in software by wiggling the clock and data lines in an appropriate manner. Also, USB can be implemented by reading and writing data to the USB PHY. If these two activities are executed as two independent tasks, then all real-time deadlines can be met individually.

The latter is a programming model known as concurrent real-time programming. Figure 1 shows how a single XMOS XCore processor can execute eight threads simultaneously. Each thread can be seen as an individual processor with a guaranteed real-time execution rate. Each instruction will execute within a known amount of time; hence the programmer can predict whether programs will meet timing deadlines or not.

 

 

The beauty of this model is that timing prediction is entirely self-contained to the task. As an example, consider the I2S task mentioned before. Once the program has been written in a way that it will execute on, for example, a 50 MIPS processor, then regardless of modifications to other threads, this I2S thread will always meet its timing. The only way to break the timing is by not providing data at the appropriate rate. This is to be expected; if data is not provided at 48 kHz, then the codec cannot be given the data at 48 kHz, and something must break.

Software is not a panacea. Two obvious limitations are interfaces that require too much instantaneous bandwidth and hardware interfaces that need very short turnaround times. For example, it would not be feasible to write a multi-GHz SERDES in software on today’s processing hardware, but many commonly found interfaces can be formulated in software.

There are three reasons why a software implementation is preferable over a hardware interface:

1. Economics: It is not possible to provide all interfaces available as hardware blocks. A processor can model any type of interface as required.

2. Adaptability: An interface built in hardware is set in silicon. If a standard evolves, or if a particular device is not completely compliant or is required to perform some extra operations, then a silicon interface will not do the job. A software-defined interface can be adapted to meet the requirements.

3. Optimization: A software-defined interface can be optimized to address the problem at hand. Consider the EtherCAT application mentioned previously. If a hardware Media-Independent Interface (MII) is used, then the packet is stored and forwarded, which does not meet, for example, latency requirements. If the interface is defined in software, then the buffering requirements can be tailored to the problem.

The third reason is important, as many standard blocks dealing with UARTs, I2S, MII, and other standards must have built-in FIFO buffers to decouple the interface, and those buffers in many cases are unwanted because they add delay.

Once the designer chooses a software-based design flow, the possibilities are endless. Figure 2 shows a USB board that simultaneously supports an analog interface using a stereo I/O codec (over I2S), a differential digital interface (using S/PDIF), and a Musical Instrument Digital Interface (MIDI).

 

 

The embedded processor implements the USB stack and the audio-over-USB protocol. In this particular configuration, three audio interfaces are driven: MIDI, I2S/analog, and S/PDIF. The latter can be changed to a different protocol such as ADAT by a mere software change. More importantly, variations of the product can be made with different sets of interfaces, such as a multitude of coaxial outputs or I2S-based codecs. The software on the embedded processor can be tailored to the specifics of the interfaces with only minor alterations. There are no predefined numbers of each interface.

Flexible hardware can enable greater product differentiation, allowing developers and product managers to deliver distinguishable value to their customers. Concurrent real-time programming allows tight timing requirements to be guaranteed, with embedded processors such as the XMOS XCore providing the silicon and development tools required to take advantage of this programming method.

Henk Muller is principal technologist at XMOS Ltd.

XMOS Ltd. [email protected] www.xmos.com

Follow: Twitter Facebook Google+ LinkedIn YouTube Community forum