Feed aggregator

In booth 243 (Hall 6) at the PCIM 2026 (Power Electronics, Intelligent Motion, Renewable Energy and Energy Management) Expo & Conference in Nuremberg, Germany (9–11 May), fabless company Wise Integration of Hyeres, France is showcasing its latest WiseWare-powered AC–DC demo boards, highlighting its roadmap toward distributed digital control with the new generation of WiseGan Digital First power ICs...

Video Dragon 6222 combines a frame grabber and frame generator in a single device. GÖPEL electronic offers a modular setup using the Video Dragon 6222 for the verification of high-resolution industrial cameras, display systems, and imaging units. As a high-performance solution, this setup is suitable for all camera and display applications where the highest standards of image quality, reliability, and reproducibility are required. The setup combines a frame grabber and frame generator into a single system, enabling the capture, analysis, and output of video data in a seamless workflow—from development through validation to production.

With increasing resolutions, frame rates, and heterogeneous interfaces, the complexity of testing camera and imaging systems is growing. Video Dragon 6222 addresses this challenge head-on and impresses with a modular hardware design, flexible sideband communication, and intuitive application software. The use of project-specific interface units, such as pin adapters, enables flexible implementation and a precise connection to the respective applications. Developers, test engineers, and production managers thus gain a powerful solution for reliably testing stability during continuous operation, interface compatibility, and timing.

Video Dragon 6222 combines a frame grabber and frame generator in a single device. This allows incoming video streams from high-resolution cameras to be recorded, visualized, and analyzed. It also enables the output of test patterns and videos with freely configurable resolution, color formats, and frame rates. As a “man-in-the-middle,” Video Dragon can integrate into existing systems without affecting their behavior. This flexibility enables rapid debugging of prototypes, objective verification of production products, and long-term and stress testing under realistic conditions. The modular architecture reduces integration effort and ensures investment security, as new interfaces can be added as needed.

The included Dragon Suite software offers a clear, intuitive user interface that provides access to all hardware functions—without any programming effort. The cross-hardware interface G-API is available for integration into custom applications. It maps all hardware functions and enables rapid automation, e.g., in validation environments, production test benches, or HIL systems.

The Video Dragon 6222 product family includes three models that cover all use cases:

• G CAR 6222 (standalone device): Ideal for lab, mobile testing, and flexible setups
• G PCIe 6222 (PCI Express card): Directly in the test PC, high data density, and automation
• G PXIe 6222 (PXI-Express module): Optimized for modular test systems and fully automated production lines

These variants enable end-to-end deployment from the developer’s workstation through validation test benches to production testing.

The post Optimizing Vision: High-Performance Testing for Industrial Cameras and Displays appeared first on ELE Times.

End-user spending on public cloud services in India is forecast to grow 28.1% to a total of $17.5 billion in 2026, up from $13.7 billion in 2025, according to Gartner, Inc, a business and technology insights company.

“Strong enterprise demand for AI-ready cloud infrastructure is redefining cloud investment priorities in India, driving the next phase of public cloud spending growth,” said Ashish Banerjee, Sr Principal Analyst at Gartner. This is further fueled by rising demand for application modernization, digital sovereignty, digital service delivery, and more scalable, consumption-based IT models, as organizations move toward more advanced and strategic cloud use cases.

“Cloud adoption is becoming more tightly aligned with business goals, such as improving productivity, accelerating innovation and go-to-market speed, enhancing customer experience, and strengthening business resilience,” said Banerjee.This sharper focus on business outcomes is sustaining strong momentum in cloud investments across the country.
Gartner analysts are exploring how IT infrastructure and operations (I&O) leaders can advance their cloud strategies and optimize costs at the Gartner IT Infrastructure, Operations & Cloud Strategies Conference in Mumbai this week.
Infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) are expected to be the fastest-growing segments in India’s cloud market, with IaaS projected to grow 40% in 2026, followed by PaaS at 25.4% (see Table 1).

Table 1. India Public Cloud Services End-User Spending Forecast (Millions of U.S. Dollars)

	2025 Spending	2025 Growth (%)	2026 Spending	2026 Growth (%)
Cloud Application Infrastructure Services (PaaS)	5,114	22.1	6,414	25.4
Cloud Application Services (SaaS)	3,901	16.7	4,637	18.9
Cloud Desktop-as-a-Service (DaaS)	171	4.9	176	2.9
Cloud System Infrastructure Services (IaaS)	4,470	34.9	6,259	40.0
Total Market	13,656	24.0	17,487	28.1

Source: Gartner (June 2026)

