DSP coprocessor having control flags mapped to a dual port section of memory for communicating with the host

A DSP coprocessor 2 is connected to a host sub-system (3). The host sub-system (3) has a host processor (4), a host RAM (5), and shared RAM banks (6, 7). Multiplexers (11) provide access for either the DSP or the host to a shared RAM bank. Macro commands for functions of the DSP coprocessor are retrieved from the shared RAM banks. This allows comprehensive interaction of the host and the DSP coprocessor.

FIELD OF THE INVENTION
 The invention relates to DSP systems, and more particularly to the manner
 in which DSP coprocessors are utilised.
 DSP coprocessors allow performance of a number of different operations
 within a single clock cycle. These operations typically include
 multiplication and accumulation, one or more data memory reads or writes,
 and incrementing address pointer registers. Typical applications are
 control of AC or DC motors, speech processing, vehicle engine knock
 detection, modems, frequency analysis circuits, and data communication
 equipment generally.
 While DSPs are very efficient for the specific tasks involved, they
 generally suffer from the problem of requiring a large degree of
 hand-optimised assembly language to achieve desired performance. This has
 arisen from the complex nature of such processors.
 OBJECTS OF THE INVENTION
 One object is to provide a DSP coprocessor which operates efficiently, and
 which may also be controlled in a flexible manner
 Another object is to minimise size and cost of a DSP system.
 SUMMARY OF THE INVENTION
 According to the invention, there is provided a DSP coprocessor comprising:
 an arithmetic logic unit;
 an address generation unit;
 a program control unit;
 means for addressing memory to retrieve instructions for a function
 selected from a library of functions; and
 activation means for receiving an external input macro command to activate
 a selected function.
 The addressing and activation means allow the coprocessor to operate
 independently after an external circuit or interface has activated a
 selected function. This provides excellent design and control flexibility.
 In one embodiment, the memory storing the library of functions is a
 non-volatile memory.
 In another embodiment, the program control unit comprises the means for
 addressing the memory storing the library of functions.
 In one embodiment, the program control unit comprises the activation means.
 In another embodiment, the activation means comprises means for addressing
 an external memory to retrieve the macro command.
 In another embodiment, the external memory comprises a shared random access
 memory which is accessable by a host processor.
 Preferably, the shared random access memory is mapped with a parameters
 section, and the coprocessor comprises means for reading initialisation
 instructions from the parameters section.
 In one embodiment, the shared access memory is mapped with a parameters
 section, and the coprocessor comprises means for reading locations for
 data and results from the parameters section.
 In a further embodiment, the non-volatile memory instructions are in very
 long instruction word (VLIW) format.
 In one embodiment, the program control unit comprises means for addressing
 programmable instructions in the shared random access memory. In the
 latter embodiment, the shared random access memory preferably has a
 partitioned section for instructions.
 In one embodiment, the program control unit comprises means for addressing
 programmable instructions in the shared random access memory and means for
 decoding the instructions.
 In another embodiment, program control unit PC values are within
 pre-determined ranges and the program control unit comprises means for
 determining the source of the next instruction according to the value of
 the PC. In the latter embodiment, the coprocessor preferably comprises
 means for determining the source of a next instruction, and missing a
 fetch operation in the current cycle if the source of the next instruction
 is from the programmable instruction section and the current instruction
 accesses the shared random access memory.
 In a further embodiment, the shared random access memory includes a dual
 port section and busy and bus request flags are mapped to said section,
 whereby a host may read or write a flag without affecting coprocessor
 operation.
 According to another aspect the invention provides a DSP coprocessor system
 comprising a DSP coprocessor as described above and a shared random access
 memory comprising means for allowing host processor access.
 According to a further aspect, the invention provides a DSP coprocessor
 system as described above and further comprising a host processor.

