Architecting High-Performance Embedded Systems: Design and build high-performance real-time digital systems based on FPGAs

Okay, so let's unpack this. It is Thursday, February twenty sixth, twenty twenty six, and today we are going to look at something that is literally all around.

You right now, well absolutely everywhere.

Yeah, Like it is probably on your mist it's definitely in your pocket, it's in your car, and it might even be in your toaster. But you never really.

See it, right, which is I mean, that's the mark of a good design, right, If it's working perfectly, it's completely invisible. It's kind of the dark matter of the digital world.

The dark matter. I love that exactly. So we are doing a deep dive today into the invisible digital infrastructure that basically runs the modern world. We are talking about embedded systems and to guide us through this absolute maze of you know, wires and logic gates, we're doing a deep dive into the source material here, which is the book Architecting High Performance Embedded Systems by Jim Leaden.

It's a fantastic resource.

It really is. Now. I have to admit, when I first saw the title, I thought, well, I thought, okay, this is going to be a super dry technical manual.

Sure, yeah, it sounds like one.

Right, but it's actually a beast of a book. I mean it covers everything from the literal physics of sensors all the way up to computer chips that can basically rewire themselves on the fly.

It is a comprehensive guide for sure. And what I really appreciate about Lenins approaching this book is that he doesn't just treat these systems as well as like small computers. He really emphasizes the immense complexity and the precision that's

Yeah, the environment is brutal. So let's start with the basics for you listening, what actually counts as an embedded system? Because I feel like that term gets thrown around a lot, like I have a laptop, I have a smartphone, I have a car. Are they all embedded system?

It's a really great question to start with. The core definition Leaden gives is pretty specific. An embedded system is digital processing that is integrated into a device that has a larger purpose beyond just computing.

Well, okay, unpack that a bit, a larger purpose beyond computing.

Yeah, so think about your laptop. Its entire purpose is to compute. It is a general purpose machine. Right. You can use it to write a novel, you can edit a video, you can calculate a giant spreadsheet. It's flexible. But a car, a car's purpose is to move people from point A to point B right to drive exactly. The computers inside the car are just there to facilitate that physical movement. They are specialists.

Okay, So the laptop is the jack of all trades and the embedded system is the master of one.

Precisely, And Lettin uses a really great simple example to draw the line here. He calls it the toothbrush test.

The toothbrush test. Okay, I love this. Break it down.

So take a standard electric toothbrush from say, maybe twenty years ago. Bat a motor and the little physical switch you turn it on, the circuit closes, the motor spins, and you brush your teeth. Is that an embedded system.

I'm gonna guess. No, I mean it's just it's electric, right, It's just mechanics and a battery.

Right. There is no digital processing happening. It's just dumb logic.

Right.

But take a modern smart toothbrush, the kind that lights up red if you press too hard against your gums.

Oh yeah, I have one of those. It actively gets angry at.

Me exactly, and that anger requires intelligence. It has a physical sensor to measure pressure. That sensor feeds analog data to a tiny micro controller okay, and then the micro controller processes that data and mathematically decides, hey, that is too much force. I need to turn on the red led and slow down the motor.

That whole loop, that is an embedded system. It is a layer of digital thinking tucked inside an everyday object.

Wow. And unlike my laptop, which, let's be honest, I have to reboot like once a week because it just gets confused. Yeah, things have to be incredibly robust.

That is the other massive key distinction here. These systems don't usually have nice cooling fans. They have to survive intense vibration, dust, wild temperature swings.

Because they're in the real world. Exactly. Think about it. If your laptop crashes, you lose an unsaved word document annoying, but fine. If the embedded system in your car is anti lock breaking, unit crashes, oh man. The consequences are physical and they are immediate.

That makes total sense. And this naturally bleeds into I think the biggest buzzword of the last decade, which is the Internet of things or IoT because once you have that smart toothbrush, the next logical step for a company is to make it talk to your phone. Right.

That is the natural evolution, and let draws a very clear line there in the source material. Embedded systems evolve into the Internet of things when they start communicating with central nodes. It's all about massive network communication.

