EDN Network

Chime in with your suggestions in the comments. We’ll even allow the mechanical engineers out there to participate. Well…maybe.

The following are a few of the tips, advice, rules, or guiding principles, I’ve discovered after many years of engineering and in various engineering positions. I’m not an expert in engineering management; this list is just items I’ve discovered from being in the engineering trenches (or should I say, cubes).

Do you have a memorable experience solving an engineering problem at work or in your spare time? Tell us your Tale

General engineering

• Trust the math. We’re lucky to be in a profession where many design solutions can be derived using mathematics – it is more science than art. Use the math and trust its results.
• You can’t violate the laws of physics no matter how smart you are. I’ve been in a room when presentations have been made of a design, but where the basic concept violated some law of physics. These poor people spent a lot of time heading to the dead-end.
• Be clever only when it’s needed. Don’t design in an “interesting” part into a company project unless it is needed. Save that exploration for your home projects.
• Build on previous designs if you can. Reusing parts of a proven solution is very good for business, and for your career.
• Document everything – code, tests, schematics, simulations, sketches. This is for the next engineer and for possible patent filings. It leaves a nice trail of work done to get to a solution.
• Work on the biggest unknowns first. This brings the risk to a project down quickly. If these issues cannot be resolved, the project concept may be able to be changed to avoid the issue.
• Estimate a project’s tasks to 8-hour resolution – make a list of all pieces of the project – code to write, circuits to design, mechanical, docs, testing, etc. Typically, you bring a representative of each design section into a room for a number of days. You discuss all areas of the design down to the smallest detail. I have found that if you break it down to a one-day task level, your time estimates will be very accurate, and you also may discover some risks early. Also never assume an 8-hour workday means 8 hours of engineering – many things get in the way. I always use 80% for the actual engineering time in a day.
• Fight for your time estimates. Management may tell you that your time estimate is too long, and give you a number that is too short. If you do a deep estimate down to the 8-hour level, you should be confident of the estimate and you can, and should, defend it. Don’t get pushed into an impossible time line.
• Adding people to a project in the middle may slow it down. Management may say they will give you more people. It depends on the project and where in the project you are, but more people can also be a time-sapping burden.
• Focus on your piece and trust the others to focus on theirs. I often had people tell me how this other team will not be ready when their part is needed. This is for a project manager to worry about. Keep your eyes on your part and make sure you’re ready on time.
• There is a fog-of-war on large projects. Project details can get lost and confused, especially on a large project. Things get missed in the activity – this is one of the project managers main tracking jobs. Make sure your part is well documented and progress/issues well communicated.
• Always stay calm. Things will go wrong; project disasters will happen. If you stay calm during these times, you will see that fixing the issue will go much smoother.
• Make sure all applicable department managers have signed off on the product spec. If someone wants a change, all departments need to sign off after engineering re-quotes the time/cost requirement changes.

Testing and troubleshooting

• Pay attention to anomalies. Anomalies are often dismissed, but these can be clues to an underlying problem. Document these anomalies for future reference.
• Ship what you tested – if you change anything, always retest. Don’t assume it will work.
• Use simulations but verify in the lab as there may be unaccounted-for parasitics. All components can have some level of parasitics; resistors can have capacitance and inductance. Capacitors can have resistance and inductance; capacitance values can change relative to the applied voltage. Inductors have resistance and winding to winding capacitance. Transistors, FETs, and all semiconductors can have various capacitance, inductive, and resistive parasitics. Don’t even get me started on crystals.

Your job

• None of us is irreplaceable. The company probably wouldn’t collapse if you were gone tomorrow. Management knows that – you need to know that, too.
• Take care of your career yourself. Don’t depend on your company to move you along in your career. Push for a position you want. Discuss wages if you want an increase. Work to get the training you want and need.

Hardware engineering

• Never assume a part can be substituted with one from a different manufacturer, product line, or value without retesting in the product.
• Understand basic practical thermodynamics as it applies to electronics design – this knowledge is needed often in electrical engineering (EE)-type projects. Calculations are needed when using things like heatsinks, PCB heat dissipation, thermal vias, active or convection cooling, heat pipes, etc. Much of this can be dealt with by an EE without the need for a mechanical engineer.
• Tell your manager that the first PCB assembly will have issues, the second works sometimes, and the third’s the charm. I’m not sure I’ve ever seen a PCB be perfect on the first pass (except maybe a very simple one). Problems can be EMI issues, schematic errors, assembly issues, pad/trace tweaks, mechanical issues, etc. The latest layout and simulation tools help a lot, but they won’t tell you that you spelled the company name wrong on the silkscreen.

Firmware engineering

• Don’t write obfuscated code. If it seems a bit cryptic, then document it well. ( I actually saw production code with the line “Bet you don’t know what this does”.)
• Stop using so many pointers.
• All code has bugs, even yours.
• Use a coding standard – consider MISRA guidelines.
• Use lots of comments – at the top of the program file, at the top of every procedure, the top of large conditionals, and on all cryptic statements.
• Adding your comments to AI-written code will help assure that you understand the code.
• No magic numbers in the code – if you have an actual number in a line of code, consider if it is better defined in something like a #define or const.
• Keep fixing code to remove all warnings from your compiled code – fix anything that shows an error code, at any level.
• Minimize the use of global level variables (I’m admittedly a serial violator of this crime.)
• Always check to see if pointers are in bounds. You may be creating unstable code along with security issues.
• Consider using AI, because it can often speed things up. Then again, though, it can also slow them down. My experience is that it can write very nice-looking code that typically compiles, but often there are subtle errors, especially on boundary conditions. So, don’t trust but verify, but suspect and test.
• Avoid dynamic memory allocation if you possibly can. This can very quickly lead to hard-to-understand crashes.

For managers

• Employees are expensive, and equipment is cheap if it speeds their work up. Get them what they ask for.
• Employee training is important – encourage and pay for expos and classes. Set up vendor presentations (and buy lunch).
• Encourage patent filings and implement bonuses for filed and granted patents. Patents are good for the company portfolio and the employee’s morale, as well as your recognition of support.
• All engineers have a type of engineering that they are good at. They may good at systems engineering, clean-sheet-of-paper designers (those that can design a device from scratch based solely on a concept) , lab test engineering, simulator/modeling, maintenance and component engineering, estimating/spec writing, customer facing or not, field engineering, analog and digital engineering, EMI/EMC experts, etc., etc. You wouldn’t assign a digital engineer to do a complex analog design; in the same fashion, don’t assign an engineer that’s good at analyzing field data to a clean-sheet-of-paper task (and vice-versa).
• If you lead, supervise, or manage, never ever micromanage. This is discouraging to an employee. If you think they’re not performing, ask if they need assistance. If you think they are in over their heads, back off their task list or move them to another task or project.

For everyone

• The 50% rule – this is my rule that states that 50% of the information you get from a user, having an issue with a device you designed, will be misleading or untrue. That doesn’t (hopefully) mean that they lied. It means they exaggerated, interpreted what happened and gave you the interpretation, mis-remembered a sequence of events, or used incorrect terminology (for example, said that the device died instead of that the screen or keyboard locked up). All data from the field must be vetted before digging too deep. ( I’m being generous with 50% because I actually believe the occurrence of this is more like 75%.)

I’m sure all the engineers out there have many other tips to add to this list. Let’s see some of yours in the comments. We’ll even allow mechanical engineers to chime in.

Damian Bonicatto is a consulting engineer with decades of experience in embedded hardware, firmware, and system design. He holds over 30 patents.

Phoenix Bonicatto is a freelance writer.

The post Some tips for electrical engineers appeared first on EDN.

Part 1 of this mini-series covering single event upset (SEU) challenges in FPGA architectures examined radiation particles and related SEU challenges for FPGA applications that require robustness and predictability in ground-based and terrestrial applications.

Part 2 of the mini-series will cover SEU detection, recovery, and validation for FPGAs used in mission-critical systems such as aerospace, defense, telecommunications, and industrial applications.

Detection and recovery from SEUs require a layered strategy that addresses the distinct vulnerabilities of configuration RAM (CRAM), user logic, and embedded data storage. No single technique provides comprehensive coverage across all FPGA resource types. Instead, an effective approach combines complementary methods, each targeting a specific failure mode, with recovery mechanisms that are tightly coupled to the detection events that trigger them.

The following sections describe the detection techniques and their associated recovery strategies, from configuration-layer monitoring to logic-level redundancy to system-level behavioral observation.

CRAM readback and scrubbing

CRAM readback is the most basic detection technique for SEUs in CRAM. The system calculates a cyclic redundancy check (CRC) for the bitstream. An internal hardened configuration block in the FPGA reads back the CRAM contents and compares the calculated CRC to the expected result. If the results don’t match, the system can set a status flag to alert the user, for example via an internal interrupt to a soft processor or an external pin to a system-level board controller.

If the system flags an SEU error, the user can take action, for example:

• Stop the FPGA application and reload the bitstream, overwriting the CRAM to fix the flipped bit.
• Wait for an accumulation of SEUs before halting the application and reloading the bitstream.
• In some applications, it may be acceptable to power cycle the board and thereby the FPGA, which automatically reloads the bitstream upon power-up.

SEU scrubbing is another SEU recovery technique. Some FPGAs contain blind scrubbing circuits that run in the background and can periodically rewrite the entire bitstream regardless of whether the system detects an error. It’s easy to implement blind scrubbing because it does not require comparison logic; the downside is that blind scrubbing cannot give diagnostics on error rates and specific locations of SEU.

You can schedule scrubbing continuously or for a fixed period, depending on the application and trade-offs on additional power utilization. At terrestrial levels, you can usually set scrubbing intervals further apart, while at higher elevations, given the higher probability of radiation particles, intervals should be shorter.

More advanced SEU readback scrubbing circuits can detect and fix SEUs and report multiple upsets within a bitstream frame. Recent FPGA architectures have bitstreams that have frames that program subsets of the CRAM. Each frame is protected with single error correction and double error detection (SECDED). The SEU readback scrubbing circuit reads the contents of the CRAM and compares the calculated error correction code (ECC) for each frame with a known good ECC for that frame.

If the comparison fails, the circuit can locate the single bit failure based on the ECC mismatch signature and re-write the bitstream frame with the incorrect bit corrected. The SEU readback circuit is more complex and can give better diagnostics for error rates and failure locations. If the readback detects multiple uncorrectable errors however, you may need to reload the entire bitstream or power cycle the FPGA.

Error detection and correction for block RAM

Block RAM upsets require a dedicated detection and correction strategy because the stored data changes dynamically during operation and cannot be protected by static configuration scrubbing. Data written to RAM is wider by a certain number of bits, depending on the data width and encoding used for protection.

If you use an ECC encoder when writing data to RAM, you can use an ECC decoder when reading from RAM to detect corruption. ECC encoders and decoders can detect and correct single- and double-bit errors. From a system design perspective, using ECC to protect block RAM adds latency for encoding and decoding.

Some FPGAs have in-silicon ECC encoders for writing to the RAM and ECC decoders for reading from the RAM to detect and correct corrupted bits. These hardware-based encoders/decoders use more silicon area, have higher power, and have additional output delays. Implementing ECC encoding and decoding in your RTL design is a good option if few block RAMs are used for critical functions such as soft processor program memory, high integrity data paths, or state machine storage.

Triple modular redundancy (TMR)

TMR is the most robust mitigation strategy to guard against SEU errors. TMR requires three independent copies of a circuit to produce the same output. Each circuit has its own copy of combinational and sequential logic. The system compares the result from all three circuits, and two out of the three must match. This method provides a correct result even if one circuit is corrupted.

TMR provides continuous cycle-to-cycle error masking without any detection latency, and is very effective for protecting state machines, control logic, and safety-critical signal paths. However, TMR requires very strict architectural implementation to guarantee that none of the circuits share logic or routing with each other.

Although robust, TMR comes with a large trade-off in terms of FPGA resource usage and power. You need to use at least three times the resources to accommodate the triple redundancy and plan on higher power requirements as a result. Additionally, TMR cannot self-correct a bit error. A bit flip in one of the circuits continues to be corrupt until CRAM scrubbing can address the corruption.

Measuring SEU rates in FPGAs

Quantifying the reliability of an FPGA’s exposure to SEU can be done with specific testing using particle beam accelerators in specialized facilities. The standard figure of merit for terrestrial SEU rate is the soft error rate (SER) expressed in failures in time (FIT), where one FIT equals one failure per 10⁹ device hours.

Most FPGA manufacturers that support SEU detection and scrubbing reserve time at reputable facilities that can provide high energy beams of heavy ions, neutrons, protons, and alpha particles. Facilities can be found in the U.S., Canada, Switzerland, and Japan. This ground-based approach for accelerated testing helps to characterize the FPGA family’s radiation sensitivity. FIT data from the testing helps predict upset rates in target environments.

Ground-based testing and analytical modeling provide pre-deployment FIT rate estimates, but operational monitoring during deployment in the application environment provides the most accurate characterization of device behavior. CRAM detection and scrubbing circuits can log time, location, and frequency of detected SEUs, which you can compare to pre-deployment predictions.

If you observe rates that differ from pre-deployment predictions, you can redesign critical circuits, change scrubbing intervals, and/or change operational range. Most FPGA users work closely with their FPGA vendor to understand measured ground-based FIT rates from beam testing within a specific family and compare it to the application environment testing results.

FPGAs with SEU capabilities

Take the case of Efinix’s Titanium and Topaz families that are built on TSMC’s 16-nm FinFET process. These FPGAs benefit from the inherent SEU sensitivity advantages of the FinFET geometry relative to planar 2D transistor architectures at equivalent geometry.

These FPGas have characterized SEU behavior through independent testing conducted per JEDEC Std. JESD89A for alpha particles and per STd. JESD89 and JESD89-A for neutron particles, providing design engineers with measured FIT data from which you can determine system-level reliability.

The company’s Titanium FPGAs have CRAM SEU detection that lets design engineers monitor configuration integrity and respond to detected upsets through external recovery actions. Efinix also provides data on the FIT contribution from SEU events (transient failure rate) in a soft-error rate (SER) report.

Design engineers can use this data to determine whether on-chip mitigation features are required to achieve target Probabilistic Metric for random Hardware Failures (PMHF) values under ISO 26262-5 for their specific ASIL level.

Next, Titanium Edge FPGAs pair SEU detection capability with hardware scrubbing. The scrubbing architecture implements SECDED on a per-frame basis, operating at clock rates up to 80 MHz. SECDED enables automatic single-bit error correction without an external processor, and it flags uncorrectable double-bit errors for system-level response.

The SEU detection is configurable to meet different application needs. Automatic detection cycles through CRAM frames without user intervention, providing the lowest mean time to detection and the highest assurance of configuration integrity. Manual monitoring allows you to initiate a scrub cycle on demand.

Similarly, you can set detection and correction triggering as automatic, manual, or fixed-rate operation, tailoring the scrubbing interval to your deployment environment’s potential SEU rate. To support design validation and test system robustness, Titanium Edge FPGAs include a hardware error injection capability that can inject a single-bit error at any location within the CRAM array.

