It seems like every day I’m delighted and enthralled by some new use of AI that makes me exclaim, “No! What? Wow!” For example, I was recently introduced to the world’s first AI electric screwdriver.

The full title of this Kickstarter project is The World’s First AI Electric Screwdriver with Eyes and a Brain. At the time of this writing, they’ve already got $204,000+ pledged against their original $11,500 goal, and they still have 29 days to go.

I don’t know about you, but even though I’ve got multiple screwdriver kits, when I’m working on a project, I invariably spend an inordinate amount of time (a) deciding which type of bit to use and then (b) working out the correct size of that bit.

This AI screwdriver addresses both these issues. You start by pointing the base of the screwdriver, which is equipped with an HD camera, at the head of the screw in question, and the AI identifies the type and size of the bit you require.

The screwdriver is wirelessly connected to its associated smart case. An OLED (organic light-emitting diode) display in the case shows a close-up of the screw in question. Each of the bits in the case has an associated LED that lights up to show you exactly which one to grab.

But wait, there’s more, because this is an electric screwdriver (although you can still turn it by hand if you want to go “old school”). One problem with electric screwdrivers is that it’s easy to apply too much torque and strip the head of the screw you’re working on, which can result in much gnashing of teeth and rending of garb, let me tell you. Well, this bodacious beauty is equipped with something called Auto Torque Assist, which is enabled by default and matches the torque applied to the screw that’s been identified.

Oh my goodness gracious me. I really want one of these. When I think of the countless hours I’ve spent dorking around trying to decide which bit I want to use, and then working out which slot in my kit I mistakenly left that bit in, well… all I can say is that I’m drooling with desire. It’s not a pretty sight. I’m not proud. But we digress…

Speaking of AI making our lives easier, I was just chatting with Oliver Tan and Balaji Natarajan, both of whom are Product Marketing Directors at Lattice Semiconductor. Poor old Oliver and Balaji had been tasked with bringing me up to speed on Lattice Prompt, including the latest and greatest enhancements arriving in version 1.1.

“What’s Lattice Prompt?” I hear you cry. I’m glad you asked; otherwise, I would have had to come up with some cunning way to introduce this little rascal into the conversation.

As we* all know, designing an FPGA-based system can be a time-consuming hobby (*by “we” I mean people who design FPGAs; those who pursue less stressful careers, like herding cats, probably remain blissfully unaware of the problems involved).

Even after you’ve written your RTL (register-transfer level) code in Verilog, SystemVerilog, or VHDL, you still need to contend with synthesis, placement, routing, timing analysis, simulation, and generating the configuration bitstream. And that’s assuming everything works the first time (excuse me while I laugh hysterically).

This is where Lattice Prompt leaps onto center stage with a ballyhoo of bassoons. Instead of manually navigating development tools, configuring projects, running commands, and interpreting reports, Lattice Prompt lets designers describe what they want to accomplish in everyday language. An AI assistant can then help translate their intentions into appropriate operations, invoke Lattice’s development tools, examine the results, and guide the next steps.

Lattice claims productivity improvements of 10 times or more for certain tasks. That’s a bold statement, but—as we’ll see shortly—the company has some interesting examples to back it up.

One thing that piqued my interest is that Lattice Prompt doesn’t come equipped with its own large language model (LLM). This is deliberate. Rather than insisting that engineers abandon their existing AI tools and adopt an entirely new environment, Lattice has chosen to work with compatible tools they may already be using, such as Claude Code and Cursor, along with their preferred LLMs. In effect, Lattice is saying, “You bring the AI, and we’ll bring the FPGA expertise.”

The secret squirrel sauce includes the Model Context Protocol (MCP), an open standard that allows AI applications to communicate with external tools, along with something called Skills, which provide instructions and specialized knowledge. Lattice Prompt uses these mechanisms to connect the designer’s AI agent to Lattice’s FPGA development tools, device information, IP catalogs, reference designs, and engineering expertise. It also provides deterministic validators to check results against design rules and constraints.

The important distinction is that the AI agent provides the reasoning and makes design decisions, while Lattice Prompt supplies the specialist knowledge and mechanisms needed to implement those decisions.

Lattice Prompt: Design in natural language (Source: Lattice)

The original Lattice Prompt 1.0, released in September 2026, focused on automating Lattice Radiant, the company’s FPGA design software. This included synthesis, placement, routing, timing analysis, simulation, and bitstream generation.

Version 1.1, released on 30 October 2026, adds design consultant capabilities, including SoC construction using Lattice Propel, RISC-V firmware development, timing closure, RTL simulation, and hardware debugging using Lattice Reveal.

Propel is particularly interesting because many FPGA designs incorporate embedded processors. Lattice supports four principal, customizable RISC-V soft-core variants: Nano, for simple control and monitoring; SM, for small bare-metal systems; MC, for more capable microcontroller applications; and RX, for higher-performance applications, including those requiring real-time operating systems.

With Lattice Prompt 1.1, designers can use natural-language requests to help assemble processor-based systems, configure IP blocks and peripherals, and develop associated firmware, including drivers and linker scripts.

Behind the scenes, Lattice Prompt 1.1 employs two MCP servers. The Lattice Prompt Server provides design knowledge, validation, and execution capabilities, including Propel integration. The Lattice Radiant MCP Server handles the Radiant implementation flow, including timing analysis and closure. The AI agent invokes the appropriate server for the task, while the designer continues working with their preferred AI assistant, blissfully unaware of any behind-the-scenes shenanigans.

Lattice Prompt 1.1: Two servers, one flow (Source: Lattice)

Another important point is that Lattice says design files, build logs, and license settings don’t leave the user’s machine through Lattice Prompt (users must still consider the data-handling arrangements of their chosen AI tools).

All of this sounds wonderful (everything does if you talk quickly and gesticulate furiously), but what can Lattice Prompt actually accomplish in the real world? Well, “the proof of the pudding is in the eating,” as the old saying goes. Oliver and Balaji shared three examples that speak for themselves.

The first involves industrial automation. Imagine designing a motion-control system in which motors, sensors, and actuators must exchange information with predictable timing. This is where Time-Sensitive Networking (TSN), a collection of Ethernet enhancements that support deterministic communication, comes in.

Lattice illustrates its approach using the following natural-language request: “Give me a TSN Ethernet endpoint for a motion-control drive, deterministic and low power.” The AI agent can use Lattice Prompt to identify relevant device information and IP, invoke development tools, and work towards a solution comprising an FPGA configuration bitstream, timing and simulation results, and documentation.

The second example involves optical coherence tomography (OCT), an imaging technique that uses reflected light to generate detailed cross-sectional images of materials and biological tissues. In this case, Lattice’s engineers started with OCT reconstruction code written in NVIDIA’s CUDA parallel computing environment. Their objective was to port this code to a Lattice Avant FPGA.

The request was simply: “Port this CUDA OCT reconstruction code to my Lattice Avant FPGA.” The resulting process involved creating a Python implementation verified against the original CUDA code, generating RTL verified against the Python version, and implementing the design on the FPGA.

The resulting FPGA design ran at a clock frequency of 200 MHz. Interestingly, the engineering team reportedly had no previous experience with CUDA or OCT, although they did perform verification as part of the exercise. According to Lattice, the entire process took about 30 hours, compared with the months of development that would have been required using conventional techniques.

The third example concerns something painfully familiar to FPGA designers: timing closure. The design in question was Relay-BP, a decoder associated with quantum error correction. The target was 200 MHz on a Lattice Avant FPGA, but the initial implementation was achieving only 98 MHz (give or take).

The designer’s request was refreshingly straightforward: “Fix the timing on my Relay-BP decoder. It’s failing 200 MHz by 5 ns on Lattice Avant.” Using Lattice Prompt, the AI-assisted flow helped identify the causes of the timing violations and guide implementation changes, reducing the number of iterations required.

The result? Timing closure at 200 MHz, with 0.075 ns of positive slack at 85°C, zero hold-time errors, and passing simulations. And the time required? Just four hours, compared with an estimated effort of days using conventional techniques. For anyone who’s spent countless hours staring at timing reports, trying to work out why a supposedly simple change has made everything worse, that’s the sort of result that makes you sit up and take notice.

If all this has whetted your appetite, Lattice Prompt 1.1 is available as a free download, complete with a one-command installer and user guide.

Of course, we’re still in the early days of AI-assisted electronic design, and there’s plenty of room for further development, particularly when it comes to independent verification and hardware debugging. It’s easy to imagine a not-so-distant future in which one AI agent generates a design, another independently verifies it, and yet more agents compile, program, test, and debug the resulting hardware. We certainly do live in interesting times.

In her journey to create the field of software engineering, Margaret Heafield Hamilton programmed many of the most historic early electronic computers including the Librascope/Royal McBee LGP-30, Digital Equipment Corp’s PDP-1, IBM’s XD-1 for the SAGE (Semi Automatic Ground Environment) air defense network, and the Apollo Guidance Computer (AGC). She didn’t set out to be a software programmer. Instead, she was drawn to mathematics starting in high school. However, an early job with mathematician Edward Lawrence at MIT paired her with the LGP-30 for modeling weather patterns and weather prediction. Once she’d been exposed to computer programming, her path was firmly set for the next several decades. President Obama presented Hamilton with the Presidential Medal of Freedom in 2016 for her pioneering software development that took the Apollo astronauts to the moon, and Lego featured Hamilton as a minifig (miniature figurine) in its “Women of NASA” Lego set in 2017. She passed away on September 30, 2026.

Lego honored Margaret Hamilton in the “Women of NASA” Lego set in 2017. She appears on the box in the upper left position, standing with a stack of printouts for the Apollo Guidance Computer (AGC), replicating a famous photo taken of Hamilton during her days on the Apollo program. Image credit: MIT Museum

Hamilton was born in the small town of Paoli, Indiana. She grew up and lived in many other small towns throughout the United States’ Midwest. Her parents were teachers and moved frequently. She spent her high school years living in Michigan’s Upper Peninsula and found that she especially liked math. After high school, Hamilton attended the University of Michigan, but only for one semester. She found the school too large, which clashed from her small-town experiences, so she transferred to Earlham College in Richmond, Indiana. There, she fell in with Elizabeth Long, head of the math department, and decided to follow in Long’s footsteps by becoming a math teacher. She earned a BA in math with a minor in philosophy in 1958 and planned to get a graduate degree at Brandeis University in Waltham, Massachusetts. However, she also married James Cox Hamilton in 1958. He needed another year before he could graduate from Earlham, so she spent a year teaching math and French in the small town of Boston, Indiana while he completed his undergraduate degree. After her husband graduated, the couple needed to make a choice. Both wanted to earn PhDs, but they also needed immediate income for living expenses. Both volunteered to postpone their graduate studies but, in the end, Margaret continued to work while James went to Brandeis and earned a master’s degree in chemistry. He then switched to Harvard and earned a law degree.

Meanwhile, Margaret worked to support her family, and her next job set the course of her career. She became a software programmer for Edward Lorenz, the MIT mathematician who was working on weather modeling and weather prediction. This early work eventually led to Lorenz’s development of “strange attractors,” the mathematical concept that was the precursor to chaos theory. Lorenz had a Librascope LGP-30, the world’s first desk-sized personal computer, which he used to help compute weather simulations. Hamilton had never seen a computer, so Lorenz taught her how to program the LGP-30. She quickly learned the ins and outs of programming the LGP-30, including directly editing the programs stored on paper tape by punching holes in the tape with the point of a pencil and covering up other holes with tape to change ones into zeroes and vice versa. She did this rather than spend the time to punch another tape on the computer’s Flexowriter, a computer-driven typewriter and paper tape reader and punch. Hamilton also started programming Digital Equipment’s first minicomputer, the PDP-1, as part of her work with Lorenz.

By 1961, the Hamiltons had a child and needed more money than Margaret was making as Lorenz’s assistant, so she applied for a programming job at Lincoln Laboratories, which was developing software for the SAGE air defense system. SAGE was planned as a giant system including a large fault-tolerant computer, one hundred graphic display terminals, and associated early networking equipment that would be used to process data from multiple radar sites spread across the continent to provide a unified image of the Western hemisphere’s airspace. That information would be used for directing the US response to a possible Soviet air attack. Lincoln Labs was hiring every experienced programmer that it could find for the project, but an interviewer told Hamilton over the phone: “We’re really interested in having an interview [with you], but please forgive me, I’ve only interviewed men and I do interviews in my hotel room. I can’t do that with you because you’re a girl. Would it be okay if we had an interview at the bar in the hotel?” Hamilton laughed, agreed to the interview, and had a drink with the interviewer. She got the job.

