Feed aggregator

The complexity of vehicle hardware and software is rising at an unprecedented rate, so traditional development methodologies are no longer sufficient to manage system-level interdependencies among advanced driver assistance systems (ADAS), autonomous driving (AD), and in-vehicle infotainment (IVI) functions.

That calls for a new approach, the one that enables automotive OEMs and tier 1s to speed the development of software-defined vehicles (SDVs) with early full-system, virtual integration that mirrors real-world vehicle hardware. That will accelerate both application and low-level software development for ADAS, AD, and IVI and remove the need for design engineers to build their own digital twins before testing software.

It will also reduce time-to-market for critical applications from months to days. Siemens EDA has unveiled what it calls a virtual blueprint for digital twin development. PAVE360 Automotive, a digital twin software, is pre-integrated as an off-the-shelf offering to address the escalating complexity of automotive hardware and software integration.

While system-level digital twins for SDVs using existing technologies can be complex and time-consuming to create and validate, PAVE360 Automotive aims to deliver a fully integrated, system-level digital twin that can be deployed on day one. That reduces the time, effort, and cost required to build such environments from scratch.

Figure 1 PAVE360 Automotive is a cloud-based digital twin that accelerates system-level development for ADAS, autonomous driving, and infotainment. Source: Siemens EDA

“The automotive industry is at the forefront of the software-defined everything revolution, and Siemens is delivering the digital twin technologies needed to move beyond incremental innovation and embrace a holistic, software-defined approach to product development,” said Tony Hemmelgarn, president and CEO, Siemens Digital Industries Software.

Siemens EDA’s digital twin—a cloud-based off-the-shelf offering—allows design engineers to jumpstart vehicle systems development from the earliest phases with customizable virtual reference designs for ADAS, autonomous driving, and infotainment. Moreover, the cloud-based collaboration unifies development with a single digital twin for all design teams.

The Arm connection

Earlier, Siemens EDA joined hands with Arm to accelerate virtual environments for Arm Cortex-A720AE in 2024 and Arm Zena Compute Subsystems (CSS) in 2025. Now Siemens EDA is integrating Arm Zena CSS with PAVE360 Automotive to enable design engineers to start building on Arm-based designs faster and more seamlessly.

Figure 2 Here is how PAVE360’s digital twin works alongside the Arm Zena CSS platform for AI-defined vehicles. Source: Siemens EDA

On the other hand, access to Arm Zena CSS in a digital twin environment such as PAVE360 Automotive can accelerate software development by up to two years. “With Arm Zena CSS available inside Siemens’ pre-integrated PAVE360 Automotive environment, partners can not only customize their solutions leveraging the unique flexibility of the Arm architecture but also validate and iterate much earlier in the development cycle,” said Suraj Gajendra, VP of products and solutions for Physical AI Business Unit at Arm.

PAVE360 Automotive, now made available to key customers, is planned for general availability in February 2026. It will be demonstrated live at CES 2026 in the Auto Hall on 6–9 January 2026.

Related Content

• Why the Cloud Is Essential for SDV Development
• Unveiling the Transformation of Software-Defined Vehicles
• Software-defined vehicle (SDV): A technology to watch in 2025
• Architectural opportunities propel software-defined vehicles forward
• Digital Twins Power Rapid Software Deployment in Autonomous Vehicles

The post An off-the-shelf digital twin for software-defined vehicles appeared first on EDN.

In this Design Idea (DI), the classic Schmitt-trigger-based RC oscillator is “hacked” and analyzed using the simulation software QSPICE. You might reasonably ask why one would do this, given that countless such circuits reliably and unobtrusively clock away all over the world, even in space.

Well, problems arise when you want the RC oscillator to be tunable, i.e., replacing the resistor with a potentiometer. Unfortunately, the frequency is inversely proportional to the RC time constant, resulting in a hyperbolic response curve.

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

Another drawback is the limited tuning range. For high frequencies, R can become so small that the Schmitt trigger’s output voltage sags unacceptably.

The oscillator’s current consumption also increases as the potentiometer resistance decreases. In practice, an additional resistor ≥1 kΩ must always be placed in series with the potentiometer.

The potentiometer’s maximum value determines the minimum frequency. For values >100 kΩ, jitter problems can occur due to hum interference when operating the potentiometer, unless a shielded enclosure is used.

RC oscillator

Figure 1 shows an RC oscillator modeled with QSPICE’s built-in behavioral Schmitt trigger. It is parameterized as a TLC555 (CMOS 555) regarding switching thresholds and load behavior.

Figure 1: An RC oscillator modeled with QSPICE’s built-in behavioral Schmitt trigger, it is a TLC555 (CMOS 555).

Figure 2 displays the typical triangle wave input and the square wave output. At R1=1 kΩ, the output voltage sag is already noticeable, and the average power dissipation of R1 is around 6 mW, roughly an order of magnitude higher than the dissipation of a low-power CMOS 555.

Figure 2 The typical triangle wave input and the square wave output, where the average power dissipation of R1 is around 6 mW.

Frequency response wrt potentiometer resistance

Next, we examine the oscillator’s frequency response as a function of the potentiometer resistance. R1 is simulated in 100 steps from 1 kΩ to 100 kΩ using the .step param command.

The simulation time must be long enough to capture at least one full period even at the lowest frequency; otherwise, the period duration cannot be measured with the .meas command.

However, with a 3-decade tuning range, far too many periods would be simulated at high frequencies, making the simulation run for a very long time.

