In Part 1 of our introduction to the RT600 crossover MCU, we examined the RT600 CPU/DSP core complex and its unique system memory architecture. In part 2, we will put a spotlight on some other unique peripheral features thatmake the RT600 standout as a high-performance audio crossover MCU.
Inter-processor Communications and Synchronization
Since there are multiple CPU cores in the RT600, it is important to have hardware support for Inter-Processor Communication (IPC). The RT600 includes a Messaging Unit (MU) which provides a hardware-based IPC mechanism. While It is possible to setup shared memory between the CM33 and the Hifi4 DSP, the MU offers a way to efficiently send messages/notifications between the processors with interrupt support. The MU is an important component to allow one CPU to wake up another when using power-down modes.
Figure 1. The RT600 Messaging Unit.
In addition to the MU, the RT600 includes a hardware enforced semaphore function. Both the CM33 and Hifi4 DSP have access to internal peripherals and memories. It is important to have mechanisms in place to ensure appropriate mutual exclusion. The semaphore unit implements 16 hardware enforced “gates”. A processor must write a special sequence to gain access to a hardware gate and to release its lock. The gates are generic in nature and can be used as needed by the software architecture to implement mutual exclusion on both peripherals and memory. Hardware support in the RT600 for IPC and semaphores make multicore processing simpler to architecture and implement.
RT600 Audio Peripherals
Processing audio streams is a key feature of the RT600. A proper audio “Crossover Processor” would not be complete without hardware peripheral support for common audio IO interfaces. The bread and butter of digital audio is the I2S protocol. I2S is the gateway into large ecosystem of high-quality external data converters, sample rate converters and audio transmitters (AES3/SPDIF). The RT600 includes eight multi-function “Flexcomm” serial peripherals. Flexcomm peripheral channels are reconfigurable for all the common serial protocols including USART, SPI, I2S and I2S. Each of the Flexcomm interfaces support four I2S channel pairs for a potential of 32 channel pairs available to the system. All the common digital audio modes are supported in the Flexcomm I2S peripheral including Left justified, Right Justified and TDM (Time Division Multiplexing) modes. The Flexcomm I2S peripheral includes an eight entry FIFO to ensure glitch-less audio streams.
For voice applications, the RT600 contains a flexible Digital Microphone (DMIC) subsystem. DMICs most commonly use Pulse Density Modulation PDM to encode audio data. A DMIC has no analog output, data is output digitally synchronous to a clock. The clock is supplied by the DMIC subsystem and its frequency is at a binary multiple (i.e. 64x) of the audio sample rate. DMICs are extremely popular replacement to older electret microphone technologies as they are small, can be built on a repeatable semiconductor process and have a direct digital interface. As an example, Knowles Acoustics manufactures DMICs for applications including voice and ultrasonic sensing.
Figure 2. Knowles Acoustic Digital Microphones.
PDM data streams require a digital filter and decimation to recover the audio waveform. The DMIC subsystem in the RT600 has the necessary hardware to directly connect and decode PDM data streams Up to eight microphones are supported with flexibility over decimation and sample rate control. Processing an acoustic array of microphones is now much simpler with the RT600!
Also included in the DMIC subsystem is a hardware voice activity detector (HWVAD). The HWVAD is dynamic envelope detector that can be used to trigger /wakeup processing functions when activity is detected in a digital audio stream.
Figure 3. RT600 Hardware Based Voice Activity Detector.
One last important component that I want mention (that is important to audio applications) is a dedicated Phased Locked Loop (PLL). Audio IO protocols always require a dedicated master clock that is at some binary multiple of the target sample rate. When using common audio sample rates such as 44.1KHz or 48KHz, the master clocks may not be aligned or easily derived from an internal MCU clock source. For example, it is common to observe a 12.288MHz or 24.576MHz master lock when working with 48KHz audio streams. The RT600 includes a dedicated PLL for audio applications.
Figure 4. RT600 Audio PLL.
General Purpose Connectivity and Timers
With all the dedicate hardware for audio and sensor fusion workloads, there is still a great deal of support in the RT600 for general purpose connectivity, timing and analog integration.
Figure 5. RT600 Connectivity, Timers and Analog Integration.
The RT600 has all the standard connectivity support you would expect including two SD/eMMC interfaces and high-speed USB. One aspect of NXP microcontrollers that I love are the plethora of timers! Two of my favorites being the State Configurable Timer (SCT) and the Multi-Rate Timer (MRT). I have previously written about interesting applications such as ultrasonic pulse pattern generation with the SCT and Modbus communication with an RS485 enabled UART and the MRT. The built-in analog system includes a 1MSPS ADC and analog comparator which can allow the RT600 to be used into interesting industrial applications that require sensor fusion.
I3C
One last unique feature of the RT600 is the addition of a MIPI® I3C interface. I3C is a super set of the classic I2C bus. I3C was developed by the MIPI alliance to provide an upgrade to the I2C for mid-speed applications. It is positioned as an alternative to SPI will keeping a simple two wire interface between devices on a PCB. It is widely expected that I3C will be a standard interface on many new sensors and peripheral components. Some notable features:
- Up to 12MHz clock rate. SDA and SCL lines use both open-drain and push-pull modes to increase data rate and allow bi-directional communications
- “In Band Interrupts”. A slave can interrupt a master over the bus without extra pins.
- Multi-Master/Multi-Drop
- Double data rate modes that offer transfer speed on parity with classic SPI
- Hot Joins. Nodes can join the bus at any time. Nodes get notifications when a new device joins the bus.
- Backwards compatibility with I2C.
- Dynamic Addressing
- In-Band Common Command Codes to standardize behaviors.
I3C is looking very cool and offers a unique blend of I2C and SPI capabilities. Be sure to get informed on I3C as you will see a lot more of it in years to come.
Next Steps with the RT600 – Hardware Design
I hope that I was able to get you interested in the RT600 crossover processor and its unique capabilities. My background in acoustics, audio and sensor fusion always steer my interests to parts with a diverse mix of capabilities. From my perspective, it is one of the most interesting MCU platforms currently available. I was only able to hit on the highlights and I hope you can find you way to the RT600 website to learn more.
In my next series of articles, I will be demonstrating how to bring up a simple hardware design with the RT600 in its 0.5mm pitch VFBGA176 package (don’t fret, it is easier than you think). We will look at all the basics in powering, clocking, and bringing up the device with a simple use case. I will even prototype the design and offer some demonstrations. From there we will look at RTOS support with Zephyr and some real-time audio processing demos. Stay tuned to learn a lot more about the RT600.
Links:
Crossing Over With the i.MX RT600 Part 1 of 2
Crossing Over With the i.MX RT600 Part 2 of 2
i.MX RT685 Hardware Design 1 of 3 - Power and Package
i.MX RT685 Hardware Design 2 of 3 - Flash Memory and Boot Configuration
i.MX RT685 Hardware Design 3 of 3 - The SuperMonkey Design
i.MX RT685 SuperMonkey QSPI Bringup with MCUXpresso and Segger J-Link
Creating a Custom Zephyr Board for the i.MX RT685 SuperMonkey