EDN Network

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.

Some folks prefer pushbutton switches to take effect on push instead of release. These buttons do that very thing.

I suppose it’s really just a matter of taste, but I’ve always liked momentary contact switches that act when you push them better than those that wait until you let go. It’s really an arbitrary thing, so I wouldn’t presume to criticize designs that choose the latter over the former, like this one from one of my favorite Design Idea contributors.

It’s not worse. Or better, for that matter. Just different. 

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

In contrast to RJ’s design, Figure 1’s circuit implements my preferred method. It bumps DPOT U2’s setting by one count each time the UP button is pressed, and un-bumps it when DOWN is mashed.

Figure 1 This pushbutton-to-digital-potentiometer interface is optimal for impatient people.

Here’s how it works.

Pushing either button makes U1a’s pin 3 go high. Contact bounce is filtered out by R3C1’s ~5 ms time constant, and Schmidt trigger inverter U1d then delivers a single clean low-going transition to U2’s clock input. This makes U2’s wiper take one step up if its pin 2 is high (i.e., the UP button is pressed and DOWN isn’t) or one step down if  pin 2 is low (i.e., DOWN is down).

Other than that difference, there’s really no compelling reason to choose Figure 1 over RJ’s circuit. Figure 1’s parts count does include one fewer chip, but so what? They’re cheap.

But stay tuned for future developments that go-when-pushed makes possible, which might be more significant…

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

• Push to increase, decrease a digital potentiometer
• Keep Dpot pseudologarithmic gain control on a leash
• Synthesize precision Dpot resistances that aren’t in the catalog
• Op-amp wipes out DPOT wiper resistance
• PWMpot approximates a Dpot

The post DPOT push up/down appeared first on EDN.

The power factor correction (PFC) boost converter is the industry-standard topology for meeting harmonic current regulations such as IEC 61000-3-2. This circuit is essential in modern AC/DC power supplies, where it shapes the input current (IIN) to follow the input voltage (VIN) sinusoidal waveform, achieving a power factor near unity.

The key to successful PFC design lies in its operating mode. While three basic modes exist—continuous conduction mode (CCM), discontinuous conduction mode (DCM), and critical conduction mode (CrM)—the fundamental design choice is between a system built for CCM and a system optimized for CrM. A controller designed for CrM naturally operates in DCM at lighter loads, meaning CrM and DCM are often analyzed together as a single design path (CrM/DCM).

Selecting between CCM and CrM/DCM presents a fundamental trade-off that directly impacts the converter’s efficiency, physical size, cost, and EMI performance.

Figure 1 shows the typical PFC boost converter schematic.

Figure 1 A typical PFC boost converter schematic shows the industry-standard topology for modern AC/DC power supplies. Source: MPS

Below is the 4-step guide to selecting PFC conduction mode. It provides a clear methodology for navigating the tradeoffs, beginning with the primary design constraint and culminating in an informed topology selection. 

Step 1: Identify primary design constraint

Before analyzing technical specs, the primary design constraint must be defined, as this informs the rest of the decision-making process. Common design constraints include:

• Maximum power density: Make the power supply as small and compact as possible.
• Minimum cost: Reducing the BOM is usually the most critical design factor.
• Maximum efficiency: Target a specific efficiency rating, for example, 80 PLUS Titanium, where every fraction of a percentage point matters.
• EMI performance: The product is intended for a sensitive environment, for example, medical, avionics, or high-fidelity audio, where passing strict EMI regulations is a major challenge.

Once the primary design constraint is identified, the next step is to analyze core trade-offs.

Step 2: Analyze core trade-offs of selected power range

While the ideal conduction mode is heavily dependent on the application’s power range, it’s crucial to first understand the inductor current (IL) behavior in each mode, as this determines all other performance characteristics.

Figure 2 shows the fundamental difference between the IL waveforms of the PFC boost modes (CCM and CrM) across a few switching cycles around the peak of the line half-cycle, where the average inductor current (IL_AVG) is highest.

Figure 2 Note the fundamental differences between the IL waveforms of the PFC boost modes. Source: MPS

The IL behaviors in CCM and CrM are described below:

• CCM: IL always remains above 0 A and has a relatively small triangular ripple current superimposed onto a large average inductor current (IL_AVG).
• CrM: IL is a series of triangles, where each cycle begins at 0 A. The current ramps up to a peak, then ramps back down to 0 A, at which point the next cycle immediately begins.

For selecting component stress and size, the peak switching current (ISW_PK), required inductance (LPFC), and dominant power losses must be calculated. These calculations are typically evaluated at the peak of the low-line AC input voltage (for example, 85 VAC), which represents the worst-case scenario for the RMS inductor current (IL_RMS) and peak inductor current (IL_PEAK).

Peak Switching current

ISW_PK determines the required current rating of the MOSFET and diode. The baseline for comparison is the average input current at the sinusoid peak (IIN_PK_AVG).

The CCM peak switching current (ISW_PK_CCM) can be calculated with Equation (1):

Where IIN_AVG is the average input current, and KR is the ripple factor (typically between 0.2 and 0.4).

The CrM peak switching current (ISW_PK_CRM) can be calculated with Equation (2):

The peak current flowing through the switch and diode in CrM is about twice the peak current in CCM for the same input power (PIN). This directly impacts conduction loss (I2R).

Required inductance

LPFC determines the main magnetic component size. The required CCM inductance (LPFC_CCM) can be calculated with Equation (3):

Where DPK is the duty cycle at the peak input voltage (VIN_PK), and fSW is the switching frequency.

The required CrM inductance (LPFC_CRM) can be calculated with Equation (4):

The required boost inductance depends strongly on the target ripple current and fSW strategy. In many practical PFC designs, CCM uses a higher inductance to limit current ripple, while CrM can use a lower inductance at the expense of higher peak and RMS current.

Dominant power losses

Efficiency requires a trade-off between conduction loss and switching loss. Table 1 shows the dominant power losses in CCM compared to CrM/DCM.

Table 1 Here is a comparison of dominant power losses in CCM vs. CrM/DCM. Source: MPS

Based on Table 1, CCM reduces conduction loss with the disadvantage of high switching loss, meanwhile CrM eliminates the worst switching losses with the disadvantage of higher conduction loss. This understanding can be applied to different power ranges.

For low-power applications below 200 W, CrM/DCM is preferred. The high switching loss in CCM (from IRR) is the dominant factor for power loss, which is eliminated in CrM. This leads to higher overall efficiency. For high-power applications exceeding 400 W, CCM is preferred. The total current is high enough to result in massive conduction losses from the IRMS2 penalty in CrM. These IRMS2 x RDS(ON) losses far outweigh the advantages of lower switching loss, meaning CCM is more efficient overall.

Step 3: Verification using design decision map

A visual decision map can be used for verification by plotting the output power (POUT) against typical switching frequencies (see Figure 3).

Figure 3 A PFC mode design decision map (CrM/DCM vs. CCM) can be used for verification. Source: MPS

The ideal operating regions for each mode are described below:

• CrM/DCM recommended (green region in Figure 3): As established in step 2, when analyzing the core trade-offs, this region is ideal for CrM due to superior efficiency at light loads and lower cost.
• CCM recommended (red region in Figure 3): The lower conduction losses and smaller inductor size in CCM are ideal for high-power, high-density designs. Moreover, CCM offers advantages for conducted EMI and EMI filter designs due to its lower inductor current ripple and higher continuous input current.
• Transition zone (yellow region in Figure 3): The decision between selecting CrM/DCM and CCM depends on the primary design constraint identified in step 1.

Step 4: Select controller and explore alternatives

If a CrM/DCM controller is selected based on step 3, the design typically benefits from lower cost, good light-load efficiency, and reduced reverse-recovery-related switching stress.

If a CCM controller is selected based on step 3, using a fast-recovery or silicon carbide (SiC) boost diode can significantly reduce reverse-recovery-related losses and ease thermal design.

When selecting between a CrM/DCM and CCM controller, interleaved PFC architecture provides an alternative design that achieves higher performance, low switching loss, and EMI benefits. Interleaved PFC architecture can significantly reduce input current ripple and RMS current in both the input and output capacitors. This improves thermal stress and can reduce filtering requirements while preserving many of the switching loss advantages associated with transition mode.

Final design checklist

By following this 4-step guide to selecting PFC conduction mode, the correct topology can be selected according to the design specifications. A final checklist is provided below, summarizing the rules of thumb to keep in mind.

1. If the power is below 200 W, select CrM/DCM.
2. If the power exceeds 400 W, select CCM (with a SiC diode).
3. If the power is between 200 W and 400 W, select the PFC conduction mode based on the primary design constraints defined in step 1:

• Cost or EMI: CrM/DCM
• Size: CCM
• Performance: Interleaved CrM

Final design

Designing the CrM/DCM PFC stage is based on the calculation of the boost inductance and the peak stress on key switching components. Table 2 shows the design results.

Table 2 These design results are based on the calculation of boost inductance and peak stress on key switching components. Source: MPS

Take the case of the MP44018A chip employed for the PFC stage as a multi-mode controller operating in CrM and DCM via the ZCD pin (Figure 4). It’s designed to provide high-performance active PFC with a minimal number of external components. This PFC controller’s very low supply current achieves low standby power loss, with a typical no-load power consumption below 30 mW.

Figure 4 Here is how CrM/DCM PFC boost works using the MP44018A controller. Source: MPS

Light-load efficiency is improved through dead-time extension technology, which reduces the switching frequency under such conditions. Furthermore, MP44018A achieves lower total harmonic distortion (THD) compared to conventional constant-on-time (COT) control by utilizing a variable-on-time control strategy while in DCM.