SAGE was based on IBM’s XD-1, a fault-tolerant, real-time computer that used MIT’s unfinished Whirlwind II design, a follow-on to the successful Whirlwind project. The immense machine used 49,000 vacuum tubes, consumed 3 megawatts of electricity, and weighed 250 tons. Hamilton could not leave her child for the required eight weeks of training, so she taught herself to program the XD-1 while the rest of the programmers were attending the training class out of town.

The SAGE air defense system became fully operational in 1963, and Hamilton left the project that same year. She subsequently learned about a new project starting at MIT’s Instrumentation Laboratory (later renamed Draper Laboratory) involving software development for the Apollo Moon program. The idea intrigued Hamilton, who had long been a fan of science fiction. She applied for a position and nabbed a spot on the flight software team, which was developing guidance, navigation, and control software for the Apollo Command Module (CM) and the Moon lander, called the Lunar Module (LM). 

This work involved multi-tasking, real-time software with priority scheduling and asynchronous interrupts. It was groundbreaking software that had to run on the Apollo Guidance Computer (AGC), which was designed to meet severe weight, size, and power restrictions. Embedded programmers of today still fight with memory, bandwidth and latency just like the AGC programmers did in the 1960s. Their lessons are our lessons.

Margaret Hamilton poses inside a mockup of the Apollo Command Module. Image credit: MIT Museum

During the Apollo program, Hamilton coined the term “software engineering” in an attempt to lift software programmers from their second-class status. In her oral history, she states:

“Okay, you know when the guys [hardware and aeronautical engineers] used to throw the stuff over the wall? It was something [that occurred] at Draper Instrumentation Labs, right? And there’s the engineers, hardware engineers. There were aeronautical engineers, just engineer engineers. But we were the programmers, and we were kind of like second-class citizens. I mean, you know, we’d take the stuff and we’d ‘make it run,’ right? And so, in doing the simulations, especially when we were simulating everything, I kept noticing patterns between the different kinds of engineering that were very similar, because when we simulated the software or the hardware, we still had decisions to make. We had things going that were– interrupts that had to be done.

“The commonality in the designs, it’s like ‘Was the software this design or was it hardware?’ They looked alike in the simulation. But also, I noticed there were things that they didn’t do, like the systems software stuff. They didn’t worry about who interrupted who. They worried about their stuff working and getting the right results. So, when we would say, ‘Well, wait a minute. Which is this module? Is this hardware or software?’ I said, ‘Why don’t we call this one the hardware engineering part and this the software engineering part?’ It was like I just came up with a term to say let’s name this part in this whole system definition. So, anyway, the engineers thought it was funny. ‘There’s Margaret again with her software engineering.’”

One person who didn’t find Hamilton’s “software engineering” ideas funny was David Garratt Hoag, the Director of the Apollo program’s primary CM and LM guidance, navigation, and control systems development. According to Hamilton’s oral history, Hoag said, “You know, Margaret’s right. This is engineering, what you people are doing, just as much as the stuff we’re doing,” meaning the hardware. Hoag said, “She’s trying to formalize it and I think it should become formalized.” And with those words spoken by the program director, software engineering was formally born at NASA. Eventually, Hamilton would be promoted to Director of the newly created Software Engineering Division.

Hamilton worked on the Apollo program’s flight software through all the crewed flights starting with Apollo 8. She was constantly aware of the pressure in creating “man-rated” software. If the software failed, the astronauts’ lives would be in danger. Someone might die. She put in many long hours to ensure that didn’t happen because of a software problem.

After the Apollo program wound down, morale was low because the team had little to do, so Hamilton refocused the team and led a project to collect and analyze the mistakes made during the flight software’s development. She wanted to classify those errors, to understand why they were made, and to develop methods for avoiding the mistakes in the future. She later left the program and, in 1976, Hamilton started a software company called Higher Order Software (HOS) with Saydean Zeldin, a colleague on the AGC project, to further develop the error-prevention and fault-tolerant concepts that emerged from their experiences with the Apollo program. Hamilton left HOS in 1985. In 1986, she founded another software company, Hamilton Technologies, and developed the Universal Systems Language (USL), a modeling language and formal method for specifying and designing complex systems.

Margaret Hamilton circa 1995. Image credit: Daphne Weld Nichols

Hamilton won multiple awards because of her software engineering legacy. In 1986, she received the Augusta Ada Lovelace Award from the Association for Women in Computing. In 2003, NASA awarded her the NASA Exceptional Space Act Award for scientific and technical contributions accompanied by a $37,200 prize, the largest award to an individual in the agency’s history. Earlham College gave her its Outstanding Alumni Award in 2009. In 2016, President Obama awarded her the Presidential Medal of Freedom, the highest civilian honor in the United States. She was elected as a Computer History Museum Fellow in 2017. Hamilton died on September 30, 2026, at the age of 90.

Reference

Oral History of Margaret Hamilton, Interviewed by David C. Brock on April 13, 2017, Computer History Museum.

Artificial intelligence is making its presence felt in just about every corner of electronic design, but there’s a world of difference between generating a circuit and creating one you can trust. What happens when the stakes are high, the designs are complex, and getting things wrong simply isn’t an option?

In my recent column, No Engineer Is an Island (The Butterfly Effect: Engineering Edition), I noted how none of us exists in isolation. We’re all connected to the people around us, influenced by their thoughts and actions, and dependent on one another in ways we may not even realize.

Well, it just struck me that today’s column is another manifestation of this effect. Back in the mists of time we used to call January 2024, my friend Adam Taylor, who is Founder, Director, and Principal Consultant at Adiuvo Engineering and Training, introduced me to Tomide Adesanmi, who is Co-Founder & CEO at Circuit Mind.

This introduction led me to write two columns: From Architecture to PCB Schematic in 60 Seconds! (February 2024) and From Power Supply Block Diagram to Completed Design in 60 Seconds! (March 2025).

As an aside, before we hurl ourselves deeper into the fray with gusto and abandon (and aplomb, of course), I just discovered that Tomide was selected for the 2020 Forbes 30 Under 30 annual recognition program, which celebrates rising stars in the form of young entrepreneurs, innovators, creators, and other high achievers who are making an impact in their respective fields.

I have to admit that this made me wonder why the folks at Forbes have never approached me for this honor, but Wikipedia informs me that Forbes didn’t launch its inaugural 30 Under 30 list until 2011, by which time my 30th birthday was already almost two and a half decades behind me in the rearview mirror of my life. (Maybe we should launch a campaign to persuade the editors at Forbes to start a new “People Who Should Have Been in Our 30 Under 30 List If Only We’d Had One at the Time” list.) But we digress…

I must admit that just a week or so ago I found myself thinking, “It’s about time I heard from Tomide about the latest and greatest happenings at Circuit Mind.” Only a day or two later, I received an email from him saying, “Can we have a call so I can bring you up to speed with the latest and greatest happenings at Circuit Mind?” What are the odds? “Great minds think alike,” as they say. Of course, they also say that “fools seldom differ,” but I’m sure that doesn’t apply here.

As you may recall from my earlier columns, when I first encountered Circuit Mind, its flagship product was ACE (Assistant to Circuit Engineers). This bodacious beauty lets engineers specify their requirements as a high-level block diagram and automatically generates a complete circuit schematic, bill of materials (BOM), and supporting analysis documents in minutes.

When we caught up again in March 2025, the folks at Circuit Mind had extended ACE’s capabilities to encompass power-supply design. Since then, they’ve continued to expand ACE’s repertoire to include increasingly sophisticated circuits involving system-on-chip (SoC) devices, complete with all the associated power supplies, power sequencing, and other electronic odds and ends.

But that’s only part of the story, because Circuit Mind is evolving from a company offering a single—albeit extremely capable—design automation tool into a provider of what Tomide calls an “electronic design intelligence platform.”

In this age of “AI Everything,” one thing that struck me about ACE when I first encountered it was the way it approached artificial intelligence. Rather than relying on a large language model (LLM) to dream up electronic circuits and hoping for the best, Circuit Mind used AI to extract information from component datasheets and convert it into structured, machine-readable models. The actual circuit generation used deterministic, physics-based, and mathematics-based algorithms.

This distinction is important. As we’ve all discovered (sometimes to our cost), LLMs can be astonishingly capable, but they can also confidently present incorrect information as fact. This phenomenon, commonly referred to as “hallucination,” may be amusing when you’re asking an AI to suggest a recipe for chocolate-chip cookies, but it becomes considerably less entertaining when you’re designing the electronics for a satellite, an industrial control system, or a product that’s destined to be manufactured in its millions.

When I asked Tomide whether Circuit Mind was still following its original approach, he explained that things had evolved: “In our platform now, we have some tools that use physics-based and math-based algorithms for some tasks, and then we have some other tools that use LLMs. But most of the tools use a combination of both in the right place.”

The key phrase here is “in the right place.” Circuit Mind isn’t wedded to deterministic algorithms to the exclusion of AI, nor is it jumping on the agentic AI bandwagon simply because everyone else seems to be doing so. Instead, the company chooses the technology, or combination of technologies, best suited to each task, with reliability as the overriding consideration.

This brings us to the first of the new announcements, which were unveiled yesterday (assuming you are reading this on Thursday, 29 October 2026; otherwise, you’ll have to work out the date difference for yourself): the launch of AVE (Agentic Verification Engine), a new application that complements ACE by automatically reviewing electronic circuit schematics.

Whereas ACE focuses on generating designs, AVE focuses on checking them. And, importantly, AVE isn’t limited to circuits generated by ACE. It can also examine schematics created manually using conventional electronic computer-aided design (ECAD) tools.

AVE employs multiple AI agents to scrutinize your design from different, distinct, and diverse perspectives. Some review the component datasheets and application notes, checking operating voltages, pin assignments, electrical constraints, and more. Others trace connections and communication buses, looking for inconsistencies and potential problems. Still others check the design against the company’s own engineering rules and review checklists.

Of course, there’s little point in replacing a tedious manual review process with an automated system that bombards engineers with hundreds of false alarms. To address this, AVE performs an additional quality-assurance pass, critically examining its own findings before presenting them to the engineer. It’s a case of “wheels within wheels,” with AI agents checking the work of other AI agents.

Tomide tells me AVE is already being used by customers and has identified real-world issues that previously escaped their conventional design reviews. That’s the sort of thing that makes engineers like your humble narrator (I pride myself on my humility) sit up and pay attention.

The illustration below shows how everything fits together. At the bottom we have the L1 data layer, comprising structured digital models of electronic components, along with each customer’s organizational information and existing engineering workflows. Above this sits the L2 intelligence layer, which combines deterministic algorithms with agentic AI. Finally, at the top is the L3 application layer, which includes ACE, AVE, and other tools.

One of these tools that’s worthy of special mention is Elixir, an AI-powered application that extracts information from component datasheets and generates structured, machine-readable component data and schematic symbols in accordance with an organization’s internal design guidelines.

Circuit Mind platform architecture (Source: Circuit Mind)

The important point is that these applications share the same underlying infrastructure and engineering knowledge. Circuit Mind isn’t simply bolting unrelated AI tools together and hoping they play nicely with each other.

Now we come to what I consider to be the most interesting aspect of this entire adventure. When I asked Tomide how Circuit Mind differentiates itself from the increasingly crowded field of AI-based electronic design companies, his response was refreshingly direct: “Circuit Mind is not currently focused on democratizing circuit design. Our goal is to be in the hands of professional electronics engineers in the largest companies in the world.”

That’s a good answer. There’s nothing wrong with democratizing electronic design, of course. I’m all for helping hobbyists, students, and makers turn their ideas into reality. But designing a circuit that flashes a few LEDs on your workbench is a different proposition from designing mission-critical and/or safety-critical electronics for an aircraft, a defense system, or an industrial installation where a malfunction could have serious consequences.

When failure is not an option and engineering excellence is essential (Source: Circuit Mind)

And there’s another dimension to this. Consider a consumer electronics manufacturer producing tens of millions of devices. The product may not be mission-critical or safety-critical per se, but a design error discovered after those devices have shipped worldwide could trigger an eye-wateringly expensive recall, not to mention damage to the company’s reputation.

