EDN Network

ST’s ISM330BX 6-axis inertial measurement unit (IMU) combines edge AI processing and sensor fusion for industrial vibration sensing and motion tracking. The compact system-in-package contains a 3-axis digital gyroscope and a 3-axis digital accelerometer featuring a low-noise architecture and bandwidth up to 2 kHz.

The part’s integrated edge-processing engine pairs a machine-learning core with AI algorithms and a finite state machine. This not only offloads the host processor, but also conserves system power. The ISM330BX also employs ST’s sensor fusion low-power (SFLP) algorithm for 3D orientation tracking. Adaptive self-configuration allows the sensor to automatically optimize settings in real-time to achieve best performance and power.

A built-in analog hub connects external analog sensors to the edge-processing engine for data filtering and AI inference. The ISM330BX also features Qvar, ST’s electric charge variation detector. Qvar enables the IMU to integrate touch and close-proximity detection, as well as value-added functions such as water leak sensing.

In production now, the ISM330BX costs $4 each in lots of 1000 units Additionally, the IMU is included in ST’s 10-year product-longevity program for industrial components.

ISM330BX product page 

STMicroelectronics

Find more datasheets on products like this one at Datasheets.com, searchable by category, part #, description, manufacturer, and more.

The post Industrial sensor unit embeds AI processing appeared first on EDN.

For most system-on-chip (SoC) designs, the most critical task is not RTL coding or even creating the chip architecture. Today, SoCs are designed primarily by assembling various silicon intellectual property (IP) blocks from multiple vendors. This makes managing silicon IP the dominant task in the design process.

Generally, less than a tenth of a new SoC design will be newly written RTL code. And often, the high-level chip architectural decisions will be clear: a variation on an existing architecture or a reflection of major data flows in the application layered on a standard bus or network-on-chip (NoC) structure.

But each piece of IP in the design—and there may be dozens of types and hundreds of instances—requires management. The chip designers must define requirements, select vendors and specific products, make any necessary customizations, set configuration parameters, and integrate the IP instances into a working, testable system. This process will consume most of the project resources until physical design.

This reality makes expertise in managing IP a significant factor in the success of an SoC design. Perhaps less obviously, access to IP—particularly the ability to get attention, detailed specifications and documentation, bug fixes, and customization support from large, influential IP vendors—becomes a critical issue. The growing complexity of the IP blocks only adds to the challenge.

Figure 1 IP management is a significant consideration in the success of an SoC design. Source: Faraday Technology

A vital partnership

This situation adds a new dimension to the familiar space of design partnerships. Many SoC design teams have used design-services companies to supplement their teams on specific skills—for example, to do physical design.

In some cases, this supplementing has broadened into a full partnership, with the design partner taking on many steps in the design process. In extreme cases, the client may only have a functional description of the SoC or a proverbial sketch on a napkin at the beginning of the engagement.

However, as IP becomes the center of attention, clients are asking design partners to shoulder IP management as well. Indeed, this can be a powerful lever for the client. Let’s look closer at what this new partnership level entails and what it implies about the ideal design partner.

Flexible engagement

Only a few SoC design relationships start on a scribbled napkin. However, in many more cases, there are some major IP blocks for which the client has only a conceptual understanding. For example, a client may know they need a low-power artificial intelligence (AI) accelerator block for an Internet of things (IoT) chip. However, they may have little information on how these complex blocks perform with different models or how they are structured internally.

Or a team may be writing code for a novel function in their SoC but have no idea how to select and configure a RISC-V CPU core to execute their new code within timing and power constraints. Yet another client may know precisely the UCIe interface requirements for their design, but not exactly how to configure any available UCIe interface IP blocks to meet those requirements.

These differences make flexible engagement vital. A design partner should be able to join the project at any level, from concept through netlist, and mesh smoothly with the client’s design team. Initially, the goal will be working with the client to refine the IP requirements—moving from concept to functional spec to detailed interface, power/performance/area, and layout requirements—so the partners can select the best IP for each instance in the design.

IP selection

With the requirements in hand, the client and design partner will select the IP to be used. At this point, the partner’s role diverges from the traditional idea of a hot-shot bunch of designers-for-hire. The depth of the partner’s relationships with IP vendors becomes crucial.

Figure 2 IP selection is now a crucial part of an SoC design project. Source: Faraday Technology

Ideally, the partner would develop and maintain their extensive IP libraries in-house. This allows the partner to match requirements against its inventory quickly. If a match is close but not perfect, the IP development team has the documentation, tools, and resources to customize the IP block for the client’s specific needs.

A partner needs many strengths beyond skilled design engineers in selecting, customizing, and licensing IP. A broad internal portfolio of silicon-verified IP, backed by the team that designed those blocks, is a huge advantage.

There will be cases when there is no close match. That brings in the IP outsource team, an engineering group exclusively charged with building and maintaining third-party IP relationships. Such a team has a vast global network of IP suppliers, ensuring it can match the client’s requirements.

A global network of time-tested IP licensing and development relationships with third-party IP vendors—and a team dedicated to maintaining that network—is essential. A client should especially investigate a prospective design partner’s relationship with ARM and with the growing ecosystem of RISC-V providers.

IP integration

The design partner will also be deeply involved in IP integration. The IP instances must be configured correctly and then connected to the chip’s underlying bus or network architecture. The correct operation of the assembled SoC design must be verified. Important subjects beyond functional design, such as test architecture, power management, and clock architecture, must be resolved—ideally, uniformly.

The first step, connectivity, begins with selecting IP blocks with the necessary interfaces. However, some blocks may require customization to meet interface requirements perfectly. In other cases, the integration team may have to create a wrapper, controller, or gateway between regions of the design. A large IP design team with this in-house expertise is a huge time saver.

Verification is an equal challenge. Often, an IP block doesn’t behave as expected—or as described—in the assembled SoC design. This is another situation where an internal IP design team is immensely valuable. Even with external IP, a design partner can usually resolve problems without bringing in a third-party vendor.

A detailed knowledge of the internals of the IP blocks is also valuable in power management and when designing for test. Blocks may be designed with specific assumptions about test strategies, the balance of built-in self-test (BIST) versus external access, sleep modes, and how to deploy power or clock gating.

These choices must be harmonized across the design to produce an SoC with a minimal test time and an effective chip-wide power-management strategy. Making those choices may require designers to get elbow-deep into the internals of the IP blocks.

Finding a partner

We have touched upon several issues that require an effective design partner to have deep expertise in IP. The ideal partner for today’s SoC designs would have its extensive internal IP portfolio and a broad network of third-party vendors.

It would have separate engineering groups supporting these two sources. It would also have a flexible engagement model that would divide tasks between client and partner teams on a block-by-block basis based on the client’s resources and expertise.

The dominance of IP in SoC design has changed the nature of the design task and what a client must expect of a design partner.

Efren Brito is technical director at Faraday Americas.

Related Content

• India’s niche: semiconductor design services
• Will IP use increase in forthcoming SoC design?
• Why network-on-chip IP in SoC must be physically aware
• Droop response system IP made available for SoC designs
• Accelerating RISC-V development with network-on-chip IP

The post System-on-chip (SoC) design is all about IP management appeared first on EDN.

Happy Apple Worldwide Developers Conference (WWDC) week!

Unlike many WWDCs that preceded it (but not all, with 2021 an example), this one was absent mention of any new hardware or underlying silicon, in contrast to, say, last year’s preview of the Vision Pro headset. Then again, the 2024 WWDC was also thankfully absent the wholesale culling of legacy but seemingly still perfectly capable hardware that tainted the 2022 WWDC (at least for me, with multiple computers in my personal stable getting axed in one fell swoop). But the new operating system versions unveiled at Monday’s keynote weren’t completely absent any associated axe-swinging, resulting both in system demise and maiming…

Hardware triage

From a computer standpoint, upcoming MacOS 15 “Sequoia” only fully lopped off two computers from the “supported” list (and then two years from now, not immediately, assuming Apple continues its longstanding practice of fully supporting not only the latest but also the prior two major yearly-cadence MacOS releases). But the rationale for doing so, along with that for one model that remains on the supported list, was inconsistent at best. Ahead of time, the rumor was that anything absent a T2 security chip was doomed. But the two computers dropped from MacOS “Sequoia”, the 2018 and closely related 2019 versions of the MacBook Air, are T2-inclusive systems. Conversely, the 2019 models of the iMac (both 21.5” and 27”) remain on the supported list, although neither is T2 security chip-enhanced. <shrugs shoulders>

That said, no remaining Intel-based Macs support any of the AI enhancements that Apple announced this week (hold that thought). But that said, I was pleasantly surprised that any legacy x86 Macs remained relevant. Recall, for comparison’s sake, that Apple announced its move from PowerPC to Intel at the early-June 2005 WWDC, with “universal” x86 support (alongside ongoing PowerPC support) first appearing in Mac OS X 10.4.4 at the beginning of 2006. Mac OS 10.6, released in August 2009, culled PowerPC processor support from the code, and “Rosetta” emulation support for legacy PowerPC applications ended with July 2011’s Mac OS X 10.7 (perhaps obviously, Apple temporarily elongated its traditional yearly new-O/S version stride during the transition). Measuring end of support by when hardware was dropped, July 2011 was also when Mac OS X 10.5 fell off the support list, six years (and a month) after the public transition began. How will (or not) past history inform current precedent this transition-time around, which started in June 2022? Who knows. I’m just glad my 2018 Mac mini, 2019 16” MacBook Pro and 2020 13” MacBook Pro will live on (officially, at least) for another year.

iPhones come through even more unscathed, at least at first glance; anything currently capable of running iOS 17 will also be supported by upcoming iOS 18 to some degree. But the fully supported list is conversely far more restrictive than with MacOS 15, which was simpatico to anything Apple Silicon-based. With smartphones, only “Pro” variants of the latest-generation iPhone 15 get the AI-enhanced nod. Accurately reflective of software requirements reality, or Apple’s excuse to prod existing customers to upgrade to this year’s models ? I’ll let you decide.

With iPads, the same generalities apply, with three exceptions; anything capable of running iPadOS 17 can also handle enroute iPadOS 18 to at least a baseline level, except for the now-axed 2018 sixth-generation iPad and 2017 second-generation 10.5” and 12.9” iPad Pro. This situation, as with the earlier-mentioned 2019 iMacs and 2018-2019 MacBook Airs, makes no sense at initial glance; after all, the unsupported sixth-generation and still-supported seventh-generation iPads are based on the exact same A10 Fusion SoC, and the axed iPad Pro models are based on the more advanced A10X! That said, the two base iPad generations are different in at least one building-block respect; the former has only 2 GBytes of RAM, with the latter bumped it up 50% to 3 GBytes. But that said, second-generation iPad Pros had 4 GBytes, so… <shrugs shoulders again>. And, by the way, only Apple Silicon-based iPads get the enhanced-AI goods.

The obsolescence situation’s not quite as sanguine with Apple’s smartwatch product lines, alas. Upcoming watchOS 11 drops the Apple Watch Series 4, Series 5 and first-generation SE from the supported device list. On the other hand, tvOS 18-to-come is compatible with all Apple TV HD and 4K models stretching all the way back to 2015, so it’s got that going for it, which is nice (no fancy AI features here, thought, nor with the Apple Watch or Vision Pro headset, so…).

Ongoing Sherlocking

Before diving into this section’s details, an introductory definition: “Sherlocking” refers to Sherlock, a file and web search tool originally introduced by Apple in 1998 with Mac OS 8.5. However, as Wikipedia explains:

Advocates of Watson made by Karelia Software, LLC claim that Apple copied their product without permission, compensation, or attribution in producing Sherlock 3.

Moreover:

The phenomenon of Apple releasing a feature that supplants or obviates third-party software is so well known that being Sherlocked has become an accepted term used within the Mac and iOS developer community.

Apple unfortunately has a longstanding tradition of integrating capabilities that previously were supplied by third-party “partner” developers. Here’s 2023’s WWDC list compiled by TechCrunch, for example. And as for this year, here are at least a couple of the 2024 WWDC’s Sherlocked utilities I’ve noted in particular so far:

• Password management: notably spanning not only iOS, iPadOS and MacOS but also Windows, this one seemingly has 1Password and its third-party peers in Apple’s sights.
• An iPad-native Calculator: believe it or not, it took 14 years for Apple to add this, even though one’s been in iOS for both the iPhone and iPod touch since the beginning. It admittedly has some slick Pencil-enabled features beyond those of its iOS sibling, although RPN (reverse Polish notation) support seemingly remains absent. To wit, this HP15C-trained-in-college engineer will be stubbornly sticking with RPN-supportive PCalc.