The book mentions some examples that really show the sheer scale of this. On one hand, you have everyday stuff like smart speakers, your Amazon Echo, Google Nest sitting in your living room just waiting for a wake word.

Right, an admitted system that's listening, processing audio locally, and then communicating with the cloud.

But then you connect that same concept to the industrial side. Think about an oil pipeline. You have embedded systems monitoring flow rates, pressure and temperature over thousands of miles of pipe exactly.

So instead of a guy in a truck having to drive out into the middle of nowhere to check a physical gauge.

The pope itself basically sends a text message saying, Hey, I'm leaking.

Yes. Yeah, it's incredibly efficient, but this is a big butt. The book issues a pretty stark warning here regarding security. Oh absolutely, because when you take a device that was originally designed to be a simple, isolated specialist, like a home thermostat or a pipeline valve, and you suddenly give it a live Internet connection, you are opening a door.

And historically these things aren't exactly built with Fort Knox level security, are they No.

Historically they are not. And that's exactly the danger. If a malicious actor hacks your personal laptop, they might steal your credit card info. That is bad, obviously, but it's manageable. But if they hack an IoT system like a medical pacemaker or that oil pipeline we mentioned, or the steering control of a connected car, we aren't talking about data loss anymore. We are talking about severe risks to physical safety.

It's the difference between a privacy nightmare and a literal safety crisis.

Yeah, exactly. Leaden emphasizes that in this new IoT world. Security cannot just be a software pass you add on later. It has be baked into the very architecture of the hardware from day one.

It's terrifying but also fascinating. Okay, let's step back a bit and look at how these systems actually interact with the physical world. Because a computer chip, at the end of the day only knows ones and zeros. It doesn't know what hot or fast or loud actually feels like. It lives in this dark digital bubble.

And this is the realm of sensors. This is how the system literally senses the outside world. Letting categorizes them into two main buckets in the book that are super helpful to understand, passive and active sensors.

Okay, passive sounds a bit safer. What is a passive sensor?

A passive sensor just sits there and measures the environment exactly as it is. It's observant. A classic example he gives as a thermister. A thermister, Yeah, it's a special type of resistor that changes its electrical resistance based on the ambient temperature. It's not doing anything to the air around it. It's just reacting to the heat.

Okay, so kind of like a sponge soaking up water. It changes its state based on the environment, but it doesn't spray water back out.

That's a great analogy. Now contrast that with an active sensor. An active sensor actually goes out and pokes the world to see what happens.

It pokes the world.

Well in a way. Yes, think about an ultrasonic sensor. These are used a lot in robotics and in the parking sensors on your car bumber.

Oh, the ones that beep when you get too close to a wall.

Exactly, that sensor actively sends out a ping, a high frequency sound wave. Yeah, and then it immediately switches into listening mode and waits to hear the echo bouncing back like.

A bat using echolocation or submarine.

Exactly like that. It uses a concept called time of flight. The system knows the exact speed of sound, so it sends the ping out, starts a tiny internal stopwatch. Here's the echo return, and stops the watch.

Oh, and then it just does the math.

Right, the time it took tells you exactly how far away the physical wall is. That is active sensing. You generate a stimulus and you measure the real world response, and.

The source material mentions lightar and radar working on similar principles.

Right, Yes, lightar is completely fascinating. Instead of sound waves, it uses pulses of laser light. By spinning that laser around and measuring millions of those time of flight returns every single second, an autonomous vehicle can build what's called a point clide a point cloud. Yeah, it's basically a real time three D map of the entire world around

That is just incredible. But here is where it gets really technical and honestly, I think really interesting. The real world is analog like. Temperature doesn't just jump from seventy degrees to seventy one degrees in a single instant step. It flows smoothly, it's continuous, right, But computers are digital. They only understand distinct steps. They're choppy. So how do we bridge that gap between a smooth world and a choppy computer.

That crucial job falls to the ADC. The analog to digital converter. It acts as the ultimate translator. Imagine you are drawing a smooth, sweeping curve on a piece of graph paper.

Okay, I'm picturing it.

The real physical world is that smooth curve. The ADC is looking at that curve at very specific tiny points in time. This is called sampling it, and it's turning each specific point into a precise digital number.