As Tomide pointed out, software engineers can often discover and correct problems relatively quickly. Even after a product has been deployed, software bugs can frequently be fixed via over-the-air (OTA) updates or other software patches. With hardware, however, a mistake that slips through to the prototype stage may require a complete PCB respin, potentially adding weeks or months to the development schedule.

This explains why Circuit Mind’s primary markets include aerospace and defense, industrial electronics, and high-volume consumer hardware. These environments demand reliability, consistency, and engineering rigor.

None of this means that Circuit Mind can guarantee a flawless design, of course. Engineers must still perform the appropriate verification, validation, and testing. The objective is to reduce the likelihood of errors, identify problems earlier, and give engineers greater confidence in the designs they’re creating.

It’s interesting to note that multiple companies can start with the same design requirements and legitimately arrive at quite different designs. One organization may have a preferred components list, another may insist on parts from specific approved manufacturers, and a third may have its own established rules governing schematic symbols, net naming, and component selection.

As hard as it can be to believe sometimes, these requirements aren’t arbitrary annoyances dreamed up to make engineers’ lives difficult. They represent years of accumulated experience, established supply chains, manufacturing practices, and lessons learned the hard way. Circuit Mind’s platform can be configured to accommodate these company-specific requirements. It also integrates with established ECAD environments, including tools from Altium, Cadence, and Siemens, so engineers can keep working with their existing libraries, conventions, and workflows. The result isn’t simply a circuit that functions correctly. It’s a circuit that fits the way the customer’s organization actually works.

Some of the world’s largest companies are already using Circuit Mind’s technology. Many prefer to keep this under wraps because they regard their use of these tools as a competitive advantage. However, the company has publicly identified Emerson and Schneider Electric among its customers.

Circuit Mind also reports some impressive results. In a peer-reviewed case study, the space electronics team at Los Alamos National Laboratory reported completing a design task in four hours that had previously taken two weeks. Meanwhile, Schneider Electric says its early evaluations indicate the potential to reduce electronic architecture exploration effort by more than 90%. Naturally, these are specific examples rather than promises that every design will enjoy the same improvements, but they certainly give us something to think about.

I don’t usually spend much time discussing funding rounds and financial investments in these columns. My interests tend to lie more in technologies, the people behind them, and the clever things they’re doing. However, rules were made to be broken, and this is one of those occasions when I’m happy to make an exception.

Yesterday, Circuit Mind also announced $25 million in financing, including an $18.5 million Series A led by Norwest and a previously unannounced seed round. This brings the company’s total funding to $33.4 million. That’s a substantial vote of confidence from people who presumably know a thing or two about deciding where to put their money.

This funding will be used to expand Circuit Mind’s engineering, sales, and customer-support teams, establish a US headquarters, and extend the platform’s capabilities across additional stages of the electronic design lifecycle.

Tomide says the company currently employs 32 people and plans to at least double that number before the end of next year. They’re looking for electronic engineers, software engineers, mathematicians, AI specialists, and people with sales and marketing experience in the electronics industry.

Looking further ahead, the guys and gals at Circuit Mind envisage extending their platform beyond circuit generation and schematic verification to encompass additional capabilities such as design analysis, reporting, testing, and (potentially) firmware development. For now, PCB placement and routing remain outside the platform’s capabilities, although Tomide acknowledges they may consider it in the future.

In an age when everyone is rushing around sprinkling “AI fairy dust” over everything in sight (you simply cannot get it off the furnishings or out of the carpet), I like the fact that Circuit Mind’s philosophy doesn’t assume AI should replace electronic engineers (I’m too young to be replaced). Instead, it starts with the premise that experienced engineers possess invaluable knowledge and expertise (We do! We do!) and asks how AI, deterministic algorithms, and structured engineering data can help them accomplish more in less time.

I’m looking forward to seeing where Tomide and his colleagues take things next. If their progress over the past couple of years is anything to go by, I envisage great things to come. And who knows? Perhaps by the time we next catch up, I’ll have persuaded Forbes to launch that long-overdue list for those of us whose 30th birthdays have long since vanished beyond the event horizon.

The concept of analog artificial intelligence (AI) implemented using flash memory as the core compute element first impinged itself on my consciousness way back in the mists of time that we used to call the early 2020s (which is effectively a bygone era, the way things are racing along these days).

To be honest, I’d largely forgotten about this technology until I saw a recent press release proudly proclaiming: AnalogAI Selects memBrain SAGE Intellectual Property from Silicon Storage Technology for its First Real-world Edge AI Processors.

I’m not sure why, but this prompted me to ask myself a slew of questions, including: “Who is AnalogAI?” and “What is memBrain SAGE IP?” and “Who is Silicon Storage Technology?” I’m sure I knew the answers to all these questions once upon a time, but there’s so much going on these days that I consider myself winning if I can keep my nose above the waterline in the sea of technological information constantly washing over me.

In a crunchy nutshell (and in a desperate attempt to stem the rising tide of names and acronyms), Microchip Technology is a major semiconductor company whose products include microcontrollers, microprocessors, memory devices, and a host of other electronic components. One of Microchip’s subsidiaries, Silicon Storage Technology (SST), specializes in flash memory technology and related intellectual property (IP).

The lads and lasses at SST have developed a cunning piece of neuromorphic hardware IP called memBrain SAGE (Synaptic Analog Generative Engine). Designers can incorporate memBrain SAGE IP into their application-specific integrated circuit (ASIC) and System-on-Chip (SoC) designs. Developed for an analog compute-in-memory (aCIM) architecture, this technology performs AI computations directly in memory rather than constantly shuttling data back and forth between memory and a processor.

Enter the guys and gals at AnalogAI, who are using memBrain SAGE IP to power a new generation of ultra-low-power edge AI processors that can learn and adapt on the fly. Think robots, drones, and vehicles that can perform AI inference while adapting to changing physical environments in real time, without relying on the cloud.

Meet the players (Source: Microchip)

Before we plunge deeper into the fray with gusto and abandon, let’s briefly acquaint ourselves with memBrain IP to ensure we’re all tap-dancing to the same skirl of the bagpipes. Happily, I had a chat with David Eggleston, Associate Director, Business Development at Microchip Licensing Division, who kindly took the time to walk me through the technological intricacies.

The Magic of Multiplying in Memory

As David explained, the key to understanding memBrain is to start with a multiply-accumulate (MAC) operation. This is one of the fundamental building blocks of AI, particularly neural networks, which spend an inordinate amount of their time multiplying numbers and adding the results.

In conventional digital implementations, such as the graphics processing units (GPUs) commonly used to accelerate AI applications, MAC operations are performed by dedicated arithmetic circuitry. The processor retrieves the required values from memory, multiplies them, adds the results to a running total, and repeats the process over and over (and over) again. Modern GPUs can perform enormous numbers of these operations in parallel, but there’s a catch: moving all those values back and forth between memory and the processing elements consumes significant amounts of time and energy.

Digital vs. analog MACs (Source: Microchip)

Rather than storing neural-network weights in memory and transporting them to separate arithmetic circuits, memBrain uses the memory cells themselves to perform the computations. The underlying technology is SST’s embedded SuperFlash memory, but instead of using its cells simply to store binary ones and zeros, memBrain programs them to represent different analog values.

As David explained, each flash memory cell can represent one of 32 distinct levels, corresponding to five bits of information. These levels can be expressed in terms of electrical conductance, which is essentially the inverse of resistance. If we apply a voltage to a conductance, the resulting current is proportional to the product of the two. This means we’ve just performed a multiplication using the underlying physics of the memory cell itself.

Now comes the cunning part. By arranging these cells in an array and applying input voltages to multiple rows simultaneously, the resulting currents naturally add together along the columns. This gives us the accumulation part of our multiply-accumulate operation. Instead of performing a succession of individual digital calculations, memBrain can execute multiple MAC operations in parallel, directly within the memory array.

Of course, there’s more to memBrain than a clever arrangement of memory cells. The chaps and chapesses at SST provide it as a comprehensive intellectual property (IP) solution that semiconductor designers can incorporate into their own ASICs and SoCs. In addition to the SuperFlash memory arrays, the memBrain package includes analog control circuitry, digital-to-analog converters (DACs), analog-to-digital converters (ADCs), simulation models, test programs, and software tools to prepare and load neural-network models.

Another interesting aspect is that memBrain doesn’t require some exotic new semiconductor manufacturing process. SST has developed the technology using established 40nm and 28nm foundry processes, which helps keep manufacturing costs under control.

But perhaps the most impressive trick is how little power the technology requires. David told me that, whereas a conventional flash memory cell might operate with a read current of 10 microamps or more, memBrain operates its cells with currents ranging from just 1 to 100 nanoamps. This involves operating the transistors in what’s known as their subthreshold region, which requires considerable expertise to achieve reliably.

The result is an architecture that can perform substantial amounts of AI computation while consuming a fraction of the energy required by more conventional approaches. To put some numbers on this, David shared an example comparing an aCIM implementation with a GPU-based system running a YOLOv5 neural network for video-based threat detection.

aCIM vs GPU performance (Source: Microchip)

As we can see, the GPU-based implementation processes 200 frames per second while consuming 60 watts. The aCIM implementation processes a slightly more modest 150 frames per second, but it does so while consuming just 3 watts. That translates to 50 frames per second per watt for the aCIM solution, compared with approximately 3.33 for the GPU. In other words, according to SST’s figures, the aCIM implementation delivers around 15 times the energy efficiency in this particular comparison. SST’s figures also suggest a substantial reduction in silicon die cost, making the proposition even more attractive for cost-sensitive applications.

Now, I’m not suggesting that analog compute-in-memory is about to replace GPUs in every application. Far from it. GPUs remain extraordinarily capable, particularly for large, complex AI models and workloads that require flexibility and high computational throughput. However, in edge AI applications, where every milliwatt matters, the ability to run sophisticated neural-network computations without constantly ferrying data between memory and processing circuitry is a big deal. And that brings us neatly back to AnalogAI, because this company is taking SST’s memBrain technology and adding another intriguing twist to the tale.

AI That Learns on the Job

As we’ve just discussed, SST’s memBrain technology offers an intriguing way to perform AI inference while consuming remarkably little power. But what if we wanted our AI systems to do more than simply execute neural networks that were trained elsewhere? What if we wanted them to adapt to changing circumstances after they’d been deployed in the field?

I’m glad you asked. This is where AnalogAI, a South Korean company specializing in edge AI processors, ambles into the picture. Traditionally, AI models are trained using powerful computing systems, after which the resulting models are deployed on edge devices to perform inference. This works wonderfully well until the real world starts throwing unexpected situations into the mix. Consider an autonomous robot navigating an unfamiliar environment, for example, or a drone attempting to operate under changing weather and lighting conditions.

Rather than relying exclusively on a fixed model, AnalogAI is developing processors that combine SST’s memBrain SAGE IP with the company’s own proprietary, hardware-aware algorithms. The goal is to let these devices perform inference while adapting to changing real-world conditions, without continually consulting a remote server. And here’s the really exciting part: AnalogAI is targeting all of this at a power consumption of one watt or less.

Of course, the potential applications extend well beyond our hypothetical robot and drone. We’re talking about autonomous vehicles, industrial machines, and other intelligent systems that must make decisions locally, often under tight power constraints and without guaranteed access to the cloud.

It’s early days for AnalogAI’s processors, but the combination of ultra-low-power analog computation and on-device adaptation is certainly an intriguing prospect. And, as it turns out, AnalogAI is far from being the only company to recognize the possibilities offered by SST’s technology.

It Takes an Ecosystem

One thing David was particularly keen to emphasize is that SST’s memBrain technology isn’t a one-company, one-product, one-size-fits-all proposition. Rather, it’s the foundation of a growing ecosystem of semiconductor companies, each licensing the underlying IP and using it to develop processors targeting different applications. In fact, AnalogAI is SST’s fourth publicly announced memBrain licensee, and David says others are waiting in the wings.

The first of these collaborations came in February 2022, when a Chinese semiconductor company called Witmem (or WITINMEM in Microchip’s original announcement) adopted SST’s technology for low-power speech processing. This was followed in September 2023 by Intelligent Hardware Korea, which is developing analog compute platforms for edge AI applications, particularly computer vision.