Fortunately, QSPICE has a new feature that allows a running simulation to be aborted, after which the new simulation for the next parameter step is executed. The abort criterion is a behavioral voltage source called AbortSim(). It’s not the most elegant or intuitive feature, but it works.

Schmitt trigger oscillator

Figure 3 shows our Schmitt trigger oscillator, but this time with the parameter stepping of R1, the .meas commands for period and frequency measurement, and an auxiliary circuit that triggers AbortSim(). My idea was to build a counter clocked by the oscillator. After a small number of clock pulses—enough for one period measurement—the simulation is aborted.

Figure 3 Schmitt trigger oscillator, this time, with the parameter stepping of R1, the .meas commands for period and frequency measurement, and an auxiliary circuit that triggers AbortSim().

I first tried a 3-stage ripple counter with behavioral D-flops. This worked but wasn’t optimal in terms of computation time.

The step voltage generator in the box in Figure 2 is faster and easier to adjust. A 10-ns monostable is triggered by V(out) of the oscillator and sends short current pulses via the voltage-controlled current source to capacitor C3. The voltage across C3 triggers AbortSim() at >= 0.5V.

The constant current and C3 are selected so that the 0.5 V threshold is reached after 3 clock cycles of the oscillator, thus starting the next measurement.

Note that the simulation time in the .tran command is set to 5 s, which is never reached due to AbortSim().

The entire QSPICE simulation of the frequency response takes the author’s PC a spectacular 1.5 s, whereas previously with LTSPICE (without the abort criterion) it took many minutes.

Figure 4 shows the frequency (FREQ) versus potentiometer resistance (RPOT) curve in a log plot, interpolated over 100 measurement points.

Figure 4 Frequency versus potentiometer resistance curve in a log plot, interpolated over 100 measurement points.

Final circuit hack

Now that we have the simulation tools for fast frequency measurement, we finally get to the circuit hack in Figure 5. We expand the circuit in Figure 1 with a resistor R2=RPOT in series with C1.

Figure 5 Hacked Schmitt trigger oscillator with an expanded Figure 1 circuit that includes R2=RPOT in series with C1.

Figure 6 illustrates what happens: for R2=0 (blue trace), we see the familiar triangle wave. When R2 is increased (magenta trace), a voltage divider:

V(out)/V(R2) = (R1+R2)/R1

is created if we momentarily ignore V(C1). V(R2) is thus a scaled-down V(out) square wave signal, to which the V(C1) triangle wave voltage is now added.

Figure 6 The typical triangle wave input with the output now reaching very high frequencies without excessively loading V(OUT).

Because the upper and lower switching thresholds of the Schmitt trigger are constant, V(C1) reaches these thresholds faster as V(R2) increases. The more V(R2) approaches the Schmitt trigger hysteresis VHYST, the smaller the V(C1) triangle wave becomes, and the frequency increases.

At V(R2)=VHYST, the frequency would theoretically become infinite. This condition in the original circuit in Figure 1 would mean R1=0, leading to infinitely high I(out). The circuit hack thus allows very high frequencies without excessively loading V(OUT)!

The problem of the steep frequency rise towards infinity at the “end” of the potentiometer still remains. To fix this, we would need a potentiometer that changes its value significantly at the beginning of its range and only slightly at the end. This is easily achieved by wiring a much smaller resistor in parallel with the potentiometer.

Fixing steep frequency rise

In Figure 7, we see a second hack: R1 has been given a very large value.

Figure 7 Giving R1 a large value keeps the circuit’s current consumption low, allowing RPOT to be dimensioned independently of R1.

This keeps the circuit’s current consumption low, especially at high frequencies. The square wave voltage at RPOT is now taken directly from V(OUT) via a separate voltage divider. This allows RPOT to be dimensioned independently of R1.

In the example, I used a common 100 kΩ potentiometer. The remaining resistors are effectively in parallel with the potentiometer regarding AC signals and set the desired characteristic curve.

Despite all measures, the frequency increase is still quite steep at the end of the range, so a 1 kΩ trimmer is recommended for practical application to conveniently set the maximum frequency.

Figure 8 shows the frequency curve of the final circuit. Compared to the curve of the original circuit in Figure 4, a significantly flatter curve profile is evident, along with a larger tuning range.

Figure 8 Frequency versus potentiometer resistance curve in a log plot, interpolated over 100 measurement points, showing a flatter curve profile and larger tuning range.

Uwe Schüler is a retired electronics engineer. When he’s not busy with his grandchildren, he enjoys experimenting with DIY music electronics.

 Related Content

• Exponentially-controlled vactrols
• Schmitt trigger adapts its own thresholds
• Schmitt trigger provides alternative to 555 timer
• Schmitt trigger uses two transistors
• RC oscillator generates linear triangle wave

The post Wide-range tunable RC Schmitt trigger oscillator appeared first on EDN.

“We are more interested in driving the power electronics ecosystem in the Indian market,” says Hitesh Bhardwaj, GM, Semiconductor & Devices Department, Mitsubishi Electric India, in an exclusive conversation with the ELE Times. As India doubles down on its electronics sector through various schemes, including ECMS, PLI, and DLI, the private sector, along with the government, also seems equally aspirational and positive about the Indian prospects in the electronics landscape.

In the conversation, he, along with Dr. Koichiro Noguchi, General Manager, Product Strategy Dept. Mitsubishi Electric Corporation Power Device Works touched upon some innovations that Mitsubishi Electric is launching in India, including Unifull (SBD embedded MOSFETs). In addition to the innovations, the conversation also touched upon other issues like overall material trends in the power electronics line-up and supporting the local talent.

