Українською
  In English
Збирач потоків
Keysight Addresses Cross-Domain Physics Issues That Leave Electronic Designs Vulnerable to Late-Stage Failure
Keysight Technologies (NYSE: KEYS) today announced Keysight Multiphysics, a design and verification solution that addresses the physics interactions driving failure in modern electronic designs. The structural analysis application covering drop, shock, and vibration enables engineering teams to identify and fix problems earlier, before a prototype is built.
Electronic products are growing in complexity faster than traditional engineering workflows can scale. As electrical, thermal, mechanical, and optical elements are compressed into tighter, more integrated designs, the physics interactions between them create failure risks that cannot be evaluated in isolation. Physics effects in one domain can produce unintended outcomes in another, and those interdependencies are rarely caught until the physical product is built, when the cost of redesign is highest and projects often miss deadlines and exceed budgets.
Keysight Multiphysics integrates physics simulation into the electronic engineering workflow, completing in hours a process that traditionally takes weeks. The first release addresses structural analysis and includes compliance simulation for drop, shock, and vibration. Previously, this step required building numerous physical prototypes for testing in an external lab, committing design and manufacturing tooling before identifying potential failures. Pre-built application templates embed setup expertise directly into the workflow, improving simulation fidelity.This allows teams to avoid late-stage failures without requiring a computer-aided
Key application benefits:
- Faster time to insight: Simulation-driven development helps teams reduce physical prototype iterations and identify reliability issues earlier in the design cycle.
- Lower redesign cost: Drop, shock, and vibration simulation enables engineers to locate where failures originate and make targeted corrections earlier in development.
- Increased design confidence: An application-specific database, expanded to include modern electronic materials, helps engineers model component behavior under realistic operating conditions.
- Broader access to simulation: A guided workflow interface embeds application expertise for each use case directly into the process, enabling engineers to confidently evaluate product reliability without specialist CAE skills.
- More time for engineering: Automated setup workflows eliminate manual configuration tasks traditionally required for structural simulation.
- Accelerated regulatory sign-off: Built-in compliance workflows support MIL-STD, IEC, and JEDEC standards for shock, drop, and vibration.
Niels Faché, Senior Vice President, Keysight Design Engineering Software, said: “Complexity now defines electronic design. Engineers used to treat electrical, thermal, and mechanical effects as separate problems. That approach can no longer keep pace. We built Keysight Multiphysics by working through the very problems our own engineers faced, giving teams a digital thread to detect failures earlier and more predictably.”
The post Keysight Addresses Cross-Domain Physics Issues That Leave Electronic Designs Vulnerable to Late-Stage Failure appeared first on ELE Times.
Guitar Frets

Have you heard of the golden ratio? Well, what about the gold-colored guitar fret ratio?
I’ve been listening lately to classical guitar musicians on YouTube. Such skill and artistry is utterly astonishing. After a while, though, I got curious about how the guitars were made and how they achieved their frequency outputs. I noticed something. I took a screen shot of a guitar’s strings and fretboard and, by counting pixels, I measured the dimensions seen in Figure 1:

Figure 1 Guitar fret positioning is definitely not random, acoustically speaking.
I then looked at the ratios of a string’s fret-to-base length (my choice of term) to that of the next shorter one (Figure 2):

Figure 2 Length ratios: the ratio of each fret position taken in pixels divided by that of the next fret closer to the base is the ratio of the frequencies of each note of the string. That ratio is nominally 2^(1/12) =1.05946… which is approximated in each and every case. The average of the calculations as shown here comes to 1.058422 which is only 0.1% in nominal error.
I discovered that in spite of my crudeness in using the pixels, the ratios come out very close to the twelfth root of two. That ratio is the ratio of adjacent note frequencies of a tempered musical scale. If the full length of a string is taken as “Do” in its particular key, the fret positions yield the twelve-tone-scale arrangement of notes seen in Figure 3. In hindsight, I guess I should have intuitively known this but I didn’t. I do now.

Figure 3 Tempered scale: taking the full length of each string as the note “Do” as in Do-Re-Mi-Fa-Sol-La-Ti-Do scaling, we see how each fret position corresponds to one of the twelve notes (including sharps and flats) of the Western culture’s twelve-tone scale.
It should be noted that singer Jimmie Rodgers once admitted that he couldn’t really play the guitar as he performed, so he tuned the six strings of his guitar to be in open string harmony. Then when he was performing, he would keep one finger, his thumb, across all six strings at the same time across the fretboard. Since all six strings followed the above length versus note pattern, the six strings were always in harmony. He was using a single, movable chord.
Watch how his left hand does that in the following YouTube videos and enjoy the music.
John Dunn is an electronics consultant and a graduate of The Polytechnic Institute of Brooklyn (BSEE) and of New York University (MSEE).
Related Content
- Earplugs ready? Let’s make some noise!
- A pitch-linear VCO, part 1: Getting it going
- A pitch-linear VCO, part 2: taking it further
The post Guitar Frets appeared first on EDN.
India Develops Indigenous Expendable Turbojet Engine for Future Missile System
In a breakthrough that will power the nation’s aspirations in aerospace propulsion, the first Indian expendable turbojet engine in the 350-kg thrust class was successfully demonstrated and marks an important step towards India’s capabilities in developing advanced propulsion technology. Developed by the Gas Turbine Research Establishment (GTRE) of the Defence Research and Development Organisation (DRDO), the engine will pave the way for increased self-reliance on high-end propulsion technology for upcoming aerial platforms and other defence applications.
Hyderabad-based Azad Engineering that was chosen by GTRE as the industry partner for its manufacturing and assembly, delivered the engine to GTRE on July 22, 2026. This also marks the coming together of the Indian defence research infrastructure and the private sector for building the aircraft. While DRDO lends its in-house design expertise and research in this field, Azad Engineering provides the cutting edge in precision manufacturing, modern engineering, and tooling facilities to make this possible.
The newly developed 350-kgf-thrust-class expendable turbojet engine is expected to power future air-breathing platforms, including selected missile systems and unmanned aerial vehicles (UAVs) that require compact, lightweight, and high-performance propulsion systems. As a turbojet is an air-breathing engine, it uses atmospheric air as part of the combustion process to generate thrust. The development represents an important advancement in India’s indigenous aerospace and propulsion capabilities, as the design and manufacture of jet engines require advanced materials, precision engineering, highly accurate manufacturing processes, and stringent quality-control measures. The technology could strengthen India’s domestic propulsion ecosystem and support the development of future high-speed aerial platforms.
The successful development highlights the growing contribution of India’s private defence industry to major propulsion programmes. Through its role in the indigenous manufacturing and assembly of the engine, Azad Engineering demonstrates how precision-engineering companies are increasingly participating in the development of complex aerospace and defence systems. The 350-kgf-thrust-class expendable turbojet engine was manufactured and assembled in India by Azad Engineering based on the design and technology developed by the Gas Turbine Research Establishment (GTRE), a laboratory of the Defence Research and Development Organisation (DRDO). This collaboration reflects the increasing role of private-sector companies in supporting India’s efforts to develop advanced indigenous propulsion technologies.
The post India Develops Indigenous Expendable Turbojet Engine for Future Missile System appeared first on ELE Times.
Navitas and Magnachip partner to accelerate high-voltage and ultra-high-voltage silicon carbide adoption
Test, debug, and validation of CXL memory expanders

