EDN Network

Unintended fluids dripping from above? Accumulating from below? The T300 alerts you to them all. And mysteriously threaded contacts suggest other uses, too.

Back in March, I covered the activation and ongoing usage impressions of three interrelated TP-Link smart home devices: the Tapo H100 smart hub:

display-inclusive Tapo T315 hygrometer:

and Tapo T300 smart water leak sensor:

Toward the end of that March piece, and reiterating a quote I’d initially included in a mid-May follow-up post, I wrote:

I’ve also got a redundant Tapo H100 smart hub and T300 smart water leak sensor, both sitting on the shelf, queued up for teardown, along with a display-less sibling of the T315 hygrometer, the Tapo T310 Smart Temperature and Humidity Sensor:

The Tapo T310 was tore down and analyzed within that same mid-May writeup, with the teardown of the Tapo H100 predating it in late April. And now, in early July, we’re completing the dissection triumvirate with the spare Tapo T300, which I as-always aspire to return to fully functional form post-disassembly for ongoing leak-monitoring use somewhere in the residence.

Revisiting past history

You already saw a set of box and other real-life shots for the sibling Tapo T300 in the initial mid-March entry in this series (assuming you read it, that is); that particular unit now resides at the base of my downstairs water heater. The “dumb” leak sensor previously at that location now sits below the also-downstairs whole-home water filter; another is at the back of my icemaker-augmented combo refrigerator/freezer in the kitchen.

As usual, I’ll start out with some outer box shots, also as usual accompanied by a 0.75″/19.1 mm diameter U.S. penny for size comparison purposes.

This last image of the bottom of the package reveals (among other things) the hardware version (v1.6, succeeding the original v1, as well as with its own v1.8 successor) and serial number:

The hardware version matches that of the Tapo T300 currently in use, although serial numbers differ (of course). Here’s a revisit of the associated box-bottom shot you saw in March:

Open sesame

Let’s see what’s inside:

starting with a sliver of quick-start literature (PDF…here are the accompanying full user guide and datasheet) and some protective foam:

Here’s our patient, still swathed in a translucent protective sleeve:

And now unclothed, once again echoing sibling-device images you saw back in March:

As before (referencing the packaging photos), with the exception of this bottom shot:

versus this differing-serial-number vantage point of the in-use sibling device:

in both cases (and in contrast to the bottom-perspective packaging precursors) now including the always-informative common FCC ID (2AXJ4T300).

The Tapo T300 comes already battery-equipped, as you’ve probably already ascertained from the translucent strip of plastic that begs for removal prior to first-time use, but a power-source swap will sooner-or-later be necessary (“up to three years” before replacement is the claim). The removal of two screws should gain us access to the battery compartment:

Toldja so (there’s two AAAs/LR03s inside):

Next up, four screws, one in each corner, this time with hex heads:

We have liftoff

And with them removed, the two sections of the case separate straightaway, with no further implements of destruction or elbow grease required:

The inside of the bottom portion is largely unmemorable. Nice gasket, though, for likely-already-obvious liquid-intrusion-prevention purposes (IP67). Speaking of liquids, note the four metal pass-throughs, one on each corner, originating with the bottom-side contacts you saw earlier:

The other, larger portion is much more interesting (IMHO, at least):

Leak warning-sound transducer aka “buzzer” (claimed 90 dB!) on the side:

Let’s get that PCB outta there. Removing two more screws should do the trick:

That’s what I’m talkin’ about:

Toward the right are a pair of additional feed-through contacts from the top, intended to catch drips coming from above (vs. already-pooled fluids from below in the prior four-contact case). In the middle is a visible-light pass-through originating at the multi-color multi-function status LED, which I’m betting we’ll see shortly. And at left is the mechanical button portion of the topside control switch. The buzzer on the side, fed by the red-and-black two-color wiring harness, you’ve already met, right?

Simply simple

Now for the PCB itself, beginning with the bottom side, you’ve already glimpsed in past shots.

The proximity contacts for the previously pointed out bottom-side contacts are in the corners, labeled P11-P14. Two of the four battery terminals are here; you might have already noticed that the other two are attached to the case itself. And although at first glance, I’d thought the sizeable cylinder on the left edge was an electrolytic capacitor, the “L323” PCB marking next to it suggests otherwise (analog experts: is this what’s known as a “radial inductor”?). Note, too, that the D6 diode site below and to its right is unpopulated, seemingly, unless my eyes are playing tricks on me.

Now for the more interesting (IMHO) topside (which, bafflingly, is screenprinted “BOTTOM”):

Dominating the landscape at left is the PCB mounted portion of the aforementioned control switch. Below and to its right is a sixteen-lead square IC labeled as follows (I “think”…the “S” and “5” symbols aren’t distinctly different):

300A
S906
S15

Readers’ suggestions as to its identity and function(s) are welcomed. My bet is that, as with the Tapo T310 Smart Temperature and Humidity Sensor, it’s another obscured-marking CC1 series-variant of Texas Instruments’ MSP430 embedded controller family, for (among other things) “Sub-1 GHz dual-band” wireless connectivity. More on that connectivity bit in a moment.

Above and to its right, and at the PCB center, is the status LED. To its right is another, larger IC, this one more easily identifiable; it’s the same Cmsemicon BAT32G135GE application processor that I’d found in the earlier Tapo T310 Smart Temperature and Humidity Sensor teardown. To its right are two more landing pads, labeled T9 and T10 and this time corresponding to the earlier noted topside-located drip-sensing contacts.

And above the entire circuitry assemblage is ANT5, the embedded antenna for the company’s proprietary ultra-low power wireless protocol. Since this application’s data rate (as with hygrometry) is low, unlike with a smart camera (for example), additional Wi-Fi connectivity isn’t necessary in this case.

Speaking of sides, I’ll wrap up for today with four more PCB perspectives related to its backside, since that’s where the bulk of the “vertical” parts are located.

Along with one other tidbit that I came across during my research. You might have already noticed that two of the four contacts on the bottom of the device aren’t solid; instead, they seemed to have unfilled (not to mention M2 screw-threaded) centers. You’d be spot-on with that observation, although nothing I’ve found in the product documentation explains why.

Well, this guy (or gal; dunno) used them to transform the Tapo T300 into a door open/close sensor. If it wasn’t already obvious, the Tapo T300 doesn’t directly leverage a moisture sensor, as a hygrometer does (for example). Instead, it detects normally absent current flow between any of the three paired sets of two contacts, interpreting that conductivity as evidence of fluid presence. The switch used in this creative design derivation, in its “closed” position, generates the same current flow. And this same concept can also be employed for other purposes. Nifty!

Over to you for your thoughts in the comments!

—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.

Related Content

• The Tapo Hub: TP-Link joins the low-bandwidth, long-range RF club
• Smart hygrometers: Still largely useful even without integrated visual monitors
• TP-Link’s Tapo H100: Smart sensing unencumbered
• Tapo or Kasa: Which TP-Link ecosystem best suits ya?

The post TP-Link’s Tapo T300 sensor detects water and other liquid-leak dangers appeared first on EDN.

Artificial intelligence (AI) may dominate today’s conversations about smart cities and autonomous mobility, but beneath the pavement lies a technology that has quietly kept traffic flowing for decades. Inductive loop detectors (ILDs)—simple wire coils paired with reliable electronics—continue to deliver dependable vehicle detection, enabling adaptive traffic lights, toll systems, and roadway monitoring.

In a landscape buzzing with AI-driven vision and radar, ILDs stand out as the proven, resilient infrastructure that provides clarity and consistency, reminding us that not all progress depends on novelty—sometimes it rests on steady signal amid the noise.

Applications of inductive loops

In principle, an inductive loop (or induction loop) is an electromagnetic detection system that uses a moving magnet or an alternating current to induce an electric signal in a nearby wire. They are widely applied in transmitting and receiving communication signals and are also integral to hearing-assist devices, where audio signals are magnetically transmitted directly to compatible hearing aids, improving clarity in public venues such as theaters, lecture halls, and places of worship.

Inductive loops also play a crucial role in vehicle detection—embedded beneath road surfaces, they sense the presence of cars and trigger traffic lights or vehicle presence indicators. In addition, they serve in metal detectors and other object-sensing applications, but their impact on accessibility and traffic management makes them especially vital.

The rest of this post deals with inductive loop vehicle detectors.

Inductive loop vehicle detectors

Among current vehicle detection technologies, the inductive loop system remains the industry standard due to its optimal balance of performance, reliability, and cost-effectiveness.

At their core, inductive loop detectors operate by sensing changes in inductance when a metallic object disturbs an electromagnetic field.

This field is generated by a cable loop embedded directly into the roadway; as a vehicle passes over, it alters the coil’s inductance, triggering a detection signal. These systems provide the essential control logic for automating infrastructure, such as operating gates and traffic barriers, managing signal timing at intersections, or dispensing tickets in parking facilities.

Figure 1 A vehicle induction loop presence detector triggers gate mechanisms and logs traffic data for access management. Source: Roger Trade Centre

The system comprises two primary components: the sensing element and the electronic module. The sensing element consists of a wire coil buried within the pavement and a lead-in cable with the loop’s specific geometry defining the boundaries of the detection zone. The electronic module connects to this loop to monitor electromagnetic changes that indicate a vehicle’s presence.

Once a vehicle is detected, the module processes the resulting data according to its specific programming. This information can be acted upon immediately to trigger traffic signals or automated gates, stored locally for subsequent traffic pattern analysis, or integrated as a critical data point into a larger, networked management system.

Furthermore, the physical installation of the sensing element requires a saw cut, which involves milling a narrow groove—typically 1 to 2 inches deep—directly into the asphalt or concrete. Once the wire coil is laid within this channel, the slot is filled with a specialized loop sealant to protect the hardware from moisture and traffic-induced stress.

While this method enables precise placement and easy retrofitting on existing roads, the integrity of the saw cut is vital. Any degradation in the sealant or shifting in the pavement can lead to wire breakage, resulting in system failure or “ghost” detections.

Figure 2 A basic sketch illustrates an inductive loop vehicle detector system. Source: Author

More inductive loop vehicle detector essentials

Over the years, engineers have experimented with various inductive loop geometry configurations to optimize vehicle detection. While early designs were constrained by the limitations of rudimentary electronics, modern technological advancements have rendered many of those barriers obsolete.

This evolution necessitates a reevaluation of traditional standards to accommodate the sophisticated configurations now in widespread use. Today, selecting the ideal geometry requires a comprehensive analysis of site-specific parameters, including adjacent lane interference, the required detection zone area, the specific vehicle types being monitored, and the physical distance between the loop and the electronics module.

In practice, these loops are deployed to capture two primary types of data: presence and passage. Presence detection—monitoring a vehicle within a specific zone or lane—typically requires loops with larger surface areas. Conversely, detecting the passage of a vehicle over a specific point is best achieved using a single, smaller loop.

Once geometry is established, the next critical factor is the number of turns. While the geometry defines the physical detection zone, the number of turns dictates the loop’s inductance value. It is essential to account for the lead-in cable’s inductance, as it contributes to the total input inductance of the system. Engineers must balance these values carefully, as decreasing the loop inductance below recommended thresholds can significantly compromise system stability.

Furthermore, it’s important to note that a vehicle passing over a small portion of a large loop generates a significantly smaller change in inductance than it would when passing over a smaller loop. For maximum system reliability, the detector must be able to register the greatest possible change in inductance when a vehicle enters the detection zone.

Since the detector monitors an inductance shift that is directly proportional to the percentage of the loop area displaced by a vehicle, smaller loop areas inherently provide higher sensitivity. Consequently, when wide-area coverage is required—such as along large gates—multiple smaller loops are often connected to a single detector channel rather than using one oversized loop.

When connecting multiple loops to a single channel, it is standard practice to use identical loops. These loops should share the same dimensions, shape, and number of turns. Maintaining uniform inductance across all connected loops ensures a consistent level of detection sensitivity across the entire monitored area, preventing “dead zones” where a vehicle might go undetected.

For the sake of brevity, this discussion omits foundational concepts such as fundamental inductive theory, loop phasing, and detection height considerations. Furthermore, specialized topics—including the cancellation of undesired magnetic fields through twisted-pair wiring—are left as a subject for further study for those voracious readers seeking a more exhaustive understanding of the underlying physics.

Now, let’s look at some practical pointers for the circuit design notebook.

Practical design pointers

You can build an inductive loop vehicle detector prototype by embedding a wire coil in the roadway and monitoring its inductance. The coil functions as part of a high-frequency oscillator; when a metallic vehicle passes over the loop, it induces eddy currents that decrease the loop’s inductance. This causes a measurable shift in the oscillator’s frequency, which a microcontroller can then process to reliably detect the vehicle.

Success in loop design hinges on balancing sensitivity with environmental stability. Start by documenting the specific loop geometry and the gauge of the wire used, as these factors directly dictate the magnetic field’s reach.

It’s also essential to log the chosen operating frequency; ensuring your system stays within the recommended frequency range for your specific hardware helps avoid interference from nearby power lines or electronic equipment. Finally, always record the layout of the lead-in cables, ensuring they are tightly twisted to minimize noise, and note the pavement conditions to account for any metal reinforcement that might dampen the detector’s response.

As a quick design starting point, you can utilize a Colpitts oscillator built from standard components. The oscillation frequency—typically ranging from 30 kHz to 150 kHz—is determined by the capacitor values and the inductance of the coil windings. The oscillator output is then fed to a microcontroller, which measures the frequency to determine whether a vehicle has been detected.

For better stability, it is recommended to isolate the wire loop from the sensor electronics using a 1:1 ratio isolation transformer, though this is not strictly mandatory. It’s easy to find inspiring design ideas similar to this all over the web.

It’s worth trying a directional loop setup to track traffic flow more accurately. By tracking the activation sequence of two independent sensors, a directional logic loop detector identifies which way a vehicle is headed. The system registers movement based on which loop is tripped first, allowing it to differentiate between opposing flows of traffic.

This capability is particularly useful for shared entrance/exit points in parking facilities and alerting systems to wrong-way drivers on highway ramps. Moreover, these detectors often automate barrier gates, initiating an “open” command for traffic arriving from one side and a “close” command for those departing from the other side.

Figure 3 A directional logic loop detector tracks vehicle direction by monitoring two separate loops. Source: Author

Closing the loop

Inductive loop vehicle detectors prove that even in a world obsessed with complex sensors, the fundamental laws of electromagnetism remain the gold standard for reliability. While computer vision and LIDAR grab the headlines, these buried wire loops continue to quietly power our infrastructure with unmatched precision and weather resistance.

For engineers and makers out there, this technology is a playground of untapped potential—whether you’re optimizing urban traffic flow or building an automated entry system for your own workshop. Don’t just settle for off-the-shelf solutions; grab a spool of wire, dive into the physics, and start prototyping your own detection systems today.

Let’s see what kind of smarter, more responsive world you can build from the pavement up.

T. K. Hareendran is a self-taught electronics enthusiast with a strong passion for innovative circuit design and hands-on technology. He develops both experimental and practical electronic projects, documenting and sharing his work to support fellow tinkerers and learners. Beyond the workbench, he dedicates time to technical writing and hardware evaluations to contribute meaningfully to the maker community.

Related Content

• The Inductive Nature of Voltage-Control Loops
• 6 Considerations for Integrating Sensors in Vehicles
• How Can OEMs Use Connected Vehicle Sensor Data?
• Inside DSP on Automotive Signal Processing: Street Smarts
• The Autonomous Car Industry in 2024: Sensors, Software and Safety

The post Inductive loop vehicle detectors: Still steady in the noise of AI appeared first on EDN.

Stress exceeding the levels prescribed in absolute maximum ratings specifications may lead to chip malfunctions. Key word: may.

Within the last decade, I was the head of a captive tier 1 automotive embedded electronics department for a global vehicle supplier. Our job was two-fold: on the one hand to build electronic units for our own vehicles whenever an external tier 1 could not meet our price and time-lines, and on the other hand to support external tier 1 companies as well as our own vehicle engineers to deliver robust and first-time right solutions.

Do you have a memorable experience solving an engineering problem at work or in your spare time? Tell us your Tale

Our vehicle engineering team was in the process of doing final testing of a prestigious export consignment of buses destined for a UN peace-keeping mission. A initial batch of two hundred buses were undergoing on-road tests when we discovered that around twenty of them were exhibiting electronic cabin climate control subsystem malfunctions.

This particular subsystem had been developed by a globally reputed tier 1 supplier. Their engineering team was promptly summoned to troubleshoot and fix the problem. Unfortunately, the initial troubleshooting progressed for two weeks without any desired outcome. Finally, we as in-house electronics experts were asked to intervene and rescue the seemingly intractable situation.