New Dual Inline Package Intelligent Power Modules (DIPIPM)

“The key feature of compact DIPIPM is that it is 53% smaller than the Slim DIP, which is a previous generation device that we were selling in the Indian market,” says Hitesh Bharadwaj. Mitsubishi’s all-new DIPIPM platform is all set to make the design engineers in India target next-level and more compact designs, owing to its unique construction consisting of an RC-IGBT that makes it more resilient towards thermal challenges and, consequently, improves its overall performance.

The new DIPIPM comes in two ratings: 30 amp 600 volt and 50 amp 600 volt, which make it suitable for consumer appliances, industrial equipment, and small-capacity inverters.

Unifull- New SiC high Voltage Product

“It is a unique solution in the segment of the SiC high voltage product where we architect a Schottky barrier diode and MOSFET into a single chip,” says Koichiro Noguchi as he explains the USP of the Unifull. It improves the switching and DC performance highly. He adds that this innovation in the 3.3 Kilowatt & 200-600 Amp range is the industry’s first.

Also, Mitsubishi Electric is confident of its Unifull technology, also evidenced by Koichiro Noguchi’s words when he says, “We are ready for the new business” with the all-new Unifull.

Material Trends in Power Electronics

On material trends, Hitesh Bhardwaj points out that while innovation is advancing, the industry must first capitalise on the already available WBG devices such as SiC and GaN, along with emerging 2D materials like graphene (which today sees limited use in specialised areas). Looking ahead, he notes that the next decade may open the door to ultra-wide bandgap materials, with several oxide- and nitride-based devices showing promising results in the research and development phase.

“We should give at least 10 to 12 years for WBG devices, just the way silicon was given decades to mature,” he says, underlining the natural progression of material technologies. He also mentions ongoing experiments on materials like gallium oxide and recalls Mitsubishi Electric’s earlier work with gallium arsenide for low-power, space-grade applications.

Power Electronic Ecosystem in India

Moving further, Hitesh Bhardwaj also talks about the India Power Electronics System, wherein he says, “Our priority is to develop the power electronics ecosystem in India.” He further goes on to underline the ongoing contributions of Mitsubishi Electric, specifically in regard to the training and upskilling of the local talent. He further adds that Mitsubishi Electric is currently focusing on developing the capabilities and sharing their best global practices with the local engineers, with the local design centers, and consequently making them drive benefits out of it.

Hence, enabling a self-sufficient and skilled power electronics ecosystem in India. It is currently in collaboration with universities and institutions, including IITs, NITs, so that they can contribute on their own, by using Mitsubishi’s devices.

The post “Being 53% smaller than the previous model, the new Compact DIPIPM helps engineers push PCB miniaturisation and efficiency to the next level,” says Mitsubishi Electric’s Hitesh Bharadwaj appeared first on ELE Times.

The Central Government expects the modified Electronics Manufacturing Clusters (EMC 2.0) scheme to generate approximately 1.80 lakh jobs. The approved projects cover 10 Indian states and are expected to have a total investment of Rs. 1.46 lakh crore, which will make the country’s electronics manufacturing system robust and efficient.

According to an old government notification, the scheme aims to provide world-class infrastructure support to specific clusters with shared facilities. These facilities will be provided with a ready-to-start setup to prevent wasting time by starting from scratch.

As of now, the government has approved 11 electronics manufacturing clusters along with 2 common facility centres. These projects cover nearly 4,400 acres of land, with a total cost of Rs. 5.226.49 crores, out of which the Central Government is providing financial assistance worth Rs. 2,492.74 crores.

The Ministry of Electronics and IT reports that 123 manufacturers are committed to investing a total of Rs. 1,13,000 crore in the approved areas for the projects.

An independent study by the National Institute for Micro, Small and Medium Enterprises recently assessed the impact of the scheme. The study found that the clusters help develop better supply chains and lower the cost of moving goods. The assessment also noted that the program improves skill development and creates many direct and indirect jobs within the local ecosystem.

“The assessment highlights accelerated development of electronics manufacturing infrastructure, improved supply-chain responsiveness, availability of RBF/Plug-and-Play facilities, cost-efficient logistics, and significant direct and indirect employment generation, along with enhanced skill development within the cluster ecosystem,” the release said.

The post India’s EMC 2.0 Proves to be Efficient for Supply Chains & Skill Development appeared first on ELE Times.

Диджиталізація промислових МСП — Hack & Match kpi чт, 12/18/2025 - 12:22

Fabless firm Cambridge GaN Devices Ltd (CGD) — which was spun out of the University of Cambridge in 2016 to design, develop and commercialize power transistors and ICs that use GaN-on-silicon substrates — has been named as one of the winners of Hyundai’s Open Innovation Challenge on the future of sporty driving. Out of nearly 50 companies, CGD’s one-chip ICeGaN solution has been selected for its robustness and ease of use, showing high potential for utilization in power modules for EV traction inverters. This technology enables GaN to be considered as a cost-effective alternative to expensive silicon carbide (SiC) solutions in the high-power EV inverter market, says CGD...

One of 4 Automated PCBA test fixtures I have just completed, entire design is from scratch and pretty much everything you see is 3D printed or Laser Cut! I have 2x PCBAs inside, lots of wires and an additional switching PSU with Dummy load to simulate a battery for the UUT! submitted by /u/Future_Ball_9094 [link] [comments]