Part 2 of this series covered the user-space tooling stack—cxl, ndctl, daxctl, numactl, lspci, and setpci—and walked the boot path from power-on through DRAM training, DVSEC and HDM reporting, decode programming, CDAT delivery, ACPI table handoff, and OS driver binding. It framed each stage as a validation gate so you can tell whether a failure is rooted in link training, capacity reporting, firmware tables, or policy—not only in application behavior.
Part 3 turns that framework into hands-on practice. You will learn how CXL memory may surface as system RAM or Device DAX, when to use daxctl and boot parameters such as efi=nosoftreserve, how to confirm expander memory as a distinct NUMA node, how to decode key lspci fields for link health and CXL.mem enablement, and how to drive targeted traffic with numactl and standard stress tools. So, you can separate transport defects from NUMA misconfiguration before closing bring-up or sign-off on CXL Type 3 device validation.
Integration modes: System RAM and Device DAX
CXL Type 3 host-managed memory may integrate in more than one way. The platform and kernel can expose it as conventional system RAM, or as persistent-memory-class capacity that surfaces as Device DAX character devices (for example /dev/dax0.0). The daxctl utility and libdaxctl can reconfigure those DAX instances; for example, switching a region to system-RAM mode so the same physical capacity behaves like normal DRAM instead of a raw DAX mapping, subject to firmware and driver support.
To reconfigure a device that appears as /dev/daxX.Y to system RAM:
sudo daxctl reconfigure-device –mode=system-ram daxX.Y
Firmware can mark some memory ranges in the system map as EFI “soft reserved.” Think of that map as the machine’s inventory of RAM, soft-reserved means, “this range exists, but do not treat it as ordinary free RAM yet.”
That pattern is common when capacity comes from persistent memory (PMEM) or CXL Type 3 expanders, because the platform often wants the OS to decide later whether that capacity should behave like normal DRAM or be exposed as a Device DAX mapping (a special character device such as/dev/dax0.0). By default, Linux honors those soft reservations, which leaves the memory set aside instead of freely handing it to applications as regular RAM.
The boot parameter efi=nosoftreserve changes that policy. It tells the kernel: do not keep soft-reserved areas reserved so the OS can bring that capacity online in the mode operators want (typically system RAM) when the firmware’s soft-reserve marking does not match the deployment goal.
Use efi=nosoftreserve only when your platform vendor or bring-up guidance says it’s appropriate. Applied without that context, it can change how capacity appears (RAM vs DAX), affect NUMA topology, and complicate debugging when firmware and OS expectations disagree.
Verifying NUMA topology
Use numactl to confirm the expander enumerates as its own NUMA node:
numactl -H

Figure 1 Sample numactl -H output on a two-socket system with 2 CXL devices, where each CPU is a NUMA node with native DRAM. Node 0 and node 1 show socket-local DRAM and the CXL devices appear as node 2 and node 3 with 128 GB of memory (each) and no local CPUs. This memory-only NUMA node pattern is common for Type 3 expanders and is the baseline for placement-aware testing. Source: Author
Initial sanity checks with lspci
lspci shows whether the CXL endpoint is present and reports vendor/device ID, class codes, PCIe link width and speed, and related DVSEC register status. It’s a fast first check before chasing firmware decode, driver bind, or memory-onlining issues.
lspci | grep -i cxl
lspci -s <BDF> -vvvv
Decoding key lspci fields
Device link width and speed
LnkCap and LnkSta should match expectations (for example speed 32GT/s, width x16). Unexpected degradation signals an unstable link and issues at the electrical layer. This must be resolved before proceeding further.

Figure 2 lspci output showing the negotiated PCIe link speed and width for a CXL Type 3 endpoint. Source: Author
CXL capabilities and status
CXL DVSEC blocks use Vendor ID 0x1E98 and a DVSEC ID identifying the structure type. A healthy device advertises both CXL.io and CXL.mem under CXLCap/CXLCtl. If CXL.mem is disabled (CXLCtl Mem-), possible causes include DRAM enumeration failure or the host failing to assign address space. HDMCount 0 is a red flag. When memory enumeration fails, verify DIMM compatibility and mounting, and use vendor SDKs to probe internal controller registers via out-of-band access where available.