That said, at least some of the rest-of-industry-precedent features that Apple belatedly adopts are welcomed. They include, this year, support for RCS messaging between Apple and other platforms, versus longstanding down-throttling to defeatured legacy SMS…although Apple kept plenty of other features iMessage-only. Speaking of text messages, they’re now capable of being sent via a satellite intermediary, building on last year’s Emergency SOS capabilities. And also added, this time building on earlier Apple-sourced Continuity innovations, is iPhone Mirroring support.

Earbud advancements

Touchless gesture interfaces for electronics devices have had mixed-at-best to-date success. Facial recognition-based “unlock” schemes using a front camera (conventional 2D or, better yet, a depth-sensing setup not fooled by photographs) have achieved widespread adoption. On the other hand, the countless to-date attempts to control a computer, smartphone, or tablet by a wave of the…err…hand…just haven’t taken off much, a reflection of at least four factors, I ‘spect:

• The limited applicability of the capability beyond for, say, flipping eBook pages
• The sizeable suite of gesture variants that must be retained to expand that applicability
• The imperfect decoding of, and response to, any of those gesture variants, and
• The battery-draining and privacy-concerning need to keep the camera “on” all the time

That said, the head-movement decoding support that Apple’s adding to its AirPods Pro earbuds is admittedly intriguing. This is the case no matter that I’m disconcerted that were I to use it in, for example, rejecting an incoming phone call by shaking my head side-to-side or, alternatively, accepting the call by nodding up and down, others might interpret me as afflicted by Tourettes and/or reacting to the voices in my head. That said, even more intriguing to me is the earbuds’ incoming Voice Isolation feature. As my recent piece pointed out, whereas external-oriented microphones can do a credible job of suppressing the ambient sounds that you hear, they’ve historically done little to suppress the noise that gets transmitted to someone else you’re speaking with. Apple claims to be tackling this latter issue with its upcoming update, and I’m cautiously optimistic that reality will at least approximate the hype (even though, as mine are first-generation models, I won’t be able to personally benefit from the new firmware).

Spatial computing evolution

Apple previewed the Vision Pro headset at WWDC a year ago and, in spite of reportedly flagging sales and existing-owner enthusiasm, the company is plugging on with notable (albeit, IMHO, not game-changing, particularly given the still-high price point) updates from it and partners. For one thing, sales availability is expanding to eight more countries this month (a reflection of higher production volume, accumulating unsold inventory, or both?). AI-rendered “spatial” versions of existing “2D” images in a user’s Photos library are also planned. As are, for example, an expanded repertoire of gesture interface options (to my earlier comments) and an ultrawide Mac virtual display mode equivalent in resolution to two side-by-side 4K monitors.

Other additions and enhancements are reflective of the Vision Pro’s dominant current use case as a video playback device. Spatial videos captured either by the headset itself or from an iPhone 15 Pro (there’s that exclusivity play again) will be shareable with others via the Vimeo service, for example. And for content creation by prosumers and professionals, both new hardware and software is enroute. An update to Final Cut Pro, for example, will “enable creators to edit spatial videos on their Mac and add immersive titles and effects to their projects”, to quote from the press release. Canon has unveiled a spatial still and video image capture lens, due out later this year, for its EOS R7 digital camera. And BlackMagic Design not only plans on fully supporting spatial video within its DaVinci Resolve application workflow but is developing a ground-up spatial video camera, the URSA Cine Immersive, containing dual 8K image sensors.

AI, privacy and ChatGPT

At this point, roughly 70 minutes into the keynote and with only about a half hour left, CEO Tim Cook returned to the stage to kick off the bigger-picture AI segment of the presentation (which, I’m admittedly a bit sad to say, was not introduced with the words “one more thing”). That said, if you’ve been paying close attention to my writeup so far, you’ve seen evidence of plenty of AI-enhanced breadcrumbs already being scattered about; the Apple Pencil-enabled and Notes-integrated ability to sketch out an equation or other arithmetic operation and have the iPad’s Calculator app discern and deliver what you’re asking for, for example, or spatial-converted conventional photographs to view in the Vision Pro and share with others. And at least four other aspects of this keynote segment are likely already unsurprising to many of you:

• That much of what was announced had already been leaked in advance, albeit admittedly to a shockingly extensive and accurate degree this time around
• That Apple chose WWDC to “go big” with AI and, specifically, generative AI, given all the attention (not to mention investor and shareholder love) that partners (more on this in a bit)/competitors such as Google, Meta, Microsoft and OpenAI have garnered of late
• That Apple’s generative AI implementation is multimodal, that is, capable of being trained by, accept inputs from, and infer outputs to various (and often multiple simultaneous) data types: text, voice and other audio, still images, video clips, etc., and
• That Apple had the moxie to brand an industry-standard term, AI, as “Apple Intelligence”

I’m not going to go through every showcased example of what Apple sneak-peeked (custom emoji…sigh…for example); you can peruse the liveblogs and videos for that, if you wish. Instead, I’ll share some big-picture thoughts. First off, much of what we saw at the keynote were under-development concepts, not anything that’ll be ready for prime time soon (if ever). To wit, although the AI-enhanced version of long-suffering Siri (in-advance warning: the full video is NSFW, or more generally for those with delicate constitutions!):

is eagerly awaited, the just-released initial beta of iOS 18 doesn’t include it.

Secondly, and also unsurprisingly, preserving user privacy was a repeatedly uttered mantra throughout this segment (and the keynote more generally). To what degree Apple will be able to deliver on its promises here is yet to be determined, although longstanding and ongoing software and services shortcomings admittedly have me somewhat skeptical (albeit more optimistic than with less walled-garden alternatives, but ironically counterbalanced by worldwide regulatory pressure to tear down those very same Apple walls).

Speaking of privacy, I’ll differentiate by two types of AI-enhanced services that I deduced from what I heard this week:

• Personal and contextual, such as using AI to find an open time in yours and colleagues’ or friends’ calendars for a meeting or other event, versus
• More broad, general information retrieval, such as the answer to the question “What is the airspeed velocity of an unladen swallow?”, along with synthetic data generation

In the former case, from what I’ve gathered, “Apple Intelligence” will rely exclusively on Apple-developed deep learning models, such as a “smaller” 3 TB parameter language one intended for on-device use and a much larger one resident on Apple-owned and -managed servers (which are reportedly based on M2 Ultra SoCs). Responses to inference queries will ideally run fully on-device but, if needed due to complexity or other factors, will automatically be handed off to its Private Cloud Compute server farm for processing. This all, of course, begs the question of why “Apple Intelligence” isn’t accessible to a broader range of Apple hardware, more cloud-reliant with less capable legacy devices. But we already know the answer to that question, don’t we?

For general information retrieval and synthetic data cases, Apple is likely to hand off the request (after receiving the user’s permission to do so) to a model running on one of its partners’ servers and services. The initial “anointed one” is OpenAI, who will offer free ChatGPT access to Apple’s customers (which it’s seemingly already doing more broadly) along with a ChatGPT app (ditto, albeit currently only for Plus subscribers with the desktop version). What I’m guessing here, in the absence of definitive information, is that Apple’s not paying OpenAI much if any money; the latter company’s doing this pro bono as a means of burnishing its brand (to counteract its subsumption within fellow partner Microsoft’s products, for example). To wit, however, Apple was quite candid about the fact that although OpenAI was first, the relationship wasn’t at all exclusive. In a post-keynote press briefing, in fact, Apple executives specifically expressed openness to working with Google and its various Gemini models in the future.

I’ll close with the following day-after-keynote commentary from Tim Cook within an interview with Washington Post columnist Josh Tyrangiel:

Tyrangiel: What’s your confidence that Apple Intelligence will not hallucinate?

 Cook: It’s not 100 percent. But I think we have done everything that we know to do, including thinking very deeply about the readiness of the technology in the areas that we’re using it in. So, I am confident it will be very high quality. But I’d say in all honesty that’s short of 100 percent. I would never claim that it’s 100 percent.

I’m not sure whether to be reassured, freaked out or a bit of both in reaction to Cook’s candor. And you? Let me know your thoughts in the comments on this or anything else I’ve discussed.

—Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.

Related Content

• The Apple 2023 WWDC: One more thing? Let’s wait and see
• Apple’s 2022 WWDC: Generational evolution and dramatic obsolescence
• Apple’s WWDC 2021: Software and services updates dominate
• Apple on Intel; Forecasted Transition Complete By End of 2007
• Noise-suppressing headsets and earbuds: Differences, but all telephony duds
• The 2024 Google I/O: It’s (pretty much) all about AI progress, if you didn’t already guess

The post The 2024 WWDC: AI stands for Apple intelligence, you see… appeared first on EDN.

The popular I2C communication standard manages to perform flexible serial I/O with just a super simple two pin bus: SCL and SDA. It accomplishes this trick with bidirectional timing and data flow. Bidirectional flow is good at saving pins but due to its use of passive pullup resistors, not so good at saving power. Bus pullup resistances must be chosen low enough (and therefore pass sufficient current) to charge parasitic bus capacitance at the speed dictated by the chosen data rate. Figure 1 illustrates this inconvenient arithmetic.

Figure 1 I2C bus speed inversely affects maximum effective pullup resistance. Source: Texas Instruments Application Report SLVA689

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

The amount of V/R current drawn and V2/R power squandered in passive “pull-upping” depends on bus capacitance, pullup voltage, and duty cycle; and as Figure 1 shows, for fast-mode 400 kHz, V = 5 V, and Cb = 400 pF can be as much as 5V/1k = 5 mA and 52/1k = 25 mW. This can easily comprise a sizable fraction of total system power use. This is bad for batteries and bad for political correctness in the age of “greenness” and “sustainability”.

So how to save some of that excess current and power? Figure 2 shows one way: an active pullup with values chosen for the worst-case combination illustrated in Figure 1 of high speed (400 kHz) and high capacitance (400 pF).

Figure 2 Regenerative active pullup circuit (one of two needed) with values chosen for the worst-case combination shown in Figure 1.

This simple circuit topology, given that saving pullup power was its avowed purpose, begins on an unpromising note: a passive pullup resistor R1. How the whole thing works is diagrammed in Figure 3.

Figure 3 Active pullup waveforms and 4-step sequence labeled within the image.

The active pullup process occurs in four steps.

1. Release of the bus signal line in question (i.e., SCL or SDA) allows R1 to begin passive pullup and start charging bus capacitance. The resulting voltage ramp is slow because R1 is more than 4x larger than the 1k calculated as necessary in Figure 1. It’s obviously never going to complete risetime soon enough! 
2. But wait: The resulting signal is being coupled by C1 to Q2’s base. Consequently, at Step 2 of the process, Q2 turns on, taking Q1 with it and initiating a very fast positive feedback loop that drives both transistors into saturation and completes bus capacitance charging in order of tens of nanoseconds; removing the voltage drop across R1 and ending its power drain.
3. The very short time constant of 22 pF C1 working into Q2’s base impedance discharges C1 and terminates drive for the transistors, allowing them to begin turn off and end active pullup. This gives Q1 and Q2 time to recover from saturation.
4. Pulldown begins the next cycle of bus activity and recharges C1 through D1, which also protects Q2’s limited (only 4.5 V) maximum reverse Vbe rating.

Thus, our parable of parsimonious pullup power is given a happy ending, with about a 75% saving of the power otherwise required, and without any need for software modification.

Stephen Woodward’s relationship with EDN’s DI column goes back quite a long way. Over 100 submissions have been accepted since his first contribution back in 1974.

Related Content

• Adaptable pullup
• Non-linear pullup for multi-rate I2C buses
• Validating and using the I2C protocol
• Optically isolating an I2C interface: Beware of nonlinear propagation delays

The post I2C active pullup is power thrifty appeared first on EDN.

What’s Arm up to in design and development of chiplets, the highly integrated large-scale silicon solutions? The IP giant is gradually unveiling its design blueprint for one of the most exciting opportunities in today’s semiconductor realm.

It’s critical that Arm ensures a place for its compute building blocks in multi-die silicon platforms, whether they are CPU chiplets or customized application-specific chiplets. So, Arm is cobbling strategic partnerships with chip design houses as well as semiconductor IP suppliers to ensure that Arm-based systems are part of the chipset revolution.

