EDN Network

Melexis has introduced a 5-V variant of its MLX90381 Triaxis pico-resolver for compact motor systems that rely on a 5-V supply. As motors become smaller and mechanical space more constrained, integrating accurate rotor position sensing becomes more challenging, particularly when end-of-shaft sensing is not possible. The MLX90381’s resolver-based position sensing provides greater flexibility in sensor positioning than TMR-based solutions, making it suitable for automotive, alternative mobility, and robotics motor applications.

Housed in a compact DFN-6 package measuring 2.0×2.5×1.0 mm, the MLX90381 combines Triaxis Hall technology with high-speed sine and cosine analog outputs. Its ability to sense magnetic flux density in three dimensions and use selectable X/Y, X/Z, or Z/Y magnetic axis pairs allows flexible sensor placement relative to the rotating magnet. In side-of-shaft and through-shaft motor designs, the sensor can be placed below or close to the magnetic track, reducing mechanical constraints and simplifying PCB placement and tolerance management in compact assemblies.

The MLX90381 5-V provides a 2-µs output refresh rate and measures rotational speeds above 50,000 rpm for precise rotor position detection in DC, BLDC and PMSM motors. Programmable sensitivity and filter bandwidth enable performance optimization, while I²C supports device configuration and production calibration.

Samples of the MLX90381 5-V are available now. Target use cases include e-valves, robotic actuators, cadence sensing, and motor applications for braking, steering, and seating.

MLX90381 product page

Melexis

The post Resolver enables flexible motor sensor placement appeared first on EDN.

NVIDIA’s Jetson Orin Nano 2 system-on-module delivers nearly twice the inference performance of its predecessor, the Jetson Orin Nano Super. The performance boost comes from improved Tensor Cores and higher memory bandwidth. Nano 2 also maintains the same compact form factor as the Nano Super while consuming 40% less power in 15-W mode.

The robotics computer enables developers to build robots, delivery and inspection drones, and vision AI systems with advanced generative AI capabilities. NVIDIA says the Nano 2 combines up to 78 TOPS of AI performance, 8 GB of memory, and an 8-core Arm CPU in a cost-effective, power-efficient design.

Built on NVIDIA’s open software stack and supported by Jetson agent skills and a rich AI ecosystem, Jetson Orin Nano 2 allows developers to run the latest large language models (LLMs) and vision language models optimized for memory-efficient edge inference. These include open models such as NVIDIA Cosmos, NVIDIA Nemotron, Gemma 4, and Qwen 3.

The NVIDIA Jetson Orin Nano 2 module and developer kit are expected to be available in the first half of 2027.

NVIDIA

The post Robotics computer doubles edge AI performance appeared first on EDN.

SECO announced early access to hardware samples of its SOM-SMARC-Dragonwing-IQ8 module for industrial edge AI applications. Developed with Arduino and Qualcomm, the SMARC 2.1.1 module enables the transition from Arduino Ventuno Q prototyping to production-oriented architectures for AI-enabled robotics, smart machines, industrial vision, HMI, and machine control.

The system-on-module leverages the Qualcomm Dragonwing IQ-8275 processor, with AI acceleration options of up to 40 TOPS to meet various performance and price points. It provides up to 32 GB of LPDDR5/LPDDR5X memory and up to 1 TB of UFS 3.1 flash storage. Connectivity interfaces include Gigabit and 2.5-Gigabit Ethernet, PCIe Gen4, MIPI-CSI, and CAN-FD.

Developers can build and validate designs on the Ventuno Q and use the Arduino App Lab to port them to the SOM-SMARC-Dragonwing-IQ8. The module runs Clea OS, based on Yocto Linux, providing a consistent software baseline for secure lifecycle management, OTA updates, and connected device scalability.

A limited number of SOM-SMARC-Dragonwing-IQ8 samples are expected to be made available to select customers and partners for evaluation. Register here to receive updates on priority access.

SOM-SMARC-Dragonwing-IQ8 product page 

SECO

The post SMARC module bridges Arduino prototyping to production appeared first on EDN.

The nPZ2100 sensor-management and power-saving IC (PSIC) from Nanopower provides autonomous control for battery-constrained sensor systems. Based on the nPZero power-reduction architecture, the device manages sensors and peripherals while keeping the host MCU powered down until needed. This approach enables a simple operating principle: sense, decide, wake, and process.

With typical idle current consumption of just 200 nA at 3.0 V and polling current of 1 µA, the nPZ2100 can autonomously manage up to six independent peripherals through I²C or SPI interfaces. It integrates four 1-mA peripheral power switches and a dedicated 10-mA host power switch. The device also includes 256 bytes of SRAM for data logging, a three-channel ADC with battery monitoring, a 32-bit timer with alarm and watchdog, and a 32-bit counter, as well as power-aware operation for energy harvesting.

In addition to the MCU, the nPZ2100 can also power down peripherals when they are not required, helping eliminate their idle power consumption. Nanopower says that by taking over sensor communication and system monitoring while the host MCU is powered down, the nPZ2100 can significantly reduce the host’s active time and overall system energy consumption.

Development kits and engineering samples are planned to be available in September 2026, with full product release and volume manufacturing slated for Q2 2027.

nPZ2100 product page 

Nanopower Semiconductor

The post IC manages sensors without waking the MCU appeared first on EDN.

Achronix now offers a JESD204C IP core for connecting high-speed ADCs and DACs to programmable logic in Speedster7t FPGAs. Each core supports data rates of up to 32 Gbps per lane and up to eight lanes per link, delivering an aggregate serial line rate of up to 256 Gbps. Combining up to four cores enables aggregate performance of up to 1 Tbps.

Designed for high-bandwidth, multichannel data-converter systems, the standards-based JESD204C core maintains backward compatibility with JESD204B to ease legacy system migration. It supports both 64b/66b and 8b/10b encoding, along with Forward Error Correction (FEC), CRC-12, and CRC-3 modes. Subclass-1 operation provides deterministic, phase-coherent latency for single- and multichannel systems. Flexible framing, integrated alignment and recovery features, and an AXI-Lite interface simplify system integration and control.

Speedster7t FPGAs integrate 112-Gbps SerDes to achieve the signal integrity needed for 32-Gbps JESD204C links. A 2D network-on-chip (NoC) provides high-bandwidth data transport across the device while reducing programmable-routing congestion and power consumption.

The Achronix JESD204C IP core for Speedster7t FPGAs is available now. The IP package includes a graphical interface in the Achronix ACE design environment, synthesizable VHDL/Verilog design files, templates, and example designs.

Achronix Semiconductor 

The post IP core provides scalable JESD204C connectivity appeared first on EDN.

Simple circuit saves hard-working fingers from unnecessary wear and tear.

Digital potentiometers (DPOTs) with manual up/down increment/decrement interfaces can have real utility as versatile substitutes for traditional electromechanical pots. But they start life with a big handicap.

No knob.

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

The basic (and obvious) way to interface people with DPOTs is illustrated in Figure 1, using  push buttons to increment or decrement the setting, one pulse per push. It works. But it’s work!

Figure 1 In this reference circuit, Schmidt trigger U1 senses and de-bounces UP/DOWN momentary contact pushbuttons to (tediously) move the U2 setting by one position per push.

DPOTs need large numbers of setting positions (e.g. 64, 128, or 256) to provide enough resolution to make them useful. Large changes in setting using Figure 1 therefore require comparably large numbers of button pushes. This can entail considerable time consumed, and finger fatigue endured. You could get a blister! And that’s in addition to the potentially unpleasant (and dangerous?) effects of annoying your fellow lab-mates with the associated dripping-faucet sound effects!!

Figure 2 suggests a simple labor-saving remedy comprising just four added passive parts.

Figure 2 When a button is pushed down and held, the R5C2 time constant begins running. About a half second later, if the hold is still being held, the U1b multivibrator starts up, generating auto-repeating pulses at roughly 4 Hz for as long as the hold-down continues.

If we add the illustrated components to U1b, its basic function of contact bounce filter will be unaffected. That’s unless a button-down condition lasts longer than about a half second. If that happens, then C2 will discharge to below the pin 5 low-going Schmidt trigger threshold of V+/3, driving pin 6 high.

Now C2 will be quickly recharged through D1 and R4 (this takes ~3ms), generating another clock pulse to the pot that will duplicate the initial actuation. And so on and so forth, at 4Hz or so, until the button is released. Note that C2’s timeout between auto-repeats is shorter than the initial delay before they start. That’s because auto-repeat recharge ends at the Schmidt high-going threshold of only ~(2/3)V+ instead of running all the way up to V+ like it does between button pushes.

So what’s U1d for?  Well, when the pot arrives at the desired setting and the button is released, the R3C1 debounce time constant prevents the news from instantly arriving at U1b. Therefore, depending on how close C2 was to completing an autorepeat cycle, it’s possible that it will timeout before C1  does. If so, a bogus clock pulse and unintended pot increment could then theoretically occur.

To prevent this, U1d does a fast end-run around the auto-repeat oscillator to disable U2’s CS input. So even if the spurious pulse happens, the pot won’t see it. Not a big thing, but the gate was going to go to waste, anyway.

With a little practice, auto-repeat can be used to quickly get the pot very near a desired new setting. Then you can finished it off with a (mercifully) individual button push (or few) to arrive at the precisely needed final position.

Theoretically.

And a final remark. In an earlier Design Idea, I discussed the relative advantages of  buttons that actuate on push versus those that act on release. Whatever personal taste might otherwise dictate, it’s hard to imagine how the latter scheme could be made to work with the idea shown here.

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

• DPOT push up/down
• Digital potentiometer simulates log taper to accurately set gain
• Push to increase, decrease a digital potentiometer
• Synthesize precision bipolar Dpot rheostats

The post Finger-friendly DPOT pushbuttons do ups, downs, and dittos appeared first on EDN.

AI-assisted chip design is not new. What is new is seeing an advanced ASIC reach tape-out in roughly nine months. The significance is not that AI can optimize individual design tasks; the industry already knows that. Synopsys and others have demonstrated AI-assisted implementation, verification, PPA optimization, and design-space exploration across many tape-outs.