“The rising need for AI-ready infrastructure, including GPUs, high-performance compute, high-speed networking, scalable storage and always-on inference capacity, is amplifying IaaS adoption and driving higher spending in this segment,” said Banerjee. PaaS is the largest spending category for Indian organizations in 2026, and is forecast to reach $6.4 billion, as enterprises rebuild their technology foundations to support AI-driven initiatives.

“Organizations are accelerating adoption of AI-driven technologies to unify data, connect systems, speed up development and enable real-time digital interactions, driving PaaS growth beyond cloud migration toward platform-led execution,” said Arunasree Cheparthi, Sr Principal Analyst at Gartner.

SaaS is expected to exhibit more moderate growth in 2026. “This reflects its established adoption base, as enterprises optimize licenses, rationalize usage, and shift incremental spending toward infrastructure and platform capabilities required to scale workloads and operationalize AI at scale,” said Cheparthi.

Cloud Priorities in 2026 and Beyond

Governance of increasingly complex hybrid, multicloud, and AI-enabled environments is emerging as one of the most significant cloud challenges for enterprises in 2026. Gartner predicts that by 2030, over 60% of enterprises will perform intensive AI model activity in one cloud but leverage it with their data in another, up from less than 10% today.
“Over the next 12-18 months, I&O leaders in India need to shift from cloud adoption to disciplined execution,” said Banerjee. “This includes prioritizing AI-ready data and infrastructure, stronger governance, FinOps maturity, security-by-design, and dynamic workload placement across hybrid and multicloud environments.”
“Organizations that can scale AI and digital initiatives while demonstrating business value, maintaining cost and risk discipline, and addressing critical skills gaps without slowing innovation, are expected to outperform their peers.”

The post Gartner Forecasts End-User Public Cloud Spending in India to Surpass $17 Billion in 2026 appeared first on ELE Times.

Infineon Technologies, a leading provider of power systems and IoT, joins NVIDIA’s MGX AI Factory ecosystem to help transform power delivery for next-generation AI data centers. Infineon’s power management solutions support NVIDIA’s MGX architecture and 800 VDC power architecture, an open, modular reference architecture for AI factories in the agentic AI era. 800 VDC MGX-compatible power racks help existing AI infrastructure scale AI compute performance and power density, creating an upgrade path for future AI infrastructure.

“As a member of NVIDIA’s ecosystem, Infineon is working with NVIDIA to redefine power delivery systems from the grid to the processor core, which is required for this next phase of AI innovation,” says Adam White, Division President, Power & Sensor Systems at Infineon. “As AI models continue to grow in size and complexity, data centers must deliver dramatically more compute performance within the same physical, power, and cooling constraints. Combined with NVIDIA’s modular MGX architecture, Infineon’s power solutions significantly enhance energy-efficient power distribution across the entire data center power flow. We look forward to continuing our work with NVIDIA to bring more MGX-powered innovations to market.”

Infineon’s deep expertise in power conversion from grid to core leverages all relevant semiconductor materials, including silicon (Si), silicon carbide (SiC), and gallium nitride (GaN). This comprehensive approach helps accelerate the transition toward full-scale 800 VDC architectures. Using Infineon’s GaN technology at switching frequencies close to 1 MHz enables ultra-compact bus converters at an industry-leading efficiency, while the combination of Infineon’s proprietary SiC JFET technology and dedicated control ICs is the perfect match for protection and hot-swap functionality of native 800 V server boards. Infineon’s power management solutions convert power from 800 V to 50 V, 12 V, or even down to 6 V.

As part of the NVIDIA MGX AI Factory ecosystem, Infineon supports the complete 800 VDC power conversion flow down to an intermediate bus voltage and core voltage in systems based on NVIDIA MGX, helping to reduce conversion stages and deliver DC power closer to the rack. This improves power efficiency, simplifies infrastructure, and supports higher-density AI deployments.

About NVIDIA 800 VDC

NVIDIA’s 800 VDC MGX-compatible power racks help existing AI infrastructure increase compute performance and power density without waiting for full-scale 800V DC AI factories. They provide an upgrade path for higher-density accelerated computing, enabling hybrid power architectures that protect current infrastructure investments while preparing AI factories for future workloads.

About Infineon

Infineon Technologies AG is a global semiconductor leader in power systems and IoT. Infineon drives decarbonization and digitalization with its products and solutions. The Company had around 57,000 employees worldwide (end of September 2025) and generated revenue of about €14.7 billion in the 2025 fiscal year (ending 30 September). Infineon is listed on the Frankfurt Stock Exchange (ticker symbol: IFX) and in the USA on the OTCQX International over-the-counter market.