DESCRIPTION OF THE PREFERRED EMBODIMENTS
 Referring initially to FIG. 1, there is shown a digital signal processor
 (DSP) system 1 comprising a DSP coprocessor 2 and a host sub-system 3. The
 host sub-system 3 comprises a host processor 4, a host RAM 5, and shared
 RAM banks 6 and 7. Within the DSP 2, there is an address generation unit
 (AGU) 10, a bank of multiplexers 11, an arithmetic logic unit (ALU) 12,
 and a program control unit (PCU) 13. The interconnections of the
 multiplexers 11 is based on the architecture of each multiplexer having
 either DSP and host data inputs or DSP and host address inputs, and an
 output to a RAM bank 6 or 7. They provide access either for the DSP or the
 host to the RAM 6 or 7. The DSP architecture allows provision of one, two
 or any desired number of ALUs in a modular manner.
 The DSP coprocessor 2 operates at 100 MIPs. It has a 16 bit architecture,
 with a 40 bit accumulator. Its size is very much less than that of
 conventional DSP coprocessors. The dual memory architecture allows single
 cycle multiply and accumulate. The DSP coprocessor implements various DSP
 functions which are microcoded and are invoked by the host processor 4. In
 essence, the DSP coprocessor acts as a slave under the instructions of the
 host 4
 The microcoded kernel includes FIR and IIR filters, FFT, correlation,
 matrix multiply, and Taylor series functions. Additional DSP functions may
 be microcoded. However, an important aspect of the DSP coprocessor is that
 a comprehensive set of additional functions may be coded by the user into
 RAM. Such functions may be coded in the C language using an API to invoke
 the DSP coprocessor functions. C and Verilog models are provided to allow
 system simulation.
 The DSP coprocessor of the invention achieves a very high performance for a
 small silicon area. One reason is that it includes only the minimum
 circuits required.
 The RAM banks 6 and 7 are mapped with sections as follows:
 parameters,
 RAM data, and
 programmed instructions.
 The host writes instructions and data to the relevant RAM bank 6 or 7 to
 allow the DSP to perform the required functions. For the example of a
 correlation function of X and Y vectors, the instructions and data are
 written to the mapped parameters section of the RAM and include the
 location of the function instructions in other mapped sections of the ROM,
 the X data location, the Y data location, and the RAM data section
 location to which the result is to be written. The host then writes the X
 and Y data to the indicated locations. Subsequently, the host changes the
 value of a start flag to 1 and this is understood by the DSP as a start
 trigger. The start flag is located in the mapped RAM instruction section.
 Referring now to FIG. 2, a host coprocessor interface 15 is illustrated.
 The interface is via the shared RAM 6 and 7. A control bit MASTER is used
 to select whether the DSP coprocessor or the host has access to the RAM. A
 BUSY bit is used to indicate to the host if the DSP coprocessor has
 finished processing or is still busy. To simplify the interface these bits
 are memory mapped into location 0 of the RAM. Hence, no additional control
 lines are needed by the host. This location is implemented with dual port
 access so that the host can read the busy bit without taking control of
 the RAM (and stalling the DSP coprocessor).
 Both the host or the DSP coprocessor can read or write RAM[0] while the
 other has control of (and/or is accessing) the rest of the RAM. Also the
 host of the DSP coprocessor can simultaneously read RAM[0]. If the host
 and DSP coprocessor try to simultaneously write RAM[O] then the DSP
 coprocessor must stall. The control bits are tabulated below, in which the
 DSP coprocessor is named "FILU".

Bit FILU Host Action
 BUSY = 0 Read Only Read/Write None
 BUSY = 1 Read/Write Read Only
 MASTER Read Only Read/Write Control RAM
 RESET Read Only Read/Write Reset FILU
 The control lines are tabulated below, indicating arbitrates between the
 host and the DSP coprocessor.

EN FH_A0 Busy D0 Busy Action
 0 X X X Busy No Write
 1 F 0 X 0 FILU Can't Write to Busy
 1 F 1 0 0 FlLU Writes 0 to Busy
 1 F 1 1 1 FILU Writes 1 to Busy
 1 H 0 0 0 Host Writes 0 to Busy
 1 H 0 1 1 Host Writes 1 to Busy
 1 H 1 X 1 Host Can't Write to Busy
 Usually read/write control is via a single RWB (Read/Writebar) line or two
 separate lines for RD and WR. A mode line allows either mechanism. The
 following table sets out the logic for CS and RWB or RD/WR modes.