What makes the nine-month result important is the possibility that architecture, RTL, verification, memory, network-on-chip (NoC), high-speed I/O (HSIO), design for testability (DFT), physical design, timing, and power were compressed together into a much tighter development cycle without losing overall convergence.

OpenAI and Broadcom’s Jalapeño program therefore raises a more important engineering question: How do you make many strongly dependent design activities move faster at the same time without allowing the chip to diverge?

The answer is unlikely to be one AI tool. Parallelism creates speed while intelligence-aware control keeps the design converging.

Speed begins with task parallelism

A semiconductor development flow is often shown as a sequence:

Architecture → RTL → Verification → Synthesis → Floorplan → Place & Route → Timing → Signoff

Experienced engineers know that real programs are never completely sequential. Architecture, RTL, verification, physical design, software, package definition, and other activities already overlap. But there are still expensive handoffs and feedback loops.

• Architecture decisions affect RTL.
• RTL changes affect verification.
• Synthesis exposes PPA problems.
• Physical design exposes congestion and timing problems.

These problems may propagate back into RTL, microarchitecture, memory organization, interfaces, or even the original partitioning. Every long loop consumes schedule, and AI and modern automation make it possible to push much more of this activity into continuous parallel execution.

However, architecture exploration can continue while RTL develops. Verification can run continuously against evolving blocks. Early synthesis and floorplanning can feed physical information upstream before RTL is frozen. Therefore, NoC, memory, HSIO, DFT, timing, power, and implementation teams can work simultaneously rather than waiting for a single completed design state.

In other words, AI can accelerate individual activities inside each of those workstreams. That creates speed, but it also creates a new problem.

A complex ASIC isn’t a collection of independent tasks

Consider something as simple as moving an HSIO PHY. Locally, the change might solve a placement or congestion problem. But that decision may propagate into:

Floorplan → Bump assignment → Package escape → Routing → Timing → Clocking → Power delivery → Signal integrity → DFT access → Local thermal behavior

The same problem exists throughout the chip. Change the NoC topology and bandwidth may improve, while latency, power, routing congestion, area, and verification requirements change. Change SRAM organization and compute utilization may improve while floorplan pressure and timing deteriorate.

Change pipeline depth and frequency and throughput may improve while latency, verification assumptions, clocking, and workload scheduling move in another direction. Change HBM or HSIO placement and the effect may extend beyond the silicon floorplan into package interfaces and power delivery.

This creates a fundamental problem: A locally optimized design decision can produce a globally worse chip. That’s why simply adding more AI tools cannot be the complete answer.

Imagine architecture AI, RTL AI, verification AI, DFT AI, physical-design AI, and timing optimization all running aggressively in parallel. Each one could produce a technically better answer within its own objective function. Yet together they could cause the overall design to diverge. Parallel execution therefore creates speed only if something maintains continuity between the parallel activities.

Parallel AI needs intelligence-aware control

Parallel execution therefore needs a second layer: intelligence-aware control. Call it an intelligence-aware control environment. Its purpose is not necessarily to design every transistor, block, or interface. Its purpose is to understand the relationships between design decisions and control how changes propagate through the development program.

For every significant modification, the environment should be capable of asking:

• What changed?
• What depends on it?
• Which assumptions may now be invalid?
• Which analyses must run again?
• Did this local improvement create a penalty somewhere else?
• Can the new result propagate automatically, or does it require engineering review?

That is more than launching EDA jobs. It requires awareness of the relationships among major design objects:

• Compute/NPU
• NoC
• SRAM and memory hierarchy
• HBM/DDR
• HSIO/PHY
• Clock and reset
• Power domains
• DFT
• Physical implementation
• Package interfaces

And each of these operates within engineering constraints: area, power, timing, bandwidth, latency, physical location, interface behavior, verification requirements, SI/PI limits, and thermal conditions. Change one object and some portion of these constraints may need to be reevaluated. The development environment therefore needs something resembling a live dependency map of the ASIC.

The real schedule savings may be in the feedback loops

Consider a conventional development loop. An RTL block changes, and verification runs. Later, synthesis exposes a problem and physical implementation discovers congestion. Next, STA identifies a timing issue and the problem returns upstream.

RTL or microarchitecture changes again. Downstream work repeats. So, while each individual tool may be fast, the engineering loop is slow. Now imagine a connected environment in which a change to an HSIO region immediately identifies the analyses affected by that change.

Perhaps it triggers update:

• Floorplan checks
• Timing checks
• Congestion checks
• Power checks
• Package-interface checks
• Signal-integrity checks

An NoC modification would activate a different dependency path. A compute-block modification might primarily require RTL verification, synthesis, PPA, timing, and physical evaluation. But the objective is not to rerun the entire chip every time something moves.

It is to understand what must be reevaluated because this particular design object changed. That distinction matters enormously. If feedback that previously took days arrives in hours—or minutes—many design loops can operate simultaneously without waiting for large downstream milestones. That is where months can begin disappearing from the schedule.

AI becomes more useful when boundaries are controlled

Within that environment, AI can operate aggressively on bounded engineering problems. It may help engineers explore architectural alternatives, generate or modify RTL, analyze verification failures, optimize arithmetic structures, evaluate physical alternatives, interpret timing results, propose ECOs, or search PPA space.

Synopsys’ existing products already demonstrate that AI can autonomously search enormous implementation and verification spaces and accelerate convergence within individual domains. The harder step is connecting those capabilities so that one accelerated decision does not silently invalidate another.

Instead of asking an AI system “Improve this block,” the environment can effectively ask “Improve this block while maintaining these timing, power, physical, interface, and verification constraints—and identify what downstream assumptions the change affects.” Now AI supplies speed and search capability while the control environment protects global convergence. That is a far more powerful combination.

Intelligence doesn’t eliminate engineering judgment

Suppose an optimization reduces area by 6%. Is that automatically better? No. That’s because congestion may increase, timing margin may fall, or current density may increase or redistribute. Moreover, DFT access may become more difficult and power density may create a local thermal problem. A high-speed interface may also move into a more difficult package region.

No single PPA number determines whether that design state is actually better. This is why Broadcom’s role in the OpenAI program is important. OpenAI explicitly credits Broadcom’s silicon implementation expertise as part of the nine-month result.

Years of ASIC experience create something that is difficult to reproduce quickly: an understanding of which dependencies matter, which trade-offs are acceptable, which interfaces are high risk, and which apparently small changes can create major downstream consequences. So, while AI may dramatically increase how many alternatives engineers can evaluate, experienced semiconductor teams still determine which alternatives are worth accepting.

Workload knowledge may also shorten architecture convergence

There is another advantage apparent in the OpenAI example. Jalapeño was not designed as a generic accelerator and then handed to an unknown software workload. OpenAI says the chip was built around knowledge of its models, kernels, serving systems, memory behavior, networking, scheduling, and product requirements.

That matters because many ASIC programs spend significant time determining what the chip should optimize. On the other hand, OpenAI began with extremely detailed knowledge of the workloads the silicon is expected to execute. That allows tighter co-development between:

Workload → Architecture → Memory → Networking → Scheduling → Silicon

OpenAI is now also reporting measured first-silicon results from Jalapeño, which makes the nine-month tape-out more significant than a purely simulated design exercise. But even here, the important lesson may not simply be “software-hardware co-design.” It’s that more design information becomes available earlier, reducing uncertainty that would otherwise propagate through later stages.

A nine-month tape-out is not yet a nine-month methodology

This distinction is important because a fast program could benefit from exceptional engineering talent, proven IP, mature implementation flows, large compute resources, rapid management decisions, deep Broadcom experience, OpenAI workload knowledge, extensive automation, and extraordinarily tight focus. These ingredients can produce an exceptional result.

However, an exceptional result is not automatically a repeatable process. The real proof comes with the next generations. Can ASIC #2 and ASIC #3 converge in approximately the same timeframe? Can the process deliver predictable verification closure, controlled ECO activity, consistent PPA, manageable engineering effort, and successful first silicon?

OpenAI and Broadcom describe Jalapeño as the beginning of a multi-generation platform. If the nine-month schedule becomes repeatable, then something more important has happened than simply using AI in chip design. For instance, how development methodology has changed.

The larger opportunity

The future of AI-assisted semiconductor design may therefore not be one giant AI system autonomously designing an entire system-on-chip (SoC). It may look more like many specialized engineering activities operating simultaneously:

• Architecture
• RTL
• Verification
• Memory/NoC
• DFT
• Physical implementation
• Timing/Power

With AI accelerating work within each of these domains, a higher-level control environment continuously maintains dependency, connectivity, change impact, feedback, and convergence across the complete development program. That gives us a much simpler way to understand the nine-month question: Parallelism creates speed; intelligence-aware control keeps the design converging; and AI can make each piece move faster.

The harder engineering challenge is making sure all of those faster-moving pieces continue advancing toward the same tape-out. If that can be accomplished repeatedly, the real achievement will not be one fast ASIC. It will be a new level of repeatable semiconductor development capability.

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

Related Content

• 5 ways manufacturers benefit from AI in chip design
• The AI design world in 2026: What you need to know
• Four tie-ups uncover the emerging AI chip design models
• How AI is reshaping IC signoff: Trust, speed, and intelligent workflows
• First Benchmarks Revealed for Jalapeño, OpenAI’s Clean-Sheet General Purpose AI Accelerator ASIC

The post Why a nine-month AI chip tape-out matters appeared first on EDN.

The use of hardware assisted verification (HAV) technologies was once a luxury, “nice to have” technology for IC design. Because of the costs associated with HAV, especially for the “big box” logic emulators, it was mainly leveraged by the larger companies for their largest SoC projects.

Today with even medium complexity SoCs, modern HAV technologies have become far more accessible and affordable at a time when the use of HAV has become an imperative for helping design teams get massive SoC-powered products to market on time.

In today’s SoC design world, the issue isn’t strictly getting silicon to function properly. The main issue is ensuring that the SoC and the application software that runs on the SoC work together properly and with the highest efficiency.

Let’s examine a common methodology employed with verifying hardware and software together and where the traditional methodology breaks down. We’ll then look at how EDA vendors are offering modern FPGA-based prototyping systems in their HAV suites that bypass the shortcomings of the older methods.

The HW/SW, “chicken and egg” dilemma