The post Infineon Brings 800V Power Delivery to Nvidia’s MGX AI Server Racks appeared first on ELE Times.

Keysight Technologies, Inc. announces a new capability within its RF Circuit Simulation Professional software, which enables engineers to capture their design process on an executable whiteboard. It replicates the engineer’s decision process, capturing simulations, optimizations, decision trees, and design parameters built on prior analyses. Each step generates editable Python code that can be saved, shared, and redeployed across Keysight Advanced Design System (ADS), Cadence Virtuoso, and Synopsys Custom Compiler environments.

RF organizations face a looming talent gap. McKinsey projects the semiconductor industry will need 88,000 engineers by 2029. In RF design, the challenge is more acute. Simulation methodologies spanning multiple physics domains can take years to master, and critical expertise is often lost when senior engineers leave.

Design teams face inefficient workflows, simulation bottlenecks, and knowledge barriers. RF Circuit Simulation Professional lets engineers construct their workflow on a visual whiteboard or in auto-generated Python scripts. Each step executes simulations, optimizations, and design decisions in sequence, with support for decision-based loops and parameter settings.

Each workflow becomes a repeatable methodology that can be shared across teams, reused, and driven by AI. Design review and tapeout steps that previously required manual setup for each iteration now run automatically.

Nilesh Kamdar, EDA General Manager, Keysight, said: “RF design expertise is leaving the industry faster than it can be replaced. The simulation knowledge that senior engineers have accrued cannot be transferred through documentation alone. Design teams now have a way to capture that experience as a visual, executable, reusable workflow. The structured data this generates, and the underlying Python APIs, are the first step toward fully automated, AI/ML-driven RF design.”

The post Keysight Tackles Semiconductor Talent Gap with Executable RF Design Whiteboard appeared first on ELE Times.

Efficient Power Conversion Corp (EPC) of El Segundo, CA, USA — which makes enhancement-mode gallium nitride on silicon (eGaN) power field-effect transistors (FETs) and integrated circuits for power management applications — has provided additional details on its EPC91123 evaluation board, an 800VDC-to-12.5VDC, 6kW isolated converter designed to support next-generation AI data-center power architectures. As a contributor to the NVIDIA MGX AI Factory ecosystem, EPC contributes advanced GaN-based power conversion solutions designed to support emerging 800VDC server architectures, enabling higher power density, improved efficiency, and scalable rack-level power delivery for next-generation AI infrastructure...

Efficient Power Conversion Corp (EPC) of El Segundo, CA, USA — which makes enhancement-mode gallium nitride on silicon (eGaN) power field-effect transistors (FETs) and integrated circuits for power management applications — has provided additional details on its EPC91123 evaluation board, an 800VDC-to-12.5VDC, 6kW isolated converter designed to support next-generation AI data-center power architectures. As a contributor to the NVIDIA MGX AI Factory ecosystem, EPC contributes advanced GaN-based power conversion solutions designed to support emerging 800VDC server architectures, enabling higher power density, improved efficiency, and scalable rack-level power delivery for next-generation AI infrastructure...

Deposition equipment maker Aixtron SE of Herzogenrath, near Aachen, Germany says that its Close Coupled Showerhead (CCS) R&D system will serve as the centerpiece of a new semiconductor research facility at Penn State’s Materials Research Institute (MRI)...

Deposition equipment maker Aixtron SE of Herzogenrath, near Aachen, Germany says that its Close Coupled Showerhead (CCS) R&D system will serve as the centerpiece of a new semiconductor research facility at Penn State’s Materials Research Institute (MRI)...

MacDermid Alpha Electronics displays its latest attachment materials, which help power electronics manufacturers to improve reliability, process variation, and scale production more effectively. As automotive, industrial, and AI-driven data center applications demand higher power density and faster-switching devices, manufacturers are facing tighter thermal limits and increasing pressure to maintain stable, repeatable production. Bond line control, void reduction, and manufacturing consistency are becoming more critical to long-term power module performance.

MacDermid Alpha highlights its expansion of the ALPHA Argomax sintering portfolio and the ALPHA TrueHeight solder preforms, designed to help customers improve thermal and electrical performance while supporting more stable, high-volume manufacturing.

MacDermid Alpha will also contribute to the PCIM Europe technical program, sharing insights on electronics assembly solutions for emerging applications. On the AI stage, John Hynek, Global Product Manager, will examine how attach materials can support the uptime and reliability demands of AI and data center infrastructure. In addition, Andreas Socarras, Senior Application Engineer, will present a poster session titled “Investigation of Large Area Soldering Using High Stress Assembly and Challenging Surface Coatings”.