Arm is also proactively engaged in standardization efforts to define common design frameworks for chiplet designs. That matters because Arm’s Advanced Microcontroller Bus Architecture (AMBA) specifications form the bedrock of system-on-chip (SoC) connectivity designs for over two decades.

Alphawave Semi tie-up

Arm’s collaboration with chiplet IP supplier Alphawave Semi provides a few clues on the Cambridge, England-based company’s larger blueprint for multi-die silicon devices. In October 2023, Alphawave Semi joined the Arm Total Design initiative to create chiplet solutions based on Arm Neoverse Compute Subsystems (CSS).

Alphawave Semi would integrate Arm Neoverse CSS compute with its Universal Chiplet Express (UCIe)-enabled custom silicon and pre-built connectivity chiplets. Therefore, its UCIe IP would support Arm fabric interfaces such as Advanced eXtensible Interface (AXI) and Coherent Hub Interface (CHI), enabling easy integration of connectivity for interfaces such as CXL, HBMx, DDRx, and Ethernet onto Arm-based custom SoCs and chiplets.

In short, Alphawave Semi would combine its high-speed connectivity IP and chiplet platforms with Arm Neoverse CSS reference IP solution. Moreover, its specialized team would harden and optimize the Neoverse cores for power, performance, and area (PPA) in major process nodes scaling down to 3-nm and 2-nm chiplet manufacturing.

Fast forward to June 2024, when Alphawave Semi announced the development of an advanced compute chiplet built on the Arm Neoverse CSS platform for artificial intelligence (AI) and machine learning (ML), high-performance compute (HPC), data center, and 5G/6G networking infrastructure applications. The tie-up added significant differentiators to Alphawave Semi’s design platform, including I/O extension chiplets, memory chiplets, and compute chiplets.

Figure 1 The compute chiplet features an Arm Neoverse N3 CPU core cluster and the Arm Coherent Mesh Network (CMN). Source: Arm

Arm has also partnered with Japanese design house Socionext to develop a 32-core CPU chiplet on TSMCʼs 2-nm process node. The CPU chiplet, built around the Arm Neoverse CSS platform, is designed for single or multiple instantiations within a single package. It also includes I/O and application-specific custom chiplets to optimize performance for a variety of applications.

Arm’s chiplet blueprint

A recent blog from Richard Grisenthwaite, executive VP, chief architect and Fellow at Arm, provides a few clues on the company’s chiplet design blueprint. For a start, it has launched the Arm Chiplet System Architecture (CSA) initiative to enable greater reuse of components like PHY IP and soft IP among multiple suppliers.

Figure 2 Leveraging Neoverse CSS compute, CSA aims to set the foundation for a robust chiplet environment. Source: Arm

The initiative, comprising more than 20 partners, is analyzing and defining optimal partitioning choices for chiplet-based systems. It’s also exploring new ways to better standardize system design choices for different chiplet types.

Next, Arm is updating AMBA specifications for on-chip and off-chip interfaces for chiplet designs. Arm’s AMBA specifications, such as AXI and CHI, have been used in billions of semiconductor devices.

Arm is also an active participant in efforts to create industry standards like UCIe, which define the physical layer (PHY) for transporting data between chiplets within a package. Besides bringing the SoC interconnect protocols like AMBA to chiplet designs, Arm is engaged in efforts to adopt industry standards like PCIe and CXL to aggregate well-defined peripherals from across a motherboard into a package.

Finally, as part of efforts to create alignment on many non-differentiating choices in chiplet partitioning, Arm is exploring to disaggregate the SoC into chiplets for Arm-based systems using AMBA protocols. Such initiatives are meant to expedite the design journey toward chiplet-based systems.

Chiplet partitioning framework

Arm’s investments in AMBA and CSA domains demonstrate how it’s trying to decompose an Arm-based system across multiple chiplets. That’s crucial because reusability can create interesting new possibilities in the thriving chiplet marketplace. Collaboration with connectivity IP specialists like Alphawave Semi seems part of this effort to streamline chiplet partitioning.

Still, standards enabling a common framework will play a vital role in creating viable chiplet solutions, and that’s why Arm is proactively engaged on UCIe and other standardization fronts. Its own initiative CSA is aiming to create a consensus around the most valuable partitioning schemes to reduce fragmentation.

Related Content

• TSMC, Arm Show 3DIC Made of Chiplets
• Chiplets Get a Formal Standard with UCIe 1.0
• How the Worlds of Chiplets and Packaging Intertwine
• Cadence and Arm launch ADAS chiplet development platform
• Imec’s Van den hove: Moving to Chiplets to Extend Moore’s Law

The post A closer look at Arm’s chiplet game plan appeared first on EDN.

Digital oscilloscopes are normally operated in real-time acquisition mode, where the analog input is sampled and digitized at a user-selected sampling rate and written continuously into the acquisition memory.

There are, however, other acquisition modes available in most oscilloscopes: random interleaved sampling (RIS), sequence mode, and roll mode (Figure 1).

Figure 1 The sampling mode selections in a typical oscilloscope include sequence, RIS, and roll in addition to the normally used real-time mode. Source: Arthur Pini

 These special modes are useful in applications for measuring specific types of signals. RIS mode increases the effective sampling of the oscilloscope rate for periodic signals. Roll mode is useful in displaying low-frequency signals having very long durations. Sequence mode reduces the dead time between acquisitions and is also applied to signals that have low-duty cycles with long dead times between significant events.

RIS acquisition mode

Let’s look at these acquisition modes,starting with RIS mode. RIS mode is a form of equivalent-time sampling that allows the oscilloscope to acquire repetitive signals at very high sampling rates. Multiple acquisitions are combined in RIS to create a composite waveform with a higher effective sampling rate. The trigger event and the sampling clock are not synchronous. The time between the trigger and the first sample in an acquisition is randomly distributed. Oscilloscopes use a time-to-digital converter (TDC) to measure the time delay between the trigger and the nearest sample of each sweep. This delay is called the horizontal offset. The acquisitions are grouped by delay to provide samples spaced by as little as 5 ps, an effective sampling rate of 200 giga-samples per second (GS/s). Selected waveforms are added together, creating a composite waveform, as shown in Figure 2.

Figure 2 Random interleaved sampling creates a composite waveform based on the measured delays between the trigger and the nearest sample point. Source: Arthur Pini

RIS requires a periodic input waveform with a stable trigger. The maximum effective RIS sampling rate is achieved by making multiple acquisitions and selecting those with horizontal offsets, yielding the desired sample spacing. The random timing between digitizer sampling times and the event trigger provides the time variation. The instrument uses multiple triggers to complete an acquisition. The number of acquisitions required depends on the effective sample rate. The higher the effective sample rate, the more triggers are required. Figure 3 compares real-time and RIS acquisitions of a high-frequency sine wave.

Figure 3 Comparing the real-time acquisition of a 5 GHz sinewave at 40 GS/s (lower trace) with a RIS acquisition at 200 GS/s (upper trace). Source: Arthur Pini

The real-time acquisition of the 5 GHz sine is sampled at 40 GS/s and produces a waveform with 8 samples per cycle. Viewing that waveform using linear display interpolation produces a ‘boxy’ display. The RIS acquisition has an effective sample rate of 200 GS/s, yielding 40 samples per cycle and a smoother display. Sin x/x interpolation could be used to smooth the waveform, but as the waveform bandwidth approaches the Nyquist frequency, especially for pulse-like signals, the potential for interpolator errors such as Gibbs ears increases and the RIS acquisition mode produces a more accurate representation of the acquired waveform. In the oscilloscope used, RIS is only available for timebase settings of 10 ns/division or less; similar restrictions will apply to all oscilloscopes.

Roll mode

Roll mode operates at slow sweep speeds, where the sampled data is acquired at a sufficiently low sampling rate and displays the samples in real time as they are acquired. This is important at slow sweep speeds because it eliminates “pre-trigger” acquisition delays. Usually, an oscilloscope holds off display until the acquisition is complete. If you are using a one-second per division horizontal scale setting, you have to wait at least ten seconds before you see the acquired waveform. At slow sample rates used with long acquisitions, roll mode writes to the display as the sample becomes available, eliminating that delay. In roll mode, the trace moves slowly to the left in the manner of a strip chart recorder display (Figure 4).

Figure 4 The simulated progression of a waveform acquired in roll mode. Source: Arthur Pini

This figure shows the progression of an electrocardiogram signal acquired in roll mode over time. The waveform is written starting on the right and moving to the left over time. Each grid in the figure, starting at the upper left, shows the waveform at a later time until it fills the display in the lower right when a trigger event is detected and the acquisition is complete. Roll mode can be entered depending on the sample rate. This oscilloscope enables roll mode at sweep speeds greater than 100 ms/division (higher if more acquisition memory is used).

Roll mode is useful with low-frequency signals like this electrocardiogram waveform.

Sequence mode

Sequence mode is ideal for capturing many fast signal events in quick succession or for capturing a few events separated by long time periods. This mode breaks the acquisition memory into smaller segments and allows multiple acquisitions within the acquisition memory. Sequence-mode acquisitions minimize dead time between acquisitions (typically <1 µs) by holding off display until all segments are captured. Each acquired segment is time-stamped at its trigger time with the real-time clock, the delay between segments, and the elapsed time since the first trigger.

Sequence mode has three main applications:

1. To acquire data at a high sampling rate when the input waveform has long periods of dead time.
2. To acquire data with minimum dead time between acquisitions.
3. To use the trigger time-stamp table to understand the event timing.

For an example of using sequence mode to analyze signals with long dead time, consider capturing several packets of an I2C data signal and measuring the time between packets and the rise time of the data (Figure 5).

Figure 5 Analyzing and I2C data signal for the inter-packet delay and the rise time of the data signal. Source: Arthur Pini

Four data packets were acquired at 20 ms/division at a sampling rate of 5 MS/s. Cursors measure the delay between packets at 43.5 ms. The duty cycle of the I2C signal is small. So, there is a great deal of memory used to show the dead time between packets, resulting in a low sampling rate. Measurement parameter P2 measures the rise time of the signal. It shows a rise time of less than 291 ns with a yellow warning indicator. The sampling rate is 5 MS/s, or a sample period of 200 ns, is the cause of the measurement warning.

Using sequence mode, we can acquire each packet in its own memory segment. The number of segments is model-dependent and is a function of the size of the acquisition memory. In the oscilloscope used, up to 2000 segments can be stored. The packets are much shorter than the whole data stream, and a higher sampling rate can be used (Figure 6).

Figure 6 A sequence mode acquisition captures ten data packets at a sampling rate of 500 MS/s. It also measures the time between packets using the sequence mode trigger time stamps. Source: Arthur Pini

The number of segments acquired is user-selected; in this example, ten packets were acquired with a sample rate of 500 MS/s (2 ns sampling period) horizontal scale of 200 ms/division. A zoom trace, Z1, horizontally expands segment 1. The rise time measurement now shows 28.19 ns, with the green check status icon indicating a valid measurement. The higher sampling rate provides more than adequate time resolution for the measurement.

Below the display grids, the sequence mode time stamps read the time of each trigger using the oscilloscope’s real-time clock. It also reads the time of each segment trigger from the first trigger as well as the time between triggers with a resolution of one nanosecond. The time between segments is nominally 43.6 ms. In this example, sequence mode eliminated the very long dead time between data packets and improved the measurements.

A second measurement provides an example of using sequence mode to minimize dead time between acquisitions. Looking at the signals generated by an ultrasonic range finder. The range finder emits a burst of five 40 kHz ultrasonic pulses each time a measurement is made (Figure 7).

Figure 7 Each measurement of an ultrasonic range finder emits five 40-kHz bursts. After each burst, it waits for an echo from the target before emitting the next transmitter burst, stopping after the fifth burst. Source: Arthur Pini

When a measurement is started, the range finder emits a 40-kHz burst. It waits to detect an echo before emitting the next burst and continues the process until five ultrasonic pulses have been transmitted. In real-time acquisition mode, trying to acquire five individual bursts would not work. After each acquisition, the oscilloscope would pause to display the data acquired and not be ready for the next burst in the series. That is where sequence mode has an advantage. It segments the acquisition memory into a user-set number of segments and acquires one acquisition into each segment without pausing to display the data until all the segments are filled or the acquisition is manually stopped by the user. The latency between acquisitions of each segment is less than a microsecond in the oscilloscope used. During the acquisition, it records the trigger time of each segment. Figure 8 shows an example of the five-segment acquisition.