Finally, Topaz FPGAs have similar SEU detection capabilities as the Titanium family, but they don’t have the Titanium Edge scrubbing architecture overhead. System designers can monitor detected SEU errors and recover from them via an external action. This family is targeted at high-volume applications such as machine vision, industrial robotics, and broadcast imaging and controls.

Why SEU detection is critical

Radiation-induced SEUs represent a reliability challenge in modern FPGA design and technology. SEUs can silently flip bits that corrupt configuration memory, embedded memory, routing, and logic, thereby negatively impacting system behavior.

The threat to smaller process geometry FPGAs affects terrestrial applications as well as ground-based applications where thousands of FPGAs may be deployed in a system. Ground-based FIT rates may be low for a single FPGA, but when thousands are deployed, the probability of SEU impacting system behavior may increase to a level that requires detection and recovery.

Packaging technology advancements to reduce trace radioactive impurities and alpha particle emission have helped FPGA vendors reduce FIT rates. However, heavy ions, protons, and neutrons continue to expose FPGA vulnerabilities and require heavy beam testing to quantify the sensitivity to SEU and resulting FIT rates.

Detecting SEUs and scrubbing FPGA CRAM are critical to quantify an accumulation of errors that may require a reconfiguration or power cycle. Similarly, quantifying SEU errors within a specific altitude profile can guide systems on scrubbing cycle time by analyzing system power trade-offs versus expected error rates.

You must also analyze the trade-offs when planning for embedded block RAM protection. Error detection and correction require a lot of logic resources that could be soft or hardened in silicon. If you don’t need to detect and correct errors in all block RAM, a soft implementation for mission-critical block RAM can save power and resource utilization.

The most comprehensive strategy to protect against critical control and data path errors is TMR, but with a heavy cost of three times the resources and additional power. Alternatively, some applications may use a mix of TMR, block RAM ECC, and CRAM SEU detection and scrubbing.

No matter which method you choose for mitigating SEU exposure, it’s important to work with the FPGA vendor to understand their testing methodology and resulting FIT rate data. The FPGA FIT rate data can then be extrapolated to understand and compare actual measurements with the application profile.

Mik Ichiba is principal field applications engineer at Efinix. He is a seasoned semiconductor and embedded systems professional with more than 30 years of experience spanning hardware architecture, PCB design, ASIC development, FPGA architecture, and system-level engineering. Throughout his career, Mik has worked across the hardware design lifecycle, helping organizations translate complex technical requirements into practical, high-performance solutions.

Editor’s Note

This is Part 2 of the mini-series about SEU challenges in FPGA architectures. Part 1 covered SEU radiation particles and related SEU challenges for FPGA applications that require robustness and predictability in ground-based and terrestrial applications.

Related Content

• Using FPGAs in mission-critical systems
• Rethinking the Logic-Routing Tradeoff in FPGAs
• Understanding Single Event Effects (SEEs) in FPGAs
• Enhancing robust SEU mitigation with 28-nm FPGAs
• Learn about SEU Immunity in Terrestrial FPGA Applications

The post FPGA architecture: SEU detection and recovery strategies appeared first on EDN.

Packaging innovation in the AI era has reached the doorsteps of power electronics. A new architecture uses the silicon wafer itself as the package foundation to enable a highly integrated approach to power system design. It optimizes electrical, mechanical, and thermal design together from the outset to help designers achieve higher power density and improve system performance.

Embedded Power Platform (EPP) unveiled by onsemi claims to have reimagined the package from passive housing into an active contributor to power design performance. It enables a seamless integration and interconnection of silicon, silicon carbide (SiC), and gallium nitride (GaN) technologies within a highly integrated wafer-level architecture.

Figure 1 In EPP, heterogeneous dies are embedded in silicon and connected through wafer-level redistribution layers. Source: onsemi

“For decades, the semiconductor and the package have been treated as separate technologies,” noted Hassane El-Khoury, President and CEO of onsemi. “EPP changes that by making the silicon itself part of the system architecture.” It does that by combining advanced semiconductor technologies, manufacturing, and system-level optimization into a single power design.

The AI era is creating new infrastructure challenges that computing power alone can’t solve. Take data centers, for instance, where design engineers must move and manage more electricity in server racks while controlling heat, efficiency, cost, and development time. That limits how much compute capacity can fit within a rack.

That’s mainly because traditional power system design approaches treat power electronics, mechanical design, and thermal design as separate engineering challenges. As a result, each layer is optimized independently and sequentially, so decisions made at one stage can create compromises in another. That, in turn, leads to additional engineering iterations, costly late-stage changes, and longer development cycles.

EPP replaces the sequential model with a common platform that can be co-designed, co-simulated, and co-optimized. That transforms it into a technology-agnostic platform that supports different applications and semiconductor materials while scaling across multiple power levels. As a result, multiple devices such as FETs, drivers, and controllers can be embedded together in a single package and co-optimized for electrical, thermal, and mechanical performance.

Figure 2 EPP claims to introduce a fundamentally new approach to how power is delivered, managed, and optimized. Source: onsemi

This enables tighter electrical coupling, combines power and control in a single platform, and reduces system-level complexity. According to onsemi, in a solid-state circuit-breaker design, the EPP-based solution was approximately 50% smaller and 20% cooler than existing designs.

Beyond data center power

Carmaker Subaru—an early engagement partner for EPP—is working with onsemi to evaluate how the platform could support future electrified vehicle architectures. Subaru will gain early access to engineering samples, simulation models, and technical expertise as the two companies explore opportunities to improve vehicle performance and streamline development.

Efficiency losses, thermal limitations, development complexity, and system size often constrain EV traction inverters. Here, EPP’s scalable architecture helps develop a single inverter platform that spans low-end to high-end vehicle applications. This lets carmakers reuse a common design across multiple vehicle models and power classes, reducing R&D and manufacturing costs, accelerating qualification and development cycles, improving vehicle range, and lowering system costs.

As AI, automotive, and industrial markets drive demand for more power in less space, a new architecture claims to redefine system power delivery by integrating multiple dies into a single silicon device. EPP also claims to enable 3 – 5x higher power density than current solutions through a highly integrated approach to power system design.

These claims will surely be tested in data center and EV power designs, where designers must improve efficiency while managing heat, size, and cost. EPP is expected to begin sampling in 2026 with strategic customers and ecosystem participants across automotive and AI applications.

Related Content

• The shift to 800-VDC power architectures in AI factories
• Power systems: the first parameter to evaluate is efficiency
• Low Power Design Techniques, Design Methodology, and Tools
• LTpowerPlanner: A system-level power architecture design tool
• Designing a data center power architecture with supply and processor rail-monitoring solutions

The post Highly integrated approach to power system design in the AI era appeared first on EDN.

Want to network-connect your gear using prevalent wired Ethernet? Or interference-impervious optical fiber? How about a bandwidth boost? Or a range extension? SFP and its siblings do it all.

One recent sequential-coverage cadence of mine just wrapped up, with part 4 of the “Debugging intermittent Comcast” run done. Another, my longstanding TP-Link smart plug teardown series, is nearing the finish line, with its next entry queued up to appear on EDN a week from next Monday and its final entry scheduled for next-month publication.

But if indeed all good things must sooner or later come to an end, other good things can also emerge in their stead. That’s what I hope will be the case for the small form-factor pluggable (SFP) module teardown series set to start next Monday. I first learned of SFP through my efforts to galvanically isolate my various LAN devices from lightning EMI-prone Ethernet and coax cables running outside of my residence.

Multi-gig gains ascendancy

I’ve subsequently become intrigued (also with pending editorial-coverage consequences) with the increasing (and dramatically so) cost-effectiveness of mainstream network switches, routers, and other devices based on 2.5 GbE technology. Take a look, for example, at this enterprise managed switch from the late 2000s, which cost several thousand dollars when brand new.

Granted, it has 24 primary Ethernet ports, but they “only” offer 10/100 Mbps. At far left are two more GbE Ethernet ports. And in-between the two RJ-45 arrays are two 1 Gbit SFP ports.

Fast-forward to today. This switch is admittedly unmanaged and has only eight RJ-45 ports.

But those RJ-45 ports are 2.5 GbE. The SFP ports are next-gen SFP+, 10 GbE. And the price tag? $41.39 at Amazon as I write these words.

Or this one:

Four fewer RJ-45s, albeit still 2.5 GbE. Once again, two 10 GbE SFP+ ports. And the price? $31.99. One of them is on an Amazon delivery truck headed to me later today as we speak, in fact. And in a near-future planned post, I’ll even detail how it’s possible to (and I in fact did) transform one into a fully user-managed variant using hacked factory firmware and/or open-source software.

Why 2.5 GbE (along with, to a lesser extent, 5 GbE) has become mainstream is a topic for another post another day (soon). Similarly, I’ll save for the near future more discussion on why 10 GbE SFP+ ports are appearing on mainstream gear like this. Today, in advance of a plethora of teardowns to come on a diversity of module variants I’ve been collecting in recent weeks, I just want to focus on what SFP is, along with its predecessor and siblings.

Without further ado, and focusing predominantly on the “flavors” most commonly used in consumer and workgroup settings, therefore in highest production volume, which typically translates to lowest cost (if you feel like your head’s about to explode after absorbing the full suite of SFP implementation options documented on Wikipedia, it’s perfectly understandable!)…

Mechanical form factors

Before SFP, there was GBIC, the gigabit interface converter, initially defined in 1995 and used with Gigabit Ethernet and Fibre Channel. As Wikipedia notes, “By standardizing on a hot swappable electrical interface, a single gigabit port can support a wide range of physical media, from copper to long-wave single-mode optical fiber, at lengths of hundreds of kilometers.”

Keeping in mind inevitable bandwidth extrapolation, thanks to further technology evolution, the same basic definition applies to 20-pin SFP, therefore explaining its alternative name, mini-GBIC.

Quad SFP (QSFP), as the name implies, supports four simultaneous bidirectional data lanes (therefore the 38-pin connector). The first picture above is of a standalone transceiver; the second shows an active optical cable (AOC) version conceptually like, albeit of course more complex than, the SFP-based ones I’m currently using in my network for galvanic isolation purposes.

The module is of the same height (8.5 mm/0.33 in.) as SFP, as is the XFP module I’ll discuss next. But it’s wider than SFP (18.35 mm/0.722 in. vs 13.4 mm/0.53 in.), although adapters can allow SFP modules to fit in QSFP sockets. And it’s also deeper than SFP; 72.4 mm/2.85 in. vs 56.5 mm/2.22 in.

Last, and least common nowadays, is another SFP precursor, aforementioned 30-pin XFP, dating from 2002. It’s even deeper than QSFP, 78.0 mm/3.07 in. The above photo is of it alongside SFP.

System interfaces

Commonplace SFP interfaces run at 100 Mbps and 1, 2.5 and 5 Gbps. The bitrate similarly to Ethernet counterparts is not accidental SFP+ leverages the same SFP mechanical form factor discussed earlier but runs at 10 Gbps and 25 Gbps, the latter alternatively known as SFP28. Less common 50 and 100 Mbps SFFP+ variants (SFP56 and SFP112) are also available, as are “DD” double density flavors which leverage up to 8 data lanes. Higher speed SFP+ versions migrate from non-return-to-zero (NRZ) modulation to four-level pulse-amplitude modulation (PAM-4).

Interconnect options

SFP modules connect to each other, as well as directly to system in some cases, via three main cable material and associated transceiver options: fiber optics in conjunction with electro-optical converters, RJ-45 Ethernet, and basic copper wire.

I’ll discuss fiber optics in more detail in the next section; for now, I’ll note the following:

• Both plastic and glass cable construction material options are available. Plastic characteristics include (with glass characteristics essentially the exact opposite):
  • Lower cost
  • Greater flexibility and overall handling safety
  • But much shorter usable distance due to high attenuation loss
  • Low tolerance of temperature extremes
• When the cable is permanently installed to SFP modules on both ends, it’s referred to (as alluded to earlier) as an active optical cable (AOC).

RJ-45 modules mate the SFP or SFP+ circuitry to an Ethernet transceiver. Speeds up to 10 GbE, such as with the module shown at the top of this section, are widely available. These modules tend to run “hotter” than fiber optical or basic wire alternatives, all other factors being equal.

Passive direct-attached-cable (DAC) wire harness-based cables are the most elementary version of this particular form factor, with the shortest effective range. Active copper cables (ACC), as a helpful white paper from NADDOD explains, “use a redriver chip architecture, employing continuous time linear equalization (CTLE) to boost signals on the receiver (Rx) side, acting as analog signal amplifiers.” And active electrical cables (AECs) “are more advanced, using a retimer chip architecture to amplify and equalize signals at both transmitter (Tx) and receiver (Rx) ends, with added clock data recovery (CDR) to reduce jitter, offering higher signal integrity and clearer data transmission.”

Wavelengths

SFP modules most commonly run at the following wavelengths (all are center frequencies):

• 850 nm (“multimode”)
• 1300 nm (“multimode”)/1310 nm (“single-mode”)
• 1550 nm (“single-mode”)

The distinction between multimode and single-mode fiber optics is important to comprehend and keep in mind, as the two technologies are not interchangeable (although some modules will work with both associated cable material types).

Multimode was historically much less expensive to implement, at the tradeoff of lower usable transmission distance. It features a comparatively larger cable core (50 to 62.5 microns) that lets multiple light signals travel down different paths at the same time, and it usually uses lower-cost LEDs or vertical-cavity surface-emitting lasers (VCSELs).

Single-mode features a comparatively tiny core (about 8 to 10 microns), which allows only a single ray of light to pass straight through without bouncing off the edges, and it uses focused lasers as a light source. Its historical cost disadvantage versus “multimode” has more recently decreased, due in part to the availability of non-proprietary, widely compatible modules. And as noted earlier, it generally specifies much longer usable transmission distances.

Cable tiers

We’ve already discussed fiber optic cable materials and construction options, along with associated light source and reception approaches. Each combination also has multiple quality tiers, which are commonly color-coded for ease of user recognition and interpretation.

Multimode cable comes in OM1 through OM5 options, with OM1 and OM2 now in legacy status and OM3 and OM4 most common nowadays. The fundamental tradeoffs between them involve lower cost (OM3) versus higher modal bandwidth and longer transmission spans (OM4).

For single-mode fiber optics, it’s simpler—OS1 and OS2—although the two types are incompatible in that they cannot be directly connected to each other. Cost, bandwidth and transmission distance are again the predominant evaluation criteria between them, although construction variances also tend to favor OS1 for indoor use and OS2 for outdoor applications.

Fiber connectors

Legacy GBIC deployments used the Standard (or Subscriber) Connector (SC) to mate cables to modules. Newer SFP-based implementations have switched to the much smaller Lucent Connector (LC). AOC fiber interconnect with SC plugs on one end and LC plugs on the other is also commonly available to bridge legacy and newer networking hardware.

Module flavors

As mentioned earlier, I’ve got a bunch of modules in hand, which I plan to tear down and internals-share with you in the coming months. As you can likely already imagine, the implementation diversity inherent in combining the numerous technology variables discussed in the previous sections results in oft-“interesting” module results. Here’s what I’ll be dissecting:

• 1 Gbit SR (short range, multimode) SFP module
• 1 Gbit LX (long range, usable with both single-mode and multimode cable at differing distances) SFP+ module
• 1 Gbit SFP to RJ45 transceiver module
• 5 Gbit ZX+ (extended long-haul range, single-mode) SFP module
• 10 Gbit IR (intermediate range, single-mode) SFP+ module
• 10 Gbit 0.3 meter/1 foot DAC cable
• 25 Gbit SR (short range, multimode) SFP+ (SFP28) module
• 40 Gbit SR QSFP+ module

The last one, whose image is at the top of this section, is particularly interesting (at least to me). It’s a 1 Gbit “BX” SFP module, with BX standing for bidirectional. Compared to the prior fiber-based modules, which use one strand for transmission and the other for reception (so you need to be sure when you hook them up that each strand’s transmission connection on one module end mates up with the other module’s receiver connection at the other end, and vice versa!), a BX module both transmits and receives across a common single cable strand.

The wavelengths employed by each module are vendor-specific, so you need to be careful in reading the specifications to ensure that you’ll end up with a transmit-and-receive wavelength matched pairing on both ends of the cable. Or just play it safe and buy all your modules from a single supplier, using a common model number.

And here’s a further “wrinkle” on the concept; in the above picture, since only a single strand is in use, there’s only one exposed optical connector site necessary. cSFP modules instead continue to use both fiber cable connectors, combining two bidirectional electro-optical subsystems in one module for doubled per-cable transfer rates. Tricky, eh?

That’s all I’ve got for you today. Look for my initial module teardown in the series, of the aforementioned 10 Gbit LX SFP+ module, to come early next week. And until then, I as always welcome your series-so-far thoughts in the comments!

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

Related Content

• TP-Link MC220L: Media conversion keeps the network well
• The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
• Design considerations in high-speed fiber networks

The post SFP: Add-in module delivers diminutive performance, flexibility appeared first on EDN.

The ST SafeSense VD56GA 1.1-Mpixel automotive image sensor enables infrared in-cabin sensing for driver and occupant monitoring applications. Based on ST’s DeepNIR BSI pixel architecture, the sensor delivers 35% higher modulation transfer function (MTF) and nearly 60% higher quantum efficiency (QE) than the previous generation. The higher MTF and infrared sensitivity result in sharper images, while the sensor’s small CSP allows discreet in-cabin camera designs for space-constrained installations.

With 2.43×2.43-µm pixels, the global-shutter sensor’s 1.1-Mpixel architecture achieves virtual 2-Mpixel performance. According to ST, the VDA56GA can reduce overall camera-module costs through lower-cost optics, simplified infrared illumination, and less demanding optical filtering. Embedded image-processing functions, including mirror, crop, dark calibration, auto exposure, and piecewise-linear processing, eliminate the need for external image processing. Together, these features can help designers deploy driver and occupant monitoring across a broader range of vehicle models.

The sensor is undergoing AEC-Q100 Grade 2 qualification, with a −40°C to +125°C operating junction-temperature range. It is compliant with ISO 26262 for ASIL B system integration and ISO/SAE 21434 for automotive cybersecurity.

Samples are available now. Pricing information and sample requests are available from local ST sales offices.

VD56GA product page 

STMicroelectronics

The post Sensor sharpens infrared in-cabin imaging appeared first on EDN.

Vishay’s XFD11KxxCA flat-clamping transient voltage suppression (TVS) devices provide 11 kW of peak pulse power dissipation at 10/1000 µs. Offered in surface-mount DO-218AC packages, the bidirectional devices maintain a low clamping ratio (VC/VBR) close to 1.0, supporting high power density.

The XFD11KxxCA series comprises 15 devices, each available in commercial and AEC-Q101 qualified grades. They have clamping voltages of 40.6 V to 104.0 V, breakdown voltages from 36.7 V to 104 V, and standoff voltages from 33 V to 85 V, making them suitable for 12-V, 24-V, and 48-V automotive powertrains. At the same standoff voltage, they have lower clamping voltage than conventional TVS products in DO-218 packages and deliver approximately 1.6 times higher peak pulse current, up to 207.1 A at 10/1000 µs.

Additional key specifications include an 8/20-µs surge capability of up to 2140 A and maximum leakage current of 10 µA at the standoff voltage (VWM) to minimize power loss. The series’ low, stable clamping and breakdown voltages over a wide temperature range of -55°C to +175°C allow the use of lower-voltage downstream components, reducing voltage overshoot and enabling smaller design guard bands.

Samples and production quantities of the XFD11KxxCA series are available now, with lead times of 12 weeks.

XFD11KxxCA product page

Vishay Intertechnology

The post Transient voltage suppression devices reach 11 kW with flat clamping appeared first on EDN.

Singular Photonics’ Litavis is a CMOS single-photon avalanche diode (SPAD) image sensor with integrated digital photon processing on-chip and in-pixel. By processing photon events directly on-chip, it reduces the volume of raw data that must be transferred and processed externally.  According to the company, Litavis enables scalable real-time imaging systems with lower latency and improved power efficiency.

The 3D-stacked, back-side-illuminated (BSI) sensor captures spatial and temporal information while extracting scene information such as depth and event characteristics. Its software-configurable architecture combines photon-counting imaging, programmable time gating, and photon timing within a scalable SPAD array. Litavis supports intensity, timing, and histogramming modes concurrently, allowing users to dynamically adjust sensor parameters in software without requiring a new hardware design.

Litavis provides continuous 256×256-pixel photon-counting imaging under low-light conditions and simultaneously generates time-stamped photon events across a 64×64-macropixel timing grid. It delivers 47% photon detection efficiency (PDE) at 785 nm, 37-ps timing resolution, and 4.3-ns dead time, with a 100% fill factor enabled by microlenses.

The SPAD-based sensor targets applications including machine vision, physical AI, robotics, depth sensing, and scientific imaging. A timeline for sensor availability was not provided at the time of this announcement.

Litavis product page  

Singular Photonics  

The post SPAD sensor processes photon events on-chip appeared first on EDN.

Anti-surge chip resistors in Rohm’s SDR01 series deliver a rated power of 0.33 W in the 0402 (1005 metric) package. The devices save board space and lower component count by replacing larger-size resistors in automotive, industrial, and AI server applications that require increased mounting density.

With optimized resistive element and electrode designs, the SDR01 series achieves a high rated power in the 0402 size while maintaining the reliability expected of high anti-surge chip resistors. The devices maintain their 0.33-W rating at terminal temperatures up to 125°C, making them suitable for demanding thermal environments.

Qualified to AEC-Q200, the chip resistors operate over a temperature range of -55°C to +155°C. The SDR01MZPF has a resistance tolerance of ±1% and a resistance range of 1 Ω to 2.2 MΩ, with a TCR of ±100 ppm/°C from 10 Ω to 2.2 MΩ. The corresponding ratings for the SDR01MZPJ are ±5%, 1 Ω to 10 MΩ, and a TCR of ±200 ppm/°C from 10 Ω to 10 MΩ, respectively.

The SDR01 series is now in mass production.

Rohm Semiconductor 

The post Anti-surge resistors reduce component count appeared first on EDN.

Renesas offers the RZ/G3L and RZ/G3SE series of 64-bit general-purpose microprocessors for consumer and industrial HMI and IoT edge systems. Expanding the company’s RZ/G portfolio, the pin-compatible MPUs allow developers to reuse a PCB design for multiple products.

Targeting HMI devices that require rich graphics and video capabilities, the RZ/G3L integrates a GPU for 3D graphics rendering and an H.264 video codec. The RZ/G3SE targets edge devices with basic display requirements, such as EV chargers and industrial gateways with status indicators and configuration screens.

Both series use dual or quad Arm Cortex-A55 cores running at 1.2 GHz and a Cortex-M33 coprocessor at 200 MHz. The MPUs can reduce standby power to 1 mW in deep standby mode and support fast Linux wakeup for always-connected applications. High-speed interfaces, including PCIe, TSN-capable Gigabit Ethernet, and USB, enable application-specific connectivity options such as 5G and Wi-Fi 6 modules.

The RZ/G3L and RZ/G3SE MPUs are available now in 14-mm², 400-pin LFBGA and 17-mm², 368-pin LFBGA packages.

RZ/G3L product page

RZ/G3SE product page

Renesas Electronics

The post Pin-compatible MPUs simplify product variants appeared first on EDN.

As FPGA manufacturing migrates to smaller geometries, the process change has delivered extraordinary gains in density, speed, and power efficiency. However, these gains have come at a cost in terms of single event upset (SEU) sensitivity.

Starting in the mid-1990s, the FPGA industry began experiencing a more noticeable rate of SEU sensitivity in 2D planar transistor architectures. Smaller process geometries require less capacitance to store a given state, so a lower amount of energy can disrupt the stored state. Sensitivity increased proportionally to the geometry shrink.

Moving to tri-gate 3D FinFET geometries at 22 nm helped reduce SEU sensitivity compared to 2D planar, but as tri-gate geometry reduces, SEU sensitivity will continue to increase. A bit flip used to require a direct, high-energy particle strike; now even lower-energy neutrons, alpha particles from packaging materials, or even secondary particles generated within the device substrate itself can trigger bit flips.

The result is an unavoidable increase in SEU susceptibility in FPGAs as process nodes scale smaller and FPGAs are deployed in more applications. Part 1 of this mini-series examines SEU radiation particles and related SEU challenges for FPGA applications that require robustness and predictability in ground-based and terrestrial applications.

Radiation particle types and SEU

A variety of particle types can interact with an FPGA and negatively impact system functionality. These particles differ in mass, charge, and energy strength, and interact with the semiconductor material through distinct physical mechanisms. The following discussion focuses on four particle types that lead to SEUs in FPGAs: heavy ions, protons, neutrons, and alpha particles.

1. Heavy ions

Heavy ions, which are caused by galactic cosmic rays and solar flares, are the most potent SEU-inducing particles for space and high-altitude environments. To a lesser degree they can impact ground-based systems. These particles have a heavy nucleus, high linear energy transfer (LET) values, and a positive charge.

When heavy ions traverse through the silicon substrate, they deposit large amounts of charge in their path, generating free electrons and holes that can disrupt a memory cell’s stored charge. A memory cell is constructed with transistors, and if the accumulated charge added by the heavy ion exceeds the minimum charge required by a cell’s transistor, the memory cell state can switch, resulting in a bit flip. In other words, heavy ions cause bit flips through direct ionization.

Figure 1 Heavy ion striking a planar transistor result in ionization along its path, depositing charge and potentially impacting the transistor state. Source: Efinix

Figure 2 Junction current is induced from charge collection and diffusion over time. Source: Efinix

2. Protons

Protons are a secondary radiation particle caused by cosmic rays and solar flares but are weaker than heavy ions. When cosmic rays hit the earth’s atmosphere, they cause nuclear interactions that produce protons. Proton particles have a lighter nucleus, lower linear energy transfer (LET), and are positively charged.

Although the LET is lower, protons can cause indirect ionization via nuclear reactions with semiconductor material. When protons collide with semiconductor material, they can cause a higher LET secondary ion (known as a recoil ion), which can have enough energy to cause a bit flip.

Protons are abundant in the inner and outer Van Allen radiation belts. The stronger inner belt resides 370 – 620 miles above the earth’s surface. Protons are not considered a significant concern for SEU in ground-based systems.

Figure 3 Proton particle striking silicon substrate shows spallation and generates a recoil ion, which has ionization along its path depositing charge, potentially impacting the transistor state. Source: Efinix

3. Neutrons

Neutrons are another secondary radiation particle created by cosmic rays. Like protons, neutrons are created when cosmic rays hit the earth’s atmosphere and cause nuclear interaction. Compared to protons, neutrons are slightly heavier, have a higher LET, and are neutral in charge.

Neutrons also collide with semiconductor material causing secondary high LET recoil ions, which carry a strong enough charge to cause an SEU. Neutrons have also a higher penetration value and can pass through common building materials like concrete.

At commercial aviation altitudes, the number of neutrons in the atmosphere is approximately 300 times higher than at sea level. Although ground-based systems are not as exposed, neutron-induced soft error rates are still a growing concern for data centers and industrial systems operating high-density FPGA arrays.

Figure 4 Neutron particle striking silicon substrate shows spallation and generates a recoil ion, which has ionization along its path depositing charge, potentially impacting the transistor state. Source: Efinix

4. Alpha particles

Alpha particles are a terrestrial particle caused by trace radioactive element decay in silicon packaging materials. Packaging materials contain uranium and thorium in chip packaging and solder bumps. When the trace radioactive element decays, it produces helium nuclei alpha particles.

Alpha particles have a light nucleus, high LET compared to neutrons and protons, and are positively charged. They have a very low penetration value. However, because the packaging materials are very close to the silicon substrate and because of their higher LET, alpha particles can cause SEUs in FPGAs.

Alpha particles in packaging were the original source of DRAM soft errors found in 1978. Since then, manufacturing improvements for packaging materials have helped reduce the probability of high LET alpha particles due to radioactive decay.

Figure 5 Alpha particle emitted from radioactive decay in the package and depositing a charge along its path can impact the transistor state. Source: Efinix

SEU challenges in FPGA architectures

An SEU event can impact several resources within the FPGA architecture, including configuration RAM (CRAM), look-up tables (LUTs), routing, registers, and embedded memory (block RAM). However, a bit flip may or may not impact the design’s functionality.

• In unused resources, a bit flip will not affect the functionality.
• In resources used for non-critical functions (like test circuits, image/video signal processing, or audio data), a bit flip may not impact the design significantly.
• A bit flip in mission-critical systems, like flight control, defense systems, medical systems and energy grid systems, can have serious consequences.

The following subsections describe how SEUs impact the most vulnerable FPGA resources: CRAM, routing, LUTs, registers, embedded memories, and the broader design functionality that depends on their correct operation.

Configuration RAM (CRAM)

From an architecture perspective, SEUs in FPGA CRAM have the most negative consequences. Unlike a processor or ASIC, where logic behavior is fixed in silicon, an FPGA’s function, including routing connections, logic functions, and I/O standard settings, is defined by the CRAM contents. When the FPGA powers up, the CRAM is programmed with a specific bitstream for a specific application.

The function is expected to remain constant. The CRAM controls settings related to routing, LUTs, and configuration of hard IP like transceivers and DDR controllers that are now a part of most FPGA architectures. CRAM SEUs are persistent compared to data path storage elements and can go undetected without built-in detection circuits.

Routing

FPGA routing connects logic, embedded memory, set/resets, and I/O to and from the programmable fabric. A high percentage of the CRAM is dedicated to routing.

A flipped routing bit could lead to a disconnect on a signal path, set/reset path, or clocking path where clock trees are more flexible via configuration of the FPGA. In addition to disconnects, a routing upset could unintentionally merge two independent signal nets, resulting in driver contention, illegal voltage logic levels, and logic corruption.

LUTs