Their team leader described the associated circuit block that was a suspected culprit as follows:

A three terminal low-dropout regulator (LDO) with a fourth enable pin is used to power the climate control logic. Whenever we wish to reduce drain on the battery by turning off the climate control system, the LDO is disabled by deactivating the fourth enable pin. Unfortunately, this LDO is misbehaving in all the twenty malfunctioning buses. Their “enable pin” always remains disabled internally, shutting off the output!

“What is your diagnosis?,” we asked. “Your vehicle environment is full of transient spikes reaching up to 70 volts,” he countered. “We have tied the enable pin through a resistor to the 24 V battery bus. No wonder the LDO is refusing to work, since its rating is exceeded.”

“You need to clean-up your vehicle transients to ensure the health of our system,” he advised, showing us a report issued by a certified laboratory. “Our control unit has passed the automotive transient burst tests as per international automotive transient norms. If our design was erroneous, our unit should have failed during the transient test.”

In summary, according to him, our vehicle was inflicting worst transients than those prescribed in automotive test transient specifications. I went through the supplier’s schematic, along with the LDO datasheet. The latter document clearly indicated that the absolute maximum rating for the enable pin was 45V DC. Like all datasheets, however, it also cautioned engineers that any stress exceeding the levels prescribed in the absolute maximum rating may lead to chip malfunction.

I pointed out the datasheet note, explaining to him that a transient suppressor in his circuit was needed to limit external transients to below 45V. My team immediately set to work, installing external transient suppressor units in each bus so that the consignment could be released overnight. But the supplier engineers were not convinced, repeatedly pointing out the claimed “passed” conclusion from the test laboratory.

Automotive global transient test norms specify an acceptance criterion as follows:

• The unit should first pass an in-advance functional test
• The unit can now undergo a “transient burst” test that bombards the power bus with spikes as high as 150V
• The unit should then again pass the same functional test as prior

Note, however, that an absolute maximum rating of 45V is applicable to the worst-case rated LDOs in the field. In contrast, the majority of the chips withstand much higher voltages during operation. This explained why a majority of the buses did not suffer from the malfunction. When a supplier submits samples to the laboratory, test agencies do not test “violation of absolute maximum rating”. They only apply the acceptance criterion in terms of successful functional tests both pre- and post-transient test.

But the supplier engineering team was not prepared to accept above argument. “If you don’t agree with us, let’s meet again tomorrow. This time, please also bring with you the LDO supplier’s application engineer. Both of you should declare in one voice that your circuit does not violate absolute maximum ratings. We have no time to argue now; we need to expedite corrective measures overnight.”

The next morning, we met again with the the climate control supplier engineer, this time also including the semiconductor application engineer in the discussion. The semiconductor engineer confirmed our understanding, much to the dismay of the supplier engineer. Our buses were happily dispatched to their destination after adding necessary protection units and are running without problem to this very day.

Let me summarize the lessons and insights from this case study, which I also frequently share with my automotive clients and trainees:

• An absolute maximum rating of, say, 45 volts does not mean that all chips would get destroyed at 46 volts and beyond. That said, other chips’ operating life may, however, still be reduced.
• Understand the limitations of engineering tests based on visual observations of correct functionality for electronic units. The unit may be violating datasheet limits, ratings, operating conditions etc., but may still seem to be working flawlessly.
• An accurate way to ensure robust and flawless behavior across a mass-produced population of units is to record voltage and other electrical signatures in a laboratory for key circuit points. Doubly ensure that the same is not violating any data sheet limits.
• It is good engineering practice to jointly audit key circuit blocks with the assistance of authorized chip application engineers. Most semiconductor companies are happy to do so, since it preserves their field reputations. They will also gladly prescribe proactive measures to strengthen circuit designs in order to avoid subsequently facing “field surprises” such as this incident.

Vishwas Vaidya is a graduate of the Indian Institute of Technology in Delhi, India. Currently, he is self-employed as an engineering consultant and industry faculty member in the field of embedded systems for global automotive clients and high-repute academic institutions. Vishwas’ articles and research reports have appeared in many worldwide engineering publications.

Related Content

• Stress analysis
• Semiconductor Reliability and Quality Assurance–Failure Mode, Mechanism and Analysis (FMMEA)
• Design for reliability: You have the tools
• Electronic Components Derating – Made Easy

The post Absolute illiteracy about absolute maximum ratings appeared first on EDN.

Applications in the AI era are memory starved. They need more capacity and, in many cases, more effective memory bandwidth than traditional server designs. Generative AI and large language models (LLMs) store trillions of parameters that must be accessed frequently. And real-time inference for translation, chatbots, and similar services demands low-latency memory paths.

Larger memory footprints enable bigger batch sizes, improving training and inference efficiency. However, while the fastest memory sits on die—in CPU caches—capacity there is inherently limited. For decades, systems have relied on double data rate (DDR) interfaces for high-capacity, relatively low-latency off-chip memory.

Adding more DDR to a CPU, however, runs into hard limits: each interface consumes scarce I/O pins (288 pins on modern DDR4/DDR5 modules), demands strict signal integrity at ever-higher data rates, and carries significant cost. An alternative that has gained real traction is Compute Express Link (CXL) Type 3 memory expanders—devices that attach over a CXL link and present additional system memory to the host.

CXL is a cache-coherent interconnect that lets a CPU access device-resident resources with semantics closer to memory than traditional PCI Express (PCIe) peripherals. A Type 3 memory expander exposes DRAM (and, in some designs, other media) as byte-addressable memory that firmware and the operating system can map and allocate like conventional RAM—after discovery, decode programming, and policy setup.

The critical implication for bring-up and validation is that this memory is logically host-visible yet physically and administratively distinct from local dual inline memory modules (DIMMs). That distinction affects discovery, non-uniform memory access (NUMA) topology, performance, and error-handling paths through firmware and the OS.

Figure 1 The memory-latency pyramid describes relative ordering and validation implications. Source: arXiv

The memory latency–capacity pyramid

System memory is best understood as a latency–capacity pyramid. Small, fast, most expensive structures—CPU caches—sit at the top. Larger, slower, progressively cheaper tiers sit below; local DRAM, then expansion memory, and then I/O-backed storage. Absolute nanoseconds vary by CPU generation, CXL version, link width, topology (direct attach versus retimer or switch), firmware tuning, and contention; the pyramid describes relative ordering and validation implications, not a single fixed latency table.

Local DDR, typically attached near the CPU socket, offers the lowest DRAM access times the OS sees for general-purpose allocation. CXL Type 3 expander memory is DRAM-class and byte-addressable from software’s perspective, but it’s reached across a CXL fabric hop (often with additional buffering and coherency handling).

It therefore sits below local DDR—higher average and tail latency, sometimes behaving like “far memory” in NUMA terms. In other words, imaging CPU 0 accessing DDR memory is attached to CPU 1 in the system, as shown in Figure 2.

Figure 2 Here is a typical two-socket system with a CXL memory expander device attached to CPU 0 via a Gen5, x16 CXL bus. Source: Author

For bring-up, that placement matters as correctness tests may pass while performance and quality-of-service (QoS) tests fail. Workloads with pointer chasing, fine-grained random access, or strict tail-latency budgets are the first to expose suboptimal placement, interleaving, or contention.

Storage and networked memory (NVMe, RDMA, and similar) form the broad base of the pyramid with much higher latency and usually block or page semantics. CXL memory is not in the same tier as SSDs, but it’s meaningfully different from local DIMMs for latency-sensitive software. On a typical two-socket system, the access latency of DDR behind a CXL device can be comparable to accessing DDR attached to the adjacent CPU—a useful mental model when setting performance expectations.

Platform prerequisites: A cross-layer contract

Whether CXL Type 3 memory becomes reliably visible, addressable, and serviceable depends on aligned support across the stack: CPU CXL capability and enablement; system BIOS/firmware support for discovery, decode, and ACPI tables; kernel CXL enumeration and memory management; and expander device firmware for DRAM training, HDM reporting, and mailbox/DOE services. All layers must agree.

Consider CXL Integrity and Data Encryption (IDE); it requires CPU support, BIOS enablement, and device firmware support to be usable end to end. Similarly, the kernel needs a CXL-aware path to recognize the device class, bind memory resources, and transition capacity to an online state the allocator can use.

Reliability, availability, and serviceability (RAS) matter equally. Corrected and uncorrected error notifications must propagate from hardware through firmware to OS subsystems that can log, isolate, or offline affected regions. Because behaviors evolve quickly across kernel releases, validation plans should treat OS version, configuration (huge pages, numactl policies, memory mode), and boot/firmware settings as explicit test variables. Failures are often misattributed to the expander when the root cause is a policy or enablement gap.

Host-managed expander memory generally relies on the in-kernel CXL/memory management stack rather than a monolithic device-specific driver, though platform integrations may include monitoring agents, telemetry exporters, or hardware management interfaces that affect how engineers observe link state, temperature, power, and error counters during bring-up.

Linux and the NUMA story

On Linux, a Type 3 memory expander normally appears as a PCI/CXL function. In upstream kernels with CXL support enabled, the in-tree cxl_pci module is the default bind target. A stock Type 3 host-managed device (HDM) endpoint typically comes up under cxl_pci rather than a vendor-specific host driver for basic enumeration.

The cxl_pci module is PCI-facing glue: it attaches to the device, brings up CXL.io access (including the configuration mailbox), and registers the endpoint with the CXL core so the rest of the stack can expose memory devices to the OS.

In a NUMA machine, the operating system groups CPUs and memory into nodes and treats local memory as cheaper than remote memory. DRAM next to a socket is usually the lowest-latency memory for CPUs in that socket, so the scheduler and allocator try to keep threads and pages on nearby nodes (subject to policy).

CXL Type 3 expander memory is still host-coherent and byte-addressable, but it’s physically and topologically distinct from local DIMMs. Platforms and operating systems therefore commonly expose expander memory ranges as a distinct NUMA node, or as memory with different affinity and distance metadata in ACPI proximity hints. The same application binary can run correctly while performance changes sharply depending on where pages are allocated and whether threads migrate across sockets.

For CXL bring-up and validation, the NUMA story is central. Issues often appear as unexpected remote access or imbalanced bandwidth rather than hard functional failures. Engineers must verify not only that memory is online, but that placement and distance metadata match the intended system topology.

What comes next

Part 2 of this series introduces the user-space tooling ecosystem—cxl/libcxl, ndctl, daxctl, numactl, and topology helpers—and traces the full boot sequence from slot power and DRAM training through DVSEC discovery, decode programming, CDAT delivery, ACPI table handoff, and OS driver binding. Part 3 turns to practical test and debug: interpreting lspci output, validating HDM ranges, exercising CXL-attached memory with numactl, and selecting bandwidth and stress tools for validation gates.

Together, these three parts provide a vendor-neutral, OS-focused playbook for engineers, bringing CXL Type 3 memory expanders from first power-on to production-ready validation.

Ameet Sanghavi works in post-silicon validation for PCIe and CXL at Nvidia with a focus on interface bring-up and validation on shipping products. He has worked on PCIe since 2005 (from PCIe 1.1 onward) and on CXL since 2020 (from CXL 1.1 onward).

Editor’s Note

This is Part 1 of the mini-series on CXL Type 3 memory technology. Part 2 of this series introduces the user-space tooling ecosystem. And Part 3 turns to practical test and debug work.

The views and content of the article are the author’s own and not affiliated to any of his current or previous employers.

Related Content

• Stripped Down CXL Scales Memory Wall
• CXL Efforts Focus on Memory Expansion
• CXL Adds Port Bundling to Quench AI Thirst
• CXL: The key to memory capacity in next-gen data centers
• From GPUs to Memory Pools: Why AI Needs Compute Express Link (CXL)

The post Why CXL Type 3 memory matters, what your platform must provide appeared first on EDN.

Converting frequency signals to loop current signals creates an economical result for process industry applications.

Process industry applications commonly employ multiple motors. Their speeds are monitored by tachometers using magnetic pickups from gear wheels mounted on the motors’ shafts. The tachometers produce pulses whose frequencies are proportional to their speeds. Local displays of speeds is generally done by counter/timer-based LEDs or LCDs.

Wow the engineering world with your unique design: Design Ideas Submission Guide

Special modules incorporating expensive counter/timers find use for recording these speeds in control room-based programmable logic controllers (PLCs) and more complex distributed control systems (DCSs). Shielded cables are necessary to carry these pulse signals to the control room, as the signals may induce noise in adjoining cables carrying conventional analog signals. Such an approach is expensive. A more economical alternative solution would be to convert each frequency signal to a 4-20 mA  loop current signal and then transport it to the control room using less expensive cables like those carrying analog signals. Figure 1’s circuit does exactly this.

Figure 1 In one switch SW1 position, this circuit converts 0-50 kHz frequency signals to 4-20 mA loop current alternatives. In the other switch position, the circuit converts 0-5V into 4-20 mA loop current.

The frequency to voltage conversion circuit discussed here is based on an industry-standard LM2907 IC. This chip is extensively used in automotive applications and hence is easily available and inexpensive. It needs only three components to set the basic relationship between frequency and voltage. It uses a charge pump circuit to convert frequency to voltage.

• V output = Vcc*F*R*C (In Figure 1’s circuit, R=R5, C=C4)
• U2 is wired to give a 12 V output, which is fed to the circuit. F is pulse frequency.
• With Vcc as 12V and substituting the component values shown in the circuit, the voltage output works out to 0.264V/KHz.

Exact values for R5 and C4 are not necessary; approximate values are sufficient. The signal is amplified by U1B so that a voltage relationship of 1V/KHz is obtained by tuning potentiometer RV1. C5 filters ripples; increasing its value filters ripples more effectively but also increases the response time. The portion of the circuit surrounding U3 converts 0 to 5KHz into 0 to 5 volts.

The remaining portion of the circuit converts 0/5V into 4/20 mA loop current. R2 determines the “zero” current of 4 mA. If an exact-value resistor is not available, R2 may be replaced with a potentiometer. R13 determines the current span value. Again, if an exact-value resistor is not available, it can be replaced with a potentiometer.

The current going through R2 plus the current going through R13 must be equal to current through R4, as these currents are at the + input of operational amplifier U1A, whose -ve input is grounded. A detailed description of a loop current converter with governing equations can be found in my earlier Design Idea “A 0-20 mA source current to 4-20 mA loop current converter”.

As a bonus, this circuit converts 0-5V into 4-20mA loop current by flipping switch SW1 to the alternative 0-5V input position. Multiple industrial sensors and transmitters generate 0-5V outputs for the parameters they monitor. This circuit may be used to comfortably connect such sensors and transmitters to PLCs and DCSs. Linearity and accuracy are primarily dictated by the LM2907 IC. A simulation study of this circuit indicates accuracy of better than +/- 5%.

Jayapal Ramalingam has over three decades of experience in designing electronics systems for power & process industries and is presently a freelance automation consultant.

Related Content

• 4/20mA to 0/20mA loop current converter for grounded loads
• Full circle current loops: 4mA-20mA to 0mA-20mA
• Another silly simple precision 0/20mA to 4/20mA converter
• Silly simple precision 0/20mA to 4/20mA converter
• A 0-20mA source current  to 4-20mA loop current converter

The post Tachometer frequency to 4-20mA loop current converter appeared first on EDN.

Solid-state drives (SSDs) are among the evolutionary success stories of modern computing. They replaced spinning disks, eliminated mechanical bottlenecks, and enabled the high-speed data access that today’s applications depend on. Plus, they fit into ever-smaller form factors, which we all love.

But as workloads evolve—especially with the rise of edge AI—SSDs are bumping against a critical limitation: heat.

What was once a distant consideration has become a frontline performance constraint. Today’s SSDs are faster, denser, and more heavily utilized than before. And the devices they live in—ultrabooks, tablets, gaming handhelds, and emerging AI-enabled wearables—are thinner, more compact, and often fanless. This clash of trends is creating a perfect thermal storm.

The forecast is ominous—both for consumers and system designers. SSDs will continue buckling under real-world workloads; they’ll throttle data speeds when things get hot; and users will pay the price in diminished performance.

But there must be a cooler way out.

The new reality of sustained workloads

Historically, many storage workloads—the read/write patterns of moving data—were burst-oriented. Opening files, launching applications, and saving documents created short spikes in activity, followed by idle periods that allowed components to cool. Under these conditions, passive thermal solutions such as heat spreaders, vapor chambers, and thermal pads were sufficient.

That’s no longer the case.

