Theory of Operation#

System Architecture Overview#

The XVF3800 system subdivides into two major sections: a Control Plane and a Data Plane.

The Control Plane includes all control interfaces, related logic, and housekeeping functions. Control Plane functions have low performance requirements, relaxed timing constraints, and complex logic. The XVF3800 design uses a Real Time Operating System (RTOS) to distribute Control Plane functionality across xCORE tile boundaries.

The Data Plane includes all functions that handle audio processing. These functions have hard real-time constraints and operate isochronously. They generally pass their audio data using buffers. The xCORE processor package imposes a constraint on Data Plane functions receiving data from or providing data to an external source due to the number and width of ports connected to physical pins within the package. The XVF3800 operates the Data Plane functions bare-metal, i.e. without the help of an RTOS.

Both the Control Plane and the Data Plane consist of several modules.

Control Plane Modules#

The Control Plane includes the following modules:

  • Device Control (DC)

  • Device Firmware Update controller (DFU)

  • General Purpose Input and Output (GPIO)

  • Human Interface Device (HID)

  • Input Output Configuration (IO Config)

  • Inter-Integrated Circuit Master (I2C Master)

  • Inter-Integrated Circuit Slave (I2C Slave)

  • Quad Serial Peripheral Interface (QSPI)

  • Serial Peripheral Interface Slave (SPI Slave)

  • Servicers (SER)

Data Plane Modules#

The Data Plane includes the following modules:

  • Acoustic Echo Cancellation (AEC)

  • Audio Manager (AM)

  • Beamforming and Post-processing (BAP)

  • Customer DSP (DSP)

  • Inter-IC Sound (I2S)

  • Microphone Array (MIC)

  • Software Phase-Locked Loop (SW PLL)

  • Universal Serial Bus (USB)

Control Plane Module Responsibilities#

Device Control#

The Device Control module handles the transfer of control messages between a host and the device. It connects to the host control interface, e.g. I2C Slave, SPI Slave or USB, on one end and the command servicers on the other end. It routes a command and its response between the host control interface and the intended servicer for that command.

Device Firmware Update Controller#

The Device Firmware Update (DFU) controller processes DFU messages received from a host control interface, e.g. I2C Slave, SPI Slave or USB, and interacts with the QSPI Flash module to read/write to the external flash.

General Purpose Input Output#

The General Purpose Input Output (GPIO) module reads General Purpose Input (GPI) pins and writes to General Purpose Output (GPO) pins. These pins allow device interaction with buttons, sliders or knobs for input and Light Emitting Diodes (LEDs) for output. The GPIO module includes the logic to drive GPO pins using Pulse-Width Modulation (PWM).

Human Interface Device#

The Human Interface Device (HID) module allows the XVF3800 to operate as a human interface device according to the USB Human Interface Devices specification. Compliance with the USB HID specification allows host devices to interact with physical controls and indicators connected to the XVF3800 through the GPIO module such as buttons.

Input Output Configuration#

The Input Output Configuration module configures GPIO devices and an attached Digital to Analogue Converter (DAC).

Inter-Integrated Circuit Master#

The Inter-Integrated Circuit Master (I2C Master) module provides an XVF3800-clocked I2C data transport for DAC configuration.

Inter-Integrated Circuit Slave#

The Inter-Integrated Circuit Slave (I2C Slave) module provides an externally-clocked I2C data transport for receiving and responding to control commands including the Direction of Arrival command. The XVF3800 cannot include both this module and the Serial Peripheral Interface Slave module in the same build configuration.

Quad Serial Peripheral Interface#

The Quad Serial Peripheral Interface (QSPI) module provides a QSPI data transport for input and output to an attached QSPI Flash memory device. The XVF3800 uses this data transport during the DFU process.

Serial Peripheral Interface Slave#

The Serial Peripheral Interface (SPI) Slave module provides an externally-clocked SPI data transport for receiving and responding to control commands including the Direction of Arrival command. The XVF3800 cannot include both this module and the Inter-Integrated Circuit Slave module in the same build configuration.

Servicers#