LUTs are an FPGA’s fundamental logic primitive, each implementing an arbitrary Boolean function of four to six inputs. The truth table values are stored in CRAM. Compared to routing, a lower percentage of the CRAM is dedicated to programming the LUTs.

An SEU in CRAM that impacts an LUT alters the truth table and can result in unanticipated results for a specific input state. For example, in a 4-input LUT, inputs of 1010 may be configured to output a 1. An LUT bit flip at address 1010 results in an output of 0, which could be a similar result for another combination of inputs, resulting in a missed condition or trigger, or incorrect control state calculation.

An unexpected bit flip can result in logic that enables an external I/O tri-state, or changes a voltage setting, drive strength, or termination, resulting in external I/O conflicts, poor signal integrity, and potential damage to other board components.

Registers

Registers are fundamental elements within FPGA architecture. They can be used as up/down counters, store control states, store status, and pipeline or buffer data. Registers do not have a persistent state if they are clocked and are not loaded from CRAM. Therefore, a register bit flip can be benign if it’s buffering non-critical data.

The corrupted data may make its way downstream and have no consequences. Incoming correct data to the register is then loaded on the next clock cycle. However, a bit flip in a state machine could put the state machine into an unknown state, freezing the design’s functionality or triggering an unintended action. A status register bit flip could trigger a similarly unwanted action.

Embedded memory (block RAM)

Block RAM is like a register in terms of SEU impact. A bit flip may not persist, depending on the functionality (look-up table, data buffering, or soft processor memory). Block RAM is not loaded from CRAM but can be initialized when you program the FPGA with a bitstream. If not initialized, the block RAM contents are 0 after the FPGA enters user mode.

Block RAM stores values that the design actively reads, writes, and depends upon during normal operation. The consequences of a bit flip depend on the block RAM use. For example, a bit flip can propagate downstream in video, image, or audio buffering applications without harm.

However, a bit flip within a stored soft processor program may have consequences like a control register where the executing software may branch to an unexpected area of code. A bit flip in block RAM that stores DSP coefficients can lead to a computational error that manifests itself as inaccurate results for an AI LLM or persistent unwanted noise in a filter.

SEU impact on FPGA functionality

The cumulative effect of uncorrected SEUs across CRAM, routing, LUTs, registers, and block RAM is a gradual and silent degradation of the design’s integrity. A single SEU could lead to a hard failure immediately but usually it will be unambiguous. Accumulated SEU failures follow a probabilistic profile.

The first upset may be functionally insignificant, the second may alter behavior in a rarely exercised path, and the third may corrupt a critical state register in a way that cascades into a system-level failure. This accumulation without detection or a means to correct it can result in increasing failure probability over time.

Mik Ichiba is principal field applications engineer at Efinix. He is a seasoned semiconductor and embedded systems professional with more than 30 years of experience spanning hardware architecture, PCB design, ASIC development, FPGA architecture, and system-level engineering. Throughout his career, Mik has worked across the hardware design lifecycle, helping organizations translate complex technical requirements into practical, high-performance solutions.

Editor’s Note

This is Part 1 of the mini-series about SEU challenges in FPGA architectures. Part 2 will cover SEU detection, recovery, and validation for FPGA applications that require robustness and predictability in ground-based and terrestrial applications.

Related Content

• Using FPGAs in mission-critical systems
• Rethinking the Logic-Routing Tradeoff in FPGAs
• Understanding Single Event Effects (SEEs) in FPGAs
• Enhancing robust SEU mitigation with 28-nm FPGAs
• Learn about SEU Immunity in Terrestrial FPGA Applications

The post FPGA architecture: Radiation particle types and single event upsets (SEUs) appeared first on EDN.

This circuit exemplifies the thesis that the 555 is to analog timing what the op-amp is to analog “everything else”.

In any contest to see which is easier to manually program, digital potentiometers (dpots) suffer a big handicap when compared to traditional electromechanical pots.

No knob.

But henceforth, maybe that handicap won’t matter so much. This Design Idea implements a variable frequency oscillator circuit that produces dpot up/down steps. It generates step rates from zero to 20 Hz together with a separate up/down step direction signal. Both are controlled by simply (and quickly) twisting one knob on an inexpensive linear potentiometer (e.g. Bournes PTD90 series) a fraction of a turn.

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

Voila! There’s that long lost and longed for dpot knob at last! See the Figures that follow for how it works.

Figure 1 Current-to-frequency converter U1 generates dpot clock pulses at 20 Hz-0-20 Hz, controlled by the sum of Q1+Q2 collector currents set 0 to 5 µA by R1. A1 sets the up/down step direction.

0 µA = 0 Hz corresponds to R1’s wiper centered at (or near) the midpoint of travel, and 20 Hz to both its clockwise and counterclockwise limits (Figure 1). Comparator A1 sets the dpot step direction to UP if R1’s wiper is clockwise of midpoint, DOWN for counterclockwise (Figure 2).

Q1 sources the majority of current to U1 for UP steps, and Q2 takes over for DOWN. The Vpp amplitude of the sawtooth waveform on C1 is set by the R7/R8 and 555 internal dividers to ~250 mV.

Figure 2 This graph shows the dpot step rate and direction as a function of R1.

R1’s rest position is (anywhere near) midpoint where step rate = 0. Programming a new setpoint is done by the following steps.

1. Turning R1 in the desired direction until stepping begins at a rate appropriate to the size of the intended setpoint change.
2. Then gradually slowing the step rate to dead stop by returning R1 to midpoint as the new setpoint is approached.

Done. 

With a “bit” of practice, a U2 setpoint change of 127 steps (maximum for the 7-bit resolution AD5220) can be accurately completed in less than 10 seconds. And if you feel the need for speed beyond that, there’s nothing easier. Just back off on C1. Max step rate = 20Hz/C1 for C1 in µF.

Stephen Woodward‘s relationship with EDN’s DI column goes back quite a long way. Over 200 submissions have been accepted since his first contribution back in 1974.  They have included best Design Idea of the year in 1974 and 2001.

Related Content

• DPOT push up/down
• Finger-friendly DPOT pushbuttons do ups, downs, and dittos
• Digital potentiometer simulates log taper to accurately set gain
• Push to increase, decrease a digital potentiometer
• Synthesize precision bipolar Dpot rheostats

 

The post Digital pot programming with a twist appeared first on EDN.

Beyond low-power design and beyond multi-threshold-voltage libraries, clock and power gating, and voltage-frequency scaling lies the strange land of ultra-low-power systems. Here, power comes from tiny, semi-permanent batteries or energy scavenging, and it comes in microwatts or nanowatts, not milliwatts.

For system-on-chip (SoC) designers, this is the alien realm of ultra-low voltage (ULV): supply voltages near or below transistor threshold voltages. In this realm, many things are unfamiliar to conventional SoC designers. Foundational IP must be different. Familiar-looking tool flows may hide important differences in tools and skills. New challenges appear—threats that could sink a project.

ULV design explored

All differences in ULV design begin with the definition: ULV circuits use a VDD near or below the threshold voltage of the process’s MOSFETs. This leads to several important effects.

First, of course, is energy savings, the whole reason for ULV design. ULV works because instantaneous power is quadratic in supply voltage. So, the instantaneous power consumed when a circuit is active, and hence the energy required to complete a task, can be significantly lower at lower VDD.

Usually, designers will talk not about power consumption, but about the energy required to complete an operation, typically in nanoJoules. This is a preferred metric because, in ultra-low-power systems, ULV SoCs are usually quiescent for long periods, wake to perform specific tasks, and then reenter their trance. This activity pattern makes peak and average power figures poor indicators of energy consumption and, therefore, battery life or drain on energy scavengers.

But this energy benefit comes with challenges. Near threshold voltage, a MOSFET gate exerts only weak control over channel current. Leakage can be high, and the difference between ION and IOFF is small.

Maintaining the separation—the values of 1 and 0—throughout each net’s stages and across clock trees becomes a fundamental undertaking for the design team. The separation is already low, and other factors conspire against it. Interconnect parasitics, noise, and process variations can prevent circuits from working reliably. So, ULV design requires special measures.

Foundational IP

One of the first challenges designers will face is that conventional low-power libraries will not work for most ULV designs. Cells in standard libraries may be optimized for performance or packing density, but not for operation at ultra-low voltages. Some cells in the library are likely to fail or become unreliable simply because they cannot maintain the distinction between 1 and 0, even under ideal conditions. Add in parasitics, noise, and variations, and the library cells cannot cope. New, custom cell designs are needed.

In addition, some cells, such as high-fan-in gates, may work correctly but impose so much delay that they become useless. Such cells need to be eliminated from libraries. Other cells—ULV-level shifters, in particular—must be designed for the specific voltage range the design requires.

SRAM is another problem. The standard 6T SRAM cell usually cannot perform reliable reads and writes at ULV. Adding custom assist circuitry can help, as can simply enlarging the bit cell. The dual-rail design will work better (Figure 1). And some designers avoid the issue by making the SRAM a high-voltage island surrounded by level shifters, sacrificing energy efficiency for simplicity.

Figure 1 The dual-rail SRAM design highlights array on HV, periphery on ULV, and level shifter on the WL path. Source: Faraday Technology

Fine-grained characterization

Cells that work at ULV are necessary, but far from sufficient. Traditional delay modeling at a few process corners is hopelessly inadequate to achieve timing closure in a ULV design. In this voltage region, delay can vary exponentially with voltage, often in a non-Gaussian distribution. A traditional approach using a few corners would result in hopelessly large design margins.

We have found that fine-grained characterization of the foundational libraries, using voltage increments no larger than 50 mV and often finer, is a minimum requirement. This data must be captured in an advanced format such as Liberty Variation Format with Moments (LVFM). This allows statistical timing tools—using knowledge of the intended supply voltage range of the finished system—to produce design margins that are not overly pessimistic.

So, use knowledge of the intended supply voltage range of the finished system to produce design margins that are not overly pessimistic (Figure 2).

Figure 2 This data must be captured in an advanced format such as LVFM. This lets statistical timing tools produce design margins that are not overly pessimistic. Source: Faraday Technology

The bottom line for design teams is that ULV SoC design requires custom ULV foundational libraries, characterized over the expected operating range with very fine granularity.

Tool flow

Fortunately, ULV SoC design can use standard modern synthesis and place-and-route tools compatible with the LVFM format (Figure 3). But the standard flow still requires additional ULV expertise. For example, the synthesis tool must support the custom ULV libraries.

Figure 3 Standard Tools must possess critical ULV expertise. Source: Faraday Technology

All tools must recognize that, at ULV, timing will be extremely sensitive to routing paths due to both parasitic impedance and noise. Static timing tools must be variation-aware and able to consume LVFM data to exploit the libraries’ fine-grained characterization and minimize design margins.

Special attention must also be given to noise: crosstalk, supply transients, and even substrate noise. This may come down to the designers’ skill in floorplanning and in guiding placement and routing tools to anticipate and avoid noise sources.

The concluding steps

The ULV SoC design requires additional work to reach signoff. But then, both silicon bring-up and manufacturing test also have special requirements at ULV. Test equipment needs high accuracy at low voltages and, of course, a low-noise floor. So, load boards must be designed with extra care about leakage and parasitics.

During both silicon evaluation and manufacturing test, pay special attention to the power-on reset sequence across the entire operating voltage range, as it’s particularly vulnerable in ULV designs. Also, carefully test those ULV-level shifters.

Finally, the OSAT organization or internal manufacturing test facility must use the advanced binning strategy. Because process variations—even across a wafer—are so significant at ULV, it’s necessary to perform accurate voltage-speed binning (Figure 4). This separates chips that meet the requirements across the intended operating voltage range from those that work only at higher voltages.

Figure 4 Accurate voltage binning separates chips that meet requirements across the intended operating range from those that work only at higher voltages. Source: Faraday Technology

Why ULV expertise matters

ULV design facilitates SoCs that can operate almost indefinitely on tiny batteries or scavenged power. Custom libraries, fine-grained characterization, advanced design tools, and ULV-experienced designers make these projects achievable. Moreover, deep foundry and OSAT relationships make volume production realistic.

Some large design groups have these resources, expertise, and relationships in-house and can confidently undertake ULV SoC designs independently. But in many cases, an organization will want to deploy its assets across the overall low-energy system rather than to the specialized needs of the SoC design. In these cases, a traditional SoC design team can partner with an organization with extensive ULV experience.

The right ULV expert must be ideally positioned to partner with a traditional SoC design team entering ULV land. The land is indeed strange and strewn with risks. But with the right partner, it’s the land through which the path to technical and commercial success lies.

C.H. Chien has dedicated 33 years to IC design; his industry experience includes IP development and IC design flow. He also has 10 years of experience managing overseas R&D teams. Chien worked as a director at MediaTek and GlobalFoundries before joining Faraday Technology Corp.

Related Content

• Low power design is here to stay
• Scaling the Power Wall: Low-Power SOC Design
• Designing with ultra-low voltage MOSFET arrays
• The why, where and what of low-power SoC design
• Low Power Design Techniques, Design Methodology, and Tools

The post A design path to success exists for ultra-low-voltage SoCs appeared first on EDN.

Taking various considerations into account, the theoretical advantage of the spread bit PWM can be challenging to translate into practice.

A recent Design Idea (Reference 1) addressed the implementation of digital-to-analog converters using both common “clustered-bit” and less common “spread-bit” pulse-width modulation (PWM) techniques. Within a repetitive clustered PWM cycle, all of the ones appear in succession, as do all of the zeroes. In the spread PWM, the ones and zeroes are distributed more or less evenly within a cycle.

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

The clustered PWM tends to concentrate energy at lower frequencies, while the spread PWM moves energy towards the higher frequencies, allowing for faster-settling analog ripple-suppression filters. Given PWMs with individually-customized filters of the same complexities, clocks and cycle periods, the latter has clear advantages. Such is the case for hardware-based implementations such as FPGAs. However, while most microcontrollers can advance a clustered-bit PWM with the speed of their CPU clock, they cannot do so for a spread PWM. Effective clocks for these PWMs are slower because a microcontroller must implement them with multiple CPU instructions.

Clocks are further slowed by any code required to support features other than the PWM. Note that all code blocks must execute in invariant periods of time to prevent jitter from degrading the accuracy of the output. So including interrupts in the code is problematic. Another concern is the error which accrues to unequal rise and fall times, leading to mismatched logic one and zero durations. In a clustered cycle, there is only one rising and one falling transition, leading to an error considerably less than one bit. Unfortunately, the multiple transitions in a spread cycle make this type of PWM more subject to this type of error, which will be worst at a 50% duty cycle.

This all being said, the prior article investigated a claim that a microprocessor-implemented spread-bit PWM with a single resistor-capacitor pair filter outperformed a clustered-bit PWM with a three component-pair filter. This claim was shown to be true only for PWMs of 16 bits or more, and then only for a microcontroller which supported no features other than the PWM. But it’s unfair to tie one hand behind the back of the spread PWM, limiting it to first-order filters. This Design Idea compares spread and clustered alternatives driving individually customized filters of the same third order three-R/C-pair complexities.

The rules of the game