So if you don't sample it fast enough, you miss all the details of the current exactly.

That's a problem called aliasing. If you blink too slowly, you might miss the baseball flying right past your face. The source material talks about the XCDC hardware on the RDA seven board.

Right, the RDA seven, which is a specific FPGA development board they use as an example.

Yes, that specific hardware can sample the analog world up to one million times per second.

One million times a second. That is, I mean, I can't even wrap my head around that.

And honestly, that's just considered standard for high performance control. Some advanced radio frequency systems sampled into the billions of times per second. It creates this absolutely massive fire hose of numbers that the processor then has to crunch.

Okay, so we have the data. Now, the sensor has picked up the physical world, the ADC has translated it into digital numbers. Now, how does that data actually get to the main brain of the system. We need a nervous system.

We absolutely do. And these are called the communication protocols. Depending on exactly what you're trying to do, you pick a different digital language.

Let's run through the big ones mentioned in Letin's book. Start with the absolute simplest one GPIO.

Okay, GPIO General purpose input output. This is basically the brute force method. It's usually just a single wire that is either on or off high voltage or low voltage.

One or zero, kind of like a physical light switch.

Perfect analogy is the machine's safety cover open, yes or no? Is the emergency button currently pressed? Yes or no? It's incredibly fast, it's instant, but it obviously doesn't carry complex data. You can't send a JPEG image over a light switch.

Right, Okay, So what if we do need to send actual complex data. The book talks about a protocol called I two C.

I two C or inter integrated Circuit. I always like to call this one the polite conversation.

Polite Why polite?

Because it uses just two wires. One wire is a clock to keep the timing synchronized and the other is for the actual data. But it can connect multiple different devices using a clever address system. It uses a master servant architecture. Okay, so the master controller says, hey, Sensor A, it's your turn to speak, and Sensor A talks. Then the master says, okay, thank you, Sensor B, now it's your turn.

Ah, So they actually take turns on the wire.

Yes, it's what we call half duplex. You can only send data or receive data at one specific time, not both. It's great for simple things like reading a temperature sensor once a second, but it's a bit slow.

So what if I have a real need for speed, like if I'm streaming that crazy one million sample per second data from the ADC, then you.

Need to upgrade to SPI Serial Peripheral Interface. This is the speedy connection. It uses four wires instead of two, and because it has completely separate dedicated wires for sending and for receiving, it is full.

Duplex, meaning it can talk and listen at the exact same time exactly. Sounds like a chaotic argument where everyone is just yelling over each other.

Actually, it's more like a highly efficient high speed telephone call where both people are talking and perfectly understanding each other simultananeously. It can run much much faster than it two see easily up to fifty mega herds for more wow.

Okay, but what about inside cars? Because I know modern cars are an absolute nightmare of electrical noise. You have spark plugs firing thousands of times a minute, giant alternator spinning that creates massive electromagnetic interference.

Very hostile environment for electronics.

So how do the tiny computer chips communicate without their data just getting completely scrambled by all that engine noise?

That is exactly where the CANbus comes in the controller area network. It is the absolute gold standard for automotive systems, and the way it physically handles that noise is just brilliant physics.

Okay, how does it work.

It uses something called differential signaling. Imagine you have two separate wires running right next to each other through the car. When the system wants to send a signal, it sends a positive voltage down one wire and a negative voltage down the other wire.

Okay, so like a plus one on the first wire and a minus one on the second wire.

Right now, the receiving chip at the other end doesn't look at the absolute voltage on either wire. It strictly looks at the difference between the two wires. So positive one minus negative one equals two. The intended signal is two.

Okay, I follow the math.

Now, imagine a huge spike of electrical noise from the engine suddenly hits those wires. Because the wires are physically twisted together, the noise hits both wires equally. Right, Let's say it adds ten volts of pure noise, So the plus one wire becomes plus eleven and the minus one wire becomes plus nine.

Ah, so both numbers instantly jump up.

They do, but the receiver only cares about the mathematical difference between them, and eleven minus nine is still two.

The signal is perfectly preserved exactly.