Figure 5 shows the measured input current harmonic spectrum at VIN = 230 VAC and POUT = 240 W in a compliance-oriented view of boost PFC performance. The red bars correspond to the harmonic content achieved by the implemented PFC solution with MP44018A. The blue bars show the applicable IEC 61000-3-2 harmonic current limits for the target equipment class.

Figure 5 The harmonics results are compared to IEC 1000-3-2 Class C compatibility standard. Source: MPS

A strategic approach to conduction mode selection

Implementing an active PFC front-end is a critical requirement for modern AC/DC power supplies to ensure high efficiency and compliance with harmonic current regulations. This article demonstrated that selecting the proper conduction mode is foundational for PFC construction, directly impacting the converter’s efficiency, physical size, cost, and EMI performance.

A strategic approach to conduction mode selection helps optimize the final design to meet its specific application targets, whether that is maximum power density, minimum cost, or peak efficiency. For designs that follow the CrM/DCM path, a multi-mode controller can provide an effective solution for achieving strong light-load efficiency and harmonic performance with a low external component count.

A PFC front-end with a stable DC bus provides an ideal foundation for a high-efficiency secondary stage. Pairing this PFC front-end with a resonant LLC converter is a particularly effective strategy, enabling high-performance and high-density power solutions for markets ranging from consumer adapters to industrial supplies.

Rafael Collado is a supervisor at Monolithic Power Systems (MPS).

Related Content

• Design interleaving PFC boost power stages
• How to design a digital-controlled PFC, Part 1
• How to design a digital-controlled PFC, Part 2
• How to design a digital-controlled PFC, Part 3
• How to design a digital-controlled PFC, Part 4

The post A 4-step guide to selecting PFC conduction mode: CrM/DCM vs. CCM appeared first on EDN.

Apple Silicon’s success track record is indisputably impressive. It’s also rife with implementation inconsistency, albeit reflective in no small part of broader industry status impermanence.

When Apple announced its computing platform migration from Intel x86 to homegrown Arm-based SoCs beginning in mid-2020, initial industry response was initially mixed. There was no shortage of schadenfreude, mind you, both considering that Intel had done the same thing to the IBM/Motorola PowerPC Alliance a decade and a half earlier, and more broadly Intel’s then-status as the predominant processor supplier to the computing segment. That said, and as was hopefully evident even in my earliest Apple Silicon era coverage, I was personally confident in the strategy’s sooner-or-later transition success, which is ironically winding up as we speak.

For one thing, Apple’s relationship with Intel was growing increasingly strained, as the chip supplier’s power consumption vs performance trends grew more worrisome, as new-product schedules slipped, and as the bugs in those products multiplied. For another, Apple and foundry partner TSMC (superseding initial partner Samsung) had for a while already been developing new SoCs for smartphones, tablets, smart watches and other devices. And then there’s Apple’s in-house vertical integration and control of both hardware and software, the latter spanning both operating systems and first-party applications and suites, as well as its exclusivity as provider of both developer tools and App Store approvals for third-party coders.

New life

And so here we are with today’s M6, the company’s latest mainstream SoC offering. It’s notable for being the premiere volume production implementation of TSMC’s newest 2 nm fabrication technology foundation. And Apple’s done (as well as, equally notably, not done) numerous things, most of them predictable but a few more surprising, with the expanded (albeit more expensive) transistor budget it’s been foundry-afforded.

The M5, introduced last October, integrated 10 (max, “binned” to fewer than this in some product proliferations to maximize yield and minimize cost) CPU cores and the same 10 (again, max, and again, binned in some variants) GPU cores. Each GPU core also integrated a Neural Accelerator, a fancy name for what’s likely “just” (I jest) a general-purpose massively SIMD revamp of the graphics architecture for enhanced function flexibility. And then there was the standalone 16-core Neural Engine for optimal, albeit function-specific, inference processing.

And the M6? 12 (max, bin-dependent) CPU cores this time: two “super”, four “performance” and six “efficiency”. Clock speeds, no surprise, aren’t public, nor are cache sizes or other important-to-engineer characteristics. 12 (max, again) GPU cores this time, too. And two 16-core Neural Engines. The AI emphasis is obvious, yes? And what about performance? Apple claims “up to 1.2x faster multithreaded performance as compared to M5,” which is to some degree to be expected due to the greater CPU core count, although more than a straight linear interpolation would be expected to deliver. And single-threaded improvements? I thought you’d never ask…and some part of me wishes you wouldn’t have asked, because the answer is so very lame. “It delivers the world’s fastest single-threaded performance.” That’s it. Seriously, Apple?

Life extension

What about the M5 family; is it drifting off the stage as the M6-series successors take their turn in the spotlight? Not quite…and maybe not for a while yet (hold that thought).  Apple just introduced the M5 Ultra SoC, combining two M5 Max die via a silicon interposer “stitching” technology the company brands as UltraFusion. Here’s the twist…the M5 Max itself, as I wrote about in March, is a dual-die UltraFusion-stitched configuration, as is its M5 Pro enabled-core-count subset. So, what we have here is Apple’s first quad-die, UltraFusion-combined design.

This all leads back to the “implementation inconsistency” allusion in the upfront subhead of this writeup. The first-generation Apple Silicon M1 family die shots are shown at the beginning of this section. The M1, along with the M1 Pro and M1 Max, were all single-die designs, albeit (as you can see if you look closely) with the die area devoted to the M1 Max’s graphics subsystem effectively implemented as a mirror-image doubling of that in the M1 Pro. But the M1 Ultra, unveiled ~1.5 years after the M1, employed UltraFusion dual-die merge for the first time.

Apple has skipped the “Ultra” tier for both the M2 and M4 generations; this is the first time we’ve seen one since the M3 series, where the baseline, Pro and Max tiers were simultaneously unveiled, all in single-die form, and with the M3 Ultra once again arriving 1.5 years later as a dual-die stitched design. This time around we’ve got, adding together the innate resources of each of the four dice, an up-to-36-core CPU consisting of 12 super cores and 24 performance cores, and a next-generation GPU as many as 80 cores. Compared to the M3 Ultra, Apple claims that the M5 Ultra’s CPU subsystem delivers up to 1.25x higher single-threaded performance and up to 1.3x higher multithreaded performance, with the GPU cluster supplying up to 4.5x the peak GPU compute for AI. Note, again, the AI emphasis, as if it was even possible to miss!.

Price explosion

The first systems containing these new chips are, for the M6 (and already introduced, but first-time in this form factor, M5 Pro), the Mac mini.

And for the M5 Ultra (and already introduced, but first-time in this form factor, M5 Max), the Mac Studio.

The key aspect of these parts of the story is, unsurprisingly, memory—DRAM for system and unified graphics and flash memory for the SSD—and their impacts on pricing versus with prior-generation systems in less supply-constrained times. The case study example in one of John Gruber’s event coverage posts tells, I think, the tale best of all.

If you configure an M6 Mac Mini with 2 TB of storage, the SSD upgrade ($1,000) costs more than the entire base model computer ($900). So too with the 4 TB SSD upgrade for the M5 Pro Mini ($1,800 upgrade for a $1,700 computer).

I’ll also posit a question: why did Apple make this announcement now, particularly given that initial system configurations won’t start shipping until late next month, with higher-end follow-on tiers not available until (at least) October? The company is widely expected to roll out its next-generation iPhones (high-end variants, at least), smart watches, earbuds and other related (and not?) goodies in just two weeks’ time; why not just unveil everything all at once?

Mebbe Apple’s already got so much already planned for September 9 (I’m guessing) that it decided to split the total tranche into two events out of necessity? Or maybe Intel…or AMD…or Qualcomm…or Nvidia…or some other chip and/or system supplier has something already planned for the near future, and Apple caught wind of it and decided to launch earlier than originally planned (note the lack of a dedicated event today) to steal competitive thunder?

What’s next?

I saved the best for last, IMHO and if the rumors are true. Using past history as a (potential) guide to the future, when will Apple roll out the M6 Pro, Max and maybe even Ultra (though, as already noted, this only seems to happen in odd-number generations) SoCs? How about never?

For many years, although it admittedly still boggles my mind to type these words, we’ve largely in-retrospect learned that Apple apparently was seriously involved in the development of an Apple-branded, battery-powered and autonomous car. The project is now mothballed, with the former test track now owned by Waymo, although its lineage lives on somewhat in Ferrari’s Luce, designed in conjunction with former Apple chief design officer Jony Ive and shown above.

The Apple Car project apparently involved not only vehicle hardware and software development but also dedicated-silicon development, specifically for inference processing. Apple is reportedly now “baking” its inference learnings from those earlier efforts into an accelerated development timeframe for its M7-series (and beyond) SoCs. As such, to the “stutter step” reference in the title, there supposedly won’t be any M6 variants, therefore systems based on them, beyond the baseline chip introduced today (and also encompassing, I’m guessing, pending updates to the 24″ iMac and the MacBook Air).

I’ve long believed, and intend delve into further detail in a near-future dedicated-topic blog post to come, that the long-term winners in AI silicon will be:

• Volatile and nonvolatile memory suppliers, and
• Dedicated-function inference processor and core suppliers

for the same fundamental reason: inference processing largely done today in the “cloud” will inevitably move, at least in part, to the edge. And what better case study for the trend exists than an autonomous vehicle, which absolutely cannot tolerate the lengthy roundtrip processing latency from the vehicle to the cloud and back, assuming it even has reliable connectivity at all?

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

Related Content