In October 2024, GlobalFoundries, Witmem, and Microchip announced sampling of Witmem’s WTM-8 video processor, capable of handling 8K video at 120 frames per second. Then, in March 2026, Mythic announced that it had selected memBrain technology for its next generation of ultra-low-power analog processing units. This brings us to September 2026 and the AnalogAI announcement that kicked off this column.

It’s necessary to note that we’re not talking only about theoretical possibilities or engineering prototypes. This technology is already finding its way into products that ordinary people can buy. Take the folks at Anker, for example. Their Soundcore Liberty 5 Pro and Liberty 5 Pro Max wireless earbuds feature the THUS AI audio chip, a co-developed processor that uses analog compute-in-memory technology to perform sophisticated AI computations locally, without relying on the cloud (check out this video). According to David, Witmem supplies the underlying silicon incorporating SST’s memBrain technology.

And this brings us back to the bigger picture. Microchip and SST see applications for memBrain technology ranging from smart speakers and security cameras to augmented-reality glasses, medical devices, autonomous drones, and industrial robots. The common thread is the ability to perform sophisticated AI computations without the power consumption traditionally associated with such workloads.

What started as an intriguing idea about using flash memory to perform calculations is becoming a growing family of real-world products. And if you happen to be listening to your favorite tunes through a pair of Anker earbuds, you may already have a little piece of this revolution nestled snugly in your lugholes. How cool is that?

I have a feeling that we’ll be hearing (and feeling) a lot about haptics in the not-so-distant future. With this in mind, it behooves us to prepare ourselves for the onslaught to come. Let’s start with the word “haptic” itself, which comes from the Ancient Greek haptikos, meaning “able to come into contact with” or “pertaining to the sense of touch.”

In 1685, the English mathematician Isaac Barrow used the Neo-Latin (a.k.a. New Latin) term hapticē, meaning “science of touch.” The word haptic appeared in English in the 19th century, initially in scientific and medical contexts. In 1892, German psychologist Max Dessoir proposed the term Haptik for the scientific study of touch, placing it alongside Optik (optics) and Akustik (acoustics). 

One important distinction is between passive tactile interfaces, which convey information through physical features that we can feel, and active haptic systems, which deliberately generate forces or vibrations to communicate information through touch. For example, Louis Braille developed his raised-dot writing system around 1824, allowing information to be communicated entirely through touch. This provides an excellent example of a tactile interface, although not an active force-feedback system.

Early examples of what we now call haptic feedback started to emerge in the 1940s. At Argonne National Laboratory, for example, engineers developed remote manipulators for handling radioactive materials. Their mechanical linkages transmitted forces back to the operator, allowing the person to feel resistance when the remote gripper encountered an object (I know, like you, I’m currently thinking about the scene where Homer drops his radioactive sample in The Simpsons Opening Credits and Theme Song).

Another early example of deliberately generated haptic feedback appeared in aviation in the late 1940s and early 1950s. In smaller aircraft with mechanically linked flight controls, as the aircraft approached a stall condition (when the angle between its wings and the oncoming airflow became too great), the pilot could feel aerodynamic buffeting (vibrations) through the controls. However, this natural feedback wasn’t always reliable, and the introduction of powered flight controls in larger aircraft further isolated pilots from the aerodynamic forces acting on the control surfaces.

To address these issues, aircraft designers developed devices known as “stick shakers” that monitored flight conditions, including angle of attack, and deliberately vibrated the control column when they detected an impending stall, thereby giving the pilot an unmistakable tactile warning.

For much of the 20th century, haptic feedback remained largely the preserve of specialized applications like these. However, with the rise of computers, video games, virtual reality, and mobile devices, haptics began to make its way into everyday life.

Unfortunately, there have been some “hiccups” along the way. For example, I remember being intrigued by the Logitech iFeel MouseMan, which appeared around 2000. (Eeek! That’s more than a quarter of a century ago as I pen these words!) Built on technology from Immersion Corporation, this clever little device could communicate information through touch rather than relying solely on visual cues. 

When you moved the cursor over a hyperlink or button, the mouse would generate a brief vibration that gave you the sensation of encountering a little bump. Similarly, you might feel another simulated bump when you reached the edge of a window. Essentially, this allowed you to “feel your way” around a web page.

Alas, despite its promise, the iFeel MouseMan never really caught on. In some ways, I think it was ahead of its time. One challenge was that the technology depended on specialized software, and there wasn’t a widely adopted industry standard that allowed applications and haptic devices to communicate seamlessly. Without broad support from software developers, the benefits were limited, and the technology soon faded from view.

This illustrates an important point: having clever hardware is only part of the equation. If haptic interfaces are to fulfill their potential, we also need common standards that allow hardware and software from different manufacturers to work together. Hold that thought, because we’ll be returning to it shortly.

Of course, when haptic feedback is done well, the results can be surprisingly convincing. For example, my previous iPhone had a Home button (Oh, how I miss that button). I never consciously realized that this button didn’t actually exhibit a mechanical “click” until the battery ran down, at which point it felt… well, sort of lifeless. With power, however, pressing the button triggered Apple’s Taptic Engine, which generated a precisely controlled vibration that fooled my finger into thinking something had physically moved.

Today, we’re surrounded by devices that communicate with us through touch, from smartphones that vibrate to acknowledge our commands to game controllers that shake, rattle, and roll in response to the action on the screen. And, as we are about to discover, all of this is just the beginning.

The first thing worth noting is that deliberately making things vibrate is one thing. Making them vibrate in precisely the right way, at precisely the right moment, to convey a particular sensation is quite another. For many years, the most common approach to generating haptic feedback involved an eccentric rotating mass (ERM) motor. This is essentially a tiny electric motor with an off-center weight attached to its shaft. When the motor spins, the unbalanced weight causes the entire assembly to vibrate. Think of the buzzing notification on an old pager or the rumbling of an early video game controller. These devices certainly did the job, but they weren’t particularly sophisticated. Since the motor takes time to spin up and slow down, producing short, sharply defined sensations is tricky. Also, you can only communicate so much by making something buzz.

Things became considerably more interesting with the arrival of linear resonant actuators (LRAs). Instead of spinning an off-center weight, these devices use electromagnetic forces to move a mass back and forth. Apple’s Taptic Engine (which we mentioned earlier) is a well-known example, capable of producing such convincing tactile sensations that a solid-state trackpad can feel as though it contains a mechanical switch.

But even conventional LRAs have limitations, particularly when it comes to the range of frequencies over which they can operate effectively. And this brings us, at long last (I bet you thought we’d never get here), to the fact that I was just chatting with Tim Szeto, who is the founder and CEO of TITAN Haptics.

Based in Toronto, Canada, TITAN was incorporated in 2021, although its underlying technology originated in a Silicon Valley research laboratory several years earlier. One of TITAN’s specialties is its Linear Magnetic Ram (LMR) actuator technology. Unlike traditional resonant actuators that employ mechanical springs, TITAN’s devices use a magnetic suspension system. This allows them to respond across a much wider frequency range, opening the door to far richer tactile experiences.

As Tim explained, think of a modern haptic actuator as being rather like a loudspeaker. The difference is that, instead of moving air to produce sounds you can hear, it’s mechanically coupled to a device to produce sensations you can feel.

Imagine a gaming controller that can reproduce the gentle pitter-patter of raindrops, the rumble of an approaching tank, and the sharp recoil of a weapon. Or a touchscreen that responds to your finger with a convincing mechanical click, even though nothing actually moves beneath it.

All of this sounds (well, feels) wonderful, but—as usual—there’s an elephant in the room and a fly in the soup (I never metaphor I didn’t like). Having an actuator capable of producing sophisticated sensations doesn’t necessarily make it easy to tell the little scamp what to do.

Historically, different manufacturers have developed their own approaches to describing, generating, and controlling haptic effects. But this has made life unnecessarily complicated for designers who want to create consistent tactile experiences across different products and platforms.

Enter the Universal Haptics Protocol (UHP) 1.0 specification, developed by the Haptics Industry Forum (HIF), whose members include familiar names like Logitech and iRacing. Announced in September 2026, UHP provides a common language for describing haptic effects, identifying device capabilities, directing effects to appropriate actuators, and controlling playback. Interestingly, TITAN is also a member of HIF, and Tim chairs the working group responsible for developing the protocol.

Rather than requiring every manufacturer to reinvent the proverbial wheel, the idea is to provide a shared foundation the industry can build on. In turn, this brings us to TITAN’s latest offering: their VH Module, which is the first product on the market to implement the UHP 1.0 specification.

Meet the VH Module (Source: TITAN Haptics)

Measuring a minuscule 10.8 × 10.8 mm, the VH Module is a complete embedded haptic processing and drive subsystem. One important point to appreciate is that the module doesn’t actually vibrate itself. Instead, it generates and amplifies the electrical signals that drive external haptic actuators, including TITAN’s own wideband LMR devices.

The module contains onboard digital signal processing (DSP), supports two independently controlled actuator channels, and provides up to 3W per channel under specified operating conditions. The host microcontroller communicates via a serial UART interface, while an I²S interface accepts digital audio.

This last point is particularly interesting because the VH Module supports something called “audio-to-haptics.” Suppose you’re designing a gaming controller. Your game already generates sounds corresponding to explosions, engines, impacts, and other events. Rather than creating an entirely separate set of haptic effects, you can feed the existing digital audio stream into the VH Module, which processes it in real time to generate corresponding tactile sensations.

Of course, you probably don’t want the controller vibrating every time someone speaks. Fortunately, the module’s DSP can filter and equalize the incoming audio, allowing developers to shape the resulting sensations.

But audio-to-haptics is only half of the story. For situations requiring more deliberate control, TITAN provides its Vector Haptics API, which allows developers to create precisely defined effects using a collection of fundamental building blocks, or primitives.

Tim likens these primitives to LEGO bricks. Instead of choosing from a fixed collection of prerecorded vibrations, developers can combine simple elements such as pulses, ticks, vibrations, pauses, and frequency sweeps. Parameters including duration, intensity, frequency, and sharpness determine how the resulting sensations feel.

The clever part is that these effects can be represented using remarkably small amounts of data. Rather than storing an entire sampled waveform, the host microcontroller can store a compact description of the desired effect, transmit it to the VH Module, and leave the module to generate the waveform.

Better yet, audio-derived sensations and API-generated effects aren’t mutually exclusive. The VH Module can mix them together in real time, allowing multiple effects to overlap. Imagine playing a game in which you’re piloting a spacecraft. The audio-to-haptics functionality could generate a continuous low-frequency rumble from the engines, while the API adds a sharp tactile click whenever you activate a control, followed by a powerful jolt when an enemy projectile strikes your ship. Also, because the module supports two independently controlled channels, you can direct different sensations to different actuators.

What’s particularly appealing is that TITAN has brought all these capabilities together in a tiny module, rather than requiring developers to cobble together their own combination of processors, signal-processing algorithms, amplifiers, and proprietary control interfaces.

As Tim observed during our conversation, designing compelling haptic experiences is becoming something of an art form. Much like music, it’s not simply a matter of making everything as loud as possible. Subtlety, timing, and contrast are what make the experience convincing.

Potential applications extend far beyond gaming. Think of augmented- and virtual-reality headsets, automotive controls, wearable devices, medical equipment, and computer mice that provide tactile feedback as you navigate menus, drag objects, or resize windows.

When I first heard about the Logitech iFeel MouseMan more than two decades ago, the idea of feeling one’s way around a graphical user interface seemed fabulously futuristic. I was sad when it failed to fully materialize. Now, with increasingly sophisticated actuators, compact drive electronics, and emerging industry standards, it seems that the future has finally arrived, which is a bit embarrassing because I haven’t prepared a speech and don’t have anything suitable to wear.

I don’t know about you, but I have a feeling we’re only just beginning to ride the haptic wave, and we’ve barely scratched the surface (although this time, we might actually be able to feel the scratches). May the haptic wave be with you!

As you feast your orbs on these words (assuming you’re feasting them early in the morning of October 20, 2026), magnificent marvels of modern engineering are being unveiled at Synaptics Tech Day 2026. Before we delve into these technological treasures, however, it behooves one of us to set the scene…

OK, I’ll do it if you insist. As a species, we’ve been getting up to all sorts of mischief since our ancestors first ventured down from the trees some six million years ago. We’ll return to this later, but first I have a tale to tell involving two companies: Synaptics and Google (we’re primarily interested in Google Research here). I’d wager that virtually everyone on the planet has heard of Google, while also betting that relatively few people outside the engineering community have heard of Synaptics (and even among engineers, I suspect many would have a knee-jerk reaction: “Aren’t they the folks who make the touchpads in laptop computers?”).