Hello, this is a radiophone project I'm working on while in my second year of ECE. I came up with this new design this time on 4 layers as impedances are really smaller. First part of the circuit (bottom left) is an LC that will tune close to 1Mhz using an old-school variable capacitor. On next the signal gets demodulated, amplified, given power and outputted (bottom middle) and the rest is a simple power rectifier, with an IC for a cool volume bar using LEDs Pics are in order of layers, I used GND/SIGNAL - GND - POWER / SIGNAL - GND, and keepout zone below the transformer in order to remove capacitive noise. Schematics Layer 1 gnd/signal Layer 2 GND Layer 3 power/signal Layer 4 gnd submitted by /u/S4vDs [link] [comments]

This is a small laser module built utilizing a laser diode recovered from a DVD burner. The power supply is based on a ST Microelectronics LM317T adjustable voltage regulator set up in a constant current configuration. Picture 3 is the output next to a ~5mw laser pointer output. don't think my phone camera liked taking this picture. Schematic included. submitted by /u/AwesomeAvocado [link] [comments]

Why the F did they decide to. No, no lissen, we need 36 different pinouts on the same ic with no id code on it either making it impossible to know wich "style" ic you got. Now that's what we need. Looking for help to identify GDS on the nmos somehow cuircit or instrument no problem. submitted by /u/Whyjustwhydothat [link] [comments]

I recently assembled a rosco_m68k tht kit version. Took around 4 hours, tried to keep everything as clean and careful as possible. Ironically, I’m also working on my own soldering-related project called SolderDemon, so this failure was a good reminder that even clean work can hide stupid problems. After powering it on, the board wouldn’t boot. Only the START and RESET LEDs were on. Measuring the CPU RESET pin showed ~2V, which made no sense. First suspect was the RESET button, I desoldered it completely. No change. While reflashing the PLD, I finally noticed the real issue: one of the IC sockets had a bad pin. The chip looked seated properly, but that pin wasn’t making contact at all. I fixed the contact temporarily just to test it and the system booted immediately. Lesson learned: don’t just inspect solder joints. Check IC socket pins too. Even when the board looks clean, a single bad contact can make a system look completely dead. submitted by /u/kynis45 [link] [comments]

submitted by /u/Green-Pie4963 [link] [comments]

NUBURU Inc of Centennial, CO, USA — which was founded in 2015 and developed and previously manufactured high-power industrial blue lasers — has entered into a securities purchase agreement with YA II PN Ltd pursuant to which it will receive a gross cash infusion of $23.25m in exchange for the issuance of a $25m unsecured debenture and related warrant packages...

For some time now, many of EDN’s Design Ideas (DIs) have dealt with ground-referenced, single-power-supplied voltage regulators whose outputs can be configured to produce zero or near-zero volts [1][2].

In this mode of operation, regulation in response to an AC signal is problematic. This is because the regulator output voltage can’t be more negative than zero. For the many regulators with totem pole outputs, at zero volts, we could hope for the ground-side MOSFET to be indefinitely enabled, and the high side disabled. But that’s not a regulator, it’s a switch.

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

There might be some devices that act this way when asked to produce 0 volts, but in general, the best that could be hoped for is that the output is simply disabled. In such a case, a load that is solely an energy sink would pull the voltage to ground (woe unto any that are energy sources!).

But is it lollipops and butterflies all the way down to and including zero volts? I decided to test one regulator to see how it behaves.

Testing the regulator

A TPS54821EVM-049 evaluation module employs a TPS54821 buck regulator. I’ve configured its PCB for 6.3-V out and connected it to an 8-Ω load. I’ve also connected a function generator through a 22 kΩ resistor to the regulator’s V_SNS (feedback) pin.

The generator is set to produce a 360 mVp-p square wave across the load. It also provides a variable offset voltage, which is used to set the minimum voltage Vmin of the regulator output’s square-wave. Figure 1 contains several screenshots of regulator operation while it’s configured for various values of Vmin.

Figure 1 Oscilloscope screenshot with Vmin set to (a) 400 mV, (b) 300 mV, (c) 200 mV, (d) 100 mV, (e) 30 mV, (f) 0 mV, (g)  below 0 mV. See text for further discussion. The scales of each screenshot are 100mV and 1mS per large division. An exception is (g), whose timescale is 100µS per large division.

As can be seen, the output is relatively clean when Vmin is 400 mV, but gets progressively noisier as it is reduced in 100mV steps down to 100mV (Figures 1a – 1d).

But the real problems start when Vmin is set to about 30 mV and some kind of AC signal replaces what would preferably be a DC one; the regulator is switching between open and closed-loop operation (Figure 1e).  

We really get into the swing of things when Vmin is set to 0 mV and intermittent signals of about 150 mVp-p arise and disappear (Figure 1f). As the generator continues to be changed in the direction that would drive the regulator output more negative if it were capable, the amplitude of the regulator’s ringing immediately following the waveform’s falling edge increases (Figure 1g). Additionally, the overshoot of its recovery increases.

Why isn’t it on the datasheet?

This behavior might or might not disturb you. But it exists. And there are no guarantees that things would not be worse with different lots of TPS54821 or other switcher or linear regulator types altogether. These could be operating with different loads, feedback networks, and input voltage supplies with varying DC levels and amounts of noise.

There might be a very good reason that typical datasheets don’t discuss operation with output voltages below their references—it might not be possible to specify an output voltage below which all is guaranteed to work as desired. Or maybe it is.

But if it is, then why aren’t such capabilities mentioned? Where is there an IC manufacturer’s datasheet whose first page does not promise to kiss you and offer you a chocolate before you go to bed? (That is, list every possible feature of a product to induce you to buy it.)