“Power electronics manufacturers need to attach solutions that can deliver tighter process control and higher reliability without adding unnecessary complexity,” said Gustavo Greca, Line of Business Director for Power Electronics at MacDermid Alpha Electronics Solutions.

MacDermid Alpha Electronics Solutions

MacDermid Alpha Electronics Solutions, a business unit of Element Solutions Inc, is a global leader in high-performance specialty chemicals, materials, and process technologies for every stage of the electronics manufacturing process. With expertise spanning circuitry formation, wafer-level packaging, circuit board assembly, semiconductor assembly, and film and smart surfaces, MacDermid Alpha delivers advanced, sustainable, and integrated solutions that drive innovation and reliability across the electronics supply chain. Operating worldwide and backed by more than a century of innovation, the organization supports a broad range of industries, including automotive, consumer electronics, data infrastructure, high-performance computing, and telecommunications, enabling next-generation electronics.

The post MacDermid Alpha Tackles Power Module Reliability appeared first on ELE Times.

Power Integrations Inc of San Jose, CA, USA (which provides high-voltage integrated circuits for energy-efficient power conversion) has introduced two new ultra-slim, compact auxiliary power supply reference designs for 800VDC AI data centers. The single-output, 15W design is only 30mm by 30mm with a 7mm profile, while the isolated, six-rail, 35W design is only 80mm by 60mm with an 8mm profile...

Design-time closure is no longer the end of system convergence.

In modern AI silicon—encompassing chiplet-based platforms, high-bandwidth memory systems, and advanced heterogeneous packages—the realized system continues to change after release. Workloads shift. Voltage and thermal conditions move dynamically. Network-on-chip (NoC) traffic patterns vary. Memory pressure changes. SerDes links retrain. Aging accumulates. Package and board environments influence behavior over time.

A system may pass design signoff, validation, and qualification, yet still encounter runtime states that were not fully represented during design-time closure. This does not mean the original design was wrong. It means the operating system has entered a lifecycle regime where hardware state, firmware response, and evidence maturity must remain synchronized.

This is where the firmware–hardware handshake becomes important. Hardware senses the condition; firmware executes bounded actions; and governed evidence determines whether the action is valid.

The handshake is not an uncontrolled autonomous loop. It’s a disciplined runtime structure that connects hardware telemetry, firmware policy, causality interpretation, bounded action envelopes, rollback limits, and lifecycle evidence.

In this viewpoint, firmware is not the intelligence. Firmware is the bounded execution layer. The intelligence is in the governed interpretation of evidence: whether a signal is mature enough, synchronized enough, causally grounded enough, and safe enough to support action.

From observability to action

In complex AI silicon, observability is expanding rapidly. NoC counters, voltage monitors, thermal sensors, ECC logs, accelerator stall indicators, memory-controller events, SerDes retraining records, clock-domain telemetry, firmware traces, and package-level sensors can all provide valuable runtime information.

Here is how the firmware–hardware handshake layer works in governed runtime convergence. Source: Author

Hardware telemetry is captured, normalized into evidence, checked for admissibility, evaluated for causality, and passed through bounded firmware policy before any runtime action is executed and recorded as lifecycle evidence. But telemetry alone does not create authority.

An NoC latency spike may correlate with workload congestion, but it may also reflect a localized thermal hotspot, voltage droop, memory backpressure, firmware scheduling behavior, or package-level power delivery instability. A SerDes retraining event may indicate channel degradation, but it may also be triggered by temperature drift, reference-clock behavior, board-level noise, connector variation, or power integrity disturbance.

The runtime system therefore faces a difficult question: When should firmware act?

If firmware acts too slowly, the system may lose performance, reliability, or availability. If firmware acts too aggressively, it may create instability, hide root cause, or trigger unnecessary throttling, rollback, or degraded operation. If firmware acts on weak evidence, it may correct the wrong problem.

This is why runtime telemetry must mature into governed evidence before it’s used to drive consequential action.

Hardware as sensing layer

Hardware provides the first layer of runtime awareness.

Examples include NoC latency, congestion, retry, and utilization counters; voltage droop sensors and current monitors; thermal sensors and hotspot indicators; memory-controller stalls and ECC events; SerDes equalization, retraining, and link-margin information; accelerator utilization and stall counters; clock, reset, and power-state telemetry; and package, board, and system-level sensor data.

These signals provide visibility into how the system behaves under real workload and environmental conditions.