Figure 8 The sequence mode acquisition of ultrasonic range finder signal with each of the bursts in its own segment appears in the upper left grid. Source: Arthur Pini

Sequence mode waveforms can be displayed in any of five different ways. The display shown is called an adjacent display. The segments can also be overlapped for comparison. They can be displayed as a waterfall display, with each display segment offset vertically. A perspective display provides a three-dimensional view with segments displayed with both vertical and horizontal offset. The final display type places each segment in its own grid and is called a mosaic display.

Each segment can be operated on as an independent waveform. Using zoom traces, each segment can be displayed independently of the others. In Figure 8, zoom traces Z1-Z5 show each of the segments. Any of the oscilloscope’s measurements and math functions can be applied to the segments independently. As an example, the math trace, F2, applies a 2 kHz bandwidth second-order Butterworth band pass filter centered about 40 kHz to segment 1. Averaging can be applied not only to individual segments as they are acquired, but it can also be computed across all the segments in a single sequence, as shown in math trace F1.

The sequence mode trigger time stamps table shows that ultrasonic bursts occur with a nominal 4.2 ms period and confirms that none were missed.

RIS, Roll, and Sequence modes

These examples provide evidence of the usefulness of RIS, Roll, and Sequence modes. They show how you can extend the capabilities of your oscilloscope.

 Arthur Pini is a technical support specialist and electrical engineer with over 50 years of experience in electronics test and measurement.

Related Content

• Understanding the importance of acquisition memory
• Debug CAN/CAN FD buses with an oscilloscope
• 10 More tricks to extend oscilloscope usefulness
• Using oscilloscope X-Y displays

The post Oscilloscope special acquisition modes appeared first on EDN.

As system-on-chip (SoC) designs become more complex and powerful, catching potential errors and issues in specifications at the front-end of the design cycle is now far more critical. An EDA outfit based in Gentbrugge, Belgium, claims to have employed a shift left of simulation and synthesis tasks to catch specification errors early in the chip design cycle and fix inefficiencies in hardware description language (HDL)-based design flow.

The traditional HDL-based design flow is no longer viable, says Dieter Therssen, CEO of Sigasi, a privately held and self-funded firm founded in 2008. That’s because the traditional HDL workflow cannot accommodate the massive amounts of design specifications encompassing high-level synthesis results, complex SoC intellectual property (IP), and special features like generative artificial intelligence (genAI) creations.

Such levels of abstraction call for a plug-and-play approach for large HDL files containing functionality created with domain-specific knowledge to integrate hundreds of billions of transistors on a chip. In other words, HDL creation, integration, and validation must be redefined for the chip design cycle to fix the inefficient HDL-based design flow.

Therssen claims that Sigasi’s new HDL portfolio provides hardware designers and verification engineers the workflow makeover they need, enabling them to work in a powerful environment to create, integrate, and validate their designs while leveraging shift-left principles. Sigasi Visual HDL portfolio, an integrated development environment (IDE), employs the shift-left methodology to give hardware designers and verification engineers better insight during the design process.

It enables them to easily manage HDL specifications by validating code early in the design flow, well before simulation and synthesis flows. So, it’s a shift left of simulation and synthesis tasks, which flags problems while users enter the HDL code. While doing so, it enforces coding styles as recommended by safety standards such as DO-254 or ISO 26262 and catches Universal Verification Methodology (UVM) abuses.

Sigasi Visual HDL or SVH is fully integrated with Microsoft’s Visual Studio Code (VS Code), the most popular IDE according to Stack Overflow’s 2019 survey. That allows hardware designers and verification engineers to use git, GitHub Source Control Management, and a selection of utilities to facilitate mundane tasks like extracting TODO comments or bookmarking important sections in HDL code.

Sigasi Visual HDL will be available at the end of June 2024.

Sigasi Visual HDL, built as a tiered portfolio, offers three commercial editions and one community edition to meet specific SoC design and verification challenges.

1. Designer Edition

It meets the specific requirements of individual engineers who need introspection of their HDL projects. The Designer Edition includes all the essential guidelines and tools to create quality code, from hovers and autocompletes to quick fixes, formatting, and rename refactoring.

2. Professional Edition

It builds on the Designer Edition to incorporate more complex features focused on verifying HDL specifications. That includes graphic features like block diagrams and state machine views as well as UVM support.

3. Enterprise Edition

It offers features needed by large engineering teams, including command-line interface capabilities to safeguard the code repository and ensure a better handoff to verification groups. The Enterprise Edition also includes documentation generation as part of a better HDL handoff.

4. Community Edition

It lets users explore its features for non-commercial uses and is commonly used by students and teachers who want to better learn the fundamentals of HDL design. So, students no longer need to request a limited-time educational license; they can download the VS Code extension and upgrade their HDL education.

Sigasi Visual HDL—to be made available at the end of June 2024—will be displayed at Booth #2416 on second floor during Design Automation Conference (DAC) at Moscone West in San Francisco on 24-26 June 2024.

Related Content

• HDL: A Design Flow Runs Through It
• Opinion: Why IDEs for hardware design fail
• Introduction to High-Density Programmable Design
• HDL design methods for low-power implementation
• HDL-design challenges and philosophies for real-world ASIC implementations

The post HDL makeover from creation to integration to validation appeared first on EDN.

Editor’s Note: This DI is a two-part series.

Part 1 discusses audio oscillators, namely the Wien bridge and biquad, state-variable, or two-integrator-loop configuration.

Part 2 will add distortion-free feedback to the biquad to produce a pure sine wave.

Over the years, the Design Ideas (DI) column has featured many interesting oscillators, but none that I can recall was specifically designed to produce a really clean sine wave. Putting that omission together with the need to rebuild my old sub-0.01% sine generator gave me the perfect excuse to do some exploring, ending up with this DI, which is in two parts. First, we’ll look at ways not to do it, then part 2 will show how to get Audio Precision® distortion levels for RadioShack prices.

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

The alternatives

We won’t even consider squashing a triangle wave to give something reasonably sinusoidal, as 0.3% THD is the best that this approach can give without complex, multi-breakpoint “squashing” networks. Similarly, phase-shift oscillators are out; their q-factor is low, and three-gang pots are not catalog items. And if I were designing something for modern production, the starting-point would be a 24-bit DAC fed by a small processor containing a large look-up table, but that’s not something that can be knocked up from available parts in an afternoon.

So, what’s wrong with a good old Wien bridge circuit? The relevant Wikipedia page contains much historical, practical, and mathematical detail, and it reports that distortion levels down to 0.0003% (3  ppm) can be achieved, so we have one benchmark, though that’s most likely for a spot frequency rather than for a multi-range, fully-tunable device. A practical target is 96 dB or 0.0015%, which is the absolute limit for CD-type 16-bit linear PCM audio, while a more arbitrary goal is 120 dB, or 1 ppm. At these levels, THD may be dominated by circuit noise, which we’ll conveniently ignore for now.

Wien bridge oscillator

To check things out, I breadboarded a basic circuit using an LM4562 op-amp, carefully-matched resistors and polystyrene capacitors, and amplitude-stabilised using a photoconductive opto-isolator (essentially an LED and an LDR) driven by some heavy filtering. (A thermistor only works for higher output levels and is very bouncy.) Figure 1 shows the schematic and Figure 2 the output spectrum at close to 1 kHz for a level of -20 dBV (about -22 dBu, or 0.283 Vpk-pk).

Figure 1 A simple Wien bridge oscillator, using a photoconductive opto-isolator to help stabilise the amplitude.

Figure 2 The spectrum of the oscillator running at ~1 kHz, its output being at -20 dBV.

The spectrum implies a THD of about -76 dB or 0.02%: only so-so. However, I have learnt to be cautious of FFTs when the dynamic range of the signal to be examined exceeds about 90 dB, and prefer to notch out much of the fundamental, allowing a clearer view of the harmonics. Figure 3 shows the result of this: much better, with a THD of perhaps -88 dB, or 0.004%.

Figure 3 The spectrum of the same signal, but with the fundamental mostly notched out to show the harmonics more accurately.

Better, and not bad for a lash-up, but still off-target. (Note that the scale now shows the relative level of the harmonics, in dBc, as the oscillator’s output is at 20 dBV and the notch filter has a voltage gain of 10 dB or 20 dB.) With a little more thought and a lot more fiddling—or vice versa—we could probably improve its performance to the benchmark level, but a different starting-point looks more promising. The biggest problem is the amplitude control loop because removing all the ripple effects the damping badly, increasing the loop settling time. The low Q-factor of a Wien bridge, 1/3, does us no favours at all.

Bi-quad loop filter

My favourite circuit for comprehensive filters and oscillators has always been the bi-quad(ratic), state-variable, or two-integrator-loop configuration, one topology of which is shown in Figure 4.

Figure 4 A classic bi-quad or two-integrator-loop filter, with its high-pass, bandpass, and low-pass outputs.

You may well recognise something like this from a hundred and more NatSemi/TI datasheets and app notes. Its basics go back to the 1950s, I think, when “operational amplifiers” usually meant racks of glowing bottles, and it is versatile, designable, and controllable. This version is cut for a Q-factor of ~16 and a gain of ~10. We’ll now package it with a dashed line and treat it as a module. Assume ±5 V to ±15 V supplies, with plenty of decoupling caps.

To make it oscillate, we take the bandpass (BP) output and feed it back to the input at a suitable level. This is often done by limiting the BP signal with a pair of back-to-back diodes, much as shown in Figure 5.

Figure 5 The filter with added diode-limited feedback becomes an oscillator, but with plenty of harmonics, giving a THD of around 0.0%.

With the values shown, the diodes compress the signal to ~2/3 of the output level. Less than this, and we lose stability; more, and the harmonics become excessive. The feedback network shown keeps the impedances around the diodes low to allow clean operation up to 100 kHz and beyond, while the added thermistor improves the amplitude stability with temperature. Match the diodes for forward voltage to minimise even-harmonic distortion. The third harmonic produced by the diodes is reduced by about 22 dB by the time it reaches the LP output, higher harmonics being attenuated even more.

The spectrum for the raw (LP) output shows a THD of ~0.08%, which is about the best that this approach can give. (The “notched” spectrum—not shown—showed fewer and lower peaks, but the third harmonic—the limiting factor—was still at the same level.) Because there is no control loop as such, there can be no loop stability issues, though the settling-time is appreciable at low frequencies. It’s still a good basis for a multi-range general-purpose AF oscillator.

With correspondingly larger capacitors and resistors, it also works well at very low frequencies, though FET-input op-amps are needed to avoid leakage. With tuning components of 5µ7 (= 4µ7 + 1µ0; PET dielectrics) and 3M3 resistors, and with TL072s fitted in place of the LM4562s, the waveform at ~8 mHz, or a calculated 118.2 s/cycle, looks like Figure 6.

Figure 6 Using µF and MΩ for tuning, a diode-stabilised bi-quad will easily work down in the mHz region—about 8 mHz, in this case.

Why anyone would want to use a purely analog approach to generating such low-frequency signals escapes me, but trying it was irresistible, even if it took an hour or so to settle down properly. (I lacked the patience to try even larger values of timing components. And don’t even think of asking for the spectrum.)

To be continued…

In part 2, we will take the bi-quad filter and add distortion-free feedback, similar to that used with the Wien bridge but on steroids, to produce a seriously pure sine wave.

—Nick Cornford built his first crystal set at 10, and since then has designed professional audio equipment, many datacomm products, and technical security kit. He has at last retired. Mostly. Sort of.

Related Content

• Squashed triangles: sines, but with teeth?
• Building a JFET voltage-tuned Wien bridge oscillator
• Injection-lock a Wien-bridge oscillator
• Switched-Capacitor Filters Beat Active Filters at Their Own Game
• Oscillator keeps THD below 1 ppm
• 555 triangle generator with adjustable frequency, waveshape, and amplitude; and more!
• Inductor-based astable 555 timer circuit

The post Ultra-low distortion oscillator, part 1: how not to do it. appeared first on EDN.

The Internet of Things (IoT) devices that increasingly permeate our homes, workplaces, and daily lives are only as secure as their most vulnerable components. As the adoption of these connected devices escalates, so too do concerns about their security and potential vulnerabilities within the software supply chain.

Stakeholders, including manufacturers and regulators, are turning to rigorous security testing and improved tools like the software bill of materials (SBOM) and binary analysis to enhance software supply chain transparency and manage software risks more effectively.

Figure 1 Embedded developers can generate highly accurate SBOMs to analyze components’ vulnerabilities and dependencies. Source: Finite State