Finding the lowest guaranteed output level

Consider a design whose intent is to allow a regulator to produce a voltage near or at zero. Absent any help from the regulator’s datasheet, I’m not sure I’d know how to go about finding a guaranteed output level below which bad things couldn’t happen.

But suppose this could be done. The “Gold-Plated” [1] DI was updated under this assumption. It provides a link to a spreadsheet that accepts the regulator reference voltage and its tolerance, a minimum allowed output voltage, a desired maximum one, and the tolerance of the resistors to be used in the circuit.

It calculates standard E96 resistor values of a specified precision along with the limits of both the maximum and the minimum output voltage ranges [3].  

“Standard” regulator results

A similar spreadsheet has been created for the more general “standard” regulator circuit in Figure 2. That latter can be found at [4].

Figure 2 The “standard” regulator in which a reference voltage Vext, independent of the regulator, is used in conjunction with Rg2 to drive the regulator output to voltages below its reference voltage. For linear regulators, L1 is replaced with a short.

The spreadsheet [4] was run with the following requirements in Figure 3.

Figure 3 Sample input requirements for the spreadsheet to calculate the resistor values and minimum and maximum output voltage range limits for a Standard regulator design.

The spreadsheet’s calculated voltage limits are shown in Figure 4.

Figure 4 Spreadsheet calculations of the minimum and maximum output voltage range limits for the requirements of Figure 3.

A Monte Carlo simulation was run 10000 times. The limits were confirmed to be close to and within the calculated ones (Figure 5).

Figure 5 Monte Carlo simulation results confirming the limits were consistent with the calculated ones.

A visual of the Monte Carlo results is helpful (Figure 6).

Figure 6 A graph of the Monte Carlo minimum output voltage range and the maximum one for the standard regulator. See text.

The minimum range is larger than the maximum range. This is because two large signals with tolerances are being subtracted to produce relatively small ones. The signals’ nominal values interfere destructively as intended. Unfortunately, the variations due to the tolerances of the two references do not:

OUT = Vref · ( 1 + Rf/Rg1 + Rf/Rg2 ) – Vext · PWM · Rf/Rg2

“Gold-Plated” regulator results

When I released the “Gold-Plated” DI whose basic concept is seen in Figure 7, I did so as a lark. But after applying the aforementioned “standard” regulator’s design criteria to the Gold-Plated design’s spreadsheet [3], it became apparent that the Gold-Plated design has a real value—its ability to more greatly constrain the limits of the minimum output voltage range.

Figure 7 The basic concept of the Gold-Plated regulator. K = 1 + R3/R4 .

The input to the Gold-Plated spreadsheet is shown in Figure 8.

Figure 8 The inputs to the Gold-Plated spreadsheet.

Its calculations of the minimum and maximum output voltage range limits are shown in Figure 9.

Figure 9 The results for the “Gold-Plated” spreadsheet showing maximum and minimum voltage range limits when PWM inputs are at minimum and maximum duty cycles.

The limits resulting from its 10000 run Monte Carlo simulation were again confirmed to be close to and within those calculated by the spreadsheet:

Figure 10 Monte Carlo simulation results of the Gold-Plated spreadsheet, confirming the limits were consistent with the calculated ones.

Again, a visual is helpful, with the Gold-Plated results on the left and the Standard on the right.

 Figure 11 Graphs of the Monte Carlo simulation results of the Gold-Plated (left) and Standard (right) designs. The minimum voltage range of the Gold-Plated design is far smaller than that of the Standard.

The Standard regulator’s minimum range magnitude is 161 mV, while that of the Gold-Plated version is only 33 mV. The Gold-Plated’s advantage will increase as the desired Vmin approaches 0 volts. Its benefits are due to the fact that only a single reference is involved in the subtraction of terms:

OUT = Vref · ( 1 + Rf/Rg1 + Rf/Rg2 · PWM · ( 1 – K ) )

Belatedly, another advantage of the Gold-Plated was discovered: When a load is applied to any regulator, its output voltage falls by a small amount, causing a reduction of ΔV at the Vref feedback pin.

In the Gold-Plated, there is an even larger reduction at the output of its op-amp because of its gain. The result is a reduced drop across Rg2. This acts to increase the output voltage, improving load regulation.

In contrast, while the Standard regulator also sees a ΔV drop at the feedback pin, the external regulator voltage remains steady. The result is an increase in the drop across Rg2, further reducing the output voltage and degrading load regulation.

Summing up

The benefits of the Gold-Plated design are clear, but it’s not a panacea. Whether a Gold-Plated or  Standard design is used, designers still must address the question: How low should you go? Caveat, designer!

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

Related Content/References

1. Gold-Plated PWM-control of linear and switching regulators
2. Accuracy loss from PWM sub-Vsense regulator programming
3. Gold-Plated DI Github
4. Enabling a variable output regulator to produce 0 volts DI Github

The post Enabling a variable output regulator to produce 0 volts? Caveat, designer! appeared first on EDN.

RENA Technologies GmbH of Gütenbach, Germany (which supplies production machines for wet chemical surface preparation) is a key industrial partner in a new €1.3m (£1.2m) Government-funded project led by the National Physical Laboratory (NPL) – the UK’s National Metrology Institute (NMI) – and supported by the Department for Science, Innovation and Technology (DSIT). The initiative aims to establish critical new metrology capabilities to strengthen the UK’s semiconductor innovation infrastructure and accelerate the development and adoption of next-generation semiconductor materials and processes...