Modern workloads, particularly those driven by AI, are sustained and data intensive. Running local LLMs requires loading gigabytes of parameters from storage into memory. AI-powered photo and video editing tools generate continuous read/write cycles during rendering and export. Even gaming has evolved, with real-time asset streaming and procedural generation placing constant demands on storage subsystems.

They are prolonged, high-throughput operations that keep SSD controllers and NAND flash memory active for extended periods. And that changes everything.

Thermal throttling: Hidden performance killer

SSDs are designed with thermal safeguards to prevent damage. Most standard, high-speed controllers begin to throttle performance when temperatures reach approximately 70°C to 80°C. Once that threshold is crossed, the drive reduces its speed to lower heat output.

From a reliability standpoint, this is essential. From a performance standpoint, it’s detrimental. In practical terms, thermal throttling of SSDs can reduce throughput by 20% to 30% or more. A drive capable of delivering 2.0 GB/s may drop to 1.5 GB/s under sustained load. For users, this translates into longer file transfers, slower application performance, and increased latency in AI-driven tasks.

Usually, such performance degradation is unpredictable. And in edge AI applications, where consistent performance is critical, this variability can be unacceptable.

Why passive cooling is no longer enough

The root of the problem lies in the limitations of passive cooling. Passive thermal solutions are designed to spread heat away from hotspots, redistributing it across a larger surface area. This can delay temperature spikes and improve short-term performance, but it doesn’t actually remove heat from the device.

In compact, sealed systems where SSDs operate, heat accumulates over time. Without airflow to carry that heat away, temperatures inevitably rise until throttling occurs.

This challenge is exacerbated by modern device design. In many ultrathin laptops and handheld systems, SSDs are positioned near CPUs, GPUs, and other heat-generating components. The thermal environment is already saturated, leaving little headroom for additional heat dissipation.

The industry has pushed passive cooling to its limits with advanced materials and clever mechanical designs. But physics imposes a hard boundary. Without active airflow, sustained high-performance operation is not achievable.

Micro-cooling: A new approach to active thermal management

How to achieve that airflow? Traditional active cooling relies on fans. Fans move air, enabling heat transfer that effectively removes thermal energy from a system. In desktops and larger laptops, this approach works well.

But fans are not a universal solution. They take up space, generate noise, consume power, and introduce mechanical complexity. In ultra-thin devices, wearables, and sealed systems, integrating a fan is often impractical or undesirable. As a result, many edge devices are designed without active cooling, despite the increasing thermal demands placed on their components. Still, there’s a need for active cooling that fits within the constraints of modern device design.

Micro-cooling (µCooling) technology offers a new approach. Instead of miniaturizing traditional fans, µCooling uses piezoMEMS technology to generate airflow through microscopic motion inside a silicon chip. Often referred to as a “fan on a chip,” µCooling devices are fabricated using semiconductor processes, making them extremely compact, thin, and reliable.

Because they have no moving mechanical parts, µCooling devices avoid many of the drawbacks associated with conventional fans. They operate silently, consume minimal power, and can be integrated into tight spaces where traditional cooling solutions cannot fit. But most importantly, µCooling “fans” move heat out of a system and away from SSDs, something no passive cooling solution can accomplish.

What µCooling means for SSD performance

For SSDs, the introduction of µCooling is transformative. By generating localized airflow around the SSD controller and NAND components, µCooling systems can actively remove heat before it accumulates to critical levels. This helps maintain operating temperatures below throttling thresholds, even during sustained workloads.

Instead of experiencing performance degradation over time, SSDs can sustain higher throughput for longer durations. This is particularly valuable for AI workloads, where consistent data access speeds are essential. In practical terms, this means faster model loading, smoother real-time processing, and more reliable performance during extended tasks such as video rendering or large-scale data transfers.

µCooling also enables system designers to rethink thermal constraints. With active cooling available at the micro level, they can push performance boundaries without being limited by the thermal management challenges.

Enabling the future of edge AI devices

The evolution of SSDs has always been about addressing bottlenecks—first mechanical, then architectural. The next bottleneck is clearly thermal. Without addressing heat, we can’t realize the full potential of modern storage systems in edge devices. Throttling will undermine performance gains, and the user experience will suffer.

µCooling provides a path forward. By bridging the gap between passive and traditional active cooling, it enables a new class of thermal solutions tailored to the needs of modern electronics. It ensures that SSDs, a critical component of the data pipeline, don’t become a bottleneck. And that’s crucial.

As edge AI continues to proliferate, the importance of efficient thermal management will only increase. Devices are expected to do more—process more data, run more complex models, and deliver richer experiences—within smaller and more constrained form factors. Storage systems must keep pace with the demands for sustained, not just peak, performance.

Mike Housholder is VP and GM of thermal management at xMEMS.

 

 

Related Content

• SSDs Get Smarter
• SSD drive performance chart
• Smarter SSDs bring on-drive processing
• SSD performance measurement: Best practices
• Startup Touts SSD Architecture, Private Label Model

The post SSDs are hot: Why AI demands micro-cooling appeared first on EDN.

Part 1 of this mini-series on advanced packaging outlined the basic comparison between CoWoS, wafer-scale integration, and CoWoP. It established why the package substrate, silicon wafer, and platform PCB represent different settings for future AI system bottlenecks.

Part 2 continues with the advanced CoWoP concept: pitch translation, transition patches, VRM and memory placement, Universal Chiplet Interconnect Express (UCIe) routing, and trusted realization governance.

The most challenging CoWoP part is not only whether the package substrate can be reduced or removed. The harder question is whether the architecture can physically transition from silicon-interposer pitch to platform-PCB pitch.

A wafer-level interposer, silicon bridge, or advanced redistribution structure operates in a fine-pitch environment. Micro-bumps, hybrid bonding, and high-density redistribution can exist in the tens-of-microns range. A platform PCB, even an advanced HDI board, operates at a much larger manufacturing scale, closer to hundreds of microns for practical solderable attach and board-level assembly.

This creates a major geometric discontinuity:

• Interposer/wafer-level interface: roughly tens of microns
• Platform-PCB attach interface: roughly hundreds of microns

Trying to force the primary interposer to absorb this entire fan-out directly would consume expensive interposer area, increase routing complexity, reduce yield, and weaken the economic argument for CoWoP. Therefore, the more practical CoWoP architecture may require an intermediate transition structure.

• Die/HBM → wafer-level interposer → transition redistribution patch → platform PCB

This patch is not simply another conventional package substrate. It’s a localized pitch-translation and CTE-management layer. Its role is to convert the silicon/interposer interface into a PCB-compatible attach interface while preserving electrical, mechanical, and thermal continuity.

A useful name for this structure is interposer-to-PCB transition patch, or more specifically, pitch-transition redistribution patch. This transition patch becomes the governed bridge between wafer-level precision and platform-level manufacturability.

Glass as a local transition patch

One possible implementation is a thin glass-core transition patch. A 2-3-layer glass-based transition patch could provide dimensional stability, CTE compatibility with the silicon/interposer side, and a controlled vertical path through TGVs. In this use case, glass is not being treated as a full package substrate replacement; it’s being used as a local transition bridge between wafer-level precision and board-level attach.

The concept is similar in spirit to wafer-to-package redistribution: expand the pitch in controlled stages rather than forcing one layer to absorb the entire geometric transformation. The transition could look like this in silicon die/HBM:

• Micro-bumps or hybrid bonding at fine pitch
• Primary wafer-level interposer
• First-stage redistribution
• Glass-core transition patch with TGVs
• Second-stage fan-out toward PCB pitch
• Platform PCB

The value of the glass patch is that it may preserve the CTE and dimensional-stability advantages near the interposer while providing a more manufacturable path toward the PCB. This matters because the hardest interface may not be the PCB alone or the interposer alone. It may be the transition between the two.

A glass transition patch can potentially help with:

• Fine-pitch registration
• CTE continuity near the silicon/interposer side
• Controlled vertical fan-out through TGVs
• Reduced interposer area devoted only to fan-out
• More stable pad alignment across thermal cycling
• A shorter vertical PDN path toward the platform PCB

But the glass patch also introduces its own realization needs:

• TGV reliability
• Glass/copper stress
• Attach fatigue
• Inspection accuracy
• Edge cracking
• Lifecycle drift

In other words, glass can make the transition more governable.

Organic as a compliant transition patch

Another possible implementation is a high-density organic transition patch. An organic patch may not match the dimensional stability of glass, but it may provide mechanical compliance. That compliance could help absorb shear stress between a rigid silicon/interposer structure and a larger platform PCB that expands, warps, and bends differently under thermal and mechanical loading.

This creates an important trade-off. A glass transition patch may offer stronger dimensional stability, stronger CTE matching to silicon/interposer, better fine-pitch registration, and a stronger TGV-based vertical transition. An organic transition patch may offer better mechanical compliance, more familiar substrate processing, and potentially better stress absorption between rigid silicon and PCB.

This trade-off is exactly why CoWoP should be treated as a governed realization problem, not only a layout concept. The transition patch becomes a decision point. The best material may depend on system size, thermal cycling, pitch requirements, power density, board stiffness, rework needs, reliability targets, and cost.

CoWoP as an interposer-to-patch-to-PCB corridor

With the transition-patch concept included, CoWoP becomes technically more credible. The architecture is not simply interposer directly attached to PCB, as shown below.

Interposer → controlled transition patch → platform PCB

It means CoWoP is not only a substrate-removal concept. It’s a pitch-transition, CTE-governance, and system-integration concept. The package substrate may be reduced, localized, or re-architected, but the realization burden does not disappear. It moves into a new corridor where the interposer-to-transition patch-to-platform PCB corridor must govern:

• Pitch translation
• Pad registration
• TGV or via integrity
• CTE continuity
• Attach fatigue
• Return-path continuity
• PDN impedance
• Decoupling location
• Thermal spreading
• Inspection and test
• Lifecycle reliability

Why CoWoP may be attractive for VRM placement

One of the strongest opportunities is power delivery. In advanced AI packages, the VRM is often physically far from the die. The power-delivery path must travel through the PCB, package substrate, interposer, bumps, and on-die distribution. This creates loop inductance, PDN impedance challenges, transient-response limitations, dI/dt sensitivity, resonance concerns, and pressure to place decoupling capacitance closer to the load.

Moving active power components onto the interposer or package may reduce distance, but it introduces other risks:

• Thermal density
• Active-component integration complexity
• Manufacturing risks
• Repairability concerns
• Reliability uncertainty

CoWoP may offer a more practical middle path. The VRM can remain on the PCB, where active power components are more manufacturable, serviceable, thermally manageable, and familiar to the design ecosystem. At the same time, however, the vertical corridor from platform PCB to transition patch to interposer may become shorter and more direct than the conventional package-substrate path.

So, the value is not that the VRM is placed on interposer; the value is that the VRM can stay on the PCB while the power corridor to the interposer becomes shorter, more controlled, and potentially lower inductance. That may reduce part of the package-dominated loop inductance and improve the power-delivery architecture without forcing active VRM components into the interposer itself.

This creates a new chiplet power architecture opportunity: PCB-side VRM, transition-patch power delivery, lower package burden, and governed PDN evidence. But the power problem is not solved automatically. The transition patch must preserve current return paths, minimize spreading inductance, support decoupling strategy, avoid PDN anti-resonance, and remain reliable under thermal cycling.

In short, while the corridor is shorter, it still must be governed.

Why CoWoP may be attractive for DDR and LPDDR

Memory is another important area. HBM will remain critical for high-bandwidth AI accelerators, but not every memory requirement should necessarily move onto the package. DDR and LPDDR placed on package can create manufacturing, warpage, thermal, test, yield, and reliability concerns.

So, memory on the PCB remains attractive because it’s more familiar, more serviceable, and more compatible with established board-level manufacturing. The problem is distance and signal quality.

In a conventional architecture, the memory path may be:

Die → interposer → package substrate → PCB → DDR/LPDDR with CoWoP

The path may become closer to:

Die → interposer / wafer-level routing → transition patch → platform PCB → DDR/LPDDR

This does not make PCB memory identical to on-package memory. However, it may improve the compromise: memory can remain on the PCB while the routing path becomes shorter, more direct, and potentially more controllable than the conventional package-to-board path.

That is a meaningful system architecture advantage. It may also reduce pressure to place every useful memory element inside the package, which can help with manufacturability, reliability, thermal control, and module yield.

But DDR/LPDDR on the PCB still demands careful governance.

• Timing margin
• Impedance control
• Crosstalk
• Return path
• Via transitions
• Thermal drift
• Board manufacturing variation

CoWoP may improve the memory compromise, but it does not eliminate memory convergence risk.

Why CoWoP may help UCIe and chiplet routing

UCIe and other chiplet interconnect strategies need dense routing, controlled impedance, short paths, clean return current, low jitter, and manageable power/thermal interaction. However, in conventional 2.5D architectures, much of the high-density routing is constrained by interposer size, substrate escape, package boundary, and board transition.

CoWoP may create more flexibility by making the platform PCB part of the high-density system-integration fabric. This could support more flexible routing between chiplets, memory, power, and system I/O. It may also support larger integration footprints without relying on ever-larger package substrates.

But this is also where the challenge appears. The platform PCB can no longer be treated as an ordinary board. It becomes part of the advanced-package realization path. That means PCB materials, dimensional accuracy, layer stack-up, shielding, via structures, reference planes, surface finish, warpage, inspection, and assembly control all become part of the governed convergence problem.

The transition patch makes this more realistic, but it also introduces a new boundary that must be modeled, measured, inspected, and qualified.

The new CoWoP challenges

CoWoP may reduce several package-level burdens, but it does not eliminate complexity. It shifts complexity into a new interposer-to-transition patch-to-platform PCB corridor. The key challenges include:

• Low-loss platform PCB materials
• Interposer-to-transition patch attach reliability
• Transition-patch-to-PCB attach reliability
• Pitch translation from fine-pitch interposer scale to PCB attach scale
• TGV or via reliability inside the transition patch
• Warpage and CTE mismatch
• Board flatness and dimensional control
• High-density routing precision
• Shielding between dense high-speed traces
• Return-path continuity across multiple interfaces
• PDN impedance and resonance
• VRM placement and transient response
• Decoupling location and effectiveness
• DDR/LPDDR timing and signal integrity
• UCIe routing and crosstalk
• Thermal spreading from die and HBM into board-level structures
• Inspection accuracy
• Rework strategy
• Lifecycle reliability

These challenges are solvable, but they require a different mindset. CoWoP does not simply move packaging onto a PCB. It asks the PCB ecosystem to operate closer to semiconductor-grade precision, while also asking the package ecosystem to think beyond the traditional package substrate. This is why CoWoP is not only a packaging innovation. It is a governed realization challenge.

Three architectures, three bottleneck locations

The most useful way to compare these architectures is by asking where each one places the system bottleneck. CoWoS places the bottleneck in advanced package scaling: interposer size, package substrate capability, HBM integration, substrate supply, package warpage, thermal design, SI/PI, PDN, and board transition.

Wafer-scale integration places the bottleneck in system adaptation around a very large silicon object: power delivery, cooling, mechanical design, yield management, redundancy, system serviceability, and workload mapping.

CoWoP places the bottleneck in the interposer-to-transition patch-to-platform PCB realization corridor: pitch translation, CTE continuity, low-loss PCB materials, precision manufacturing, attach reliability, power delivery, memory routing, UCIe flexibility, shielding, return-path continuity, inspection, and lifecycle evidence.

None of these paths eliminates convergence complexity. Each path chooses where complexity will live.

Why CoWoP needs a trusted realization layer

CoWoS, wafer-scale integration, and CoWoP all create different evidence domains, but the same fundamental governance problem remains. Which evidence is mature enough to support a deterministic engineering decision?

For CoWoS, the evidence includes interposer routing, substrate PDN, HBM integration, warpage, thermals, package attach, SI/PI, EM/IR, and board transition. For wafer-scale integration, the evidence includes wafer yield, defect tolerance, power delivery, cooling uniformity, mechanical stability, redundancy, board interaction, and system operation.

For CoWoP, the evidence includes interposer-to-transition-patch attach, transition-patch-to-PCB attach, platform PCB materials, VRM proximity, loop inductance, decoupling strategy, LPDDR/DDR routing, UCIe flexibility, shielding, return-path continuity, warpage, inspection, and lifecycle reliability.

The common requirement is governed convergence. This is where a scalable trusted realization layer (STRL) becomes important. STRL does not need to decide that one packaging structure is always superior. Instead, it asks whether each corridor has enough normalized, admissible, causally grounded evidence to support closure.

In this sense, CoWoP is a powerful new vector for trusted realization because it converts the platform PCB from a passive board into an active realization corridor. With the transition-patch concept included, the sharper statement is: CoWoP converts the interposer-to-transition patch-to-platform PCB boundary into a governed realization corridor.