• Apple’s question for the developer: Are you up for an AI do-over?
• Apple’s spring 2026 soirée: The rest of the story
• Apple’s M5: The SoC-and-systems cadence (sorta) continues to thrive
• The 2025 WWDC: From Intel, Apple’s Nearly Free, and the New Interfaces Are…More Shiny?
• The 2024 WWDC: AI stands for Apple Intelligence, you see…

The post Apple’s processor cadence: A pending stutter-step for improved long-term edge inference? appeared first on EDN.

Spacechips has been asked by its clients many times, “Which is the best device?” The answer? “It depends”.

Payload manufacturers are increasingly exploiting the SWaP (size, weight, and oower) advantages of single-chip, multi-channel transceivers, combining DSP and AI with RF ADCs and DACs. These devices offer significant benefits and flexibility to satellite operators, allowing them to change receive and transmit frequency plans in-orbit to deliver better services and more insights.

Using systems based on them, telecommunication operators can achieve better link performance, coverage and spectrum efficiency, while earth-observation users can transmit and receive multiple RF bands within the same orbital pass to monitor different terrains and penetration depths using a single transponder. SIGINT/ELINT operators can monitor UHF to K-band using one radio channel. The following example (Figure 1) illustrates C and Ku-band carriers being simultaneously under-sampled at 3 GSPS with respect to their absolute centre frequencies, but over and bandpass sampled in relation to their information bandwidths.

Figure 1 C and Ku-band carriers digitized at 3 GSPS are simultaneously under-sampled with respect to their absolute center frequencies and over- and bandpass-sampled in relation to their information bandwidths. Source: Spacechips

Evolving market requirements

Satellite applications are increasingly processing wider and instantaneously reconfigurable bandwidths to deliver better services and more value-add. As a designer and manufacturer of software-defined transponders, my company Spacechips considers various single-chip transceivers for different customers. These devices enable operators to change, receive and transmit frequency plans, information bandwidths, modulation and waveform types in-orbit, in response to varying communication and traffic needs.

Integrated, multi-channel semiconductors such as the AMD’s (formerly Xilinx’s) RFSoC and Versal RF, Altera’s Agilex Direct RF, Texas Instruments’ AFE80xx, Jariet Technologies’ Elektra and Analog Devices’ AD9082 offer obvious advantages such as smaller size, lower power consumption and in some cases, elimination of the external interfaces between the ADC/DAC and DSP. I remember doing the layout of the first Spacechips SDR1 prototype, where the digital interface between the ADC and the FPGA required fifty impedance- and length-matched traces, as shown in Figure 2.

Figure 2 ADC LVDS digital outputs (left) connected to a FPGA (right) exemplify legacy system design complexity. Source: Spacechips

Over the past near-two decades, transponder architectures have become increasingly software-defined, with traditional, analogue superheterodyne circuits being replaced by digital and re-configurable logic. The latest, single-chip, multi-channel transceivers offer the potential to deliver true software-defined microwave. My company’s (Spacechips) customers constantly ask questions such as the following:

• Which microchip they should use
• How they can improve ADC/DAC performance when directly processing RF carriers
• If parts will function reliably in space, and if they have heritage
• How can the customers implement in-orbit AI and machine learning, and
• How they should they design-in the parts.

There’s a big difference between:

• Evaluating these devices using development kits that accept a ±1V carrier and looking at its idealized output spectrum, and
• Developing a payload baselining the same part, combining RF and high-speed digital, and delivering the advertised SNR and SFDR from a ‑120 dBm input!

Does your test equipment have the sensitivity and RF bandwidth to prove this amplitude, for example? And there’s also a huge disparity between powering a 10 W and a 120 W semiconductor!

Spacechips provides training on, including demonstrating, the aforementioned AMD, Altera, Texas Instruments, Jariet Technologies and Analog Devices parts; in my next series of posts, I’ll share insights and lessons learned. This first tutorial will introduce devices, compare their specifications, and discuss their respective suitability for satellite applications.

Future posts will share design-in experiences and measurement results. And with that all said, discrete, space-grade, broadband ADCs and DACs up to K-band are also available, some of which offer advantages over these devices, e.g. RF bandwidth, reliability, availability, and space-qualified status. I have previously written about some of these latter options.

AMD RFSoC and Versal RF

Back in 2017, I first posted about AMD’s first-generation RFSoC product family. Gen. 3 integrates a Zynq UltraScale+ MPSoC with 14-bit, 5 GSPS, 6 GHz ADCs and 14-bit, 10 GSPS, 6 GHz DACs (Figure 3). The DFE variant operates up to 7.125 GHz. The original RFSoC was the first semiconductor device to integrate high-speed mixed-signal convertors with an FPGA and Arm Cortex processors, removing the traditional physical interfaces between these respective technologies.

Figure 3 The RFSoC family combines mixed-signal converters with FPGA fabric and Arm processors. Source: AMD

AMD’s Versal RF improves on RFSoC by offering faster and wider bandwidth mixed-signal converters, i.e. 14-bit, 8/32 GSPS, 18 GHz ADCs and 14-bit, 16 GSPS, 18 GHz DACs (Figure 4). The Versal ACAP product range contains dedicated AI engines with vector processors to accelerate machine learning, and AMD plans to formally qualify two devices from the new Versal RF product family: the VR1602 and VR1652 parts.

Figure 4 The Versal RF product family comes in multiple device options with varying ADC and DAC counts and types. Source: AMD

Altera Agilex Direct RF

Conceptually, Altera’s Agilex 9 Direct RF family is similar to RFSoC, but it offers faster and wider-RF bandwidth mixed-signal converters enabling millimeter-wave sensing payloads, i.e. 10-bit, 64 GSPS, 36 GHz ADCs and 10-bit, 64 GSPS, 36 GHz DACs (Figure 5). Higher sampling frequencies enable the digitization and synthesis of wider instantaneous information bandwidths. A lower bandwidth, higher dynamic performance, sixteen channel, 14-bit, 4 GSPS, 7.1 GHz ADC and 14-bit, 12 GSPS, 7.1 GHz DAC version is also available. The Agilex 9 Direct RF FPGA contains robust tensor-capable DSP blocks within its fabric to support SIMD execution to accelerate AI operations.

Figure 5 The Agilex 9 Direct RF FPGA integrates tensor-capable DSP blocks within its programmable fabric. Source: Altera

Texas Instruments AFE80xx

Texas Instruments’ AFE80xx is an integrated RF transceiver offering 14-bit, 4 GSPS, 7.1 GHz ADCs and 14-bit, 12 GSPS, 7.1 GHz DACs (Figure 6). The AFE80xx has eight JESD204B/C serial interfaces to connect to an ASIC or an FPGA at speeds up to 32.5 Gbps per lane. The AFE8010 variant is a ten-channel receiver-only device.

Figure 6 This AFE80xx functional block diagram shows the device’s sizeable single-chip functional integration. Source: Texas Instruments

Jariet Technologies Electra

Jariet Technologies offers the Electra-MA/MK/MX dual-channel transceivers containing two 10-bit, 40 to 64 GSPS ADCs and DACs processing instantaneous bandwidths of 6.4 GHz up to 36 GHz (Figure 7). Elektra devices have sixteen JESD204B/C interfaces to connect to an ASIC or an FPGA at speeds up to 30 Gbps per lane.

Figure 7 Elektra devices’ JESD204B/C interfaces connect to an ASIC or an FPGA at speeds up to 30 Gbps per lane. Source: Jariet Technologies

Analog Devices AD9082

Analog Devices’ AD9082 integrates two, 12-bit, 6 GSPS, 8 GHz ADCs and four 16-bit, 12 GSPS, 8 GHz DACs (Figure 8). The AD9082 has sixteen JESD204B/C interfaces to connect to an ASIC or an FPGA at speeds up to 24.75 Gbps per lane.

Figure 8 The AD9082 integrates multiple high-precision, high-performance ADCs and DACs. Source: Analog Devices

General comments

As noted earlier, Spacechips has been asked many times, “Which is the best device?” Some of our clients need to perform a lot of real-time DSP and/or AI inference on the incoming carrier traffic, so a Versal RF or an Agilex 9 Direct RF may be a better fit for their application. However, several of our other customers do not fit this same definition, and a large, complex, highly-integrated device requiring lots of power rails and watts is therefore likely not their optimum solution.

Two of our clients need more dynamic performance than that offered by ten-bit ADCs/DACs, and exploiting the processing gain from over-sampling is one way to deliver higher SNR. Many users complain about not achieving the advertised data sheet performance and we therefore teach them how to extract every last dB of performance from these parts. Just because a device has a specified sampling/reconstruction clock frequency of Fs GSPS, this does not always result in an information bandwidth close to theoretical Nyquist, i.e. Fs/2 Hz.

For some of our customers, there are financial and programmatic reasons that influence which part to baseline. One of our primary clients, for example, requires a year to approve a new supplier. This timeline did not fit with the project schedule and they resultantly developed an expensive, over-engineered system (in my opinion). For some of our clients, the physical size and/or power consumption of an integrated transceiver may be prohibitive, e.g. a 1U COTS payload might not have an adequate area or financial budget, and its small platform may not be able to generate sufficient energy to supply a power-hungry device.

Other integrated transceivers also exist, of course, but I focus here on the ones that are of most interest to Spacechips and our customers. Most of the devices are part of a wider product suite offering varying numbers of channels, resolutions and sampling speeds. Table 1 summarizes the basic specifications of the six devices and families discussed here.

	RFSoC	Versal RF	Direct RF	AFE80xx	Elektra	AD9082