On SoC projects, software development and testing can’t wait until silicon is available; on the other hand, embedded software development would need silicon to run on. As a result, design teams have come up with many techniques to make parallel development work. However, born out of necessity, one in particular has emerged over the years as the preferred methodology.

In this methodology, design teams attempt to separate the software stack into hardware-independent and hardware-dependent portions, separated by an operating-system layer and communicating through well-characterized APIs.

Typically, the larger hardware-independent code can be developed in a server environment with standard debugging techniques, using stubs to stand in for the APIs. Then the designers develop the hardware-dependent portion of the code, while the RTL design takes shape, using a hardware emulation system or perhaps even logic simulation as an execution environment.

But this methodology has its flaws. The first, and most obvious, is that it’s not always easy, or even possible, to determine which portions of the code are really hardware independent.

Dependencies accidentally created deep into the application code could go unnoticed, especially when intensive I/O and high computing loads must meet hard timing deadlines. And software developers often have to make some assumptions about execution speeds, cache sizes, and memory latencies—assumptions that may later prove false.

The second flaw of this older methodology is simply the combination of speed and capacity. In the older methodology, the integration and testing of the software with the RTL model of the chip is generally going to execute too slowly, even on an emulation system, to allow extensive exploration of the entire software stack. This leaves two options.

The first is waiting until first silicon is back and hope and pray all the bugs were caught; but hope is not a strategy and a software workaround or shut down part of the chip may not be feasible or acceptable. The second option is to move to a modern, success-oriented methodology that deals with shortcomings of the traditional hardware/software co-verification methodology.

This methodology is centered around hardware-assisted verification (HAV) solutions in general and FPGA-based prototyping in particular. Modern HAV technologies offer a much better methodology and higher likelihood of success that requires less stress and praying to a deity.

Addressing HW/SW co-verification bottlenecks

The end goal when deploying an HAV methodology is to ensure that not only is the SoC hardware functionally correct but that the software running on the SoC is optimized so the entire product meets spec and is optimized for best functionality, performance, and power. Ideally, the full software stack and the complete RTL design should be tested together as soon as both are sufficiently complete and stable to allow meaningful execution runs.

This gives the development team the opportunity to identify bugs and hardware/software interactions early, and before committing to silicon. And good version control ensures that the software team is working with the current RTL model and that the hardware team knows at once if they have just broken the software.

Speed of the HAV technology is the key. To test the full software stack on the SoC model realistically requires the use of an HAV technology, the FPGA-based prototype system. The model of the SoC under development is programmed onto the FPGAs of the prototyping system, allowing software developers to create software and run the software stack to ensure it works with the system.

An FPGA-based prototyping system will be able to run the full software stack on a realistic model of the SoC logic and memory, fast enough for intensive software and system validation. But what about the model’s interaction with the outside world? Verification requires seeing how the design behaves in continuous operation with real-world data.

In the past, many designs have attempted to circumvent the challenge of verifying their designs in continuous operations by trying to identify patterns of input data that will be most challenging to the system. They would synthesize those patterns as scripts and feed them into the prototyping system to observe its response. Unfortunately, this is ultimately a low-probability approach.

As years of development have illustrated, sometimes a bit too graphically, it’s just not possible to anticipate, for example, what streams of video from HD cameras are going to cause an AI system to miscategorize a traffic situation. And, as any communications engineer can attest, it’s equally impossible to predict the patterns of data that will appear on a real-world Gigabit Ethernet link or PCIe bus. As both ADAS and networking engineers have learned, a-priori analysis is no substitute for massive amounts of real-world data.

Ideally, verification engineers could connect the high-speed FPGA-based prototype directly to the cameras, sensors, actuators, and displays of the real system, and subject the system design to real-world data, in all its randomness, unpredictability, and at its natural speed. That could mean running the FPGA-based prototype system in a moving car, on a live network switch, or in a storage controller in a data center.

However, this raises another question: how to get at-speed or near-speed signals from the real world into the FPGA-based prototype. Design teams have tried several approaches, but once again, one solution is emerging.

Intuitively, it might seem reasonable to just implement the critical interfaces in the FPGA-based prototype. After all, the finished SoC will include those interfaces, so they are a real part of the design. And external networks, buses, and control signals could be connected directly into the prototyping system.

But there are serious issues with this approach. The first is that it will divert important design and verification resources away from the main design project. Yes, these interfaces will be present in the finished SoC, but they will almost certainly be implemented as third-party IP. Assuming that the third-party vendors have already been selected, they may or may not provide FPGA models of their IP for a particular FPGA family.

The models may or may not be accurate reproductions of the ASIC interface blocks’ functionality and will certainly differ in timing. Implementing these interface blocks in the FPGA and verifying them potentially becomes a significant FPGA design project in its own right, drawing on critical interface and FPGA skills that are needed elsewhere in the design.

An alternative is to design external interface adapter cards to connect the real-world signals into the prototype system. Such an adapter can run at full real-world speed on the real-world side, and at the speed required by the FPGA-based prototype on the prototype side. But again, there are significant challenges.

To begin with, no high-speed interface adapter is a trivial design, including power considerations, clocking, board design, connector or cable signal integrity, and so on. Then there is the matter of getting the signals back and forth between the adapter card and the prototype system.

Running cables to the system backplane will introduce timing and signal-integrity questions and will require precise understanding of the FPGA-based prototyping system’s internal design. Designing daughter cards to attach directly to expansion connectors or to the FPGA cards themselves within the prototyping system will require an even more detailed understanding of the system’s electrical, mechanical, and thermal requirements.

A modern solution

Take the case of a family of off-the-shelf extension boards for the Veloce proFPGA CS system. It includes I/O adapters for a range of interfaces, including Gigabit and slower Ethernet, PCIe GEN4, USB, DDR4, various Flash memory interfaces, and a range of connector configurations for bringing the FPGA I/O signals out of the box. Such an I/O board, for example, combines Ethernet on an RJ45 connector, a USB connector with UART, a MIPI 60 connector, and a GPIO header, along with user-definable LEDs.

Figure 1 The Veloce proFPGA CS platform is an entry-level solution in which the UNO desktop system delivers FPGA-based prototyping. Source: Siemens EDA

The extender cards plug directly onto connectors on the Veloce proFPGA CS FPGA boards, minimizing latency and signal-integrity issues. This also saves the user from having to provide external clock and power sources for the boards. Supporting software seamlessly integrates the extension boards into the Veloce proFPGA CS development environment.

Figure 2 The Veloce proFPGA CS boards can be adapted and expanded with the latest FPGA generations and extensions cards equipped with interconnections, interfaces or memories. Source: Siemens EDA

The result is that users can quickly connect an SoC prototype on the Veloce proFPGA CS into the actual environment in which the finished SoC will operate, with the interfaces operating at or near full speed. Software developers can instrument and observe the full software stack executing in the real world, not within the confines of synthetic tests. Hardware engineers can observe hardware/software interactions with live, real-world data at high speeds.

Juergen Jaeger is director of prototyping product strategy at Siemens EDA.

Related Content

• The Growing Use of Hardware-Assisted Verification
• The Case for Hardware-Assisted Verification in Complex SoCs
• Can Hardware-Assisted Verification Save SoC Realization Time?
• Hardware-Assisted Verification: The Real Story Behind Capacity
• Hardware-Assisted Verification: Ideal Foundation for RISC-V Adoption

The post Enhancing SoC HW/SW co-verification with FPGA-based prototyping appeared first on EDN.

Fakery methods, and their impacts on those who are particularly easily fooled, have advanced dramatically in recent times.

My wife and I recently saw the movie Disclosure Day, in which an extra-terrestrial being comes to earth and after much ruckus and travail, is introduced to the world’s population with the advice to “listen”. Frankly, I didn’t much care for the movie, but a lot of people seemed to have enjoyed themselves watching it.

However, a disquieting moment came about just as we were leaving the theater. I heard one woman say to the other that this movie was “proof” that the depiction of an extra-terrestrial alien was real and further “proof” that “the government” is secretly concealing truth from the general public. The fact that the scroll of credits at the end of the movie listed the puppetry experts had made no impression on this lady whatsoever.

If this lady were a close relative of mine, I would be very concerned that she would be a prime target for all kinds of fraudsters seeking to rip her off using pretty much any of the widely publicized scams we see written up in the news lately. What she could seemingly be led to believe was alarming.

Fakery methods have been very much advanced in recent times. Look at this screen shot taken from a Neil deGrasse Tyson video, in which he appears to be in conversation with an alien from “Andromeda”.

I think in looking at this image that Mr. Tyson’s forehead is shown slightly higher than reality, but that isn’t all that obvious.

As to the alien, nothing more need be said.

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

Related Content

• 2020: A consumer electronics forecast for the year(s) ahead

The post Deepfakes appeared first on EDN.

The maximum boost ratio achievable with a single stage, normally cited as 8-to-9, can be much higher if you keep important design considerations in mind.

In single-cell battery applications such as personal electronics or power tools, where the input voltage is less than 4V, you may need a high output voltage to reduce current in the system in order to provide higher power density, faster charging, improved efficiency and a small form factor. High-boost-factor designs allow a high ratio between the input and output voltage. This article discusses the process for designing a high-duty-cycle boost topology suitable for high-output-voltage applications, while showing the limits of achievable duty cycles and boost factors.

As a rule of thumb, the maximum boost ratio practically achievable with a single boost stage using regular silicon switches is often cited as 8-to-9. Much higher ratios are still possible, however, if you keep important design considerations in mind.

High-duty-cycle considerations

A boost converter can operate in either continuous conduction mode (CCM) or discontinuous conduction mode (DCM). In DCM, the inductor current reaches zero every switching cycle, whereas in CCM current always flows through the inductor. When operating in DCM, a combination of small inductance, low output current and low switching frequencies helps achieve a high boost ratio, as expressed by Equation 1.

Achieving a high boost ratio in CCM requires a high duty cycle, as shown by Equation 2.

While in theory a duty cycle of 99.9% (and a boost factor of 1,000) is possible, practical limitations exist. Most boost controller or converter integrated circuits have a maximum duty cycle dependent on switching frequency – typically in the range of 92% to 98%. Gate charge and other parasitics of the field-effect transistors (FETs) and printed circuit board traces limit the maximum duty cycle. Additionally, the higher the duty cycle, the lower the right-half-plane zero frequency becomes, which can result in a very slow regulation loop.