The b-bit PWMs discussed here can be thought of as having repetitive sequences of length N = 2b, where 1/N is the PWM resolution. N is an integer, but b needn’t be one for the clustered type. For the spread PWM, however, b typically is an integer for reasons of coding efficiency. See a discussion of why and of one way to code a spread-bit PWM in Reference 2.

Analog filters are employed to suppress PWM waveform-induced ripple. They exhibit a settling time in response to a duty cycle (DC) change. Some particular DC change will yield the maximum settling time TS to within VST of some fully settled voltage, and some duty cycle DC will produce the absolute maximum steady state error Vrip due to the ripple.

I’ve required that Vrip = ½ · 1/N and that VST = 1/N. Optimized-for-settling-time clustered-bit PWM filters are covered in Reference 3 and are easily designed. For the design of optimized spread-bit 3rd order filters (Figure 1), I’ll briefly describe the math involved at the end of his Design Idea.

Figure 1 These first (left) and third order (right) low-pass analog filter structures are buffered with op amps because their inputs employ resistors of high values. This is done to limit the errors imposed by the unequal resistances (Reference 4) of the logic high and low outputs of ICs such as the 74AC04 which drive the filter inputs.

Comparisons

The graph in Figure 2 is based on the data in Table 1. We see the expected superiority in settling time of the spread approach in comparison to the clustered alternative for PWMs with the same b (and therefore N) values and a clock frequency of 1 MHz. This relationship also holds for different frequencies as long as the clocks are identical.

Figure 2 In this comparison of b-bit PWMs clocked at 1 MHz, spread and clustered PWMs are investigated with individually optimized third order filters compliant with the information in the “Rules of the game” section. Additionally, the spread with a first order ( one R, one C ) filter (see Figure 1) is shown for reference. With third order filters, the improvement in settling time of the spread over that of the clustered PWM is apparent and grows with b and N.

Number of bits	Settling time (mS), spread, first order filter	Settling time (mS), spread, third order filter	Settling time (mS), clustered, third order filter	Spread/clustered improvement, third order filters
2	5.00E-03	3.09E-03	3.32E-03	1.08
3	1.80E-02	7.31E-03	1.01E-02	1.39
4	5.20E-02	1.65E-02	2.93E-02	1.77
5	1.34E-01	3.89E-02	8.32E-02	2.14
6	3.29E-01	9.29E-02	2.34E-01	2.52
7	7.78E-01	2.00E-01	6.53E-01	3.27
8	1.80E+00	4.23E-01	1.81E+00	4.28
9	3.74E+00	8.89E-01	4.98E+00	5.60
10	8.42E+00	1.87E+00	1.36E+01	7.28
11	1.87E+01	3.94E+00	3.71E+01	9.40
12	4.13E+01	8.32E+00	1.00E+02	12.07
13	9.03E+01	1.87E+01	2.71E+02	14.47
14	1.85E+02	4.02E+01	7.28E+02	18.11
15	4.00E+02	8.40E+01	1.95E+03	23.21
16	8.61E+02	1.74E+02	5.21E+03	29.88
17	1.84E+03	3.61E+02	1.39E+04	38.36
18	3.94E+03	7.50E+02	3.68E+04	49.09
19	8.01E+03	1.56E+03	9.75E+04	62.46
20	1.70E+04	3.43E+03	2.58E+05	75.14
21	3.59E+04	7.15E+03	6.80E+05	95.12
22	7.58E+04	1.52E+04	1.79E+06	117.43
23	1.59E+05	3.11E+04	4.71E+06	151.57
24	3.23E+05	6.33E+04	1.24E+07	195.18

Table 1 The data in this table forms the basis of the graphs shown in Figure 2.

A comparison based on identical clock rates would be appropriate if the two PWM alternatives were implemented in hardware, such as with an FPGA. But a microcontroller implementation of the spread, unlike that of the clustered, requires code execution. Comparatively, a microcontroller’s spread clock frequency is lower than that of the clustered (which requires no code to support an initialized, constant duty cycle PWM), especially if the microcontroller is performing tasks in addition to the spread PWM implementation.

Using the data

Defining a PWM whose full-scale output is “1” starts with specifying its 1 / N = 2-b resolution. With a 1 MHz clock, a PWM’s b bits correspond to points on each of the settling time curves in Figure 2. These are the maximum settling times TS, 1MHz to an error of 1/N. For a desired settling time of Tdes ≠ TS, 1MHz, the clock frequency must be changed. Defining a frequency scaling factor FSF equal to TS, 1MHz / Tdes, the PWM clock PWMclk becomes FSF · 1MHz.

If the clustered PWM has been selected, the spreadsheet in Reference 5 can be used to design the filter. Its parameter peak-peak Ripple, Fraction Frac of Full Scale should be set to 1/N, and the parameter PWM frequency, Hz to PWMclk/N. This spreadsheet executes the job with the press of a button, and it also runs an LTspice simulation of the filter’s worst-case transient response and ripple with the press of another button.

But if the spread PWM with a third order filter is selected instead, things are more complex (the first order spread PWM was discussed in Reference 6). Table 2 supplies three pairs of resistor and capacitor values to be used to implement a third order filter. These values will need to be modified to meet certain requirements. Recalling FSF, the actual component values are the table’s capacitor values divided by FSF · ZSF and the table’s resistor values multiplied by ZSF. ZSF is a positive, unit-less impedance scale factor which can be selected to meet requirements’ needs.

Number of bits	N ( 1/resolution)	r1, ohms (c1 = 10nF)	r2, ohms (c1 = 10nF)	r3, ohms (c1 = 1nF)
2	4	163.1000885	71.68292585	427.1087404
3	8	343.433862	271.9382005	828.4900535
4	16	716.8099067	681.854738	1497.328378
5	32	1444.093716	1398.000657	2966.654472
6	64	2816.731051	2186.864174	6876.068023
7	128	5619.092479	4103.426809	14167.24162
8	256	11229.51857	7684.085243	29082.22862
9	512	22464.62272	15027.67815	58621.97919
10	1024	45100.99781	27402.70118	120390.8368
11	2048	90360.13359	53513.94391	242063.9576
12	4096	182059.6186	99434.32312	490140.5768
13	8192	368094.4499	184124.8578	986470.2649
14	16384	736189.1063	368249.819	1972941.083
15	32768	1466466.446	755969.6418	3940496.058
16	65536	3005457.305	1320906.538	7870364.119
17	131072	5976310.761	2716759.439	15771899.07
18	262144	11952685.17	5433547.811	31543966.12
19	524288	24043631.67	10567240.53	62962842.83
20	1048576	47816245.75	21736693.78	126190392.7
21	2097152	95636270.97	43475105.66	252390759.7
22	4194304	191158658.6	86898441.34	504480973.5
23	8388608	384771591.2	169108145.2	1007597919
24	16777216	741230589.8	427594752.1	1990907707

Table 2 This table’s prototypical component values can be as-needed modified to implement a third order, spread-bit PWM filter (see text and Figure 1).

One of the requirements is that r1 should be large enough to swamp out the errors due to the difference rdiff between the logic high and logic low resistances of the digital ICs driving r1. A little math shows that this means that r1 > rdiff · (N -1) / 2 for an error of less than 1/ (2·N) = Vrip.

Don’t drive the circuit directly from a microcontroller, whose outputs generally won’t swing adequately close to the rails because of voltage drops across the IC’s bonding wires that accrue from the device’s supply currents. Consider buffering the output with a 74AC04. Five 74AC04 inverters connected in parallel and powered from 3V or more have a maximum rdiff of 9 ohms and a far lower typical value.

Another requirement is that the sum of r1, r2 and r3 should not be so large as to incur voltage drops in excess of Vrip due to op amp input current. All resistors should be metal film. As for the capacitors, ceramic NPO / C0G and polyester film types are sufficiently stable with temperature and voltage. Capacitor values should be more than 330pF so as to swamp out PCB and op amp input capacitances.

The freedom to choose a ZSF value might not be sufficient to meet the listed requirements. The addition of an op amp buffer stage (see Figure 3) between the 74AC04 and the filter transfers the filter’s r1 > rdiff · (N – 1) / 2 requirement to the buffer stage where it can be more easily met; the filter is now being driven from a low dynamic, constant- impedance op amp output.

Another way to ease requirement satisfaction is to sum the outputs of a “least significant” and a “most significant” PWM, also shown in Figure 3. This relaxes the r1 > rdiff · (N – 1) / 2 requirement to r1 > rdiff · (sqrt(N) – 1) / 2 and speeds settling time by a factor of sqrt(N).

Figure 3 In this circuit, ra, ca and U1 provide a means to eliminate the spread filter’s r1 > rdiff · (N – 1) / 2 requirement. Optionally, the entire circuit allows the addition of contributions from the outputs of separate PWMs weighted by factors of 1/257 and 256/257. It is recommended that the MS PWM be buffered by five 74AC04 inverters in parallel and the LS PWM by a single inverter.

A spread third order filter math overview

This section is supplied for completeness and can be skipped if desired.

The following is the transfer function of a third order low-pass filter, all of whose poles are constrained to have identical real parts so that they contribute more or less equally to the overall settling time.

H(s) = .5 · ω03 / Q / [ ( s + .5·ω0/Q ) ·  ( s2 + s·ω0/Q + ω02) ]

A worst-case settling time occurs when the filter input transitions at t = 0 from DC = 1 to DC = 0. The time domain transient response is calculated using the following equation.

ytr(t) = e-a·t · [ ( cos(a·β·t) – 4·Q2 ) / β2 –  sin(a·β·t) / β ]

where a = .5·ω0/Q  and  β = sqrt(4·Q2 – 1)

The biggest ripple occurs, perhaps surprisingly, with the input of a single one (or zero) in a cycle.

x(t) = 1

for (k · N) · T    ≤   t   ≤    (k · N + 1) · T, k = 0, 1, 2…, and T = 1/PWMcllk

x(t) = 0

otherwise.

This is well approximated by a truncated Fourier series.

x(t) = 1/N + (2/N) · Σ sinc ( π·k/N ) · cos ( 2·π·k·(t – T) / (N·T) )

where k = 0, 1, 2… 15.

The resulting steady state output ySS(t) is obtained by multiplying the amplitude and time-delaying each harmonic in x(t) by amounts determined by H( 2·π·k·j / (N·T) ). The total output y(t) is the sum of ytr(t) and ySS(t).

To design the filter, the maximum absolute values of ySS(t) – 1/N are constrained to be less than .5/N. They are examined for Q values between .5 and 2, and solved in each case for ω0. That Q, ω0 value pair is selected which corresponds to the smallest settling time of y(t) – 1/N to an absolute error less than 1/N.

The numerical values of H(s) now being determined, its analytic form expressed in terms of r1, r2, r3, c1, c2, and c3 is examined and solved through numerical techniques to obtain the resistor values (for the capacitor values shown) that appear in Table 1.

Conclusion

There’s no question that the spread PWM offers a substantially shorter settling time than the clustered alternative when same b-bit PWMs are driven by identical clocks and succeeded by topologically similar but individually optimized filters. The ratio of improvement increases with the number of PWM bits. If a PWM is to be implemented in hardware such as an FPGA, the spread PWM is probably the better choice.

The caveat comes when a microcontroller is doing the implementation. A clustered PWM can run at the CPU clock rate. The spread PWM effective clock is slower, with this type requiring the execution of X instruction cycles, including that needed to implement an infinite loop. So, the spread PWM clock is the CPU clock divided by X, and its filter’s settling time will be increased by that factor X.

Clock period and settling time are further increased if functions other than the PWM are to be implemented. And care must be taken to ensure that PWM code execution occurs at a consistent rate; a jittery clock will degrade accuracy. Accordingly, implementing interrupts is problematic.

Another concern is the error which accrues to unequal rise and fall times, leading to unequal durations of logic ones and zeroes. In a clustered cycle, there is one rising and one falling transition only, leading to an error considerably less than one bit. Unfortunately, the multiple transitions in a spread cycle make this type of PWM more subject to this type of error, which will be worst at a 50% duty cycle.

When considering PWMs with larger numbers of bits (16, for instance), minimized settling times favor the approach of using a pair of resistors to sum the contributions of two independent 8-bit PWMs. This PWM pair’s filter can settle 256 times faster than a single 16-bit PWM’s filter can do. Most microcontrollers support a pair of independent clustered PWMs running off the same counter, an approach which could be duplicated in an FPGA.

But spread PWMs, whether in hardware or on a microcontroller, demand entirely independent means of support. When these considerations are taken into account, it can be seen that the theoretical advantage of the spread bit PWM can be challenging to translate into practice.

References:

1. Implementing a DAC: The battle of the PWMs
2. Ibid
3. Custom design PWM filters easily
4. Ibid, see the SN74AC04-induced errors section.
5. Ibid
6. Implementing a DAC: The Battle of the PWMs

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

Related Content

• Implementing a DAC: The battle of the PWMs
• Custom design PWM filters easily
• A nice, simple, and reasonably accurate PWM-driven 16-bit DAC
• Parsing PWM (DAC) performance: Part 1—Mitigating errors, Part 2—Rail-to-rail outputs, Part 3—PWM analog filters, and Part 4 – Groups of inhomogeneous duty cycles

The post DAC implementations: The spread-bit PWM strikes back appeared first on EDN.

A production-ready root-of-trust and security orchestration solution provides dedicated hardware-level security for mission-critical data center and AI system-on-chips (SoCs). This enterprise-grade solution also accelerates design deployment with a complete hardware and software integration framework that includes dedicated drivers, APIs, and system-level security applications.

Rambus’ CryptoManager Root of Trust provides dedicated hardware-level security in an SoC design by combining a secure RISC-V processor, protected memory, secure key and data storage, cryptographic accelerators, and secure interfaces.

CryptoManager operates alongside an unmodified open-source Caliptra Project core, mediating interactions between the Caliptra Project core, the host processor, and other SoC components. This ensures security-sensitive operations remain within a protected boundary while extending trust across the wider platform.

CryptoManager’s root-of-trust and security orchestration are interoperable with Caliptra, an open-source security framework for silicon root of trust designed for integration into data center-class SoCs. Originally an Open Compute Project (OCP) initiative, it’s currently developed within the CHIPS Alliance.

Caliptra combines hardware, firmware, and specifications to provide a common foundation for device identity, measured boot, and attestation across CPUs, GPUs, AI accelerators, DPUs, networking devices, and other infrastructure components.

“As the Caliptra ecosystem gains momentum, organizations need a practical path to deploy scalable and supportable security solutions in demanding production environments,” said Simon Blake-Wilson, senior VP and GM of silicon IP at Rambus. “CryptoManager Root of Trust supporting the Caliptra specification provides the hardware, software, advanced protections and commercial support needed to accelerate deployment of differentiated enterprise-grade security that is interoperable with the Caliptra framework.”

CryptoManager Root of Trust combines enterprise-grade security with simplified integration and certification readiness for data center and AI SoCs. Source: Rambus

CryptoManager supports classical, post-quantum, and regional cryptographic algorithms. It also provides advanced protections against side-channel and fault-injection attacks, as well as certification support for security standards such as FIPS 140-3 and SESIP.