Architecture	FPGA, Arm, RX/TX ADC & DAC	FPGA, Arm, RX/TX ADC & DAC	FPGA, Arm, RX/TX ADC & DAC	RX/TX, ADC & DAC	RX/TX, ADC & DAC	RX/TX, ADC & DAC
Technology Node	16 nm FinFET	7 nm FinEFT	10 nm SuperFin	16 nm FinFET	12nm CMOS	28nm CMOS
Integrated FPGA	Yes	Yes	Yes	No	No	No
ADC Resolution	14-bit	14-bit	10-bit	14-bit	10-bit	12-bit
Maximum ADC Sampling Rate	5 GSPS	32 GSPS	64 GSPS	4 GSPS	40 to 64 GSPS	6 GSPS
ADC RF Bandwidth	6 GHz	~18 GHz	36 GHz	7.1 GHz	36 GHz	8 GHz
DAC Resolution	14-bit	14-bit	10-bit	14-bit	10-bit	16-bit
Maximum DAC Sampling Rate	10 GSPS	16 GSPS	64 GSPS	12 GSPS	40 to 64 GSPS	12 GSPS
DAC RF Bandwidth	6 GHz	~18 GHz	36 GHz	7.1 GHz	36 GHz	8 GHz
Maximum Instantaneous Bandwidth	~2 to 4 GHz	~16 GHz	> 20 GHz	0.4 to 1.2 GHz	6.4 GHz	~4 to 8 GHz
AI Acceleration	Fabric	AI Engines	Tensor Fabric	No	No	No

Table 1 A comparison of device specifications covers the companies and products discussed in this blog post. Source: Spacechips

All of the parts discussed here contain integrated DDCs and DUCs to assist with carrier digitization and synthesis, respectively, as well as re-programmability. For fixed frequency plans, bandpass carriers can be directly under-sampled and aliased into the baseband zone (Figure 1). For example, for a 64 GSPS ADC, a 400 MHz-wide signal centered at 25 GHz can be digitized at 1 GSPS (bandwidth over-sampling of 2.5). For wider-band carriers, e.g. SIGINT spectrum monitoring or SATCOM gateways, you do not need to decide beforehand which signal you want; you can digitize the complete Nyquist bandwidth and, using software DDC control, gain, filter and decimate the required signals.

Some of the devices contain multiple independent DDCs to extract separate baseband streams. Decimation lowers the sample rate supplying the FPGA with data, at 1 GSPS versus 64 GSPS as in the above example, reducing memory bandwidth and easing FPGA resource utilization. For CMOS devices, a lower switching speed also reduces power consumption.

On the transmitting side, some of the DACs can directly up-convert baseband to IF/RF images in the higher Nyquist zones, as illustrated in the following example with an update rate of 10 GSPS (FIgure 9). Similarly for wider-band carriers, a DUC can significantly reduce the data bandwidth to the FPGA, interpolating, up-converting, removing unwanted images and flattening the sinc roll-off within the desired passband. Changing frequency plans requires reprogramming the NCO rather than altering the entire analog RF chain.

Figure 9 This graphic shows C and Ku-band carriers in the first and fourth Nyquist zones. Source: Spacechips

None of the parts discussed here were developed specifically for space applications, but several are currently operating in-orbit. All are fabricated using ultra-deep-submicron geometries, e.g. 16 or 7 nm FinFET, 10 nm SuperFin or 28 or 12 nm CMOS, and their thinner oxide as well as general scaling have made them intrinsically tolerant to total-dose changes over the lifetime of a mission. Several also contain process-level radiation-hardening to eliminate single-event latch-up.

Device-level mitigation, e.g. the use of EDAC within fabric memory and triplicated HDL, as well as system techniques, e.g. power-rail monitors, have collectively improved overall reliability sufficiently for certain customers, resulting in very enabling transponder designs. Some of the devices have been irradiated and several are currently being tested in-beam.

Conclusions

My next planned article will describe using, testing and designing-in the devices discussed here, all of which have unique requirements. Please note that the company and product names contained within this writeup are copyrighted and trademarked by their owners!

I’m off to the lab begin testing several the first of the parts. Until next time, the person who shares their best integrated transceiver design-in story in the comments below will win a Spacechips’ Training World Tour tee-shirt. Our global training schedule can be viewed at our website (www.spacechips.co.uk/training_courses), or email us (events@spacechipsllc.com) for more information.

Dr. Rajan Bedi is the CEO and founder of Spacechips, which designs and builds a range of advanced, AI-enabled, re-configurable, L to K-band, ultra high-throughput transponders, SDRs, Edge-based on-board processors and Mass-Memory Units for telecommunication, Earth-Observation, ISAM, SIGINT, navigation, 5G, internet and M2M/IoT satellites. The company also offers Space-Electronics Design-Consultancy, Avionics Testing, Technical-Marketing, Business-Intelligence and Training Services. (www.spacechips.co.uk).

Related Content

• Reconfigurable Ka-band satellite communication without RF frequency conversion
• Introducing RFSoC

The post Comparing multi-channel RF transceiver options for space applications appeared first on EDN.

Imagine you’re an attacker staring at a billion-transistor system-on-chip (SoC). You don’t care whether the design boots Linux, passes simulation, or meets its performance targets. Your objective is far simpler. Find the one flaw nobody thought to look for.

It might be an undocumented debug port or path. Maybe it’s a configuration error between hardware and firmware. Sometimes it’s a perfectly legitimate sequence of operations that exposes sensitive information in a way the original team never anticipated. A single overlooked weakness is all it takes.

This is why testing for unexpected data paths is crucial. Source: Arteris

Design teams focus on proving that a chip operates according to its intended specifications. Security assurance requires answering a different set of questions to identify the conditions that could violate security objectives. As the above figure illustrates, security verification must test for unexpected data paths that could expose sensitive information, not only confirm that intended paths operate correctly.

Beyond intended behavior

Security verification starts from a different premise. The concern is not whether a protected asset reaches the encryption engine, but whether information associated with that asset can reach an unauthorized destination. A debug interface may unintentionally expose sensitive information, or firmware may fail to clear a memory location after a key has been used. Otherwise, legitimate operations can also interact to create an unexpected path through the system.

Achieving that level of assurance requires security requirements that can be verified throughout the design, measured for coverage, and evaluated across complex hardware-firmware interactions. Those requirements provide the basis for determining whether security objectives continue to hold as the complete system evolves.

Functional security verification evaluates whether a design matches its specification. Engineers derive tests from defined requirements and use them to demonstrate that data, control signals, and system transactions occur as designed.

For example, testing can confirm that an encryption block obtains a key from memory, receives it within the required timing constraints, and completes the requested operation successfully. Those results establish functional correctness, but they do not by themselves address unintended information paths or residual sensitive state.

Find the weakness, not the exploit

One of the biggest misconceptions in hardware security is that engineers should focus on finding vulnerabilities, which rarely manifest as a single, obvious flaw. On the other hand, a weakness is an underlying design condition that can allow security protections to be circumvented, creating multiple opportunities for exploitation in complex designs.

That is why security verification begins by identifying weaknesses rather than individual security exposures. By addressing the underlying conditions, security teams can eliminate entire categories of exposure, reducing risk far more efficiently.

Security weaknesses often emerge through interactions among hardware blocks, firmware, and system configuration. A block-level functional test may confirm that temporary storage holding a cryptographic key is cleared when commanded. After integration, however, firmware may omit or mistime the command, leaving the key resident longer than intended. The block passes in isolation, but the integrated system violates the security objective.

Rather than creating a separate test for every possible vulnerability, a more effective approach is to define the security condition that must hold. A cryptographic key should be cleared when it’s no longer needed. It should never reach an unauthorized block or cross a security boundary except under explicitly approved conditions. Verification then determines whether that condition holds throughout the design.

Information flow at system scale

Information-flow analysis traces critical design assets across a chip as the values carrying their information pass through logical and sequential transformations or intermediate storage locations. Rather than checking only for an expected value at a specified point, the method preserves traceability over time even when the original value no longer appears intact. This visibility helps reveal leakage paths and unexpected security behavior.

Security rules used in simulation at the block and subsystem levels can be carried into emulation for full-SoC hardware, firmware, and software verification. This scalable, repeatable approach also supports third-party IP assurance across the design supply chain. A security monitor generated for a component can then be reverified at the full-chip level, providing evidence that security requirements remain satisfied through integration and configuration.

Security coverage

Security coverage answers a basic question about whether the design was tested well enough. For each security rule, the metric indicates how thoroughly the existing test suite exercised the relevant logic. A passing result carries limited weight when that activity was minimal. The analysis can locate RTL that has not been exercised sufficiently and direct additional testing to those areas.

The resulting data allows teams to track progress and make informed decisions. Coverage does not turn dynamic analysis into exhaustive proof. It shows how much evidence supports signoff and where gaps remain. As regulatory requirements and customer expectations continue to increase, teams need objective evidence of what was verified.

A different way to think about verification

The semiconductor industry has become exceptionally good at proving that designs work. So, the next step is to verify that security objectives are maintained under most relevant conditions. That requires a shift in mindset, from relying on assumptions to defining security requirements, verifying them, and measuring coverage.

Take, for instance, Cycuity, which provides the software needed to put this methodology into practice. The Cycuity Radix platform integrates with existing simulation and emulation environments, allowing teams to verify security requirements, detect security violations, and measure coverage as part of their normal verification flow. Cycuity Radix-S supports simulation-based verification, while Cycuity Radix-M extends the approach to emulation, helping teams evaluate security at full-chip scale.

Security verification is its own discipline, one that must go beyond functional testing to assess whether security objectives are maintained across the integrated system.