Well yes, they are, but there’s much more to the story than that. Synaptics was founded in 1986 by two semiconductor industry legends: Federico Faggin, who led the development of Intel’s groundbreaking 4004 microprocessor and subsequently co-founded Zilog, and Carver Mead, a Caltech professor who pioneered VLSI design and neuromorphic engineering.

Many people are surprised to learn that Synaptics was originally founded to explore artificial neural networks and brain-inspired computing. Indeed, the company’s name is a portmanteau of “synapse” and “electronics” (one of those tidbits of trivia that’s obvious once you’ve been told—you’re welcome).

Thus, although Synaptics later became famous for its laptop touchpads and other human-machine interface technologies, artificial intelligence was part of its DNA from the start. Today, the company boasts an astonishingly broad portfolio encompassing embedded processors, wireless connectivity solutions (including Wi-Fi and Bluetooth), advanced sensing and display technologies, and increasingly sophisticated edge AI capabilities, along with the software and development tools needed to bring these technologies to life.

Now let’s turn our attention to Google. It’s amazing to me that many younger engineers cannot envision a world without Google, although—to be fair—many older engineers cannot remember the world before Google. (They say memory is the second thing to go; I can’t remember what the first was.)

As I’ve mentioned on past occasions, and as I’ll doubtless mention again in the future, the internet first started to impinge on the collective consciousness in 1993 with the launch of the Mosaic web browser. In those early days, there wasn’t much on the internet, and the main way to wend your weary way around what little there was involved word of mouth.

In 1994, Jerry Yang and David Filo launched Yahoo!, which began life as a manually curated directory of websites—organized into categories and subcategories—called “Jerry and David’s Guide to the World Wide Web.” Think of it as a sort of manually maintained Yellow Pages for the World Wide Web.

Yahoo was certainly a step in the right direction, but it wasn’t until 1998 that Stanford students Larry Page and Sergey Brin transformed their fledgling search engine project into a company that would go on to change the world. Their search engine, which started life in 1996 under the somewhat unfortunate BackRub moniker (it’s probably best not to ask), was renamed Google in 1997, and Google Inc. was officially incorporated in 1998.

Of course, Google didn’t stop at revolutionizing internet search. Over the years, the company has given us Gmail, Google Maps, Google Earth, Google Chrome, Google Translate, and Google Docs, to name but a few. It also acquired and developed Android, which became the world’s most widely used mobile operating system, and YouTube, which transformed how we consume video.

Meanwhile, the boffins at Google Research have been pushing the boundaries of artificial intelligence (AI), giving us everything from TensorFlow, the open-source machine learning framework that helped democratize AI development, to the Transformer architecture that underpins today’s large language models (LLMs). Add Google’s pioneering work on tensor processing units (TPUs), its DeepMind division’s breakthroughs in protein structure prediction with AlphaFold, and its Gemini family of multimodal AI models, and you begin to appreciate just how profoundly Google has shaped our modern technological world.

The reason I’m waffling about all this (yes, of course there’s a reason) is that I was just chatting with Augustine Nebu Philips, Sr. Director, Strategy & Business Development at Synaptics, and Billy Rutledge, Director of Edge AI Research at Google. 

The first thing Nebu told me was that Synaptics is introducing what the company calls a new class of microcontroller (MCU): the xMCU. The idea is to bridge the gap between traditional MCUs, which are relatively inexpensive and power-efficient but limited in their processing capabilities and memory capacity, and more powerful application processors (APs), which can run sophisticated operating systems like Linux but typically demand more power, memory, and money.

Enter the new Synaptics Astra SR200 series, which combines the best of both worlds. These little beauties are designed to handle multiple AI workloads simultaneously, including vision, voice, audio, and display processing, while maintaining the low-power characteristics needed for battery-operated devices such as smart glasses, watches, and other wearables.

The family includes three pin-compatible members: the SR210, offering 200 giga operations per second (GOPS) for voice and sensing applications; the SR230, delivering 300 GOPS for more sophisticated vision and display systems; and the SR250, boasting 400 GOPS for demanding multimodal applications.

So, what’s lurking under the hood? I’m so glad you asked; otherwise, I would have been obliged to bend over backward to work this into the plot. Consider the block diagram below:

SR200 block diagram (Source: Synaptics)

At the heart of the SR200 is an Arm Cortex-M85 processor running at up to 800MHz, accompanied by a lower-power Cortex-M52 processor for less demanding, always-on activities. By distributing tasks across different processing and power domains, the system can conserve energy instead of keeping everything running at full tilt.

It also includes up to 8MB of SRAM, complemented by high-bandwidth custom DRAM offering up to 256MB of additional memory. Add dedicated vision and graphics subsystems, optional audio processing courtesy of a Cadence Tensilica HiFi 5 DSP, hardware-based security, and a cornucopia of communication interfaces, and you get a more-than-impressive collection of capabilities squeezed into a single chip.

But the part that’s of particular interest here is the Synaptics Torq neural processing unit (NPU) subsystem, which combines two complementary AI engines: Synaptics’ own Torq T2 and Google Research’s Coral NPU.

The Torq T2 is optimized for accelerating well-understood neural-network operations, including the multiply-accumulate calculations that underpin convolutional neural networks (CNNs) and Transformers. Think of it as a specialist who can perform familiar tasks at extraordinary speed and efficiency.

By comparison, the Coral NPU is the team’s flexible, adaptable member. Based on the open RISC-V architecture, it offers programmable scalar and vector processing capabilities, allowing it to handle operations that dedicated acceleration hardware may not support.

As Nebu explained, familiar workloads can use the Torq T2’s specialized hardware, while newer or less conventional operations can be handled by the Coral NPU. The result is a combination of efficiency and flexibility that neither engine could provide quite so effectively on its own.

Now, here’s where things get really interesting. Google’s Coral NPU isn’t simply another proprietary processor core available under some complicated licensing arrangement. Instead, Google Research is making the architecture available as open-source intellectual property (IP), allowing other semiconductor companies to incorporate it into their own systems-on-chip (SoC) devices, potentially modifying and extending it to meet their own unique requirements.

Billy explained that one of the biggest headaches facing AI developers is the bewildering assortment of proprietary NPUs and associated software tools. An AI model that works beautifully on one chip may require considerable effort to port to another, and developers often have little visibility into what’s happening inside the proprietary tools.

Google wants to change all that, which is why the Coral NPU is designed around open standards, including RISC-V, while Synaptics’ open-source Torq compiler and runtime use technologies such as MLIR and IREE to provide a more consistent development environment. The goal is to make it easier for developers to move AI models between compatible platforms without reinventing the wheel every time.

Billy, who previously spent many years working on Android, sees parallels between Google’s approach to that operating system and its ambitions for Coral. Rather than keeping everything locked away, the idea is to encourage a flourishing ecosystem where developers and semiconductor companies can build on a common foundation.

And this isn’t merely a theoretical exercise. Synaptics was the first commercial adopter and integrator of Google’s Coral NPU IP, incorporating the first-generation architecture into its Astra SL family in 2025. The new SR200 series takes the collaboration another step forward by incorporating the second-generation Coral NPU, which adds SIMD vector processing to improve performance and energy efficiency.

Of course, great silicon is all well and good, but developers need some way to play with it. Which brings us to the Coralboard, a family of development platforms created through the collaboration between Synaptics and Google Research.