However, hardware signals are not self-explanatory. They must be interpreted in context. A voltage droop event means something different during peak AI workload than during idle transition. A thermal hotspot means something different if it is stable, spreading, oscillating, or correlated with a specific workload pattern. An NoC stall means something different if it aligns with memory saturation, power throttling, package temperature, or firmware scheduling.

The key point is simple: Hardware can sense state, but it does not automatically explain state. And that explanatory layer requires causality, evidence maturity, synchronization, and decision context.

Firmware as bounded execution layer

Firmware is the natural runtime bridge between hardware state and system response. Depending on the platform, firmware may be able to adjust voltage and frequency states, throttle selected regions, retrain high-speed links, reduce lane rate or link width, isolate a tile or accelerator block, migrate workload away from a stressed region, change scheduling policy, request diagnostic capture, enter deterministic degraded mode, or trigger service and validation escalation.

These actions are powerful because they allow the system to respond before a condition becomes a failure. But that power also creates risk.

Firmware should not become an unconstrained autonomous agent. A firmware action can affect performance, lifetime, reliability, customer experience, safety margin, and debug visibility. If firmware changes the operating state without traceable evidence, the system may appear to recover while the underlying cause remains unresolved.

One of the risks of adaptive firmware is that it can unintentionally hide the physical root cause. A system may appear stable because a link retrained, a frequency state changed, a workload migrated, or a region was throttled. But if the intervention is not tied to a normalized evidence record, the original cause may disappear from view. In advanced systems, repeated compensation can become a failure mode of its own.

The purpose of the firmware–hardware handshake is therefore not only to act, but to preserve the evidence trail behind the action. In other words, the correct role of firmware is not unlimited control. The correct role is bounded execution.

Firmware should execute only within approved policy limits, with clear evidence requirements, confidence thresholds, rollback rules, and auditability.

The handshake model

The firmware–hardware handshake can be described as a governed runtime sequence:

Hardware state → contextual capture → normalized evidence → admissibility check → causality assessment → firmware policy → bounded action → updated evidence → lifecycle record

Each step prevents runtime telemetry from becoming uncontrolled action.

First, the hardware signal must be captured with context: timestamp, workload class, physical location, power state, thermal state, firmware version, configuration state, and system region. Second, the signal must be normalized into an evidence object. A raw sensor reading or counter value is not enough. It must be linked to the specific system condition it describes.

Third, the evidence must be checked for admissibility. Is the timestamp valid? Is the firmware version known? Is the sensor calibrated? Is the workload context synchronized? Is the signal consistent with voltage, thermal, memory, package, and board evidence? Is the proposed cause physically plausible?

Fourth, firmware action must remain inside a bounded envelope. The system may allow a defined frequency reduction, limited link retraining, controlled workload migration, or temporary degraded mode. But if evidence confidence is low or the action exceeds policy authority, escalation is required.

Finally, the outcome must be recorded. Did the action stabilize the system? Did the same condition recur? Did the event indicate a one-time workload excursion, a design margin issue, a package-related sensitivity, or an aging trend?

This is how runtime action becomes lifecycle evidence.

Bounded action envelopes

The bounded action envelope is the core safety mechanism. It defines what firmware may do, under what evidence conditions, and with what limits. For example, a firmware policy may allow temporary throttling if thermal evidence is mature, localized, and correlated with workload.

It may allow link retraining if signal-margin evidence crosses a defined threshold. It may allow workload migration if a tile shows repeated voltage-droop sensitivity under known conditions. It may allow deterministic degraded mode if full performance cannot be preserved without violating reliability boundaries.

But the same policy may block action when evidence is incomplete. If an NoC latency spike occurs without synchronized voltage, thermal, workload, and memory context, firmware should not automatically classify the NoC as the root cause.

If a link repeatedly retrains after thermal cycling, firmware should not hide the event indefinitely by retraining silently. If a voltage-droop event becomes recurrent under a specific package lot, board lot, workload class, or thermal condition, the system should escalate the event instead of silently compensating through repeated firmware action.

Bounded action does not mean passive behavior; it means disciplined behavior. The system can respond, but it must respond within governed limits.

Extending convergence into runtime

The handshake extends governed convergence beyond design-time. At design-time, engineers close the system against modeled requirements, simulated margins, validation data, and qualification evidence. At runtime, the system encounters real workload, real aging, real environment, and real variation.

The firmware–hardware handshake allows convergence to continue operationally. Several runtime concepts become useful here.