Furthermore, CryptoManager employs specialized drivers and security applications to offer platform-level awareness, enabling security monitoring, policy enforcement, secure lifecycle management, and coordinated protection of critical system resources.

This platform-wide security awareness, combined with proven side-channel and fault-injection protections, facilitates cryptographic agility for a low-risk path to volume implementations of highly secure data center and AI semiconductor devices.

Related Content

• When AI Meets Hardware Security
• IoT security: Challenges and solutions
• Hardware Root of Trust Essential for AI Chip Integrity
• Hardware security verification must go beyond functional testing
• Hardware Security Requirements for Embedded Encryption Key Storage

The post Caliptra-enabled hardware security solution eyes AI SoCs appeared first on EDN.

PIN photodiode collects, counts, and discriminates alpha energies to determine residences’ radon gas-caused cancer danger degrees.

Back in late July, when I was working on last month’s published piece on radon gas analysis, I longed to see what was inside the battery-operated sensing device I’d recently started using.

But I resisted the temptation to fire up the spudger and screwdriver set, because:

• I’d bought it myself, for $100+, and
• I intended to continue using it long-term, since radon gas concentrations vary over time.

Even if I trusted my ability to disassemble it and then put it back together again in still-full-functional form (which I don’t), I didn’t want to interrupt the data-logging cadence even briefly.

But Providence seemingly intervened on my behalf, as counterbalance to my reticence. Less than a week after my post appeared, a PR contact from Chinese company X-Sense, who swore she hadn’t even seen my coverage yet, reached out to see if I was interested in reviewing its latest consumer-tailored smart radon alarm, the just-introduced XR0A-iR. The device is so new that it only showed up on the company website a few days ago, as I write this on September 10, 2026.

Spooky, eh?

I accepted the invitation with the as-usual qualifiers in such situations: that the company would not see my coverage until it appeared in publicly published form on EDN’s website, and that X-Sense would have no ability to influence the content either in-advance or post-publication. The PR contact agreed.

I also asked for two units; one for hands-on testing (for which I planned to recruit my next-door neighbor, both because he didn’t have one yet and because I wanted to get a non-techie’s take on activation and ongoing use) and the other to satisfy my own teardown curiosity.

Smart equals pervasive data access

X-Sense agreed again. And late last month, two units showed up at my front door. My next-door neighbor successfully activated his yesterday; stay tuned for his hands-on observations to come in a future post. And that same (yester)day, I took the other one apart.

X-Sense is a smart home device manufacturer of which I wasn’t previously aware. The company’s products are analogous to those (for example) of TP-Link, whose Kasa and Tapo temperature, humidity and fluid leak sensors I’ve dissected in recent months. X-Sense already had two radon sensors in its product portfolio, the XR0A-SR and higher-end XR0B-SR, but they’re standalone-use units. The XR0A-iR is its first “connected” radon-related product.

I’ll as-usual start with some outer box shots, accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes. Top.

Front.

Left side.

Back.

Right side.

And bottom.

Packet secrets

The first thing you’ll see after removing the box lid is a comprehensive and consumer-comprehensible (those adjectives rarely get used together, in a positive sense, at least!) user guide.

Underneath it is our patient.

Surrounded by two mysterious baggies.

I jest; they’re not mysterious, because they’re labeled. One, containing silica gel, I commonly encounter to absorb humidity, thereby keeping the electronics dry. The other, marked as indicating that inside it was activated charcoal, was a bit more of an initial head-scratcher.

But then I recalled the mail-in radon lab test (mentioned in my prior writeup) that my wife and I ordered prior to purchasing our home a decade-plus ago, and which looked something like this.

I rattle sound-suspected at the time, and subsequent research has confirmed, that inside it was activated charcoal, used both for short-duration testing and (interestingly, at least to me) for filtering radon out of well water. That said, it’s not recommended for ongoing residential-air radon gas cleansing purposes. Here, I’m guessing, it absorbs ambient radon gas at warehouses and retailer shelves that would otherwise end up on the device’s sensor, adversely affecting subsequent initial-powerup measurement results in the process.

Onward. Here’s our patient, now freed from its previous cardboard captivity. Top (note the grille; hold that thought).

Front.

Left side (note the vents).

Back.

Right (ditto).

And bottom.

Before beginning the dissection, here’s an obligatory company-supplied conceptual image of the supposed “guts”, that I know you all love so much (me too).

The battery compartment often effectively does double-duty as the pathway inside the device. Let’s see if it pans out again.

Those four screw heads, one at each corner, look promising. The unit specs a 2-year (and user-replaceable) battery life claim, by the way. Not too shabby!

Before proceeding, though, let’s zoom in on the always-informative FCC ID (2AU4DDDM).

And now for those pesky screws.

(Non-)adhesive (non-)impediments

Ladies and gentlemen, we’ve hit the jackpot!

Those white glue deposits at both flex cable-to-connector junctions initially gave me pause. Was I not going to be able to keep this teardown non-destructive, always my preference?

Not so “gluey” after all, it turned out. Never mind. Keep calm and carry on.

Let’s focus our attention first on the top panel and interior of the upper enclosure.

Four more visible screw heads suggest a way to detach the former from the latter. Let’s see.

Bingo!

And now for another perspective, after flipping the enclosure over.

Setting the top panel aside for the moment, we now see that two more screws hold the display assembly in place.

You know what comes next.

And there she goes.

Removing four more screws, I’m betting, will give us a glimpse of the display backside.

I’m on a roll! It’s usually at about this time of inflated self-confidence, by the way, when I short out something, or cut myself and bleed all over everything. Consider yourself warned.

This is not the ventilation grill you’re looking for

Now for the top panel, and maybe the most baffling aspect of this design. Look back at the earlier top-side overview shot, and you’ll see what appears to be a grille. We already know from the box-bottom notations that this is a passive diffusion design; no (noisy and battery-draining) fans, only natural airflow through the device. Does it flow through the top?

The fact that the documentation only notates the earlier-seen enclosure side vents as “air intake areas” is head-scratching. And when you look at the grille from the inside, you see a black piece of plastic nearly completely covering it. So “nope” is apparently the answer to my question.

So, then, why is it here at all? The earlier-mentioned high-end standalone XR0B-SR model has a speaker up top and behind the grill, for audible-alert purposes.

But it’s also got buttons up top, versus in the front with this particular model, so it’s not like X-Sense can reuse any particular assemblage piece across multiple models.

My only other possible conclusion is that the company is striving to establish a common cosmetic “look” across all models. To wit, ironically, I suspect that the purpose of that black plastic piece is to prevent ambient airflow from going in and/or out the top, forcing it to instead route from one side to the other, presumably over the sensor in the process. Other reader ideas are welcomed in the comments!

Speaking of which, that varying black foam-and-shiny silver plastic circular region up top, held in place by an also-plastic brace, looks promising as a potential radon sensor location.

Let’s see what’s inside it, after first perusing other varying-location perspectives of the overall internal assemblage. Front.

Left side.

Back.

And right side.

Sensing insights

I’ve delayed entry, thereby building suspense, more than enough at this point. Here goes nothing.

This looks promising.

We’ve hit pay dirt (although a subsequent Google search on the “CD2026MAR6729” mark wasn’t, alas, even remotely fruitful)!

Upside-down temporary reinsertion into the cavity affords us a closer perspective.

Again, referencing the bottom packaging information, which described the unit’s measurement method as “continuous alpha spectrometry”, this is, I believe (readers?) a solid-state PIN photodiode, described along with other possible implementation approaches in a useful online reference that I came across during my research.

As the acronym suggests, the heavily doped p-type and n-type semiconductor regions, used (among other things) as ohmic contacts, are separated by an intermediary un-doped intrinsic semiconductor region.

The conceptual visual similarity with a multi-pixel image sensor is likely already obvious.

In this case, however, where (i.e. in a particular x:y pixel grid coordinate combination) an alpha particle has struck the semiconductor medium isn’t relevant; that one has struck is all that’s necessary to determine. The sensor normally points downward; the surrounding plastic is obviously no functional impediment. In the following photo, I put the assembly back together so you can see the routing of the seeming single-wire (surprisingly, at least to me) harness out of it.

PCB details

We still haven’t found the system’s intelligence and wireless connectivity, however. The prior internal assembly front view image suggests there’s a PCB underneath the sensor. Let’s see.

Here it is.

Let’s next see what’s underneath that shiny plastic cover.

A mess of passives (along with a few five-lead ICs, likely single-package dual-transistor devices) is admittedly not what I expected to find. Then again, as I’ve confessed plenty of times before, analog is admittedly not my area of particular expertise.

Two more screws to go.

And the comparatively boring PCB backside is now accessible for visual perusal.

Yawn…unless you’re into switches, test points and/or battery terminals, that is. Let’s give the PCB frontside one more now-standalone look.

The combo 2.4 GHz Wi-Fi plus Bluetooth LE module at left, with a common-frequency, combo-protocol antenna sticking out of it, is the Ai-WB2-32S kit from a previously-unknown-to-me company called AI-Thinker. Is there something explicitly AI-related to this particular product (and/or the manufacturer, more generally)? Or is it just one of those cases nowadays where anything sounds more important if you tack “AI” onto it? The under-Faraday-Cage photo published at the webpage is woefully low-res, but hey, there’s also a spec sheet.

And at center is the system’s processing nexus, the 32-bit Arm Cortex M4-based N32L406MBL7 microcontroller from another new-to-me supplier, Nations Technologies. It has onboard flash memory and SRAM, thereby explaining why I don’t see any discrete memories on the PCB.

Last, but not least, after carefully putting everything back together, the device fired right up.

It’s a miracle!

That’s a wrap for today, folks. As always, reader insights are welcomed in the comments!

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

Related Content

• Radon: Level detection, risk determination, and as-needed mitigation
• Improve HVAC efficiency with accurate sensors
• My Geiger counter doesn’t count (sob sob)
• Design femtoampere circuits with low leakage, part 1 and part 2

The post Radon sensor embeds sizeable alpha particle detector appeared first on EDN.

When enclosure size and airflow constraints limit traditional bass‑reflex designs, passive radiators offer a smarter path to deep, controlled low‑frequency performance.

Audio engineers face a persistent challenge—delivering deep bass extension in compact, space‑constrained enclosures without resorting to unwieldy ports that introduce turbulence and design compromises. 

To address this, many have shifted from traditional bass‑reflex systems toward passive radiator (drone cone) topologies, which replace long ports with diaphragm‑based tuning elements that achieve low‑frequency response more efficiently.

This post will explore the mechanics of passive radiators, weigh their trade‑offs, and outline how to select the right approach for your next build.

How passive radiators work

At the heart of any passive radiator system lies the active driver, the true motor of the enclosure, converting amplifier power into acoustic energy. Its displacement dictates how much air is moved inside the box, setting the stage for low‑frequency behaviour.

Opposite to it sits the passive radiator—the drone cone—which visually resembles a standard loudspeaker but omits the voice coil and magnet. Instead, it functions as a mass‑loaded resonator: the trapped air volume inside the enclosure acts like a spring, driving the radiator in sympathy with the active driver’s motion to extend bass response without the turbulence of long ports.

Passive radiator vs. ported designs

When engineers weigh passive radiators against traditional bass‑reflex ports, the trade‑offs become clear. Passive radiators enable more compact enclosures by eliminating the need for long, tuned ports, and they completely sidestep the issue of turbulent airflow and audible chuffing at high excursions.

Their response carries a perceptibly steeper roll-off below tuning due to the compliance notch at the radiator’s free-air resonance, demanding careful tuning and mass adjustment to achieve the desired performance. By contrast, ported designs typically require larger internal volume to accommodate the port and maintain smooth airflow, and while they risk turbulence at higher levels, their fourth‑order roll‑off often produces a more gradual, natural decay.

Ports are also simpler to implement, relying on standard tubing or slot dimensions, whereas passive radiators introduce greater design complexity but reward it with noise‑free operation and space efficiency. In practice, when a purpose‑built speaker is paired with a matching passive radiator, its low‑frequency performance can extend nearly an octave deeper—delivering exceptional bass response without the added space or turbulence of a tuned vent.

Figure 1 A comparison of bass roll‑off profiles shows the passive radiator dropping more sharply (~30 dB/octave) below tuning than the ported system (~24 dB/octave). It explain that the radiator’s steeper slope comes from the acoustic notch at free‑air resonance, while both remain 4th‑order high‑pass alignments in theory. Source: Author

Critical design considerations for builders

Designing with passive radiators demands careful attention to tuning and balance. The system’s tuning frequency can be adjusted by adding or subtracting weight from the radiator’s cone, a straightforward but crucial step in aligning low‑frequency response with the enclosure’s goals.

Many builders refine this further by attaching extra mass directly to the cone, a technique that shifts the resonance frequency with precision and allows deeper bass extension without altering cabinet dimensions—though care must be taken to avoid over‑loading the driver and reducing efficiency.

Figure 2 A passive radiator with an easily adjustable mass enables the design of extremely compact speaker systems capable of incredibly low-frequency output. Source: Dayton Audio

Equally important is the volume compliance ratio (δ), where the passive radiator’s displacement volume should be 1.5 to 2 times greater than that of the active driver, ensuring efficient energy transfer and preventing the radiator from bottoming out. Finally, builders often employ dual passive radiators mounted on opposing sides of the cabinet, a technique that cancels mechanical reaction forces and stabilizes the enclosure. This vibration‑cancellation approach has become especially popular in portable Bluetooth speakers, where compact form factors and mechanical stability are paramount.

Chamber considerations

Every passive radiator system relies on the enclosure chamber as the “spring” that drives the radiator. The trapped air volume inside the cabinet provides the restoring force, so the chamber size must be carefully matched to the driver and radiator parameters. Too small a chamber can raise the tuning frequency and limit bass extension, while too large a chamber can reduce control and efficiency.

In practice, builders balance chamber volume against radiator size and mass, ensuring the compliance of the air spring complements the driver’s displacement. This makes chamber design just as critical as cone mass or compliance ratio when aiming for clean, extended low‑frequency performance.

At its core, the passive radiator system is simply another expression of the Helmholtz resonator principle. In a ported design, the mass of air in the port oscillates against the compliance of the chamber air, producing resonance at the tuned frequency.

With a passive radiator, the cone itself replaces the air column, acting as the moving mass while the trapped air in the enclosure remains the spring. This substitution preserves the Helmholtz effect but eliminates turbulent airflow, enabling deeper bass extension in compact cabinets without the drawbacks of long ports (port tubes).

Figure 3 Large-diameter port tubes optimize bass response in the active resonator circuit but increase enclosure volume and introduce air-chuffing distortions that passive radiators inherently avoid. Source: Author

Additional considerations

Beyond the fundamentals, builders should also weigh practical details that shape real‑world performance. Passive radiators generally require greater displacement capacity than the active driver—typically 1.5 to 2 times more—to move sufficient air at low frequencies and avoid bottoming out under load. Excursion limits are equally critical, since radiators can lose control if driven beyond their mechanical capacity.