Choosing the switching frequency

Selecting a switching frequency involves a trade-off between efficiency and solution size. For a high boost ratio, a lower switching frequency is preferable. When designing for DCM, the frequency must be low enough to maintain DCM operation for a given inductance value. Thus, a lower switching frequency directly helps achieve a higher boost factor in DCM.

In CCM, the switching frequency theoretically does not influence the maximum boost factor, but drive strength and metal-oxide semiconductor field-effect transistor (MOSFET) turnon and turnoff time will limit it in practice. If the driver is weak and the MOSFET switching speed is low, a lower switching frequency is better.

Choosing the inductor

As a rule of thumb, in CCM, an inductor current ripple between 15% and 40% of the maximum load current is preferable. A higher inductance value tends to increase peak efficiency, while a lower inductance value can achieve higher full-load efficiency.

For high boost ratios in CCM, the inductance may need to be high enough so that the internal slope compensation ramp is sufficient. As shown by Equation 3, the slope compensation ramp needs to be at least half of the sensed inductor current’s falling slope.

For a DCM design, the inductance needs to be small enough to operate in DCM at a full load for the given frequency. This can result in high peak currents. Operating in DCM is advantageous because it allows you to achieve a higher boost ratio. Typically, the inductor DC resistance (DCR) must remain small, since DCR has a strong effect on achievable performance.

Component-level design considerations

For the MOSFET, the drain-to-source on-resistance (RDS(on)) must be small, since it has a strong influence on the achievable boost factor. Gate-drain (Qgd) and gate-source (Qgs) charges directly affect the rise and fall time of the switch, respectively, and become a limiting factor for achieving a high boost factor when the driver is weak or the switching frequency is too high.

The total gate charge (Qgate) compounds this issue further, demanding a stronger driver simply to keep switching losses and timing under control. The FET output capacitance, Coss, has a small impact on the maximum achievable boost factor, as long as it does not limit the duty cycle to a lower value than necessary.

This is precisely where gallium nitride (GaN) FETs offer a decisive advantage over silicon MOSFETs: their substantially lower Coss, Qgd, Qgs and Qgate enable much faster switching without requiring an oversized driver, removing this bottleneck and unlocking higher achievable boost ratios.

The output diode in synchronous designs does not significantly influence the boost factor, since its voltage drop occurs on the output side of the converter. A synchronous or nonsynchronous topology also has low impact in this regard.

Finally, both the output capacitor and input capacitor have low impact on the boost factor; for the input capacitor, this holds true as long as the input source is strong, meaning that it has low impedance.

High-boost-ratio design example

Figure 1 shows a single-cell, 3V-to-42V boost converter using the LMG5126 integrated GaN boost converter from Texas Instruments (TI).

Figure 1 The TI 3V to 42V Synchronous GaN Boost Converter Reference Design uses the LMG5126 boost converter with integrated GaN FETs. Source: Texas Instruments

This design achieves an ultra-high-boost ratio of 14-to-1 while delivering up to 20W of output power and maintaining efficiency over 84%, as shown in Figure 2.

Figure 2 GaN FETs ensure over 84% efficiency at 600kHz. Source: Texas Instruments

To avoid the high peak currents associated with DCM operation, the converter operates in CCM, requiring a duty cycle of 93%. A 600kHz switching frequency minimizes the overall solution size. Figure 3 shows the resulting high-duty-cycle switch-node voltage.

Figure 3 This graph shows the LMG5126 boost converter’s switch-node voltage for VIN = 3V. Source: Texas Instruments

Conclusion

Inductor DCR and MOSFET RDS(on) have a high impact on achievable boost factor and should be priorities during component selection. FET rise and fall time may limit the maximum boost factor, and are closely tied to driver strength, gate resistor and FET parasitics. GaN FETs can help enable higher switching frequencies and will increase the boost factor.

Finally, it is essential to check the controller’s maximum duty cycle rating, since this may depend on switching frequency or other design parameters. Following these tips will help ensure success on your next high-boost-ratio converter design.

 

Florian Mueller is a systems engineer and Member Group Technical Staff in TI’s Power Supply Design Services group. He has a master’s degree in electrical engineering from the Technical University of Haag, Germany. Florian’s main focus lies on industrial high-voltage designs for different end equipment.

Moritz Mueller is an applications engineer at Texas Instruments. He has a master’s degree in electrical engineering from the University of Applied Sciences in Landshut, and mainly works on synchronous and nonsynchronous boost converter and flyback designs.

 

Related Content

• Power Tips #90: Get more boost from your boost converter
• Power Tips #115: How GaN switch integration enables low THD and high efficiency in PFC
• Power Tips #138: 3 ways to close the control loop for totem-pole bridgeless PFC
• Should you operate your step-down converter in power-save or forced PWM mode?

The post Power Tips #156: How to design a high-boost-ratio boost converter appeared first on EDN.

Electric linear actuators (ELAs) turn intention into motion—precise, predictable, and quietly powerful. This guide offers elementary notes and practical pointers on their basics and everyday use. Let’s begin with a quick distinction: linear actuators are broadly categorized into integrated, application-specific units and modular, high-performance industrial assemblies.

In its simplest form, an electric linear actuator is a compact device that converts electrical energy into straight-line motion by using a motor to drive a lead screw, ball screw, belt, or gear assembly. This design enables quiet, precise push, pull, lift, or positioning tasks. Unlike hydraulic and pneumatic systems that rely on fluid pressure, electric actuators are valued for their plug-and-play simplicity and self-contained construction.

Moving beyond everyday consumer units brings us to heavy-duty industrial electromechanical actuators. While the underlying physics is identical, industrial-grade assemblies are engineered for demanding environments. They incorporate robust external limit switches to prevent over-travel under massive loads, and precise sensor-driven feedback systems—such as optical encoders or resolvers—that continuously monitor position to enable closed-loop control.

In practice, standard integrated designs are most relevant to consumer automation and light duty cycles, while modular, high-performance systems provide the customizable, feedback-rich precision required for heavy-duty factory automation. By focusing mostly on plug-and-play linear actuators, this guide highlights the approachable designs that make automation not only practical but also empowering for everyday innovators.

Figure 1 Mini electric linear actuators facilitate makers and engineers with a self-contained, ready-to-mount solution for converting rotational motion into linear force. Source: Author

Electric linear actuators: Framing the basics

To appreciate how these actuators empower everyday automation, it helps to start with their core anatomy and working principles. At its heart, an electric linear actuator is a bridge between rotation and translation.

By transforming the circular force of a motor into a steady linear stroke, these devices achieve precise straight-line movement. The primary components of an ELA include an electric motor (the power source), a lead screw or ball screw (the mechanical converter), a drive nut that travels along the shaft, and a gearbox to optimize torque and speed.

Also, most modern electric linear actuators—even the basic models—include a built-in potentiometer. This feature provides precise position feedback, simplifying monitoring and control while ensuring accurate alignment across diverse applications. Together, these elements form a compact system that turns electrical intent into reliable mechanical motion, making automation not only practical but also accessible to routine groundbreakers.

Figure 2 An ELA with an integrated potentiometer enables precise position control by continuously tracking movement across its range. Source: Author

Extending from the actuator’s anatomy, most ELAs incorporate integrated limit switches. These built-in safeguards automatically halt motion at preset travel points, preventing over-extension and protecting both the actuator and the system it serves. In modular or industrial designs, external limit switches may be added for greater flexibility, but in everyday plug-and-play units, their quiet presence ensures dependable, safe operation.

By blending built-in safeguards with straightforward design, electric linear actuators embody the balance of reliability and simplicity that makes everyday automation both safe and accessible.

Internal circuitry and control methods of ELAs

Now let’s look at the basic internal circuitry of a typical ELA equipped with a potentiometer. The potentiometer delivers a resistance or voltage signal as positional feedback, which can be fed into an external controller, such as an Arduino, for precise and reliable motion control.

Within the actuator, two limit switches automatically cut power at the end of the stroke to ensure safe operation. The diodes then allow the actuator to reverse direction, backing away from the engaged limit switch without risk of over-travel.

Figure 3 Here is the basic internal circuitry of an ELA with its integrated potentiometer for feedback and limit switches for stroke-end protection. Source: Author

These ELAs can be driven directly from a suitable DC supply. Applying one polarity extends the actuator, while reversing the polarity retracts it. In simple applications, this can be accomplished with a DPDT switch that manually flips the supply polarity. For more advanced control, an H‑Bridge circuit is used to handle polarity reversal electronically, enabling seamless integration with MCUs and allowing programmable, automated motion sequences.

Beyond the basic designs, advanced ELAs are available with integrated controllers that simplify wiring and expand control possibilities. These models support a variety of industry-standard interfaces, including 0–5 V mode for straightforward analog positioning, 4–20 mA mode for robust industrial signal transmission, RC servo mode for hobbyist and robotics applications, and PWM mode for precise digital control. Such versatility allows these actuators to be tailored to diverse environments, ranging from simple automation tasks to complex, microcontroller-driven systems.

As a practical example, the L12‑I series from Actuonix demonstrates how advanced models integrate internal position controllers. These linear actuators can directly accept position commands, which they then follow without the need for external circuitry. To suit different applications, they support multiple input modes—including 0–5 V analog, 4–20 mA current loop, RC servo signals, and PWM control—offering flexibility across hobbyist, industrial, and embedded system environments.

Figure 4 Demonstrating micro linear actuators with embedded position controllers that accept external commands and follow them precisely. Source: Actuonix

Engineer’s checklist: Design insights for ELA selection

When selecting an electric linear actuator, engineers weigh several key specifications that define performance and suitability for the application. For a start, dynamic force indicates the actuator’s ability to move a load while in motion, while static force reflects its holding capacity when stopped.

Speed (inches/second) determines how quickly the actuator can extend or retract, often balanced against load requirements. The duty cycle specifies how long the actuator can operate relative to rest periods, critical for avoiding overheating. Stroke length defines the maximum travel distance, and the IP rating (for example, IP66) ensures protection against dust and water ingress for harsh environments.