• A boot-time realization baseline can capture the initial measured system state at startup. This provides a reference for later drift.
• A corridor stability index can summarize the health of a specific governed path, such as an NoC region, power domain, HBM interface, SerDes path, or package-to-board corridor.
• A global convergence epoch can ensure that telemetry from multiple runtime sources is compared within a valid synchronization window.
• Realization fatigue tracking can monitor accumulated stress, repeated throttling, retraining frequency, thermal exposure, voltage events, or degradation patterns.
• A deterministic degraded mode can preserve safe operation when full performance is no longer evidence-supported.

These concepts are not meant to add vocabulary for its own sake. They define how runtime signals can be organized into a governed system state rather than scattered logs.

Why this matters for AI silicon

AI workloads are especially relevant because they stress systems dynamically and unevenly.

A training or inference workload may create localized NoC congestion, memory pressure, power spikes, or thermal concentration. The system may remain within global specifications while a local region experiences repeated stress. A package or board condition may interact with workload behavior in ways that were not fully visible during nominal validation.

In such systems, the firmware–hardware handshake becomes a reliability and performance tool. It allows the platform to distinguish between transient workload variation, recurring physical sensitivity, firmware scheduling artifacts, marginal power delivery behavior, thermal containment issues, aging-related degradation, validation escapes, and package or board interaction.

The goal is not to blame the NoC, firmware, package, power delivery network (PDN), memory, board, or workload too early. The goal is to preserve causality until the evidence is mature enough to support a decision.

Relationship to fleet learning

Runtime evidence becomes even more valuable when it’s aggregated across systems, products, lots, platforms, and field conditions. This is where fleet learning enters the picture.

Fleet learning becomes valuable when repeated runtime patterns appear across systems, lots, boards, packages, workloads, or field environments. A recurring SerDes retraining signature after thermal exposure may indicate a package, board, connector, or policy sensitivity.

A workload-specific droop pattern across a defined power domain may inform future PDN design or validation coverage. A degradation signature that appears after a thermal-cycle threshold may reshape future qualification assumptions.

But these patterns should not automatically rewrite firmware policy. Field data should not autonomously change system behavior, alter operating limits, or modify release criteria. Fleet learning recommends and bounded gate authority approves. This preserves the difference between learning and governing.

Physical state and bounded action handshake

The firmware–hardware handshake is becoming a necessary part of advanced system realization.

As AI silicon, chiplets, HBM platforms, high-speed interconnects, and advanced packages become more dynamic, design-time closure alone cannot cover every runtime state. Hardware must sense. Firmware must respond. But the response must remain bounded by evidence maturity, causality, synchronization, rollback limits, and lifecycle governance.

So, the future system will not be defined only by better telemetry or more autonomous firmware; it will also be defined by a disciplined handshake between physical state and bounded action.

In SEGA-AI terms:

• Observability provides signals
• Admissibility qualifies evidence
• Bounded firmware action preserves convergence
• Fleet learning refines the next lifecycle decision

The system does not remain trustworthy because it can sense everything. It remains trustworthy when it knows which signals are mature enough to act on.

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

Editor’s Note

This is Part 2 of the article series about silicon governance framework for AI silicon. Part 1 described why data movement alone cannot explain system behavior in modern AI chip designs.

Related Content

• UVM Reactive agents verify with a handshake
• Development tool evolution – hardware/firmware
• Hardware Root of Trust Essential for AI Chip Integrity
• What you need to know about firmware security in chips
• Hardware Verification: What AI Gets Right When It Generates Your Testbench

The post The firmware-hardware handshake in a silicon governance system appeared first on EDN.

Wolfspeed Inc of Durham, NC, USA — which makes silicon carbide (SiC) materials and power semiconductor devices — is expanding into the rapidly growing data-center market with the creation of a dedicated data-center solutions team and regional office in the San Francisco Bay Area. The new data-center solutions team is targeted at enabling closer alignment with leading hyperscalers, ODMs and the entire ecosystem to build differentiated products and solutions for AI and other data-center applications...

A new hardware-in-the-loop (HIL) testing framework claims to make automated, hardware-validated testing accessible to every team by offering engineering resources previously available only at large enterprises. This new testing framework—called BootLoop Test—unifies bench, continuous integration (CI), and end-of-line validation on a single platform.

Though HIL testing is one of the most valuable practices in the hardware world, it’s mostly adopted without any rigorous testing infrastructure. That’s because building a hardened HIL framework requires dedicated test engineers, months of custom development, and specialized skills that most firmware teams don’t have.

Consequently, many companies either forgo testing entirely or rely on ad hoc scripts and manual validation processes. That, in turn, slows development cycles, misses errors, and causes fragile release processes.