Figure 3 CXL DVSEC capability and control fields showing CXL.io and CXL.mem enablement, HDM decoder configuration, and active memory ranges. Source: Author
Address range and Active bit
Device firmware can be set up to include the entire HDM in one range or split it into two. The range fields reflect the size and which range is active. Range fields should translate to the full HDM size with Valid+ and Active+ set. Otherwise, it indicates that DDR negotiation or mapping failed. For initial bring-up, set the decoder and mailbox timeout values to their maximum supported settings to avoid premature failures during DDR negotiation.
Driver and kernel modules
Kernel driver in use should be cxl_pci. To verify kernel version, kernel 6.3 and above are recommended. During link stability testing, unlink drivers as required by your test procedure.
The cxl CLI tool for CXL memory expander bring-up
The cxl command-line utility is the user-space front-end to libcxl, shipped with the ndctl project on most Linux distributions. It walks the kernel CXL sysfs hierarchy, which includes buses, ports, endpoints, memdevs, decoders, and regions and prints structured as JSON output.
It complements lspci, which shows transport and DVSEC state at the PCI layer, and daxctl or numactl, which show how onlined memory capacity is exposed to applications. Reach for cxl after dmesg if the firmware, CXL driver, and user-visible memory policy do not agree.
What cxl exposes
At a high level, cxl list reports the objects the Linux CXL core registers under /sys/bus/cxl/devices/; root buses, switch and root ports, endpoints tied to PCI functions, memory devices (mem0, mem1, …), host-managed device memory decoders, and regions that may span one or more expanders. For single-LD Type 3 cards, the first sanity check is usually whether a memdev appears with a non-zero ram_size, a host BDF, and decoders or regions in a committed decode_state after platform firmware has programmed HDM and asserted mem_enable.
Essential commands during bring-up and sanity testing
Initial discovery
Run these early in bring-up to confirm the kernel bound cxl_pci and registered at least one memdev:
cxl list -M
cxl list -M -u
Look for memdev entries with ram_size, serial, host (PCI BDF), and numa_node when memory is onlined. An empty list or zero-sized memdev often means the device is present on the bus but not yet consumable—trace back to HDM validity, decode programming, or driver bind before chasing application issues.
Topology and decoder verification
After link-up and driver bind, verify the decode path from root port through endpoint decoders:
cxl list -vvu
cxl list -D -d endpoint -u
cxl list -P -p switch,endpoint -m memX -u
Use -vvu for buses, ports, decoders, regions, and target mapping in one view. Filter by memX or by PCI BDF (cxl list -M -m 0000:bb:dd.f) when multiple expanders or a switch is present. Decoder listings should show plausible Host Physical Address (HPA) windows and a committed state before you treat CXL-attached DRAM as usable system memory.
Region and exposure mode checks
When the platform surfaces expander memory through a CXL region and DAX subsystem, confirm how capacity is configured before running daxctl or numactl tests:
cxl list -R -RXu
cxl list -r regionN -RXu
The daxregion section reports chardev names (for example dax0.0), mode (devdax versus system-ram), and memblock onlining progress. This tells you whether the next step is daxctl reconfigure-device, memory hotplug onlining, or NUMA verification with numactl -H.
Enable, disable, and health
Type 3 expanders usually auto-enable by default. These commands matter after manual disable, hot-reset recovery, or scripted regression gates:
cxl enable-memdev mem0
cxl disable-memdev mem0
cxl list -m mem0 -H -u
enable-memdev revalidates HDM decoders and CXL.mem enablement along the port hierarchy. The -H health listing exposes maintenance, media, and error counters when the device supports mailbox health reporting—useful during long stress runs alongside dmesg and RAS logs.
Suggested bring-up command sequence
A practical first-pass sanity script on a booting system:
lspci | grep -i cxl
lspci -s <BDF> -vvvv
cxl list -M -u
cxl list -vvu
cxl list -R -RXu
cxl list -m mem0 -H -u
numactl -H
Together, these commands separate device not seen (lspci) with details of DVSEC that can be parsed for information of interest, device seen but not registered (no memdev in cxl list), decode not committed (decoders/regions), and memory online but misconfigured (numactl shows wrong node or missing capacity). That layering matches the validation mindset used throughout the “Bring-up and testing of systems with CXL Type 3 memory expanders” series.
Keeping kernel pages off CXL memory
CXL expander memory should be treated as a migratable capacity tier, not as interchangeable DRAM. Slab caches, page tables, and other non-migratable kernel structures must stay on local socket memory because they cannot be demoted or migrated and would suffer higher latency and reliability risk on CXL.
Online CXL capacity in ZONE_MOVABLE
The primary remedy is to defer CXL expander capacity only into ZONE_MOVABLE on a discrete, CPU-less NUMA node. After confirming the device with cxl list and daxctl list, reconfigure it as system RAM with the default movable policy as we saw previously.
sudo daxctl reconfigure-device –mode=system-ram daxX.Y
daxctl onlines new blocks as movable by default; avoid –no-movable. Only move blocks assigned to CXL memory to ZONE_MOVABLE. This must be done carefully; determine the NUMA node assigned to a CXL device, use the sysfs interface, /sys/devices/system/node/node2/memory*, to determine which blocks are assigned to the CXL memory and only apply the ZONE_MOVABLE attribute to those blocks by looping over the respective CXL nodes. It’s important to note that CXL memory range onlined in ZONE_MOVABLE is not eligible for 1-GB Gigantic Page allocation.
Page temperature and tiered memory placement on CXL systems
Hot, warm, and cold pages
In CXL-enabled tiered memory systems, pages are commonly classified by access frequency over a sliding time window rather than by a fixed label. Hot pages are touched often enough to affect performance while cold pages are allocated but remain idle for minutes or longer.
Production studies report that a large share of allocated memory, often well over half, can be cold in short windows. Warm pages sit between those extremes: accessed occasionally or likely to be re-accessed soon, so they tolerate slower tiers better than hot data, but still benefit from promotion if they heat up.
TPP further notes that page type matters. Anonymous heap and stack pages tend to run hotter than file-backed cache and tmpfs, and temperature can flip quickly as pages are allocated and freed, so static placement fails.
Why page placement is critical
CXL expander memory is reachable with byte-addressable semantics but at higher latency and often lower effective bandwidth than socket-local DRAM. If the OS treats all NUMA nodes as equivalent, hot working sets can land on CXL, new allocations compete with cold data for fast DRAM, and capacity-bound workloads that should tolerate tiering still lose double-digit performance.
TPP reports up to roughly 18% performance improvement over default NUMA balancing on CXL-tiered platforms, and production analyses show sharp latency-sensitivity once the hot footprint exceeds what local DRAM can hold.
For CXL Type 3 bring-up, correctness may pass with memory online, but performance sign-off requires verifying not only that CXL capacity exists, but that hot, warm, and cold pages are landing on the intended tiers under the policies that the user fleet actually runs.
Default Linux policies
Default policies start simple: allocate preferentially from local DRAM and spill to the CXL NUMA node only when fast-tier capacity is exhausted. The kernel’s NUMA balancing (numa_balancing) enables and configures automatic, page-fault–based balancing. Setting it to NUMA_BALANCING_MEMORY_TIERING (value 2) tells the kernel to treat the NUMA nodes as tiers and promote frequently accessed (“hot”) pages into the fast tier.
echo 2 > /proc/sys/kernel/numa_balancing
Memory-tier demotion (numa_demotion_enabled) under reclaim pressure moves cold pages to the slow tier instead of swapping them to disk.
echo 1 > /sys/kernel/mm/numa/demotion_enabled
Zone reclaim mode is a Linux kernel parameter that controls how aggressively the system reclaims memory from a local NUMA node when that specific node runs out of memory, rather than allocating memory from other remote nodes. It accepts one of the specified policies or a combination. Typical production knob will enable all reclaim policies.
echo 7 > /proc/sys/vm/zone_reclaim_mode
The above setting should not be used in all conditions. It’s highly recommended that the user try combinations of the above settings with benchmarks that closely resemble the workloads and use the combination that works best.
Tools for traffic generation and performance validation
While a detailed discussion of each benchmark and the traffic type deserve a separate discussion, some common benchmarks and tools are mentioned below that should help the reader get started.
Memory structural test
Latency
Intel Memory Latency Checker (MLC) for x86 platforms
Bandwidth
Google Stressful Application Test (SAT/GSAT/stressapptest)
Google Multichase – pointer chasing benchmark
When expander memory appears as its own NUMA node, numactl+membind forces traffic onto CXL-attached DRAM.
numactl –cpubind=0-15 –membind=2 <command to run memory traffic>
The example below runs on node 0 CPUs but allocates memory on node 2. CXL memory (see Part 1, Figure 2); swapping –membind between 0 and 2 gives a direct local-DRAM versus CXL comparison. On single-socket systems, the CXL device may enumerate as NUMA node 1.
Matching CXL link width to memory bandwidth
When sizing a CXL memory expander, usable bandwidth is not simply the PCIe/CXL rate on the connector. Traffic crosses two stages: the host-facing PCIe/CXL link and the DDR channels behind the Type 3 controller. End-to-end bandwidth is therefore the lesser of the two.
Effective Bandwidth = min(PCIe/CXL link bandwidth, DDR bandwidth behind CXL)
Recycled DDR4 is often slower, or with fewer active channels than native DDR5. Subsequently, the DRAM side can limit throughput before a full-width link saturates. In that case, a x16 link may not add much, and an x8 (or narrower) link can already match what DDR4 sustains. This frees up lanes, cutting expander cost and power, and leaving host I/O for GPUs, NICs, and other devices. Size the link to the slower of the two bandwidths, not to the maximum PCIe generation width.
A cross-layer validation mindset
CXL Type 3 memory expanders offer a practical way to grow capacity and effective memory bandwidth for data- and memory-intensive workloads where traditional DDR scaling is constrained by I/O, cost, and signal integrity. But successful deployment is not only a silicon or link problem.
Host-visible expander memory remains physically and administratively distinct from socket-local DRAM, so discovery, NUMA topology, performance, and RAS must be validated as a cross-layer problem spanning CPU, firmware, kernel parameters, device firmware, and user-space policy.
This three-part series outlined system context and platform prerequisites; the boot timeline from power through DVSEC, decode/mem_enable, CDAT/DOE, ACPI tables, and driver attach; and user-space tooling plus transport-level checks for CXL.mem enablement and HDM validation.
Future work includes switched and multi-device topologies, CXL 3.x pooling models, formal compliance automation, and standardized regression coupling protocol evidence with OS topology and workload QoS.
Acknowledgment
The author thanks Linux CXL kernel developers (the detailed notes and exchanges in lwn.net are extremely valuable), the open-source CXL community, the CXL Consortium, and platform engineers at CXL memory expander vendors and hyperscalers. Any errors remain the author’s own.
Ameet Sanghavi works in post-silicon validation for PCIe and CXL at Nvidia with a focus on interface bring-up and validation on shipping products. He has worked on PCIe since 2005 (from PCIe 1.1 onward) and on CXL since 2020 (from CXL 1.1 onward).
Editor’s Note
The views and content of the article are the author’s own and not affiliated to any of his current or previous employers.
Related Content
- Stripped Down CXL Scales Memory Wall
- CXL Efforts Focus on Memory Expansion
- CXL Adds Port Bundling to Quench AI Thirst
- CXL: The key to memory capacity in next-gen data centers
- From GPUs to Memory Pools: Why AI Needs Compute Express Link (CXL)
The post Test, debug, and validation of CXL memory expanders appeared first on EDN.
STMicroelectronics Reports 26% Rise in Revenue, Bets Big on AI Data-centre Markets
According to STMicroelectronics, net revenues for the second quarter were $3.49 billion, up 26% on an annual basis. Gross margins reached 34.8% and for the quarter the firm saw $187 million in operating income. Net income of $222 million signifies a robust bounce back from a net loss last year.
The company said that the quarterly results were helped by solid business conditions with demand for a range of products rising in the markets such as communications equipment, computer peripheral, automotive and other semiconductor applications. In addition, STMicroelectronics revised upward its outlook for its data-centre activities due to rising demand associated with AI-related infrastructure.
For the third quarter of 2026, the company forecasts net revenues of $3.70 billion and a gross margin of 37.0%. STMicroelectronics is looking forward to robust second-half demand from AI and other end-market segments.
During the Q2 2026, STMicroelectronics (news releases) reported quarterly net revenues came above the mid-point of its business outlook driven by stronger revenue performance in its Communications Equipment, Computer Peripherals (CECP) and Automotive segments, and the company also reported gross margin in line with the mid-point of the outlook. “Q2 net revenues came above the mid-point of our business outlook range, driven by higher revenues in CECP and Automotive,” stated Jean-Marc Chery, President & CEO at STMicroelectronics. “Gross margin was in line with the mid-point of our business outlook range.”
Chery added that it will also see a rise in AI data-centre markets contribute to revenue, seeing “sustained strength in AI data-centres” means the company will now increase revenue for its data-centre market segment. This segment’s revenues “will exceed $1 billion in 2026, and, if we maintain customer engagements and market trends continue to evolve, are projected to well surpass $2 billion in 2027”, the company confirmed, signalling strength within “this burgeoning AI data-centre market space.”
The post STMicroelectronics Reports 26% Rise in Revenue, Bets Big on AI Data-centre Markets appeared first on ELE Times.
Rohde & Schwarz Presents New Software for Three-Phase Power Analysis on MXO Series Oscilloscopes
Rohde & Schwarz has introduced the new R&S MXO-K333 software option for three-phase power analysis on its MXO series oscilloscopes. The software adds in-depth measurement and analysis functions for testing and debugging three phase power systems, drives and inverters.
Available for all four and eight channel models of the MXO 3, MXO 4, MXO 5 and 5C oscilloscopes, it supports the analysis of voltage and current signals in three-phase AC systems. This innovative test solution keeps the captured waveforms visible during measurement, allowing engineers to review power values and check transient behavior in the same instrument. Other oscilloscope functions such as math, spectrum analysis, measurement tracking and zone trigger remain available for further analysis.
A guided setup wizard assigns the oscilloscope channels to the voltage and current probes used for the three-phase analysis. It verifies the wiring and supports common two-wire, three-wire and four-wire configurations (2V2A, 3V3A and 3VN3A). After setup, the software provides cycle-by-cycle calculations for RMS values, power factor, active power, reactive power and total power. By defining the input and output configuration, users can also calculate the system’s three-phase efficiency. Additional analysis views include phasor display, harmonic analysis and THD measurements in line with IEC 61000-3-2 and MIL-STD-1399.
As an oscilloscope-based solution, the R&S MXO-K333 enables engineers to correlate three-phase power results directly with the underlying voltage and current waveforms in real time. This is especially valuable during R&D and debugging, when power behavior often must be analyzed alongside switching events, transients, control signals and communication activity. Users can combine the three-phase analysis with inherent MXO capabilities such as advanced triggering, FFT, automated measurements, track functions and protocol decoding. This allows engineers to move from power measurement to root-cause investigation in a single instrument.
The post Rohde & Schwarz Presents New Software for Three-Phase Power Analysis on MXO Series Oscilloscopes appeared first on ELE Times.
Palomino ships first-generation micro-LED light engine prototypes to first hyperscaler customer
USB-C’s lingering incompatibilities and complexities, part 2: Splitter issues