Platform PCB as an active realization corridor

The most important idea is this: CoWoP may turn the platform PCB into the next active control plane for AI system realization. This does not mean the board replaces the interposer. It means the board becomes more deeply integrated into the convergence path.

The platform PCB must support power delivery, memory routing, thermal interaction, high-speed signaling, mechanical stability, shielding, and manufacturing precision. The board is no longer downstream from the package. It becomes part of the package-system continuum.

That creates a new research and industry-development opportunity: Interposer + transition patch + platform PCB as a governed system EM corridor. This corridor can be evaluated across:

• Power delivery and transient response
• Loop inductance and dI/dt sensitivity
• Decoupling effectiveness
• UCIe/chiplet routing flexibility
• DDR/LPDDR signal integrity
• Shielding and crosstalk
• Thermal spreading
• Mechanical stability
• CTE and warpage
• Manufacturing yield
• Inspection and test
• Field reliability

This is not only convergence theory; it’s a practical architecture direction.

Evidence domains for a governed CoWoP corridor

For CoWoP to become a credible production architecture, the key evidence domains must be governed together, not separately.

A CoWoP realization corridor would need evidence from:

• Interposer layout and redistribution
• Micro-bump or hybrid-bonding interface quality
• Transition-patch material selection
• TGV/via resistance and reliability
• Pad registration and pitch expansion
• CTE transition and shear stress
• Patch-to-PCB attach integrity, platform PCB flatness, and dimensional stability
• VRM phase-current behavior
• PDN impedance and transient droop
• Decoupling effectiveness across frequency
• DDR/LPDDR timing margin
• UCIe crosstalk and return-path continuity
• Thermal gradients and cycling stress, inspection, rework, and lifecycle failure signatures

In conventional workflows, these may be treated as separate domains. In a governed realization architecture, they become one corridor. That is the role of STRL:

• Normalize evidence
• Preserve causality
• Qualify admissibility
• Support bounded engineering authority

Why this idea matters now

The current package stack is under pressure. AI packages are becoming larger, more complex, more thermally constrained, more power-hungry, and more challenging to manufacture. Moreover, package substrates face size, availability, yield, warpage, layer-count, PDN, and cost challenges.

At the same time, memory, UCIe, power delivery, thermal design, and system-level integration are becoming harder to close independently. CoWoP may not be mature enough today to replace CoWoS in mainstream high-volume AI accelerators. But the direction is important.

If low-loss PCB materials, precision board manufacturing, inspection capability, transition-patch technology, and interposer-to-board attach reliability continue to improve, CoWoP may become one of the important platform-level architectures for future AI systems. The reason is simple.

It reduces the number of realization layers between silicon and system, but only if the transition boundary is engineered correctly. Instead of managing interposer, package substrate, and PCB as three separate convergence domains, CoWoP points toward a tighter corridor: interposer → transition patch → platform PCB.

That can potentially improve power-delivery proximity, reduce package-dominated loop inductance, keep active VRM components on the board, preserve DDR/LPDDR manufacturability, support flexible UCIe routing, and reduce some package-size and substrate-related burdens. But it also demands stronger governance.

What makes CoWoP practical

CoWoS proved that advanced packaging is central to AI scaling. Wafer-scale integration proved that silicon-scale system integration can unlock a different class of compute architecture. CoWoP may become an important middle path: wafer-level density brought closer to the platform PCB, with power, memory, routing, and system realization governed through a shorter corridor.

However, the most important CoWoP challenge is not only substrate removal; it’s the transition from silicon/interposer scale to PCB scale. The opportunity is not that CoWoP solves every problem. The opportunity is that it relocates the problem to a corridor that may be more scalable, more board-integrated, and more compatible with practical power and memory placement.

The challenge is that this corridor must be governed. Low-loss materials, pitch translation, transition-patch reliability, VRM proximity, PDN impedance, loop inductance, decoupling, LPDDR routing, UCIe flexibility, shielding, thermal behavior, warpage, and lifecycle reliability must be treated as one convergence problem. This is where STRL becomes relevant.

The future question is not only whether CoWoP can be built. The future question is whether the interposer-to-transition patch-to-platform PCB corridor can remain electrically, thermally, mechanically, manufacturability, and operationally converged across lifecycle. That is trusted realization.

It’s also the next bottleneck. And it may also be the next opportunity.

Interoperability moves data. STRL qualifies evidence. Governed convergence closes decisions.

Dr. Moh Kolbehdari is senior director of IC/packaging at Socionext US.

Editor’s Note

This is Part 2 of the mini-series on advanced packaging. Part 1 highlighted the basic comparison between CoWoS, wafer-scale integration, and CoWoP technologies.

Related Content

• True Wafer-Level Packaging
• Wafer Level Chip Size Package (WLCSP) Guidelines
• Intel’s Embarrassment of Riches: Advanced Packaging
• Nvidia, TSMC, and advanced packaging realignment in 2025
• Intel flash move could put wafer-level packages on the map

The post The interposer-to-PCB realization corridor in CoWoP appeared first on EDN.

Built around the NXP RW612 wireless MCU, Quectel’s FCM365X module combines dual-band Wi-Fi 6, Bluetooth LE 5.4, Zigbee, and Thread connectivity in a single device. It integrates a 260-MHz Arm Cortex-M33 processor with TrustZone, 1.2 MB of SRAM, and 8 MB of flash, with optional PSRAM expansion.

The FCM365X gives developers the flexibility to support multiple wireless protocols while simplifying device design. Zigbee and Thread enable low-power, reliable mesh networking across smart home and industrial IoT ecosystems, with Thread emerging as a key technology for Matter-enabled devices.

Suited for power-constrained applications, the FCM365X offers multiple low-power modes and keep-alive mechanisms. Standard interfaces include GPIO, SDIO, UART, USB, SPI, and JTAG, while the QuecOpen SDK enables access to I²C, I²S, ADC, LCD, and PWM. The module also complies with WPA-PSK, WPA2-PSK, and WPA3-SAE security standards and uses AES-128 encryption.

The FCM365X is housed in an LCC+LGA surface-mount package with a compact footprint of 25.5×18.0×3.16 mm. A timeline for availability was not provided at the time of this announcement.

FCM365X product page 

Quectel Wireless Solutions

The post Wireless module simplifies multiprotocol IoT design appeared first on EDN.

The TPM1R408RH 80-V N-channel MOSFET is built on Toshiba’s latest-generation low-voltage U-MOS11-H process. It features an optimized device structure with an RDS(on) of 1.4 mΩ—about 26% lower than the 80-V TPM1R908QM based on the previous-generation U-MOS X-H process. It also improves the RDS(on)-Qg tradeoff, reducing figure of merit by ~45% versus the TPM1R908QM.

These reductions lower power loss in switch-mode power supplies for industrial equipment such as AI data centers and communication base stations. The TPM1R408RH also suppresses drain-source voltage spikes during switching, reducing EMI. This helps minimize late-stage design rework and simplifies filter and snubber circuits.

The MOSFET is supplied in the SOP Advance(E) package, which delivers approximately 65% lower package resistance and approximately 15% lower thermal resistance than Toshiba’s current SOP Advance(N) package. This reduces conduction losses and improves thermal performance, enabling higher power density in compact power supply designs.

The TPM1R408RH is available through Toshiba’s authorized on-line distributors.

TPM1R408RH product page 

Toshiba Electronic Devices & Storage 

The post 80-V MOSFET improves power supply efficiency appeared first on EDN.

Infineon’s AIROC UWB TSL100 SoC enables centimeter-level distance measurement and localization using ultra-wideband (UWB) time-of-flight (ToF) technology. Designed for low-power, secure operation, the device targets automotive, consumer, and industrial applications such as secured vehicle access, in-cabin presence detection, contactless payment and ticketing, and industrial asset tracking and collision avoidance.

The TSL100 is the first member of a scalable UWB product family intended to align with upcoming standards such as IEEE 802.15.4ab. It includes a CCC-, FiRa-, and Aliro-compliant MAC. The PHY delivers 48-bit FiRa and CCC security in challenging non-line-of-sight conditions, detecting and verifying direct paths up to 100,000 times weaker than reflected paths.

The SoC enables more than two years of coin-cell battery life in CCC ranging schemes for key fobs, achieved through a dedicated low-power mode that reduces current consumption by more than 50%. Its RF architecture extends sensing functions to presence detection, kick sensing, intrusion detection, and NCAP scenarios. Additionally, AIROC zoning technology enables configurable unlock zones and inside/outside detection for Aliro-enabled smart locks.

Engineering sample kits for the AIROC UWB TSL100 are available upon request.

AIROC USB TSL100 product page 

Infineon Technologies 

The post UWB SoC provides precise distance measurement appeared first on EDN.

ST’s ST54M integrates a post-quantum cryptography (PQC) hardware accelerator, NFC controller, secure element, and eSIM on a single die. The chip helps smartphone and personal electronics manufacturers prepare for future post-quantum security requirements while enabling secure mobile connectivity. Applications include contactless payment, transit ticketing, access control, digital identity, and mobile driver’s licenses.

The ST54M’s hardware accelerator supports PQC algorithms such as ML-KEM and ML-DSA, aiding the transition from hybrid cryptographic approaches to full post-quantum deployment. It also helps protect against side-channel and fault-injection attacks and addresses emerging PQC requirements.

Based on an Arm Cortex-M3 32-bit MCU, the contactless front-end provides NFC card emulation, reader/writer, and peer-to-peer communication modes. It increases RF communication distance, simplifies NFC integration, and supports efficient low-power operation. An integrated step-up DC/DC converter enables transmit drive up to 3 W.

Samples are available now. Production and Common Criteria 2022 EUCC and EMVCo certifications are targeted for July 2026.

ST54M product page 

STMicroelectronics

The post Chip combines NFC and post-quantum security appeared first on EDN.

The Melexis MLX91229 Hall current sensor provides a second-order sigma-delta digital output that improves signal integrity in EV traction inverter applications. Optimized for automotive systems, this output tolerates heavy EMI, helping maintain signal integrity over longer PCB traces or wiring where electrical noise can introduce disturbances between the sensor and MCU.

Unlike analog sensors, the MLX91229 encodes measured current into a sigma-delta bitstream, with information represented by the density of digital pulses rather than absolute voltage levels. This encoding makes the signal inherently more resistant to electrical noise during transmission to the MCU. Because demodulation is performed in the host MCU, designers can optimize the tradeoff between fast overcurrent detection and high-accuracy current measurement.

Supporting current sensing from 200 A to 2000 A, the MLX91229 measures peak magnetic fields from 11 mT to 400 mT. It uses Manchester-encoded data transmission over differential RS-422 or LVDS interfaces. The AEC-Q100-qualified sensor operates over an ambient temperature range of –40°C to +125°C and is powered from a selectable 3.3-V or 5-V supply.

The MLX91229 is available in a 4-pin SIP through authorized distributors and is designed as a drop-in replacement for conventional analog sensors.

MLX91229 product page 

Melexis

The post Hall current sensor delivers sigma-delta output appeared first on EDN.

A linearized output is a useful elaboration of a capacitive sensor design. But what if the circuit is located a significant distance from the control electronics?

Recently, Design Ideas included a circuit that comprised a simple analog interface to basic capacitive position sensors. Figure 1 shows its minimal six parts topology with complementary outputs: Out and –Out.

Wow the engineering world with your unique design: Design Ideas Submission Guide

Figure 1 U1a and U1b cross-coupled Schmidt trigger timers form a ~1MHz RC multivibrator. The Tsense pulse width is inversely proportional to sensor displacement Tref/Tsen = Cref/Csen = d.

Doubling the parts count to 12 transmogrifies Figure 1 into Figure 2 and provides a linear voltage mode output,  Then, with the exemplar 38mm-diameter sensor plate capacitor connected, separation d between plates reads out as d = (Vout – 1) = 0 to 4 millimeters as Vout goes from 1 to 5v.  Vout ripple is just half a millivolt pk-pk. The linear voltage output modification is described in this Design Idea.

Figure 2 Averaging integrator A1 implicitly computes the output voltage needed to linearly balance the charge transferred onto C1 during Tref through discharge during Tsense. Vout = Tref / Tsense  + 1 = Cref / Csense + 1 = d + 1.

So, let’s take it as granted that providing a linearized output was a useful elaboration of the original design.  But suppose the capacitive sensor is located a significant distance from the control electronics.  Voltage mode analog outputs are notoriously vulnerable to noise pickup and disturbances like ground loop voltage differentials.  What to do then?  Figure 3 shows a simple and plausible remedy.  It’s a classic, if I do say so myself.  A noise- and cable length- tolerant, linear 4 to 20mA, current mode output.

Figure 3 Dangling the TLV431 shunt voltage reference Z1 from the 15 volt supply is a shortcut toward implementing a noise- and cable length- tolerant current mode output.

Here’s how it works. Figure 3’s A1 integrator generates a 1 to 5 volt linear output, much like Figure 2’s A1 does.  The difference is this 1 to 5v is inverted, referenced to +15v, and developed across 249ohm current sense resistor R5.  It’s therefore an accurate readout of Pfet Q1’s 4 to 20mA source current.  Shunt reference Z1 provides both the 1.00v integrator reference and a 5v step-down supply for U1 and U2.  DC blocking C4 and R9 trickle protect the chips from being instantly fried in case the sensor capacitor plate shorts to ground.

Some random remarks: U1’s unused inputs should be tied to +15v.  C1, 2, 3, and 4 should be rated for the full supply voltage, which itself isn’t critical but shouldn’t exceed 20v.  Otherwise Q1’s gate will be at risk for over-voltage if the load becomes disconnected.  If  the supply equals 15v as shown, voltage compliance and consequent ground noise resistance is >9v. Iout ripple is ~0.01% pk-pk.  Figure 4 shows the net nicely linear response.

Figure 4 In this graph, black = sensor readout d in mm, and red = the nicely constant 4 microamps per micrometer resolution.

Stephen Woodward‘s relationship with EDN’s DI column goes back quite a long way. Over 200 submissions have been accepted since his first contribution back in 1974.  They have included best Design Idea of the year in 1974 and 2001.

Related Content

• Capacitive position sensor with linearized output
• ~0.1% resolution capacitive position sensor
• CMOS flip-flop used “off label” implements precision capacitance sensor
• Flip-flop plus choke comprise simple and cheap inductive sensor

The post Position sensor gets linear 4 to 20mA current source output appeared first on EDN.

Advanced AI systems are forcing the semiconductor industry to rethink the boundary between silicon, package, board, power delivery, memory, cooling, and manufacturing. For several years, the dominant discussion has centered on advanced packaging capacity, high-bandwidth memory (HBM) integration, large interposers, organic substrate constraints, glass-core substrates, and scaling limits of 2.5D and 3D integration.

That discussion remains valid. But a deeper system question is emerging. What happens if the package substrate is no longer the center of the system-integration hierarchy? This question becomes especially important when comparing three architectural directions:

• CoWoS-style 2.5D integration
• Wafer-scale integration
• CoWoP/chip-on-wafer-on-platform-PCB concepts

Each approach is trying to solve the same industry problem: how to scale AI compute density, memory bandwidth, transient power delivery, thermal control, and multi-die integration beyond the physical limits of conventional packaging stacks. However, each architecture moves the bottleneck to a different place.

Chip-on-Wafer-on-Substrate (CoWoS) makes advanced packaging central to AI and high-performance compute (HPC) scaling. Next, wafer-scale integration pushes silicon integration to the extreme. Finally, Chip-on-Wafer-on-PCB (CoWoP) may create a new middle architecture where the platform PCB becomes part of the governed realization corridor.

Therefore, it’s not only a packaging phenomenon; it’s also about system realization.

CoWoS: The proven advanced packaging path

CoWoS has become one of the most important advanced-packaging architectures for AI accelerators and HPC silicon. It enables logic die, HBM stacks, and high-density interconnect to be integrated through an interposer and then connected to a package substrate and board.

The strength of CoWoS is apparent. It provides high-density die-to-die and die-to-HBM connectivity, supports large AI/HPC modules, and has become a production-proven integration path for high-bandwidth systems. However, CoWoS also exposes the limits of the modern package stack. See the complex corridor below:

Die/HBM → interposer → package substrate → PCB → voltage regulator module (VRM)/system

The package substrate must support escape routing, power delivery network (PDN) distribution, coefficient of thermal expansion (CTE) transition, mechanical stability, manufacturing yield, decoupling strategy, signal integrity (SI)/power integrity (PI) control, warpage management, and board attach reliability. And as package size increases, these challenges become more critical.

