IRCAM - Centre PompidouServeur © IRCAM - CENTRE POMPIDOU 1996-2005.
Tous droits réservés pour tous pays. All rights reserved.

The IRCAM Musical Workstation: Hardware Overview and Signal Processing Features

Eric Lindemann, Michel Starkier, François Dechelle

ICMC 90, Glasgow (Ecosse), 1990
Copyright © Ircam - Centre Georges-Pompidou 1990


Abstract

The IRCAM Musical Workstation (IMW) is designed to facilitate experimentation with real-time signal processing and interactive musical composition and performance algorithms.The IMW's calculation engine is a general purpose multiprocessor based on the Intel i860 microprocessor. The calculation engine provides a unified platform for complex real-time musical event processing and signal processing. An overview of the calculation engine architecture is presented along with a discussion of the choice of host platform.

1. Introduction

Thc hardware architecture of the IMW is based on a high-speed multiprocessor providing sufficient number crunching power for non-trivial real-time musical signal processing and event processing. The multiprocessor consists of a number of processor boards (each with two Intel i860 processors) which plug into a host computer (a NeXT machine). The host is used for its graphic interface and file system. The i860s handle all real-time event processing and signal processing. A real-time operating system (CPOS/FTS) (Viara, Puckette [1]) has been designed which runs on the i860s. This papers describes the architecture of the multiprocessor.

2. Existing Architectures

Systems for real-time musical signal processing have typically been divided into a control section and a signal processing section (Lindemann [2], Moorer [3], Di Guigno [4]) . The control section may be an off the shelf personal computer or workstation in combination with one or more embedded real-time control processors (680xx,80x86, RISC, etc) The signal processing section is usually implemented in special purpose hardware, either a discrete design or one based on special signal processing VLSI. The signal processing section is usually programmed in microcode or extended assembly language. Various communications protocols are used between the host computer the embedded control processors and the signal processing engines

As a vehicle for experimentation this type of system can easily become unwieldy. There is generally a separate development environment which must be mastered for each of the processors in the system (host, control, signal processing). To implement a function a program must generally be written for each type of processor and these programs must be made to communicate reliably.

The complexity of this process tends to be discouraging to researchers, and limits the usefulness of the system. Generally research tends to be simulated on "standard" non-real-time systems and only when an algorithm is sufficiently proven is an attempt made to implement it on the real-time system.

3. The IMW - A Step Forward

As a result of experience with the types of systems described above, the following goals were deemed important for a new generation design:

1) Reduction of the number of types of processors and development environments in the system.

2) Minimization of specialized low level programming requirements (microcoding, etc.)

To reduce the number of processor types it is desirable to unify the roles of embedded control processor and signal processor. Until recently this has been difficult due to the lack of number crunching ability of available microprocessors. The recent introduction of the Intel i860 (Intel [5]), the first in a new generation of super-scalar processors, was important in solving this problem. Its 25ns cycle time, its ability to perform a floating point add, floating point multiply, and integer operation every cycle, its integrated caches and MMU make it ideal for vector/signal processing. Its general purpose RISC core make it well suited to general purpose scaler calculations as well. The i860 makes possible the unificalion of the real-time control and signal processing environments, turning a three Ievel system (host, control, signal processing) into a two level system (host, real-time).

4. The IMW Calculation Engine

The IMW calculation engine is implemented as a plugin coprocessor board for the NeXT computer. A block diagram of the board is shown in figure 1.

Each board has two i860 processors with up to 32 vfbytes of local dynamic RAM. Processors communicate by reading or writing each others RAM. Interconnection between processors on the same board is through a crossbar switch. The crossbar switch is arranged as two blocks each with four 36 bit (32 bit as shown in Figure 1) ports. Each block receives the full address of one of the i860s on one of its four ports. One block receives the least significant 32 bits of each of the two i860s 64 bit data busses on two of its four ports. The other crossbar switch block rcccives the mos significant 32 bits of each of the i860 data busses.

When an i860 reads or writes the local RAM of its neighbor processor on the same bord thcn 64 bits of data are passed directly through the crossbar switch blocks nd the address bus of the "mster" proccssor is passed out through the fourth port of the first crossbar switch block, into the fourth port of the second block and out through the address port of the "slave" processor. This connection provides no wait-state 50ns burst transfers (160 Mbyte/sec) between neighboring processors. The bus connecting the fourth port of the crossbar switch blocks also serves as a 32 bit address/dat multiplexed bus for l/O and off-board communications. This bus is connected to a Motorola 56001 DSP processor which is used as an I/O processor. It supports four bidirectional channels of serial digital audio at a 44.1 kHz sampling rate and an RS 422 serial port for MIDI and other controller interfaces. The 56001 also serves a DMA controller for burst transfers between the local memory of i860 proccssors on different boards.


Figure 1
The four-slot NextBus permits three dual-processor i860 boards to be plugged into the same machine alongside the host CPU board which occupies one slot. The NextBus is an extended version of the TI NuBus with a twice speed burst mode which permits 40ns 32 bit transfers. This gives a theoretical maximum transfer rate of 100 Mbytes/sec between cards on the NextBus. The practical rate after arbitration is somewhat less than half that.

Figure 2

In the future, a daughter-board option will be offered which will provide a high speed parallel interconnection path between NeXT machines. This interconnection scheme is shown in stylized form in Figure 2. In any machine each of three boards is connected to one of three boards in one of three other machines. Each one of these connections is the equivalent of a separate NeXT/NuBus. This connection scheme was chosen over a simpler single bus extender approach because of the added bandwidth it provides and because of peculiarities of the NeXT/NuBus bus address decode mechanism (NeXT [6]) which would have made it difficult to implement a single multi machine interconnect bus and still allow complete memory mapping of all the local RAM blocks into the physical address space of every i860 processor, a symmetry which we wanted to preserve. This connection scheme allows a maximum confiuration of twenty-four i860 processors with 760 Mbytes of memory.

References

[1] Viara, E. and Puckette, M., A Real-Time Operating System for Computer Music. Forthcoming International Computer Music Conference (ICMC) proceedings (1990).

[2] Lindemann E. - DSP Architectures for the Digital Audio Workstation Discusses the AudioFrame digital audio workstation. AES Preprint- 83rd.Convention (1987) New York.

[3]Moorer, J.A. - The Audio Signal Processor. Computer Music Journal, Vol 6, No. 3 Fall 1982.

[4] Di Guigno, Gerzso, et. al. - La Station de Travail Musical 4X - IRCAM 1986.

[5] Intel, i860 64-Bit Microprocessor Programmer's Reference Manual (1989)

[6] NeXT Inc., NextBus Interface Chip Preliminary Specification (1989)

____________________________
Server © IRCAM-CGP, 1996-2008 - file updated on .

____________________________
Serveur © IRCAM-CGP, 1996-2008 - document mis à jour le .