The noise literally cancels itself out. It is an incredibly robust design. That is exactly why your anti lock breaks still work perfectly even when your engine is screaming at the red line.

That is so smart. It's just elegant engineering.

It really is. And there's one more very cool thing about cambus. Unlike it two C, there is no master controller. It's entirely peer to peer.

Wait, so who decides who gets to talk? If there's no master it sounds like it would be chaos.

The priority is actually built directly into the message ID number itself. If it deploy breaks message and the turn up radio volume message both try to talk on the network at the exact same millisecond. The system is physically designed so that the breaks have a lower ID number, and on a canvas, a lower number mathematically wins out and gets higher priority.

That is amazing. The radio automatically just shuts up and waits yep.

The physics of the wire forced the lower priority message to back off.

I honestly wish human conversations worked like that, Like important safety info just mathematically overrides small talk.

It would definitely make office meetings a lot more efficient.

No kidding, Okay, So we had our sensors and we have the nervous system protocols. Now, let's talk about the brain. And this is where the book really focuses heavily. We aren't just talking about normal CPUs here, we are talking about FPG.

Yes, this is where the engineering gets really interesting. FPGA stands for field programmable gate array.

Field programmable makes it sound like I can literally fix it while I'm standing out in a cornfield.

I mean, basically, yes, it means you can completely change how the physical chip works after it has already been manufactured and deployed in the field.

How is that fundamentally different from a normal computer processor like the one in my laptop.

Well, a normal CPU like an Intel or AMD chip has a totally fixed hardware structure. It is etched in silicon. It reads software instructions one by one from memory. Add this number, then move this data, then check this condition. It operates sequentially right, one step at a time, exactly. And FPGA, on the other hand, is basically a blank box of digital lego bricks. Raw logic gates, memory blocks flip flops. When you program it. You don't write software

Wait, I'm physically well electronically changing the actual circuit.

Yes, you are literally creating custom hardware on the fly.

Let's break down those lego bricks you mentioned. The book talks a lot about logic gates.

Right, These are the fundamental decision makers of the digital world. You have eighty gates which say if input A andy input B are true, then do this. You haver gates, exoor gates, and then you have flip flops, which act as high speed memory units. They hold a single bit of data for a split second based on the ticking of the system clock.

And a single FPGA is just made of millions of these little gates, millions.

Of them, and because you are wiring them all up yourself in whatever pattern you need, you unlock the FPGA's true superpower parallelism. Parallelism that is definitely the key word here. Think of a standard CPU as a genius level math professor. He can solve absolutely any problem you give him, but he can only solve one problem at a time. He is very fast, but he's working entirely alone. Okay, And FPGA is more like a giant room flow of ten

So if I'm processing an image that has a million pixels, the normal CPU has to look at pixel one, then pixel two, then pixel three exactly.

Even if it does it fast, it's still sequential. The FPGA, however, can be wired to look at all one million pixels, simultaneously process every single one of them, and be completely done in a single tick of the clock. That is true hardware acceleration. It's not just about running faster, it's about doing everything at once.

That honestly blows my mind. But you don't use regular programming languages like Python or C plus plus to program these things, do you.

Well? You can use C plus plus with some newer high level synthesis tools now, which definitely helps. But underneath it all the native tongue of the FPGA is VHDL or verolog. These are hardware description languages.

Hardware description.

Right when you type in violog, you aren't writing a sequential to do list for the computer. You are describing a physical structure. You are telling the software I need you to connect this wire to that specific gait.

It's drawing architectural pootprints, not writing a recipe.

Perfectly put, it is hardware design, just done at a keyboard.

So we have this amazing custom hardware brain. But there is one more massive constraint that Leaden really hammers home in the book, and that is the concept of real time.

Yes, and this is a concept that is so often misunderstood. Real time does not just mean really fast. A supercomputer taking three days to predict the global weather is incredibly fast, but it's not real time. Real time means computing with the strict deadline.

A deadline like it has to be done by a certain millisecond.

The mantra of embedded engineering is the system must be functionally correct, meaning it gets the right math answer, and it must be temporarily correct, meaning it gets that answer at the exact right time. If the right answer arrives late, it is a wrong answer.