Many of the hardest problems in advanced AI packaging aren’t located in silicon; they occur in the package and package-to-board realization path.

• Warpage
• Substrate availability
• Package size
• Thermal gradients
• PDN impedance
• Loop inductance
• dI/dt response
• Decoupling placement
• SI/PI discontinuities
• Manufacturing complexity

In other words, CoWoS is powerful, but the package substrate becomes a major convergence burden. This is why glass-core substrates are receiving so much attention.

Glass substrates help, but they don’t remove corridor

Glass can improve dimensional stability, reduce warpage, provide better CTE control, support finer routing environments, and improve vertical power-delivery paths with through-glass vias (TGVs). For large AI/HPC packages and future electro-optical integration, these advantages are meaningful.

But glass should not be treated as a complete escape from package realization complexity. In most practical glass-core substrate architectures, the glass is primarily the core and the build-up layers still there. That means many high-speed routing-density challenges remain concentrated in the top build-up structure.

Moreover, bottom-side routing through the core is still not equivalent to short top-side interconnect. Signals passing through TGVs and returning through lower layers still face discontinuities, parasitics, reference-plane challenges, and SI/PI governance requirements.

So, glass changes the package problem, but it does not eliminate it. This distinction matters because CoWoP is not simply about replacing one substrate material with another. It’s about asking whether the realization hierarchy itself can change.

Wafer-scale integration: The extreme silicon path

Wafer-scale integration takes a different route. Instead of assembling many dies through a package-level integration strategy, it expands the silicon system itself. The result is an extremely large compute fabric with direct wafer-level integration, specialized power delivery, cooling, redundancy, and system infrastructure.

This can be technically powerful because it removes many conventional package boundaries and creates a very large on-wafer compute fabric. At the same time, however, wafer-scale integration does not eliminate realization complexity. It relocates it.

The board, power architecture, cooling system, mechanical structure, redundancy strategy, yield-management approach, and system-level service model must all adapt around a very large silicon platform. A useful way to summarize the difference is that wafer-scale integration expands silicon until the system must adapt around it. That can be attractive for certain AI workloads and specialized systems, but it’s not necessarily the most flexible path for every AI accelerator, custom ASIC, chiplet platform, or memory-rich architecture.

CoWoP: A possible middle architecture

CoWoP is interesting because it may offer a third path. Instead of the traditional path comprising die/HBM, interposer, package substrate and PCB, CoWoP points toward a shorter realization path.

Die/HBM → interposer/wafer-level structure → platform PCB

The deeper architectural value is not simply cost reduction. The deeper value is that CoWoP may change the power, memory, mechanical, and system-realization architecture. If the package substrate is reduced or removed, the system no longer needs to carry as much of the convergence burden through three separate layers: interposer, package substrate, and PCB.

Instead, the corridor becomes more direct. However, this directness should not be oversimplified. A realistic CoWoP architecture cannot simply assume that a fine-pitch silicon interposer can land directly onto a platform or PCB without a transition strategy.

The most important challenge may be the transition between wafer/interposer precision and PCB manufacturability. That transition may define whether CoWoP becomes a practical system architecture or remains only an attractive concept.

Dr. Moh Kolbehdari is senior director of IC/packaging at Socionext US.

Editor’s Note

This is Part 1 of the mini-series on advanced packaging. Part 2 continues with the advanced CoWoP concept: pitch translation, transition patches, VRM and memory placement, UCIe routing, and trusted realization governance.

Related Content

• True Wafer-Level Packaging
• Wafer Level Chip Size Package (WLCSP) Guidelines
• Intel’s Embarrassment of Riches: Advanced Packaging
• Nvidia, TSMC, and advanced packaging realignment in 2025
• Intel flash move could put wafer-level packages on the map

The post CoWoS, wafer-scale and CoWoP: Why AI packaging bottleneck is moving appeared first on EDN.

Ones and zeroes: are clustered or spread out bits better? “It depends,” is the answer. Well, at least sorta.

In the Comments section of a recent Design Idea for a DAC (Reference 1), one reader expressed a full-throated preference for an alternative to the common type of PWM used therein. For this “common” PWM, the ones in a repetitive cycle are “clustered” together, as are the zeroes. The reader’s preferred alternative is a “spread” type, in which the ones and zeroes are evenly disbursed within each cycle.

The clustered PWM tends to concentrate energy toward the lower frequencies, versus toward the higher with the spread PWM. Noting the relative ease of filtering out the higher frequencies, the reader argued that a microcontroller implementing the spread PWM filtered by a first order low pass (single resistor, single capacitor) filter was superior to the clustered version followed by a more complex third order filter (three pairs of these components.) So, which is the better choice? Let’s take a look.

The job of a PWM filter

PWMs generally produce repetitive sequences of NO ones and NZ zeroes of length N = NO + NZ. A sequence’s filtered resolution is 1/N. Its duty cycle (DC) is its average value, NO / N. The filter will take some settling time TS to get to within some value VST of a new DC. And as long as DC is neither zero nor one, there will be an AC “ripple” signal of some level at the filter output.

Not only must the ripple signal’s contribution to TS be considered, but its post-setting time peaks and valleys must be closer than some error value VRip to DC. Typically, VRip is set to .5/N. The ideal filter meets this requirement while minimizing TS for a VST of 1/N. These requirements must hold for all DCs and transitions between them.

Verdict first, then the trial

With apologies for my paraphrase of a famous quote from Lewis Carroll’s Queen of Hearts, there’s enough math and batch file simulations required to adjudicate this PWM shoot-out that I thought it best to present the somewhat surprising (to me at least) conclusions without forcing you to first endure the derivations (perhaps this reported result will spur an interest in that math). Figure 1 provides the summary:

Figure 1 This graph shows the settling time TS for clustered and spread PWMs at various clock speeds. The spread filter employs a single resistor and capacitor; the clustered, 3 pairs of the same (see Table 1 for filter details.) Dividing the clock frequency by a factor multiplies the settling time by that same factor. The error VST at the settling time is 1/N. The post-settling time absolute maximum ripple error VRip is .5/N.

If implemented fully in hardware, such as with an FPGA, it would be possible to clock both PWM types at the same rate and compare their performances. For PWMs of more than 8 bits, the spread PWM (purple trace) with a first order analog filter does indeed settle faster than its clustered competitor (red trace) with a third order filter. The situation is reversed for PWMs of less than 8 bits. A simple explanation for this behavior is that below 8 bits, the clustered filter’s time constants turn out to be less than those of the spread, and the situation reverses above 8 bits. However, it’s worth noting that matched clocking is not possible in a microcontroller.

In a microcontroller, until a change in duty cycle is required, an initialized, clustered PWM can run indefinitely without further processor intervention. It can also benefit from the fastest clock available to the controller. Not so with the spread PWM; it requires code to be executed every PWM clock cycle period. I have assumed 6 machine cycles to execute this spread code within an infinite loop (blue trace). As such, only 16 bit and lengthier PWMs will favor the spread option.

Of course, if you need the processor to do more than just run a spread PWM, these additional functions will increase the effective spread clock period well beyond a mere 6 machine cycles. Obviously, this increases the settling time of the associated filter. And by the way, any non-PWM code had better take a constant number of clock cycles to execute, or the spread PWM output will jitter and its accuracy suffer. The less-than-pristine “cherry on top” is that processor interrupts while supporting a spread PWM are problematic.

PWM bits	Sequence length	Spread R·C/T: filter time constant / clock period	Spread settling time TS (ms), 1/6 MHz clock	Spread settling time TS (ms), 1 MHz clock	Clustered filter	Clustered settling time TS (ms), 1 MHz  clock
1	2	9.102E-01	6.00E-03	1.00E-03	See Reference 2 which points to a spreadsheet for filter design	7.92E-04
2	4	3.228E+00	3.00E-02	5.00E-03		3.32E-03
3	8	7.810E+00	1.08E-01	1.80E-02		1.01E-02
4	16	1.696E+01	3.12E-01	5.20E-02		2.93E-02
5	32	3.527E+01	8.04E-01	1.34E-01		8.32E-02
6	64	7.187E+01	1.97E+00	3.29E-01		2.34E-01
7	128	1.451E+02	4.67E+00	7.78E-01		6.53E-01
8	256	2.915E+02	1.08E+01	1.80E+00		1.81E+00
9	512	5.843E+02	2.24E+01	3.74E+00		4.98E+00
10	1024	1.170E+03	5.05E+01	8.42E+00		1.36E+01
11	2048	2.341E+03	1.12E+02	1.87E+01		3.71E+01
12	4096	4.684E+03	2.48E+02	4.13E+01		1.00E+02
13	8192	9.369E+03	5.42E+02	9.03E+01		2.71E+02
14	16384	1.874E+04	1.11E+03	1.85E+02		7.28E+02
15	32768	3.748E+04	2.40E+03	4.00E+02		1.95E+03
16	65536	7.496E+04	5.17E+03	8.61E+02		5.21E+03
17	131072	1.499E+05	1.11E+04	1.84E+03		1.39E+04
18	262144	2.999E+05	2.36E+04	3.94E+03		3.68E+04
19	524288	5.997E+05	4.81E+04	8.01E+03		9.75E+04
20	1048576	1.199E+06	1.02E+05	1.70E+04		2.58E+05
21	2097152	2.399E+06	2.16E+05	3.59E+04		6.80E+05
22	4194304	4.798E+06	4.55E+05	7.58E+04		1.79E+06
23	8388608	9.596E+06	9.57E+05	1.59E+05		4.71E+06
24	16777216	1.919E+07	1.94E+06	3.23E+05		1.24E+07

Table 1 This table details spread and clustered settling times and filter characteristics. Multiply the R·C / T term by the desired spread PWM clock period T to obtain the product of the resistance and capacitance of the first order analog filter (see Figure 4).

To avoid large settling times, recall the option of operating a most significant and a least significant 8-bit PWM simultaneously and adding their outputs as seen in Reference 2. A filter with a 16-bit settling time can be swapped for one with a much shorter 8-bit settling time. Should you want even more resolution, use this concept to add a third PWM.

All this being said, read on for some important sequence characteristics and how best to implement k-bit spread PWMs where k = 1, 2, 3… 24.

Clustered-bit PWM sequences

Clustered-bit PWMs’ NO ones and NZ zeroes each appear in contiguous streams. An example of a waveform for such can be seen in Figure 2. Most microcontrollers can implement these with no software overhead. Just “set ‘em and forget ‘em”: specifically, program the count (NO – 1) after which a one-to-zero output transition is to be produced, and the count (N – 1) after which the counter returns to 0 and the output to a one. The PWM goes on its merry way with no further intervention necessary from executable code unless a change in the value of the duty cycle DC is required.

8 and 16-bit counters are typically available, and so DC values of A / B can be had for any integers such that 0 ≤ A ≤ B ≤ either 28 or 216, respectively. Typically, these counters can be clocked from the same high frequency clock source used to execute the microprocessor instruction set. This is useful because in general, the higher the frequency, the shorter the settling time of the filter needed to suppress the ripple.

Figure 2 This plot is of a clustered-bit PWM where NO = 16, N = 256, and T = 1uS.

Spread-bit PWM sequences

Another type of PWM produces the same number of ones and zeroes in a cycle, but spreads these binary values as evenly as possible. An example can be seen in Figure 3.

Figure 3 With this spread-bit PWM, NO = 16, N = 256, and T = 1uS.

Notice that lowest frequency of the spread PWM is far higher (16 times) than that of the clustered one. Accordingly, a faster-settling filter can be used to suppress the ripple. So what rule governs the positions of the ones and zeroes in the spread sequence? A very simple one.

Consider a parameter X which can take on the values 0, 1, 2… or N – 1. Y is periodically updated to the value of (Y + X) modulo N. If an update reduces Y, the PWM output is one; otherwise, it’s zero. The DC is X / N. This process has at least two important properties:

1. The period of the PWM sequence is N. This can be shown by considering a parameter W upon which the process W = W + X is repeatedly performed (no modulus is involved in the W update.) If the initial values of Y and W were both C, then Y = (Y + X) modulo N and (W + X) modulo N would be equal after each process step. N steps later, W would be C + N X. For any X, (C + N · X) modulo N is C. Since the moduli of W and Y are always equal, C is also the value of Y after N process steps. And so for any X, the PWM sequence is periodic in N.
2. To gain insight as to how spreading works, consider when X is 0. Y would never be reduced, and so there would never be a PWM output of one. If X were 1, the PWM would produce a one only once every N steps. If X were increased, there would be ones approximately (if not exactly) every N/X steps. As X approached N/2, the proportion of ones in the output would increase, but as long as X ≤ N/2, ones would never appear in succession. For X ≥ N/2, there would never be any zeroes in succession. And as X approached N, a reversed version of the aforementioned progression of ones would apply to the zeroes.

How might this process be executed on a basic 8-bit microcontroller? The simplest implementation would be to set N to 28 and periodically hijack a portion of the processor’s executable bandwidth to run the process. The following code implements a spread 8-bit PWM of duty cycle X / 28, where the value of X is in register r17 and that of Y is in register r16:

ADD r16, r17 ; r17 holds the value of NO which can be anywhere from 0 to 28-1. ; r16 is a simple accumulator which overflows periodically. ROL r20 ; The carry bit ( 0 or 1) from the prior addition goes to bit 0 of r20. OUT PORTB, r20 ; Bit 0 of the PORTB GPIO register takes on the carry bit value.

Of course, you can include a few more instructions so that the other PORTB bits are unaffected. It’s important to note that this code must be executed regularly. Aperiodic, “jittery” execution will impact the accuracy of the filtered value of the output stream. This means that all non-PWM code must always take the same amount of time to execute, making interrupts on the processor problematic.

Want a PWM with more resolution? Place the following instruction after the existing ADD:

ADC r18, r19 ; r19 is the MSbyte of the input X and r17, the LSbyte.

This additional instruction enables a 16-bit duty cycle of X / 216. It’s obvious how to further increase resolution by additional factors of 28 to obtain 224, etc.

The inputs of spread PWMs can range from X = 0, 1, 2… to N-1. But if N is limited to integral powers of 28, there’s a very big jump (a factor of 28) of sequence lengths between these options. That means a proportional jump in filter cutoff frequencies and, more importantly, in settling times. Fortunately, a finer range of selections is readily available. Simply limit the allowable values of X to those for which X / 2k is an integer, where k = 1, 2… log2(N)-1. The result is a (log2(N) – k) bit DAC.

The settling times of filters meeting the ripple suppression requirement are now available in increments of a factor of 2. Of course, a spread-bit DAC can have any integer value for N. But values other than 2k require additional code which must explicitly compare Y to N to generate a carry, and then conditionally update Y by subtracting N from it. Also, the spacing between successive values of X could vary unless all N possible input values were used. Perhaps a better approach would be to operate multiple PWMs simultaneously, whose outputs are weighted differently by a factor of 28. The relatively quick settling time of an 8-bit filter would be a benefit.

Analog filters

For PWM filter designs, it’s necessary to determine the input-dependent output sequence whose ripple which is the most challenging for a filter to adequately suppress. As discussed in Reference 3, the worst case for a clustered PWM is a 50% DC. To achieve reasonable settling times (TS) to within an error VTS of 1/N while meeting the Vrip requirements of .5/N, a third order lowpass filter is employed. The structure of such a filter is seen in Figure 4. The referenced Design Idea offers a downloadable spreadsheet which designs filters to users’ specifications of PWM cycle frequency and of peak-peak ripple as a fraction of full-scale output.  It was used to populate the settling time entries in Table 1 for the clustered PWM.

For the spread PWM, the worst case was determined by running simulations of all 256 output sequences of an 8-bit spread PWM applied to a first order filter (see Figure 4 again.) But what first order filter? To answer this question, I started by assuming (perhaps counterintuitively) that the worst case for ripple suppression occurs for 1 one, that is, when PWM input X = 1. (Since zeroes and ones are fully symmetric, this is equivalent to the case of 1 zero, or X = 255.) What will the ripple troughs and peaks look like for each input value at the output of a filter with a time constant selected to provide the necessary ripple suppression for X =1 only?

Figure 4 With these first and third order low-pass analog filter structures, the filters are buffered with op amps because their inputs employ resistors of high values. This is done to limit the errors imposed by the unequal resistances of the logic high and low outputs of ICs such as the 74AC04 which drive the filter inputs (Reference 4).

First we have to find that time constant. We start by writing equations for ripple starting at time t = 0. Here, R and C are the first-order filter components, and NO + NZ = N as before. The filter output is:

1. V0 (immediately before a zero-to-one transition)
2. V1 = V0·e-NO·T/(R·C) + (1 – e-NO·T/(R·C)) (immediately before the next one-to-zero transition)
3. V2 = V1·e-NZ·T/(R·C) (immediately before the next zero-to-one transition)