Walk into any modern AI lab, data center, or autonomous vehicle development environment, and you’ll hear engineers talk endlessly about FLOPS, TOPS, sparsity, quantization, and model scaling laws. Those metrics dominate headlines and product datasheets. If you spend time with the people actually building or optimizing these systems, a different truth emerges: Raw arithmetic capability is not what governs real-world performance.

What matters most is how efficiently data moves. And for most of today’s AI accelerators, data movement is tangled up with something rarely discussed outside compiler and hardware circles, that is, memory swizzling.

Memory swizzling is one of the biggest unseen taxes paid by modern AI systems. It doesn’t enhance algorithmic processing efficiency. It doesn’t improve accuracy. It doesn’t lower energy consumption. It doesn’t produce any new insight. Rather, it exists solely to compensate for architectural limitations inherited from decades-old design choices. And as AI models grow larger and more irregular, the cost of this tax is growing.

This article looks at why swizzling exists, how we got here, what it costs us, and how a fundamentally different architectural philosophy, specifically, a register-centric model, removes the need for swizzling entirely.

The problem nobody talks about: Data isn’t stored the way hardware needs it

In any AI tutorial, tensors are presented as ordered mathematical objects that sit neatly in memory in perfect layouts. These layouts are intuitive for programmers, and they fit nicely into high-level frameworks like PyTorch or TensorFlow.

The hardware doesn’t see the world this way.

Modern accelerators—GPUs, TPUs, and NPUs—are built around parallel compute units that expect specific shapes of data: tiles of fixed size, strict alignment boundaries, sequences with predictable stride patterns, and arranged in ways that map into memory banks without conflicts.

Unfortunately, real-world tensors never arrive in those formats. Before the processing even begins, data must be reshaped, re-tiled, re-ordered, or re-packed into the format the hardware expects. That reshaping is called memory swizzling.

You may think of it this way: The algorithm thinks in terms of matrices and tensors; the computing hardware thinks in terms of tiles, lanes, and banks. Swizzling is the translation layer—a translation that costs time and energy.

Why hierarchical memory forces us to swizzle

Virtually, every accelerator today uses a hierarchical memory stack whose layers, from the top-down, encompass registers; shared or scratchpad memory; L1 cache, L2 cache, sometimes even L3 cache, high-bandwidth memory (HBM), and, at the bottom of the stack, the external dynamic random-access memory (DRAM).

Each level has different size, latency, bandwidth, access energy consumption, and, rather important, alignment constraints. This is a legacy of CPU-style architecture where caches hide memory latency. See Figure 1 and Table 1.

Figure 1 See the capacity and bandwidth attributes of a typical hierarchical memory stack in all current hardware processors. Source: VSORA

Table 1 Capacity, latency, bandwidth, and access energy dissipation of a typical hierarchical memory stack in all current hardware processors are shown here. Source: VSORA

GPUs inherited this model, then added single-instruction multiple-thread (SIMT) execution on top. That makes them phenomenally powerful—but also extremely sensitive to how data is laid out. If neighboring threads in a warp don’t access neighboring memory locations, performance drops dramatically. If tile boundaries don’t line up, tensor cores stall. If shared memory bank conflicts occur, everything waits.

TPUs suffer from similar constraints, just with different mechanics. Their systolic arrays operate like tightly choreographed conveyor belts. Data must arrive in the right order and at the right time. If weights are not arranged in block-major format, the systolic fabric can’t operate efficiently.

NPUs-based accelerators—from smartphone chips to automotive systems—face the same issues: multi-bank SRAMs, fixed vector widths, and 2D locality requirements for vision workloads. Without swizzling, data arrives “misaligned” for the compute engine, and performance nosedives.

In all these cases, swizzling is not an optimization—it’s a survival mechanism.

The hidden costs of swizzling

Swizzling takes time, sometimes a lot

In real workloads, swizzling often consumes 20–60% of the total runtime. That’s not a typo. In a convolutional neural network, half the time may be spent doing NHWC NCHW conversions; that is, two different ways of laying out 4D tensors in memory. In a transformer, vast amounts of time are wasted into reshaping Q/K/V tensors, splitting heads, repacking tiles for GEMMs, and reorganizing outputs.

Swizzling burns energy and energy is the real limiter

A single MAC consumes roughly a quarter of a picojoule. Moving a value from DRAM can cost 500 picojoules. Moving data from a DRAM dissipates in the ballpark of 1,000 times more energy than performing a basic multiply-accumulate operation.

Swizzling requires reading large blocks of data, rearranging them, and writing them back. And this often happens multiple times per layer. When 80% of your energy budget goes to moving data rather than computing on it, swizzling becomes impossible to ignore.

Swizzling inflates memory usage

Most swizzling requires temporary buffers: packed tiles, staging buffers, and reshaped tensors. These extra memory footprints can push models over the limits of L2, L3, or even HBM, forcing even more data movement.

Swizzling makes software harder and less portable

Ask a CUDA engineer what keeps him up at night. Ask a TPU compiler engineer why XLA is thousands of pages deep in layout inference code. Ask anyone who writes an NPU kernel for mobile why they dread channel permutations.

It’s swizzling. The software must carry enormous complexity because the hardware demands very specific layouts. And every new model architecture—CNNs, LSTMs, transformers, and diffusion models—adds new layout patterns that must be supported.

The result is an ecosystem glued together by layout heuristics, tensor transformations, and performance-sensitive memory choreography.

How major architectures became dependent on swizzling

1. Nvidia GPUs

