Abstract: AI (Artificial Intelligence) data centers are driving the rapid evolution of optical modules from 400G and 800G to 1.6T, and a long-overlooked MCU (Microcontroller Unit) is evolving accordingly. Although it does not participate in high-speed data transmission, it handles tasks such as the CMIS protocol, firmware management, analog monitoring, fault protection, and device coordination. With the continuous addition of Flash, I3C, analog resources, and security features, optical module MCUs are showing a clearer trend toward specialization, software-defined capabilities, and integration. Meanwhile, CPO may alter the traditional "one module, one MCU" architecture, further migrating control functions into the Optical Engine and board-level management controllers.
Why Is an MCU Costing Just a Few Dollars Becoming Increasingly Critical?
AI data centers are pushing optical modules to an unprecedented upgrade pace. While 400G is still being widely deployed, 800G has become a key configuration for AI clusters, and 1.6T is beginning to accelerate into the next round of large-scale applications. Around this high-speed optical interconnect link, the chips that attract the most market attention are typically DSPs, EMLs, silicon photonics chips, TIAs, and Drivers, as these devices directly determine transmission rates, power consumption, and optoelectronic performance, and also represent the highest value portion of optical modules.
In contrast, the MCU is neither responsible for high-speed SerDes data processing nor involved in core optoelectronic conversion. In an 800G optical module valued at hundreds of dollars, the MCU typically costs only a few dollars or even less, accounting for less than 1% of the BOM. However, this unassuming chip undertakes another set of tasks: monitoring temperature, voltage, current, and optical power; configuring the DSP and peripheral devices; managing power and laser states; running the CMIS protocol and state machines; and handling firmware upgrades, exception alerts, and fault protection.
As optical modules upgrade to 800G and 1.6T, the requirements for MCUs are gradually increasing. The MCU must simultaneously increase Flash, RAM, ADC/DAC, and communication interfaces, while also shrinking its package, reducing power consumption, and improving fault response and reliability. New-generation high-speed optical module MCUs have begun to introduce Cortex-M33, dual-bank Flash, I3C, multiple analog peripherals, and smaller packages. The product definition is significantly different from the simple "housekeeping MCU" of the past.
For a chip costing just a few dollars, its system management complexity is rapidly increasing, becoming a key part of the architectural changes in next-generation optical interconnect systems.
From 800G to 1.6T, What Exactly Has Changed for the MCU?
If looking only at the data path, there seems to be no reason for the optical module MCU to undergo significant changes. Data from 400G, 800G, or even 1.6T does not pass through the MCU for processing; the devices truly responsible for high-speed signal processing are DSPs, SerDes, Drivers, TIAs, and optoelectronic devices.
In early optical modules, the MCU was closer to a typical "Housekeeping MCU." It collected module temperature, supply voltage, laser bias current, and Tx/Rx optical power, performed simple calibration, status reporting, and exception alerting, and then communicated with the host via I²C. Maxim's early DS4830A already embodied this approach: the CPU performance was not outstanding, but it integrated a large number of ADCs, DACs, temperature detection, comparators, and PWM resources. It can be said that optical module MCUs never won on "computing power" from the very beginning.
By the 800G and 1.6T era, this role has been further amplified. The number of DSPs, optical devices, and power rails that need to be managed inside the optical module is increasing, and the operating states and diagnostic data are becoming richer. Meanwhile, the module is still confined to compact spaces such as OSFP and QSFP-DD, and the PCB (Printed Circuit Board) area and thermal dissipation capacity do not increase synchronously with the transmission rate. Therefore, the MCU begins to face more complex systemic requirements.
The most obvious change first comes from CMIS. Early management interfaces focused more on basic status monitoring, whereas today's CMIS has developed more complex data path state management, diagnostics, fault information, and telemetry mechanisms. The CMIS 5.3 released by OIF continues to expand management capabilities, and subsequent evolution has even begun to discuss SPI, I3C, and Ethernet management interfaces, studying the migration from traditional register-based management to object/message-based management.
This means that the optical module MCU is increasingly becoming a "small embedded system" rather than a simple register reader/writer. The MCU needs to run state machines, manage the Memory Map, complete module initialization, switch between low-power and high-power states, and simultaneously handle firmware upgrades, fault recovery, and compatibility across different host platforms. The higher the optical module speed and the more complex the functions, the higher the weight of the firmware. Therefore, this round of upgrades is first manifested in a significant increase in Flash and RAM, rather than just an increase in CPU clock frequency.
The ADuCM451 launched by ADI in 2026 is a highly representative example. This MCU, explicitly targeting 400G, 800G, 1.6T, and higher-speed optical network modules, adopts the Cortex-M33 and is simultaneously configured with two sets of 1MB independent Flash and 512KB SRAM with ECC, while supporting multiple interfaces such as I²C, I3C, SPI, QSPI, and MDIO. Compared to the CPU itself, these peripheral resources are more noteworthy.
Changes in communication interfaces also illustrate this point. I²C has long been sufficient for optical module management, but with the increase in telemetry and configuration data, it is beginning to encounter efficiency issues. MIPI directly pointed out in its I3C technical documentation for communication equipment that as bus data volume increases, I²C speed is becoming a bottleneck; I3C SDR can run up to 12.5MHz while maintaining compatibility with legacy I²C devices, making it suitable for optical modules that require frequent access and high-speed telemetry.
However, this does not mean that I3C will immediately replace I²C. Existing optical modules, switches, and host platforms have a massive I²C ecosystem, and the industry migration will not happen in a single step. A more realistic trend is for new-generation MCUs to retain I²C, I3C, and even multiple interfaces like MDIO and SPI simultaneously, covering different customers and generational products with a single chip. The OIF is currently still in the evolution and discussion phase regarding the next-generation management physical interface, which itself indicates that the management bus for optical modules is not yet fully finalized.
Another easily overlooked change is that analog capabilities have not declined despite optical modules becoming increasingly "digitalized." Parameters such as temperature, voltage, Laser Bias, and Tx/Rx Optical Power still originate from the analog world, and lasers, TECs, and some optoelectronic devices also require DACs, PWMs, or closed-loop control. Therefore, ADCs, DACs, comparators, and voltage references remain critical resources for dedicated optical module MCUs. The ADuCM451 even integrates up to 16 external ADC channels, multiple DACs, and voltage comparators, while providing 3.3V, 1.8V, and 1.2V multi-voltage GPIOs.
The multi-voltage domain itself is also a result of the increased integration of high-speed optical modules. Traditional host management interfaces may still operate at 3.3V, but DSPs, EICs, and advanced digital chips are increasingly adopting 1.8V or even 1.2V I/Os. If the MCU can only support a single voltage, the module will need additional level shifters, which not only increases the BOM but also occupies valuable PCB area. High-speed modules are therefore turning the previously unassuming GPIO voltage configurations, small packages, and peripheral device integration into actual product competitive points.
Security features are also entering this round of upgrades. ADI's new products have added TrustZone, Secure Boot, hardware encryption, and random number generators. This does not mean that 1.6T optical modules already universally mandate complex information security features, but as firmware grows larger, field upgrades become more common, and optical modules gradually become manageable network nodes in large-scale AI infrastructure, firmware authentication and secure boot are transitioning from "optional features" to a new design dimension.
Therefore, if we compare optical module MCUs from the past decade or more, a very clear change can be seen: the upgrade of the CPU core from 8-bit, M0/M3 to M4/M33 is just the surface; what is actually growing much faster are Flash, RAM, communication interfaces, analog resources, security features, and software complexity.
What Is the True Barrier for Optical Module MCUs?
From the perspective of chip manufacturing processes, optical module MCUs do not require advanced nodes. The IP cores can be sourced from ARM, and other IPs such as ADC, DAC, I²C, and SPI are already highly mature.
When products begin to reach this level of specialization, a new question arises: Since IP cores can be purchased and mature processes are not scarce, why hasn't the high-speed optical module MCU rapidly homogenized?
In fact, the truly difficult parts are hidden precisely beyond these specification parameters.
The first threshold is the trade-off between analog resources and digital control. Although optical modules handle high-speed digital communication, they are essentially systems highly dependent on analog monitoring and control. Temperature, voltage, current, Laser Bias, and Tx/Rx optical power all require ADC acquisition, while lasers, TECs, and some optoelectronic devices may rely on DACs, PWMs, or comparators for control. Therefore, Optical MCUs have exhibited a distinct "mixed-signal" characteristic from a very early stage.
Taking Maxim's early DS4830A as an example, this product had only a 16-bit MCU core and 32KWords Flash, yet it integrated 8-channel 12-bit DACs, 26-channel ADC inputs, 10-channel PWMs, temperature detection, and comparators. Its design goal was to minimize external circuits to reduce costs and PCB area. By the time of ADI's ADuCM451 in 2026, this philosophy still exists, but the resource scale has expanded significantly: Cortex-M33, 2×1MB Flash, 512KB SRAM, multiple analog peripherals, various high-speed interfaces, and multi-voltage I/Os are integrated into a single chip, directly targeting 400G, 800G, and 1.6T optical network modules.
It is understood that there are currently three typical product routes for high-speed optical module MCUs:
The first is the highly analog-integrated dedicated MCU represented by ADI/Maxim, which reduces external chips through a large number of ADCs, DACs, comparators, and thermal control resources;
The second adopts high-performance general-purpose MCUs, with module manufacturers configuring external analog devices themselves. The advantage is a mature software ecosystem and a wide range of product choices;
The third lies between the two, adding necessary analog IPs, special interfaces, and small packages to general-purpose MCUs specifically for optical modules. Products from GigaDevice and Shanghai Belling are closer to this route. Shanghai Belling's BL32F512X integrates multiple ADCs, DACs, OPAs, and comparators, while placing 512KB Flash, 144KB SRAM, and CMIS support in the same product, positioning itself for 200G, 400G, and 800G high-speed optical modules.
It is difficult to simply judge which of the three routes is more advanced. The more analog IP is integrated, the lower the peripheral BOM and PCB area usually are, but the chip area, power consumption, and verification complexity will also increase; relying entirely on external analog devices can improve design flexibility but at the cost of space and component count. For today's 800G and 1.6T modules, where space is already extremely tight, what truly tests MCU manufacturers is actually their product definition capability—knowing which functions must be integrated and which are better left to peripheral devices.
The second threshold comes from firmware. This is very directly reflected in the recruitment needs of optical module manufacturers. The Firmware Engineer recruited by Samtec for 200Gbps/lane optical modules needs not only to develop low-level drivers for I²C, MDIO, ADC/DAC, PMIC, SPI, etc., but also to implement CMIS/SFF state machines and Memory Maps, handle Laser/TEC control, power-up sequencing, fault management, optical power and temperature closed-loop control, and cover complete module states such as Init, Low Power, High Power, Diagnostic, and Firmware Update. This has far exceeded the scope of "MCU driver programming."
High-speed optical module firmware is becoming the system software layer connecting DSPs, optical devices, power supplies, thermal control, and host management interfaces. Therefore, future competition among MCU manufacturers will likely gradually expand from the chip itself to: MCU + BSP/Driver + Bootloader + Firmware upgrade mechanism + Security + CMIS reference framework + FAE support.
But this does not mean that MCU manufacturers will take over the entire optical module software. Laser calibration, temperature compensation algorithms, DSP parameters, control strategies for different optical devices, and vendor-specific CMIS functions still belong to the core know-how of optical module manufacturers.
The third threshold is reliability and customer certification.
The MCU itself may account for only a small portion of the BOM for high-speed optical modules, yet it manages DSPs, lasers, and optoelectronic devices that are worth far more than itself. Once an I²C anomaly, ADC drift, Flash upgrade failure, abnormal power-down, or software deadlock at boundary temperatures occurs, the entire optical module may ultimately fail.
Therefore, customers rarely replace a validated MCU solely to save a few tens of cents. Re-conducting firmware adaptation, module validation, interoperability testing, and even end-customer certification often incurs engineering costs that are higher than the chip price difference. This gives optical module MCUs the inherent characteristics of a low BOM proportion, high certification costs, and high customer stickiness.
The fourth threshold comes from long-term mass production experience.
The Arm cores used by mature MCU manufacturers do not have fundamental differences, and many digital IPs also come from similar supply chains. What ultimately creates the gap is often the issues hard to see in the datasheet: whether boundary conflicts occur when different IPs operate simultaneously, whether I²C can run stably under high temperatures or strong interference, whether ADC accuracy drifts in actual board-level environments, how to recover from sudden power loss during Flash upgrades, and whether system state consistency can be guaranteed when switching between multiple voltage domains. The know-how in these design processes can often only be exposed after several generations of products, a large number of customers, and long-term mass production.
In the words of Jeff Cui, Senior Marketing Manager of the MCU Business Unit at GigaDevice: "Everyone is buying ARM cores, and everyone is either developing in-house or buying other IPs to build like Lego. The difference is that some people have been building Lego for two years, while we have been building Lego for many years. We are very clear that the connection between two specific Legos might have some hidden risks; this is an accumulation of many years."
Review of Different Optical Module MCU Suppliers
Currently, there are quite a few MCU suppliers claiming to target the optical module market, but not many can truly support 800G/1.6T and have entered customer validation or even mass shipment.
Theoretically, many 32-bit MCUs can perform temperature acquisition, I²C communication, and basic status management. However, for high-speed optical modules, products need to simultaneously meet larger firmware space, multiple analog resources, small packages, multi-voltage domains, and more complex communication and security requirements.
Maxim, acquired by ADI, launched the DS4830A very early on, a product explicitly named "Optical Microcontroller," targeting optical communication applications such as SFP+, QSFP+, and PON. Its approach is very typical: the CPU does not pursue high performance, but integrates a large number of ADCs, DACs, PWMs, and temperature detection resources in a single MCU to minimize optical module peripheral devices. By the time of the ADuCM451 in 2026, this logic still exists, but the product specifications have completely entered another stage: Arm Cortex-M33, 2×1MB Flash, 512KB SRAM with ECC, I3C, multi-voltage I/O, and Secure Boot are integrated. ADI officially positions it directly for 400G, 800G, 1.6T, and higher-speed optical network modules. It can be said that ADI represents a highly specialized, deeply mixed-signal Optical MCU route.
ST has not treated optical module MCUs as an independent product line but has directly brought the STM32 ecosystem into high-speed optical interconnect systems. The PIC100 targets single-channel 200Gbps PAM4 and can be used for 800Gbps and 1.6Tbps pluggable modules; meanwhile, the STM32H5 handles module configuration, monitoring, diagnostics, and system management. Since STM32 has mature software tools, a development ecosystem, and a long lifecycle, customers who already possess strong analog front-end and optical module design capabilities do not necessarily need to integrate all ADC, DAC, and control resources into a highly dedicated MCU. General-purpose high-performance MCUs combined with a mature software ecosystem can also form competitiveness.
GigaDevice is currently a strong representative in terms of publicly disclosed shipment base. During the 2026 Shenzhen Optical Expo, GigaDevice disclosed that its cumulative shipments of dedicated optical module MCUs have approached 100 million units. Its GD32E511/512 is explicitly targeted at 400G to 1.6T high-speed optical modules, adopting Cortex-M33, large-capacity dual-bank Flash, I3C, and analog resources configured for optical modules.
Shanghai Belling's early BL32F32x2 mainly covered optical modules below 100G, while the new-generation BL32F512X is explicitly expanding towards 200G, 400G, and 800G. The BL32F512X adopts the Cortex-M4F and integrates analog resources such as ADCs, DACs, OPAs, and comparators, essentially finding a balance between general-purpose MCUs and highly dedicated analog controllers.
Nations Technologies is a relatively active new player entering the high-speed optical module MCU competition in 2026. The N32H493 adopts the Cortex-M4F with a 240MHz main frequency, offering up to 1MB Flash, dual-bank, ECC SRAM, multiple ADCs/DACs, and a hardware cryptographic engine. It is officially positioned for 800G/1.6T optical modules; the next-generation N32H5 further plans M33, 2MB Flash, and I3C, targeting products above 1.6T. According to official materials, the N32H493 is already being "promoted for adoption" by leading domestic optical module manufacturers.
Nuvoton's M029G/M030G/M031G represents another type of traditional Optical MCU. Its products are explicitly targeted at optical transceiver modules, adopting Cortex-M0, 32KB to 64KB Flash, and integrating temperature sensors, multiple ADCs/DACs, and a 3×3mm small package; for higher-speed optical transceivers, Nuvoton recommends Cortex-M4 products such as the M471 and M485, adding dual-bank Flash and higher-speed I²C.
Based on the major competitive thresholds mentioned earlier by the author, the biggest challenge facing domestic MCUs in the optical module field remains reliability and customer certification, which still requires long-term accumulation over time.
Will CPO Make the MCU Disappear?
As pluggable optical modules transition to CPO, the position and form of the MCU will also face changes.
In traditional pluggable optical modules, the DSP, optoelectronic devices, power supply, Flash, and MCU are all located within a relatively clear module boundary. The MCU is responsible for CMIS management, status monitoring, firmware execution, and peripheral device control, basically forming a "one module, one controller" architecture.
CPO moves the Optical Engine closer to the switching ASIC or XPU to shorten the high-speed electrical connection distance, reduce SerDes loss and power consumption, and simultaneously splits the laser source, control, and management functions. A trend of controllers migrating into the Optical Engine can already be seen.
The 1.6T Silicon Photonics Light Engine demonstrated by Marvell integrates the Linear Driver, TIA, silicon photonics chip, as well as the embedded microcontroller and firmware into the same package. TSMC (Taiwan Semiconductor Manufacturing Company)'s COUPE is also advancing the 3D integration of Photonics Chips and Electrical Control Chips. The Electrical Control Chip here cannot be simply equated to a traditional MCU, but both solutions indicate that optical control electronics are getting closer and closer to the PIC, even becoming part of the Photonic Engine itself. This means that future control resources such as CPU cores, Flash, ADCs/DACs, and firmware may not continue to appear independently on the PCB in the form of a standard MCU.
On the other hand, the management scope of CPO systems may actually expand. With the adoption of External Laser Sources, a system may manage multiple Optical Engines and multiple laser sources simultaneously. In the ELS management architecture proposed by OIF, the Optical Engine is responsible for reporting the required optical power, the ELS reports its own capabilities and status, and it is the Host Board Controller that truly coordinates the two, controls the continuous-wave light source, and maintains connection relationships. Thus, the CPO control system begins to shift from the relatively flat single-module management of the past to a more obvious hierarchical architecture: the controller inside the Optical Engine is responsible for local monitoring and execution, the Host Board Controller is responsible for coordination among multiple optical engines and external laser sources, and the higher-level BMC or switch management system is responsible for overall machine management.
It can be said that CPO is not simply "moving" today's optical modules "next to the chip," but is redefining the boundaries between optical, electrical, control, and management functions.
Finally, the author believes that the most noteworthy trends for optical module MCUs in the next few years can be summarized into three points: specialization, software-defined capabilities, and integration. Following the rapid evolution of AI optical interconnects, the competition for optical module MCUs is entering a new stage: the ability to better understand system requirements under 1.6T, 3.2T, and even CPO architectures, and to write these requirements into chip definitions in advance, is becoming a new watershed.