BootLoop, a startup that provides an AI platform for firmware and embedded development, addresses this problem by offering a complete HIL platform that spans the entire embedded product lifecycle. As a result, a hardware company can go from zero testing infrastructure to a fully automated pipeline in days.

“Most hardware companies know they need more rigorous firmware testing,” said Noah Pacik-Nelson, CEO of BootLoop. “They just don’t have the time or the tools. We built BootLoop Test, so they don’t have to choose between shipping quickly and shipping robust code.”

The HIL test platform helps teams to create a fully automated pipeline in days. Source: BootLoop

BootLoop’s agent ingests PCB design files and component datasheets to automatically generate tests that validate real hardware behavior down to the register level. The agent connects to serial monitors, debuggers, and test equipment to iterate until the code runs clean. So, test teams can go from zero testing infrastructure to a full CI pipeline on real hardware in hours by using a single command install.

BootLoop—a Y Combinator company founded by SpaceX and MIT Media Lab engineers—covers the entire embedded development lifecycle, including development, testing, and debugging. The company was founded in 2025 and is based in San Francisco.

Related Content

• HIL simulation boosts automotive design efficiency
• Firmware Testing Still Falls Short of What We Need
• Hardware-in-the-loop or digital twin: Use one, both, or neither?
• Accelerate Automotive Dev Time: Fill Hardware-in-the-Loop Gaps
• Hardware-in-the-loop testing for electric vehicle drive applications

The post HIL platform automates tests to validate hardware behavior appeared first on EDN.

Наставниця Ганна Шевлякова: "Вмотивовані учні надихають рухатися вперед" Інформація КП пн, 06/01/2026 - 18:00

Independent power electronics company Quantum Power Transformation (QPT) Ltd of Cambridge, UK — which was founded in 2019 and develops gallium nitride (GaN)-based electric motor controls — has opened customer demonstrations of its MicroDyno test platform, now updated with full field oriented control (FOC) and real-time dynamic cogging correction. The platform is available for in-person demos at QPT’s new R&D facility in Edinburgh, with remote-access demos available for international customers unable to travel...

BluGlass Ltd of Silverwater, Australia — which develops and manufactures gallium nitride (GaN) visible laser diodes based on its proprietary low-temperature, low-hydrogen remote-plasma chemical vapor deposition (RPCVD) technology — has secured a firm commitment of $1m, with the potential to be raised to $1.5m in total, following the execution of a shortall agreement in relation to options with an exercise price of $0.26 which expired on 31 May...

Macro shot taken using Fujifilm XH2 and Laowa 65mm F2.8. submitted by /u/Nightrach [link] [comments]

🎥 Круглий стіл «Механізм безпеки», присвячений механізованому розмінуванню в Україні kpi пн, 06/01/2026 - 15:18

Two devices. Same manufacturer. Similar cosmetics. (Near-)identical dimensions. Different branding. What about the insides?

After taking a month’s break from the TP-Link smart plug family teardown cadence, I’m back for more. This time, we’ll be looking inside the Tapo P105, one member of a four-pack, to be exact.

Back in early December, I’d noted that it was a “seeming Tapo equivalent to the Kasa EP10”, which I’d subsequently dissected for early March publication, and indeed there are many similarities between them:

• The Kasa EP10 has published dimensions of 2.36 x 1.50 x 1.21 in (60 x 38 x 33 mm), while those of the Tapo P105 are near-identical (in imperial units, that is, identical in metric): 2.4 × 1.5 × 1.3 in (60 × 38 × 33 mm)
• They both support switching load currents of up to 15 A
• And they both support Amazon (Alexa), Google (Assistant and Gemini) and Samsung (SmartThings) smart device protocols, in addition to company-proprietary schemes.

A smart plug by any other name…

The last bit of that last bullet, however, is indicative of a minor-at-least deviation between them. The earlier device was the Kasa EP10; this one’s the Tapo P105. Once again requoting my early December piece, appropriately titled “Tapo or Kasa: Which TP-Link ecosystem best suits ya?”:

“Kasa” was TP-Link’s original smart home device brand, predominantly marketed and sold in North America. The company, for reasons that remain unclear to me and others, subsequently, in parallel, rolled out another product line branded as “Tapo” across the rest of the world. Even today, if you visit the “smart plugs” product page on TP-Link’s website, you’ll see a mix of Kasa- and Tapo-branded products. The same goes for wall switches, light bulbs, cameras, and other TP-Link smart home devices. And historically, you needed to have both mobile apps installed to fully control a mixed-brand setup in your home.

