Industry Article

Understanding DSP Enablement Using NXP’s i.MX RT500 Crossover MCU

Learn about multi-threaded programs, developing applications using the XOS real-time operating system, resource sharing with semaphores, and how NXP's i.MX RT500 family of microcontrollers help engineers design DSP-enabled smart devices.

Today’s smart consumer devices require components capable of processing large amounts of data to meet the demands of various security and signal processing applications. These components (including microcontrollers) must be able to process that data quickly and efficiently, requiring highly optimized digital signal processors.

This article introduces some features of the Cadence® Tensilica® Fusion F1 audio processor, a designated co-processor that aids the main CPU of the i.MX RT500 MCU in performing signal processing calculations.


Core Concepts of Multi-Threaded Programs

At first glance, modern processing hardware creates the illusion that it executes many threads simultaneously. In reality, a single CPU core takes care of a single thread at a time. When the number of threads exceeds the number of available CPU cores, an operating system is needed to schedule the threads.

The OS needs to keep track of all started threads and their state, and it assigns CPU time slots to each thread so that various applications can run efficiently and seemingly in parallel.


Figure 1. The different states of a thread


The operating system scheduler maintains a queue for threads that are ready to run, a queue for blocking threads, and it needs to store information about the threads that are currently running to accomplish the fair distribution of CPU time:

  • Threads in the ready queue are currently waiting for the OS to schedule them on the CPU. Typically, the OS scheduler knows different priority levels, which it considers when choosing the upcoming thread to run on the CPU.
  • Blocking threads wait for an external event to happen, for example, a pin interrupt or a file operation. Scheduling these threads would mean that the CPU wastes processing power waiting for an external operation to finish. Once the blocking operation finishes, the associated waiting thread returns to the end of the ready queue.
  • The currently running threads might perform a blocking operation, or the OS might schedule a different thread according to its scheduling strategy. In that case, the scheduler will then move the currently running thread to the list of blocked threads or the end of the ready queue, respectively.

OS developers can choose to implement one or many different scheduling strategies depending on the exact requirements. Besides scheduling, synchronization and communication between different threads are other essential aspects of multi-threaded systems.


Conditions and Events in XOS 

Conditions within the XOS RTOS (real-time operating system) allow developers to instruct a thread to block until a specified condition becomes true. The system evaluates each condition using a condition function defined by the application developers. XOS performs an evaluation whenever another thread signals the condition object or when an interrupt handler triggers one.

Events within XOS, on the other hand, represent a group of bits that developers can utilize to synchronize different threads or threads and interrupt handlers. XOS allows multiple threads to wait for events and to signal them concurrently.


Interrupts in XOS

XOS offers a rich set of features for handling interrupts and exceptions that occur during runtime. The interrupt mechanisms within XOS offer programmers the flexibility to install custom handlers while ensuring that dispatching interrupts works as fast as possible within the system. The XOS also supports nested interrupt handling, which means that the OS pauses the current interrupt handler if a higher priority interrupts occurs. Once the system finishes handling the high-priority interrupt, it automatically resumes serving the low-priority interrupts.

Threads may also have time-related services such as timed delays and periodic timer callbacks in XOS. The DSP co-processor supports up to three internal timers that the programmers can configure as required.


Understanding Semaphores

In multi-threaded programming, semaphores provide a means to control and coordinate access to a shared resource. Semaphores help avoid critical section problems in concurrent systems by synchronizing different threads. Semaphores are a simple construct that keeps track of an internal counter with a predetermined starting value that the programmers can freely set in the source code. Different implementations exist, but the counter usually represents how many threads may still access a shared resource.

Whenever a thread wants to access the shared resource, the system checks whether the associated counter is greater than zero. If it is, the OS grants access to the resource and decreases the semaphore’s internal counter. If a thread may not access the resource at the given time, the thread switches to a blocking state and waits until it receives access to the resource. Whenever a thread frees the resource, the OS increases the semaphore counter, and a new thread may enter the critical section.


Figure 2. A flow-chart illustrating how semaphores work


An Overview of the i.MX RT500 MCU and the DSP

i.MX RT500 is a family of dual-core microcontrollers based on a powerful Arm® Cortex®-M33 core with a clock speed of up to 275 MHz and support for up to five megabytes of SRAM.

The i.MX RT500 MCU offers protection features such as Arm TrustZone and a built-in memory protection unit (MPU) with support for up to eight regions. The CASPER crypto co-processor enables hardware acceleration to boost various functions required for asymmetric cryptographic algorithms. A set of power-saving features allow designers match the power consumption of the i.MX RT500 to their application requirements.

Various dedicated hardware accelerators aid the main CPU in performing DSP calculations. An additional Cadence® Tensilica® Fusion F1 audio DSP, a 2D GPU with vector graphics acceleration, and various display interfaces make the i.MX RT500 suitable for various secure and low-power embedded applications. Typical use-cases include HMI applications, IoT devices, hearables, voice-activated personal assistants, and other similar consumer devices.


A Look at the Audio DSP

The i.MX RT500 contains various special co-processors that can help lighten the load on the CPU cores by performing mathematically complex calculations while leaving the processing cores free to perform other tasks. One such dedicated processor is the fusion DSP, which includes a Cadence® Tensilica® Fusion F1 audio processor and a hardware floating-point unit.

This audio processing engine runs at frequencies up to 200 MHz and is designed to enable always-on voice-triggered devices such as virtual assistants. Also, the audio DSP combines various modules for typical pre-processing and post-processing tasks using numerous audio codecs.

The DSP and main CPU cores can communicate with each other via various means. Developers can use the entire SRAM when working with the fusion DSP unless the RAM is protected and certain parts are marked for secure-only access.


Programming with the DSP in Mind

Tensilica DSPs support various real-time operating systems (RTOS), including FreeRTOS™, Zephyr™, Linux®, and XOS. Cadence developed the XOS embedded kernel as a reference design with Tensilica processors in mind.

The lightweight XOS kernel features include a task scheduler, adaptive context switching, synchronization mechanisms, interrupt and exception management, and critical resource management. The kernel’s source code is mainly written in standard C and not specific to Xtensa processors and DSPs.


Meeting Smart Consumer Device Requirements

The i.MX RT500 family of crossover MCUs has various features designed to inspire the smart consumer devices of tomorrow. The different co-processors aid the MCU’s main processing cores in performing mathematically complex calculations for security and signal processing applications. One such co-processor is the highly optimized Cadence® Tensilica® Fusion F1 audio DSP, enabling always-on voice-triggered devices such as virtual assistants. Programmers can utilize XOS and the Xplorer IDE to design applications for the dedicated Cadence processor.

The application note AN13159 contains further details, a list of supported API functions, and examples for conditions and events in XOS, and NXP’s website offers more information on the i.MX RT500 capabilities and applications. It also provides different training materials such as application notes, videos, and on-demand webinars.

Industry Articles are a form of content that allows industry partners to share useful news, messages, and technology with All About Circuits readers in a way editorial content is not well suited to. All Industry Articles are subject to strict editorial guidelines with the intention of offering readers useful news, technical expertise, or stories. The viewpoints and opinions expressed in Industry Articles are those of the partner and not necessarily those of All About Circuits or its writers.