Tensor cores require specific tile-major layouts. Shared memory is banked, avoiding conflicts requires swizzling. Warps must coalesce memory accesses; otherwise, efficiency tanks. Even cuBLAS and cuDNN, the most optimized GPU libraries on Earth, are filled with internal swizzling kernels.

2. Google TPUs

TPUs rely on systolic arrays. The flow of data through these arrays must be perfectly ordered. Weights and activations are constantly rearranged to align with the systolic fabric. Much of XLA exists simply to manage data layout.

3. AMD CDNA, ARM Ethos, Apple ANE, and Qualcomm AI engine

Every one of these architectures performs swizzling. Morton tiling, interleaving, channel stacking, etc. It’s a universal pattern. Every architecture that uses hierarchical memory inherits the need for swizzling.

A different philosophy: Eliminating swizzling at the root

Now imagine stepping back and rethinking AI hardware from first principles. Instead of accepting today’s complex memory hierarchies as unavoidable—the layers of caches, shared-memory blocks, banked SRAMs, and alignment rules—imagine an architecture built on a far simpler premise.

What if there were no memory hierarchy at all? What if, instead, the entire system revolved around a vast, flat expanse of registers? What if the compiler, not the hardware, orchestrated every data movement with deterministic precision? And what if all the usual anxieties—alignment, bank conflicts, tiling strategies, and coalescing rules—simply disappeared because they no longer mattered?

This is the philosophy behind a register-centric architecture. Rather than pushing data up and down a ladder of memory levels, data simply resides in the registers where computation occurs. The architecture is organized not around the movement of data, but around its availability.

That means:

• No caches to warm up or miss
• No warps to schedule
• No bank conflicts to avoid
• No tile sizes to match
• No tensor layouts to respect
• No sensitivity to shapes or strides, and therefore no swizzling at all

In such a system, the compiler always knows exactly where each value lives, and exactly where it needs to be next. It doesn’t speculate, prefetch, tile, or rely on heuristics. It doesn’t cross its fingers hoping the hardware behaves. Instead, data placement becomes a solvable, predictable problem.

The result is a machine where throughput remains stable, latency becomes predictable, and energy consumption collapses because unnecessary data motion has been engineered out of the loop. It’s a system where performance is no longer dominated by memory gymnastics—and where computing, the actual math, finally takes center stage.

The future of AI: Why a register-centric architecture matters

As AI systems evolve, the tidy world of uniform tensors and perfectly rectangular compute tiles are steadily falling away. Modern models are no longer predictable stacks of dense layers marching in lockstep. Instead, they expand in every direction: They ingest multimodal inputs, incorporate sparse and irregular structures, reason adaptively, and operate across ever-longer sequences. They must also respond in real time for safety-critical applications, and they must do so within tight energy budgets—from cars to edge devices.

In other words, the assumptions that shaped GPU and TPU architectures—the expectation of regularity, dense grids, and neat tiling—are eroding. The future workloads are simply not shaped the way the hardware wants them to be.

A register-centric architecture offers a fundamentally different path. Because it operates directly on data where it lives, rather than forcing that data into tile-friendly formats, it sidesteps the entire machinery of memory swizzling. It does not depend on fixed tensor shapes.

It doesn’t stumble when access patterns become irregular or dynamic. It avoids the costly dance of rearranging data just to satisfy the compute units. And as models grow more heterogeneous and more sophisticated, such an architecture scale with their complexity instead of fighting against it.

This is more than an incremental improvement. It represents a shift in how we think about AI compute. By eliminating unnecessary data movement—the single largest bottleneck and energy sink in modern accelerators—a register-centric approach aligns hardware with the messy, evolving reality of AI itself.

Memory swizzling is the quiet tax that every hierarchical-memory accelerator pays. It is fundamental to how GPUs, TPUs, NPUs, and nearly all AI chips operate. It’s also a growing liability. Swizzling introduces latency, burns energy, bloats memory usage, and complicates software—all while contributing nothing to the actual math.

One register-centric architecture eliminates swizzling at the root by removing the hierarchy that makes it necessary. It replaces guesswork and heuristics with deterministic dataflow. It prioritizes locality without requiring rearrangement. It lets the algorithm drive the hardware, not vice versa.

As AI workloads become more irregular, dynamic, and power-sensitive, architectures that keep data stationary and predictable—rather than endlessly reshuffling it—will define the next generation of compute.

Swizzling was a necessary patch for the last era of hardware. It should not define the next one.

Lauro Rizzatti is a business advisor to VSORA, a technology company offering silicon semiconductor solutions that redefine performance. He is a noted chip design verification consultant and industry expert on hardware emulation.

 

Related Content

• Overcoming the AI memory bottleneck
• AI to Drive Surge in Memory Prices Through 2026
• HBM memory chips: The unsung hero of the AI revolution
• Generative AI and memory wall: A wakeup call for IC industry
• Breaking Through Memory Bottlenecks: The Next Frontier for AI Performance

The post Why memory swizzling is hidden tax on AI compute appeared first on EDN.

NHanced Semiconductors Inc of Batavia, IL (the first US-based pure-play advanced packaging foundry) says that it uniquely supports mixed-material hybrid bonding with either copper or nickel bonds. Its new Besi bonding system further expands its advanced packaging yield and throughput...

The North-Eastern Hill University (NEHU) in Meghalaya, developed an innovative indigenous semiconductor chip aimed at repelling the Red Spider Mite, one of the most destructive pests affecting the tea gardens across Northeast and other tea-growing regions in India.