A set of Servicer (SER) modules handle requests from the Device Control module to get or set controllable parameters. It also provides a response back to the Device Control module. Each Servicer handles a request either on its own or through an underlying resource. When using an underlying resource, each Servicer manages the associated control packet queue and ensures thread safety when modifying shared memory or altering a Data Plane module’s controllable parameter.

Data Plane Module Responsibilities#

Acoustic Echo Cancellation#

The Acoustic Echo Cancellation (AEC) module removes from the microphone signal the acoustic echos of the reference signal projected into the room by the loudspeaker.

Audio Manager#

The Audio Manager (AM) performs a number of functions. It collects individual samples from the microphone array and the reference signal source, and it assembles them into a block for further audio processing. It prepares the reference and microphone signals for acoustic processing by, for instance, changing the reference signal sample rate, amplifying either signal as required, converting them between integer and floating point format, and/or adding any necessary delay to synchronise them. It also includes an audio packing facility that allows the XVF3800 to send a selection of six 16 kHz signals which it time-division multiplexes into two 48 kHz I2S or USB channels.

Beamforming and Post-processing#

After the completion of acoustic echo cancellation, the Beamforming and Post-processing (BAP) module further enhances the audio signal through the use of a multi-beam beamformer, de-reverberation, generalised side-lobe cancellation, dynamic echo and noise suppression, automatic gain control, and application of a limiter.

Customer DSP#

The Customer DSP module includes two separate digital signal processing functions set aside to allow customisation of signals as desired for a particular product. The first function allows the customer to alter the reference signal before use by the Acoustic Echo Cancellation module and transmission over I2S. This function operates at the audio interface sample rate. The second function allows the customer to add processing after the signal emerges from the Beamforming and Post-processing module. This function operates at the internal audio processing sample rate. In it, the customer has access to all four beam signals produced by the BAP module and to the residual signals produced by the AEC module.

Inter-IC Sound#

The Inter-IC Sound (I2S) module provides an audio interface to an integrated processor which supplies the reference signal, consumes the processed audio signal, or both. It also includes an audio unpacking facility that allows the XVF3800 to receive the 16 kHz reference signal and four 16 kHz substitute microphone signals as two 48 kHz time-division multiplexed I2S channels.

Microphone Array#

The Microphone Array (MIC) operates four PDM microphones in either a linear or a square/rectangular configuration. It converts the sample rate of the microphone output to match the audio processing sample rate.

Software Phase-Locked Loop#

The Software Phase-Locked Loop (SW PLL) module enables the XVF3800 to synchronize the clock signal used by the microphones with the reference audio signal received via I2S or USB.

Universal Serial Bus#

The Universal Serial Bus (USB) module provides a USB Audio Class 2 (UAC2) interface to a USB host. The host supplies the reference signal, consumes the processed audio signal, or both. This module includes an audio unpacking facility that allows the XVF3800 to receive a 16 kHz reference signal and four 16 kHz substitute microphone signals as two 48 kHz time-division multiplexed USB channels. It also provides a control interface used by the Control Plane.

Product Configurations#

The XVF3800 supports two primary use cases:

  • Integrated device

  • USB accessory

The integrated device use case embeds the XVF3800 within a system that includes a separate, primary microcontroller. The primary microcontroller provides the reference signal to the XVF3800, receives the processed microphone signal from the XVF3800, and initiates any control commands sent to the XVF3800. It also provides all system functionality outside of the audio processing performed by the XVF3800.

The USB accessory use case embeds the XVF3800 within a system that connects to a USB host. The USB host provides the reference signal, receives the processed microphone signal, initiates any control commands, and provides all functionality outside of the XVF3800.

Interface variations for each use case appear in the table below:

Table 32 Use Case Interface Variations#

Interface Attribute

Integrated Device

USB Accessory

Control Protocol

I2C slave or SPI slave

USB

Data Bit Depth

32

16, 24, or 32

Data Protocol

I2S slave

USB and I2S master

Master Clock

Derived or Input

Output

All use cases support either a linear or a square/rectangular geometry of four microphones. Likewise, all use cases support either 16 kHz or 48 kHz operation of the data interface.