SBOMs are comprehensive records that detail each software component within a product. They are critical for understanding potential vulnerabilities and dependencies that may be embedded in the software. However, not all SBOMs provide a comprehensive view into a device’s components. That’s where binary analysis comes in.

Why binary analysis?

Binary analysis forms the cornerstone of the transparency and continuous visibility needed for a robust and effective product security testing framework.

Binary analysis exposes vulnerabilities in the final software product that might not be evident during earlier testing stages, ensuring that the software delivered to consumers is as secure as possible. Binary analysis accomplishes this by allowing security teams to scrutinize the final, compiled version of the software inside connected devices, exposing vulnerabilities that emerge during the compilation process or from third-party components.

This approach provides a complete security assessment of the final software product, mitigating discrepancies between the software under test and the software consumers ultimately receive.

By providing a comprehensive view of software vulnerabilities, binary analysis ensures that connected products are as secure as possible from today’s cyber threats, providing verifiable due diligence that can build trust with regulators, manufacturers, distributors, and, ultimately, consumers.

Software transparency with SBOMs and VEX

Software transparency is critical to a comprehensive testing approach. It is essential for building trust with customers, stakeholders, and regulators. A central component of this transparency is the generation of software bill of materials (SBOMs) and Vulnerability Exploitability eXchange (VEX) for software products.

While SBOMs list a product’s software components, VEX, by comparison, provides a standardized format for communicating detailed information about vulnerabilities and their exploitability. Integrating SBOMs and VEX provides a more transparent and streamlined vulnerability reporting process. It allows faster and more effective communication of vulnerabilities and associated risks to all relevant parties.

Embracing transparency through SBOMs, binary analysis, and VEX helps ensure a comprehensive software security assessment, and fosters an environment conducive to rapid and clear communication of vulnerabilities.

This environment enables product and software supply chain security practitioners to uphold their commitment to the highest security and reliability standards in an age where security is increasingly seen not merely as a feature but as a fundamental requirement for technology products.

The global response and the need for transparency

Recent regulatory efforts in the United States and European Union highlight the growing emphasis on software supply chain security. These include the FDA’s Final Cybersecurity Guidance and the EU’s Cyber Resilience Act (EU CRA). The drive toward more stringent regulations reflects a broader trend of prioritizing security by design.

Binary analysis supports these efforts by enabling deeper visibility into software components, helping companies meet and exceed, and show their commitment to these evolving regulatory standards.

The role of independent risk assessment

In recent years, U.S. policymakers have pivoted their approach to supply chain risks. Their focus, and concerns, have increasingly centered on Chinese technology firms, citing potential threats about technology security, intellectual property (IP) theft, and espionage

While several Chinese technology companies have faced enforcement actions due to national security risks and the need to secure software supply chains, others are making significant strides toward enhancing security and maintaining transparency. Some, like Quectel, have committed to continuous security improvement and have evidenced this commitment through their adoption of software supply chain testing that integrates SBOMs and binary analysis.

Companies like Quectel that adopt, follow, and promote clearer, more transparent software supply chain security standards and embrace and champion the importance of security by design will lead the charge to stronger, more resilient software security.

They will spearhead the evolution we need to protect consumers and industry from the increasing onslaught of threats to the IoT/connected device ecosystem from a variety of bad actors, both those who are state-sponsored and those who are not.

Integrating binary analysis into software supply chain security protocols

A robust security program includes multiple stages: binary analysis, integrated testing and remediation throughout the development lifecycle, manual and automated penetration testing, independent risk assessment, and comprehensive software transparency and reporting.

Each of these phases contributes to the overarching goal of securing software products throughout their lifecycle, bolstering security and transparency, while unearthing distinct categories of vulnerabilities and addressing a broad spectrum of potential security risks.

Binary analysis, in particular, ensures that vulnerabilities related to binary components are identified early and managed effectively.

Figure 2 Binary analysis exposes components vulnerabilities early in the design cycle. Source: Finite State

Leveraging developments in binary reverse engineering, automated reasoning, and other advanced techniques helps identify otherwise elusive vulnerabilities to ensure software products align with the requirements and intent of new and emerging regulation as well as industry-leading security standards and best practices.

Notably, binary analysis provides security practitioners the ability to identify and trace vulnerabilities to otherwise opaque binaries, resulting in more secure software supply chains by identifying the sources of potential threats.

A commitment to comprehensive security

Embracing binary analysis as the cornerstone of security testing ensures that companies can address the full spectrum of potential risks in software supply chains. By integrating advanced testing methods, promoting transparency through SBOMs and binary analysis, and conducting independent risk assessments, businesses, regardless of their geographical location, can demonstrate a solid commitment to security. This comprehensive approach is vital in an era where digital threats are increasingly sophisticated and pervasive.

Companies that proactively seek to prioritize transparency in their security strategies and adhere to established standards not only comply with regulations but also demonstrate a clear commitment to maintaining high-security standards.

An independent risk assessment is critical in verifying the security posture of software products. This independent evaluation helps foster trust and confidence in the security measures a company implements, assuring stakeholders, regulators, and, ultimately, consumers of the robustness and effectiveness of their security practices.

That’s an approach everyone can support.

Matt Wyckhouse—founder and CEO of Finite State—has over 15 years of experience in advanced solutions for cyber security. As the technical founder and former CTO of Battelle’s Cyber Innovations business unit, and now the CEO of Finite State, Matt has been at the forefront of tackling complex cyber security challenges across various domains, including IoT and embedded systems.

Related Content

• Navigating IoT security in a connected world
• Security Key Proliferation Vexes IoT Supply Chain
• Protecting embedded IoT devices with fuzz testing
• Hardware RoT: The Key to IoT Security in Smart Homes
• What’s Driving the Shift from Software to Hardware in IoT Security?

The post Why binary analysis is the cornerstone of robust IoT testing appeared first on EDN.

The PI3WVR41310 four-lane video switch from Diodes supports DisplayPort 2.1 transmission rates at 13.5 Gbps and HDMI 2.1 at 12 Gbps. Its high-speed capability enables increased resolution and refresh rates in commercial displays, gaming monitors, video-matrix switches, and embedded applications.

Operating as a four-lane 3:1 multiplexer or 1:3 demultiplexer, the PI3WVR41310 achieves low insertion loss of -1.8 dB at 13.5 Gbps and offers a -3 dB bandwidth of 10 GHz. The device can pass high-speed signals with up to 1.2 V peak-to-peak differential and TMDS signals with a common-mode voltage from 0 V to VDD.

To aid proper configuration and communication between connected devices, there are dedicated display data channel (DDC) and auxiliary channel (AUX) pins, as well as hot-plug detection (HPD) pins. These pins allow equipment to automatically recognize when connections are made.

Housed in a 52-pin, 3.5×9-mm TQFN package, the PI3WVR41310 video switch costs $1.65 each in lots of 3500 units.

PI3WVR41310 product page

Diodes

Find more datasheets on products like this one at Datasheets.com, searchable by category, part #, description, manufacturer, and more.

The post Multistandard video switch handles 13.5 Gbps appeared first on EDN.

AOS offers the AOZ71137QI, a 3-rail, 7-phase controller that complies with Intel Mobile Voltage Positioning (IMVP) 8, 9, 9.1, and 9.2 specifications. Together with an AOS power stage, the hybrid digital controller offers a Vcore power management system for Intel Meteor Lake and Arrow Lake CPUs, as well as other notebook CPUs.

The step-down controller supports four separate SVID domains: up to four phases for the core voltage, two phases for graphics, and one phase for the auxiliary output. It also includes the Psys domain’s reporting functions. The part operates in a variable frequency hysteretic peak current mode, combined with a proprietary phase current sensing scheme. This design allows for fast transient response and optimal current balance for both transient and DC loads.

AOS offers a portfolio of DrMOS and Smart Power Stages (SPS) for use with the AOZ71137QI controller. According to the company, DrMOS devices meet Vcore power requirements with robustness, featuring a 30-V breakdown voltage and UIS testing. SPS devices integrate current and temperature monitoring for accurate reporting. The AOZ71137QI also works with industry-standard DrMOS and SPS components.

The AOZ71137QI controller is available now in production quantities, with lead times of 12 to 16 weeks. Prices start at $2.40 each in lots of 1000 units.

AOZ71137QI product page

Alpha & Omega Semiconductor 

Find more datasheets on products like this one at Datasheets.com, searchable by category, part #, description, manufacturer, and more.

The post Multiphase controller meets Intel IMVP 9.2 appeared first on EDN.

Fabless semiconductor firm CGD announced two packages for its ICeGaN family of GaN power ICs that enhance thermal performance. Both are variants of the dual-flat no-leads (DFN) package and will debut at this month’s PCIM Europe exhibition.

The DHDFN-9-1, or dual heat-spreader DFN, is a thin 10×10-mm package featuring dual-side cooling. Wettable flanks enable more reliable optical inspection. This package supports bottom-side, top-side, and dual-side cooling, outperforming the TOLT package, particularly in top-side and dual-side cooled configurations. Additionally, a dual-gate pinout simplifies PCB layout and paralleling, enabling applications up to 6 kW.

The BHDFN-9-1, or bottom heat-spreader DFN, provides bottom-side cooling and wettable flanks. According to CGD, this package has a thermal resistance of 0.28 K/W, matching or exceeding other leading devices. Despite being smaller than a TOLL package, the 10×10-mm BHDFN package shares a similar footprint. This allows a common layout with TOLL-packaged GaN power ICs, simplifying use and evaluation.

ICeGaN power transistors operate with standard silicon gate drivers and do not require negative voltages for shutdown. They can be used in servers, data centers, inverters, motor drives, and other industrial applications.

Cambridge GaN Devices 

Find more datasheets on products like this one at Datasheets.com, searchable by category, part #, description, manufacturer, and more.

The post GaN power packages improve thermal resistance appeared first on EDN.

Mitsubishi will be sampling its MGFS52G38MB GaN power amplifier module (PAM) capable of supplying 16 W of average output power starting this month. The device can be used in 32T32R antenna configurations to reduce the manufacturing cost and power consumption of 5G massive MIMO (mMIMO) base stations.

In September 2023, Mitsubishi introduced a GaN PAM offering 8 W (39 dBm) of average output power across a frequency range of 3.4 GHz to 3.8 GHz, suitable for 64T64R mMIMO antennas. The new GaN PAM increases average output power to 16 W (42 dBm) over a frequency range of 3.3 GHz to 3.8 GHz, targeting 32T32R mMIMO antennas. This advancement extends the coverage of 5G mMIMO base stations, while minimizing the number of required PAMs.

Key specifications for the GaN power amplifier module include:

Mitsubishi will exhibit the 16-W GaN PAM at this month’s IEEE MTT-S International Microwave Symposium. A datasheet was not available at the time of this announcement.

Mitsubishi Electric

Find more datasheets on products like this one at Datasheets.com, searchable by category, part #, description, manufacturer, and more.

The post GaN power amp delivers 16 W for mMIMO appeared first on EDN.

Microchip’s TimeProvider XT extension system migrates E1, T1, or CC synchronization outputs to a fully redundant TimeProvider 4100 grandmaster. The accessory device allows operators to replace existing SONET/SDH frequency equipment, while adding timing and phase, essential for 5G networks.

Each TimeProvider XT shelf is configured with two distribution modules and two plug-in modules. Together, they provide 40 redundant and individually programmable outputs with synchronization that meets ITU-T G.823 requirements for the control of wander and jitter. Operators can scale up to 200 fully redundant T1/E1/CC communication outputs by connecting five XT shelves to a pair of grandmasters. All configuration, status monitoring, and alarm reporting is done through the grandmaster.

TimeProvider is compatible with DCD, SSU 2000, TSG-3800, and TimeHub systems’ wire-wrap and output panels, eliminating the need to rewire network elements. A composite clock (CC) input allows for live in-service CC phase cutovers, typically performed during maintenance windows to ensure continuous network synchronization.

The TimeProvider XT extension system is available now for purchase. Contact a Microchip sales representative or authorized distributor.

TimeProvider XT product page

Microchip Technology 

Find more datasheets on products like this one at Datasheets.com, searchable by category, part #, description, manufacturer, and more.

The post Timing module migrates legacy equipment appeared first on EDN.

Software engineers developing artificial intelligence (AI) models using standard frameworks such as Keras, PyTorch, and TensorFlow are usually not well-equipped to translate those models into silicon-based implementations. A new synthesizable tool claims to solve this design conundrum with faster and more power-efficient execution compared to standard AI processors.