The book distinguishes between hard and soft real time systems. What are the stakes here?

Soft real time is low stakes. The classic example used is a car keyfob. You walk up to your car, you press the unlocked button. If the system takes two seconds to unlock the door instead of point one seconds, you might be annoyed.

Right, you might angrily press the button this second time.

Exactly, but the system hasn't catastrophically failed. No one is hurt. It just lag right. But hard real time think about the airbag controller in that same car. If you can do a crash, the sensor detects the sudden impact, the processor has to calculate the force and physically fire the air bag. If that system deploys the air bag even one hundred milliseconds.

Too late, it's entirely useless. Or even worse, it deploys right as your head is moving forward and actually hurts you exactly.

That is a total system failure. In hard real time engineering, missing the deadline by a fraction of a second is literally the exact same thing as the computer completely crashing.

This has to create a huge challenge for the programmer, doesn't it. Because the process is usually doing a dozen things at once. It has to check the sensors, It has to update the dashboard display, it has to talk to the CAN network. How do you guarantee that the life or death stuff happens first?

That is known as the scheduling challenge, and the book discusses this in great detail. I imagine you have an electric motor that needs its voltage adjusted fifty times every single second, so fifty hertz, just to run smoothly without burning out. But the processor also has a display screen that it needs to update ten times a second.

And if the display update takes just a little bit too long to draw the graphics.

The motor doesn't get its critical voltage adjustment on time. The motor physically stutters. In the industry, that's called jitter. Yeah, and jitter is the absolute enemy of real time systems.

Jitter just the word makes me anxious. So how do engineers fix it?

The standard solution is using an RCOs, a real time operating system. It's a highly specialized operating system that acts like a completely ruthless traffic cop. Yeah. It manages all the system priorities using some they called preemptive multitasking.

Preemptive meaning just violently interrupts whatever is happening ruthlessly.

If the motor control task suddenly says, hey, it's my exact millisecond I need to run right now, the RTOS instantly pauses the display update task right in the middle of drawing a pixel. Let's the motor code run, and then it resumes the display. It doesn't ask permission. It absolutely ensures the heart deadlines are met, even if the soft deadlines have to wait a microsecond. M Wow.

Okay, So bringing this all together, we have gone on quite a journey here. We start from a physical change out in the real world, a temperature rise or a brake pedal being pressed. Right, that physical change becomes an electrical signal through a sensor. The ADC translates that analog wave into digital numbers. Then those protocols, the ITCDESPI, the can bus zip that data safely through the nervous system.

Honestly, when you summarize it all put together like that is kind of a miracle that anything in our modern world works at all.

It really is. It completely changes how you look at everyday things. When I go out and unlock my car door today, I'm not just opening a door. I am triggering a massive, silent symphony of physics, electrical engineering, digital logic, and perfect timing.

And that is the true AHA moment for me. When studying this stuff. We look at a car or a smartphone and we just see a single solid object. But underneath the metal and glass. It's actually a high speed conversation between hundreds of tiny specialized computer systems, all shouting at each other in perfect synchronization.

Before we wrap up today, I really want to leave you the listener with a provocative thought that struck me while reading the source material about FPGAs. We are so used to the idea that hardware is hard it's the physical, unchangeable silicon chip, and that software is soft it's the code you can easily update.

Right, That's the classic divide.

But with FPGAs we are literally rewriting the physical circuit layout on the fly, we are downloading hardware.

It raises a really fascinating question.

About the future, right, like, where does the line between hardware and software actually exist anymore? If I can just download a file from the Internet that fundamentally changes the physical electrical pathways of my computer chip, essentially downloading an entirely new computer architecture over Wi Fi, are we entering an arrow where the hardware itself is just as fluid and temporary as the code running on top of it.

That is the absolute frontier of embedded design, And as these systems get more connected and more complex, that dividing line is only going to get blurrier and blurrier. The rigid static hardware of the past is very quickly becoming a memory.

Definitely something to mull over the next time you are standing in the bathroom waiting for your smart toothbrush to perform a firmware update exactly Well, that is it for this deep dive into the invisible infrastructure of our life vibes. Thanks so much for listening.