Yours truly can’t try to do the splits without ending up in the hospital, and suspects many of you would find the maneuver equally complicated-to-impossible…as does, it turns out, USB.
In last week’s initial post of this series, I discussed ongoing imperfections in the latest-generation USB-C standard, specifically with respect to single-source-to-sink interconnect, and encompassing power transfer, data interchange, and both-simultaneously setups.
- Nebulous-at-best identified cable capabilities and their user impacts
- Polarity dependencies on resultant performance
- The broader pros and cons of an industry standard which encourages compliance but doesn’t require independently assessed compatibility
In doing so, I was following up on other points already raised in my prior coverage, based on multiple case studies personally experienced by me.
- USB: Deciphering the signaling, connector, and power delivery differences
- USB Power Delivery: incompatibility-derived foibles and failures
- USB 3: How did it end up being so messy?
That includes the necessity for “sink” devices using USB-C for power-input purposes (including charging of embedded batteries) to connect solely to power sources via USB-A-to-USB-C adapter cables, versus newer and more logical dual-ended USB-C alternatives, in order to achieve proper-operation outcomes. Such workarounds presumably result from subpar USB Power Delivery (USB-PD) implementations.
At the conclusion of that prior post, I wrote:
I’ve got one more notable USB-C-related implementation-challenge situation to discuss, but after just passing through 2,000 words, I’m going to save it for next week’s part-two post.
Background to my curiosityThat’s where today’s follow-up blog comes in. Specifically, if you haven’t already figured it out from the title and subhead, I’m going to cover splitters, which assist in interconnecting a single source with multiple “sinks”, again with power, data, or both transfer aspirations.
My main impetus for recent interest in the topic is the portable power stations from EcoFlow and others that I’ve been acquiring, using, testing, and writing about of late. Take, for example, the EcoFlow RIVER 2 that I first covered in detail in February 2025.