Designers also watch for unwanted resonance peaks in the mid‑band, often around 1–2 kHz, which can be tamed with damping materials or improved suspension structures. Unlike ports, radiators don’t provide airflow cooling for the driver, so thermal management becomes a factor in high‑power systems. Finally, measurement and simulation tools such as impedance sweeps or modelling software are invaluable for predicting system behavior and ensuring the radiator is properly matched to the enclosure.

Also, accurate parameter testing is vital when integrating passive radiators. What’s more, builders can rely on impedance sweeps, frequency response plots, and excursion measurements to confirm tuning and displacement margins. These tests not only verify that the radiator achieves its intended resonance without bottoming out, but they also expose mid‑band anomalies or thermal limitations. While simulation tools provide useful predictions, hands‑on measurement remains the most reliable way to validate radiator behavior in a real enclosure.

Figure 4 A datasheet snippet outlines the key technical specifications for the passive radiator. Source: PUIaudio

Material choices for passive radiators

The diaphragm material defines how a passive radiator behaves under load. Rubber and elastomer membranes dominate portable designs, offering flexibility, damping, and resistance to moisture. Polymer composites such as ABS or PET provide lightweight stiffness and cost‑effective molding, though they can fatigue under high SPL.

Metal plates—aluminum or steel—deliver precise mass and long‑term stability but add weight and require damping to avoid ringing. Hybrid laminates that combine rubber with metal or fiber composites balance compliance with rigidity, giving engineers a tuneable middle ground. Selecting the right material is ultimately a trade‑off between durability, acoustic control, and the enclosure’s performance goals.

Application matrix

Choosing between a passive radiator and a ported design depends on the priorities of the build. Passive radiators excel in ultra‑compact or battery‑powered Bluetooth speakers, where enclosure space is at a premium and port tubes would be impractically long. They are also favored in subwoofers that demand deep extension without sacrificing internal volume, and in applications where eliminating port turbulence or chuffing is critical.

Ported designs, on the other hand, remain the go‑to for high‑power, high‑SPL systems such as PA speakers, as well as budget‑focused projects where standardized tubing makes tuning straightforward. When enclosure size is not a limiting factor, ports offer a simple, effective solution with predictable performance.

Passive radiators and ported bass‑reflex designs each bring their own strengths to the table—radiators deliver compactness, vibration control, and noise‑free operation, while ports offer simplicity, predictable tuning, and gradual roll‑off at the expense of larger enclosures and potential turbulence. The decision ultimately rests on your design priorities: whether you value space efficiency and acoustic precision, or raw output and ease of implementation.

As you move forward with your projects, think about which trade‑offs align best with your goals. Are you crafting a portable Bluetooth speaker that demands stability and compactness, or a high‑SPL system where simplicity and sheer output dominate? Share your builds and design choices—I’d love to hear how you’re pushing bass performance beyond the port.

T. K. Hareendran is a self-taught electronics enthusiast with a strong passion for innovative circuit design and hands-on technology. He develops both experimental and practical electronic projects, documenting and sharing his work to support fellow tinkerers and learners. Beyond the workbench, he dedicates time to technical writing and hardware evaluations to contribute meaningfully to the maker community.

Related Content

• Cooling high-power LEDs
• Does global warming impact datacenter cooling?
• Liquid cooling fundamentals for high-power electronics

The post Beyond the port: Fundamentals of passive radiators appeared first on EDN.

Goldilocks and the Three Bears (and their porridge, beds and chairs) have got nothing on this high voltage design challenge.

Sometimes a client gets into areas of technology that go way over my head, but I manage to pick up a snippet here or there. This is one such case.

The requirement was to create an electron beam for which the beam energy would be precisely known. The measurement technique is diagrammed as follows (Figure 1).

Figure 1 Fairy tales and their application to electron beam energy (if-necessary reference)

Two curved metal channels were arranged in a circular path through which the electron beam was to be directed. Equal but opposite polarity high voltages would be applied as shown. When an electron source was aimed into one end of this structure, the path of that beam, i.e., the beam’s radius of curvature, would vary as a function of the applied high voltages.

By dint of equations that left me in the dust, when the high voltages and beam energy were a proper match, the electron beam would emerge at the output end where it would go on to serve its intended purpose. The beam’s radius of curvature under the electrostatic field would be just right, and the beam energy would be precisely known. If there was a mismatch, the electron beam would impinge instead on one metal plate or the other and not appear at the output.

The high voltage and voltage precision requirements for this thing were quite demanding. The dual power supply we made for this setup went from zero to 25 kV on each side and had a room temperature versus voltage temperature coefficient on the order of 1 ppm per °C.

Happily, it worked very well.

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

Related Content

• Researchers develop electron-based Airy Beam

The post Electron beam energy appeared first on EDN.

As systems grow, the knowledge needed to safely change them becomes harder to retrieve quickly, even when the design itself is sound. Models increasingly encode not just algorithms, but also assumptions, trade-offs, and system-level intent that accumulate over time. As ownership changes hands, understanding that intent becomes the bottleneck.

Consider a common engineering handoff: you are new to an existing project and are asked to update the braking system to support a heavier vehicle variant. The system works. The architecture looks intentional. But you were not part of the original design decisions, and before touching anything, you need to understand what is safe to change and why.

Compared to reading thousands of lines of code, being given a model offers a clear advantage. It exposes structure, makes data flow visible, and captures behavior in a form engineers can reason more quickly. For years, this has been a core strength of model-based design.

However, this advantage is now under pressure. Today’s software-defined systems are larger, more interconnected, and built across distributed teams, suppliers, and release cycles. Even with a well-structured model, engineers still need to reconstruct why signals flow a certain way, which subsystems own specific behaviors, which parameters are safe to modify, and where hidden constraints exist.

So, when that context is hard to recover, teams slow down. Review cycles expand. The risk of validation failures or schedule delays increases. This is not because the design is wrong, but because its underlying rationale is difficult to access quickly. Over time, this becomes an engineering scalability problem: critical knowledge lives inside the design but becomes harder to retrieve as systems grow more complex.

The challenge is no longer simply one of scalability, but of how engineers recover that context quickly enough to make the right change. This is the gap that shows up most clearly in engineering handoffs.

Walkthrough: Recover context in the ABS braking model

To see how this challenge appears in practice, consider an anti-lock braking system (ABS) model. The system runs, but the engineer has been asked to update the braking system to support a heavier vehicle variant. Before making that change, engineers first need to understand where the wheel-speed behavior lives and how it interacts with the rest of the design.

Figure 1 ABS demo regulating wheel slip (Desired Relative Slip) via a bang-bang controller (Controller) drives vehicle/brake dynamics (Vehicle Dynamics) with visualization (Visualization). Source: MathWorks

This opens sldemo_absbrake, a model that simulates vehicle dynamics under braking with a bang-bang controller. The example is small enough to follow end to end, but it raises the same questions that appears in production handoffs: What are the major pieces? Where does the behaviour live? Which blocks should be inspected before changing it?

Get the big picture

Start by building a system-level understanding of the model. Before inspecting individual blocks, click “Simulink Copilot Chat” on the “Simulation” tab of the toolstrip, and type: Give me an overview of this model.

Simulink Copilot returns a structured breakdown of the four top-level subsystems (Controller, Vehicle Dynamics, Visualization, and More Info), the high-level signal flow from slip reference to controller to braking dynamics to visualization, and the control strategy: bang-bang control on the slip error. Every block name in the response is a clickable hyperlink, so the explanation remains tied to the model canvas rather than floating apart from it.

Figure 2 Simulink Copilot generates a grounded overview of the open model, with hyperlinks to each subsystem and block. Source: MathWorks

Instead of digging through the model block by block, a working mental map is established. The model’s behaviour, major connections, and the part of the design worth inspecting before making a change are now clear.

Drill into a subsystem

The overview points to “Vehicle Dynamics” as the subsystem that handles braking physics. If a change could affect wheel motion, stopping distance, or slip, that is the area to drill down next. Instead of opening the subsystem and reading every block manually, right-click the “Vehicle Dynamics” block on the canvas and choose “Explain with Simulink Copilot” in the Simulink context menu.

Figure 3 Right-click any block and choose “Explain with Simulink Copilot” for a contextual explanation without typing a prompt. Source: MathWorks

Simulink Copilot generates a contextual explanation of the subsystem: its purpose, its inputs and outputs, and the internal structure that connects tire forces, brake pressure, wheel speed, vehicle speed, and relative slip. This is not a generic block description. It explains how Vehicle Dynamics is connected to this specific design, which is the context needed before deciding what to modify.

Find where a feature lives

Now suppose the design change requires extending or reviewing the wheel-speed calculation. There is no longer a need to start at the top of the model or guess which subsystem owns that behaviour. Ask the question directly: What components handle wheel-speed calculation?

Figure 4 Simulink Copilot identifies the specific blocks that implement wheel-speed calculation, each hyperlinked for one-click navigation. Source: MathWorks

Simulink Copilot returns the specific blocks involved, including sldemo_wheelspeed_absbrake, the integrator that computes wheel angular velocity, and the gain block that converts angular velocity to wheel speed. Each result is hyperlinked to a model element, enabling navigation from a design question to the implementation detail.

What this looks like in practice

Generate an overview, drill down into subsystems, and perform a targeted search: this becomes a repeatable three-step pattern for working with an inherited Simulink model. Start broad enough to understand the architecture, narrow the conversation around the subsystem that owns the behaviour, and then ask targeted questions that lead to the blocks that may need modification.

From there, follow-up questions can move from orientation to change impact:

• How does the bang-bang control strategy work within the context of this model?
• What outputs are visualized during simulation, and how do they reflect braking performance?
• What adjustments can be made to controller parameters to enhance braking response time?

Each response references the model itself: block names, signal paths, subsystem boundaries, and parameter values. The conversation builds on itself, so by the time the first edit is made, the process is no longer based on a disconnected search result. Instead, it provides a model-specific explanation of what the design does, how the relevant pieces fit together, and why they matter to the requested change.

Tips for better handoff questions

• Be specific about scope. “Explain the braking control logic” works better than “explain this model” once the relevant part of the inherited design has been identified.
• State the goal, not just the question. “I need to extend the wheel-speed calculation” gives Simulink Copilot context to focus on the behaviour that is changing.
• Reference blocks by name when possible. “Explain the Sum block labelled slip_error” is more useful than “explain the Sum block” because it anchors the question in the design.
• Use Deeper Insights for questions that require sophisticated reasoning. Reserve the more thorough analysis for decisions about design intent, subsystem responsibilities, or change impact.

Now return to the engineer at the start: you inherited a model, and you were asked to update the braking system to support a heavier vehicle variant, and the risk was not that the model lacked structure. The risk was acting before understanding the intent behind that structure.

A grounded conversation changes that first hour. The architecture can be mapped, the subsystem that owns the behaviour can be inspected, and the relevant blocks can be identified before making the change. That does not replace engineering judgment or validation, but it provides a faster, more defensible way to inform decisions for the next design change.

Amal Jayarajan Phillai is a product manager at MathWorks.

Related Content

• Accelerating development with model-based design
• Model-based design and early verification aid designers
• Early verification and validation using model-based design
• Understanding the specific use cases for Simulink and Stateflow
• Plan strategies for adopting Model-Based Design for embedded applications

The post You just Inherited a Simulink model you have never seen before. Now what? appeared first on EDN.

There’s a lot you can potentially do to boost your WAN’s downstream and upload speeds, as well as to minimize its latency. But only if your service provider lets you.

This is my final post in this series. Really. I promise! Like I’ve said before, I’ve learned a lot in the near-year that started last October, when an inadvertent cable cut led to chronic broadband and TV service outages. Four blog posts’ worth, apparently. But I’ll wrap up today. Really. I promise!

At the conclusion of last week’s third post:

• Debugging intermittent Comcast, part 1: Scenario-setting
• Debugging intermittent Comcast, part 2: Remediation details
• Debugging intermittent Comcast, part 3: Retrospective analysis

I’d been seduced by the Sirens’ Song of the Comcast technician, who, after swapping out some hardware, had confidently proclaimed “wait until you see how fast your Internet access will be now!” Unfortunately, although my connection was now rock-solid reliable, it wasn’t seemingly any faster than before. Why, I wondered? Thereby launching myself down the packet-hole into broadband-land (with apologies to Alice and the White Rabbit for the admittedly lame analogy). Recall upfront that I hadn’t yet done the necessary online research to realize that I was already running near the upper end of my location-determined Comcast-offered speed tier options.

Spectral extension and overlap

DOCSIS 3.1, I learned through my research, is theoretically capable of leveraging wire-based frequencies all the way up to 1,218 Mhz (original plans for further spectrum extensions up to 1,794 Mhz are now instead comprehended in subsequent-gen DOCSIS 4.0). In the process, though, it spectrally overlaps with MoCA 2.5 beginning at 1,125 MHz by default, at least (hold that thought for a dedicated-topic post to come, hopefully in the near future).

Recall, too, that I still had a point of entry (PoE) filter sitting ahead of the cable modem, initially a self-purchased and -installed standalone unit, subsequently integrated within the grounding block supplied by Comcast. In both cases, however, the specified low-pass cutoff frequency was only 1,002 MHz, matching that of the lingering two-way splitter in-between the filter and the cable modem (connection-shared with a CABLEcard receiver, therefore the splitter). And building on the fact that I wasn’t currently running MoCA anyway, I suspected that nobody else in my neighborhood was, either.

Why, then, did all the extra hardware “gifts” the technician had passed on to me at the end of his visit—standalone MoCA filters, two- and three-way splitters, etc.—have 1,002 MHz low-pass cutoffs, too, if DOCSIS 3.1 supposedly stretched to 1,218 Mhz? And what would therefore happen, I wondered, if I were to ditch the outside filter entirely, along with replacing the limited-frequency splitter in the furnace room with a spectrally wider alternative? There’s no better way to find out than to try it and see what happens, right? So that’s what I did.

Here again is the original outside setup:

Here’s my original in-the-furnace-room splitter:

And here are some snapshots of the original dataset, first as a benchmark result from my router.

Followed by a data dump leveraging my cable modem’s convenient second integrated Ethernet port.

Now let’s replace the filter-inclusive grounding block outside with a filter-less one.

And swap out the original furnace room splitter with one that spec’d operation all the way out to 2,450 MHz.

The outcome? Data suggestive of a degraded-performance response to the changes, actually. The benchmark results alternatively might simply reflect test run-to-run variability.

But the higher upstream signal power that the modem is being required to generate in the latter case is, as I first explained in Part 2, suggestive of higher channel noise level that it’s “fighting”.

Perhaps MoCA is operational somewhere in my neighborhood after all? Obviously, I immediately reversed course and returned to the original setup.

Router uniqueness and artificial constraints

The fact that I was “only” getting ~850 Mbps (average, ~890 Mbps peak) download speeds still nagged at me, particularly given that my upload speeds were notably exceeding Comcast’s estimates (43+ Mbps vs. 35 Mbps), and in spite of the fact that I’d best-case only be able to squeeze an additional 50 Mbps or so of downstream bandwidth out of the setup. My cable modem is a somewhat unique Netgear variant, the Nighthawk CM1100, which I’d first mentioned more than seven years back, with more in-depth coverage a year-plus later.