Fortunately, TP-Link has made some notable improvements of late, from which I’m reading between the lines and deducing that a full transition to Tapo is the ultimate intended outcome. As I tested and confirmed for myself just a couple of days ago, it’s now possible to manage both legacy Kasa and newer Tapo devices using the same Tapo app; they also leverage a common TP-Link user account…They all remain visible to Alexa, too, and there’s a separate Tapo skill that can also be set up…along with, as with Kasa, support for other services.

A perusal of the outside cosmetics also reveals some differences. The Kasa EP10’s status LED is integrated within the left-side-located multi-function on/off, pairing and reset switch:

whereas the Tapo P105’s status LED is in the top-left corner of the front panel, with the left-side switch now non-illuminated:

…would switch as sweet?

The illumination locational variance between the two devices presumably results in at least some internal-layout deviance between them, but what about the building-block components themselves? Reiterating what I’ve asked before in similar teardown comparison projects, how different (if at all) are these two product generations from a hardware standpoint, versus TP-Link relying solely on software-only differentiation schemes? Let’s find out.

I’ll start with a conceptual internal view to whet your appetite:

As mentioned previously, today’s patient was sourced from a four-pack that I’d acquired during a 2025 Thanksgiving-week Amazon Warehouse-now-Renewed promotion for $18.06 ($25.80 minus 30%). I’ll start with some outer box shots, as usual accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes.

The “US/1.26” bit in the upper right corner of the product label in the following photo, based on my past experiences with TP-Link gear, is suggestive of hardware v1.26 inside the box. I’ve mentioned before both the company’s tendency for hardware-iteration profusion and the inter-version compatibility problems that can result from it. That said, the Tapo P105 product page on TP-Link’s website lists only hardware versions v1 and v1.2 (but not v1.26) for both the one- and four-pack bundle variants. Dive into the product support page, on the other hand, and four to-date hardware versions are listed there (none of them v1.2, ironically):

• v1
• v1.26 (mine)
• v1.60, and
• v1.80

So…

Onward…

Time to dive inside…

The first things I found were a piece of protective foam, a slip of quick-start literature (PDF), and a small sheet of clear plastic.

What I subsequently realized was that the latter was normally folded in thirds and wrapped around two of the smart plugs. Its sibling was still in place, thereby tipping me off that (at least) one of the two lower devices in the box was removed (and presumably tried out) pre-return by the original purchaser.

Let there (not) be blood

I went with the one in the lower left corner as my dissection victim. Front:

Left side (and upside-down, I subsequently realized):

Back (note the screw head; hold that thought):

Right side (once again upside-down, too):

Top:

And last but not least, the most informative of the lot, the bottom (the penny’s temporarily taped in place from underneath, in case you were wondering):

There’s that US/1.26 notation again, along with the always useful FCC ID (2AXJ4P105):

Remember that screw head I noted earlier? Buh-bye:

I’ve taken apart a few of these devices’ cases by now, so I’ve figured out how to do so without maiming myself like I did the first time (and yes, I realize I’ve just jinxed myself by writing this):

Mission accomplished.

SoC swap motivation: Processing necessity or product availability?

And now for the perspectives you all care about:

The switch, as noted before, is still on the left side:

but whereas with the Kasa EP10, it had been mounted to the same mini-PCB that contained the system SoC:

it’s now standalone, with the mini-PCB lodged in one corner, as already suggested by the earlier-shown conceptual teardown image and presumably to improve wireless connectivity:

The SoC itself is also evolved, from the Realtek RTL87210 to the same dual-core RTL8720 (PDF) found in the Kasa EP25, whose teardown was published in late March.

Note once again the presence of an antenna connector on the module, not used in this particular system implementation.

A relay merry-go-round

Once again on the right side is the blue-colored relay:

this time a Churod A16-V-105DA2F (PDF):

Top and bottom side perspectives follow, for your “edumacation” purposes:

And alas, as with its TP-Link-developed predecessors, I was unable to share with you any perspectives of the PCB backside, although as you might be able to tell from the glimpses in the following shots, there’s not much there to share anyway.

As usual, the FCC certification documentation provides additional visual insights.

And that’s “all” I’ve got for you today! Next up in the TP-Link smart plug dissection series, again as I initially alluded to back in December, I plan to tear down the Tapo P125, which builds on the Tapo P105 foundation with Apple HomeKit (now Apple Home) “smart” support. It’s akin to the earlier Kasa EP10-to-EP25 transition, albeit absent added energy monitoring features this time. Until then, and 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

• 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 P105: A Kasa EP10 clone, or evolutionarily derived? appeared first on EDN.