It has only two USB-A power outputs, both 12 W max (industry-standard 5V@2.4A, absent any proprietary QC enhancements). And although its USB-C facilities are USB-PD cognizant (5/9/12/15/20V@3A, 60 W max), there’s only one of them. So, if my wife and I both want to fast-recharge our smartphones via USB-C during an extended power outage, for example, how might we be able to accomplish this without arm-wrestling or a shouting match? With a splitter, of course.
Here’s one example of the concept, an early “category creator” market entrant, Anker’s 140W 2-in-1 USB-C to USB-C cable.

We’ll revisit it later in this piece. It comes in 4’ and 6’ length options and black and white color variants and is analyzed in detail in this Reddit thread and linked teardown.
Proportional power allocation (or not)Back in prior-generation USB days, specifically for power splitting purposes, the implementation and usage were reasonably straightforward. The only source output voltage option was 5 V. The output current was whatever the source max’d out at. And the parallel-connected “sinks” consumed whatever subset of the available electrons each of them could successfully allocate to itself.
The only notable issues (unless I’m overlooking something; readers, let me know in the comments) with this elementary implementation were practical:
- Each “sink” device might recharge slower than if it had the source all to itself.
- Some of the “sinks” might not work reliably because their available allocated percentage of the current was insufficient for requisite power and/or recharge purposes.
- Others might not work because they required a voltage higher than 5 V (Apple laptops, for example, something I learned while researching adapters for part 1 of this series).
- And in the opposite-trend direction, if the source was subpar in its design, the high aggregate “sink” current demand might result in excessive output voltage drop sufficient to take all connected power destinations offline.
With USB-C (specifically, USB-PD), things unsurprisingly have gotten a “bit” more complicated. As my colleague Bill Schweber noted in his recent treatise on the topic, “USB-PD allows for multiple loads to be charged at the same time, each with different requirements”. And of course he’s right. But, then again, only with a properly implemented USB-PD ecosystem.
To wit, I’ve also come across plenty of case study examples on Reddit and elsewhere detailing situations, both hypothetical in their proposed root causes and confirmed by postmortem analysis, wherein someone plugged a laptop into one output of a splitter followed by a mouse, keyboard or some other more elementary device into the other output, a second device which (incorrectly) was then also subjected to the first device’s required high voltage and promptly emitted “magic smoke”, followed by demise.
So, what’s a splitter supplier to do? (At least) three options exist, as I see it:
- Bail on USB-PD and power everything by 5V@3A only (with already-discussed consequent potential functional issues).
- Negotiate with every connect device and run ‘em all at the lowest voltage that they all have in common. Safe? Sure. But also functional interruption-prone with every splitter output-tethered device connection and removal. Want your SSD to power-cycle mid-write each time something else mates with or detaches from the splitter? Me neither.
- Or follow the USB-PD spec to the nth degree, aspiring for per-splitter-output voltage and current optimization to the capabilities and preferences of the associated connected “sink” device, and hoping that your silicon and software “building block” suppliers have adequately accounted and compensated for all possible edge and corner cases.
Good luck with that, product developers and users alike.
Selective data directionalityReady for our next implementation complication? What, if anything, do you do about your customers’ potential desires for the connection between the splitter input and any/all output(s) to transport not only power but also data? In all the product implementations I’ve come across so far (stay tuned for the details to come shortly), bidirectional USB 2.0 (480 Mbps) rates are best-case supported, either assigned consistently to a dedicated output connector or to “the first output to connect to a device,” not simultaneously to all possible splitter outputs. But why?
Keep in mind that, akin to the passive Ethernet splitters that I discussed recently, there’s no active switching going on here. That’s what more complex (and costly) USB hub devices are for, if it’s what you need. Instead, once again, (at least) three implementation options exist with humble splitters, again as I see it (sound off in the comments, readers, if I overlooked or conversely overstated something):
- Bail on data carriage and focus only on power transfer. You’ll still need to comprehend the Configuration Channel (CC) signals if you want to support USB-PD, however.
- Pick a splitter output and run the bidirectional data solely and consistently between it and the input.
- Or decide that the first device that connects to the splitter’s multiple outputs is the only one that has the opportunity, if it chooses to take advantage of it, to leverage not only power but also bidirectional data transfer facilities. And what happens when that device later disconnects from the splitter? Unclear.
I’ve so far collected four USB-C splitters in recent months, for both personal-use and teardown purposes. As you’ll see shortly, they handle both power and data transfer very differently, a divergence scenario that I find very interesting, as it implies leverage of different reference designs if not entirely different chip-supplier foundations (therefore the teardown angle).
In alphabetical order, beginning with the product you’ve already been introduced to earlier:
- Anker 2-in-1 USB-C to USB-C cable
- Length options: 4’ and 6’
- Color options: black and white
- Outputs: 2
- Power carriage: 140 W (max). “When two devices are used simultaneously, the first device plugged in receives higher power. The actual power each device receives depends on its power needs.”
- Data carriage: USB 2.0 (480 Mbps) to first connected device
- Belkin 2-in-1 USB C to USB c Cable
- Length: 5’
- Color options: black and white
- Outputs: 2
- Power carriage: 140 W (max). “With two devices, smart power sharing splits power and the first device plugged in may get priority.”
- Data carriage: USB 2.0 (480 Mbps) to first connected device