As I mentioned before, the Nighthawk CM1100 “only” implements 1 GbE connectivity, but it integrates two Ethernet ports, thereby (barely) rationalizing NETGEAR marketing’s “multi-gig” product claims.

The intent here is to optionally mate the CM1100 with a more advanced router containing dual Ethernet WAN connections, subsequently leveraging a feature known as “link aggregation”. But, as my research eventually revealed, this particular feature, not to mention the router’s broader 1 GbE (minus protocol overhead) claimed peak performance specs, were for naught “thanks” to Comcast’s unavoidable setting tweaks.

Here’s what Google AI Assistant, aggregating various info bits on the Internet that I’d already come across, spat back at me when I searched on the phrase “Xfinity 1 Gbit plan actually 800 Mbit CM1100”.

The reason your Xfinity 1 Gbps (1,000 Mbps) plan is maxing out at roughly 800 Mbps is because Xfinity explicitly limits the Netgear CM1100 to an 800 Mbps speed tier on their network.

Even though the Netgear CM1100 is a highly capable DOCSIS 3.1 modem with a theoretical multi-gigabit capability, Comcast’s official device compatibility lists cap this specific hardware for plans “Up to 800 Mbps” (previously rated for up to 945 Mbps). When an unapproved or downgraded modem is connected to a higher tier like the 1 Gig plan, Xfinity’s automated provisioning system pushes a default, restricted config file to the modem. This prevents it from pulling your full subscription speed.

Hardware and Network Bottlenecks

Beyond Xfinity’s strict software provisioning profile, your hardware setup likely has several physical bottlenecks preventing you from reaching 1 Gbps:

• Lack of a 2.5 Gbps Port: The CM1100 only features standard 1 Gbps (1,000 Mbps) Ethernet ports. Due to standard network overhead (headers, routing metadata, and packet loss), a single 1 Gbps port will max out at roughly 940 Mbps in a real-world wired environment.
• Link Aggregation Limits: While the CM1100 supports Link Aggregation (bonding its two 1 Gbps ports together to achieve 2 Gbps), Xfinity generally disables or restricts this feature on customer-owned modems. Furthermore, most consumer Wi-Fi routers do not support WAN Link Aggregation.

How to Fix It

If you want to get the full speed you are paying for, you have three primary paths forward:

• Downgrade Your Plan: Call Xfinity and drop your service to the 800 Mbps tier. Your CM1100 is perfectly optimized for this tier, you will save money on your monthly bill, and your real-world internet performance will feel exactly the same.
• Upgrade Your Modem: If you want to keep the 1 Gbps speed (or plan to upgrade to 1.2 Gbps in the future), you must purchase a modern DOCSIS 3.1 or DOCSIS 4.0 modem that features a dedicated 2.5 Gbps Ethernet port (such as the Arris Surfboard S33 or Netgear CM2000). This will allow Xfinity to push a “Next-Gen” provisioning profile to your house.
• Rent an Xfinity Gateway: You can opt to rent an Xfinity XB7 or XB8 gateway. These come equipped with native 2.5 Gbps LAN ports and are completely optimized for Xfinity’s over-provisioned gigabit speeds.

Unfortunately, as you already saw from the screenshots I shared last time, an “800 Mbps” plan isn’t offered at my particular Comcast service location. I’m also not interested in paying Comcast a monthly rental fee for the “privilege” of using Xfinity Gateway gear I’ll never own free-and-clear.

And regarding the “upgrade your modem” option, I now recall an email I received from the company in late May 2025 with the tantalizing subject line “Replace your equipment to get faster speeds – at no extra cost.” Here’s the body verbiage.

Good news

Bringing customers like you the best in-home WiFi experience is our top priority. That’s why we’re excited to give you faster speeds so your home can continue being everyone’s favorite binge, scroll, share, and stream zone.

Here’s the best part: These faster speeds are included with your current Internet plan at no extra cost.

Next steps

Your current internet equipment can’t deliver these new speeds, so we’ve compiled a list of compatible devices to purchase so that you can take advantage of the fastest speeds available to you. Click below to find a compatible device.

Find compatible devices

Or you can explore our Xfinity Gateway option, which is a modem + WiFi router in one with advanced security designed to deliver the fastest, most reliable coverage on our network.

Take action today so you can start enjoying faster speeds as soon as possible.

Thanks for being with us.

The “no extra cost” angle, perhaps obviously, was specific to the service tier I was paying for. The “replace your equipment” encouragement, on the other hand, was most definitely not “no extra cost”. And nowhere in the email, or the linked website page for that matter, did Comcast happen to mention Google AI Assistant’s tipoff that “when an unapproved or downgraded modem” such as my existing CM1100 “is connected to a higher tier like the 1 Gig plan, Xfinity’s automated provisioning system pushes a default, restricted config file” (known as a bootfile) “to the modem. This prevents it from pulling your full subscription speed”.

The information Google AI’s Assistant is sharing with me seems spot-on, by the way; an over-provisioned “800 Mbit” plan (if it theoretically existed as a service tier option for me) would likely deliver the ~890 Mbps peak download and ~43 Mbps peak upload speeds that I’m now seeing.

I’m more than a little irritated to learn that Comcast’s latest-version provisioning bootfile for CM1100, which downloads every time the modem connects to the network and overrides NETGEAR’s factory-default settings, is disabling my device’s dual-Ethernet facilities. I’m even more irritated to learn that the bootfile now also artificially restricts my modem’s peak speeds, which were previously unhindered.

And don’t get me started on the fact that Comcast wants me to drop several hundred dollars on a brand-new replacement modem with capabilities that the speed tiers available at my location can’t even leverage, discarding my perfectly good existing hardware in the process, just so I can take full advantage of the service I’m paying for.

Thanks but no thanks, Comcast. Thoughts, readers? Sound off in the comments!

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

Related Content

• Debugging intermittent Comcast, part 1: Scenario-setting
• Debugging intermittent Comcast, part 2: Remediation details
• Debugging intermittent Comcast, part 3: Retrospective analysis
• The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
• A quest for faster upstream bandwidth

The post Debugging intermittent Comcast, part 4: Broadband diagnostics appeared first on EDN.

New smart phones, earbuds and watches, this year with an added dash of memory price increases. It’s September in Cupertino again.

September 1 was Tim Cook’s last day as Apple’s CEO, after a 15-year tenure with that title. Hereafter he’ll be Executive Chairman of the board of directors, succeeded as CEO by John Ternus, former senior vice president of Hardware Engineering. And reflective of the changing of the guard, Cook was nowhere to be seen in this morning’s prerecorded launch event video, albeit in a brief cameo at the beginning.

Not because, I suspect, Cook’s got anything against product launches, although after having fronted so many of them by now, he’d certainly be entitled to a bit of burnout. Instead, I’m guessing he just wanted to make the passing of the baton as clean and obvious as possible.

Just like last year…and the year before it…and…Apple launched new and updated wearable and broader mobile products in September 2026 (which, I’ll note, has just started, so we might not be done with the month yet, far from the rest of the year). The biggest surprise this time around was that today’s unveilings weren’t the first in this year’s late-summer sequence, having been preceded by the release of new M-series SoCs and systems containing them late last month.

And speaking of M-series SoCs, there’s as-usual no shortage of commonality between those earlier latest-generation application processors for computers and high-end tablets and the one(s?) that rolled out today for high-end iPhones. Speaking of which…

The iPhone 18 Pro series

What do you do if rising DRAM and flash memory costs are clobbering your products’ bill-of-materials budgets? You focus your new-product energy on the stuff that’s most profitable already. And you do something else…which I’ll share in a minute. New stuff first. There’s no mainstream iPhone 18 yet, for the first time ever. But the high-end iPhone 18 Pro and Pro Max are here. And they’re priced $100 higher than were their forebears of similar memory capacities, along with adding an even higher-end (and higher-priced) 2 Tbyte storage tier.

That new SoC? It’s the A20 Pro. First-time 2 nm-fabricated by foundry partner TSMC. 50% higher memory bandwidth than the A19 Pro. Faster CPU (6 cores total, 2 “super” and 4 “efficiency) and GPU (seven cores total) subsystems than those in the A19 Pro. And a dual 16-core Neural Engine inference subsystem. Lessee…where have we heard this same messaging…two weeks ago, to be exact? Yessiree, it seems that once again there’s no shortage of shared DNA between the late-August M6 and today’s A20 Pro SoCs, albeit with varying dollops of various on-die resources, befitting varying platform cost, feature and performance requirements.

What I’m admittedly most excited about as an unabashed photography geek is the camera subsystem’s variable aperture (along with, by association, manual shutter speed setting) support for the rear main unit.

Yes, it enables more meaningful user control of exposure, particularly in low light environments (adjusting for bright-light settings can always alternatively be done via integrated or external neutral density filters, of course). But it also first-time affords user adjustment of depth of field, allowing for both shallow-depth “bokeh” effects and sharpness across a wider depth range than possible before.

Oh, and by the way…even though Apple delayed releasing the mainstream iPhone 18 (which, in saying so, I’m obviously assuming is still coming eventually), the company still found another way to use our credit cards and bank accounts as counterbalance to the higher semiconductor-content costs it was incurring. The iPhone 17 Pro and Pro Max are no more, of course. But the company’s still selling the baseline iPhone 17 and 16, the boutique iPhone Air, and the “cost-effective” (relatively speaking, at least) iPhone 17e. That said, post-Apple Store resurrection mid-day today, they all now cost $100 more than they did yesterday. Yay…???

The AirPods 5

Two years ago this same month, Apple released the 4th-generation AirPods in two flavors, $129 with only passive noise reduction (PNR, and not great, at that, given their imperfect ear-shape seal for many users), and $50 more for an active noise control (ANC)-supportive model. I’d love to see the comparative sales stat results between the two variants, but clearly the world has moved en masse to ANC since then.

To wit, Apple’s fifth-generation AirPods successors have dropped the PNR option, but the company’s marketeers can’t seem to quit the price-differentiation shtick completely. Want a conventional wired-charging case? That’ll cost you $129. How about a wireless charging-capable case option? $20 more, please. Maybe two years from now, Apple Marketing will realize that the world’s already moved en masse to Qi…oh, sorry, this is Apple…MagSafe…too. Wonder how they’ll try to extract more money out of our wallets next time? Reader prognostications are as-always welcomed in the comments!

Apple Watch Series 12 and Watch Ultra 4

Three key takeaways distinguish this year’s mainstream and high-end smartwatches from their prior years’ versions:

• An upgraded S11 processor, whose specifics were as-usual not revealed but likely include a sprinkle (or few) of deep learning inference acceleration, reflected in…
• AI as a first-time notable element in Apple’s smartwatch pitch this time, particularly focusing on ambient audio processing capabilities (including conversations, although Apple predictably maintains its “privacy by design” reassurance mantra) and thanks in no small part to a recently unveiled partnership with Google that has seemingly finally gotten Siri on track for something other than corporate embarrassment, and…
• The other notable AI-analyzed data set, an enhanced health sensor suite enabling, among other things, continues heart rate monitoring every five seconds, all day.

This year’s models are identically priced to their generational predecessors, surprisingly, although around 24 hours ago, I’d wondered if Apple was going to deal with its burgeoning semiconductor memory bill-of-materials burden in a different way. Beginning some time yesterday and continuing for quite a while, although subsequently corrected, the company’s entry-level Apple Watch SE 3 models all became “unavailable” for purchase.

Apple typically takes its online store down a few hours ahead of launch events to make the necessary tweaks in preparation and out of the public eye, but this was unprecedented. I’d wondered if Apple was planning on dropping the whole line, either because it wasn’t AI-capable and/or because memory cost increases had rendered it insufficiently profitable, and if someone had “pulled the plug” prematurely and highly visibly. But given that the Watch Series 3 had just been unveiled a year ago, the “yank” seemed premature. As, it turned out, it was. Maybe. Then again, maybe someone just decided to do a last-minute course-change. We’ll likely never know.

Back to the future

I guess John Ternus thought that instead of charting his own course, he’d use his first launch event to “channel” a predecessor’s past glory. Yes, he pulled out the memory closet a Steve Jobs “chestnut”, the “one more thing”. And of course, it was one of the worst kept secrets of recent Apple corporate strategy: the foldable iPhone. Although at least one thing was surprising about it: industry scuttlebutt had long branded it the “iPhone Ultra”, but instead it’s the “iPhone Duo”. Begging the question of what, if anything, the “iPhone Ultra” will be…but I digress.

It’s $1999 (and up, capacity-dependent). It won’t be available until next month (October). And like its iPhone 19 Pro siblings, it’s based on the A20 Pro Soc. But I don’t want to spend my precious few remaining paragraphs in this section talking about that. Instead, I want to talk about aspect ratios. Let’s start with my long beloved, in spite of chronic software bugs, Microsoft Surface Duo, an example of which still inhabits my storage closet in the hopes that someone will someday release a stable, robust-featured, reasonably current Android build for it or…dare I dream…Windows 11 for Arm with Wi-Fi and cellular data support? Be still my heart.

Yes, it was foldable. But no, unlike the iPhone Fold it wasn’t comprised of a single piece of bendable OLED internal “glass”. Instead, there was that jarring hinge in-between the two internal displays. And there was no external screen, either, so you had to unfold it to use it at all, even for basic smartphone tasks. But again, I digress. Look at its aspect ratio. Unfold it and, without rotating it 90°, you had a 7.36” wide by 5.72” tall screen (yes, I know, with a gap in the middle) perfect for reading eBooks in a style akin to that of actual books, watching movies, and the like.

Next, let’s look at the first-generation (2023) Google Pixel Fold, an example of which my wife bought me for my birthday earlier this year.

Same fundamental aspect ratio, this time with an added bonus: no midway gap. And this time, there was a third outer display, too.

But given overall system form factor dimensions, it was atypical in both size (5.8” diagonal) and (especially) aspect ratio in comparison to the ones in conventional smartphones. Atypical equals low volume. Low volume equals costly and supplier-option deficiency. All of which explains why second and subsequent-generation Pixel Folds have switched to “bifolds”, taller than before, albeit losing the unfolded “book” (or, if you prefer, movie screen) form factor in the process.

Now look at the iPhone Fold again. The “book” form factor is back (in black, aka “night sky”, as well as “star white”)!

Apple perhaps obviously has supplier leverage that Google doesn’t (or at least didn’t) have, so assuming customers buy into the design decision, I suspect it’ll play out better this time around. Agree or disagree, readers? Let me know your thoughts on this or anything else I’ve discussed here, in the comments!

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

Related Content

• Apple’s processor cadence: A pending stutter-step for improved long-term edge inference?
• Apple’s question for the developer: Are you up for an AI do-over?
• Apple’s 2H 2025 announcements: Tariff-touched but not bound, at least for this round
• Microsoft’s Surface Duo: A software evolution testimonial, but for who?

The post The Microsoft-reminiscent iPhone Duo: How much customer holding-and-folding is necessary to keep Apple from folding on the experiment? appeared first on EDN.