GB2594269A - Emulation software and a method of emulating behaviour of a device containing one or more DSP cores - Google Patents

Abstract

Emulation software 10, which emulates behaviour of a device containing one or more DSP cores, when running core firmware as software under test (SUT 20), comprises: a software interface to the SUT in place of the interface provided by the device, the software interface including definitions of core datatypes 30, and a simulation of storage 40 by the device; and a device simulation which is based on a device register map description 60. Also provided is software arranged to capture a sequence of configuration operations, sent by firmware configuring a device containing one or more DSP cores, and to convert them to a table of operations which can be loaded by the firmware in place of the configuration operations.

Description

EMULATION SOFTWARE AND A METHOD OF EMULATING BEHAVIOUR OF A DEVICE CONTAINING ONE OR MORE DSP CORES

The present application relates to emulation of a device containing one or more DSP cores.

Such devices include devices that have digital processing capability only (for example handling digital audio) and mixed-signal devices that include both analogue and digital processing capability. They include devices, often implemented as ICs, such as codecs (which encode/decode a signal for transmission/storage). They depend on a useful range of firmware programs running on them to generate their full value. For example, the embedded DSP core and firmware in an audio mixed-signal device may allow features such as ultralow-power always-on voice wakeup, ambient noise cancellation and karaoke. They also enable an eco-system of third-party developers developing and selling their own unique effects and processing. However, due to the relatively small size and limited resources of such devices, it is not a particularly friendly environment for developing and debugging DSP (Digital Signal Processor) algorithms.