in the steady state, after the filter settles from a change in duty cycle, V2 = V0. Solving:

4. V₁ss = (1 − e-NO·T/(R·C)) / (1 − e-N·T/(R·C)) + 1/N (ripple peak)
5. V₀ss = 1/N – (e-NZ·T/(R·C) − e-N·T/(R·C)) / (1 − e-N·T/(R·C)) (ripple trough)
6. Vrip = V1ss – V0ss = (1 – e-NO·T/(R·C)) · (1 – e-NZ·T/(R·C) ) / (1 – e-N·T/(R·C) ) (peak – trough)

Setting V₁ss in #4 above to .5/N for N = 28 and solving numerically, a value of 291.5 is obtained for the unit-less term R·C / T. Setting V0SS in #5 to .5/N with R·C / T = 291.5 yields a smaller error than .5/N for the trough; the peak error is the larger of the two (tabulations of this term for a range of N values were calculated from #4 and appear in Table 1). In a simulation, T was set to 1uS, R to 1MegΩ and C to 291.5pF. Output sequences resulting from inputs from 1, 2… 255 were applied to an 8-bit spread PWM.

Figure 5 shows a graph verses the input X values of the maximum ripple deviations from DC and of half the peak-to-trough differences. It’s clear that the biggest error is associated with inputs both of 1 one and of 255 ones (1 zero). This filter time constant 291.5uS does indeed limit the deviation from the duty cycle of 1/N (1/256) to .5/N times the PWM’s full-scale output, one half of the PWM resolution, and an input of X = 1 does yield the worst-case ripple. For any clock period T, simply multiply the Table 1 unit-less parameter R·C / T by T to obtain the filter’s R-C time constant.

Figure 5 This graph shows the filter output deviations from DC in the steady state vs. input values of 1, 2… 255 for an 8-bit spread PWM. A 100mS wait was employed before measurements to ensure settling, more than 300 times the 291.5uS filter time constant.

It might be surprising that the worst ripple peaks are associated with a single one or zero in the output sequence. But a little thought reveals that a single pulse is the case where the lowest frequency f1 = 1/(N·T) Hz that the PWM can produce has the largest amplitude. Note that input values which are powers of 2 have the lowest maximum errors. This is in part because they have no energy at f1 Hz. I have spot-checked sequences of N-4096 and those for N < 256 and found an input of X = 1 to consistently produce the maximally deviant ripple.

Settling times of the spread PWM filter

Tired of the math by now? You ain’t seen nothin’ yet!

Because an analog filter is being driven by a digital sequence, difference equations can be used to calculate the filter output. The worst case for setting time is when the filter output at time t = 0 is DC = 1 (NO = 256) and the input transitions to NO = 1. Then:

7. y[k]      =          a*y[k-1] + (1-a)*x[k],              y[0] = 1,           a = e-T/(R·C),       k = 0, 1, 2…

where x[k] = 1 when k modulo N = 0, and 0 otherwise.

Ripple peaks occur when x[k] = 1 and troughs when k modulo N = N – 1 =255 (immediately before a peak.) We have:

8. Yp[k·N]             =          ak·N + (1 – a)*(1 – a(k+1)·N) / (1 – aN),                   ripple peaks
9. Yt[k·N – 1]        =          ak·N -1 + (1 – a)*(aN-1 – a(k+1)·N-1) / (1 – aN),          ripple troughs
10. yp_SS                 =          (1 – a) / (1 – aN)                                                steady state ripple peak
11. ypp                             =          (1 − a)(1 − aN−1) / (1 − aN)                                steady state p-p ripple
12. k1st_peak = N * Ceiling [ Log { ( (2/N) · (1 – b) + a – 1) / (1 + (a – 2)·b) } / Log(b) ],       b = aN

where k1st_peak is the smallest value of k for which all ripple peaks are less than 2/N.

It’s worth taking a look at what is going on for the worst-case ripple when N = 256. See Figure 6.

Figure 6 This graph represents data for a spread PWM with N = 256 and filter outputs starting at one (1 volt.) At time t = 0, the red trace reflects a change of input to X = 1 and the blue, an input change to X = 0. X = 1 takes longer to settle because it spends 1/N of its time with an input of one, whereas X = 0 spends all of its time with an input of zero.

From #12, k1st_peak is the smallest value of k for which ripple peaks y[k·N] are less than or equal to 2/N. In this case, that corresponds to k = 8·N at 2.048mS ( y[7·N] is slightly larger than 2/N.) Finally, #7 is used to iterate all integer values of k from 7·N to 8·N find the smallest value of k = kS (that is, the first time) for which y[k] and all subsequent values of y[k] are less than 2/N. The settling time is then T·kS. This procedure is used to populate in Table 1 the spread PWM settling times at various cycle lengths N for a 1MHz clock.

In conclusion…

PWMs can be implemented by microcontrollers. For a clustered-bit PWM, no further intervention is required by the controller beyond the cycle length of a programmable counter and the latest value of DC. Typically, the counter can be advanced by the highest speed clock available to the controller. But for a spread-bit PWM, a supportive block of code consisting of multiple instructions must be executed periodically This must be done at consistently timed intervals if accuracy is to be maintained.

To allow the processor to perform other functions, these intervals, the effective period of the spread clock, can be quite long in comparison to those of the clustered-bit PWM. Longer clock periods lengthen the settling time of the filter needed to suppress a PWM’s ripple. Granted, the spread sequence has generally much less lower frequency energy than a comparably clocked clustered sequence and therefore can employ a faster settling time filter for ripple suppression. But in practice, microcontrollers cannot clock code-driven spread PWMs at the rates of clustered ones, which have inherent hardware support. Comparable resolution spread PWM filters generally take longer to settle than those of their clustered cousins when microcontrollers implement these PWMs.

It’s intriguing to consider that the spread PWM discussed herein can be considered to be a first order delta-sigma modulator (Reference 5). The overflow of the registers can be thought of as an accumulator which, when instead of overflowing, adds a value of -N to its input X. Modulators of order higher than the first can shift even more low frequency energy to higher frequencies, relaxing ripple-suppression requirements even more and reducing settling time. Most commercial implementations of such techniques replace analog filters with digital versions thereof which then drive conventional multi-bit DACs, all implemented on a single IC.

If our PWM types were to be implemented in hardware such as an FPGA, their clock rates could be identical. As per Table 1, at identical clock rates, some sequence lengths N would favor the spread PWM with a simple single R-C pair (first order) filter, and others which would favor the clustered PWM with its three-pair (third order) R-C filter. However, the spread PWM would also benefit by replacing its first order filter with a third order one, something I plan to discuss in a forthcoming Design Idea.

PWMs: the gift that keeps on giving!

References:

1. Custom design PWM filters easily
2. Ibid, Figure 3.
3. Ibid
4. Ibid, see the SN74AC04-induced errors section.
5. https://www.ti.com/lit/an/slyt423a/slyt423a.pdf

Christopher Paul has worked in various engineering positions in the communications industry for over 40 years.

Related Content

• A nice, simple, and reasonably accurate PWM-driven 16-bit DAC
• Parsing PWM (DAC) performance: Part 1—Mitigating errors
• Parsing PWM (DAC) performance: Part 2—Rail-to-rail outputs
• Parsing PWM (DAC) performance: Part 3—PWM analog filters
• Parsing PWM (DAC) performance: Part 4 – Groups of inhomogeneous duty cycles

The post Implementing a DAC: The battle of the PWMs appeared first on EDN.

Floating-point computations dominate the landscape of all AI/ML compute but also in automotive, avionics and healthcare. While performance and compute errors dominated the landscape of floating-point design and verification, power optimizations forced designers to use non-standard precisions such as FP4, FP8, BF16, and so on. So, mixed precision computation has become prominent in modern-day design.

Figure 1 Here isa a sneak peek at floating point compute in AI designs. Source: Axiomise

However, a new paradigm of transprecision compute is also emerging. Tagliavini et.al captured this beautifully in their paper coining the term transprecision floating-point computing. According to the paper, transprecision computing is an area where “rather than tolerating errors implied by imprecise HW or SW computations, systems are explicitly designed to deliver just the required precision for intermediate computations”.

Mixed precision vs transprecision

Mixed precision and transprecision are closely related, but they are not the same thing. Mixed precision is mainly an algorithmic/use pattern; transprecision is a broader system and architecture paradigm. Mixed precision means using two or more fixed numeric formats within one algorithm or kernel. Transprecision goes further: it’s about designing the hardware, software, and algorithms so that the precision itself is a tunable resource.

In short, mixed precision is combining a few existing formats in one computation for performance/energy, with accuracy recovered by algorithmic tricks. And transprecision is an end-to-end paradigm where precision is a first-class, tunable knob, and the system supports many possible precisions (not just, for example, 16-bit/32-bit) to meet accuracy/energy goals.

The benefits are clear. Exploit lower precision where it’s safe, allowing better balance of performance and throughput, and lower energy consumption, thereby cooler chips, but maintain full-precision (higher) accuracy where needed. Specifically, formats such as FP16 and BF16 allow hardware to execute more FLOPs per cycle, often giving 1.5-3X speedups in deep learning workloads. Transprecision architectures can achieve multi‑x speedups by vectorizing and simplifying datapaths for small formats (for instance, 8-bit or 16‑bit “minifloats”).

Verification challenges

Mixed-precision and transprecision computing introduce substantial verification challenges because correctness is no longer tied to a single, well-understood format, but to a tapestry of interacting precisions, formats, and rounding behaviors across the pipeline. Mixed-precision and transprecision computing create a significantly harder verification problem than conventional floating-point design because correctness must be established not only within each individual format, but also across the boundaries between them.

In these systems, values may be computed, accumulated, converted, rounded, and stored at different precisions, so verification must account for interactions between multiple exponent ranges, mantissa widths, rounding modes, exception rules, and format-conversion paths rather than checking a single uniform arithmetic model. This increases the risk of subtle failures such as incorrect narrowing or widening behavior, loss of precision at format boundaries, inconsistent NaN and infinity propagation, mismatched exception flags, non-equivalent fused and non-fused results, and corner-case errors involving subnormals, saturation, or directed rounding.

The challenge is amplified further in configurable or transprecision FPUs, where the same hardware datapath may serve several formats and custom numerical types, making it easy for implementation shortcuts or shared logic to satisfy one format while violating the architectural intent of another.

As a result, effective verification of mixed-precision and transprecision designs requires more than numerical result checking: it demands format-aware reference models, carefully targeted boundary-case stimulus, cross-format property checking, and systematic validation of rounding and exception behavior under every supported precision configuration. The challenges of microarchitectural implementation are too many to capture here so we will defer to these for a separate blog, but pipelined implementations offer an interesting cross-dimensional challenge for verification.

Traditional verification methods

Simulation-based verification, whether directed or constrained-random, is inherently inadequate for mixed-precision and transprecision floating-point designs because it can exercise only a vanishingly small fraction of the enormous input and state space. Moreover, it’s biased toward scenarios that verification engineers think to test.

Even with sophisticated UVM environments and large regression farms, most tests focus on typical operating ranges and a limited set of corner cases, leaving huge gaps around precisely those conditions where multiple formats interact: operands that sit exactly on format boundaries, rare combinations of subnormals with different exponents, intricate sequences of narrowing and widening conversions, or subtle interactions between fused operations, rounding modes, and exception flags.

Many of the most damaging floating-point bugs historically have come from such corner cases that were numerically benign for most inputs but catastrophically wrong for particular patterns that simulation never hit. In a design that supports several precisions and custom formats, the number of distinct cross-format behaviors quickly explodes, making it practically impossible to gain real confidence from coverage metrics alone. That’s because hitting each branch or bin does not guarantee that all critical numerical combinations and flag behaviors have been validated.

Formal methods-based solutions

Formal verification, in contrast, can reason symbolically about entire classes of inputs and states at once, proving that key arithmetic, rounding, and exception properties hold for all operand values and all supported format combinations within a given block, and thus is uniquely positioned to close the coverage gap that simulation-based methods cannot realistically bridge. However, while C-to-RTL equivalence checking has been in use for many years to establish formal equivalence through proofs, deploying formal methods on direct pipelined implementations of RTL is not easy with C-to-RTL based tools.

What we need is a homogeneous architecture whereby we can reason about correctness of RTL micro-architectural implementation directly using a golden reference implementation in SVA, exploiting the abstraction-based techniques in property checking. This is why we built floatrix.

It’s an app offered as part of the axiomiser platform that can be automatically configured at runtime through a GUI to verify a range of FP precision formats through proofs obtained by exercising custom SVA properties on actual designs implemented in Verilog or VHDL requiring minimal human interaction; and most importantly requiring zero model minimization that is the norm in any C-to-RTL based formal equivalence checking solutions.

SVA models used in floatrix have been goldenized against the Berkeley Hardfloat models for IEEE-754 compliance. For non-standard precisions, we follow the reference guides of the implementation to adapt the models.

We have deployed floatrix on several designs since its launch in September 2025. We continue to find interesting bugs. Recently, we identified a tinniness issue on the FPU used by the OPENHW group. The Github ticket has more details.

In this article, we describe an interesting bug we caught in floating-point dividers found in the fpnew design (again part of the OPENHW group), using our floatrix app. In the next section we describe the bug itself and then we elaborate on its significance, and whether bugs like these are likely to happen in other designs. Our analysis covers the broader scope of what happens with designs in mixed-precision format, and gaps in verification causing these bugs to be missed in the first place.

Details of the bug

Before we describe the bug, let us capture some of the basic definitions.

Inexact flag: Raised when the rounded floating-point result is not equal to the mathematically exact result, meaning some precision was lost in rounding (this can accompany normal, overflowed, or underflowed results).

Underflow flag: Raised when a non-zero mathematical result is so small in magnitude that, after rounding to the target format, it becomes tiny (typically subnormal or zero); under IEEE‑754’s default rules, this is signalled only when that tiny result is also inexact.

Scenario

The inexact and underflow flags should be set if the unbound exact result (out of format) is 1×2-140 and the bounded result should be 16’h0000. Moreover, in the case of rounding up, the expected result should be 16’h0001. However, in FPnew, the result is always 16’h0000 with no exception flags raised.

Root cause

Root cause might be from performing the operations using single-precision arithmetic and then converting back to BF16.

Detection methods

The bug was caught using the floatrix underflow flag checks.

Figure 2 Waveform shows the special underflow case in division. Source: Axiomise

Why this class of bug is realistic?

Bugs like this can happen in real designs, especially in floating-point units that mix internal higher-precision arithmetic with lower-precision output formats such as BF16.

A bug like this reflects a common implementation pattern where the datapath computes in a wider internal format, such as FP32, and then converts or packs the result into a narrower format. If exception logic is tied only to the internal format and not to the final target format, the design can silently produce a numerically plausible output while missing required flags.

This is especially plausible in trans-precision designs. BF16 has the exponent range of FP32 but much less precision, which makes conversion-stage edge cases more common. A value can be representable or exact internally yet still underflow or become inexact when rounded to BF16. If the final conversion step is treated as a formatting step instead of a full IEEE-aware operation, underflow and inexact can be lost.

Reuse of a FP32 datapath for BF16

Modern fpu designs may implement a single “main” datapath (often FP32) and derive lower-precision results (BF16) by:

1. Computing in FP32
2. Rounding/packing down to the architectural format

For this bug, it means:

1. The internal FP32 computation is perfectly normal and may produce a small, exact, subnormal value.
2. Because that internal value is exact, the FP32 underflow and inexact logic quite reasonably decides “no underflow, no inexact”.
3. If the design then blindly packs to BF16, the BF16 representation of that exact value can be 0x0000 or 0x0001, which is architecturally tiny and inexact from the BF16 point of view, but no new flags are generated.

So, the specific condition “exact subnormal in FP32, non-representable in BF16” is not rare; it’s exactly what you get whenever BF16 sees the far tail of the FP32 subnormal range.

Flag logic attached to the wrong format

In a typical implementation:

• The main datapath correctly implements all rounding modes in FP32.
• The BF16 path is implemented as a simple truncation, or as a hard-coded “round-to-nearest-even” micro-operation, ignoring the global rounding-mode control.

For this bug, that architectural decision has a precise consequence:

• Underflow and inexact are defined with respect to the architectural result format and rounding (here BF16, with “tininess after rounding” for RISC‑V BF16).
• If flags are tied to the internal FP32 representation, any case where FP32 is fine but BF16 underflows will be mis‑flagged.

The bug is therefore a very plausible pattern and can occur in other kinds of FP implementations because it reduces duplication of flag logic but is architecturally wrong for BF16 arithmetic.