This tech driven and eco-friendly innovation has been entirely developed at the Department of Electronics and communication Engineering, NEHU with collaborative research efforts of Pankaj Sarkar, Sushanta Kabir Dutta, Sangeeta Das, and Bhaiswajyoti Lahon.

The chip’s fabrication was undertaken at the Semiconductor Laboratory, Mohali, a premier Government of India facility for semiconductor manufacturing.

Currently, the semiconductor technology is relevant in the agricultural sector with regards to sensors, drone facilities, edge computing, IoT, and Artificial Intelligence. The development of technology has modernised the agricultural infrastructure to provide precision farming, and predictive analysis to boast yield.

The post NEHU’s indigenous chip against Red Spider Mite for tea gardens appeared first on ELE Times.

submitted by /u/jim11662418 [link] [comments]

Renesas Electronics Corporation is expanding its software-defined vehicle (SDV) solution offerings centered around the fifth-generation (Gen 5) R-Car family. The latest device in the Gen 5 family, the R-Car X5H is the industry’s first multi-domain automotive system-on-chip (SoC) manufactured with advanced 3nm process technology. It is capable of simultaneously running vehicle functions across advanced driver assistance systems (ADAS), in-vehicle infotainment (IVI), and gateway systems.

 

Renesas has begun sampling Gen 5 silicon and now offers full evaluation boards and the R-Car Open Access (RoX) Whitebox Software Development Kit (SDK) as part of the next phase of development. Renesas is also driving deeper collaboration with customers and partners to accelerate adoption. At CES 2026, Renesas will showcase AI-powered multi-domain demonstrations of the R-Car X5H in action.

 

The R-Car X5H leverages one of the most advanced process nodes in the industry to offer the highest level of integration, performance and power efficiency, with up to 35 percent lower power consumption than previous 5nm solutions. As AI becomes integral to next-generation SDVs, the SoC delivers powerful central compute targeting multiple automotive domains, with the flexibility to scale AI performance using chiplet extensions. It delivers up to 400 TOPS of AI performance, with chiplets boosting acceleration by four times or more. It also features 4 TFLOPS equivalent of GPU power for high-end graphics and over 1,000k DMIPS powered by 32 Arm Cortex-A720AE CPU cores and six Cortex-R52 lockstep cores with ASIL D support. Leveraging mixed criticality technology, the SoC executes advanced features in multiple domains without compromising safety.

  

Accelerating Automotive Innovation with an Open, Scalable RoX Whitebox SDK

To accelerate time-to-market, Renesas now offers the RoX Whitebox Software Development Kit (SDK) for the R-Car X5H, an open platform built on Linux, Android, and XEN hypervisor. Additional support for partner OS and solutions is available, including AUTOSAR, EB corbos Linux, QNX, Red Hat and SafeRTOS. Developers can jumpstart development out of the box using the SDK to build ADAS, L3/L4 autonomy, intelligent cockpit, and gateway systems. An integrated stack of AI and ADAS software enables real-time perception and sensor fusion while generative AI and Large Language Models (LLMs) enable intelligent human-machine interaction for next-generation AI cockpits. The SDK integrates production-grade application software stacks from leading partners such as Candera, DSPConcepts, Nullmax, SmartEye, STRADVISION and ThunderSoft, supporting end-to-end development of modern automotive software architectures and faster time to market.

 

“Since introducing our most advanced R-Car device last year, we have been steadfast in developing market-ready solutions, including delivering silicon samples to customers earlier this year,” Vivek Bhan, Senior Vice President and General Manager of High-Performance Computing at Renesas. “In collaboration with OEMs, Tier-1s and partners, we are rapidly rolling out a complete development system that powers the next generation of software-defined vehicles. These intelligent compute platforms deliver a smarter, safer and more connected driving experience and are built to scale with future AI mobility demands.”

 

“Integrating Renesas’ R-Car X5 generation series into our high-performance compute portfolio is a natural next step that builds on our existing collaboration,” said Christian Koepp, Senior Vice President Compute Performance at Bosch’s Cross-Domain Computing Solutions Division. “At CES 2026, we look forward to showcasing this powerful solution with Renesas X5H SoC, demonstrating its fusion capabilities across multiple vehicle domains, including video perception for advanced driver assistance systems.”

 

“Innovative system-on-chip technology, such as Renesas’ R-Car X5H, is paving the way for ZF’s software-defined vehicle strategy,” said Dr. Christian Brenneke, Head of ZF’s Electronics & ADAS division. “Combining Renesas’ R-Car X5H with our ADAS software solutions enables us to offer full-stack ADAS capabilities with high computing power and scalability. The joint platform combines radar localization and HD mapping to provide accurate perception and positioning for reliable ADAS performance. At CES 2026, we’ll showcase our joint ADAS solution.”

 

First Fusion Demo on R-Car X5H with Partner Solutions at CES 2026

The new multi-domain demo upscales from R-Car Gen 4 to the next-generation R-Car X5H on the RoX platform, integrating ADAS and IVI stacks, RTOS, and edge AI functionality on Linux and Android with XEN hypervisor virtualization. Supporting input from eight high-resolution cameras and up to eight displays with resolutions reaching 8K2K, the platform delivers immersive visualization and robust sensor integration for next-generation SDVs. Combined with the RoX Whitebox SDK and production-grade partner software stacks, the platform is engineered for real-world deployment covering multiple automotive domains.

Availability

Renesas is shipping R-Car X5H silicon samples and evaluation boards, along with the RoX Whitebox SDK, to select customers and partners.

The post Renesas Launches R-Car Gen 5 Platform for Multi-Domain SDVs appeared first on ELE Times.