H_R
 Mode CS RD WR WB OE Action
 X 1 X X 0 0 RAM not
 selected
 RWB 0 X 0 0 0 Host Write
 RWB 0 X 1 1 1 Host Read
 RD_W 0 1 0 0 0 Host Write
 R
 RD_W 0 0 1 1 1 Host Read
 R
 RD_W 0 0 0 1 1 Shouldn't
 R Happen
 RD_W 0 1 1 1 0 Do Nothing
 R
 An important aspect of the DSP coprocessor is that the host may write a
 single macro command to the RAM instruction section, and this is
 interpreted as an instruction to activate one of a selected library of
 functions such as an FIR filter, a FFT Fourier Transform, or an IIR filter
 (infinite impulse response filter). For example, the correlation function
 above is activated by a single macro command. The library of functions is
 stored in a ROM of the PCU 13.
 This aspect of the invention allows very simple and powerful user control
 using an API. The DSP coprocessor performs the functions very efficiently,
 while the host-RAM interface allows excellent user control and
 flexibility. The coprocessor acts as a slave to the host.
 The software interface between the host and the DSP coprocessor is in two
 parts. The first part is a host API which allows the host to control the
 DSP coprocessor. The API functions are invoked using standard C function
 calls and they allow the host to:
 initialise the DSP coprocessor.
 read data from the DSP coprocessor.
 write data to the DSP coprocessor.
 load function parameters for the DSP coprocessor functions.
 call DSP coprocessor functions using C function calls.
 poll the DSP coprocessor operating status.
 The host API functions are tabulated below.

Function Name Description
 ResetFILU Initialises the DSP coprocessor.
 StartFILU Calls a DSP function.
 ReadFILU Reads data from the shared RAM
 WriteFILU Writes data to the shared RAM
 CheckFILU Status Determines the operating status of the
 DSP coprocessor
 LoadFILU Loads the DSP function parameters into
 the shared RAM
 Parameters
 The second part of the software interface is a run time library which is
 the set of DSP functions which can be executed by the DSP coprocessor.
 These include:
 an FIR filter.
 a first order IIR filter
 a second order IIR filter
 an N point in-place FFT, where N is radix 2 number and N.ltoreq.256.
 a correlation function.
 a Taylor series.
 These ROM functions are called using C function calls as macro commands.
 The functions are tabulated below. All of these functions are included in
 the C-Model. These functions are called by the host using API and executed
 in the DSP coprocessor.