Electrical input—whether DC or AC—and the maximum current draw influence compatibility with power systems. Mechanical details such as clevis-end diameter affect mounting and integration. Finally, limit switches, either internal factory-preset or external, provide end-of-travel control and safeguard against overextension.

Beyond mechanical and electrical parameters, actuator selection also depends on control and interface compatibility. Options include analog signals (0–10 V or 4–20 mA) for proportional control, digital I/O for simple extend/retract commands, and PLC interfaces for automation environments. Advanced models may support bus-based protocols like CANopen or Modbus, enabling precise synchronization and monitoring.

In addition, potentiometer feedback—whether linear type and built-in or external—provides position lookup and monitoring, ensuring precise control and seamless integration with automation systems. Together, these specifications and interface options ensure the actuator not only meets load and speed requirements but also integrates seamlessly into the broader control architecture of the application.

Figure 5 An optical feedback linear actuator datasheet snippet highlights its specifications. Source: Firgelli Automations

Extend–retract: Closing the loop

From factory automation to medical devices to renewable energy systems and even smart home solutions, electric linear actuators prove their versatility in delivering controlled, reliable motion. Their practicality is not just in the datasheet; it’s in the hands of engineers who design systems around them and makers who adapt them to solve real-world challenges, turning specifications into productivity and innovation.

This blog has walked through the essentials, but the field stretches far wider than what I have outlined here. What I have covered is a starting point. If you see an application, parameter, or design cue I missed—fill it in. Your insights will enrich this guide and help shape a more complete, practical resource for the engineering community.

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

• DIY Linear Actuator Controller
• Programmable driver targets piezoelectric actuators
• Senseg unveils breakthrough flexible actuator technology
• ALPS: Piezoelectric actuator has very compact dimensions
• Compact electric actuators provide unlimited rotary motion

The post Driving motion: A practical guide to electric linear actuators appeared first on EDN.

A zonal power distribution network for cars offers many benefits, but how it affects finding problems is unclear.

In the few years, I’ve been seeing a lot of stories about zonal architecture, the next stage in the evolution of providing power to the many dispersed automotive-electronics functions. This architecture is increasingly being designed into cars for many solid technical reasons.

What is a zonal architecture? I won’t do a deep dive into details, as it has been discussed in detail in EDN and elsewhere. In short, it divides the car’s power distribution network (PDN) along geographic zones, each with a regional power controller, and all supplied by a central power controller and the car batteries. Each of these regional controllers provides power to the local regulators of individual modules in the car – cars now typically have over a hundred of these, permeating and managing every nook and cranny.

On the face of it, zonal makes a lot of sense with respect to weight, cabling complexity, power-systems management, and many other critical factors. This is especially the case as the siting and number of zones can be adjusted to fit the vehicle arrangement (Figure 1).

Figure 1 A zonal architecture assigns a controller (power manager) to different physical areas of the car, and the number and placement of these zones is flexible. (Image source: EV Engineering Online)

It is a radical departure from its predecessor, usually called a domain or centralized architecture (Figure 2). In that classic arrangement which has been used for decades, power distribution is not determined by the physical or spatial location of loads in the car, but rather the function of the module(s) being supported. For example, the four power windows might have a single power unit for all four windows (and maybe the trunk release) with DC rail cabling running to all these locations.

Figure 2 In the widely used domain architecture, controllers are assigned to cover one or more related functions (left); in the zonal approach, the controller division is by physical location the vehicle. (Image source: EETimes Asia)

The domain architecture was the second stage in this evolution. It was the successor to tried-and-true distributed power, which is conceptually the simplest and made a lot of sense in cars when there were relatively few electrical loads.

Distributed power is clear: each load, such as the radio, lights, starter motor, or dashboard, has a direct connection to the battery (regulators were largely non-existent) with a simple on/off switch for that loop (there might be an intermediate relay for higher-current loads). Each loop and load was physically and electrically separate and independent of all the others.

This arrangement made it easy to add loads or disconnect them. Even better, when the car was off – meaning the physical key was out of the ignition – there was zero vampire drain. The only drain on the battery was its self-drain of around a few percent per month.

Why I’m intrigued by the zonal architecture

I’ve been especially interested in the promised benefits of zonal control since I have had a run of electrical problems in my basic ICE 2019 Subaru Outback with 60,000 miles. This car predates zonal distribution, and even uses tangible buttons (networked, of course) for most functions such as A/C; the touch screen is only for secondary functions such as radio, map, and housekeeping (you can drive the car without problem even if that screen blanks out.)

I’ve had these three problems, directly or indirectly related to “vampire drain”:

1. First, the car’s 3G transponder, formally called a Telematics Data Communication Module (TDCM or DCM), kept trying to connect to that service, thus killing the battery. The problem is that 3G is being “sunsetted”, so nearby towers were going dark, and it was trying to link up with a non-existent service (or what if it was in an underground garage?). It kept trying and trying, killing the battery since I didn’t start the car for a few days. The dealer replaced the module free of charge for this known but kept-quiet design flaw.
2. Then, a module that controls power flow to other modules when the car is nominally off malfunctioned and allowed too much vampire current to flow. Again, the module was replaced at no cost to me, but not until I had to jump-start the car.
3. Finally, the door-lock module malfunctioned, and I could only get into the car using the mechanical key that comes with the electronic key fob. While that would be a major annoyance, the added problem was that in this fault mode, the module continued to drain excessive power, again killing the battery.

Yet in all the talk about the zonal architecture, I have seen barely any mention of how it impacts electrical-system troubleshooting. Will it make it easier, harder, or very difficult?

Speaking as a car owner – not as a designer or manufacturer – that’s an important issue.  As cars get more complicated electrically with mandated features, enhanced drive-train control (where ICE, EV, or hybrid), ADAS functions, and more “smarts”, dealing with something that is no longer working can be an impressive challenge leading to quick, easy, and incorrect answers.

How so? When I brought my car to the dealer for each of the three problems with the symptom “dead battery,” the service tech checked the charging system, saw that was good, and so assumed it had to be a bad battery (each time replaced under warranty). Yet the real problems were those load modules drawing vampire current for various reasons.

What’s my user-side concern?

I’m not at all saying that the zonal architecture is a bad thing or a step backwards. I am only observing the extent to which its proponents – all very credible people – have focused almost entirely on its design/build impact and not discussed any in-the-field troubleshooting considerations.

I’ve been burned before by this scenario, and so I get a little worried when proponents of a new architecture or technology talk almost exclusively about its virtues but ignore discussion of any drawbacks. As engineers, we know that nearly every design decision involves pros and cons with respect to overall performance, weight, efficiency, manufacturability, and cost, and these have to be weighed against each other. Nearly every advance also has some downside ranging from trivial to a somewhat bigger deal.

This happened with USB-C and USB-PD (Power Delivery): whatever your requirements within its large power-range “envelope”, USB-C in conjunction with USB-PD is posited as the “universal” solution. Yet experience has shown that such broad, all-encompassing solutions can get a little too clever for themselves, as they try to accommodate so many use cases and scenarios. There are so many power-interconnect arrangements and possibilities, with so many variations, that many cannot be anticipated, tested, or validated despite a detailed standard. USB-C and USB-PD embed the opposite of the engineer’s top rule: keep it simple.

I expressed my concerns about USB-C and USB-PD in a recent EDN blog and received some supporting comments (USB-C and Power Delivery: Too much of a good thing?). As further confirmation, my colleague, EDN’s Associate and Contributing Editor Brian Dipert – who has much more hands-on experience in power interconnects and related – expressed similar concerns along with evidence (USB-C’s lingering incompatibilities and other complexities, part 1: Direct-connect complications and USB-C’s lingering incompatibilities and complexities, part 2: Splitter issues).

My question is simple: what’s the impact of the zonal architecture on troubleshooting? Will service technicians be further confused by its intricacies? Alternatively, is there evidence showing it will actually ease the troubleshooting problem, given the huge number of loads that the vehicle power subsystem must support along with their interconnection via various in-car networks?

I’m not an anti-advances person, but I do sometimes long wistfully for the early days of cars (and other products) when each load was on its own circuit from the battery, and you could troubleshoot most electrical problems with a schematic diagram and multimeter to read voltages, currents, and resistances. There’s a lot to be said for this type of directness and simplicity, that’s for sure, even though I know it’s not coming back.

Do you have any insight or thoughts about zonal architecture and eventual need for troubleshooting?

References:

• 48V zonal architecture made easy using power modules, Vicor Corp
• Zonal Electrical Architectures Cut Vehicle Wiring-System Cost, Complexity, TE Connectivity (via Tech Briefs)
• Zonal Architecture 101: Reducing Vehicle System Development Complexity, On Semiconductor
• Zonal Architecture vs. Domain Architecture: Modular Automotive Infrastructure Face Off, Molex LLC
• SDV Series Episode 2: From Domains to Zones , Keysight Technologies
• Zonal Wiring Architecture Will Make EVs Easier to Assemble, Assembly Magazine/BNP Media
• The hidden car revolution: zonal architecture, ST Microelectronics
• How a Zone Architecture Paves the Way to a Fully Software-Defined Vehicle, Texas Instruments

—Bill Schweber is a degreed senior EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features. Prior to becoming an author and editor, he spent his entire hands-on career on the analog side by working on power supplies, sensors and signal conditioning, and wired and wireless communication links. His work experience includes many years at Analog Devices in applications and marketing, and he also developed significant mechanical-engineering insight while designing control electronics for large materials-testing systems.

Related Content

• Accelerating the shift to next-gen SDVs with zonal MCUs
• Automotive Architecture

The post How will zonal architecture impact automotive troubleshooting? appeared first on EDN.

For decades, semiconductor progress trained us to think about scaling in a particular way. Make the fundamental building block smaller, increase density, improve performance, and integrate more functionality into the same physical space. However, an optical interconnect doesn’t have an equivalent scaling mechanism.

There is no single optical knob that can simply be turned generation after generation to deliver the bandwidth required by future AI and HPC systems. Instead, optical systems have advanced by combining multiple dimensions:

• Higher baud rates
• More wavelengths
• More fibers
• More spatial channels
• Higher-order modulation
• Stronger DSP and FEC
• Better photonic integration
• Shorter electrical reach
• Co-packaged and near-package optics