John Elliott is a security applications engineer at Arteris, bringing over 35 years of experience in electronic design automation (EDA). His work centers on security assurance for hardware designs, helping designers identify and mitigate security vulnerabilities in semiconductor devices before they are manufactured.

Related Content

• IoT security: Challenges and solutions
• Torture-testing your new SoC’s security quotient
• Hardware Root of Trust Essential for AI Chip Integrity
• Lockdown! Random Numbers Secure Network SoC Designs
• Hardware Security Requirements for Embedded Encryption Key Storage

The post Hardware security verification must go beyond functional testing appeared first on EDN.

Does the addition of Apple smart home protocol support necessitate hardware augmentation and upgrade, or do firmware-delivered feature updates suffice?

After pausing my TP-Link smart plug teardown publication cadence in May, I temporarily paused again in July (although the company’s products weren’t completely overlooked last month, mind you). It’s August, and I’m back on the treadmill, this time with a look at the Tapo P125, which adds Apple HomeKit support to the Tapo P105 foundation I dissected at the beginning of June.

I’d bought a Tapo P125 two-pack from Amazon’s Resale website area last November during a 30%-off holiday promo sale, for $12.59. Here’s a stock shot of the Tapo P105 four-pack acquired at the same time, for comparison’s sake.

The two products are dimensionally identical (2.4 × 1.5 × 1.3 in, 60 × 38 × 33 mm) and more broadly visually similar, save for the Tapo P105’s front panel status LED, whose illumination-related information has been relocated to the side-located switch on the Tapo P125 (non-illuminated in the Tapo P105 predecessor).

A history revisit

As a reminder, as it’s been a while since I started this particular teardown-coverage sequence, my basic aspiration with this project is to ascertain to what degree (if any) differences in the company’s various smart plug products’ feature sets, broadly between the Kasa and Tapo product lines as well as between products within a given line, are due to hardware variability versus (or in addition to) software-implemented inconsistency.

Here’s the so-far published dissection list:

• TP-Link’s Kasa HS103: A smart plug with solid network connectivity
• TP-Link’s Kasa EP10: If at first it doesn’t connect, buy, buy again
• TP-Link’s Kasa EP25: Energy monitoring for a hoped-for utility bill nose-dive
• TP-Link’s Tapo P105: A Kasa EP10 clone, or evolutionarily derived?

Note that hardware changes can, of course, be developer-motivated not only by evolving feature set requirements but also by the phaseout and replacement of building block components inside these devices. Such supply chain impermanence also helps explain the multiple to-date hardware versions of each product as documented on TP-Link’s support site.

In the Kasa past, I made a two-notable-feature teardown jump from the EP10 to the EP25: not only added energy monitoring capabilities but also support for Apple HomeKit (and Siri, for that matter). In the more recent and ongoing Tapo era, the product feature iterations are more modest. As already noted, today’s Tapo P125 augments the baseline Tapo P105 with Apple HomeKit cognizance, while the Tapo P115 (dissection to come next month) instead adds energy monitoring capabilities.

And I’ll close out, hopefully before year end, with a teardown of the Tapo P110M: slightly wider albeit no taller (or shorter) or deeper (or shallower) than the Tapo 115 and also with energy monitoring support, but additionally offering Matter smart home ecosystem cognizance.

Enough of the background; let’s get to Tapo P125 tearing down. I’ll start with the remainder of the Amazon-hosted stock images, which for some unknown reason tend to be higher-resolution and otherwise higher quality than those on TP-Link’s own company and Tapo product sites.

This last one, always a pre-dissection favorite and in this case solely published on TP-Link’s own site, is the “conceptual teardown”.

Assuming it’s correct, it suggests a relocation of the mini-PCB containing digital circuitry from the upper corner of the device (seen below with the Tapo P105) back to the more common side locale.

As well as the re-integration of the LED onto that mini-PCB versus standalone and soldered to the main board in the Tapo P105 situation.

Prepping the patient

Let’s definitively confirm-or-deny the conceptual tease. Here are some box shots to start, as usual accompanied by a 0.75′′ (19.1 mm) diameter U.S. penny for size comparison purposes.

Per the obscured-but-still-faintly-visible box-bottom marking, the devices inside are based on v1.26 hardware (the initial release, per TP-Link’s support page, along with v1.6 and v1.8 successor versions). And what’s obscuring it is the as-usual additional sticker suggestive of, per its formerly-Warehouse origins, an initial customer return followed by an Amazon resale to me.

Often, albeit not always, such products were opened by their previous owners prior to being sent back (for various reasons, including malicious ones) for refund. So too was seemingly the case here, although the top of the box was still sealed (albeit damaged). When I instead initially opened it from the bottom, the cardboard around the then-left (normally right when upright) device’s plug was comparatively sullied versus that of its packaged companion.

Turning the box back over, cutting the clear plastic seal, and opening it revealed more evidence of the right-side device’s prior-owner disturbance.

So, I went with that one for the dissection.

Cute, huh?

Scrubbed for surgery

Here’s our patient.

The bottom side perspective was as-usual the most informative from FCC ID (2AXJ4P125) and other info perspectives.

The (not-)final cut

Potentially obscure reference

Time to dive inside, starting with the previously seen backside screw.

I’ve now done a few of these similar-form-factor dissections, and they seemingly get easier (for my body, if for no other reason) each time, since the first time.

This one was no exception to the trend…and yes, I realize I’ve just jinxed myself for future project(s) by typing those words.

Here comes the series of shots I know you’re all most interested in.

That blue-colored (this time) relay on the right, a common component (for…y’know…power switching reasons…) in all smart plugs I’ve taken apart to date as well as presumably also in the future, is this time a Churod A16-V-105DA2F, which we also found inside the Tapo P105.

Now for the smarts-packed mini-PCB on the left side.

Remove the foam square, zoom in, and:

That’s (once again) Realtek’s RTL8720, also previously found inside the Tapo P105, as well as in the Kasa EP25. Which might lead you to decide that although the mini-PCB and LED have been relocated (note the switch in the lower left corner this time, with the LED just to its right), the digital hardware is exactly the same as the Tapo P105. And which in fact seems to be a reasonable deduction, it turns out, although I’d initially thought otherwise.

The nexus of my initial confusion (putting aside my ever-present confusion about most if not all things) are the ICs you can’t see (clearly, at least) in my shots, on the mini-PCB backside, which was previously bare in the Tapo P105 case. Head back over to the FCC site, click on the Internal photograph link, and you’ll be able to see them for yourself.

The larger eight-lead chip, for example, is the exact same Eon Silicon Solution EN25Q32B 32 Mbit serial flash memory (marked QH32b-104HIP) as before. And the other, smaller, five-lead (two on one side, three on the other) SOT-packaged IC, marked FE1RYE and not noted (albeit still there) before, is function-unknown to me. On the Tapo P105, it (assuming my commonality assumption is correct) was marked ACeN2. Ideas, readers?

In closing, I as usual was unable to gain access to the PCB backside, although as you might be able to discern from these shots, there’s not much there to write home about, anyway.

If you really care, the FCC site is always there to alternatively satiate your solder-blob appetites. With that, I’ll wrap up for today. Reader thoughts are as-always welcome in the comments!

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

Related Content

• TP-Link’s Tapo P105: A Kasa EP10 clone, or evolutionarily derived?
• Tapo or Kasa: Which TP-Link ecosystem best suits ya?
• TP-Link’s Kasa EP10: If at first it doesn’t connect, buy, buy again
• TP-Link’s Kasa HS103: A smart plug with solid network connectivity
• TP-Link’s Kasa EP25: Energy monitoring for a hoped-for utility bill nose-dive

The post TP-Link’s Tapo P125: A smart plug with an Apple HomeKit vibe appeared first on EDN.

Think of a data diode as the digital equivalent of a mechanical check valve—it forces network traffic to flow in one direction only. By enforcing this strict physical separation, these hardware devices offer an unhackable barrier that software firewalls simply can’t match.

Think back to your earliest days at the lab bench, probing a standard PN junction. Its elegance lies entirely in its asymmetry: a fundamental, physics-driven one-way valve that lets electrons flow freely in forward bias while slamming the door shut the moment the potential flips—a behavior perfectly captured by that classic, sweeping I-V characteristic curve.

But what if we took this exact primitive concept and scaled it up? What if, instead of confining this one-way restriction to a microscopic sliver of silicon at the component level, we applied it to entire enterprise network architectures?

By shifting our focus from shifting electrical current to directing data streams, we unlock a formidable paradigm in hardware-enforced security: the data diode.

The physics of the “one-way mirror”

To understand why a data diode is virtually unhackable, you must strip away the network jargon and drop down to layer 1 physics. At its core, the device relies on a strict optical gap. Inside the chassis, the copper network line terminates at a dedicated light-emitting source, a laser or an LED. Facing it across a literal physical air gap sits a photodiode receiver. When data arrives, electricity translates to photons, flashes across the gap, and is converted back into bits on the isolated receiving network.

Here is where physics enforces security: a photodiode cannot be manipulated into emitting photons to talk back. There are no clever firmware exploits, zero-day vulnerabilities, or routing tricks that can reverse this flow. The probability of data leaking upstream against this optical barrier is a hardware-enforced mathematical zero.

Figure 1 A hardware data diode eliminates bidirectional attack vectors by forcing data into a strict, one-way physical path from Network 1 to Network 2. Source: Author

Yet, while this absolute isolation satisfies the security engineer, it introduces a catastrophic headache for the network engineer. By completely severing the return path, you instantly break the fundamental mechanics of modern communication protocols.