Meet the Coralboard (Source: Synaptics

The first member, the Coralboard SL, is based on the Astra SL2619 processor, which features dual Arm Cortex-A55 cores and a 1 TOPS NPU subsystem combining Synaptics’ Torq T1 and Google’s first-generation Coral NPU. Following an initial limited release, this board is now generally available through DigiKey.

Meanwhile, Synaptics is introducing the Coralboard SR, based on the new SR250, with its Cortex-M85 and Cortex-M52 processors and 400 GOPS Torq/Coral NPU subsystem. Samples are being demonstrated at Tech Day 2026, with broader availability anticipated in the first half of 2027.

Both boards provide interfaces for connecting cameras, displays, sensors, and other peripherals, along with access to the same open-source development environment. The idea is to make experimenting with sophisticated edge AI almost as accessible as experimenting with an Arduino or Raspberry Pi.

As you may have spotted from the box in the image above, there’s a third company involved in this adventure: an embedded hardware specialist based in Poland called GRINN (smile when you say that). As Nebu explained, the Coralboard design incorporates a production-grade system-on-module (SoM) from GRINN, complete with essential supporting components such as memory and storage.

This provides an attractive path from prototype to production. Developers can start by experimenting with the Coralboard, then incorporate the GRINN SoM into their own products, or ultimately design the Synaptics processor directly onto their own circuit boards.

The possibilities are enormous. Imagine smart glasses that recognize objects and interpret their surroundings, wearables that understand spoken instructions without constantly communicating with the cloud, industrial sensors that recognize developing problems, and robots that respond intelligently to their environments.

And this is only the beginning. Billy told me that Google Research has further enhancements to the Coral NPU architecture in the pipeline, while Synaptics plans to continue introducing new processors and development boards as the technology evolves.

Which brings us full circle. As we noted at the beginning of this column, around six million years ago, our ancestors ventured down from the trees to explore the possibilities of life on the ground (I bet you thought I’d forgotten about this—actually, I bet you’d forgotten about this). Forty years ago, Synaptics was founded to explore the possibilities of neural networks and brain-inspired computing. Today, working closely with Google Research, the company is helping bring sophisticated neural processing capabilities to devices that can fit in the palm of your hand. All of this makes me proud to be a hominid, is all I can say.

Samples of the two-chip 1801 (internally known as the TC 1084 and TC 1085) became available in 1972 and were used to construct a series of FRED development systems. The basic FRED system had a front panel with lights and switches for entering programs by hand, a gravity-fed punched-card reader and a cassette tape deck for program storage, and a television interface for display.

The Weisbecker family got one of these early FRED systems, and Joyce Weisbecker started writing COSMAC programs that year, at the age of 14. At first, she just toggled the programs into the FRED system using the front-panel switches. She’d key them into the system, debug them, play with them, and then move on. Then, Joyce’s father said:

““Hey, you know, we need demonstration programs to show how much you can actually do with this because everyone looks at the instruction set and the speed and says, ah, it’s too limited. Well, if you’re doing things in real time with people, you only have to be faster than people are. And people are really slow. So, there’s plenty of time to get things done at the human reaction level.”

The demonstration programs including those written by RCA employees and a teenaged Joyce Weisbecker went into the RCA VIP manual. As Joyce explained:

“I got credit… So I got my name in it, but I didn’t get any money.”

Joe Weisbecker then started to lobby for an inexpensive development system and convinced RCA to develop a single-board computer based on the 1802 and called the VIP. Joyce described her father’s thinking behind the VIP:With prototype samples of the two-chip COSMAC 1801 microprocessor available in 1972, Joe Weisbecker turned his attention to creating the documentation and development support that a processor or microprocessor needs to succeed in the market. First, he wrote a manual for his initial development system, System 00, which is the prototype for a system he called “FRED” or the “Flexible Recreational Educational Device.” That typewritten manual, dated July 1972, carried the drawing of a happy face on its cover, which likely symbolizes the joy Weisbecker felt from having realized the vision of a small computer he’s carried in his head for two decades.

“Now the way he got the VIP done, since RCA didn’t want to do products, what he pitched was, ‘OK, if you want companies to embed your processor, to use your part in their equipment, and have large volume orders, you have to have something that lets the design engineers get up to speed with it and prototype.’ So, the VIP was meant to be the prototype kit with self-study.”

Naturally, the COSMAC VIP manual needed to include sample programs. Joyce explained:

“So that’s how Dad pitched it. He said, ‘You need something that, in addition to corporate training, you can just have people buy and learn on their own, for the little companies and the guys who just want to get into it and their companies are not sponsoring it, because those are your future customers for volume production.’

“And Dad said, ‘If you do that, people are buying this now on their own budget. They have to justify it.’ And of course, you know, at the time, men are buying it, and they have to justify it to their wives. So that’s how he pitched it. 

“And he said, ‘So, it’s [going to cost] $250 or $300. That’s a lot of money for something that the company should be paying for, and the argument is going to be, well, I need it for my work.’ It was like you need it for your work, so how come work isn’t paying for it? And this is the way to get around companies that won’t pay for it, he said: ‘If you put games in it, you can say, ‘Well, when I’m done, the kids can use it to play games with it. So, it’s not a complete waste after I’m done with it.’

“He said, ‘So it was, of course, a hobbyist system. You want to have games in it because you want someone that, before they do anything interesting with it and creative, you want them to just type in games and show all their friends what it can do. But you can’t tell RCA that because they don’t want to be in a low volume business like a hobby computer.’”

RCA’s COSMAC VIP was an early trainer for the RCA COSMAC microprocessor. Image credit: The Sarnoff Collection, The College of New Jersey

However, a hobby computer was exactly what Joe Weisbecker had in mind. The VIP also needed a manual, and Joyce Weisbecker contributed two games to the VIP manual as well. Her father Joe, acting as her agent, managed to secure $250 for each game, which went to Joyce’s college fund.

RCA’s COSMAC VIPs were low-cost, single-board computers based on the COSMAC 1802 microprocessor. RCA originally sold the COSMAC VIP for $275 and then dropped the price to $249. By 1980, RCA was selling a reduced-cost VP-111 version of the COSMAC VIP for $99 and the original VP-711 with more RAM, expansion connectors, a power supply, and a plastic cover for $199.

This advertisement from the February 1980 issue of Byte magazine lists the original COSMAC VIP, the VP-711, for $199 and the lower-cost version, the VP-111, for $99 – payable directly to RCA Corp. Image credit: RCA and Byte magazine

Prior to introducing the COSMAC VIP, RCA produced two earlier development systems: the COSMAC Microkit and the Microtutor. RCA introduced the Microkit in 1974. It was a more traditional and far more expensive microprocessor development system packaged in a metal box sized for a 19-inch rack. The COSMAC Microkit was based on the initial two-chip COSMAC 1801 microprocessor. The Microtutor was a bare-board computer system with a 44-pin edge connector that accepted a processor card. Initially, that card would be populated with the two-chip COSMAC 1801 microprocessor, which could be replaced by a card based on the single-chip 1802 microprocessor when it became available. RCA later produced the CDP18S601 COSMAC Microboard, a single-board computer based on the 1802 microprocessor that was designed to slide into a small card cage.

EDN magazine featured the RCA COSMAC Microkit for its 1975 microprocessor directory. Image credit: EDN

However, Joe Weisbecker didn’t trust RCA to stick with the COSMAC microprocessor, and with good reason given the sale of its entire mainframe computer business to Sperry Rand in 1971, so he devised a plan to keep his microprocessor in the public eye even if RCA lost interest and backed off. He initiated that plan by publishing a single-board 1802 design as the cover story in the August 1976 issue of Popular Electronics magazine. That design, the COSMAC Elf, was essentially a homebrew version of the COSMAC Microtutor, but it was based on the single-chip COSMAC 1802 microprocessor instead of the two-chip 1801.

Popular Electronics featured Part 1 of a series of articles about the COSMAC Elf microprocessor trainer on the cover of its August 1976 issue. Image credit: Popular Electronics

Weisbecker’s first COSMAC Elf article in Popular Electronics was a big success. The electronics hobbyist community was hugely interested in microprocessors, and the Elf was a low-cost way of getting access to a microprocessor-based computer. Weisbecker’s article claimed you could build an Elf using only about $80 worth of parts. The first two paragraphs of the article read:

“There are basically two ways in which you can get involved with microcomputers on the nonprofessional level. You can buy one of several reasonably priced hobby computer kits, add a TV or typewriter terminal, and learn to use high-level language. On the other hand, you can build your own inexpensive system from scratch. This permits you to experiment with simple applications that do not require an expensive terminal or a large memory. You can communicate with the computer in a relatively simple language.

“The ‘Elf’ microcomputer project gives you the latter category of computer system-for about $80. It is an excellent hardware and software trainer that uses machine language and can be easily expanded to do just about anything a full-blown microcomputer can. Packaging, however, is up to you.”

Weisbecker followed up with several more COSMAC Elf articles in Popular Electronics. Part II of the original Elf article appeared in the September 1976 issue of Popular Electronics, followed by Part III in the March 1977 issue, and Part IV in the July 1977 issue. These subsequent articles described a low-cost Elf display, expansion of the Elf’s I/O ports and memory, and the addition of a graphic video display that could drive a television using RCA’s inexpensive CDP1861 “Pixie” graphics chip and video display controller.

Depending on how you count, the 1802 has between 90 and 100 machine instructions. The official number is 91. However, Weisbecker designed the architecture so that it could easily be supplemented by a small byte-encoded interpreter that acted as an instruction-set extension or a virtual machine. On System 00 and the FRED machines, the interpreter was called FEL (FRED Experimental Language) or FPL (Fred Programming Language). For the COSMAC VIP and the Elf, the language evolved into CHIP-8. The purpose of all these small interpreters was to give the processor additional programming features without expanding the hardware instruction set. Weisbecker’s design philosophy was to implement capabilities such as a software stack or a call and return mechanism with short pieces of code instead of processor hardware to add flexibility and to minimize hardware complexity. This concept proved so popular with hobbyists that there are still people devising extensions along the lines of FEL, FPL, and CHIP-8 for 1802 systems.

Weisbecker’s articles in Popular Electronics started a COSMAC Elf bandwagon that continues to roll 50 years later. Hobbyists created add-ons and software for the COSMAC Elf and wrote articles in various publications including Popular Electronics, Byte, and Dr Dobbs. Enthusiasts are still developing Elf-related projects including new and improved versions of the Elf, hardware add-ons, and software to run on Elf systems. Today’s Elf bandwagon is simply Joe Weisbecker’s vision for an accessible computer, alive and walking.

For example, should you want to build a working COSMAC Elf, you can get a bare printed circuit board from PCBWay for a design called the ELF2K, designed by Emilio Aoi. Alternatively, Lee Hart has developed a kit called the Membership Card that miniaturizes the half-century-old Elf design so that it fits into an Altoid breath mint tin. Kits cost $39.95 to $89.95, and there are many inexpensive accessories and proto boards available as well. Bill Rowe looked at Lee Hart’s Membership Card and said, “Hold my beer.” He developed the Olduino board that allows you to interface the Membership Card to Arduino shields.

Lee Hart’s Membership Card shrinks the COSMAC Elf’s design so that it fits in an Altoid breath mint tin. Image credit: Lee Hart/Sunrise-EV.com

If you merely want to play with the 1802 instruction set and the various software environments wrapped around the 1802 during the 1970s and 1980s without dealing with the antique hardware, Marcel van Tongeren has been developing his Emma 02 Emulator since 2007. It’s based on Mike Riley’s RCS Elf Emulator, developed in 2006. The Emma 02 Emulator emulates a variety of CDP1802-based systems and is available for several operating systems.

One central repository for 1802-related information is cosmacelf.com. The site’s links page will take you on a magical mystery tour of the efforts still being devoted to Joe Weisbecker’s architecture. In addition, Herb Johnson’s retrotechnology.com site collects a huge amount of information about old computers including 1802-related information. However, numerous broken links on these sites attest to the gradual disappearance of people who have been fascinated by and working with the 1802 for 50 years.

RCA and its semiconductor division are long gone but the COSMAC 1802 is still available. The 1802 has survived for five decades by bouncing from one semiconductor manufacturer to the next. Harris bought RCA’s semiconductor division in 1988. Sterling Holding LLC bought Harris and spun it off as Intersil in 1999. Renesas bought Intersil in 2017 and still lists the 1802 as an active part (although the datasheet still says “Intersil”). Digikey shows thousands of CDP1802 microprocessors in stock across several related part numbers at the time of this writing. Digikey currently lists 1802 processors for between $5 and $48 depending on which speed grade and package type you pick. The data sheets for these 1802s show Harris as the maker but the 1802 Web pages on Digikey’s site say that the parts are currently supplied by Rochester Electronics, a specialist in supplying “vintage” semiconductors. As long as there’s a market for 8-bit microprocessors, it seems that the 1802 is likely to be one of the longest-lived survivors.

See all three articles in this COSMAC series:

COSMAC: The Long, True, and Never-ending Story of the World’s First CMOS Microprocessors, Part 1

COSMAC: The Long, True, and Never-ending Story of the World’s First CMOS Microprocessors, Part 2

COSMAC: The Long, True, and Never-ending Story of the World’s First CMOS Microprocessors, Part 3

I often hear (or read) someone saying something that really strikes a chord, like the lyric “I wish I didn’t know now what I didn’t know then” from Toby Keith’s 1994 single Wish I Didn’t Know Now. Some of these turns of phrase, memorable observations, and pearls of wisdom really stick with me, often leaving me thinking, “I wish I’d said that.”

Of course, this reminds me of the famous exchange that’s generally attributed to the Irish playwright Oscar Wilde and the American artist James McNeill Whistler. Oscar was renowned for his wit, but he also had a reputation for borrowing other people’s clever remarks and passing them off as his own (something I would never do). As the story goes, on one occasion Whistler made a particularly witty remark, prompting Wilde to exclaim, “I wish I had said that.” To which Whistler replied, “You will, Oscar, you will.”

In turn, this reminds me of Monty Python’s Oscar Wilde Sketch featuring Oscar Wilde, James McNeill Whistler, and George Bernard Shaw, who are entertaining the Prince of Wales.

They take turns making increasingly outrageous and insulting remarks about the Prince, only to attribute them to one another. The unfortunate person credited with each insult must then scramble to explain how it was actually intended as a compliment. The insults grow more offensive, the explanations more desperate, until poor Shaw is eventually left holding the proverbial bag.

I’m sorry, I got distracted; where were we? Oh yes, I was thinking of how John Donne’s famous observation that “No man is an island” is as true today as it was when he penned those words more than 400 years ago. None of us exists in isolation. We’re all connected to the people around us, influenced by their thoughts and actions, and dependent on one another in ways we may not even realize. Everything we do builds, in some way, on what others have done before us.

The reason for my meandering musings is that I recently saw an announcement on the E3 Designers LinkedIn Page: “Super excited to announce that E3 Designers is now an AMD Embedded Partner Network company!” I found a corresponding entry when searching for E3 Designers in the AMD Embedded Partner Directory.

Now, I realize that a small engineering company becoming an AMD partner may not sound like news that will make the Earth tremble on its axis. But bear with me, because there’s a lot more to this story than meets the eye.

First, a little background. E3 Designers is a small engineering consultancy founded in 2015 by Dan Binnun, who serves as its President and Principal Hardware Architect. Based just west of Boston, Massachusetts, E3 comprises a team of only five people, most of whom work remotely. Don’t let this company’s diminutive dimensions deceive you, however, because these chaps are more than capable of punching above their weight.

The company specializes in helping customers tackle complex hardware design challenges, from developing complete electronic systems to solving problems that can leave even experienced engineers scratching their heads. In recent years, Dan has become particularly involved in signal integrity (SI) and power integrity (PI), both of which are increasingly important as electronic systems become faster, smaller, and more complicated.

But I’m getting ahead of myself. To understand why E3’s recent announcement caught my attention, we need to rewind to 2012. What were you doing then? At the time, I was managing a website called All Programmable Planet (APP), which was devoted to all things programmable, especially field-programmable gate arrays (FPGAs).

One day, I received an email from my friend Mike Santarini, who was the publisher of the Xilinx Xcell Journal at the time. This was an award-winning, quarterly technical magazine and trade journal published by the semiconductor company Xilinx (which was eventually acquired by AMD).

Mike told me about a young engineer (well, young compared to me) in England called Adam Taylor, who had been writing on FPGA-related topics. Mike thought Adam might be interested in contributing to APP, so he suggested that I reach out to him. I did. Adam was. And he subsequently started writing columns for the site. At the time, this seemed like nothing more than a straightforward introduction between two people with a shared interest in electronics. None of us knew where this would lead.

A little later, I was asked to prepare a webinar involving functional safety, reliability, mean time between failures (MTBF), and related topics. I knew just enough about the subject to realize how much I didn’t know (which, in a weird way, sort of brings us back to Toby Keith).

I remembered that Adam had considerable experience in this area, so I emailed him to ask if we could have a chat on the phone. This was back in the days before widespread video conferencing when people used their telephones to talk to one another. Adam generously shared his knowledge; I managed to put my webinar together; and before long, we’d become firm friends.

Meanwhile, I was also involved with the Embedded Systems Conference (ESC), where one of my responsibilities was recruiting interesting people to give highly technical presentations. Naturally, Adam sprang to mind, so I invited him to speak at one of the conferences in 2013. He proved to be an excellent presenter, so I kept inviting him back. 

Over the years, we attended a cornucopia of conferences across America, and Adam went from strength to strength. In 2014, he founded ADIUVO Engineering and Training, which has become a highly respected name in the FPGA and embedded systems communities. More recently, he launched the FPGA Horizons Journal and an accompanying series of FPGA Horizons Conferences, which bring together engineers, industry experts, and technology companies on both sides of the Atlantic (the second annual UK event has just taken place, while the second annual US event is scheduled for April 2027).

Now we come to the next link in our chain of events. At an Embedded Systems Conference in Boston, around 2015 or 2016, Adam met a fellow engineer called Dan Binnun. They got chatting, found common interests, and stayed in touch. Again, nothing particularly earth-shattering, perhaps, but this meeting was destined to bear fruit.

In 2017, Adam, Dan, and Saket Srivastava collaborated on a project involving technology intended to help people with visual impairments. The experience evidently went well, because they subsequently decided to write a book together. The result was A Hands-On Guide to Designing Embedded Systems, published by Artech House (see my column A Hands-On Guide to Designing Embedded Systems). This provides practical guidance on developing embedded systems, drawing on the authors’ extensive experience in hardware and software engineering.

Over the following years, Adam and Dan worked together on various engineering challenges, which brings us to one of Adam’s more ambitious projects: an FPGA-based development platform called the Explorer Board.

The Explorer board (Source: ADIUVO)

Now, designing a modern FPGA development board isn’t simply a matter of plonking a few components onto a printed circuit board (PCB), connecting the appropriate pins, and hoping for the best. Today’s high-performance FPGAs can communicate at extraordinary speeds. When signals are traveling at multiple gigabits per second, PCB traces, vias, connectors, impedance discontinuities, and power distribution networks all become important considerations.

This is where signal integrity and power integrity come in. In simple terms, signal integrity ensures electrical signals arrive at their destinations in good enough condition to be interpreted correctly. Power integrity ensures the circuitry receives a stable, clean power supply, even when large numbers of transistors switch at breathtaking speeds. The two are closely related, and getting either wrong can result in a system that works intermittently, behaves unpredictably, or refuses to work at all.

Adam’s Explorer Board presented a particularly interesting challenge. He wanted to use devices with extremely fine-pitch ball grid array (BGA) packages, featuring connections spaced just 0.5mm apart, while achieving high-speed serial communications using relatively conventional PCB fabrication techniques. Rather than resorting to exotic materials and expensive manufacturing processes, the goal was to employ standard FR-4 PCB material and conventional through-hole vias. At these speeds, this is easier said than done.

Fortunately, Adam knew just the chap to call. Dan and E3 Designers brought their signal integrity and power integrity expertise to bear on the problem, performing the analysis needed to establish that the proposed approach could work. And work it did! The resulting design achieved serial communications at an impressive 12.5 gigabits per second using conventional PCB construction techniques.

Adam is unequivocal about Dan’s contribution. When we chatted recently, he credited Dan as a key reason they achieved this performance. In fact, Adam told me that whenever he needs an SI or PI engineer, Dan is the person he turns to. Coming from someone with Adam’s experience, that’s quite an endorsement.

By now, you may be wondering what any of this has to do with E3 Designers becoming an AMD Embedded Partner Network company. Well, here’s where the various threads come together (“I love it when a plan comes together,” as Colonel John “Hannibal” Smith was wont to say).

Adam’s Explorer Board project demonstrated E3 Designers’ ability to tackle demanding high-speed hardware challenges. Adam was delighted with the results, and the folks at AMD were impressed, too. As Dan explained when we spoke, Adam and Bryan Fletcher at AMD helped make the partnership happen. Bryan championed E3 internally, recognizing the value of having a specialist partner with expertise in signal integrity and power integrity.

So, a company of just five people found itself welcomed into AMD’s Embedded Partner Network. Of course, this didn’t happen simply because Dan knew the right people. Connections may open doors, but expertise, hard work, and the ability to deliver results let you walk through them.

Dan and his colleagues had spent years honing their skills, tackling demanding projects, and establishing a reputation through word-of-mouth recommendations. Indeed, Dan tells me that virtually all of E3’s business has come through personal recommendations rather than conventional marketing. He doesn’t even issue press releases, which may explain why his company’s achievements aren’t as widely known as they deserve.

There’s also something rather endearing about Dan’s modesty. Despite working on sophisticated designs for some seriously impressive customers, he remains reluctant to describe himself as an expert. Adam, by comparison, has no such reservations about Dan’s abilities.

Consider the sequence of events we’ve just explored. Mike Santarini introduced me to Adam Taylor. I invited Adam to contribute to All Programmable Planet, and later to speak at the Embedded Systems Conference. At one of those conferences, Adam met Dan Binnun. Adam and Dan subsequently became friends, worked on engineering projects, wrote a book together, and collaborated on the Explorer Board. That collaboration helped demonstrate E3’s high-speed design expertise, which ultimately led to the company joining AMD’s Embedded Partner Network.

None of us set out to make this happen. Mike was simply making an introduction. I was looking for interesting authors and conference speakers. Adam and Dan were pursuing their engineering interests and helping one another along the way. And yet, here we are.

I find this fascinating because it makes me wonder how many other seemingly insignificant interactions have set similar chains of events in motion. How many careers have been shaped by a casual conversation? How many companies have been formed because two people happened to meet at a conference (or in an Irish pub, as described in my column The Internet: If A Wants to Talk to B, Why Does C Need to Be Involved?)?

And, of course, there’s one important conclusion to be drawn from all this. If Mike hadn’t introduced me to Adam, I might never have invited Adam to speak at ESC. If Adam hadn’t attended ESC, he might never have met Dan. And if Adam hadn’t met Dan, E3 Designers might never have become an AMD partner. So, when you think about it, E3 Designers’ latest achievement is almost entirely down to me. You’re welcome, Dan. It’s just one more service I offer (although I suppose Mike deserves a little credit too).

Joking aside, I think there’s an important lesson here. In this age of emails, instant messaging, and video conferencing, it’s easy to forget the value of getting together with other people in the flesh. There’s something special about attending a conference, listening to presentations, chatting with fellow engineers over coffee, and striking up conversations with complete strangers. You never know who you’ll meet, what you’ll learn, or where those chance encounters might lead.

And this isn’t just about conferences. Every time we share an idea, offer someone a helping hand, make an introduction, or encourage someone to pursue an opportunity, we set something in motion. The ripples from these seemingly insignificant interactions can spread much further than we ever imagined (see my column Is Dust in the Wind All We Are?).

Which brings us back to John Donne and his observation that no man is an island. We’re all connected, and we can all influence the people around us, often without even realizing it. Somewhere out there is a person you haven’t met, an idea you haven’t heard, or an opportunity you haven’t considered.

A conversation you have tomorrow might lead to something extraordinary five, ten, or twenty years from now. So, the next time you have an opportunity to attend a conference, introduce yourself to someone new, or lend a hand to a fellow engineer, I encourage you to grab it with both hands. You never know whose future you might change and, come to think of it, that future might be your own.

I find it hard to wrap my brain around how something as innocuous as Bluetooth can suddenly start impinging on my consciousness (and my Bluetooth-equipped devices) from all directions, including—it now turns out—from satellites whizzing around above our heads in low Earth Orbit (LEO).

Just to ensure we’re all tap-dancing to the same skirl of the Great Scottish Bagpipes, let’s kick off this column by briefly reminding ourselves what Bluetooth is, what it does, and—especially—what it was never intended to do.

Bluetooth is one of those technologies that has become so ubiquitous that we rarely stop to think about what it actually is. Conceived in the 1990s primarily as a short-range wireless replacement for cables, Bluetooth operates in the unlicensed 2.4GHz industrial, scientific, and medical (ISM) band. Its original mission was relatively modest: to let electronic devices in close proximity talk to each other without requiring us to festoon ourselves, our desks, and our homes with tangles of cables.

Bluetooth didn’t remain modest for long. What we now call Bluetooth Classic was later joined by Bluetooth Low Energy (BLE), which was introduced as part of Bluetooth 4.0 in 2010. BLE was designed for devices that could spend much of their time asleep, wake up to exchange relatively small amounts of data, and then return to their slumbers, thereby opening the door to battery-powered sensors, beacons, wearables, and a cornucopia of other applications.

And the Bluetooth boffins didn’t stop there. Over the years, they added mesh networking, direction finding, high-accuracy distance measurement, low-energy audio, one-to-many broadcast audio, and… the list goes on.

But the crux of this biscuit is that when somebody says “Bluetooth,” most of us still instinctively think in terms of devices separated by meters or perhaps a few tens of meters. However, as Bob Dylan so pithily put it, The Times They Are a-Changin’.

Hopefully you got to cast your orbs over my previous column: 50+ km Bluetooth? You Want to Do What? If so, as you will recall, the guys and gals at RFOXiA have already demonstrated a 4.6km ground-to-ground Bluetooth link, and they’re now targeting 20+km ground-to-air and 50+km air-to-air.

You might reasonably wonder why I’m returning to Bluetooth-centric shenanigans so soon after that column. Well, something just came along to catch my attention, tickle my fancy, and—more importantly—give me the perfect excuse to plunge even deeper into the weird and wonderful world of Bluetooth.

I’ve said it before (and I’ll doubtless say it again): I’m rarely excited to receive press releases focusing on business-type news along the lines of so-and-so having just been appointed CBW (Chief Bottle Washer) at company such-and-such; two organizations entering into a tentative agreement to evaluate the possibility of doing something potentially interesting at some indeterminate time in the future; or some institution being delighted to inform me that it’s just been awarded $41.99 in funding.

But there’s always the exception that proves the rule. Recently, for example, Jake Hertz from NanoHertz Communications reached out to share the news that a company called Hubble Network had announced a $200 million Series C round, bringing Hubble’s total funding to $300 million and valuing the company at $1.6 billion.

I must admit that a small “ho-hum” started to raise its sleepy head in the depths of (what I laughingly call) my mind. But then Jake went on to say, “Hubble’s LEO satellites communicate with standard, existing Bluetooth radios and chips, rather than requiring a satellite modem, antenna, or second radio.” This set my quizzical eyebrows quivering and caused me to think, “Wait! What?”

All of which explains how I came to find myself chatting with Ben Wild, who is the CTO at Hubble Network (Ben wants you to know they’re hiring). Not surprisingly, my first conversational gambit was to ask how a Bluetooth chip that sometimes struggles to communicate from one end of my house to the other can hold a conversation with a satellite that’s zipping around 550km above the planet.

Ground-based Bluetooth to Hubble satellite (Source: Hubble Network)

Ben was unfazed, explaining that several technological tricks are involved. For a start, normal Bluetooth Low Energy (BLE) operates at a data rate of around 1Mbps. Hubble slows this to only a few hundred bits per second and adds error-control coding. Taken together, Ben says these changes improve the receiver sensitivity from around −100dBm for standard BLE to approximately −140dBm—which is roughly comparable to LoRa. 

But that alone isn’t enough. Hubble’s current satellites carry phased arrays comprising more than 100 antennas. The signals from these antennas are combined using digital beamforming, providing approximately another 20dB of antenna gain. This beamforming also lets the satellite spatially filter interference from outside the area on the ground where its beam is pointed.

Finally, rather than using Bluetooth’s normal advertising channels, Hubble operates towards the relatively quiet edges of the 2.4GHz ISM band. According to Ben, when all these cunning tricks are combined, the current system enjoys around 15dB of link margin. 

The clever part is that none of this prevents the hardware from remaining a regular Bluetooth device. Hubble provides a software development kit (SDK) that runs on existing BLE chips. Most of the time, the device can carry on doing whatever Bluetoothy things it was doing before. When a satellite is due to pass overhead, the SDK temporarily takes control of the radio, transmits its satellite packet, and then returns the radio to normal Bluetooth operation.

Of course, these are really small packets. The current system supports payloads of up to 13 bytes, which may not sound like much until you consider how many useful things can be represented by relatively few bits. Sensors can report temperatures, tank levels, soil moisture readings, equipment status, and other small nuggets of information. A transmission takes only around 400ms, and Ben says each satellite can handle millions of devices simultaneously.

Hubble currently has six small satellites in orbit. These are approximately 20kg CubeSats—about the size of a shoebox before deployment—with phased arrays that unfold to around two meters across. A satellite is overhead for roughly three minutes, and the current six-satellite constellation provides at least one transmission opportunity per day.

Right now, this is strictly a one-way affair: the Bluetooth device can transmit to the satellite (uplink), but the satellite cannot transmit back to the device (downlink). Ben says a downlink capability may be added in the not-so-distant future. Once a satellite has received a packet, it stores the data until it passes over a ground station, whereupon the packet makes its way through Hubble’s servers to the customer. The data is end-to-end encrypted, so even the folks at Hubble cannot see what’s inside.

This isn’t merely a science experiment. Hubble says commercial service is available in North America today, with limited-availability customers already being onboarded. Ben told me they have “quite a few customers” and are already generating revenue.

Things are about to get even more interesting. Starting in 2027, Hubble plans to launch a series of much larger 500kg satellites whose phased arrays will contain more than 1,000 antennas and unfold to around nine meters across. These next-generation satellites are designed to hear devices transmitting at only +4dBm, compared with the +20dBm required today. The current plan is to grow the constellation to 60 satellites by 2030, reducing the wait between transmission opportunities from hours to around 20 minutes.

This means that a humble Bluetooth chip costing pocket change could eventually provide both conventional local Bluetooth connectivity and global satellite connectivity, all without adding a satellite modem, a satellite antenna, or a second radio.

Of course, there is one elephant in the room and fly in the soup (I never metaphor I didn’t like). We are already awash in a sea of electromagnetic radiation, and it appears the waves are getting higher and coming at us from ever more directions, but what can we do?

Well, for one thing, we can pity those poor fools who succumbed to the lure of the original DIY Aluminum Foil Deflector Beanies (AFDBs), which are “so 20th century, my dear.” These days, thank goodness, we have access to professional EMF Radiation Protection Beanie Caps from the folks at Defender Shield, who claim their 100% silver-fiber inner lining blocks up to 99% of RF radiation from 300Hz to 40GHz from reaching your head.

I don’t know about you, but I’m thinking of adding one to my Christmas list. That way, should the chaps and chapesses ever add a Bluetooth downlink from space, at least my poor old noggin will be ready to repel boarders.

After reading Edmund Callis Berkeley’s “Giant Brains or Machines that Think” shortly after it appeared in 1949, Joe Weisbecker decided he wanted to design computers but he was forced to wait for the better part of two decades to design one, despite getting a job with RCA’s mainframe computer division in 1956. Weisbecker was so frustrated with RCA that he developed an 8-bit computer in his basement using parts purchased from local New Jersey Radio Shacks. He completed the computer’s construction during the summer of 1970 and by the fall was telling anyone at RCA who would listen that he’d designed and built a computer. 

Joe Weisbecker’s System 00, the ur-COSMAC, used a gravity-fed punched-card reader for program storage (shown on top of the System 00 cabinet) and is using Weisbecker’s Heathkit oscilloscope for a display. Image credit: Joyce Weisbecker

Weisbecker called the computer System 00 and reasoned that someone, perhaps RCA or perhaps some other company, would ask him to design a computer based on his proof of concept: System 00. Weisbecker’s ultimate goal was to implement a computer on an IC.

System 00 was Joe Weisbecker’s TTL implementation of his 8-bit processor architecture, which would become RCA’s COSMAC microprocessor. Image credit: Herb Johnson/retrotechnology.com

By the fall of 1970, the signs at RCA’s computer division were becoming clear. People in the division were either being moved from New Jersey to Marlborough, Massachusetts or they were simply leaving the company. In addition, no one was working on a successor to RCA’s latest computer, the Spectra 70. Weisbecker interpreted the mass exodus to Marlborough as an early indication that RCA was planning to sell its computer division, and he was correct. RCA would announce that it was leaving the computer business by selling its mainframe computer division to Sperry Rand in September 1971.

Joe Weisbecker developed the core architecture of RCA’s COSMAC microprocessor in his basement using parts purchased from local Radio Shack stores in New Jersey. Image credit: RCA Engineer

Another person who also noticed these signs was Gerald “Jerry” Herzog, a 20-year veteran at RCA and Director of RCA’s Solid State Technology Center in Somerville, New Jersey – part of RCA Laboratories. Herzog had spearheaded CMOS development under a US Air Force contract and was responsible for proposing that RCA create a commercial product line of CMOS ICs – the CD4000 series. By 1970, half of the semiconductors made by RCA were going into RCA’s mainframe computers, so Herzog foresaw a huge problem looming in his future if RCA exited the computer business.

Herzog had heard about the System 00 computer and telephoned Weisbecker. During an interview, Joyce Weisbecker recounted the way her father described that phone call:

“My father came home and said, ‘I got a great call from Jerry Hertzog today. It turns out that he’s a physicist, and he’s been working at RCA on transistors since the transistor was new. And his goal was to figure out how to put an entire computer on a single semiconductor and was hoping to do that before he retired…

“And so, Hertzog was getting worried about it, so he called me up and he said, yeah, he’d be really interested in [my System 00 computer]. But he doesn’t think RCA will green light anything to do with computers since they’re in the process of getting out of it. And I said, ‘Yeah, that is going to be a problem.’ And Jerry said, ‘Well, but I really want to do it. Do you think you can do it in CMOS?’

“And Dad says, ‘Oh, it’s all TTL. I don’t see why not. It’s meant to be put on a chip. You know, there’s nothing in it that won’t go on an integrated circuit.’ And Hertzog says, ‘Yeah, OK. You know, RCA management’s really happy with how we’re doing these custom printed circuit boards for control, for original equipment manufacturers. That’s a very lucrative business, and they want us to expand it. So, I’m thinking maybe we could tell them that this is a way of using semiconductors to improve turnaround time and profit margins in that business, that it’s going to be two semiconductors, one standard, so we can get the volume up, and one custom in small volume for each customer.’ Dad said that wouldn’t be lying about what we’re doing, and yeah, that sounds good.

“So that was their cover story. When he came home, Dad told [us] that story and he said, ‘OK, if anybody in the family is talking to anyone from RCA, if they call the house, if you see them at the grocery store, you say we’re working on a two-chip semiconductor replacement for custom printed circuit boards for control of equipment. We’re not working on… don’t even mention computers, OK?’

“And my mother, bless her heart, the schoolteacher, who’s not really into this technology, she says, ‘But aren’t they going to realize that you’re talking about a computer and a memory?’ 

“I think, ‘Way to go, Mom. You’ve been paying attention.’

“And my father says, ‘No, because everyone in the computer division at RCA thinks of computers as rooms full of equipment with lots of things attached to them. And they can’t imagine them ever being small.’ And then he paused and said, ‘And anyway, they’ve been moving everyone up to Marlborough, Massachusetts from the computer division, so anyone who worked with computers and may have known that computers could get really small is either in Marlborough, Massachusetts or has left the company looking for another job. So, there’s nobody left.’”

This subterfuge lasted only a few weeks, as Joyce Weisbecker explained:

“And the great thing is, that is such a great story, that to this day, people think that lasted a long time. But two or three weeks later, my father comes home and says, ‘I just got a really great call from Jerry Hertzog again. He called just before lunch. He said he just got out of a meeting. And it was, you know, a standard status report on something. And [Herzog] says, ‘And at the end, one of the RCA managers points to a piece of paper and says, can we do something like that? I look at it, and it’s a computer on a chip. And I say—Joe, you’d be proud of me—I put on my best poker face and I said, ‘Well, yeah, I guess we could. The guys in the labs are working on something that we might turn into something like that, if you wanted to fund it and you want me to put more people on it. And the end result is, we are now officially working on a microprocessor and the great thing is I don’t even think they realize they asked for a microprocessor. They just asked for a chip like that… I don’t even think they realize they’ve authorized a computer on a chip. But they don’t have to know…

Joyce Weisbecker concluded this part of the story by saying, “So yeah, for two or three weeks they were undercover. But it’s such a great story that people love to tell it like it lasted forever.”

Those conversations between Herzog and Joe Weisbecker took place around Thanksgiving in 1970. Joe Weisbecker transferred to RCA Laboratories in January 1971 and started to develop a CMOS microprocessor based on his System 00 computer design. Herzog assigned some of his IC design people to work with Joe Weisbecker to implement the System 00 in CMOS, and that was the beginning of RCA’s COSMAC microprocessor development.

The IC design project first resulted in a two-chip microprocessor, the 1801, because RCA’s 10-micron, metal-gate CMOS technology could not fit the entire design on one chip. The 1801 chip designs were completed in 1971 by Norm Swales at RCA’s Palm Beach Gardens Division, and prototype chips were being sampled internally by 1972, but RCA wouldn’t announce commercial availability of the two-chip 1801 microprocessor until 1975.

Norm Swales of RCA’s Palm Beach Gardens Division in Florida laid out the original two-chip 1801 microprocessor in 1971. He’s holding the completed pair of chips in his right hand and the much larger 1801 breadboard in his left hand. Image credit: RCA Engineer magazine

These two-chip 1801 samples (internally called the TC 1084 and TC 1085) were then used to build somewhat expanded versions of Weisbecker’s System 00. They’re called FRED systems, an acronym developed by Joe Weisbecker to describe the computer systems based on his processor design including the original System 00. “FRED” stands for “Flexible Recreational Educational Device.” Over time, many FRED systems are built. These systems evolved over time, so there’s a FRED, a FRED 1.5, a FRED 2, a FRED II, etc. RCA engineers used these early FRED systems to develop software for the COSMAC microprocessor.

RCA expected that advancing CMOS manufacturing technology would eventually allow the two-chip 1801 microprocessor to be made as a single-chip device. That was the plan from day one. The needed semiconductor design advances came quickly in the form of a new CMOS topology called Closed COS/MOS Logic (C2L). (“COS/MOS” was RCA’s trade name for its brand of CMOS logic.) 

C2L made several modifications to RCA’s existing 10-micron, metal-gate CMOS layout and process techniques including the replacement of metal gates with polysilicon gates, a topology that surrounded the CMOS transistor’s drain with the polysilicon gate, and the replacement of doped guardbands around individual transistors with source planes that served multiple transistors. According to a short paper that RCA’s Andrew Dingwall and Roger Stricker presented at the 1976 IEDM (International Electron Device Meeting), C2L delivered 4x to 5x better packing CMOS density without a lithography shrink.

In addition to the C2L optimizations, Swales used a technique he called “bit-slice design” to further reduce the footprint of the COSMAC microprocessor. Joyce Weisbecker’s description makes this version of bit-slice design sound like macrocell optimization. Instead of wiring individual flip-flops, latches, and gates together with aluminum interconnect on the chip, Swales designed optimized one-bit-wide versions of large structures including the register file and ALU, and then concatenated the macrocells to create the full structures with the desired bit width. This approach further reduced the amount of real estate by optimizing the structures’ transistor and interconnect layouts.

As a result of these advances, RCA shrank the real estate requirements of the COSMAC architecture from the 1801’s 120,000 square mils spread across two chips to 40,000 square mils consumed by the single-chip 1802. That’s a 3x reduction in silicon real estate. At the same time, RCA’s chip designers were able to add 10 or 15 percent more functions to the 1802’s implementation. Norm Swales laid out the 1802 using C2L. Samples of the 1802 were available internally by 1975, and RCA announced the chip in February 1976.

The RCA 1802 single-chip microprocessor chip photo. IEEE Spectrum put the CDP1802 in its Chip Hall of Fame in 2018. Image credit: Paul Rautakorpi/Wikipedia 

Joe Weisbecker was now ready to realize his true ambition: getting his microprocessor into the hands of hobbyists, students, and small business entrepreneurs. To that end, he left further development of the COSMAC microprocessor and related ICs to the chip designers and turned his attention to developing the software and development kits needed to popularize the microprocessor’s architecture.

See all three articles in this COSMAC series:

COSMAC: The Long, True, and Never-ending Story of the World’s First CMOS Microprocessors, Part 1

COSMAC: The Long, True, and Never-ending Story of the World’s First CMOS Microprocessors, Part 2

COSMAC: The Long, True, and Never-ending Story of the World’s First CMOS Microprocessors, Part 3