Each contributes another part of the bandwidth equation. But increasingly, no single one appears capable of carrying the scaling trajectory alone. That changes the nature of the problem.

So, the next generation may be defined less by one component becoming dramatically faster and more by how many different scaling mechanisms can be made to work together in one physical system.

One channel can only be pushed so far

The most direct way to increase bandwidth is to increase the rate of a single channel. That approach has worked repeatedly. But higher serial rates progressively tighten nearly every part of the link, and as a result, electrical insertion loss becomes more difficult, jitter budgets shrink, and equalization becomes more aggressive.

Moreover, modulators require greater bandwidth, photodetectors must respond faster, and signal-to-noise margin becomes harder to preserve. Consequently, digital signal processing (DSP) complexity increases, power rises, and thermal density grows with it.

At some point, simply making one lane faster becomes increasingly expensive in power, margin, latency, or implementation complexity. So, another dimension is introduced: instead of one faster channel, use more channels.

When parallelism becomes difficult, add wavelengths. When wavelength count becomes constrained, add spatial paths. When raw signal quality becomes insufficient, add more sophisticated modulation, DSP, and coding. Each mechanism extends aggregate bandwidth, but each one also adds another architectural dependency.

Wavelength becomes a scaling dimension

Wavelength-division multiplexing (WDM) allows multiple optical carriers to share the same physical path. That is an extraordinarily powerful scaling mechanism. Instead of increasing fiber count every time capacity increases, multiple channels can be carried simultaneously on one fiber or waveguide.

However, wavelength scaling is not free bandwidth. Lasers must remain within controlled operating windows, and filters and resonant structures must maintain appropriate spectral relationships. Otherwise, temperature can shift wavelength and process variation can shift device behavior, so control and calibration may become necessary.

More channels increase characterization and test complexity. Therefore, WDM increases aggregate bandwidth while simultaneously introducing additional thermal, process, control, and manufacturing requirements. Therefore, while the optical capacity increases, so does the architectural requirements needed to sustain it.

Space becomes another dimension

When wavelength or serial scaling is insufficient, physical parallelism becomes another option. There are more fibers, fiber arrays, and waveguides. Then there are parallel optical engines, multicore fiber, and spatial-division multiplexing.

Again, capacity can increase significantly, but physical parallelism creates another set of challenges. For instance, alignment becomes more demanding while connector density increases. Also, fiber attach becomes more complex, and package escape becomes more difficult.

As a result, assembly tolerances tighten and test channel count increases. Furthermore, yield can become increasingly sensitive to the number of optical paths that must all operate correctly.

How modulation and coding extend the channel

When the raw physical channel cannot be improved enough, more information can be extracted from it. Here, higher-order modulation places more information into each symbol and DSP compensates for impairments. Next, forward error correction (FEC) allows operation in regimes that historically would have produced unacceptable error rates.

These techniques are remarkable examples of engineering overcoming physical constraints. But they also move complexity into other parts of the system. For instance, more DSP consumes power, more sophisticated modulation usually requires greater signal quality and control, and FEC can introduce latency.

Also, transmitters and receivers become more complex and characterization becomes more difficult. So, system performance becomes increasingly dependent on the combined behavior of optics, electronics, algorithms, power delivery, and thermal conditions. At that point, the link is no longer simply an optical-device problem; it’s an architectural issue.

Electrical and optical scaling getting coupled

This becomes especially important as optical engines move closer to compute. Traditional pluggable optics created a relatively clear boundary. The electrical system drives the module, the module performs electrical-to-optical conversion, and the fiber carries the signal.

As bandwidth rises, however, the electrical path between the processor, switch, or accelerator and the optical module becomes increasingly costly. Board loss rises, SerDes power increases, and equalization becomes more demanding. In short, electrical reach begins consuming a growing fraction of the system power budget.

That is one reason near-package optics (NPO) and co-packaged optics (CPO) are receiving so much attention. Shortening the electrical path can help substantially, but the interconnect problem does not disappear. It moves, so the package must now support:

• High-speed electrical I/O
• Optical coupling
• Laser deliver
• Fiber attachment
• Power delivery
• Thermal gradients
• Mechanical stress
• Alignment stability
• Test access
• Manufacturing yield
• Serviceability

As optical engines move closer to compute, component benchmarks become less meaningful in isolation. A faster laser, modulator, or detector creates system value only when its performance can be preserved through electrical drive, thermal conditions, optical coupling, alignment, packaging, manufacturing, and test.

The useful performance of the optical link is therefore increasingly determined by the architecture surrounding the device, not by the device alone. Moving optics closer to compute therefore does more than shorten an electrical connection. It changes where the system boundary must be closed.

Package becomes part of optical scaling strategy

At moderate bandwidth density, packaging can sometimes appear to be supporting infrastructure around the optical function. At extreme bandwidth density, that distinction becomes difficult to maintain.

The package determines how close the optical engine can be placed to compute. It influences electrical reach, determines fiber and optical access, and carries the power. Next, it establishes much of the thermal environment and influences mechanical stability and alignment. That affects manufacturability and yield and determines how the device can be inspected and tested.

That influences long-term optical performance through thermal expansion, stress, material movement, and aging. This means optical scaling can no longer be separated cleanly from advanced packaging. So, the relevant question is no longer how fast is the modulator or how many wavelengths can the fiber carry?

The more important question becomes: Can the optical, electrical, thermal, mechanical, packaging, and manufacturing architecture support the required bandwidth together? That is a system-level scaling problem.

Scaling mechanisms beginning to stack

This may define the next phase of optical interconnect. A future architecture may simultaneously use:

• Higher symbol rates
• Multiple wavelengths
• Spatial parallelism
• Advanced modulation
• DSP and FEC
• Co-packaged or near-package optical engines
• New fiber or waveguide structures
• More sophisticated thermal and control systems

As a result, the scaling mechanisms begin to stack. That creates enormous potential bandwidth. But it also means that every generation depends on a larger number of interacting mechanisms functioning correctly at the same time. Theoretical aggregate bandwidth may be extremely high.

The realizable bandwidth is constrained by whether all of those mechanisms can coexist within acceptable mode:

• Power
• Latency
• Temperature
• Signal margin
• Alignment tolerance
• Manufacturing yield
• Testability
• Reliability
• Cost

The scaling limit therefore begins to move. It’s no longer determined only by the maximum capability of an individual optical device. It’s increasingly determined by the ability to integrate multiple scaling dimensions into a manufacturable system.

Architecture becomes multiplier

This leads to a broader distinction. Electronics historically extracted enormous value from repeatedly improving a fundamental building block. Make the transistor smaller and many system-level advantages followed. But optics has no single, equally-dominant scaling knob.

So, optical interconnect increasingly creates aggregate progress by combining several mechanisms at once. However, it doesn’t make device innovation less important.

• Better lasers matter
• Better modulators matter
• Better detectors matter
• Better fibers matter
• Better photonic platforms matter
• Better electronic interfaces matter

But the value of each technology increasingly depends on how successfully it participates in the larger system. A high-performance modulator may be difficult to scale if its thermal sensitivity requires excessive control. A fiber architecture may provide enormous theoretical capacity but struggles if connectorization and alignment become impractical.

A wavelength-rich design may lose its advantage if tuning and calibration consume too much power. An optical engine may achieve exceptional bandwidth density but fail economically if assembly yield is too low. A very fast lane may provide little system benefit if the electrical path required to drive it consumes too much power.

There is no isolated winner. Architecture determines how much of each technology can actually be used.

Metric is also changing

Optical progress has traditionally been summarized with headline numbers such as Gb/s per lane or Tb/s per module. Those metrics remain important, but architectural scaling demands broader measures.

• Bandwidth per watt
• Bandwidth per fiber
• Bandwidth per package edge
• Bandwidth per unit area
• Bandwidth per optical engine
• Bandwidth per dollar
• Bandwidth at acceptable manufacturing yield
• Bandwidth that remains stable across temperature, variation, and lifetime

Those metrics force physical realization into the discussion. A laboratory demonstration with extraordinary bandwidth is not automatically a scalable interconnect. A solution that achieves higher throughput by consuming excessive DSP power may simply move the system bottleneck into cooling.

A solution that increases channel density while making alignment intolerant to normal manufacturing variation may convert a bandwidth improvement into a yield problem. A design that performs at room temperature but shifts substantially across real operating conditions may not provide the usable bandwidth suggested by its nominal specification. Bandwidth alone is therefore not enough. The bandwidth must be realizable.

Next optical breakthrough may not be one device

The next major optical interconnect advance may therefore look different from historical semiconductor scaling. It may not arrive as one device or material that suddenly changes the entire trajectory. It may arrive as an architecture that combines several imperfect technologies unusually well.

• A little more baud rate
• More wavelengths
• More spatial parallelism
• Better modulation
• Better DSP
• Shorter electrical reach
• Better photonic integration
• More advanced packaging
• Better thermal control
• Better assembly
• Better test

Each contributes part of the answer. The breakthrough is making them coexist without losing the benefit to power, manufacturing complexity, yield, reliability, or cost. That is the architectural transition.

Optical scaling becoming system scaling

AI and HPC systems are creating extraordinary pressure on interconnect bandwidth. That pressure is unlikely to disappear, so individual optical and electronic devices will continue improving. But the bandwidth trajectory required by future systems may increasingly exceed what any single scaling mechanism can provide.

When that happens, architecture becomes the multiplier. The question changes from how fast can one optical link become to how many scaling dimensions can be combined into one manufacturable, power-efficient, reliable physical system? That is a different problem.

It’s also a much larger opportunity. The next optical scaling law may not belong to a single device. It may belong to the architecture that successfully combines multiple scaling dimensions into one realizable system.

When one physical dimension cannot scale fast enough, the system must scale in many dimensions. That’s why optical scaling is becoming architectural scaling.

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

Related Content

• AI Clusters Spur Optical Connectivity
• The 200G/lane CPO pushes optical interconnect boundaries
• Where co-packaged optics (CPO) technology stands in 2026
• Photonics: A Foundational Scaling Layer for AI-Era Computing
• From Co-Packaged Optics to Nanolasers, Photonics Moves Inward

The post Optical scaling turning into an architectural challenge appeared first on EDN.

While updating and streamlining the hardware setup improved the situation, why it achieved this welcome outcome was less clear. And then there was the truly “shocking” discovery…