The “No-ACK” paradox

Every network engineer knows that reliable communication is built entirely on a digital handshake. You send a packet, and you wait for the receiving end to say, “Got it.” But what happens when you violently amputate that return path? You enter the “No-ACK” paradox.

By stripping away the return channel, standard TCP becomes completely useless. There is no three-way handshake, no sliding window for flow control, and absolutely no Acknowledgement (ACK) packet. The transmitting side is effectively screaming into a void, completely blind to whether its data arrived intact, corrupted, or at all. To survive in this one-way environment, network protocols must shift from the comfortable, deterministic reliability of TCP to a brutal, speculative UDP-style broadcast.

To bridge this gap without data loss, engineers can’t rely on retransmission; they must rely on math. This is where Forward Error Correction (FEC) algorithms, such as Reed-Solomon coding, come into play. Instead of sending just the raw payload, the transmitting side injects precise mathematical redundancy into the data stream.

If a burst of packets gets dropped or corrupted across the optical gap, the receiver uses these error-correcting codes to algorithmically reconstruct the missing data on the fly. It’s a brilliant piece of engineering jujitsu: solving a physical limitation with pure algebraic resilience.

Here is a side note: While the optical gap in a data diode enforces one-way flow at the hardware level, in practice, integration errors, side-channel exposures, or misconfigured surrounding systems can still undermine security. Likewise, FEC boosts reliability but does not guarantee absolute integrity under all throughput and latency conditions. Just to keep some expectations low, data diodes are best understood as exceptionally robust components within a layered defense strategy, not as flawless stand-alone solutions.

System-level reality: Where theory meets the grid

In the abstract, a one-way data stream sounds like an elegant mathematical exercise. In the wild, it’s the thin line defending critical infrastructure. This is especially true in operational technology (OT) environments, where a compromised network doesn’t just mean leaked passwords; it means physical destruction.

Consider the classic security layout of a nuclear power plant or a massive regional utility grid. Engineers need real-time thermodynamic telemetry, vibration data, and RPM metrics from a massive turbine generator to monitor efficiency and predict maintenance needs. This data must be sent out to the open corporate network and cloud-analytics platforms where data scientists can dissect it. However, you cannot risk a single malicious bit traveling back down that wire to manipulate the turbine’s control systems.

By dropping a data diode directly between the critical OT network and the standard IT infrastructure, you achieve absolute isolation. The telemetry streams out continuously, but the physical layer ensures that the turbine controls remain totally invisible and inaccessible to the outside world. It creates an impenetrable digital fortress around the infrastructure that keeps the lights on.

Figure 2 Enabling unidirectional data transfer over fiber-optic cable, this data diode uses hardware separation to guarantee absolute network security. Source: Fibersystem

This brings us squarely back to the core philosophy of robust engineering design. When the stakes are this high, software firewalls—with their endless cycles of patches, configurations, and human errors—are no longer enough. True security requires moving past the ephemeral nature of code and anchoring your defense in the unyielding laws of hardware physics.

Ultimate testing ground: Avionics and high-flying isolation

While power grids demonstrate the power of hardware isolation on the ground, the aerospace industry represents perhaps the most demanding and critical application landscape for data diodes. Modern commercial aircraft are essentially flying data centers, generating massive volumes of non-critical data—fuel efficiency metrics, cabin temperature logs, and passenger infotainment streams—that must be offloaded to ground stations or corporate servers.

However, the passenger entertainment system and the flight control computer cannot share a standard, bi-directional connection; a rogue packet crossing into the flight guidance system represents an unacceptable, catastrophic safety risk. Avionics engineers solve this by implementing data diodes—often integrated into ARINC 429 or ARINC 664/AFDX network gateways.

Telemetry flows seamlessly from the cockpit down to the cabin and maintenance servers, but the physical layer ensures that a passenger trying to access the onboard Wi-Fi can never send a single bit upstream to the flight control surfaces.

Figure 3 The hardware-enforced, single-chip data diode VEGAS-429 secures the ARINC 429 serial avionics bus by physically preventing malicious back-feeding or data corruption from untrusted devices. Source: NuWaves RF Solutions

Fundamental takeaway and a challenge to the bench

Ultimately, the data diode reminds us of a fundamental truth that is often forgotten in a software-centric world: software is mutable, complex, and inherently buggy, while physics is rigid, predictable, and absolute. The industry spends billions of dollars and endless development hours in a reactive cycle of patching software vulnerabilities, updating firewalls, and chasing zero-day exploits.

Yet, the most robust network security boundary ever devised doesn’t run a single line of code. It’s forged in silicon, gallium arsenide, and glass. When the stakes are absolute, physics remains the only truly unhackable firewall.

So, for the modern engineer, maker, and hardware hobbyist, this paradigm is a call to action. It proves that the most elegant solutions to massive digital problems are often found right at the component level, sitting on the breadboard.

Figure 4 High-speed CMOS optocouplers such as ACPL072L isolate data channels to facilitate secure data-diode prototyping. Source: Author

Take this as a design challenge for your next deep-bench project. Try stripping away the bi-directional safety nets of standard networking and build a proprietary one-way data link from scratch.

Bench challenge: How would you design a high-throughput, low-latency communication protocol over a medium that physically forbids the receiver from talking back? Beyond basic Reed-Solomon codes, how would you structure timing loops, heartbeat signals, or frame interleaving to guarantee 99.999% data integrity without a single ACK packet?

Dust off the optocouplers, fire up the microcontrollers, and lay out your architectural ideas, mathematical models, or protocol hacks in the comments below. It’s time to build.

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

• Ideal Diode ideas
• Diode classifications
• Diode Characteristics
• Optocoupler Input Drive Circuits
• Guidelines for reading an optocoupler datasheet

The post Data diodes: One-way check valves of network security appeared first on EDN.

The frequency response of a Butterworth filter is not supposed to have any peaking. SPICE claims the contrary.

I came across an online datasheet for some op-amps where I found two schematics that intrigued me. Screen-shotting them together resulted in the following montage (Figure 1).

Figure 1 Two published filter circuits that caught the author’s eye.

Doing a quick Google search on the term “Butterworth Filter Response” yielded the following two paragraphs.

The Butterworth filter is a type of signal processing filter designed to have a frequency response that is as flat as possible in the passband. It is also referred to as a maximally flat magnitude filter.

As the ripple increases (bad), the roll-off becomes sharper (good). The Chebyshev response is an optimal trade-off between these two parameters. When the ripple is set to 0%, the filter is called a maximally flat or Butterworth filter (after S. Butterworth, a British engineer who described this response in 1930).

This was nothing new, but I just wanted to confirm for myself that the frequency response of a Butterworth filter is not supposed to have any peaking.

Putting these two filters into a SPICE simulation led to something unexpected (Figures 2 and 3).

Figure 2 This SPICE simulation of the low-pass filter circuit seemingly shows peaking.

Figure 3 This SPICE simulation of the high-pass filter circuit also seemingly shows peaking.

Both simulations show peaking in their frequency responses, which for a Butterworth filter is not supposed to be the case. I then modified the circuits as shown in Figures 4 and 5, with the  simulation results again also included in the graphics.

Figure 4 This SPICE simulation of the modified low-pass filter circuit is absent any peaking.

Figure 5 This SPICE simulation of the modified high-pass filter circuit is also absent any peaking.

One change to each filter, highlighted in the graphics, seemed to correct the peaking issue. Whether the modified filter coefficients are truly Butterworth might be questioned, but for all practical purposes, these two changes seem good enough.

The applicable caveat is that if you really do need a Butterworth or Chebyschev or Bessel or Elliptical or…. filter frequency response, don’t just blindly follow whatever example you might find printed, no matter who wrote it. Check your design independently of any supplier’s application note(s).

An approximation might not be good enough to serve your needs.

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

Related Content

• A digital filter system (DFS), Part 1
• A digital filter system (DFS), Part 2
• Using oscilloscope filters for better measurements
• Component tolerance sensitivities of single op-amp filter sections
• Toward better behaved Sallen-Key low pass filters

The post Dual amplifier active filters appeared first on EDN.

When applying an input signal to an operational amplifier (op amp) that is far beyond its bandwidth, you would expect that the op amp would reject or attenuate the input signal. For example, if you’re applying a 600-MHz input signal to an op amp with a 10-MHz bandwidth, you would expect the 600-MHz signal to have significant attenuation. Both SPICE and general amplifier theory will predict this expected output.

Unfortunately, the high-frequency noise will not be rejected, and will actually cause a shift in the op amp’s input offset voltage (VOS). In addition to the shift in offset, some of the high-frequency noise will simply pass through the op amp.

Some op amps are better at rejecting this high-frequency signal than others: The ability of an op amp to reject radio-frequency signals is called the electromagnetic interference rejection ratio (EMIRR). See the application report, “EMI Rejection Ratio of Operational Amplifiers” with OPA333 and OPA333-Q1 op amps as a design example.

Amplifiers with good EMIRR often have a simple internal filter on the input pins of the op amp. Amplifiers with this feature are called EMI-hardened. The input filter is a simple RC filter where the amplifier inputs have small resistors and capacitors placed both in common mode and differentially across the inputs (Figure 1). The input resistors generate noise, and the differential capacitor can degrade amplifier stability, so there are limits to how effective this filter can be.

Figure 1 Here is how EMI-hardened op-amp works using input filtering. Source: Texas Instruments

To improve the EMI rejection, many engineers choose to add an external filter capacitor across the input pins of the op amp. This can be an effective solution, but the op amp generally needs additional components to maintain stability. Stability in this context is the ability of an op amp to properly amplify a signal without oscillating.