Most machine learning (ML) experts working on AI frameworks—Keras, PyTorch, and TensorFlow—are not comfortable with synthesizable C++, Verilog, or VHDL. As a result, there has been no easy path for ML experts to accelerate their applications in a right-sized ASIC or system-on-chip (SoC) implementation.

Enter hls4ml, an open-source initiative intended to help bridge this gap by generating C++ from a neural network described in AI frameworks such as Keras, PyTorch, and TensorFlow. The C++ can then be deployed for an FPGA, ASIC or SoC implementation.

Siemens EDA joined hands with Fermilab, a U.S. Department of Energy laboratory, and other leading contributors to hls4ml while tying up its Catapult software for high-level synthesis (HLS) with hls4ml, an open-source package for ML hardware acceleration. The outcome of this collaboration was Catapult AI NN software for high-level synthesis of neural network accelerators on ASICs and SoCs.

Figure 1 Here is a typical workflow to translate an ML model into an FPGA or ASIC implementation using hls4ml, an open-source codesign workflow to empower ML designs. Source: CERN

Catapult AI NN extends the capabilities of hls4ml to ASIC and SoC design by offering a dedicated library of specialized C++ machine learning functions tailored to ASIC design. This allows designers to optimize power, performance, and area (PPA) by making latency and resource trade-offs across alternative implementations from the C++ code.

Design engineers can also evaluate the impact of different neural net designs to determine the best neural network structure for their hardware. Catapult AI NN starts with a neural network description from an AI framework, converts it into C++ and synthesizes it into an RTL accelerator in Verilog or VHDL for implementation in silicon.

Figure 2 Catapult AI NN provides automation of Python-to-RTL for neural network (NN) hardware designs. Source: Siemens EDA

“The handoff process and manual conversion of a neural network model into a hardware implementation is very inefficient, time-consuming and error-prone, especially when it comes to creating and verifying variants of a hardware accelerator tailored to specific performance, power, and area,” said Mo Movahed, VP and GM for high-level design, verification and power at Siemens Digital Industries Software.

This new tool enables scientists and AI experts to leverage industry-standard AI frameworks for neural network model design and synthesize these models into hardware designs optimized for PPA. According to Movahed, this opens a whole new realm of possibilities for AI/ML software engineers.

Catapult AI NN allows developers to automate and implement their neural network models for optimal PPA concurrently during the software development process,” he added. Panagiotis Spentzouris, associate lab director for emerging technologies at Fermilab, acknowledges the value proposition of this synthesis framework in AI designs.

“Catapult AI NN leverages the expertise of our scientists and AI experts without requiring them to become ASIC designers,” he said. That’s especially critical when A/ML tasks migrate from the data center to edge applications spanning consumer appliances to medical devices. Here, the right-sized AI hardware is crucial to minimize power consumption, lower cost, and maximize end-product differentiation.

Related Content

• Key technologies push AI to the edge
• C++ runs hardware/software designs
• Adapting the Microcontroller for AI in the Endpoint
• Edge AI accelerators are just sand without future-ready software
• Don’t Be Misled By “Accuracy” — 3 Insights For More Useful AI Models

The post Synthesis framework simplifies silicon implementation for AI models appeared first on EDN.

Given their generally low cost, small size, robust construction, accuracy, versatility, and sensitivity, it’s no wonder that basic negative temperature coefficient (NTC) thermistors rate among the most popular temperature sensors available. However, their temperature response function is highly nonlinear (literally exponential), making excitation and signal digitization and processing interesting design exercises.

The typical NTC thermistor’s datasheet (e.g., Molex 2152723605) summarizes thermo-electric properties with four parameters (Equations 1 through 5), shown in Figure 1 (numbers borrowed from 2152723605 data):

To = rated/calibration temperature (25°C = 298.15 K)          (1)
Ro = resistance at To (10k ±1%)                                               (2)
b = beta (3892 K)                                                                         (3)
Dissipation (self-heating) factor (1.5 mW/°C)                       (4)

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

Then thermistor resistance (Rt) as a function of temperature (T) in Kelvin is predicted by:

Rt = Ro exp(b(T-1 – To-1))                                                           (5)

Applying the classic KISS principle, we see in Figure 1 a candidate for the simplest possible circuit to wheedle a signal from a thermistor, and some basic math to winnow a temperature measurement from its output and parameters 1, 2, and 3 from above.

Figure 1 Basic thermistor passive excitation circuit: Cx = optional noise reduction, perhaps 100 nF; Rx = excitation resistor; Rt = Rx(V/Vref)/(1 – V/Vref); T = (Ln(Rt/Rx)/b + Tx-1)-1.

Other than the (very uncritical) Cx and the thermistor itself, the only component in Figure 1 is Rx. How best to choose its value?

Intuition suggests and math confirms that the optimum (at least nearly so) choice is to make Rx equal to the thermistor’s at the middle of the span of temperature measurement required by the application. Said mid-point temperature (call it Tx) will then output V = Vref/2 and thus distribute ADC resolution symmetrically over the range of measurement. Equation. 5 tells us how to get there.

Suppose we choose a measurement range of 0oC to 100oC, then Tx = 50oC = 323.15 K and Equation 5’s arithmetic tells us (using the 2152723605’s numbers):

Rx = Ro exp(b(Tx-1 – To-1))
Rx = 10000 exp(3892(323.15-1 – 298.15-1))
Rx = 3643 (closest standard 1% value = 3650)

Now, if we conveniently choose Vref = 5V for both input to Rx and to the reference input of the ADC (since this is a ratiometric measurement, the absolute value of Vref is relatively unimportant) we can set:

X = ADC/2N = V/Vref
Then,
T = (Ln(X/(1 – X))/b + Tx-1)-1
oC = (Ln(X/(1 – X))/3892 + 0.003095)-1– 273.15

 And the job is done! 

Or is it? What about that dissipation (self-heating) factor (1.5 mW/°C)? 

We obviously don’t want thermistor self-heating to significantly interfere with the temperature measurement. A reasonable limit for self-heating error might be half a degree and in the case of the 2152723803’s 1.5 mW/°C, this would dictate limiting maximum dissipation to no more than:

Pmax = (1.5 mW)/2 = 0.75 mW

Dissipation maxes out to Vref2/4/Rx when Rt = Rx and in this case of Vref = 5 V will therefore be:

Pmax  = Vref2/4/Rx
= 25/4/3650
= 1.7 mW
= 1.1°C

Yikes! That’s more than twice the stipulated maximum self-heating error. What to do? Not to worry, a solution is suggested by Figure 2.

Figure 2 Rvdd limits max thermistor self-heating to Pmax: Pmax = Vdd2/4/(Rx + Rvdd); Rvdd = Vdd2/4/Pmax – Rx if  > zero, else Rvdd = 0; (Vdd Rx/(Rvdd + Rx)) < Vref  < Vdd.

Dipping again into the 2152723605 numbers and keeping Vdd = 5 V:

Rvdd = 25/4/(0.75 mW) – 3650
Rvdd = 8333 – 3650 = 4.7k
Pmax = 0.749 mW
2.8 V < Vref  <  5 V

Note that if the Figure 2 math yields a zero or negative value for Rvdd, then no Rvdd is required, and the original Figure 1 circuit will work just fine.

Although Vref will vary with Rt and therefore temperature, external-reference monolithic ADCs are typically very tolerant of Vref variations within the range shown and will perform accurate ratiometric conversions despite them.

And now the job is done! We just had to keep thinking positive.

Stephen Woodward’s relationship with EDN’s DI column goes back quite a long way. Over 100 submissions have been accepted since his first contribution back in 1974.

 Related Content

• Linearize thermistors with new formula
• Designing with temperature sensors, part two: thermistors
• Pseudologarithmic thermistor signal conditioning spans wide temperature range
• Precision temperature controller has thermal-gradient compensation

The post Getting positive results from NTC thermistors with a simple passive interface appeared first on EDN.

In modern electronics, embedded systems have become increasingly complex, incorporating a variety of sensors and components in many applications including IoT, computing, wearables and security-sensitive applications. To meet the growing requirements of these markets, the MIPI Alliance has developed the improved inter-integrated circuit® (I3C) interface. I3C is an advanced serial communication interface that offers a major upgrade in how electronic components can communicate with each other by providing faster communication rates, lower power consumption, and improved design flexibility. As a key component of an embedded system, microcontrollers (MCUs) are used to control application functions like sensor signal acquisition and closed-loop control. We will delve into several applications that can utilize an MCU with an I3C communication interface, offering a robust upgrade path and compatibility for I2C and SPI implementations. 

I3C and IoT applications

IoT touches nearly every facet of our daily routines, spanning from household gadgets to sophisticated building automation and wearable devices. These interconnected devices gather and exchange data, fundamentally shaping our digital ecosystem. Within IoT devices, different types of sensors play a pivotal role, measuring, monitoring, and relaying crucial physical attributes like temperature, humidity, pressure, and distance, among others.

The I3C protocol offers several benefits for networked sensor nodes. It enables high-speed communication, with speeds of up to 12.5 MHz in single data rate (SDR) mode. It also supports in-band interrupts and dynamic addressing. In dynamic addressing, a central controller assigns unique addresses to each connected device, preventing address conflicts. Compared to its predecessor I2C, I3C boasts faster speeds, a simpler 2-wire interface, a more efficient protocol structure, and operates at lower voltages to reduce power consumption. These improvements make I3C well-suited for efficiently managing multiple sensor nodes within a connected network.

Incorporating a low cost MCU with built-in I3C peripherals into IoT sensor nodes as an analog “aggregator” can enhance functionality and efficiency of the entire sensor network. In this setup, the MCU’s on-chip analog-to-digital converter (ADC) is utilized to convert readings from multiple analog sensors into digital values. These digital values can then be stored in the MCU’s internal memory for further analysis or organized for more efficient transmission. The aggregated sensor data is transmitted to the main controller via the I3C bus at intervals optimized for system efficiency.

The distinct advantage of I3C in sensor-based systems becomes apparent when considering its capacity to minimize component complexity, cost, and power consumption by necessitating fewer pins and wires compared to alternative communication interfaces. For system designers navigating the demanding IoT market landscape, a compact MCU with I3C communication interface emerges as an essential solution, facilitating the creation of successful IoT devices that align with market requirements.

Multiple protocols and multiple voltages in embedded devices

As technology requirements grow, embedded developers face increasing challenges with backward compatibility. This compatibility is crucial because it allows for embedded systems to be gradually updated, rather than completely redesigned. To help ease the transition to I3C, the new communication protocol addresses the limitations of I2C and SMBus, while using the same two pins as I2C for clock and data to maintain compatibility.

While I3C aims to be backward-compatible with I2C/SMBus protocols, the presence of an I2C/SMBus device on an I3C bus can affect bus performance, even with controller optimization for I3C devices. To resolve this, an MCU with an I3C module can serve as a bridge device, isolating I2C/SMBus target devices from the “pure” I3C bus. This maintains the integrity of the I3C bus, allowing the main I3C controller to communicate with I2C /SPI devices via the bridge MCU. Additionally, the MCU can consolidate interrupts from I2C /SMBus devices and transmit them to the main I3C controller using in-band interrupts, without additional pins or signals.

Embedded systems incorporate various components such as MCUs, sensors, and other circuits. Oftentimes, these components need to be connected to one another, yet they operate in different voltage domains. For instance, analog sensors typically operate at 5 V, while communication protocols like I2C and SMBus require 3.3 V. The I3C bus can even operate at 1 V to match the requirements of modern high-speed processors.

MCUs with a multi-voltage I/O (MVIO) feature resolve voltage incompatibility and eliminate the need for level shifters. This feature enables I3C and I2C /SMBus buses to operate at different voltages simultaneously. For instance, an MCU can run the I3C bus at 1 V while keeping the I2C /SMBus bus at a higher 3.3 V for compatibility with legacy devices.

As shown in Figure 1, Microchip’s PIC18-Q20 MCUs, with MVIO support, offer multiple communication protocols like I3C, SPI, I2C, and UART, and up to three independent operating voltage domains. This flexibility proves highly beneficial in complex networked environments where devices use different protocols and voltages, allowing embedded developers to maintain existing protocols while futureproofing their designs.

Figure 1 The PIC18-Q20 MCUs, with MVIO support, offer multiple communication protocols like I3C, SPI, I2C, and UART, and up to three independent operating voltage domains. This offers flexibility in networked environments where embedded devices may use different protocols and voltages. Source: Microchip