Last time, in part 1 of this series, I gave a historical overview of my longstanding broadband and television relationship with Comcast (aka Xfinity, the company’s brand for consumer products and services), focusing on the service in my most recent (and current) Colorado residence.

Specifically, I discussed the increasing frequency and severity of service “drop” issues my wife and I experienced subsequent to inadvertent cabling damage consecutively done by our community’s water and sanitation service provider last October and our power company earlier this summer.

At last week’s writeup’s conclusion, I was awaiting the arrival of yet another Comcast technician, subsequent to a recent service issues-escalation to a near-daily cadence (a particular problem given that my wife and I both work from home), an on-site visit which I’d insisted on sticking with in spite of the service’s as-usual temporary resurrection later that same evening. The on-site technician visit wasn’t scheduled until the next afternoon, but he called me mid-morning that (next) day and asked if he could arrive early, a rare deviation from the “late arrival” norm.

Competence is the best

Appreciative of his promptness and hopeful that I could still persuade him into making the debug session gratis for us, I asked him to delay his arrival only 45 minutes until my wife and I had both wrapped up a few work to-dos. He happily obliged, subsequently pulling up on the street in front of our house right on time. I’m not sure whether he was an “official” Comcast employee or a contractor, not that it really matters; his vehicle was a minivan with no corporate markings on it, albeit filled with Xfinity-branded tools, cabling, and other equipment.

I identified myself as a “techie” and asked if I could follow him around, periodically picking his brain and more generally absorbing through observation at least a bit of his conceptual plus experience-accumulated knowledge. He was happy to oblige: “this’ll be fun” were his exact words. And indeed he was smart and nimble of mind, not to mention enthusiastic; a delightful experience, all in all. But he also was in a hurry, so I strove to practice appropriate question-cadence restraint.

The first notable thing I learned from him was that the strand of coax coming out of the ground around the back of the house was completely unrelated to the plastic box labeled “Comcast” attached to the wall on the other (front corner) end of the house, first mentioned and pictorially shown in part 1 of this series.

This cable ran straight to the tap near the street. I assumed it was the mysterious “other line of service that the prior owner had installed” mentioned by the realtor more than a decade earlier.

Speaking of taps, not to mention the RF amplifiers I mentioned last time, along with other constituent building blocks of a hybrid fiber-coax system such as Comcast’s, check out this block diagram from Wikipedia’s as-always thorough, accurate and otherwise excellent entry on the topic.

I don’t know, by the way, where the fiber-to-coax conversion node(s) is/are located in our community, either in general or to what degree of proximity to my residence location.

MIA (not to mention obligatory)

The second thing the technician immediately noticed and I learned, to our mutual great dismay, was that this length of coax was nowhere properly earth-grounded nearby where it entered my home. The plastic box, which I was now realizing was likely associated with the legacy Comcast service likely stretching back to the original owners, was grounded.

As was the tap near the street.

But here? Nothing. Thereby representing not only potentially serious fire and electrocution danger for the home and its occupants but also suggestive of why I’ve endured multiple bouts of electrical shock-induced equipment destruction in my so-far time here (ironically, by the way, there’s a summer-monsoon lightning storm underway as I type this).

Then he saw the three-way splitter attached to the outer wall, which predated (by how long I have no idea) the initiation of my home ownership. Attached to the input end was the PoE (which stands for point-of-entry in this particular case, not power over Ethernet) filter I’d subsequently added for network security purposes back when I was experimenting with MoCA, and which I’d neglected to remove afterwards.

And attached to the splitter outputs were short spans of coax that ended up at wall connectors in two downstairs bedrooms (one each), along with a longer third coax span that also ended up inside, this time in the furnace room, where it split one more time and fed both the CableCARD receiver and cable modem.

After shaking his head and muttering “I don’t know how you even have any broadband service at all” under his breath, he fired up his smartphone, on which was installed a Comcast-proprietary (presumably) app that enabled him to live-monitor my cable modem’s statistics over its WAN connection. Once again, this time louder and more emphatically, he said (and this time also gestured), “I don’t know how you even have any broadband service at all” and invited me to look at the phone display for myself.

I noticed that the upstream transmission power ratings for the various in-use channels were all in the upper 50 dBmV range. I didn’t know much (and still don’t know as much as I’d like) about cable systems, but I knew enough to realize that this wasn’t a good thing.

Swaps and simplifications

Again, I realized he was in a hurry, so I refrained from asking a bunch more questions. He indicated that he thought the existing splitter was left over from a long-past satellite television system installation. I don’t quite buy that theory; although the DC power pass-through support and broader top-end frequency afforded by such a splitter (2.4 GHz vs 1 GHz, with a common 5-MHz bottom end of the range), the latter theoretically allowing for neighbors’ latest-generation MoCA signals to “leak” into my setup, might destructively interfere with my DOCSIS 3.1 modem. So, the PoE filter I’d inadvertently left installed would (or at least should) have alternatively blocked neighborhood noise.

That said, the splitter and filter were admittedly ancient, both also containing passive RF circuitry. So, perhaps something inside either or both had gone awry with advancing age and longstanding lightning, moisture, temperature, and other ambient environmental exposure.

He asked if I was currently using the downstairs bedrooms’ splitter outputs. When I replied in the negative, he wholesale-replaced the splitter with a grounding block (and wire) containing an integrated PoE filter, leaving the other two previous splitter-supplied coax feeds detached.

He also swapped out the connectors on both ends of the new grounding block-plus-PoE filter combo. Then he revisited his smartphone app and happily reported that the data he was seeing was “still not great, but much better now, and good enough”. Again, I got only a brief glimpse of the screen, but enough to confirm that the upstream channels’ power measurements were all now comfortably in the lower end of the 50s dBmV range.

I wish they were even lower than that, but again, we’re at the end of the neighborhood “loop” line. And it’s been more than three weeks (as I write this) since his visit, with not a single service drop, so in the spirit of “perfect is the enemy of good”…I’m good!

In case you were wondering, by the way, I immediately ordered, and subsequently installed as soon as it arrived, a grounding rod to attach to the other end of the grounding block-and-wire he’d generously given me.

The sticker on the side of the rod’s snug plastic packaging was awesome.

When I walked him back to his car (passing by the mysterious plastic box marked Comcast on the way, of which he had no knowledge and no spare time to further explore that day), he gifted me a bunch of extra hardware—MoCA filters, grounding blocks, 2- and 3-way splitters, and a 10’ span of high-quality coax cable with connectors on both ends—all of which I’ll be discussing more in next week’s finale (as planned, but who knows for sure) to this series.

In the upcoming concluding post(s), I’ll suggest some possible theories as to why (and to what degree, straight from my cable modem’s logs) his efforts bore fruit. I’ll also share the results of my subsequent sleuthing regarding the aforementioned mysterious plastic Comcast box and the various cables running into and out of it, as well as what was within it. Stay tuned for that and more; for now, please continue to share your thoughts in the comments!

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

Related Content

• Debugging intermittent Comcast, part 1: Scenario-setting
• Will a location change improve my MoCA?
• The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
• A quest for faster upstream bandwidth
• Lightning strikes…thrice???!!!

The post Debugging intermittent Comcast, part 2: Remediation details appeared first on EDN.

We stand at the dawn of a new era in chip design as artificial intelligence (AI) moves from a conceptual promise to a practical necessity in the semiconductor landscape. Semiconductor companies are looking to AI to help manage design complexity, accelerate development cycles, and maintain the high standards of quality and reliability demanded by the semiconductor industry.

IC design teams are confronting physical, electrical, and reliability verification challenges that require new approaches to achieve acceptable speed and cost. Advanced-node designs bring thousands of design rules, dense hierarchical layouts, and millions of circuit errors that need to be debugged during the design flow. Manual workflows that once sufficed now create schedule bottlenecks which threaten product launches and market windows.

This creates a fundamental tension between speed and risk: Verification teams need AI-driven acceleration to manage complexity and compress schedules, yet IC signoff remains one of engineering’s most risk-averse domains.

A single undetected error can cost millions in respins or field failures. The question facing design organizations is not whether to adopt AI, but how to deploy it in ways that enhance both speed and confidence.

The intelligence foundation: Generative and agentic AI platforms

By balancing advanced algorithms with openness, these platforms can serve design needs while upholding intellectual property (IP) integrity—a crucial factor for building trust. Such systems ensure that designers can tap into a powerful, secure, and customizable environment, enabling continuous learning within a protected infrastructure.

The AI platforms becoming available are designed to integrate across the entire electronic design automation (EDA) tool stack, providing a unified intelligence layer. Figure 1 shows an example of a system architecture that integrates AI models with a multimodal “data lake” to support diverse verification tasks.

Figure 1 In an AI platform for chip design, the internal architecture with AI models and a multimodal data lake underpin the tools for a design flow. Usage modalities are shown on the right. Source: Siemens EDA

Determinism at the core: Why signoff engines must remain AI-free

A strategic consideration in the age of AI is that for the core signoff calculations—which determine whether a chip design is clean and ready for manufacturing—must be done with rigorous, deterministic algorithms, not probabilistic AI models. IC design teams responsible for signoff need confidence that repeated runs will always produce the same results; there is no room for AI “hallucinations” seen with probabilistic models.

This foundation in determinism directly supports trust in any design flow that includes AI. Engineers, managers, and foundry partners must be able to rely on results, providing certainty that each signoff result is the product of rigorous, provable mathematics. Figure 2 illustrates how a deterministic signoff engine remains central to the process, ensuring reproducible analysis and audit-ready results, while AI-powered tools enhance peripheral tasks like setup, error debugging, and collaboration.

Figure 2 This diagram illustrates an AI-augmented signoff process, detailing inputs, the core deterministic signoff engine, AI-accelerated setup, AI-powered error grouping and debug, AI-enabled collaboration tools, and the resulting outputs. Source: Siemens EDA

Productivity revolution: Where AI transforms the verification journey

While the core signoff remains deterministic, the path leading to signoff involves a series of complex phases that are ripe for AI-driven optimization. Leveraging AI in conjunction with deterministic engines is already improving productivity in three primary areas:

Resource optimization