Op amps can become unstable when connecting a capacitive load to the output pin or when capacitance connects to the inverting node. For the EMI filter, the concern is the capacitance on the inverting node because the filter capacitor is connected between the inverting and noninverting nodes.

It’s possible to use a transient small-signal step on the input or a transient load step on the output of an op amp to test stability. The amount of overshoot to the step directly relates to the circuit phase margin, which is a measurement of stability. A circuit is considered to be stable with an overshoot of less than 23%, which corresponds to a phase margin of greater than 45 degrees.

For a circuit with a filter on the input pins, test the stability with an output load step rather than an input step. An input step does not work for this circuit because the edges on the input step will be filtered by differential capacitance.

Figure 2 shows the transient response stability test for the uncompensated amplifier to a ±1 mA load step. The circuit in this example is a difference amplifier with a 1-nF filter capacitance between the inputs. For the load-step stability test, the initial output transient spike is the step size, and the following spike is the overshoot.

Figure 2 A transient output load stability test shows instability. Source: Texas Instruments

The percentage overshoot for Figure 2 is 68.2% (see Equation 1):

The Analog Engineer’s Calculator can convert the percentage overshoot to a phase margin of 13.8 degrees (Figure 3). The circuit is unstable, since a phase margin of greater than 45 degrees is required for stability.

Figure 3 Analog Engineer’s Calculator is used to convert overshoot to phase margin. Source: Texas Instruments

Understanding why the input capacitor causes instability requires some background in stability theory. Figure 4 shows the standard open-loop test circuit applied to the same circuit that underwent the transient stability test.

Figure 4 Here is a view of open-loop test circuit for op-amp stability. Source: Texas Instruments

The open loop is the most accurate way to test stability; it provides curves for open-loop gain (AOL), loop gain (AOL×β), 1/β, and phase margin (Figure 5). Stability is tested at the point where 1/β intersects AOL. The phase margin is the phase shift where AOL intersects 1/β.

Figure 5 Open-loop stability results show instability. Source: Texas Instruments

The phase margin for the open-loop circuit is 17.5 degrees, whereas the phase margin from the transient step test was 13.8 degrees. Technically the two numbers should match exactly, but there are some differences because the transient test assumes that the system is a second-order system. Nevertheless, the results are reasonably close, and both results indicate instability.

The open-loop test has an additional benefit in that it provides insight into what is causing the stability problem and how to stabilize the circuit. One way to understand the source of the stability issue is to use the rate-of-closure (ROC) rules. The ROC looks at the difference in slopes where the AOL and 1/β curve intersect.

If the difference in slopes is greater than 40 dB/decade, then the circuit is unstable. In Figure 5, the slope of AOL is –20 dB/decade, and the slope of 1/β is +20dB/decade. The difference between these two slopes is 40 dB/decade, so the circuit is unstable (Equation 2):

To correct the stability issue, you need to adjust the ROC to 20 dB/decade. The problem in this example is that 1/β has a zero at approximately 87.5 kHz, which causes the gain to increase by 20 dB/decade (Equation 3):

Adding a pole at the same frequency cancels this zero. The zero frequency is set by CIN and 2 × RG, and CF and RF set the pole frequency. To set the pole frequency the same as the zero frequency, choose CF so that RF × CF = RIN × CIN. In this example, setting CF = 100 pF will cancel the zero (Equation 4):

Setting CF = 200 pF yields the open-loop response shown in Figure 6. Note that the 1/β curve is completely flat because the pole and zero cancel each other (Equation 5 and Equation 6). Since the ROC is now 20 dB/decade and the phase margin is 81 degrees, the circuit is stable.

Figure 6 Stable open-loop response is shown with CF = 100 pF. Source: Texas Instruments

The compensated transient response, shown in Figure 7, also shows minimal overshoot and no ringing, indicating good stability.

Figure 7 Stable transient response is shown with CF = 200 pF. Source: Texas Instruments

Setting the pole and zero in 1/β equal provides good stability and also improves noise, since the noise-gain peaking is minimized. It’s possible to stabilize the circuit and increase the bandwidth using a smaller value of CF, however. Equation 7 gives the minimum value of CF that will stabilize the circuit, and Equation 8 applies the example values.

Figure 8 shows the open-loop and transient response for the minimum CF value (CF_MIN = 47pF). The phase margin is lower for the minimum value of CF compared to the case where the pole and zero cancel, but the circuit is still very stable (phase margin = 62 degrees).

Figure 8 Open-loop and transient response is shown for minimum CF compensation. Source: Texas Instruments

Figure 9 compares the bandwidth and noise for the two compensation options.

Figure 9 Here is a comparison between bandwidth and noise for two different CF compensations. Source: Texas Instruments

Stabilize the circuit

When using a capacitive filter across the input pins of an op amp, it’s important to use feedback capacitors to stabilize the circuit. The theory presented in this article is useful for understanding the root cause, but not necessary to compensate the circuit. Ultimately, you can stabilize the circuit by choosing the feedback capacitors according to Equation 3.

The feedback capacitor can also be helpful in reducing noise and stabilizing circuits with capacitive load. In general, it’s a good idea to include a placeholder for the feedback capacitors in most op-amp circuits because it can often be helpful in resolving stability and noise issues.

Art Kay is application engineer at Texas Instruments.

 

 

 

Related Content

• The perils of input capacitance
• Active filters: Design tips and tricks
• Tips and Techniques for Capacitor Testing
• Designing RC active filters with standard-component values
• Testing op amp tools for their active filter design accuracy and dynamic range

The post Op-amp input filtering can cause instability without proper compensation appeared first on EDN.

Inconsistency is a fundamental bane of troubleshooting. So it goes at work…and also at home.

At some point(s) in your engineering career, have you ever had the “pleasure” of inheriting the ongoing development and maintenance for a poorly-at-best documented project whose original leader was no longer available for advisement? Me too; I’ve dealt with handoff aftereffects for more than a dozen years so far with no definitive end in sight, albeit with increasing clarity as time passes. But in the case study described today, my project is personal, not professional.

When my then-fiancée (now-wife) and I bought the home we now live in, the previous owner had recently passed away and the original builders/owners were also no longer available for consultation (the husband is also deceased, I believe; I don’t have any contact-or-other info about his wife). So, aside from a pile of user manuals, receipts and other paperwork, I was pretty much on my own in sorting out the plumbing, mechanical, electrical, and other aspects of the residence.

An incomplete history

Judging from reputation per conversations with neighbors, not to mention the thick speaker wiring still installed in various rooms’ walls and baseboards, along with a nice set of B&W outdoor speakers, the prior owner was an enthusiastic audiophile. And judging from the sizeable living room plasma television, not to mention the projection system downstairs, also a videophile (as well as, I suspect, a “techie”).

So, it was no surprise to be told by the realtor that the home was already pre-wired for Comcast (a.k.a. Xfinity, the company’s brand for consumer products and services) broadband and television. That said, the only residence-specific detail I was aware of, and mentioned by the realtor only in passing, was that the prior owner “had another line of service installed” at some point. Hold that though.

When I moved in, I transferred my existing Comcast service from my previous Colorado residence, a process that to the best of my recollection was quick and painless. Coax cable runs on top of (plus shallowly under) the ground, as well as being attached to exterior walls at three of the four sides of the home, along with shielded, outdoor-rated Ethernet cable (all of which I’ve mentioned before).

The technician showed me which coax feed I should plug my cable modem into. And with that, for the next decade-plus and beyond relocating that strand’s interior end to my furnace room, which became the home’s networking nexus, and upgrading my service tier during the COVID-19 pandemic, ignorance was bliss.

I’ve played around a bit with MoCA in attempting to wired-extend the LAN to two guest bedrooms downstairs, versus running new Ethernet feeds or just relying on Wi-Fi. Beyond that, I kept the various wall-mounted coax connectors scattered around the house capped with terminators, since I was instead leveraging Windows Media Center over Ethernet to distribute TV service from a networked CableCard triple-tuner device and a Windows 7-based PC to various Xbox 360-based clients.

A missed-map mishap

Eventually, I expanded from a single-router setup to a multi-node mesh network, still using wired Ethernet for the backbone. All this time, the mysterious plastic box labeled “Comcast” in one corner of the property nagged at me.

As did the realtor’s cryptic “prior owner had another line of service installed” insight. But in the spirit of “if it works, don’t touch it,” I held my curiosity at bay…until last October, when necessity first forced my hand. In preparation for the nearby emergency access road construction that began shortly thereafter, the community’s water and sanitation service upgraded my neighborhood’s hydrants, so they could alternatively act as conveniently-located refill sites for water trucks. Unfortunately, in the process of replacing the hydrant across the street from me, they inadvertently also cut the thick coax feed(s) that Comcast-serviced my residence as well as that of my next-door neighbor.

After alerting Comcast to the fact that I was having a problem that was theirs, not mine, to solve (I can’t count the number of times I’ve heard the words “when’s the last time you replaced your cable modem” in the last near-year), they sent out a diagnostics tech, who confirmed the cut.

The community’s water and sanitation service washed their hands of the issue, since it turns out Comcast had seemingly neglected to add the wiring to publicly accessible maps post-initial installation. And it took another couple of days to get a different Comcast technician out to spend nearly a day digging up the wiring, re-splicing it back together, and re-burying it.

Broadband and television service came back up immediately…but only for about 24 hours; then they went down again, this time only for a couple of hours (that day, at least). I’d never experienced Comcast flakiness before, so it wasn’t much of stretch to associate not only a correlation but a more definitive causation between what I was now experiencing and the day-prior repair attempt.