- Baseus Flash 2 in 1 USB C cable
- Length: 4.9’
- Color: black and white
- Outputs: 2
- Power carriage: 100 W (max)
- Data carriage: USB 2.0 (480 Mbps)
- Note: data transfer is apparently supported only in the latest v2 design. Conversely, with the seemingly initial product version I’d purchased back in September 2024, “Please note that this cable is designed specifically for charging purposes and does not support data transfer or video signal transmission.”

- MPATIBY 4 in 1 USB C cable
- Length: 5’
- Color: Black and grey (the version I own: various other options also available)
- Outputs: 4
- Power carriage: 5V-only: “The usb c multi charging cable does NOT support fast charging.”
- Data carriage: USB 2.0 (480 Mbps), consistently and only to one of the outputs, with a uniquely labeled connector.

Back in the early days of USB-C, when Nexus smartphones and M1 Apple Silicon-based laptops were getting destroyed by dodgy cables, hubs, chargers and other third-party implementations (or at least that’s what Apple was blaming), an engineer at Google named Benson Leung was the “knight in shining armor” that everyone was relying on to both publicly shame the miscreants and tell users what they should be buying instead. Benson’s seemingly still at Google and remains active on Reddit re USB-C matters, even though his Linkedin profile reports he’s now primarily working on other stuff.
More generally, I consistently found myself directed toward relevant discussion threads on the UsbCHardware subreddit (for which Benson is one of the moderators) as I was web searching while researching various topics in preparation for writing this piece, links to several of which I’ve already shared in both parts of this writeup series. Quality time spent there to get up to speed, while as-usual-for-Reddit filtering out the cruft, is recommended for any USB-C devotee.
And with that, I’ll wrap up for today. As always, I welcome your thoughts in the comments!
—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.
Related Content
- USB-C’s lingering incompatibilities and other complexities, part 1: Direct-connect complications
- USB: Deciphering the signaling, connector, and power delivery differences
- USB Power Delivery: incompatibility-derived foibles and failures
- USB 3: How did it end up being so messy?
- USB-C and Power Delivery: Too much of a good thing?
The post USB-C’s lingering incompatibilities and complexities, part 2: Splitter issues appeared first on EDN.
EEVblog 1761 - Micsig MHO14 Tablet Oscilloscope TEARDOWN
КПІшник створив дрон для пошуку мін
☑️ 20-річний студент Київської політехніки Юрій Юрчук разом із командою розробляє безпілотник SOLER, що допомагатиме нашим саперам обстежувати потенційно заміновані території.
Aixtron recruiting staff for new Penang facility
Volta to acquire remaining 20% stake of Springer Rare Earth and Gallium Deposit
AXT adds Jia-Bin Duh to board
Rad-hard GaN converters: Design insights for space hardware