Currently, many DSP cores have limited debug access built into them, which means that the debugging capabilities available to the developers are limited, particularly in respect to inspection and analysis of the current state and tracing and profiling of operations. The JTAG (Joint Test Action Group) standard has a dedicated debug port implementing a serial communications interface -accessing subblocks of ICs (Integrated Circuits). An in-circuit emulator (or, more correctly, a "JTAG adapter) uses JTAG as the transport mechanism to access on-chip debug modules inside the target CPU.

Through JTAG an IDE (Integrated Development Environment -a software application with e.g. source code editor, build automation tools and a debugger) can allow breakpoints to be set on particular instructions and memory and registers to be inspected, but there may be no way of creating conditional breakpoints or data watchpoints (both facilities developers on workstations are accustomed to), and it is difficult to set up particular failure scenarios to test and debug error handling.

Running on the codec/device itself also obviously requires the hardware to be present. During early development, hardware systems can be in very short supply, which can drastically limit the number of developers who can be active at any one time.

An Instruction-Set Simulator (ISS) is a simulation model, usually coded in a high-level programming language, which mimics the behaviour of a mainframe or microprocessor by "reading" instructions and maintaining internal variables which represent the processor's registers. An ISS may be, for example, based on auto-generated code from SynopsysC) ASIP Programmer. This provides emulation of memories and the instruction set decode, plus interrupts. It does not provide any emulation of device blocks outside the DSP core itself, so any software running within this simulator must either restrict itself to calculations alone or be modified to incorporate some code which reproduces the behaviour of the blocks it is using (which means it is not the same software as will execute on the hardware).

Running in the ISS goes part way to addressing the JTAG issues but is very slow and only covers the core itself -it does not allow interaction with the wider system such as the co-processors nor does it allow any simulation of multi-core firmware.

This makes developing and debugging firmware for cores a slow and tedious process. It also makes testing and debugging of drivers used to configure firmware running on such devices tricky, since it requires the hardware to be up and running and integrated into an environment such as a Linux test environment.

An alternative is generating a runnable C model for test harnesses (collections of software and test data configured to test a program unit by running it under varying conditions and monitoring its behaviour and outputs) using the System Verilog C generation. This emulates not just the visible behaviour, but the exact behaviour of the silicon design. Consequently, it runs extremely slowly. There is no need to reproduce this level of verisimilitude in order to test the software interaction with the chip -the only requirement is that the observed outputs match those which would be observed when running on the real silicon.

It is desirable to provide an improved way of simulating such device behaviour.

STATEMENTS OF INVENTION

According to a first aspect there is provided emulation software which emulates behaviour of a device containing one or more DSP cores, when running core firmware as software under test, SUT. The emulation software comprises a software interface to the SUT (in place of the interface provided by the device). This software interface includes definitions of core datatypes, and a simulation of storage. The emulation software also comprises a device simulation which is based on a device register map description.

The emulation can be used for debugging software running on the device, without the device itself being required. The emulation simply replaces the device.

Since the device simulation is based on a device description, the emulation is easily adapted to different devices, by using a new description.

The emulation software interface may also comprise a simulation of interrupt handling by the device. Interrupt handling is another important aspect for interaction between SUT and the device.

The emulation software may comprise emulations of hardware (sometimes referred to as silicon) blocks in the device (and outside the core). These blocks may include, for example, any accelerators and DMA streaming (for example a stream arbiter). A control block may be arranged to re-route accesses to the storage (memories, registers etc.) to the emulated hardware blocks using the register map description, to provide the device simulation. This control block may be a central control which handles the overall control of the emulation software, or part of a distributed control arrangement. A single control block (whether central or distributed) may be provided for all the control central to the functionality of the emulation software. The emulated hardware blocks may be arranged to update the state of the storage and to trigger signals to the SUT. In this way the device functionality may be reproduced.

Each of the emulated hardware blocks may include an external hardware interface, for communication with the other parts of the software. The emulation software may further comprise extension emulated hardware blocks. These provide extensions of the device's current functionality (not currently implemented in the core emulation code). These additional blocks may each include the external hardware interface and thus have the same format for interfacing with other parts of the software as the blocks currently within the device. This allows easy addition of blocks for silicon design that is not yet implemented, so the emulation can test designs before they are added to the device.

A control block (which may be the central control) is arranged to act as an interrupt multiplexer and controller and is arranged to output to the SUT interrupts produced from the signals from the emulated blocks.

A control block (which may be the central control) may be arranged to accept a device definition, which is used as the device register map description. This may be a simple textual definition but other formats are available. It may include, for example, definition of which area of memory is used for which functions of the device. It may also include information identifying the device, such as a device name and/or number.

A control block (which may be the central control) may be arranged to accept input data streams and route them to an emulated hardware block emulating the streaming hardware/DMA.

A control block (which may be the central control) may be arranged to accept input timing signals from the SUT. The timing signals may be routed via the same interface with the SUT as the interrupt handling. The control block may convert them to simulation timing ticks.

The emulation software may further comprise a library accessible by the SUT storing the definitions of core datatypes. The library (and core datatype interface) may be provided separately from the rest of the emulation module and linked into the SUT.

In one embodiment, the emulation software is arranged to capture a sequence of configuration operations sent by the SUT and to convert the configuration operations to a table of operations. This can allow reduction of the SUT code size.

The emulation software may be instantiated in any way preferred by the skilled person.

In one embodiment, the emulation software is incorporated into an instruction-set simulator. In this case, the SUT may be provided in a device-specific executable format and the instruction-set simulator may load in the device-specific executable and pass storage accesses to the emulation software.

In another embodiment, the emulation software is contained within a library which is linked against an executable form of the SUT. The SUT may be compiled by a workstation-native development toolsuite.

According to a further aspect, there is provided software arranged to capture a sequence of configuration operations sent by firmware configuring a device containing one or more DSP cores, and to convert the configuration operations to a table of operations which can be loaded by the firmware in place of the configuration operations. In a particular deployment scenario which is not limited to emulation, this may replace the general code in SUT which generates those operations with an auto-generated table-based implementation specific for that deployment scenario which results in the same configuration using less code space.

According to a method aspect, there is provided a method of emulating behaviour of a device containing one or more DSP cores, when running core firmware as software under test, SUT. The method comprises providing a software interface to the SUT (in place of the interface provided by the device). The software interface includes definitions of core datatypes, and simulations of storage, and interrupt handling by the device. The method further comprises executing a device simulation which is based on a device register map description.

The invention also provides software in the form of a computer program (or suite of computer programs) or a computer program product (or suite of products) for carrying out any of the methods described herein, and a computer readable medium having stored thereon (a) program(s) for carrying out any of the methods described herein. A computer program embodying the invention may be stored on a computer-readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

Although the aspects (software/methods) are discussed separately, it should be understood that features and consequences thereof discussed in relation to one aspect are equally applicable to the other aspects. Therefore, where a software feature is discussed, it is taken for granted that the method embodiments include a method step performing that feature, and if there is a method feature it is taken for granted that one or more programs are configured to cause a computing apparatus on which they are being executed to perform said method feature.

The invention also provides a computer program or a computer program product for carrying out any of the methods described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein.

A computer program embodying the invention may be stored on a computer-readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which:-Figure 1 illustrates the basic components of a DSP; Figure 2 is a block diagram illustrating a general embodiment; Figure 3 is a flowchart illustrating a method embodiment; Figure 4 is an overview of emulation software and its connections to SUT; Figure 5 is an overview of emulation software as used in an ISS; Figure 6 is an overview of emulation software as used in an IDE; and Figure 7 is a hardware diagram of a suitable implementation; DSP Core and Subsystem Fig. 1 shows an example DSP which is to be simulated, although the simulation is not limited in any way to the example shown. The DSP includes two data memories XM and YM which can be accessed in parallel. XM and YM both include memory XMEM or YMEM and an external memory interface, and XM includes registers XREGS. The DSP also has PRAM and PROM (PM) as program memory containing the program being executed, along with an external memory interface.

In this DSP, multiple data formats are supported including the basic 24-bit and 56-bit accumulator. Native support is provided for 48-bit double-precision calculations.

The core is designed for accurate, low-power, efficient audio processing and control. It is supported by a JTAG debugger as previously described. The interrupt controller is in communication with the core and XREGS and receives 24 IRQ (Interrupt Request) external interrupt lines and input from a watchdog timer. The timer is a configurable binary up counter generating a signal which is used by the subsystem to indicate a status change, generate an interrupt to the DSP or even reset the subsystem.

A memory protection unit (MPU) is provided for the core, with an MPU trace stack. The Memory Access Control or MAC arbitrates the three multiple-access memory address spaces -two data memories and a program memory -and is supported by configurable FFT, FIR and LMS accelerators which may access data and/or external memories.

User algorithms (the SUT) are for example programmed in C and using a host-interaction APL They may be loaded into and run on the core. The DSP core data path may implement maths and logic operations primarily for fixed-point data but support may be provided for integer operations. It is aligned to the types used in the C application layer, with a strict correlation between parts of the hardware (such as the registers, I/O etc.) and these C data types.

In this example and as shown in Fig. 1, the registers are mapped into an area of XM (XREGS). There are also a number of moveable "memory windows" which can be mapped onto any part of the register map to allow memory-mapped access to those registers. The basic purpose of the register map is to provide command, control and status communication between the SUT, the device blocks and the wider system.

For the wider system, all the core memory is also exposed to the system via the register map to allow the control to provide the initial configuration of the core and to communicate with the SUT via SUT-defined configuration areas within the core memory.

The streaming hardware supports data transaction between the memories in the core subsystem and the audio channels. It includes a number of transmission (memory to audio channel) and reception (audio channels to memory) channels and IRO ports.

Fig. 1 shows external communications for interrupts, JTAG, audio, external memory and bus communication using an AHB (Advanced High Performance Bus) interface.

Introduction to Simulation Embodiments

To address the deficiencies in the prior art in debugging SUT for devices such as the one described above, and to provide enhanced debugging capabilities that are not available on hardware, the inventors have developed an emulator (also referred to as a simulator) and an emulation (or simulation) of a device which can be used to develop and run firmware, for example in the developer's workstation-native IDE. This software/emulation can also be incorporated into a cycle-accurate Instruction Set Simulation (ISS).

The emulator is advantageously implemented in software and since it emulates the relevant hardware component of the device, it does not require connection to the device itself. In fact, it may simulate not only the DSP core itself, but also the surrounding hardware subsystem, for example, any accelerators in the device. It can also simulate blocks outside the subsystem if required.

The simulator may provide an interface to the software under test (SUT) which duplicates the interface provided by the hardware -such as the core memories with the device register map, the interrupts -and hooks into these to emulate the behaviour of a particular device. In some devices however, there is a separate register interface, which is not memory mapped and the simulator will then provide the corresponding software interface.

The simulator may allow developers to build and run core DSP firmware on their own workstations under their favourite IDE -such as Microsoft Visual Studio and Windows or Eclipse and Linux. It may alternatively give a representation of the hardware around the core when used with an Instruction-Set Simulator (ISS). In either of these arrangements, and in general, there are a large number of operations which could be reproduced for a more faithful emulation, but a great deal of benefit can come from just reproducing just a few key features.

GENERAL EMBODIMENTS

Invention embodiments may comprise a module 10 as shown in Fig. 2 which emulates the behaviour of a device containing one or more DSP cores, providing an interface to the SUT which replicates the interface the SUT would have to a real device.

The emulation interfaces with the SUT via representations 40 of the device's storages (such as memories including a loaded register map) and preferably also signals (in particular interrupt handling 50 and possibly also other signals such as timing signals).

These replace the basic communication with the firmware implemented by a device. The emulation also provides definitions of core datatypes 30 which are used in the device which is being modelled. The emulation module includes a device simulation which is based on a description of the device in the form of a register map description.

A corresponding method is shown in Fig. 2. In S10 the method provides a software interface to the SUT in place of the interface provided by the device, the software interface including definitions of core datatypes, and simulations of storage, and interrupt handling by the device. In step 520, the software runs a device simulation which is based on a device register map description.

SPECIFIC EMBODIMENTS

Fig. 4 is an overview of a specific embodiment, with an emulation module 10, storages 40, and interrupt handling 50.

In this embodiment, the emulation may provide the core datatype definitions as a library 30 containing implementations of the device base datatypes, such as integral, fixed-point and complex values, in a form which can be incorporated into the SUT, along with implementations of various intrinsic operations. In one instantiation, these datatypes include 16-bit, 24-bit, 32-bit and 48-bit integer types (signed and unsigned) which wrap on overflow, plus 24-bit and 48-bit integer types which saturate on overflow; 24-bit, 48-bit and 56-bit fixed-point types in multiple Q-formats; and compound types formed of paired 24-bit and 56-bit fixed-point types. Intrinsic operations may include modulo address operations for circular buffer handling, bit manipulation operations, minimum and maximum functions and so on.

The behaviour of the device, and the configuration of the various storages, blocks and signals, is configured based on a description 60 of the device which may be provided separately, for example loaded on initialisation and loaded into a control function 70 (which may be central or distributed). This allows the same module implementation to be used for multiple device designs.

When the SUT accesses the device storage, this is re-routed to emulations of the appropriate blocks which process the access. In response, these emulated hardware blocks 80 update the state of the device storage and trigger signals to the SUT to reproduce how the real device would react.

Input data streams 90 can come from test vectors supplied on the development machine, from other programs running on the machine (e.g. MATLAB), or from the peripherals on the machine (e.g. audio hardware). Output data streams 90 can be likewise sent to files, other programs running on the machine, or other peripherals on the machine.

Where configuration tools have a method of remote communication with a device, the emulation module can implement this remote communication protocol via configuration interface 100 to allow the configuration tools to configure and tune the SUT in the same way as on a real device. An example of such a configuration communication protocol is StudioBridge, which is a TCP/IP protocol which allows SoundClear® Studio and WISCETm to communicate remotely with a device within a handset or other development platform.

As part of its processing, the emulation module can output debugging information in various ways, for example as messages output to the standard output stream, to a log file of operations, or using any other known method.

This information can include: * Tracing of block operations, such as enabling and disabling, signals being generated, configuration changes being made * Warnings where configuration settings for a block appear incorrect -such as enabling a stream block which has not been configured with any input sources, or incompatible clocking configuration for different blocks * Flagging where operations access invalid storage, such as accesses beyond the end of available memory * Flagging accesses to uninitialised storage locations, which are often the source of subtle errors which can be difficult to diagnose on hardware Tracing accesses to storage, in particular to configuration elements such as device registers The emulation module can also be used to set up particular error cases which may not be possible or may not be repeatable on a real device such as: * Pre-initialising memory with specific patterns which are known to cause trouble, in order to detect access to uninitialised memory * Randomising the initial contents of memory * Generating error conditions in the emulated blocks, in order to test the error-handling of the SUT The new firmware communicates with simulations of storages 40. The storages would include any silicon element which can hold a value. In an exemplary implementation this includes several banks of memory (the XM and YM and described above), and the registers. They could also include external memory, static ROM or RAM, or even potentially hard drives. The data in the storage emulation is determined by its hard-coded startup value (if any -otherwise the initial value is indeterminate), the SUT and the central control, which is described later.

Accesses to device registers may be re-directed via a register map emulation, provided for example as part of the central control (which acts as a "switchboard" between the SUT and the emulated blocks) or potentially as part of the storages This emulation may serve several purposes: * Storing and returning the values currently in the registers * Modifying the register values according to the rules for the bits within the register design (as specified in the loaded device description), such as whether the bits are readable and/or writable, and whether writing a particular value will clear (e.g. write-1-toclear) or set (e.g. write-1-to-set) those bits.

* Providing a callback interface to the software blocks which emulate the blocks in the silicon, so that they can respond to register reads and writes appropriately and update the state exposed via the emulated register map and memories and/or trigger emulated interrupts.

Register maps and memories can both be considered as arrays of data backed by some storage. In the case of register maps, these arrays are sparse, and indexed by both address and name. Individual configurable elements, "register fields", map onto contiguous bits in the register map. They are smallest meaningful units of configuration.

There are two parts to both the register map and to the individual data elements within the register map. There is the definition, containing the static information about the device, and the live data, corresponding to the current settings which may be changed. Within the definition may be information such as the device name and revision, the number of bits per register, and the definitions of the registers and fields which make up the configurable elements within the register map. The register definition may contain a list of register fields, including name and start and end bits within the register These definitions may come from the SoundClearCD Studio or WISCETm device description, if these packages are used. The live data for the register map is a dictionary of configurable data elements. Each data element contains the current value for that element, along with a reference to the definition of that data element.

Interrupts 50 (and other signals such as timing signal 110) are also fed into/out of the new firmware.

The SUT interfaces with the library in any suitable way available to a person skilled in the art. For example, for "native" builds only, i.e. workstation-native builds where the developer is building in their favourite desktop build environment (such as Microsoft Visual Studio or Eclipse + gcc) and creating executables which can be run directly in Windows or Linux, the library may be provided as part of device support package. There are a set of header files defining the C++ classes which emulate the datatypes, along with the intrinsic functions and memory interfaces and a test harness API providing access to the emulated state for test purposes.

Here, some of the implementation may be pure inline code in the header files, and some may be included as part of an object library which is distributed with the device support package and linked against in the normal way.

The SUT sends a timing signal 110. For example a DSP core cycle tick or other suitable signal may be sent. There are other clocks, such as SYSCLK or 32K clock, which in some implementations may be derived from the DSPClock. In the hardware there may be a master clock and the DSPClock may be derived from that, typically using an FLL.

The emulated blocks 80 include any self-contained functional processing block.

Examples in the system described above may include the streaming hardware (DMA)(and its sub-components) for streaming audio into and out of the DSP core, the signal generation/routing/interrupt mechanisms; and the "accelerators", or coprocessors, such as the FFT (Fast Fourier Transform), FIR (Finite Impulse Response filter), [MS ([east Mean Square), dB<->linear (conversion between dB and linear values) and white noise generator/ Rand (random number generator). Different/fewer/more accelerators may be provided for different cores and applications. The accelerator blocks within the simulator may be wrappers around an accelerator library which contains emulations of the different accelerators, which are preferably bit accurate. Other functional processing blocks may be provided for the timer, a MIPS or other profiler for program analytics, trace and event buffers, and the I2C master for connecting to external devices over the I2C bus.

The emulated blocks may also include blocks within the device but external to the DSP core subsystem such as audio routing within the device, clocking control, GPIO control, sample-rate converters, format converters and any other suitable blocks for emulation.

The emulation module may provide an external hardware interface used by the signals and interrupts processing, streaming hardware/DMA and hardware accelerator blocks.

This may provide a common (code) interface format to all these blocks, for example taking into account simulation timing ticks and resets to simulate updates event, defining registers and fields of interest and accessing the register map.

The central control 70 provides the overall emulation functionality. It provides the interrupts to the SUT, has read and write access to the storages, and receives the timing signal from the SUT, a device definition and data streams. It can be configured using external configuration tools over a configuration interface. The control is referred to here as "central" but may be divided into a number of separate functional blocks (of code).

An interrupt may be handled as follows, taking the example of the stream processing, although an interrupt may also originate from an accelerator, or any other hardware block simulation. A signal from the streaming block is triggered. How it is then processed depends on the routing in an interrupt multiplexer function, for example in the central control (since this is part of the central functionality) or in a separate block. Any interrupt which has set that signal ID as its interrupt source will be notified that the signal has fired, and this then causes the appropriate bit in the pending interrupts to be set. This is exposed through a register. This step is additional to the direct notification via the current active interrupts, and is part of the interface provided to the SUT by the silicon. This allows the SUT to use an interrupt or a polling interface as desired. The emulation can also be interrogated via the test harness API in a native IDE for the current "active" interrupts, i.e. the set of interrupts which are pending and do not have the corresponding bit set in the mask register. This is checked by the instruction set simulator every cycle, or if in a native IDE may be checked by a test harness or directly trigger interrupts by calling the appropriate interrupt handler function in the SUT and that causes the appropriate handling within the auto-generated section corresponding to the instruction set simulation. When handled, the appropriate bit is "acknowledged" to the emulation, which clears the pending flag. Depending on the configuration and what has happened in the meantime, the interrupt may remain active after acknowledgement.

The simplest possible example of handling an audio stream 90 in the central control would be to take the stream, apply a gain value to scale the audio level, and output the scaled audio. Any sort of audio processing could be done here -boosting quieter sections, boosting or removing certain frequencies to improve the clarity of the received sound, applying the inverse of the background noise to the signal received from MP3 or phone to reduce the ambient noise heard by the user (often referred to as Ambient Noise Cancellation), detecting a wakeup trigger phrase such as "Hi Sin" or "Ok Google", etc. The central control may access one or more emulated blocks to carry out these functions.

The external configuration tools shown can be used for remote configuration of the SUT, via the emulation. In this case, the SUT defines an area of core memory set aside for configuration by the system (device). This memory is exposed to the user of the emulation through the register map, allowing the user to view, in a GUI, for example, parameters updated by the SUT (which could be anything -command handshaking, frame counts, current processing mode, time-points at which particular features have been identified, log messages, debugging information -as appropriate for the SUT), and to update configuration parameters in the SUT (such as model data for algorithms, gains, state changes, commands, and so on). Quite often a program or module is created within user configuration software (e.g. WISCETM or SoundClear0 Studio) which interfaces with the emulation via the configuration interface 100, handles the configuration and presents it to the user at a higher, more intuitive level.

The device behaviour is determined based on device data, populating a device definition in the form of a register map description, which is for example loaded from a file to provide the register map. The description can be extended to support any device simply by changing the register map description used and implementing emulations of any of the new blocks within that device. The register map description may be built into an executable or library for a specific device, but whether it is loaded from a separate file or built-in, it is derived from the silicon device data.

As will be appreciated from the above, the simulator can emulate multiple cores within the same subsystem in a full device emulation, simply by reproducing the capability of those cores. It can also emulate multiple subsystems, each with one or more core.

Reducing Code size of Embedded Firmware Embodiments may also provide a method for capturing significant configuration operations from a firmware image running in a particular deployment scenario and replacing the general code which generates those operations with an auto-generated table-based implementation specific for that deployment scenario which results in the same configuration using less code space.

These configuration operations would typically be when the SUT is carrying out its initial setup -configuring audio channels, registering its processing threads, etc. These operations are often implemented in a Hardware Abstraction Layer (HAL) of a Software Development Kit (SDK) which abstracts the basic register configuration interface available to the SUT from the device into a set of higher-level function calls. This implementation is generic with conditional code to handle all the different possible combinations and number of streams/channels/etc. The SUT will always set things up the same way, so from its point of view, the instructions to work out the configuration are overhead.

Embedded devices, such as a DSP core for audio processing, are extremely restricted in terms of resources, in particular memory. However, as mentioned previously, there is a continual desire to provide more functionality within the firmware running on the device.

This leads to a conflict between the functionality which can be implemented and the code space available for such functionality, and frequently functionality has to be sacrificed in order to make the code fit.

Previously, the firmware may have been hand-optimized for a specific deployment scenario by replacing generic code with register writes to achieve the same purpose.

However, this is difficult to debug, maintain, amend and reuse for another project because it is so specific to the project and written at such a low level.

In another prior art approach, the firmware can be partitioned into multiple sections or "overlays", which can be stored in data memory or downloaded by a control application when switching functionality. This allows more functionality to be written into the firmware but requires an explicit switching operation to use functionality which is not currently present in code memory, which takes time and cannot be used for operations which need to run concurrently.

Code-size reduction embodiments capture sequences of configuration operations sent to the core by the firmware, and then convert these to a table of operations which can be loaded by the firmware in place of the function or functions which generate those operations.

The capture process can be achieved in various ways, e.g. * Running the firmware within the emulation of the core disclosed herein, which can trace the configuration operations (however, this code-reduction aspect is not limited to the emulation) * Instrumenting the functions which perform the configuration operations so that they additionally output trace information when run on the core, either to memory or some output stream hardware such as an audio PCM stream * Adding debug hardware to the configuration channels of either the processor core and/or surrounding subsystem so that they additionally output trace information as above * Other ways of implementing such capture will be obvious to a practitioner skilled in the art The capture process can be started and stopped by a trigger such as a write to a known location or the change of level of a General-Purpose Input-Output GPIO (other similar triggers will be obvious to a practitioner skilled in the art).

The operation of generating the corresponding table of operations can be performed either at the point of capture or in a post-processing step.

The table of operations can be encapsulated in various forms: * A compilable file containing the actual code to perform the operations * A compliable file containing code to build up an array of structures, each entry of which describes a particular operation, accompanied by a function to decode the table and apply the operations * A binary or other format file which contains a sequence of operations in some appropriate format which the firmware can interpret in order to apply the operations * Other possibilities will be obvious to one skilled in the art One instantiation uses the emulation of the device described herein to capture the operations, process them inline and output a file containing code to build up an array of structures. This code is then compiled and the array is interpreted by a function which applies the operations so described.

More specifically, in one example, when the configuration is performed via a series of register writes, possibly with some checks on registers as necessary (typically to wait for the hardware to reach a particular state), code-size reduction embodiments may record these register operations during an instrumented run of the SUT which uses the normal SDK, and then output one or more code files which contain tables of the register operations.

The SUT may then compile in a different mode which replaces these calls to the SDK functions with calls to a function which processes one or more of these tables of register operations. Since this function is purely dedicated to processing the table and performing register reads and writes, and since the register operations are just those operations needed by this specific SUT, this results in more compact code than the generic code which it replaces. In experiments, about 800 words were saved for a typical firmware, which is quite significant when running on a device with a total of 8k words of program memory, as some smaller devices may contain.

This embodiment achieves most of the benefits of this hand optimization mentioned above without affecting maintainability by allowing the code to be written using best software practices and then updated in an automated, manageable, traceable way with the corresponding sequence configuration operations. This embodiment can work with partitioning, but also increases the effective amount of code space available thereby potentially avoiding the need to partition in the first place.

Project-specific Extensions Further embodiments add the concept of loadable extensions to the general device/processor core emulation, to allow project teams and third parties to add emulation of their own specific blocks for experimentation, early development and debugging, tracing and testing prior to or in parallel with hardware implementation.

The software emulation described herein allows firmware images targeted at a core DSP to run within an instruction set simulator (ISS) or emulation layer ("workstation-native") with the same behaviour and output as if they were running on the silicon.

The emulation may cover all or almost all of the standard blocks and hardware in the core DSP and subsystem. However, it may not include emulation of speculative blocks which projects might work on during development, and the roadmap for implementation of new blocks may give higher priority to blocks being developed for other projects.

This means that new development projects do not have control over whether or when their new IF is supported within the emulator.

It can also be desirable to trace the data through particular blocks/registers and the state changes during particular operations in order to assist debugging and/or validation.

Many prior art tools have the concept of plugins which allow third parties to provide additional functionality. For example: * WISCETM is a generic device configuration/tuning tool for Cirrus Logic devices. It supports plugins which allow projects (silicon or, more commonly, firmware) to provide project-specific tuning tools. These are aimed at providing additional tuning tools and configuration tools rather than extending the underlying functionality of the device.

* Adobe Photoshop has plugins which provide additional art tools or brushes. Again, these are extensions of the capabilities of the tool itself, rather than extending the functionality of a device emulation.

There are many others, but these are all aimed at extending the capabilities of the tool being used and are not used to provide early emulation of hardware development.

In another example of prior art, Verilog has a compiler which provides a C-code instantiation of the hardware being developed, allowing tests and software to be run against the emulation. Since this reproduces the whole device and a gate level, it runs extremely slowly, and it requires the output to have been developed in Verilog first rather than allowing quick experimentation. Also, it is all-or-nothing -extending the functionality requires adding the functionality in Verilog and then re-generating the whole device, rather than adding project-specific extensions to a generic emulation.

The extension embodiment provides a mechanism within the emulation library to detect and incorporate extensions which comply with a particular interface, and to instantiate them in response to particular conditions. These conditions may be based on the presence of particular registers or register fields, based on particular device IDs or other feature flags within the device, or unconditional. Further similar conditions will be obvious to a practitioner skilled in the art.

The extensions may be detected by specification in a configuration file, by location in a well-known directory, by registration via a well-known TCP/IP or UDP/IP port, by registration in the Windows registry, or by various other similar communication mechanisms.

The extensions may be deployed within a loadable module (for example a Dynamically Loadable Library, such as DLL on Windows or a.so on Unix), within a separate executable or script, or even within an executable on a remote machine, and may communicate with the emulation using local or remote procedure calls, through shared memory, through TCP/IP or UDP/IP channels or sockets, or through any other inter-process communication mechanism. The dynamically loadable library may expose a pre-defined interface and implement or consume the external hardware interface which forms the base of all the software blocks within the emulation.

The extensions may communicate with the emulation through this API which provides access to the emulated blocks within the emulator, and in particular to the register map and memories. The extensions can register to be notified when particular register accesses -read or write -occur, allowing them to process these accesses in the same way as the silicon (hardware) instantiation will. The extensions can also register for periodic notifications based on a certain frequency or number of cycles to emulate background or intermittent processing.

When the emulation starts up, it may scan a pre-determined location or set of locations for dynamically loaded libraries and try to load the initial interface from each one. This would allow the emulation to determine which such libraries actually are intended as extensions, and what the capabilities of that particular library are.

The external hardware interface may provide the interaction with the register map and clocks -for example, a module can register interest in accesses to particular named registers and receive a notification when the appropriate registers are accessed in that way. It can then process the access and update the state of the device/registers/memory and/or log/validate information if appropriate. The module can also register to be notified after a particular number of ticks of a particular clock (either one-off or repeatable), again updating the state of the device or logging/validating information/settings.

Extensions may be used for emulations of new hardware. They could also be used as test probes to track that the SUT is performing expected actions, or to trigger particular failure cases in response to a certain set of input conditions, or to log SUT operations to a file, or to emulate hardware inputs such as GPIOs. The full set of possibilities is only limited by the plugin developer's imagination.

Some simple extensions may, for example, carry out functions such as performing simple arithmetic operations in response to register reads and/or writes, reporting the current DSP cycle clock tick in response to a register read, triggering interrupts in response to register writes, or filling the emulated core memory with particular patterns in response to register writes.

Instantiation The simulator can be instantiated in several different environments. One instantiation is as a library (static or dynamic) which exposes the firmware interface (registers and memory) and the software blocks via APIs. Alternatively, the module may be a library directly linked into the SUT, communicating using function calls Another instantiation is within an instruction-set simulator (ISS) to allow the ISS to provide a more faithful reproduction of a device. This simulator can be cycle-accurate or instruction-accurate. This may provide an extended instruction set simulator for a core DSP, which may fully emulate a Core DSP and subsystem. The instruction set simulator may communicate with the simulated instructions to provide the behaviour of the device as part of a debugging suite; an example of this is the instruction-set simulator "checkers" which forms part of the Synopsys0 suite of development tools and works together with the ChessDE integrated development environment and debugger A further instantiation is linked into an emulation library such as a native emulation layer. This allows the firmware to be built and tested on the developer's workstation within their favourite development environment -for example in C++ in Microsoft Visual Studio or Eclipse.

The emulation module may be directly or indirectly linked into a test harness which controls both the operations being performed by the firmware -for example sequences of register accesses -and the responses of the device to verify the software's handling of specific device conditions which are difficult to force on a real device.

The emulation module may be within a pseudo-driver of an operating system, allowing testing of the operating system drivers' interaction with device firmware without requiring a device present.

The emulation module may be provided in some form of standalone executable, communicating with the SUT via some form of remote procedure call or other communication protocol The emulation module may be within an executable which communicates with device control software via some inter-process communication mechanism, such as shared memory, remote procedure calls, a TCP/IP or UDP/IP-based protocol (e.g. StudioBridge), http, ftp, etc A practitioner skilled in the art of software development could readily envision further similar environments Invention embodiments can also extend beyond emulation of a single OSP core or device to a device containing multiple cores or even a system containing multiple devices.

Instruction-set simulator (ISS) Instantiation This arrangement is shown in Fig. 5. The parts already shown in Fig. 4 are not described again here, for brevity.

In this instantiation, the firmware code (SUT) is compiled to a device-specific executable format, such as a.elf format suitable for deployment directly onto a DSP core on the real hardware The emulation module is incorporated into an instruction-set simulator such as checkers, which loads in the device-specific executable and interprets the device-specific machine code instruction-by-instruction using an instruction decoder in the same way as on a real device.

The instruction-set simulator passes the instruction decode clock to the emulation module for timing synchronisation. When the code on the device would access device storage elements, the ISS passes the access to the emulation module storages for processing, and returns the information provided by the emulation.

As part of the processing, the emulation module may generate device signals such as interrupts, and these are passed back to the ISS for processing as defined by the instruction set.

Where the device would provide data input or output streams, these are mapped into the emulated storages by the emulation module as described above.

The ISS can be controlled using the debug environment in the normal way, setting breakpoints, watching registers and variables, and so on.

Some benefits are specific to the ISS instantiation: * the exact same firmware image is being run as would run on the hardware, giving confidence that any results are representative * the firmware can be paused and device state be interrogated in exactly the same way as if running on the real hardware * the firmware can be paused, and any audio or other input and output streams also pause, unlike when running on the real hardware where such streams are transient * the SUT can be profiled by the instruction-set simulation, allowing precise indication of performance of the SUT on the hardware and identification of execution hot-25 spots Direct linkage Instantiation This arrangement is shown in Fig. 6. Again, the parts already shown in Fig. 4 and described above are not described here, for brevity.

In this instantiation, the firmware source code (SUT) is directly compiled by a workstation-native development toolsuite, such as Microsoft Visual C++ or gcc, and linked against a library containing the emulation module and the emulated datatypes and intrinsics.

In this case the resulting image is in a form which can run natively on the developer's workstation -for example a Windows executable -and the developer can run the firmware within the appropriate debug environment -for example Microsoft Visual Studio, gdb or Eclipse.

Benefits specific to IDE testing include the following: * Since this is a workstation-native executable, it runs significantly faster than the instruction-set emulation * The developer has access to all the advanced debugging tools of modern development environments, allowing for greater ease of debugging * the SUT executable can be integrated into a test harness which can o set up the emulated device blocks in particular configurations o run specific firmware sections o validate the resulting device configuration after running these firmware sections * the emulation can flag up serious errors by interrupting the debugger at the point at which the error occurs -for example interrupting the debugger at the point of access to an invalid memory location by throwing an exception. This takes the developer directly to the point where the error occurs, and allows them to inspect the full context at the point of failure. This greatly eases the debugging of the problem.

Hardware Implementation Fig. 7 is a block diagram of a computing device, such as a PC or data storage server], which embodies the present invention, and which may be used to implement a method of emulation as described herein and to execute the emulation software described herein, as well as the SUT and any of the other surrounding software, such as an IDE and/or an ISS. The computing device comprises a processor 993, and memory, 994. Optionally, the computing device also includes a network interface 997 for communication with other computing devices, for example with other computing devices of invention embodiments.

For example, an embodiment may be composed of a network of such computing devices. Optionally, the computing device also includes one or more input mechanisms such as keyboard and mouse 996, and a display unit such as one or more monitors 995. The components are connectable to one another via a bus 992.

The memory 994 may include a computer readable medium, which term may refer to a single medium or multiple media (e.g., a centralized or distributed database and/or associated caches and servers) configured to carry computer-executable instructions or have data structures stored thereon. Computer-executable instructions may include the code described herein for carrying out the invention embodiments, for example, instructions and data accessible by and causing a general purpose computer, special purpose computer, or special purpose processing device (e.g., one or more processors) to perform one or more the functions or operations as described herein to model the device. Thus, the term "computer-readable storage medium" may also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methods of the present disclosure. The term "computer-readable storage medium" may accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media. By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media, including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices).

The processor 993 is configured to control the computing device and execute processing operations, for example executing code stored in the memory to implement the various different functions of the module and the blocks described here and in the claims. The memory 994 stores data being read and written by the processor 993. As referred to herein, a processor may include one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. The processor may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processor may also include one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. In one or more embodiments, a processor is configured to execute instructions for performing the operations and steps discussed herein.

The display unit 997 may display a GUI including a representation of data stored by the computing device and may also display a cursor and dialog boxes and screens enabling interaction between a user and the programs and data stored on the computing device. The input mechanisms 996 may be part of the GUI and enable a user to input data and instructions to the computing device. For example, the GUI may display configuration options and allow the user to change those options.

The network interface (network I/F) 997 may be connected to a network, such as the Internet, and is connectable to other such computing devices via the network. The network I/F 997 may control data input/output from/to other apparatus via the network. Other peripheral devices such as microphone, speakers, printer, power supply unit, fan, case, scanner, trackerball etc may be included in the computing device.

The emulation module of Figs. 2 and 4 to 6 may be a processor 993 (or plurality thereof) executing processing instructions (from one or more programs) stored on a memory 994 and exchanging data with other programs executing on the same processor or elsewhere and if necessary via a network I/F 997. Furthermore, the processor 993 may execute processing instructions to store on a connected storage unit and/or to transmit, via the network I/F 997.

Methods embodying the present invention may be carried out on a computing device such as that illustrated in Fig. 7. Such a computing device need not have every component illustrated in Fig. 7 and may be composed of a subset of those components. A method embodying the present invention may be carried out by a single computing device in communication with one or more data storage servers via a network. The computing device may be a data storage itself the emulation module and potentially any other interconnected software.

Summary

Invention embodiments provide a software test bench containing a behavioural emulation of a device containing one or more DSP cores, where the behaviour may be driven by a definition of the device derived from the design data, and can be changed by changing the definition of the device.

Benefits of Invention Embodiments * The DSP firmware can be run in an environment which has more resources available, (such as the ISS on a developer's workstation) providing improved debugging facilities.

* The same tests can be run across a series of devices and in a series of environments simply by providing the descriptions of the devices, without requiring a bank of hardware platforms on which to run.

* Developers can all start developing against a device without requiring every developer to have their own hardware -particularly useful when devices are in development and there are only a few expensive FPGA (Field-Programmable Gate Array) implementations available.

* Firmware developers can even start developing for a new device based purely on the device definition, before there is even an FPGA available.

* Firmware developers can start to develop against features of the device due to be added to the silicon design later. For example if the simulator is available at the start of development before accelerators are added, it is possible to develop and test the firmware within the ISS containing the simulator and add the register definitions for an accelerator, such as a dB/linear converter to the device definition. Then the simulator will then instantly support it.

* Regular automated tests can run against every change to the hardware interface to determine whether it impacts the software, without even requiring the hardware to be instantiated.

* System architects can play "what-if" with different device options by generating a range of device definitions with these different options and evaluating the capabilities and/or performance of the firmware with these device options -adding and removing features to a speculative device and playing around with memory sizes or when adding or removing particular hardware blocks and seeing the impact on the firmware.

* The behavioural implementation of an IF block provides an independent implementation which can be used to verify silicon behaviour against requirements.

* The emulation environment can output a log of all the interactions with the chip, making reconstructing the sequence of operations which led to a problem far simpler.

When an error occurs, the sequence of configuration operations which led to the error can be reviewed.

* The emulation environment can validate the operations being performed and output a warning or error message if it looks like it might be an error. An example might be starting an audio stream master which has no channels assigned. This probably suggests a mistake in the configuration of the streaming hardware, but the only symptom would otherwise be a lack of audio which could have been caused in various ways.

* Since the data streams are coming from and going to files on the workstation, pausing the execution also effectively pauses the data streams, unlike on the real device where the data is being generated in real-time (consider speech) and hence will be lost if the execution pauses.

* The emulation can output information about the dynamic state of the hardware blocks as the execution proceeds, providing greater information for debugging error cases.

* The emulation can be configured with various hard-to-generate error conditions to test the firmware error-handling.

* The emulation can flag up dubious configuration states.

* The developer can run through a series of tests with different input test vectors and initial configurations to explore the behaviour over a range of conditions; this is particularly useful for regression testing or stress testing.

Claims (15)

1. CLAIMS1. Emulation software which emulates behaviour of a device containing one or more DSP cores, when running core firmware as software under test, SUT, the emulation software comprising: a software interface to the SUT in place of the interface provided by the device, the software interface including definitions of core datatypes, and a simulation of storage; and a device simulation which is based on a device register map description.
2. 2. Emulation software according to claim 1, wherein the software interface also includes a simulation of interrupt handling by the device
3. 3. Emulation software according to claim 1 or 2, further comprising emulations of hardware blocks in the device, wherein a control block is arranged to re-route accesses to the storage to the emulated hardware blocks using the register map description, the emulated hardware blocks being arranged to update the state of the storage and to trigger signals to the SUT to reproduce the device functionality.
4. 4. Emulation software according to claim 3, wherein the emulated hardware blocks each include an external hardware interface, and preferably further comprising extension emulated hardware blocks which are extensions of the device's current functionality and which each include the external hardware interface.
5. 5. Emulation software according to claim 3 or 4, wherein a control block is arranged to act as an interrupt multiplexer and controller and to output to the SUT interrupts produced from the signals from the emulated blocks.
6. 6. Emulation software to any of the preceding claims, wherein a control block is arranged to accept a device definition, which is used as the device register mapdescription.
7. 7. Emulation software according to any of the preceding claims, wherein a control block is arranged to accept input data streams and route them to an emulated hardware block emulating streaming hardware.
8. 8. Emulation software according to any of the preceding claims, wherein a control block is arranged to accept input timing signals from the SUT and preferably to convert them to simulation timing ticks.
9. 9. Emulation software according to any of the preceding claims, further comprising a library accessible by the SUT storing the definitions of core datatypes.
10. 10. Emulation software according to any of the preceding claims, wherein the emulation software is arranged to capture a sequence of configuration operations sent by the SUT and to convert the configuration operations to a table of operations.
11. 11. Emulation software according to any of the preceding claims, incorporated into an instruction-set simulator, wherein the SUT is in a device-specific executable format and the instruction-set simulator loads in the device-specific executable and passes storage accesses to the emulation software.
12. 12. Emulation software according to any of the preceding claims, contained within a library which is linked with an executable form of the SUT, wherein the SUT is preferably compiled by a workstation-native development toolsuite.
13. 13. Software arranged to capture a sequence of configuration operations sent by firmware configuring a device containing one or more DSP cores, and to convert the configuration operations to a table of operations which can be loaded by the firmware in place of the configuration operations.
14. 14. A method of emulating behaviour of a device containing one or more DSP cores, when running core firmware as software under test, SUT, comprising: providing a software interface to the SUT in place of the interface provided by the device, the software interface including definitions of core datatypes, and a simulation of storage, and preferably of interrupt handling by the device; and executing a device simulation which is based on a device register map description.
15. 15. A non-transitory computer-readable medium storing software as defined in any of claims 1 to 13 in the form of one or more computer programs.