Modern computing infrastructure

People can easily underestimate how much we rely on data centers in our daily digital lives. From conducting business and financial transactions to browsing the internet, storing data, engaging in social networking, attending virtual meetings, and enjoying digital entertainment—all these activities are facilitated by data centers. These centers ensure that our data is safe, our internet is fast, and our digital services are always available.

At the core of the data center lies the modern blade server: a highly advanced computer designed to maximize space efficiency and optimize network performance on a large scale. Due to the crucial nature of their function, certain system tasks within each server chassis are delegated to a sideband controller. While the main processing unit focuses on managing the primary data flow, the sideband controller steps in to enhance network performance. It establishes a secondary communication channel to oversee individual server blades and handles important tasks such as monitoring system health, detecting faults, discovering and configuring devices, updating firmware, and conducting diagnostics without disrupting the main processor. This ensures smooth and efficient operation. Sideband management serves as a critical tool that can greatly enhance the reliability, availability and efficiency of data centers.

Solid state drives (SSDs) are also commonly used in data centers to store and quickly access data. The newest SSD form factor, SNIA® Enterprise and Datacenter Standard Form Factor (EDSFF), has adopted the I3C protocol for sideband communication as a natural upgrade from the existing SMBus protocol. I3C addresses the demand for faster performance, higher data transfer rates, and improved power efficiency. The high-speed communication of I3C enables faster bus management and configuration modifications for enhanced system responsiveness.

Flexible MCUs such as the PIC18-Q20 family (Figure 2) are particularly well-suited for system management tasks in data center and enterprise environments. With up to two separate I3C interfaces, these MCUs can easily connect to an SSD controller for performing system management tasks, as well as to a baseboard management controller (BMC) via a sideband connection. Moreover, with built-in legacy communication protocols like I2C/SMBus, SPI, and UART, these devices represent an ideal solution for both current and next-generation SSD designs.

Figure 2: The PIC18-Q20 family will easily connect to an SSD and BMC controller via a sideband connection. Source: Microchip

I3C’s growing ubiquity

The integration of the I3C protocol has emerged as an enabling force in embedded systems. The enhanced communication capabilities, lower power consumption, and compatibility with existing protocols make I3C a cornerstone for next-generation IoT and computing applications. By optimizing sensor functionalities in IoT devices and data center communication, the versatility of I3C when integrated into MCUs can provide a robust foundation for the modern electronic systems. The adoption of I3C is quickly growing in ubiquity, enabling enhanced performance, reliability, and efficiency.

Stephanie Pinteric and Ulises Iniguez are senior product marketing engineers in Microchip’s 8-bit MCU business unit.

 Related Content

• Fundamentals of I3C interface communication
• Proper IC interconnects for high-speed signaling
• How 8-bit MCUs enable smart farm technology
• Multichannel priority amplifier
• Eliminating level shifters in microcontroller applications – Part 1
• Design calculations for robust I2C communications
• Slideshow: The most-popular MCUs ever

The post Elevating embedded systems with I3C appeared first on EDN.

A new generation of CMOS image sensors can exploit all the image data to perceive a scene, understand the situation, and intervene by embedding artificial intelligence (AI) in the sensor. CEA-Leti researchers have reported this design breakthrough when demand for smart image sensors is growing rapidly due to their high-performance imaging capabilities in smartphones, automobiles, and medical devices.

The design breakthrough is built on a combination of hybrid bonding and high-density through silicon via (HD TSV) technologies, which facilitates the integration of various components like image sensor arrays, signal processing circuits and memory elements in image sensors with precision and compactness.

The design breakthrough is based on a three-layer test vehicle that featured two embedded Cu-Cu hybrid-bonding interfaces, face-to-face (F2F) and face-to-back (F2B), and with one wafer containing high-density TSVs. Source: CEA-Leti

Communication between the different tiers in an image sensor design necessitates advanced interconnection technology. The new design presented by CEA-Leti employs hybrid bonding due to its very fine pitch in the micron and sub-micron range. It also uses HD TSV, which has a similar density that enables signal transmission through the middle tiers.

“The use of hybrid bonding and HD TSV technologies contribute to the reduction of wire length, a critical factor in enhancing the performance of 3D-stacked architectures,” said Renan Bouis, lead author of the paper titled “Backside Thinning Process Development for High-Density TSV in a 3-Layer Integration.” He added that stacking multiple dies to create 3D architectures, such as three-layer imagers, has led to a paradigm shift in sensor design.

The paper presents the key technological bricks that are mandatory for manufacturing 3D, multilayer smart imagers capable of addressing new applications that require embedded AI. “This sets the stage to work on demonstrating a fully functional three-layer, smart CMOS image sensor, with edge AI capable of addressing high-performance semantic segmentation and object-detection applications,” said Eric Ollier, project manager at CEA-Leti and director of IRT Nanoelec’s Smart Imager program.

The Grenoble, France-based research house CEA-Leti is a major partner of IRT Nanoelec, an R&D institute also based in Grenoble, France.

It’s worth mentioning that at ECTC 2023, CEA-Leti scientists reported a two-layer test vehicle combining a 10-μm high, 1-μm diameter HD TSV and highly controlled hybrid bonding technology, both assembled in F2B configuration. Now, they have shortened the HD TSV to 6-μm height, which led to the development of a two-layer test vehicle exhibiting low dispersion electrical performances and enabling simpler manufacturing.

It’s mainly due to an optimized thinning process that allowed the substrate thickness to be reduced with favorable uniformity. “This reduced height led to a 40% decrease in electrical resistance, in proportion with the length reduction,” said Stéphan Borel, lead author of the paper titled “Low Resistance and High Isolation HD TSV for 3-Layer CMOS Image Sensors”. “Simultaneous lowering of the aspect ratio increased the step coverage of the isolation liner, leading to a better voltage withstand.”

Scientists at CEA-Leti are confident that this smart image sensor technology will enable a variety of new applications.

Related Content

• Embedded Intelligence Empowers Image Sensors
• How PMICs operate in image sensor-based designs
• Image sensors evolve to meet emerging embedded vision needs
• The Next-Generation CMOS Image Sensor: All 4-Coupled (A4C) Sensor
• Image sensor enables higher quality images and video recording in camera phones

The post Image sensor embeds AI to explore image data appeared first on EDN.

Editor’s note: This DI invites the reader to reference custom Excel sheets for:

• Low pass filter,
• High pass filter, and
• Bandpass filter design.

Please refer to these as you review this DI.
—Aalyia Shaukat

Several manufacturers offer op amp-based filter design tools [1-3]. Some tools choose off-the-shelf capacitor values, but others select non-standard ones. The option to alter passive component (resistor and capacitor) values while maintaining a given response is often limited, if available at all. Certain tools seem to consider the effects of particular passive component combinations on unwanted variations in filter responses, but others do not. Some limit designs to a specific set of filter characteristics (Butterworth, Bessel, Chebyshev) when filter design tables of quality factor (Q) and resonance frequency f0 (Hz) for other response types are readily available (see section 8.4  in [4] and [5]).

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

This article addresses second-order op amp-based low, band, and high pass filter sections. A reference for many of the design equations used in the article can be found here [6]. Excel spreadsheets for each filter type allow the user to specify three defining characteristics: passband gain, Q, and resonance frequency f0. It requests the tolerances in percent of the capacitors and the resistors to be used. Each filter has a minimum of four passives, and so there is an infinite number of combinations of values which will satisfy the three characteristics. Because the difference between successive standard capacitor values is at least 10% while that for 1% resistors is only 2%, and because quality capacitors are generally more expensive, the user is given the option of specifying the two capacitors’ values rather than those of the resistors. This leaves it to the spreadsheet to calculate the latter. If desired, near exact resistor values can be implemented in a physical filter cheaply by using two standard parts.

The main purpose of this article is to demonstrate graphically and numerically how different sets of passive component values and tolerances contribute to unwanted variations in filter responses. From these, the user can readily select capacitor values which minimize the combination of a filter’s response sensitivity and component size and cost.

Before getting into a detailed discussion about sensitivity, it’s worth discussing the types of passive components (see [4] pp. 8.112-8.113) that should be used in filters. For SMD and through-hole applications, 1% metal film resistors are a good, inexpensive choice as are NPO ceramics (stay away from the monolithic, high dielectric value ceramics). For surface mount applications only, there are thin film capacitors. For through-hole, polystyrene, polypropylene, and Teflon capacitors are available. As for active components, this article assumes ideal op amps (which we know are difficult to source). The reference (see [4] pp. 8.114-8.115) gives a discussion of what is required of this component, the biggest concern of which is the gain available at f0 Hz. By “rule of thumb” this should exceed 4·Q2 for the filter by a factor of 10 or more.

But rather than dealing with a rule of thumb, it is recommended to start by simulating the filter using nominal value passive components and an op amp with no high frequency roll-off and a resonance frequency gain of 1000·4·Q2 or more. Then, reduce the gain and introduce a high frequency roll off until a response change is seen. Finally, an op amp with matching or superior characteristics can then be selected and used in a simulation for design confirmation.

Generally, a variation in a passive’s value will result in some change in filter response characteristics. If that change is small enough, there will be some sensitivity S which is a constant of proportionality relating the filter parameter y variation to the passive x’s change. To keep S dimensionless, it will be useful to relate fractional changes in the passive’s value to those of the parameter. Mathematically,

Solving for in the limit as Δx goes to zero, we have:

The instances of x that are of concern are the resistor and capacitor values that make up the filter. The instances of y are the defining filter parameters: passband gain, Q and ω0 = 2π·f0. The following is an example of how the various S values are computed for the low pass filter in Figure 1.

Figure 1 A sample lowpass filter used to compute various S values.

The frequency domain (s-plane) transfer function of the above filter is:

For such a section, this is equal to:

By equating like terms, the various parameters can be computed. But what is really needed is some total sensitivity of each y parameter to a complete filter design, one which involves all its passive components. One way to do this is to use the following equation:

This is the square root of the sum of the squares of the sensitivities of a specific y to each of the i component’s xi multiplied by the tolerance of xi in percent, pct_tolxi. This expression is useful for comparisons between the overall sensitivities of implementations with different sets of component values.

Refer to Figure 2 which shows the spreadsheet LPF.xlsx used for the design and analysis of low pass filters. Many of its characteristics are identical to the ones used in the high and bandpass spreadsheets.

Figure 2 A screenshot of the low pass filter spreadsheet where the yellow values are entered by the user, the orange cells are filter component values automatically calculated by the spreadsheet, the bottom parameters are intermediate calculation required by the spreadsheet, and columns F and G contain the sensitivity values. There is also a graph which ignores _ρ and displays a wide range of possible component values from which the user may choose.

The yellow values in column C rows 5 through 14 are the only values entered by the user. These include the filter characterization parameters Q, Gain, and f0; as well as the ratio _ρ = C1/C2 (take note of the comment associated with cell C10); values for C1 and RG (reference designators for the components in the schematic seen in columns B through D and rows 26 through 37); and the percent tolerances of the resistors (r_tol) and the capacitors (c_tol) intended to be used in the filter.

The orange cells, columns B and C, rows 20 to 24, are filter component values calculated by the spreadsheet from these user entries. Columns C and D, rows 43 to 48 contain some of the intermediate calculations required by the spreadsheet.

Columns F and G contain the , , and sensitivities associated with each component x. Only those which have non-zero effects on the total sensitivity parameters SQ, SGain, and Sω0 (also shown in these columns) are listed. Notice that the equation for every parameter calculated by the spreadsheet appears to the right of the parameter value. There is also a graph which ignores _ρ and displays a wide range of possible component values from which the user may choose.

Now let’s take a look at the curves on the graph for parameters _ρ = _C1 /_C2 and sensitivities SQ and Sω0 which are parameterized by _r = _R2/(1/_R1a + 1/_R1b) for values from .01 to 100. These depend only on Q, Gain, and _r. all these are dimensionless.