The aerospace industry is undergoing a profound power architecture shift. For decades, radiation-hardened (rad-hard) silicon MOSFETs were the undisputed workhorses of spaceborne DC-DC converters. However, as modern satellite payloads demand higher efficiency, tighter density, and lower mass, silicon is hitting its physical limits.
Enter gallium nitride (GaN) high electron mobility transistors (HEMTs). Boasting a wider bandgap, superior electron mobility, and inherent robustness against certain radiation mechanisms, GaN is the key to unlocking next-generation space power densities. Yet, translating these raw material advantages into flight-ready, highly reliable hardware requires a deep understanding of its unique driving requirements and its interaction with rad-hard pulse width modulation (PWM) controllers.
The rad-hard landscape: Silicon vs. GaN
Space radiation hazards generally fall into two categories: Total ionizing dose (TID) and single event effects (SEE).
In silicon MOSFETs, TID causes a build-up of trapped holes in the thick gate oxide, leading to a severe negative shift in threshold voltage (Vth) and increased leakage current. On the other hand, GaN HEMTs lack a traditional gate oxide, utilizing a Schottky or p-GaN gate structure instead. Because there is no oxide to trap charges, rad-hard GaN devices exhibit exceptional inherent tolerance to TID, often surviving exposure well past 100 krad(Si) to 1 Mrad(Si) with minimal parameter shifts.
While GaN shines under TID, SEE is where the engineering nuances lie. Silicon MOSFETs are susceptible to single event burnout (SEB) and single event gate rupture (SEGR) due to heavy ion strikes creating parasitic bipolar conduction paths or destroying the gate oxide.
But GaN HEMTs don’t suffer from traditional SEB or SEGR because they are majority-carrier devices without parasitic bipolar structures. However, they are prone to single event transients (SETs) and catastrophic degradation at high drain-to-source voltages (VDS). Under heavy ion bombardment, localized high electric fields near the drain can cause high-current leakage paths. Consequently, a VDS derating of 30% to 50% of the maximum rated voltage is standard practice for spaceflight GaN applications.
Alex Lidow, CEO and co-founder of Efficient Power Conversion (EPC), notes the physical limitations of legacy materials: “Silicon has had a glorious 60-year run, but it has hit its theoretical performance wall. In space applications, where every gram of weight translates directly to launch cost, GaN isn’t just an alternative—it’s an absolute architectural necessity.”
Driving the delicate GaN gate
The primary challenge when designing a flight-ready GaN converter is managing the gate drive. Silicon MOSFETs typically feature a comfortable gate threshold of 2 V to 4 V and can tolerate gate voltages up to ±20 V. GaN HEMTs are far less forgiving:
- Low threshold voltage: GaN devices typically turn on at a mere 1.5 V to 2.0 V.
- Fragile gate rating: The absolute maximum gate-to-source voltage (VDS) is often capped at a tight -5 V to +6 V.
- Ultra-low gate charge (QG): GaN switches an order of magnitude faster than silicon. While this minimizes switching losses, it introduces severe dv/dt and di/dt sensitivities.
If the gate drive circuit experiences even minor parasitic inductance, the rapid dv/dt transition can couple back through the device’s Miller capacitance (CGD), generating a transient voltage spike on the gate. If this spike exceeds 1.5 V, it triggers a catastrophic spurious turn-on (shoot-through), potentially destroying the power stage. Conversely, if the gate driver overshoots beyond 6 V due to ringing, the gate permanently degrades.
Interfacing with heritage PWM controllers
Because dedicated rad-hard GaN-integrated drivers are still emerging, power engineers frequently pair discrete rad-hard GaN FETs with established, flight-proven rad-hard analog PWM controllers.
These heritage controllers were designed to drive the heavy, capacitive gates of silicon MOSFETs, delivering output swings from 0 V to 12 V or higher. Interfacing these high-voltage controllers with a delicate 5-V GaN gate requires a meticulously designed intermediate drive stage and layout discipline.
- Voltage clamping: Direct connection is catastrophic. Engineers must employ a high-speed level shifter or a dedicated, rad-hard gate driver buffer (for example, ISL71020M) that accepts standard PWM logic levels and provides a tightly regulated 5-V drive output.
- Asymmetric gate resistance (RG): The gate resistor network must be split into separate turn-on (Rgon) and turn-off (Rgoff) paths via a diode-resistor network. Rgon is optimized to purposefully slow down the turn-on dv/dt to suppress gate ringing. Rgoff is kept near 0 Ω to provide a low-impedance hold-down path, ensuring the gate remains firmly below the threshold voltage during rapid drain voltage transitions.
- Dead time management: GaN HEMTs lack a native body diode; so, they conduct in reverse through the channel when the gate is off. During this dead time, the reverse voltage drop (VSD) can be quite high (2 V to 3 V). If the PWM controller introduces excessive dead time, efficiency penalties from reverse conduction negate the switching advantages of GaN. Therefore, designers must utilize PWM controllers with highly precise programmable dead-time control or implement an external low-forward-drop Schottky diode in parallel.
In my years managing power electronics design, I have watched countless clean schematics fall apart under the oscilloscope simply because an engineer treated a fast wide-bandgap loop layout like a legacy 100-kHz silicon board.
When marrying a heritage 12-V PWM architecture to a 5-V gate, your layout must be an absolute work of art. Parasitic inductance can easily destroy the gate on the very first pulse if the loop area isn’t locked down.
Packaging innovation and real-world use cases
The unique performance GaN metrics are actively reshaping the size, weight, and power (SWaP) equation across various orbital profiles.
In satellite bus power, utilizing isolated GaN-based flyback or forward topologies allows engineers to push switching frequencies past 500 kHz—up from the standard 100 kHz legacy limit—directly translating to a 60% reduction in magnetics volume. In point-of-load (POL) converters, synchronous buck configurations supply core logic rails for spaceborne FPGAs and deep-space processing computers with near-zero reverse recovery losses. Furthermore, in space robotics and motor control, three-phase GaN inverter stages enable compact, motor-integrated electronics housings that bypass heavy shielded cabling.
To support these high-frequency applications, manufacturers have developed innovative, low-inductance packaging structures specifically engineered to eliminate the internal bond wires that cripple traditional high-reliability packages.
Vendor landscape and flight heritage
Navigating the space-qualified GaN marketplace requires examining components that meet the rigorous screening levels required for aerospace reliability. Below are three design case studies.
- EPC Space
The EPC Space family of devices commands a long track record in commercial-volume rad-hard discrete GaN deployment. Its enhancement-mode (eGaN) discrete FETs (such as 60-V EPC7014) and integrated power modules have accumulated an impressive lineage, with thousands of devices actively operating in orbit since January 2019. These components are heavily utilized in LEO small-sat constellations and GEO communication platforms, powering intermediate bus converters and high-speed pulsed laser drivers for autonomous LiDAR systems.

Figure 1 EPC Space’s hermetic packaging replaces traditional wire bonds with broad, low-profile bottom contact pads to eliminate loop inductance. Source: EPC
- Infineon Technologies
Infineon’s CoolGaN family represents the entry of traditional military-standard (MIL-PRF-19500) JANS-grade rigor into the wide-bandgap space ecosystem. Leveraging its heritage in spaceborne silicon MOSFETs, Infineon modernized GaN packaging by removing wire bonds entirely. It PowIR-SMD package delivers a 49% footprint reduction compared to legacy housings and reduces internal parasitic package inductance by 97%—dropping to a mere 0.1 nH. This nearly eliminates internal gate ringing, allowing clean interfacing with fast PWM controllers.