Setting up verification jobs is increasingly complex, time consuming, and error prone due to the number of tasks and different compute environments, from on-premise clusters to the cloud. AI can help engineers manage and optimize these jobs by providing real-time monitoring, actionable recommendations, and post-run analytics. This approach improves hardware usage through compute resource optimization and speeds up job turnaround.

Error debugging and prioritization

One of the biggest bottlenecks in signoff is debugging. Designs at advanced nodes often generate millions of errors in early verification passes. AI-powered tools let designers sift rapidly through enormous error sets by categorizing and prioritizing issues so engineering attention is immediately focused on the most critical problems. In one instance, a leading GPU manufacturer leveraged AI-driven visual analysis to reduce verification time by 50%—translating weeks of effort into just days.

Collaboration and delegation

Modern semiconductor teams are globally dispersed. AI can group errors and assign them to specific team members, ensuring that productivity isn’t lost in handoffs. Applying familiar digital collaboration workflows—such as bookmarking and assignment—in an engineering context brings clarity and speed to what used to be a fragmented process.

AI-driven verification tools, like the one illustrated in Figure 3, integrate full chip analysis with intelligent debug capabilities to streamline error management and team communication.

Figure 3 Modern verification software provides a visual interface for full chip analysis, intelligent debugging through error clustering and prioritization, and enhanced user collaboration for streamlined results distribution. Source: Siemens EDA

Learning and growing with AI-assisted tools

AI in physical or electrical verification is not just about automation for its own sake. Features that provide contextual, in-house documentation and root-cause explanations help both experienced and junior designers understand not only what went wrong, but why it matters and how to fix it.

Incorporation of AI into design tools can be used to capture critical designer knowledge that can be leveraged throughout the organization. In this way, AI is part of the debug process, where a training aid accelerates ramp-up and enables distributed teams to achieve expert-level productivity.

Figure 4 shows how an intelligent interface can display a detailed list of design checks with results, allowing users to add fixing suggestions, view visual comparisons, and access shared notes. In this example, this “assistant” gets more valuable over time as it captures designer expertise every time it’s utilized.

Figure 4 Capturing notes about fixing a violation or displaying shared insights across the organization enhances the design verification flow. Source: Siemens EDA

Keeping IP secure: Customization, openness, and control

Gaining trust in AI also depends on how data is managed and knowledge is shared. A “data lake” approach ensures each organization can incorporate its own designs, best practices, and internal documentation into the AI system—always within a secure, isolated environment. The result is continuous system learning and richer insight that ensures sensitive IP remains strictly within the company boundary.

As design and manufacturing complexity continue to grow, the industry is extending AI-enabled productivity gains to additional domains: layout versus schematic (LVS), electrical reliability, and even automated error correction. The roadmap is ambitious, but the guiding philosophy remains clear: trust the deterministic core and unleash productivity with AI where it adds value.

AI with accountability: A balanced approach

The semiconductor industry’s balance between innovation and risk requires a nuanced approach to AI. By aiming for practical automation around a bedrock of deterministic signoff, design teams can achieve real-time productivity and confidence without compromising on quality or control.

As industry moves toward higher complexity chips, this blend of innovation and trust will be the true differentiator in AI-driven EDA.

Carey Robertson, VP of product management at Siemens EDA, oversees the product development for Calibre Design Side products. He has been with Mentor Graphics/Siemens EDA for 27 years in various product management/engineering roles. Prior to Siemens EDA, Carey was a design engineer at Digital Equipment Corp. (DEC), working on microprocessor design.

Related Content

• AI features in EDA tools: Facts and fiction
• What is the EDA problem worth solving with AI?
• EDA’s AI Revolution Meets Its Real-World Constraints
• AI in EDA Is Real, It’s Now, and It’s on Show at DAC 2026
• Next Gen AI EDA Startups Have Potential to Disrupt Design Automation

The post How AI is reshaping IC signoff: Trust, speed, and intelligent workflows appeared first on EDN.

The G3VH SiC MOSFET relay from Aratas America supports high-voltage switching applications requiring load voltages of 1800 V or 3300 V. SiC MOSFET technology enables high-voltage switching with low leakage current and fast switching while minimizing power loss and heat generation.

The G3VH relay is well suited for semiconductor test equipment, battery management systems, measuring instruments, and other applications demanding precise, high-voltage switching. Available in a 6-pin DIP with either board-mount or surface-mount terminals, the device contributes to equipment miniaturization.

The 1800-V and 3300-V versions support continuous load currents of 30 mA and 300 mA, respectively, with maximum leakage currents of 10 µA and 1 µA when the relay is open. Maximum turn-on times are 1 ms for the 1800-V version and 2 ms for the 3300-V version, while turn-off time is 0.2 ms for both versions. On-resistance is 200 Ω for the 1800-V version and 5 Ω for the 3300-V version. These specifications are measured at an input current (IF) of 10 mA and the respective continuous load current, with the load current applied for less than 1 s.

G3VH relays are available from authorized distributors, including Arrow Electronics, Newark, and Mouser.

G3VH product page 

Aratas America 

The post SiC MOSFET relay switches up to 3300 V appeared first on EDN.

Advantech has launched four industrial vision intelligence products based on the Qualcomm Dragonwing IQ-9075 processor. The AOM-6741 SMARC module, ASR-A503/AFE-A503 robotic controllers, and AIR-055 edge AI system deliver up to 100 TOPS of AI performance and provide interfaces for multi-camera vision processing. They enable real-time vision reasoning for robotics, industrial automation, and smart surveillance applications.

The Dragonwing IQ-9075 integrates an ISP, VPU, and NPU with MIPI-CSI, USB 3.0, and GbE interfaces for image preprocessing and video streaming. It supports multi-camera deployments and computer vision workloads such as object detection, tracking, and OCR. The processor also features an 8-core Kryo Gen 6 CPU and an integrated MCU subsystem for real-time, deterministic performance.

Each IQ9-powered product offers a range of communication interfaces. The AOM-6741 full-size SMARC 2.2 edge AI module includes four 4-lane MIPI-CSI camera inputs. The ASR-A503 4-in. single-board robot controller and AFE-A503 enclosed controller provide sensor connections for up to eight GMSL cameras. The AIR-055 edge AI inference system supports multimodal inputs in a fanless, enclosed design.

Samples of the AOM-6741, ASR-A503, AFE-A503, and AIR-055 are now available.

Advantech

The post Advantech brings 100-TOPS AI to vision systems appeared first on EDN.

Toshiba’s TCKE1401NM 75-V, 6-A eFuse provides 48-V power-line protection for industrial and consumer equipment, including servers and power tools. In addition to short-circuit, overcurrent, and overvoltage protection, it integrates reverse current blocking, input reverse polarity protection, and thermal shutdown in a 4×4-mm VQFN24D package.

The TCKE1401NM operates from a 4.7-V to 75-V input, with an 80-V absolute maximum input voltage. Its high-voltage tolerance makes it suitable for power-line protection in 24-V, 48-V, and 54-V systems. The eFuse has a maximum output current of 6 A and integrates a MOSFET with a typical on-resistance of 44.5 mΩ, helping to reduce power loss during operation.

Operating thresholds for overcurrent limiting (0.82 A to 6.43 A typical), undervoltage lockout, and overvoltage protection are set with external resistors. Slew-rate control is adjustable with an external capacitor to reduce inrush current. Overcurrent fault response is selectable via a mode pin for either auto-retry or latch-off operation. Reverse current blocking and reverse polarity protection are provided using an external MOSFET.

Toshiba says it has now begun shipments of the TCKE1401NM eFuse.

TCKE1401NM product page 

Toshiba Electronic Devices & Storage 

The post eFuse protects 48-V power lines appeared first on EDN.

Morse Micro’s MM8108-RD09 and MM8108-RD17 USB dongle reference designs add Wi-Fi HaLow connectivity to existing devices. The RD09 uses host-side drivers for Windows, Linux, and macOS, while the driverless RD17 presents itself as a standard USB Ethernet interface. Both designs are based on the company’s MM8108 Wi-Fi HaLow SoC, which uses a 1-GHz 256-QAM physical layer to deliver maximum PHY throughput of 43.4 Mbps over a distance of up to 1 km.

The MM8108-RD09 provides Wi-Fi HaLow connectivity for access points and client devices. OpenWrt drivers enable HaLow functionality on routers and APs with a USB interface, while native Windows and Linux drivers and a macOS application support client devices.

The MM8108-RD17 provides driverless Wi-Fi HaLow connectivity for a wide range of client devices. The USB dongle appears to the host as a standard CDC-NCM Ethernet interface, enabling use with industrial computers, robots, point-of-sale terminals, and Android or iOS devices. A pairing button enables device authentication through Wi-Fi Easy Connect, which uses the Device Provisioning Protocol (DPP).

Morse Micro provides schematics and software for the MM8108-RD09 and MM8108-RD17 reference designs to tier-1 customers through its sales team.

Morse Micro

The post Morse Micro simplifies Wi-Fi HaLow integration appeared first on EDN.

Semtech’s LR2022 and LR2012 LoRa Plus transceivers target a range of IoT deployments, from sub-GHz sensors to global multiband non-terrestrial networks (NTNs). The devices are subsets of the previously announced LR2021 and share its fourth-generation LoRa Plus IP core.

Both transceivers provide LoRa receiver sensitivity down to −141.5 dBm at SF12 with 125-kHz bandwidth and data rates up to 125 kbps for LoRa and 2 Mbps with FSK modulation. A single, switchless front-end design enables multiregion operation, while increased frequency offset tolerance improves performance across different frequency bands.

The dual-band LR2022 covers terrestrial sub-GHz, 2.4-GHz ISM, and NTN L and S bands and supports LoRaWAN, Bluetooth LE, and FSK-based legacy protocols. The sub-GHz-only LR2012 supports LoRaWAN, Wi-SUN, wireless M-Bus, and FSK-based proprietary protocols. Transmitter output power ranges from +22 dBm to −10 dBm in the sub-GHz band for both devices, while the LR2022 provides +12 dBm to −15 dBm in the 2.4-GHz band.

The LR2022 and LR2012 transceivers are now in production.

LR2022 product page

LR2012 product page

Semtech

The post Semtech expands LoRa Plus transceiver lineup appeared first on EDN.