The _ρ curve shows that for this particular filter, there are no solutions for values less than 4·Q2 = 4. (If you had entered such a value for _ρ, Excel would return the #NUM! error for many spreadsheet calculations.) The curve for Sensitivity of Gain, SGain, can’t be shown on a logarithmic scale—cell G25 shows it to be equal to zero. Why? The pass band (low frequency) Gain is 1, RF is zero, R1b is infinite (the spreadsheet shows it to be ridiculously large), and no passive components have any effect on Gain. (In a physical filter, there is still a sensitivity to the unity gain-configured op amp’s gain, which is actually less than unity due to its finite gain bandwidth product. Hence one of the reasons to simulate filter designs with the intended op amp.) Interestingly, the component sensitivities to Sω0 are independent of Q, _r, _ρ, and Gain for gains greater than or equal to unity, being dependent on tolerances r_tol and c_tol only. If Gain is unity, the only overall sensitivity that can be influenced is SQ, which is minimized in this case for _ρ = 4·Q2 = 4.

When 12.0E-9 is entered for _C1, the expression = 12/2.7 ≈ 4.44 for _ρ is close to 4 to allow the use of standard value capacitors. It will be seen that for low and high pass filters, the least sensitive choice is for a Gain of unity. Figure 3 shows what happens when the Gain requirement is increased by even a small amount to 1.5.

Figure 3 The low pass filter design of Figure 2 with the Gain parameter increased from 1 to 1.5.

Sω0 is unchanged as expected, but the best SQ has now more than doubled and SGain has made a showing, although it’s not much of a concern. The only good news is that _ρ = _C1/_C2 could be reduced to 2.2/1 and _C1 to 2.2E-9 (not shown in Figure 3) with no significant effect on SQ. A significant increase in Gain is definitely not recommended, as it causes a large jump in SQ, as can be seen in Figure 4.

Figure 4 Low Pass Filter screenshot with Gain jumping from from a value of 1 to 5, resulting in a large jump in SQ.

Such large gain values increase the best obtainable value of SQ by a factor of 6 in comparison to the Figure 3 design. The problem is compounded for higher values of Q and for component tolerances greater than 1%.

It’s no surprise that the best results will be obtained with the lowest tolerance passive components. There is little that can be done to influence the value of Sω0 which is constant for Gain values greater than or equal to unity, and which falls by small amounts only for smaller gains. Fortunately, its value is relatively small. For given values of Q and f0, the least sensitive low pass filter designs overall have a Gain of unity. For such a case, SGain is zero and SQ is at its minimum. Gains of unity or less leave SQ  unchanged, but can cause SGain to rise a small amount above the very stable Sω0. The real problem comes with Gain values greater than unity: Even slightly higher values cause SQ to increase significantly and overwhelm the contributions of SGain and Sω0, but they will reduce the minimum usable value of _ρ, which may be an acceptable tradeoff against increased SQ for some high Q cases. Generally, though, it’s wise to avoid Gain values much greater than unity, you can verify that the commonly recommended case of Gain = 2 to allow _ρ = 1 for equal capacitor values can produce a horrendous increase in SQ.

Other than a few differences related to interchanging the treatments of R1 and R2 with those of C1 and C2, high pass filter design and the high pass filter design spreadsheet shown in Figure 5 are much like those for the low pass filter. The biggest differences are first, that parameterization of the graph’s curves is by _ρ = _C1/_C2 (assuming values from .01 to 100) rather than by _r = _R2/_R1. For the low pass, any value of _r produces a realizable result, while this is true for _ρ for the high pass. Second, there is no C1b/C1a voltage divider corresponding to the low pass filter’s R1b/R1a—there is only _C1. The introduction of a capacitive voltage divider would require a prior stage to drive a capacitive load, courting oscillation. And so, although the high pass filter cannot support Gain values less than unity, the high and low pass designs show significant similarities. A comparison between Figure 4 and Figure 5 graphs, which employ the same Q, Gain, and f0, show virtually identical results (with _ρ and _r switched).

Figure 5 High Pass Filter screenshot with the same Q, Gain, and f0 requirements as those of Figure 4.

The comments found in the “Low pass filter design summary” section apply here too, except that there is no option for Gain values less than unity.

Although the least sensitive topology for component tolerances in high and low pass filters is the Sallen-Key, for the bandpass it’s the Delyannis-Friend (aka the multiple feedback configuration). A screenshot of the bandpass filter spreadsheet can be seen in Figure 6.

User data entry with the bandpass is much like that for the low and high pass cases, except that there is no _RG (and therefore no _RF). Once again, please be aware of the comments in the notes in columns D and E. If the background of cell C6 (filter Gain at resonance) is red, there are no realizable filters, calculations in columns C through G should be ignored, and the graph will be blank.

In some cases, the cell C6 background color will be the normal white, but filters will be realizable for certain smaller values of _ρ only, and the graph’s curves will be displayed accordingly. The curves might be absent, or partially or fully present, regardless of the value of _ρ in cell C10. But if C10’s background color is red, the _ρ-dependent calculations in columns C through G should be ignored. Figure 6 is an example where the filter Gain at resonance is close enough to the maximum possible value of 2·Q2 to render high values of _ρ (greater than 30) unrealizable.

Figure 6 A bandpass filter screenshot where user entry data (yellow) is similar to the low and high pass filter excel sheets.

It’s surprising that the passive sensitivity curves can be shown to be almost completely independent of the user-specified filter Gain at resonance. This is because for a given Q and f0, the filter Gain is set by the ratio of R1a to R1b. The parallel combination of these components is independent of filter Gain, and the remainder of the filter sees no difference in other than signal level. (Designers should be aware that the op amp can easily clip at or near resonance with too high a gain.) Surprisingly, sensitivities are independent of Q. However, the higher the Q, the higher the op amp open loop gain must be to provide enough margin to accurately implement the required op amp closed loop gain. Simulation of the filter design using the op amp intended for it, or one with similar gain characteristics, is strongly recommended.

Looking at the sensitivity curves only, it could be concluded that the best choice would be for a _ρ of 1 or less. _ρ = 1 has the advantage of the smallest ratio _r = R2 / (R1a || R1b). But consider the Gain of op amp at resonance: Less gain is required at higher values of _ρ, putting less of a burden on op amp open loop gain requirements to provide enough margin to meet the closed loop gain requirement.

Higher values of _ρ increase the overriding SGain by only a small amount. Clearly, there is a rather large disadvantage to values of _ρ less than unity when the demand on op amp closed loop gain is considered. Perhaps the best choice is _ρ = 1. The matched capacitors can be any standard value, SGain is near its smallest value, _r is at its smallest value, and there is only a modest increase in the op amp closed loop (and therefore open loop) gain requirement.

This article and its attendant spreadsheets provide an understanding of the sensitivities of pass band gains, Q’s, and resonance frequencies to the nearly infinite combinations of passive components that can make up low, band, and high pass, single op amp filters. The ability to implement designs using capacitors of readily available values is provided. It is hoped that filter designers will find these to be a useful set of tools whose features are not found elsewhere.

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

Related Content

• A Sallen-Key low-pass filter design toolkit
• Optimizing a simple analog filter for any PWM
• Double up on and ease the filtering requirements for PWMs
• Toward better behaved Sallen-Key low pass filters
• Parsing PWM (DAC) performance: Part 1—Mitigating errors

References

1. Texas Instruments. WEBENCH® Filter Design Tool. https://webench.ti.com/filter-design-tool/design/8
2. Analog Devices. Analog Filter Wizard. https://tools.analog.com/en/filterwizard/
3. FilterLab Active Filter Designer. https://www.microchip.com/en-us/development-tool/filterlabdesignsoftware
4. Zumbahlen, Hank. “Chapter 8: Analog Filters.” Linear Circuit Design Handbook. Elsevier, 2008, https://www.analog.com/en/resources/technical-books/linear-circuit-design-handbook.html.
5. Williams, Arthur Bernard. Analog Filter and Circuit Design Handbook. McGraw-Hill, 2014.
6. Jurišić, D., Moschytz, G. S., & Mijat, N. (2010). Low-Sensitivity Active-RC Allpole Filters Using Optimized Biquads. Automatika, 51(1), 55–70. https://doi.org/10.1080/00051144.2010.11828355

The post Component tolerance sensitivities of single op-amp filter sections appeared first on EDN.

Back at the beginning of last year, EDN published my dissection of a yellow-color ADATA UV128 16 GByte USB flash drive that for unknown reasons had died on me:

At the time, I also showed you its blue-tint 8 GByte sibling:

which, again at the time, I noted was still working. Well, it’s still working…at least with Windows-based computers, that is. With MacOS, on the other hand, although it still shows up in System Information when inserted in a USB Type A system connector (either directly or via a USB-C translation adapter intermediary):

it doesn’t “mount” in either Finder or Disk Utility, no matter how I have it formatted (FAT32 or exFAT). This has me wishing that I still had the remnants of last year’s yellow 16 GByte ADATA drive in hand, too, because I now wonder if the same O/S fickleness had applied to it!

Nevertheless, I thought I’d take this one apart, too, to see if there’s any obvious reason why it’s (O/S-selectively) no longer working. I’ll as usual begin with some overview shots, accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes (the UV128 has dimensions of 2.3” x 0.8 x 0.4”/60 x 20 x 9mm and a weight of 0.4oz/10g):

Regarding the prior images’ sometimes-visible USB connector, note that while ADATA’s website is quick to trumpet the product’s USB 3.x interface capabilities:

USB 3.2 High-Speed Transmission Interface

Now there is no reason to shy away from the higher cost of the USB 3.2 Gen 1 interface. The UV128 USB flash drive brings the convenience and speed of premium USB drives to budget-minded consumers.

Only read performance (“Up to 100 MB/s”) is specified. Initially, post-teardown, I was planning on just writing the following:

“Suffice it to say that, at least from my anecdotal (i.e., non-analytical) experience, although the interface transfer rate may have been 5 Gbps peak, the media transfer rate seemingly wasn’t, at least for writes.”

However, I then remembered that I had a copy of Blackmagic Disk Speed Test on my Windows system (for which, remember, the USB flash drive was—at least pre-teardown—still recognized). On a hunch, I plugged the bare PCB into the computer…the USB flash drive still worked!

Here are the benchmark results:

Like I said, the media transfer rate isn’t 5 Gbps (or even close to it), especially for writes and even for reads.

Then there’s this:

Starting from January 1, 2019, the warranty period for the UV128 is changed to 5 years; For UV128s purchased before (inclusive) December 31, 2018, the warranty period remains unchanged.

What exactly was the warranty period prior to January 1, 2019? Who knows. I’d bought three of these devices from Newegg in mid-July 2016 promo-priced at $3 each (the 16 GByte siblings were purchased from the same retailer 11 months later via a $5.33-per promotion).

Onward. Let’s get the two halves of the case apart:

As was the case last time, the internal assembly then popped right out of the remaining case top half:

A bit more blue plastic left to remove:

The now-revealed pad- and passive-dominant PCB topside (with orientation relative to where the slider “button” is located on the flash drive’s case):

is unsurprisingly reminiscent of the one seen earlier in its 16 GByte sibling:

As for the bottom side of this 8 GByte drive:

in comparison to the earlier 16 GByte counterpart:

I’m once again unable to identify the manufacturer and product details of the flash memory used in the design, which has the following markings:

60074882
5301486066

However, I can ID the media controller, which is different than the one we saw last time. The 16 GByte USB flash drive had used Silicon Motion’s SM3267. This time, conversely, it’s the IS917 from Innostor Technology. My Google research on the IS917 reveals one possible root cause for its incompatibility with MacOS, within an Amazon review titled “WARNING be very careful on non-Windows devices” which details multiple examples of unrecoverable media errors resulting from reformat attempts on both MacOS and Linux. Unfortunately, the flash memory storage device associated with this review no longer exists on Amazon, so I can’t tell if it was the UV128 (or another ADATA product, for that matter) or something from a different manufacturer.

Since USB Mass Storage specifications are standardized nowadays, I struggle to understand how there could be such significant variances from one operating system’s implementation of those specifications to another’s. On the other hand, given that this USB flash drive, and therefore the controller inside it, dates from around a decade ago (here’s an IS917 spec sheet with a 2013 copyright, for example), perhaps there’s a never-fixed firmware or silicon bug in the IS917 that non-Windows operating systems expose (there’s no firmware update available for download on ADATA’s support site), in spite of the product’s claimed longstanding, extensive O/S support?

Windows Vista, 7, 8, 8.1, 10, 11, Mac OS X 10.6 or later, Linux kernel 2.6 or later, with no device driver needed

Reader ideas are welcomed in the comments!

—Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.

 Related Content

• A deep dive inside a USB flash drive
• Memory cards: Specifications and (more) deceptions
• USB activation dongles: Counterfeit woes
• Fundamentals of solid-state memory technologies in consumer electronics – Part 4: Flash memory format specifications and characteristics

The post An O/S-fussy USB flash drive appeared first on EDN.