Figure 2 The PowIR-SMD technology minimizes internal parasitic inductance down to 0.1 nH via an advanced die-free construction. Source: Infineon
Regarding the validation of these advanced architectures, a high-reliability engineering expert at Infineon stated: “Removing internal wire bonds was the final frontier for GaN in space. By developing a die-free, surface-mount package like PowIR-SMD, we didn’t just solve thermal management—we completely neutralized the parasitic gate inductance that historically caused engineers to shy away from high-speed wide-bandgap switches in critical flight hardware.”
- Renesas
Renesas entered the space-qualified GaN arena by executing a brilliant ecosystem play: combining its decades-long legacy of rad-hard analog power management with high-reliability GaN FETs like ISL73024SEH. These devices are frequently designed alongside dedicated multi-phase synchronous PWM controllers—such as the ISL73847SEH—to form the fundamental backbone of spaceborne core power bricks.

Figure 3 The Renesas/Intersil radiation-hardened GaN family is engineered in rugged, space-qualified ceramic flatpacks optimized for severe thermal environments. Source: Renesas
Achieving mission success
While designing deep space profiles, we must ruthlessly enforce gate-clamping rules. Designing radiation-hardened GaN converters for space applications is ultimately an exercise in managing extremes. GaN offers game-changing thermal and volumetric efficiencies, but its unforgiving gate drive margins and extreme switching speeds mandate a departure from legacy silicon layout rules.
The accumulated flight data from the GaN industry pioneers has rewritten the rulebook for space power systems, dispelling early engineering anxiety through years of anomaly-free orbital operation. When carefully controlled by a robust, rad-hard PWM controller, these devices provide a mature, predictable, and remarkably rugged path toward achieving unparalleled power density in the cosmos.
Bharrat Mehta, a senior space scientist, is former deputy project director of Indian Space Research Organization (ISRO).
Related Content
- GaN Transistor for Space Missions
- Infineon unveils rad-hard GaN transistors
- Deep Space Challenges Rad-Hard IC Development
- Test and Measurement Priorities for GaN-Based Power Electronics
- GaN in Space: Unlocking Efficiency and Performance in Satellite Systems
The post Rad-hard GaN converters: Design insights for space hardware appeared first on EDN.
Sorting and repairing a batch of returned gaming gear — daily workbench & storage workflow
| Here is a look at my daily workshop setup for diagnosing, micro-soldering, and refurbishing batches of returned gaming gear and electronics. My main focus is on component-level fixes: replacing double-clicking microswitches, faulty wheel encoders, damaged PCB traces, connectors, and power components. Working with larger volumes requires keeping the workbench organized for fast diagnosis, desoldering, and full functional testing before reassembly. Always open to discussing repair techniques, equipment preferences, or diagnostic approaches for small electronics! [link] [comments] |
Riber’s revenue grows 19% in first-half 2026, driven by 71% growth in Services & Accessories
Low-power RTC simplifies embedded timekeeping

The RTC 27 Click board from Mikroe provides ultra-low-power timekeeping with alarm, watchdog, and timestamp functions. Based on the mikroBUS add-on board socket standard, it integrates the NXP PCF8525 nano-power CMOS real-time clock and calendar chip with an I2C interface. The board is the 2000th member of the Click family, enabling developers to quickly build proof-of-concept designs, prototypes, and embedded applications.

Using the PCF8525’s default temperature compensation engine and integrated temperature sensor, the RTC 27 Click corrects crystal frequency drift, achieving typical ±30-ppm accuracy across temperature and up to 5× better timekeeping than an uncompensated RTC design. It provides time and calendar information, including year, month, day, weekday, hour, minute, second, and 1/100 second.
The RTC 27 Click operates with 3.3-V and 5-V logic voltage levels, while the PCF8525 consumes a typical 64 nA in timekeeping mode with a 3.3-V supply. This makes the board well suited for battery-powered and always-on designs, including portable instruments, wearables, industrial systems, and IoT applications.
The RTC 27 Click is available from Mikroe and its distributors with single-unit pricing of $19.
The post Low-power RTC simplifies embedded timekeeping appeared first on EDN.
AI assistant optimizes inference pipelines

Voyager Wingman from Axelera AI is an AI-powered assistant that works with the Voyager Toolkit to accelerate AI application development. It enables developers to interact with the Voyager SDK and Axelera’s documentation using natural language to build, debug, and optimize AI inference pipelines. In internal testing, Wingman achieved 20% to 30% higher accuracy than general-purpose AI coding tools such as Claude Code.

Developing AI applications for dedicated hardware involves tasks such as model export and compilation, pipeline configuration, performance tuning, analytics, and output visualization. To streamline these workflows, Voyager Wingman focuses on four key areas:
- Application development. Natural language generation of computer vision pipelines, including AI models, pre-processing and post-processing steps, and multi-stage pipelines.
- Performance optimization. Recommendations for compiler settings and other optimizations to improve application performance on Axelera hardware.
- Debugging. Assistance with identifying and resolving configuration errors, device detection problems, and model compilation failures.
- Documentation assistance. Natural language access to information on supported operators, APIs, runtime behavior, and configuration syntax.
Voyager Wingman is available through the Axelera Developer Community and Customer Portal. The web-based chat service includes a free credit allowance for developers, while the standalone application is free with the developer’s own LLM API key. For more information, visit the Voyager SDK and Wingman page.
The post AI assistant optimizes inference pipelines appeared first on EDN.
Rapidus, Cadence partner on agentic SoC AI

Rapidus and Cadence are collaborating to advance agentic AI for advanced SoC design and accelerate design turnaround time. The effort integrates the Cadence InnoStack AI Super Agent with the Rapidus AI-Agentic Design Solution (Raads), combining Cadence’s agentic AI orchestration technology with Rapidus’ AI-native design and manufacturing ecosystem for advanced-node semiconductors. According to Rapidus, the approach targets up to a 2× reduction in design turnaround time over conventional design flows.

Rapidus is extending its Raads AI-agentic design environment with the introduction of Raads Navigator and Raads Indicator to enhance quality assurance and help designers resolve design issues. Integrated with the InnoStack AI Super Agent, the new capabilities enable agentic design orchestration across key SoC workflows, automating and coordinating tasks from early architectural exploration through implementation and signoff. The integration allows teams to better manage advanced-node complexity and improve design predictability.
The InnoStack AI Super Agent is available from Cadence. Raads is part of Rapidus’ AI-native foundry ecosystem for customers developing advanced-node semiconductor designs.
The post Rapidus, Cadence partner on agentic SoC AI appeared first on EDN.