RISC‑V BF16 underflow definition vs implementation shortcut

RISC‑V BF16 explicitly says:

• Tininess is detected after rounding.
• Underflow is signalled only when the result is both tiny and inexact.
• The tininess detection itself conceptually uses rounding as if the exponent were unbounded in the target format.

A shortcut implementation for BF16 in a FP32-based unit often does:

“Let the FP32 unit compute and round; then chop its bits down to BF16.”

For this bug, perhaps that shortcut misses exactly this:

• “Tiny and inexact” must be interpreted in BF16, not in FP32.
• A result can be “non-tiny and exact” in FP32, yet “tiny and inexact” in BF16.

So, the focused risk factor is not generic underflow subtlety; it is the temptation to reuse the FP32 tininess logic instead of implementing BF16-aware tininess-after-rounding. That shortcut directly creates the buggy behavior.

Directed rounding applied only at the FP32 level

This case also involves a mode where “round to max” (or analogous directed rounding) should drive the BF16 result from 0x0000 to 0x0001. We suspect, this leads to:

• FP32 sees the tiny result as exact, so the rounding mode does nothing interesting at that level.
• BF16 should use the rounding mode to decide between 0x0000 and 0x0001, but the conversion block ignores it.
• Consequently, the result is always 0x0000, and the flags never see the inexact/tiny condition.

So, the specific vulnerability of rounding-mode control is not propagated into the BF16 block, yet the ISA treats the BF16 operation as architecturally rounded in that mode.

Verification gaps specific to this pattern

For bugs like these to escape into silicon, we imagine that two very concrete verification gaps typically exist:

• Format-mismatch in checkers: The reference model or scoreboard checks only the numeric value in FP32, or it narrows in the same way as the RTL (for example, using a float32‑>BF16 helper that also ignores flags), so it cannot see that BF16 flags differ from the spec.
• Lack of subnormal+narrowing directed tests: Random and ISA-level tests hit plenty of BF16 arithmetic, but almost nothing in the region where:

1. The true value is representable as a tiny FP32 subnormal.
2. That value is below the BF16 subnormal range.
3. The rounding mode is a directed one that should change 0x0000 to 0x0001.

These are not generic underflow issues; they are exactly the missing cases needed to expose flags generated in a wider format, and then silently narrowed.

Other similar bug patterns

This bug fits into a broader family of real floating-point design bugs:

1. Flag-silent narrowing conversions: FP32 to BF16 or FP32 to FP16 loses information, but the design fails to raise inexact or underflow.
2. Wrong rounding-mode application: The internal result is correct, but the final conversion stage ignores directed rounding such as round-toward-positive or round-to-max.
3. Fused/non-fused mismatch: FMADD produces different flags than a mathematically equivalent MUL followed by ADD because the implementation handles flags at the wrong stage.
4. Flush-to-zero leakage: A supposedly IEEE-compliant path accidentally behaves like flush-to-zero in one stage, especially for subnormal intermediates.
5. Tininess detection mismatch: The design effectively uses one tininess rule internally and another assumption in verification or architectural expectations.

These are all realistic in designs that support multiple formats, configurability, or internal reuse of a higher precision datapath.

Practical impact

The practical impact of these kinds of bugs can be profound, even if the affected values are tiny. In many applications, the numerical difference may seem small, but the bug still matters because:

1. Exception flags may drive diagnostics, fallback logic, or compliance tests.
2. Image, DSP, and ML pipelines can be sensitive to repeated bias near zero.
3. Safety or standards-driven environments care about architectural correctness, not just approximate numeric usefulness.

Why formal models for floating-point designs

Mixed-precision and transprecision floating-point designs offer compelling benefits in performance, power, and area, but they also amplify the risk of subtle correctness issues that are extremely hard to detect with traditional simulation-based verification alone.

The bug analyzed in this article illustrates how easy it is for architectural intent to be violated when arithmetic is performed in a wider internal format, flags are generated with respect to that format, and the final narrowing step is treated as a “mere” formatting operation rather than a first-class floating-point transformation with its own rounding and exception semantics.

This pattern is not unique to a single core or vendor; it’s a natural by-product of reusing FP32 datapaths to implement BF16, separating execution, rounding, conversion, and flag generation, and relying on checkers that mirror the same implementation shortcuts. More generally, the same structural causes can lead to a family of related failures: flag-silent narrowing conversions, incorrect application of directed rounding modes, inconsistencies between fused and non-fused operations, flush-to-zero leakage in ostensibly IEEE-compliant paths, and mismatched tininess rules between specification, design, and verification.

Addressing these challenges requires a shift from “best-effort” simulation to exhaustive, property-driven reasoning. By using format-aware formal models, such as those provided by floatrix, it becomes possible to prove that rounding, underflow, overflow, and flag behaviour are correct for all operands and all supported precisions, and to expose bugs that would otherwise hide indefinitely in rarely exercised corners of the state space.

Nicky Khodadad is senior solutions engineer at Axiomise.

Nguyen Vu is formal verification engineer at Axiomise.

Ashish Darbari is Founder and CEO of Axiomise.

Related Content

• Hardware-based floating-point design flow
• Implementing floating-point DSP on FPGAs
• Floating-Point Data in Embedded Software
• How to create fixed- and floating-point IIR filters for FPGAs
• Understanding Peak Floating-Point Performance Calculations

The post Hidden underflow in BF16 divider in mixed-precision FP designs appeared first on EDN.

Need just one more network port than you’ve currently got available (often: none)? A splitter can do the trick; just spend a few extra bucks to make sure you’ve made the right pick.

I’ll begin this teardown with an analogy. Imagine you’re grilling weekend hamburgers for the family. After the patties are cooked (medium-rare, of course), you slot them in buns and load them up with per-recipient preferred extras—lettuce, pickles, tomatoes, onions, mustard, and the like. The one condiment everyone wants is catsup (of course, again). But then you belatedly realize that there’s not enough of the tomato-derived sauce left in the bottle for everyone; specifically, one of the kids is about to be catsup-deprived.

Obviously, this just won’t do. But if you run to the store for more, the food will be cold by the time you get back. Plus, everyone’s already starving. And none of the neighbors, specifically those that you know well enough to even think of knocking on their doors and asking to borrow some of their catsup, are home. But then you remember the spare catsup packets from a recent take-out meal, jammed in the back of the refrigerator. An imminent condiment crisis is averted!

Or take this one. Your four-cylinder car is already paid off, in solid cosmetic condition and (mostly) equally great functional shape. But it just doesn’t have the “get up and go” that you’re now looking for. You could finance a more powerful replacement. But assuming you could even find someone to sell your existing vehicle to, or a dealer willing to take it in trade, you won’t get what you think it’s worth. And did I already mention that the one you already have is debt-free?

But then you realize you’ve only been putting regular (vs premium-octane) gas in it all this time. And/or that it’s been a while since you’ve taken it to the shop for a spark plug swap and broader tune-up. And/or maybe just that its tires are underinflated, or your trunk is overfilled. Rectifying these shortcomings transforms your existing vehicle, making it sufficiently spunky such that you can shelve the alternative of a replacement, keeping money in your pocket in the process.

An RJ45 in every port

What’s this all got to do with technology, specifically with Ethernet splitters? Well, multi-port Ethernet switches commonly come in the following configurations:

• 5-port
• 8-port
• 16-port
• 24-port
• 48-port

(10- and 12- port models, and other variants, also exist but are less common and therefore tend to be much more expensive on a per-port basis).

What happens if, as I’ve repeatedly experienced over the years, I have an eight-port switch  already in service and fully populated, but then add another wired Ethernet device to my LAN (for example, another NAS)? This leaves me needing one more port, but I don’t have any available spares. I could:

• Replace the 8-port switch with a 16-port successor: an expensive transition proposition that also leaves me with a perfectly good but now-unused 8-port switch predecessor, or
• Add a separate 5-port switch to the mix, connected to the original 8-port switch using a short span of Ethernet cable. While this is more economical than the prior approach, it “wastes” a port on both switches, dedicated solely to the interconnect between them, plus it takes up more space on the networking equipment shelf (along with another power strip spot).

Passive deficiencies

But there’s a third option, which I’ll be analyzing today. It’s a splitter, most commonly found in 1:2 ratio variants such as today’s dissection victim, although larger configurations are also available at least in active, versus passive, splitter form. What’s the difference? Passive splitters, as their name suggests, are unpowered (I’m also assuming here that they’re not self-powered, specifically via PoE). They’re also quite inexpensive, as this $8.99-total pair of them exemplifies:

Alas, they’re not a perfect panacea. Not even close. In this particular implementation case, notice the “(Can’t Run Both at The Same TIME)” qualifier right in the product title, conceptually replicated in another stock image, although the embedded verbiage muddies the waters as least as I’m interpreting it:

What’s basically going on with this particular implementation of the concept (with thanks to a knowledgeable Amazon reviewer, whose graphics I’m “borrowing”) is that the eight Ethernet wires flowing into one end of the splitter are duplicated at both connectors on the other end:

The upside? From a performance standpoint, both split-end (see what I did there?) connectors use all eight original-end wires (hold that thought). The downside? If you plug active devices into both “split” connectors at the same time, neither of them will go online. Not to mention all the short-circuiting going on between all three devices mated to the splitter, which should instead be called a duplicator (or maybe an overly complicated and potentially tragic coupler).

In the other implementation of the concept, which as my Amazon reviewer friend points out, often looks identical from the outside, four of the eight original-end connector wires go to one split-end connector, with the other four going to the other.

There are upsides to this variant approach, potentially. No short circuits, for one thing. And depending on how the wiring is handled at the other end of the cable plugged into the splitter’s original-end connector, gear plugged into both split-end connectors may be able to coexist. But since each of them is only using four wires of the total eight-wire strand, they’re each restricted to 100 Mbps peak bandwidth, since GbE connectivity requires the use of all four two-wire sets.

Active rationalization

Powered (active) splitters are the real deal. Essentially, they’re mini-switches, with a subset of the total number of connectors found in a “true” five-port (or larger) switch. Take today’s Goalake 2:1 patient, for example, which set me back only $6.49 post-35%-off-promotion when I bought it from Amazon in December 2024.

Along with its 3:1 sibling, which I’d purchased at the same time for only $9.09.

No inter-device packet collision issues, plus full GbE bandwidth to both “split end” devices, albeit subdivided between them if they’re concurrently transmitting or receiving.

With the stock image out of the way, let’s now look at the “real thing”, starting with box shots accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes, as usual.

Packaging contents

Open ‘er up, and inside you’ll find a slip of paper up top:

with the rest of the goodies below:

Extras first, also including a USB-A to USB-C cable, whose purpose you’ll see shortly:

And now for our patient, initially translucent-swathed:

And now “unclothed”:

This side you’ve already seen in the “stock” image:

These two are, like the bottom, bland:

And this one explains why the aforementioned included USB cable exists:

It’s for the USB-C incoming power connection:

To my earlier “takes up more space on the networking equipment shelf (along with another power strip spot)” crack, this device in contrast is pretty tiny (58.1 mm x 23.4 mm x 62.8 mm). And although you could plug the USB-A end into a dedicated “wall wart”, the power requirements (5V@1A) are low enough that you could instead leverage an already-available and otherwise-unused USB connector coming out the back of a nearby NAS or UPS, for example.

Unsurprising (and highly integrated) innards

Time to get inside. You probably already noticed the four screws, two on each end. And you probably already guessed what comes next:

Turns out, I didn’t necessarily need to remove both ends’ plates; I could slide the PCB out either:

Oh well…nothing wrong with being thorough:

Note the lingering glue on the inside-chassis slot, to hold the PCB in place as originally installed:

Speaking of which, not much of note on this PCB side, save for more glue remnants and the fact that the manufacturer went with multiple smaller LAN transformers per-connector versus one unified per-connector alternative, as I’ve seen in other wired Ethernet-inclusive products.

The other side’s more interesting, albeit only a bit, reflective of the minimized bill-of-materials cost for this low-priced device.

That thermal pad presses up against the lower half of the (aluminum, I presume) chassis when the PCB is in place. Let’s see what’s underneath:

Surprise, surprise (not)…an Econet (later merged with Airoha Technology, both subsidiaries of MediaTek) EN8850DHE five-port switch with embedded 10/100/1000Base-T PHY!

That’s all I’ve got for you today. Reader thoughts are as-always welcome in the comments!

—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.

Related Content

• Teardown: Powerline networking plus PoE
• Malfunctioning Ethernet cable comes up short
• Cutting into a conventional USB-C charger
• Modern UPSs: Their creative control schemes and power sources

The post Dissecting an active Ethernet splitter appeared first on EDN.

In the world of retail, security is not always about cameras or guards; it’s often about technology you barely notice. Electronic article surveillance (EAS) tags are a prime example: small, lightweight devices that quietly safeguard billions of dollars’ worth of merchandise every year. Their strength lies in simplicity; an elegant mix of materials science and signal engineering that creates a reliable deterrent against theft.

For engineers and technologists, EAS tags are more than just retail accessories; they are a case study in how discreet design and robust physics converge to solve a persistent, real-world problem.

Principle of operation: Resonance and detuning

EAS tags are built on the physics of resonance. In RF systems, tag’s circuit is tuned to the frequency of the detection gates, producing a clear signal when energized. Acousto-magnetic (AM) systems rely on magnetostrictive strips that vibrate under alternating magnetic fields, creating a distinct response. In both cases, the tag’s resonance or detuning is what makes it detectable—a simple but elegant exploitation of electromagnetic behavior.

Detection gates: Antennas at the exit

The tall panels at store exits are more than just barriers; they are antennas transmitting and receiving fields. As a tag passes through, it interacts with these fields, altering the electromagnetic environment in a way the system recognizes. That interaction—a resonant “signature”—is what triggers the alarm. Without it, the gates remain silent, underscoring how precise the tag–antenna relationship must be.

The shielding challenge: Countering the Faraday cage

While EAS systems are robust, they face a persistent challenge from tag shielding, a technique where shoplifters use “booster bags” lined with conductive materials like aluminum foil. This creates a Faraday cage—a metal barrier that blocks the electromagnetic or magnetic fields from reaching the tag, preventing it from resonating or “talking” to the detection gates.

Because the tag’s signal cannot penetrate the shield, the system remains silent even as the item passes through the antennas. To counter this, modern engineering has introduced metal detection sensors within the antennas that trigger an alert when a large volume of metal is detected, ensuring the system isn’t bypassed by simple physical interference.

Ink security tags: Benefit-denial strategy

Developed in 1984, ink security tags feature an ampoule of indelible dye that ruptures and seeps into a product when tampered with, rendering the stolen item useless. This benefit-denial strategy has since evolved to work alongside EAS, combining electronic monitoring with a visible deterrent that discourages thieves from attempting removal.

Modern designs integrate ink ampoules directly into EAS housings, available in both AM and RF frequencies to suit all common systems, while ink dye pins can also be added to existing tags as an extra layer of protection.

Types of EAS tags

Retailers deploy different tag formats depending on the product and security need. Hard tags are the familiar plastic housings with locking pins, designed to be durable and reusable. They’re common on apparel and electronics, where reusability offsets cost. Soft labels are adhesive-backed and disposable, often hidden in stickers or packaging. These are ideal for books, cosmetics, and boxed goods, where speed and convenience matter.

Finally, specialty tags are engineered for unique shapes or high-value items—think liquor bottles, eyewear, or luxury accessories. Their design ensures protection without interfering with the customer’s ability to handle or try the product.

Figure 1 Composite image captures a black RF security hard tag pinned to jeans, a second detached tag with its metal pin exposed, and a white rectangular AM soft label marked with a barcode pattern. Source: Author (composite); individual images belong to their respective producers

Deactivation vs. removal: Two paths to clearance

Checkout counters handle tags in two distinct ways. Soft labels, often hidden in stickers, are electronically deactivated by disrupting their resonant circuit. Once deactivated, they no longer respond to the exit gates.

Hard tags, however, are mechanical devices locked onto the product. These require a physical detacher to release them, ensuring they can be reused. The dual approach reflects retail priorities: speed for disposable labels, security and sustainability for reusable tags.

Engineering behind the scenes

The effectiveness of EAS systems rests on careful engineering choices. Materials science plays a central role: ferrite cores and resonant circuits are tuned for reliable response, while adhesives ensure soft labels stay in place without damaging products. Signal processing is equally critical, with systems designed to operate within specific frequency ranges, reduce false alarms, and manage interference from other electronics.