R0 = *PP++; // Load X data pointer
 R1 = *PP++; // Load Y data pointer
 D0 = *PP++; // load correlation width
 R2 = *PP++; // load output data pointer
 A = 0L // clear A
 X = *R0++; // load X data point
 Y = *R1++; // load Y data point
 do {
 A = A + X*Y; multiply - accumulate
 X = *R0++;
 Y = *R1++;
 }
 while (D0--);
 *R2++ = A.A0; // save LSP
 *R2++ = A.A1; // save MSP
 *R2++ = A.A2; // save XP
 return;
 }
 R0, R1, R2, and PP are address registers and * indicates that the address
 register is used as a pointer. The sequence "//" denotes that what follows
 is a comment. The sequence "++" indicates an automatic increment when the
 operation is completed.
 "PP" denotes a parameter pointer. "A" denotes the accumulator value. In the
 first cycle, A stores the accumulation of the product of each X and Y
 element.
 Referring now to FIG. 3, the structure of the AGU 10 is described in more
 detail. R0 to R3 are pointers, and control of the multiplexer gives the
 current address. The selected address is fed back to the summation
 function. The PCU 13 initially transmits a value n, being the value to add
 to the fed back address for accumulation. Incrementing the value of PP
 allows progression through the parameters of the RAM bank 6 or 7. The N
 register holds the value of n, and allows indexed addressing. The M
 register allows modular arithmetic. The registers D0 and D1 are counters
 and are used for looping.
 The DSP allows user programmability without Flash memory. This is achieved
 by adding a sequence of instructions in the RAM mapped section. On the
 other hand the microcoded instructions are located in the mapped ROM
 section.
 Referring now to FIG. 4, the data path architecture is illustrated. A
 multiplexer 16 receives inputs from both a ROM 17 of the PCU 13 and from
 the RAM 6 and switches between these two. The RAM input is via a decode
 function ID. The multiplexer is controlled to output the relevant
 instruction by analysis of the output of the PC. As is clear from this
 diagram, only the RAM instructions are decoded. There is no need to decode
 the ROM instructions because they are in the format of very long
 instruction words (VLIWs). These are 30 to 60 bits wide, and in general
 are of any width required to achieve simultaneous control of a number of
 execution units in a single cycle. For example, where there are two ALUs
 and AGUs, the VLIWs have a width sufficient to control both ALUs and AGUs
 in parallel. The library of functions is stored in the ROM 17 in VLIW
 format.
 In more detail, the ROM instructions are executed very efficiently for
 efficient performance of the functions, while the decode circuit ID allows
 use of user-programmed instructions in the RAM 6 or 7. The ROM
 instructions are in VLIW format ie. words built up by concatenating
 several different control words which are wired directly to components
 such as the AGU, ALU, PCU, and registers to give full control of every
 unit in every cycle. These instructions are, in a general sense, performed
 without decoding. By this we mean that the only decoding involved is of a
 very minor nature for such things as processing a bit in an AGU control
 word to indicate status of the increment, or a 3-bit flag to indicate
 which of the five registers is to be updated. On the other hand, the
 instructions from RAM 6 or 7 are decoded and this is performed by the
 decode circuit ID. While they are therefore processed less efficiently
 than the ROM instructions, this is a small price to pay for the
 versatility provided by the facility to program "after silicon".
 Referring now to FIG. 5, the sequence of Fetch-Decode and Execute phases
 for ROM and RAM instructions are illustrated. The following are important
 aspects of instruction execution.
 As each instruction is fetched from ROM or is decoded from RAM, the VLIW is
 latched in a VLIW register.
 In each cycle, the instruction in the VLIW register is executed.
 In parallel, the DSP determines where the next instruction is to come from.
 This is achieved by monitoring the PC output and comparing it with
 pre-determined ranges.
 If from ROM, the instruction is fetched and written to the register.
 If the next instruction is from RAM, and the current instruction accesses
 RAM for its operation (e.g. a MOVE instruction) then the instruction is
 not fetched in this cycle, but is delayed to the next cycle. In the next
 cycle, the instruction is fetched from RAM and decoded.
 If the next instruction is from RAM, and the current instruction does not
 access RAM (eg A=0), then the instruction is fetched from RAM and decoded.
 Where the instruction is from RAM, it may be a macro command which
 activates a coprocessor function with the DSP coprocessor operating in a
 slave mode to the host.
 The above sequence is illustrated in FIG. 5 in which it will be seen that a
 Fetch is not performed in cycle 4 because the next instruction is from
 RAM. However, in cycle 8 a Fetch-Decode from RAM is implemented in
 parallel with an instruction execution because that instruction does not
 use RAM. This level of control is achieved because the value of the PC
 output can indicate precisely whether the instruction is from ROM or RAM.
 This is because the RAM is mapped with pre-defined sections for RAM
 instructions and for ROM instructions.
 This data path architecture is a combined Harvard von Neumann architecture,
 obtaining the benefits of both approaches. The VLIW instructions are very
 powerful and provide a high performance, and the RAM instructions allow
 post-production programmability which allows different applications.
 If all of the functions are written to ROM and the sequence of function
 calls and parameters are in RAM, then the sequence of FIG. 5 is an example
 of the code near the end of a function (in ROM) followed by an RTS to RAM
 followed by another JSR (jump to subroutine) to ROM. The expense of an
 additional cycle when executing from RAM is the same as with the
 von-Neumann architecture. The cost of the hardware is an additional
 multiplexer for the RAM address bus between the AGU and the PC and an
 additional multiplexer for the source of the instruction, between ROM and
 RAM. This is a very small price to pay for the considerable additional
 flexability provided by the ability of the user to program in RAM.
 One factor which allows a low gate requirement for the DSP is the fact that
 only a minimum subset of the instruction set must be supported from RAM.
 Thus, only a very simple decode is required. These are ALU, indirect
 addressing, and jump instructions. The full instruction set can be divided
 into four basic types. These are move indirect, move direct (including
 immediate), ALU, and control.
 Also, only three simple addressing modes are supported. These are no
 increment, post-increment and post-decrement. However, it is envisaged
 that the DSP may include post-increment by n.
 FIG. 6 illustrates an example instruction encoding with 16 bits which
 allows immediate, move direct, move indirect, ALU and control
 instructions.
 The invention is not limited to the embodiments described but may be varied
 in construction and detail within the scope of the claims. For example,
 the DSP coprocessor may receive macro commands other than via shared RAM,
 such as via a parallel port. Also, the library of functions may be stored
 in a volatile random access memory which is dynamically loaded.