I’d already realized that a simple cable splice, versus a comprehensive full-run replacement, would result in at least a modicum of SNR loss. I deduced the incremental signal degradation had “pushed” our apparently already-marginal service “over a cliff”, at least periodically.

What symptoms did I notice whenever I was having Comcast service issues, aside from the fact that LAN devices would lose Internet connectivity and sometimes the router itself would also go down (since the Google Nest system is cloud-managed)? The second LED from the top of my Netgear CM1100 cable modem, referencing downstream connectivity, would perpetually blink, with those below it non-illuminated.

And speaking of the cable modem, sometimes even when I was online, the third LED down, referencing upstream connectivity, would still blink (versus its usual steady-illuminated state). That all said, unless broadband connectivity went down for an extended period, and sometimes even if it did, television service often still remained “up”.

Convincing Comcast of the validity of my ongoing issues—not to mention the company’s ongoing responsibility for solving them—was a different matter. The first tech that came out had given me his business card with an invitation to reach out if I continued having issues. Every time I texted him—I did strive to practice at least some restraint—he’d remote-check my modem and CableCard status and report back no issues logged on his end, including no T2, T3 or T4 timeouts.

There was also seasonal variability to the unreliability (assumed associations: ambient temperature and moisture). As autumn turned to winter, the outages thankfully became less frequent, at least for a while (again, hold that thought). So, I eventually gave up trying to get someone back out on Comcast’s dime and switched over to cellular hotspots whenever broadband started flaking out.

Learnings and lingering mysteries from this portion of the story:

• The Comcast “tap” that services me and my next-door neighbor, it turns out, is at the very end of the line that runs through our neighborhood. Service-drop alerts sent to Comcast when customers’ cable modems, set-top boxes, and the like go offline only automatically result in a “truck roll” when a critical mass of customers are simultaneously affected. I don’t remember the exact number, but I think the tech said a half-dozen or thereabouts. Otherwise, Comcast logs the situation as a potential issue (similar to what happens if a customer reports an outage over the phone or in-app) but by default assumes a power outage or other unrelated-to-Comcast problem is the root cause of the service glitch. This is why I had to work so hard on my end to get the repair going in the first place.

• You might have noticed in the earlier photos I took last fall that there are two thick coax feeds that had gotten severed. Particularly given that ours was the last line “tap”, I was baffled as to why there wasn’t just one cut cable. Descriptions sometimes refer to such lines as “loops” or “rings”, which initially explanation-contented me. But I more recently came up with what I think is a more likely answer. Again, hold that thought.

Another year, another cut cable

Fast-forward to June of this year. We were still getting occasional outages, but only a couple of times a month, most of them lasting only a few minutes each, and typically happening in the mid- to late-afternoons (again, with an assumed ambient temperature association). But one day, broadband was up-and-down (lather, rinse and repeat) for several hours straight. I decided to take a break from work and go for a hike around the neighborhood, wherein I came across a bunch of Comcast trucks.

Apparently, an Xcel Energy boring machine digging a pathway under the road in preparation for running electrical cabling had once again sliced through a Comcast feed, this one servicing an entire street’s worth of customers next to ours. And although we didn’t solidly lose service where I lived, the technician I spoke with indicated that as part of the repair, they were re-tuning all the area’s line RF amplifiers, thereby explaining why our service was also up-and-down for so long that afternoon. Here’s what a few of the neighborhood RF amps look like:

Including this one near the cut location, which for some reason, ended up with its top still off (or is this a broader area-servicing fiber coax transceiver node, readers? Let me know in the comments!

And then there’s this unidentified (again, readers?) hunk of equipment right next to it, also surrounded by Comcast “flags”, in this case with its cover still intact albeit ajar.

Unfortunately, this re-tuning apparently further suppressed the ongoing SNR at my residence, because beginning the very next day I started experiencing more frequent outages again, this time roughly every other day. I eventually rang up Comcast again and scheduled a technician call for the next day. That evening, when service came back, Comcast called me back and tried its best to convince me to cancel my appointment, but I strongly declined the offer.

I’ll continue the story in part 2 of this series, scheduled for publication next week. Until then, I as-always welcome your thoughts in the comments!

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

Related Content

• Dear Comcast, we haven’t yet tangled our last
• Keeping technology user-friendly and simple: the latest failure example
• Will a location change improve my MoCA?
• The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
• A quest for faster upstream bandwidth
• Debugging a “buggy” networked CableCARD receiver

The post Debugging intermittent Comcast, part 1: Scenario-setting appeared first on EDN.

Quectel’s 4G SH602FA and 5G SE505FE smart modules feature built-in Android 16 to accelerate industrial and commercial IoT development. The modules enable developers to build connected products such as handheld terminals and inspection devices with rich user interfaces and enhanced multimedia performance.

The 4G SH602FA is powered by a MediaTek MT8786 chipset with a 64-bit octa-core processor comprising two Arm Cortex-A75 cores and six Cortex-A55 cores. An Arm Mali-G52 MC2 GPU supports graphics-intensive embedded applications without requiring an external host processor. The smart module integrates LTE Cat 4, Wi-Fi 802.11ac, Bluetooth 5.1, and GNSS, along with camera and touch-panel interfaces. 

Offering Android 16-powered 5G connectivity, the SE505FE leverages a MediaTek MT8863T chipset with a 64-bit octa-core processor comprising two Arm Cortex-A76 cores and six Cortex-A55 cores, along with an Arm Mali-G57 GPU. The module supports 5G sub-6-GHz and LTE Cat 4, together with Wi-Fi 6, Bluetooth 5.2, and GNSS.

A timeline for module availability was not provided at the time of this announcement.

SH602FA product page 

SE505FE product page 

Quectel Wireless Solutions 

The post Smart modules bring Android 16 to IoT designs appeared first on EDN.

A Class-D mono audio amplifier, the PAM2011Q from Diodes delivers up to 3 W of output power for automotive applications. Designed for instrument clusters, dashboard and backup cameras, driver notification chimes and warnings, and emergency call (eCall/T-box) systems, the filter-free amplifier provides 1.8-mA quiescent current and up to 94% efficiency.

The PAM2011Q comes in a compact, thermally enhanced package and requires minimal external components, simplifying design and reducing system cost. It operates from a 2.8-V to 6.0-V supply and delivers 2.53 W at 1% THD and 3.15 W at 10% THD from a 5-V supply into a 4-Ω load. Audio specifications include THD+N below 0.03% and 21-µV integrated output noise (A-weighted) at 6-dB gain.

The amplifier is AEC-Q100 qualified and operates over a junction temperature range of -40°C to +125°C. Integrated de-pop circuitry provides silent startup and shutdown while eliminating unwanted noise. Overvoltage and overtemperature protection with auto-recovery are also integrated to enhance system reliability.

The PAM2011Q is available now from Mouser Electronics.

PAM2011Q product page

Diodes Inc.

The post Class-D amplifier enhances automotive audio performance appeared first on EDN.

The Vertex 6.0 channel emulation platform from VIAVI supports carrier frequencies up to 23.6 GHz and 400 MHz of instantaneous bandwidth. The company says it is the industry’s first channel emulator for 6G and Wi-Fi 7/8 testing, meeting newly defined 6G waveform requirements and exceeding Wi-Fi 7/8 bandwidth requirements. The enhanced platform features field-replaceable RF modules that can be installed in an existing 6U Vertex chassis.

Building on the 5G FR1/FR2 capabilities of the previous generation, Vertex 6.0 recreates real-world wireless conditions in the lab for complex cellular, Wi-Fi, military, and aerospace RF applications. Combined with the VIAVI FR3 MIMO converter and raytracing, the platform serves as a digital twin for RF propagation, enabling use cases such as FR3, Wi-Fi 7, AI-RAN, and ISAC.

Each chassis accommodates 36 RF ports, 256 digital links, and up to 1.6 GHz of bandwidth. For cellular technologies, the platform handles FR3 bands with up to 1 GHz of bandwidth. For Wi-Fi 7/8, it offers native support for 320 MHz and 4096 QAM in 2×2 to 8×8 configurations. The channel emulator supports land-to-land, land-to-air, and air-to-air transmissions, including anechoic and reverberation OTA chambers, NTN (LEO, MEO, and GEO), mesh, drone, and ISAC networks.

Vertex 6.0 product page

VIAVI Solutions  

The post Channel emulator adds 6G, Wi-Fi 7/8 testing appeared first on EDN.

Kinetic Technologies’ KTS1642Q AEC-Q100-qualified load switch protects automotive loads from abnormal power-supply or load conditions. When used with the appropriate external TVS diodes, the device supports ISO 7637-2 transient requirements while helping designers address the electrical stress conditions of ISO 16750-2.

Operating from 4 V to 40 V, the KTS1642Q integrates two N-channel MOSFETs with 41-mΩ on-resistance and delivers 6 A of continuous output current. It provides reverse-battery protection to -28 V, fixed 20.3-V overvoltage protection with a typical 360-ns response time, overtemperature protection with auto-retry, battery detection, and a fault flag output. Input ESD protection meets IEC 61000-4-2 Level 4, with ±2-kV HBM ESD protection on other pins per AEC-Q100-002.

The load switch operates over a temperature range of -40°C to +125°C and is supplied in a 4×4-mm TDFN. The KTS1642AQGDV-TR features an active-high enable, while the KTS1642QGDV-TR features an active-low enable. Both versions are available now.

KTS1642Q product page 

Kinetic Technologies 

The post Load switch guards automotive power rails appeared first on EDN.