Finally, engineers face constant design trade-offs: balancing cost, durability, and detection reliability. A tag must be inexpensive enough for mass deployment, rugged enough to survive handling, and precise enough to trigger only when it should. This interplay of physics, electronics, and economics is what makes EAS technology both ubiquitous and invisible in everyday retail.

EAS tag frequencies: RF vs. AM

The performance of EAS systems hinges on their operating frequencies. RF tags typically resonate at 8.2 MHz, making them cost-effective and widely used for general merchandise. Acousto-magnetic (AM) tags, by contrast, operate at 58 kHz, using magnetostrictive strips that vibrate under alternating magnetic fields to deliver stronger detection in environments with metal shelving or foil packaging.

These frequency choices are deliberate: RF systems provide scalable protection for everyday goods, while AM systems excel in challenging conditions, reducing false alarms and ensuring consistent reliability. Frequency engineering, in short, is what makes EAS technology both practical and precise in modern retail.

Figure 2 8.2-MHz RF tags display the internal resonant coil structure and the standard barcode-printed adhesive backing. Source: Author (composite); individual images belong to their respective producers

Dual-frequency and RFID integration

Dual-frequency EAS tags combine AM (58 kHz) and RF (8.2 MHz) technologies into a single housing to ensure universal compatibility across different retail security systems, regardless of which hardware a specific store uses. This makes them the gold standard for source tagging, where manufacturers apply the security tags during production rather than at the store; because the tag is “universal,” the manufacturer can ship the same protected product to any retailer worldwide without worrying about system compatibility.

By further integrating RFID into this setup, the tag evolves into an all-in-one solution that not only triggers exit alarms to prevent theft but also provides item-level data for real-time inventory tracking and supply chain visibility from the factory floor to the point of sale.

Figure 3 This dual-technology label integrates a UHF RFID inlay and an EAS tag to provide item-level tracking and secondary loss prevention for retail apparel. Source: Avery Dennison

Just to clear the mist…

At the core of the above dual EAS technology lies the NXP UCODE 9 chip, a high sensitivity “brain” engineered to deliver superior read ranges and maintain stable signals even under physical interference or shifting environmental conditions. Operating within the global ultra-high frequency (UHF) band of 860–960 MHz, it ensures seamless tracking across international regulatory standards, enabling long-range detection far beyond the proximity limits of standard “tap-to-pay” systems.

Data management is anchored by a 96-bit Electronic Product Code (EPC) memory, a rewritable digital barcode for precise item identification, complemented by a 96-bit Tag Identifier (TID). This TID serves as a permanent digital fingerprint, factory-locked with a 48-bit unique serial number that provides hardware-level authentication and protection against counterfeiting—an identity that cannot be duplicated or altered.

Smarter EAS for modern retail

The evolution of EAS technology is not just about new features; it’s about reshaping retail practice. As mentioned before, source tagging embeds protection at the point of manufacture, streamlining store operations and ensuring every item arrives shelf-ready. Likewise, integration with RFID merges theft prevention with inventory intelligence, giving retailers real-time visibility into stock while safeguarding assets.

Smarter systems, powered by AI-driven analytics, further reduce false alarms by distinguishing genuine threats from background noise. The practical results are clear: shrink reduction delivers measurable savings, customer experience improves through unobtrusive security, and operational efficiency rises with reusable tags and scalable systems. Together, these innovations transform EAS from a silent guard at the exit into a strategic enabler of modern retail.

The harmonic handshake: Integrating EM physics and DSP intelligence

Modern electronic article surveillance systems achieve reliability through the sophisticated interplay of electromagnetic (EM) physics and digital signal processing (DSP).

EM tags, built around high-permeability amorphous metal, generate a distinctive non-linear magnetic response when exposed to a low-frequency interrogation field (typically between 10 Hz and 1 kHz). Thin, durable, and capable of indefinite activation or deactivation, these tags remain the gold standard for high-security applications such as libraries and pharmaceuticals. Yet the low-frequency spectrum they inhabit is increasingly crowded with electronic noise.

Figure 4 These adhesive electromagnetic strips integrate seamlessly into book gutters for discreet security. Source: The Library Store

Here the DSP becomes the system’s discerning ear, applying advanced algorithms to isolate the harmonic signatures produced by the EM strip. By analyzing the timing and ratios of these harmonics—especially the unique “spikes” created as the tag’s magnetic material reaches saturation—the DSP can instantly distinguish a genuine tag from background interference like power lines or moving metal doors.

This synergy preserves the physical strengths of EM technology, including detection through foil and ease of concealment, while adding digital intelligence that virtually eliminates the false alarms once common in legacy analog systems.

From security tags to ambient intelligence

The humble EAS tag is no longer just a one-bit alarm. It’s evolving into the foundation of ambient IoT—a world where everyday objects speak digitally without batteries or costly processors. By merging chip-free EAS principles with conductive inks and AI-driven signal processing, we’re entering the age of computational matter. Imagine a cereal box that not only sets off a gate alarm but also tells a recycling sorter what it’s made of and quietly alerts your smart kitchen when it’s nearing expiration.

And this isn’t just theory—it’s a call to action. For makers, the playground now includes conductive filaments and paints, where a 3D-printed resonator might shift frequency when bent or a touch sensor could be embedded directly into a wooden desk. For engineers, the challenge lies not only in faster chips but in mastering signal-to-noise ratio using machine learning to extract meaning from the messy electromagnetic echoes of chipless tags and designing packaging tech that’s as recyclable as the cardboard it’s printed on.

The future of IoT isn’t merely connected—it’s ambient, invisible, and accessible. Whether you’re hacking RF readers or sketching with graphene ink, remember that sophistication isn’t measured in transistor counts, but in achieving the most with the least. Keep tinkering, keep questioning, and let’s weave an internet into the very fabric of our world.

T. K. Hareendran is a self-taught electronics enthusiast with a strong passion for innovative circuit design and hands-on technology. He develops both experimental and practical electronic projects, documenting and sharing his work to support fellow tinkerers and learners. Beyond the workbench, he dedicates time to technical writing and hardware evaluations to contribute meaningfully to the maker community.

Related Content

• Flash-based FPGAs serve point-of-sale apps
• Secure supervisor IC has active tamper detection
• Building Next-Generation Point-of-Sale Terminals and Kiosks
• Transforming a Smartphone Design into a Sophisticated POS Terminal

The post EAS tags: The invisible backbone of retail security appeared first on EDN.

Sometimes, getting true stress levels can be tricky because things happen that are sneaky.

Stress analysis is often required to confirm that a designed product will perform properly in hazardous environments. Rather than trying to ascertain a “mean time between failures” (MTBF) or a “mean time to repair” (MTTR), the required assumption can also be that failure is simply unacceptable, no matter what, with the further assumption that repairs will simply not take place. For example, when spacecraft are sent out, they usually had better just work…period.

Among the tools that can be brought to bear toward that end, we have MIL-STD-975M (NASA), in which derating guidelines are given for all kinds of electronic parts. If your components all operate within stress limits as defined in that document, it will be assumed that your product will function as required after having been launched.

Sometimes though, getting true stress levels can be a bit tricky because sneaky things can happen, as in the following case study. It exemplifies the following lesson: when doing a stress analysis on the components that have been incorporated into a product, don’t overlook the possibilities of transient conditions. Your design might not be as safe and secure as you think.

Imagine we have a half-bridge switch mode inverter. We can make a very simple SPICE model for it and see what happens when the circuit is first energized.

Figure 1 A simple SPICE model for an also-simple circuit shows what happens when it is first energized.

L1 and R3 are a crude model of the primary winding of a loaded inverter transformer. We look at the voltage excursion that capacitor C1 undergoes when the circuit is first energized and see that the voltage there follows an under-damped wave shape.

Even though the final value of the C1 voltage is headed for half the rail voltage (minus just a little bit of that half to account for switching losses), there is a momentary voltage excursion that goes to a positive peak which is well above that final settling point.

Excerpting from MIL-STD-975M, we find the following.

Figure 2 These excerpts from MIL-STD-975M are relevant to the example half-bridge switch mode inverter circuit.

Taking one particular CLR81, 220 µF capacitor whose nominal voltage rating is 75 volts, if we apply the derating requirement of 0.4, we have an allowable maximum voltage of 75 x 0.4 = 30 volts.

If we are so blithe as to say that C1 will have 14 volts across itself, we will find a stress level of 46.7%, but what we really have is a peak excursion during power-on rising to 21.451 volts, which means a stress level on C1 of 71.5%. We will still be okay, but we will have significantly less of a safety factor to the maximum stress level than we might have originally thought.

Sneaky stuff like this could result in you overlooking an over-stress condition. It is therefore important to consider every circumstance, from stead-state service to any kind of transients to which your designed product’s components may (or maybe more accurately, will?) be subjected.

John Dunn is an electronics consultant and a graduate of The Polytechnic Institute of Brooklyn (BSEE) and of New York University (MSEE).

Related Content

• Semiconductor Reliability and Quality Assurance–Failure Mode, Mechanism and Analysis (FMMEA)
• Design for reliability: You have the tools
• Electronic Components Derating – Made Easy
• Connector voltage stress, Part 1 and Part 2

The post Stress analysis appeared first on EDN.

Just because generational device improvements aren’t in-your-face obvious doesn’t mean they aren’t sooner-or-later still tangibly impactful.

As mentioned last week, one of the perks that accompanied my recent personal-cellular-line transition from AT&T to Google Fi Wireless was a free (after two years’ service, albeit still notably discounted upfront) Pixel 10 smartphone, which I’d needed to press into service immediately in order to qualify for the various promotion discounts (this “stock” photo is of the “Indigo” colorway; as noted last week, mine’s “Obsidian”):

As long-time readers may recall, I’ve been a (mostly) Google Pixel “daily driver” since mid-2017, across multiple product generations. And I’ve been specifically using a pair of Pixel 7s for the past three years. So, I feel a “bit” qualified to offer some observations and comparisons with past device experiences. Without further ado…

I’m not a power user

What I’m referencing by means of this admittedly cryptic initial section header is the fact that although the Pixel 10, which I initially wrote about as part of my coverage of Google’s August 2025 multi-product launch event, has a three-generation-newer Tensor SoC inside it (the G5, versus the earlier G2), the performance differences aren’t strikingly obvious. at least to me. Not that they’re nonexistent, mind you; Google’s increasingly impressive AI “chops” are most evident at the moment in the handset’s computational photography capabilities. That said, I strongly suspect that AI’s effects will be comparatively even more broadly visible (both in their results, responsiveness and fundamental existence) with the passage of time.

To that point, the “bump” in RAM from the Pixel 7 (8 GBytes) to the Pixel 10 (12 GBytes) is likely at least as important as is bolstered inference processing “muscle” in delivering local AI enhancements, as it enables on-device deep learning models to be more comprehensive and otherwise robust than would otherwise be the case, delaying if not completely foregoing a performance- and power-sapping handoff to the “cloud” in the process. And if there’s one upside to today’s semiconductor memory shortages, it’s that it’ll compel Google’s and other organizations’ developers to make their models even more efficient (while retaining sufficiently high results accuracy) than might otherwise be the case.

Pleasantly pocketable and reliably chargeable

Put the two phones side-by-side and you’ll realize that although the active screen dimensions and other high-level display attributes are identical (6.3” diagonal OLED with 1080 x 2400 pixel resolution, though the Pixel 10 variable refresh rate tops out at 120 Hz versus 90 Hz for the Pixel 7, for whatever that’s worth…), the Pixel 10 (at left in the following photos) is actually a smidge shorter and narrower, the result in part of bezel decreases, not to mention rounder:

• Pixel 7: 6.13 x 2.88 x 0.34 inches (155.6 x 73.2 x 8.7 mm)
• Pixel 10: 6.02 x 2.83 x 0.3 inches (152.8 x 72.0 x 8.6 mm)

That aside, the Pixel 10 has a higher internal battery capacity than its Pixel 7 forebear—4,970 mAh vs 4,355 mAh—and the foundry transition from Samsung to TSMC that accompanied the to-Tensor G5 SoC evolution also aspires to improve not only performance (decreasing the energy consumption necessary to complete a given task in the process) but also stored-electron efficiency, with the two factors combining to boost claimed battery life.

Speaking of battery life, a few words on charging. The Pixel 7 supports wired charging at up to a 21W incoming power payload and wireless charging at up to 12W with conventional Qi chargers or 20W with the pricey, seemingly no longer available 2nd-generation official Google Pixel Stand:

For the Pixel 10 family, there’s a new wireless charger, the magnet-augmented Pixelsnap (reflective of the magnet-inclusive and Apple MagSafe-reminiscent QI2 support now within the phones themselves), which supports 15W charging speeds with the baseline Pixel 10 and 25W for the high-end Pixel 10 Pro (both of which also support wired charging at 30W rates):

And even though, as with the Pixel 7, I still need to use a case that’s magnet-inclusive with the Pixel 10 to ensure sufficient “cling” strength to a charger or whatever else I’m striving to stick it to (or, depending on the circumstance, stick to it), MagSafe-tailored chargers now work with it, too. With the Pixel 7, charging reliability with magnet-based chargers such as my Belkin-based desktop:

and in-car setups:

was flaky at best, typically DOA with the magnet-augmented case but magnet-less foundation. Now, for whatever reason, it’s ironclad (I hope I haven’t jinxed myself by writing those words).

Optics upgrades

Speaking of computational photography, while the Pixel 7’s front camera did implement face recognition-based unlock support (for the first time since the Pixel 4), it was both too flaky and insufficiently robust in associated software support to be something I could rely on. Beginning with the Pixel 8 (therefore also including the Pixel 10), the implementation is not only faster but also more accurate and broadly robust, thanks to machine learning algorithm augmentation:

That said, it’s still reliant on the front visible light image sensor, dropping the Pixel 4’s Kinect-reminiscent and IR-derived structured light approach in the process, in an ironic contrast to the conceptually similar IR-based TrueDepth technique that Apple uses to this day with FaceID. As such, it doesn’t work great in dim light, and not at all in the dark; thankfully, Google has also seemingly improved its historically woeful fingerprint ID detection implementation as a backup in such situations. And there’s always also your PIN or other unlock sequence, after all…

One other camera-related note; in the earlier backs-of-phones images you might have noticed what appeared to be a third lens on the Pixel 10’s rear “camera bar”. Or maybe you’ve just noticed the increased prevalence of ultra-closeup pictures in my recent teardowns, ones specifically taken without the bulky multi-piece accessory I had to use previously:

Google refers to it as a 5X telephoto, and it’s admittedly nice for that, but its Macro Focus capabilities are what I’m lovin’ the most, right now at least.

Tying up loose ends

I mentioned earlier in this piece, and have also mentioned previously, how much I appreciated the fact that Google extended support (not only security patches but also full O/S updates) for the Pixel 6 and 7 series from 3 to 5 years at the end of 2024. As such, they’ll remain reliable backup-at-least options in my smartphone arsenal for at least the next year-plus. That said, beginning with the Pixel 8 series, therefore also including both my Pixel 10 and Pixel 9a, support was further extended to seven years from initial release date. Nice.

One (very) minor downside, for which I have nobody but myself to “blame” since I knew about it before I pressed “purchase”, involves ultrawideband (UWB) support. Apple’s latest-generation AirTag trackers leverage not only integrated Bluetooth and Wi-Fi subsystems but also UWB capabilities to enable more precise location discernment. So too do advanced Android-friendly trackers such as Motorola’s Moto Tags, one of which currently resides on my teardown shelf:

This is all well and good, but there’s one key qualifier: tracker-based UWB is only meaningful if the connected device that’s doing the tracking also supports UWB. That gives a green light to the Pixel 10 Pro, but not my UBW-deficient Pixel 10. Oh well…First World problems strike again.

And speaking of Android friendliness, I’m ironically writing this piece one day ahead of Google I/O 2026, with my special-project coverage of it scheduled to be published weeks ahead of this piece. Google has already talked some about Android-centric stuff at least week’s (again, as I write this) Android Show I/O Edition, replicating a cadence tradition it did for the first time a year ago. I’ll be curious to see what else Android- and Pixel-related is unveiled tomorrow. And I hope it doesn’t obsolete what I’ve just written today in the process! I’ll see you all “on the other side”, where I as-always also welcome your thoughts in the comments.

—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.

Related Content

• Try Google Fi (Wireless)? The perks-for-the-price are why
• From T-Mobile To AT&T: It Couldn’t Have Been More Easy
• Playin’ with Google’s Pixel 7
• If you made it through the schtick, Google’s latest products were pretty fantastic
• The 2025 Google I/O conference: A deft AI pivot sustains the company’s relevance
• Google I/O 2026: Agentic AI gets serious

The post Google’s Pixel 10: Upgrading smartphones again appeared first on EDN.