A system diagram for each use case appears in Fig. 37 and Fig. 38.

../../../../_images/XVF3800_system_diagram_INT_device.png

Fig. 37 XVF3800 Integrated Device System Diagram#

../../../../_images/XVF3800_system_diagram_UA.png

Fig. 38 XVF3800 USB Accessory System Diagram#

Module Placement and Interconnection#

The diagrams in this section show the location of the XVF3800 modules on the two tiles of the xcore.ai and the interconnections between them.

Note

These diagrams do not depict logical cores or channel interconnections.

One diagram is included for the USB Accessory (Fig. 41) use case. The Integrated Device use case supports a control data transport over either SPI or I2C, so two diagrams (Fig. 39 and Fig. 40) appear for it.

Integrated Device with SPI Control#

../../../../_images/02_XVF3800_location_diagram_INT_device_SPI.png

Fig. 39 XVF3800 Integrated Device (SPI control) Location Diagram#

Integrated Device with I2C Control#

../../../../_images/02_XVF3800_location_diagram_INT_device_I2C.png

Fig. 40 XVF3800 Integrated Device (I2C control) Location Diagram#

USB Accessory#

../../../../_images/02_XVF3800_location_diagram_UA.png

Fig. 41 XVF3800 USB Accessory Location Diagram#

Control Plane Detailed Design#

Control Plane Structure and Operation#

Fig. 42 shows the modules involved in processing control commands. In order to concentrate on their processing, it does not include Control Plane modules, such as the DFU controller, HID, I2C Master or QSPI, that are not directly involved with control command processing.

../../../../_images/02_XVF3800_control_plane_components_diagram.png

Fig. 42 XVF3800 Control Plane Components Diagram#

Fig. 43 shows the interaction between the Device Control module and a Servicer. In this diagram, boxes with the same colour reside in the same RTOS task.

../../../../_images/02_XVF3800_control_plane_device_control_servicer_flow_chart.png

Fig. 43 XVF3800 Device Control – Servicer Flow Chart#

This diagram shows a critical aspect of Control Plane operation. The Device Control module, having placed a command on a Servicer’s command queue, waits on either the Gateway queue or on the Inter-tile context for a response. As a result, it ensures processing of a single control command at a time. Limiting Control Plane operation to a single command in-flight reduces the complexity of the control protocol and eliminates several potential error cases.

Note

Since the Control Plane design requires the host application to poll read commands, limiting operation to a single command in-flight does not limit operation to a single read transaction at a time. For example, a host application may issue a read command to a particular Servicer, receive a status value indicating that it should poll the device for the completion of that read operation, issue a second read command to the same or a different Servicer, receive a status value indicating that it should poll the device for the completion of the second read operation, and then issue additional read commands for either operation in any order until they complete.

Control Protocol#

The XVF3800 uses a packet protocol to receive control commands and send each corresponding response. Because packet transmission occurs over a very short-haul transport, e.g. I2C or SPI, or as the payload within a USB packet, the protocol does not include fields for error detection or correction such as start-of-frame and end-of-frame symbols, a cyclical redundancy check or an error correcting code. Fig. 44 depicts the structure of each packet.

../../../../_images/02_XVF3800_control_plane_packet_diagram.png

Fig. 44 XVF3800 Control Plane Packet Diagram#

Packets containing a response from the XVF3800 to the host application place a status value in the first byte of the payload.

Data Plane Detailed Design#

Fig. 45 shows the activities within each Data Plane logical core.

../../../../_images/02_XVF3800_data_plane_activity_diagram.png

Fig. 45 XVF3800 Data Plane Activity Diagram#

The portion of the Customer DSP module that allows processing of the reference signal prior to use by the Acoustic Echo Cancellation module appears in the I2S logical core. The other portion of the Customer DSP module, which allows further processing of the audio produced by the Beamforming and Post-processing module, appears in the Audio Manager logical core.

The Software Phase Locked Loop module appears in the I2S logical core. The other Data Plane modules each appear in the logical core of the same name.