Pathological Design Features: Eric Bogatin on PCB Design

Dr. Eric Bogatin, Dean of Signal Integrity Academy is back for some awesome discussion about bad PCB design guidelines. How to spot them to avoid ruining your design? This is going to be fun and insightful! Make sure to check the show notes and additional resources below. Watch until the end, our favorite Dean has some perks for our listeners.

Listen to the Podcast:

Download this episode (right click and save)

Watch the video:

Show Highlights:

• Eric’s AltiumLive Presentation
  • Pathological Design Features
  • Demonstration of the 2D Field Solver built-in for free in Altium Designer
• Your intuition + PCB design tool can make or break your PCB design performance
• Most Common Sources of Noise
  • Ground bounce as an extreme case of crosstalk
  • Design structures that can strongly contribute to EMI failures
• Eric Explains “transparent interconnect”
• Best measurement practice and routing correctly
• Is an Arduino board really for beginners?
• EMI Problems cause by split planes—the trifecta, you get reflection noise, you get crosstalk noise, you get EMI noise out of it
• Eric Bogatin, Steve Sandler, and Larry Smith debunked PCB design myths and legends—the Myth of Three Capacitor Values
• Power integrity becoming Signal Integrity
  • What is Rad-hard?
  • Reliability concerns in aerospace technology and automotive systems
  • Fiber in vehicle and fiber base radar could be the solution
• Eric answers, What do you think about right-angle traces?
• 3 Month Signal Integrity Academy Subscription, use promo code ALT21
• AltiumLive Connect, register now!

Links and Resources:

• Article: The Myth of Three Capacitor Values 
• Signal Integrity Journal
• Laboratory for Atmospheric Space Physics
• Should You Worry About 90 Degree Bends in Circuit Board Traces?
• Previous Podcast Episode with Eric Bogatin
  • Why You Should Stop Hanging on to Legacy Design Rules
  • Eric Bogatin Debunks Common Misconceptions About Transmission Lines
  • Signal Integrity Expert Eric Bogatin on Best Measurement Practices
• AltiumLive 2022 Connect: Now open for registration
• Connect with Zach Peterson on LinkedIn
• Connect with Eric Bogatin on Linkedin
• Watch Zach’s latest Altium Academy courses on Youtube
• Read Zach’s articles on Altium’s resource hub

Full OnTrack Podcast Library
Altium Website
Download your Altium Designer Free Trial
Learn More about Altium Nexar

Altium 365: Where the World Designs Electronics

Transcription:

Eric Bogatin:

I should have used the word pathological in the title, now that I think about it, but it'll be pathological design features that can ruin your day. That's going to be the keynote. In fact, if it's not... Now that I'm thinking about it, maybe I will try to grab Judy and change the title to Pathological Design Features. But it's going to be really bad design guidelines. Don't do this in your design.

Zach Peterson:
Thank you everyone for joining us and welcome to the OnTrack podcast. I am here with Dr. Eric Bogatin, who is a well-known speaker at many Altium Lives and in many other outlets within the industry. I think I first saw Dr. Bogatin speak at PC US 2019, and it was a very enlightening discussion. He threw lots of pieces of candy at me after answering his questions. So definitely a great person to go out and see speak if you have an opportunity.

Judy Warner:
Welcome to Altium's OnTrack podcast, where we talk to leaders about PCB design, tackling subjects ranging from schematic capture all the way to the manufacturing floor. I'm your host, Judy Warner. Please, listen in every week and Subscribe on iTunes, Stitcher, and all your favorite podcast apps. And be sure to check out the show notes at altium.com/podcast, where you can find great resources and multiple ways to connect with us on social media.

Zach Peterson:
Dr. Bogatin, thank you so much for joining us on the podcast.

Eric Bogatin:
Hey Zach, it's always a pleasure to join you guys on your podcast.

Zach Peterson:
Well, I will do my best to commandeer this thing until Judy gets back. She is busy planning Altium Live at the moment, and I know that you are going to be speaking at Altium Live again this year. Just recently, I was watching your talk from Altium Live 2020, the virtual session and very cool stuff, obviously. I'm interested to hear about what you're going to talk about in this coming Altium Live.

Eric Bogatin:
Yeah. Let's see. I think I'm going to do two presentations. I always enjoyed coming to Altium Live when it's been live, and then even when it was virtual because it's such a great opportunity to be around enthusiastic users of Altium tools. It's a very friendly, very good audience to participate with. Let's see. I think I'm going to do a keynote on some of that about how noisy designs can be if you're not careful in the design guidelines. And I always say that that if you look at a schematic, a schematic tells you about how the terminals are connected and what components you've got there. But when you translate the schematic to a layout, the schematic doesn't tell you anything about how the interconnects themselves behave. And so when you create the layout from the schematic, that's when you have to pay a lot of attention to the role interconnects play in the system.

And interconnects will only screw things up. They will only introduce noise. They can never improve the performance of what the ICs and the active devices can do. So it's really about interconnect design, and the layout is really about what can you do to reduce the noise. And I'm going to look or demonstrate a couple of what I've come across as the most common sources of noise, where you can have so much noise, it will break your system. And I think one of them is going to be... I'll probably start off with some ground bounce examples because ground bounce can grow because of the shorter rise times, the more IOs that switch. You can easily see ground bounce in the vault range. And then I'm probably going to look at near-field emissions from a good and bad design that can contribute to FCC certification, EMC failures.

That'll be about out some extreme... Maybe I should have used the word pathological in the title now that I think about it, but it'll be pathological design features that can ruin your day. That's going to be the keynote. In fact, if it's not... Now that I'm thinking about it, maybe I will try to grab Judy and change the title to Pathological Design Features. But it's going to be really bad design guidelines. Don't do this in your design. And then I'm doing another technical session to walk through how to use the built-in 2D Field Solver in Altium in order to do stackup design because it's a really cool feature. I use it all the time. I make my students use it. Really easy to use and I think as a really powerful addition to Altium Designer that I think more engineers should know about.

Zach Peterson:
Yeah, I definitely agree about the layer stack manager. I use that tool all the time. One of the designers that works for me uses Polar as well. If the client demands Polar that we use Polar, go with their results, that's fine. But we generally use the Altium tool. I think it's the best.

Eric Bogatin:
Yeah. Polar, they have a great 2D Field Solver tool. I featured that a lot in the last book I did with our tech on transmission lines, really easy to use, you get a lot of stuff with it. If you don't have Polar, I think more Altium users should know that there is a really good 2D Field Solver built-in for free in Altium. And that should get more visibility, more usage.

Zach Peterson:
Yeah. It's funny because like you said, it's in there. It's not like it's hard to find. There's a little tab at the bottom that says Impedance. But one of the questions that I see sometimes is, "Well, how do I figure out... If I change the width and I don't know intuitively what I need to do to the stack-up to accommodate that, where do I figure that out? Is there a tool in Altium?" And then I'm always replying with links. Well, go learn about the layer stack manager.

Eric Bogatin:
Yeah. And you said the key thing is you have to have some intuit. I think it's important to have that intuition about what do you expect? If the line gets wider, what's going to happen to the characteristic impedance?

Zach Peterson:
Exactly.

Eric Bogatin:
So if you're not familiar with characteristic impedance and how the geometry affects it, it's hard to have that intuition. But I think before you use the stack-up tool or any other tools, you should have a little bit of that physical intuition of how design is going to affect performance. And then you use the tool to put in the numbers to give you that couple decimals, to do the actual optimized design.

Zach Peterson:
Yeah. I totally agree with you. I think that if someone just jumps in and they don't... It's as simple as changing a number. You're changing a laminate thickness or you're changing a width. Maybe you're changing a copper weight. But let's say you go to change the laminate thickness. If you change it the wrong direction and you don't have that intuition, you're going to start thinking, well, what's wrong with this tool? Or does that mean everything I know is wrong? And you know, that's-

Eric Bogatin:
Yeah. Or maybe you're typing in 17 and you meant 71, you didn't notice that. I'd make that mistake. So the number comes out. So many of these tools, I always say it's really easy to get a number. It's hard to get a number without artifacts. And having that idea of what to expect, that's what I call Rule Number Nine, having that anticipation of what to expect is such an important check on how you're using a tool.

Zach Peterson:
Yeah. I totally agree with you. When you brought up the most common sources of noise, you brought up two good ones, which was ground bounce, and then EMI. And I was going to say the third one that you were going to bring up was crosstalk. Are you also going to show some interesting results with crosstalk? Because I remember in one of your sessions, students design a little 5, 5, 5 timer. And you encourage them to do design less than optimal, let's just say. And you can see the crosstalk on a blinking LED. Are you going to show some more results with that?

Eric Bogatin:
Yeah. I kind of lump crosstalk as an extreme case... I'm sorry, ground bounce as an extreme case of crosstalk. And I'll tell you the punchline. It's return path discontinuities. If you have a nice wide uniform plane, you won't see ground bounce at the board level, you'll see it in the packages and connectors, but not necessarily at the board level. But if you screw up that return plane and then you see it at the board level. And it can literally be orders of magnitude increase in noise. We'll definitely be talking about crosstalk. When you look at the different sources of noise that interconnects can create, some of them are based on reflection noise, and terminations, and that kind of thing, crosstalk, and then the rise time degradation because of the losses in the lines and jitter and collapse of the eye. And then the fourth is EMI. And so I was only going to hit the big ones, the real serious pathological ones, ground bounce, which is extreme crosstalk, and then design structures that can strongly contribute to EMI failures.

Zach Peterson:
Sure. Yeah. I think these are all really important topics within really at all levels of the design, but especially when you're starting to deal with designers who maybe have different levels of experience. So the new designers, this is something that I think in the past was at the edge. It was something you dealt with as an exception and not the norm. And then now, with even so many simpler devices running at edge rates that are fast enough to produce some of these problems, it is now the norm. I'm wondering if you get a sense or if you have some experience working with students, possibly, who have experienced these problems, and then they're just unsure of what to make of it until they maybe interact with you.

Eric Bogatin:
Yeah. That's a really good point. I teach an upper-division and graduate class on printer circuit board design. And I get students that... So see, we're pretty heavily into projects. Students get involved in building things early on. Freshman year, there's a project design class. I'm teaching the senior design class right now. And throughout their curriculum, they'll often get involved in projects and sometimes they'll do printer circuit boards. And so I'll get students in my class that have maybe built a board two or they've seen boards and it is remarkable. And I know that none of the Altium professional users out there would ever do this, but my students that don't have a lot of experience, they haven't gotten feedback on the design, they just naively design a board, the vast majority, they just naively design a board, design a board with no ground bounce.

The vast majority of... It's literally taking a design that you would have in a solderless spread board with connections and wires going everywhere and implementing that in a printer circuit board. And for a lot of the simple designs that they do, it works because the interconnects are transparent. And so I try in my PCB class, I teach them the good habits, but I also try to get them involved in circuits where the interconnects are not transparent. And you exactly mentioned it, the example that I show. Yeah.

Zach Peterson:
Real quick. When you say transparent interconnect, I assume you mean electrically short.

Eric Bogatin:
Well, electrically short is part of it. That just means it doesn't behave like a transmission line, but it's also, doesn't the noise that you get... Because the inductance in the leads, the rail collapse, the IDT, that the noise that you get doesn't depend on the interconnects. You can literally... And my rule of thumb is if you can build your product in a solderless breadboard with jumper wires and it works just fine, the interconnects are transparent. Doesn't matter how you design the circuit board. And generally, that's how a lot of these students have built their boards. They've never gotten the feedback, they've never gotten the experience of what happens if interconnects are not transparent, if the design of the interconnects influences the noise. Yeah.

Zach Peterson:
I'm assuming you're dealing with students who are at least able to route in such a way that they're not going to break an interconnect that was already made with just a wire.

Eric Bogatin:
Yeah. Exactly. You start with the schematic and you push it over to the layout and you get all the ghost wires there. And my students are used to using simpler tools and just doing connectivity, just wires to go to make sure you don't have any ghost wires left anymore. And those designs have worked for them, but it's bad habits, number one. And number two, they will absolutely have a design in one of the next ones they do where that doesn't work. If they have a microcontroller on their board, or if they have any kind of high current drivers, then that simple, just connect the dots with wires isn't necessarily going to work. So I try to establish good habits. And then the second board that they do is a board where they route one quadrant just with wires, with no ground plane, and then identical circuit with a quadrant where there's a nice return plane. They use good design habits and they actually get to measure the crosstalk noise when they don't pay attention and then how much it's reduced when they do pay attention. And it's that-

Zach Peterson:
I see. So they've got a direct comparison on the exact same board.

Eric Bogatin:
Yeah. And it's a combination of, I also try to teach best measurement practices, because I think it's important for hardware engineers to know how to measure correctly, but they see that visceral sense of, oh my gosh, it's exactly the same circuit. The only difference is how I did the routing. And I can reduce the noise by a factor of almost 10 in some cases, by doing the routing correctly. And we use hex inverters with only a couple, maybe one or two nanosecond rise times, which is common these days. An Arduino board has a mega 328 microcontroller in it, that board that's been around forever. I heard from the microchip guys, over a million of them are sold each year, the actual board itself, the UNO Form Factor. You can buy the clones for like three bucks. That board, three nanosecond rise times. In some cases, a little less than three nanoseconds, pretty fast edges. And you can see a lot of crosstalk on those boards.

Zach Peterson:
Yeah. That's interesting because I think there's this perception that something like Arduino or maybe another microcontroller board, it's going to be one of those things where it's supposed to be simple. So why would you have to worry about these things that seem really advanced or really complex? But I think it just underscores that issue where those things actually are the norm, even in something that is supposed to be a beginner's like an Arduino.

Eric Bogatin:
Yeah.

Zach Peterson:
And I think for many designers, that definitely is the beginning of the process.

Eric Bogatin:
Yeah, you're absolutely right. We also build an Arduino board as one of the test boards and we compare it to the commercially available boards. And if you look at the commercially available boards, and that's one of the exercises we do is I have them... Once they understand what the good design practices are, we look at one of the commercial Arduino boards and I have them make a list of five things they're doing wrong. And then we compare the noise on the commercial board with the noise on their board that they've done correctly. And the biggest difference surprisingly is... So bottom line is, look, the Arduino is an incredibly robust design. So five-volt logic, it tolerates a lot of noise, but if you know how to measure it, you'll see a lot of noise on the board, but it still works.

But surprisingly, the biggest difference between the commercial board and the board they build is from the emissions. And I'm going to show this at an Altium Live that the commercial boards because they use split planes all over the place and they use copper fill everywhere, they think they're doing a good thing by using copper fill, but they're not careful in how they do the return path control. And there's more than an order of magnitude difference in the near-field emissions from the commercial board than the ones my students build with nice continuous planes. The near-field emissions are effective so low. We literally are at the limit of our poor little scopes to be able to measure it. Can't measure the near-field emissions on the boards the students make. So there's a very visceral difference.

Zach Peterson:
Yeah. It's amazing. The thing with split planes routing between plane sections, I don't know when that started. And I have heard from, I don't want to say older guys, but I will say much more experienced folks in the industry that this is something that was totally fine pre-1980s, something like this way back when before I was even alive. So it's just interesting to me that something that, like you're saying, you can measure that it doesn't work is still pushed as a standard design guideline, including when you're dealing with something like the mixed-signal and people still do it. I even see, running a design firm, I even get clients that will send in something to me for rework because it failed EMI and it failed. And what do you think the first thing I look for is?

Eric Bogatin:
Split planes.

Zach Peterson:
Split planes. Yeah. Split planes or crossing references without providing a continuous return path.

Eric Bogatin:
Yeah.

Zach Peterson:
But it's basically the same thing.

Eric Bogatin:
You're absolutely right. I think signals crossing planes, return planes are... I call it the trifecta, that you get reflection noise, you get crosstalk noise, you get EMI noise out of it.

Zach Peterson:
Yeah, absolutely. Yeah. That's funny. And I even see it in ApNotes.

Eric Bogatin:
Yeah.

Zach Peterson:
Yeah. I still see in ApNotes. And these aren't ApNotes from 1990, they're ApNotes from like 2008.

Eric Bogatin:
You must see a lot of designs come through your firm then if you get clients from outside sending you designs to fix or to start originally.

Zach Peterson:
Well, it's not a huge number, but yeah, we do occasionally get the request for rework for EMI EMC problems. And like I said, that's usually one of them. Or they will do something weird where they try and tie planes together with an inductor and then use that as a return path, not an inductor, but basically a conductor.

Eric Bogatin:
Yeah.

Zach Peterson:
And you already know what I'm talking about. And then they'll do something like, "Oh, well, we want to be able to provide a low frequency connect, or we want to eliminate DC blocking between them, or we want to provide a high-frequency return path." So then they'll put a capacitor and parallel with it. So they've just created an LC tank and then they will wonder why they're seeing this huge spike in their EMI spectrum. And it's little stuff like that where it's just like, if you would've just used the continuous return plane, to begin with, we wouldn't be having these problems.

But with dealing with EMI failures... and this kind of relates to something that you brought up in terms of using copper pour instead of ground planes, it seems like some of these recommendations are sometimes recommended either as a bandaid for a problem when they should be dealing with the cause first. Or it's just one of those things where it's like, "Well, I see everybody else doing it. So Zach, will you guys please do it?" Do you see students maybe providing the same type of justification for certain design practices? Whether or not it's copper pour or stitching vias or guard traces, I still see people recommend guard traces, this kind of thing.

Eric Bogatin:
Yeah. I think you're absolutely right. It's a combination of myths and legends that have stayed in our industry or legacy code. And I see, you mentioned one of the real common examples of the use of guard traces. My other two favorite ones are the use of copper pour on layers that have signals on them. And the third one is, I call it the myth of three capacitor values.

Zach Peterson:
That one is my favorite.

Eric Bogatin:
Yeah. And that was such a prevalent comment. And I think of all the habits my students had coming in, the one that they learn from either ApNotes or they learned it from other professionals in the industry, or I have some students that work full time and they learn it from their design community and they see it in ApNotes is the idea of using three different value decoupling capacitors of a 10, a 1, and a 0.1 microfarad. I have had classes where I show examples and I talk about the principles behind it, and I still get students that do it because they said, "Well, that's what's in the ApNote."

And so about, I think it was one or two years ago, I got together with... Larry Smith is one of my go-to experts in the industry of power integrity. He and I wrote a book together. And I spent five years once a week for two hours on the phone with him going through all the material and arguing a lot and discussing it. He won most of the arguments, but we both still learned a lot from it. So he's one of my experts. And then Steve Sandler, another industry expert in power integrity, very, very sharp guy. He assumes that everybody understands things as well as he does. And so sometimes it's a little hard for me to understand exactly what he is telling me, but he's usually right.

So the three of us, I got them together and we had long discussions about the Myth of Three Capacitor Values. And we did some investigation as to where that myth came from, where it started, why it is appropriate in some cases. And then we came to our own conclusions that it's not appropriate in modern designs. And we wrote an article in Signal Integrity Journal a couple years ago. Anybody can go to signalintegrityjournal.com and just do a search for Myth of Three Capacitors. And if you still design with three capacitors, I strongly recommend you grab that copy of that article. And we walked through where the myth came from, when is it appropriate and when is it not appropriate? Yeah.

Zach Peterson:
That's a great point.

Eric Bogatin:
Oh good.

Zach Peterson:
And actually, we're going to link to that article in the show notes. So everybody who's interested in that article, go to the show notes and take a look.

Eric Bogatin:
Yeah. It was a lot of fun working on that paper. We also had a lot of arguments. You get three experts together and you probably have four different opinions about things. But I like doing that every now and then because I find even when I teach a class I've taught for 20 times, I still learn something new when I teach it or when there's someone in the audience that challenges me or offers some other view. And so with guys like Larry and Steve, they're so opinionated about what they do and they each touch a different piece of the elephant. They have different kinds of designs they work on. So the generalizations and guidelines for one design don't always apply to another. And that helps us challenge our assumptions and we rethink. It's always a lot of fun and I always learn a lot when I work with other experts with other perspectives.

Zach Peterson:
Yeah. I love that you said that, the generalizations. I think that's what gets a lot of newer designers is a generalization of one design guideline that works fine in one specific case, but then they want to apply it to every other case. And I think there's a lot of context that surrounds some of those guidelines that often gets lost, especially if you start doing searches online, looking on forums, and then you start seeing discussions. Sometimes you'll see discussions around this stuff where one guy says, "Well, I always do this and I never have a problem." And then the next guy says, "Well, I never do it. And I never have a problem." Well, who's right? They're probably both right. It's just that the situations are totally different. And then we lose all of that content.

Eric Bogatin:
Very good. Yeah.

Zach Peterson:
I think it's great that you can get into that. And that's one of the things that I think we try and do in the articles that get posted on Altium's blog. But I see you doing that as well in a lot of the stuff that you create, especially on Signal Integrity Journal.

Eric Bogatin:
Yeah. And it's this question about it, I did it and it worked. I often say sometimes working isn't the same as margin. And if you haven't looked at the... Like I said, the only thing interconnects are going to do is introduce noise. And if you haven't looked at the noise, it may not be enough to cause the product to not work, but it could still have significant amount of noise that may be close to the edge. Just because you did something and it worked doesn't mean it worked because of what you did, it could be working in spite of what you did. And that's why it's so important to, like you said, go back to the fundamental principles and try to quantify, try to measure the impact of the noise that you have, even if it's not enough to cause an actual problem.

Zach Peterson:
Yeah. What you're really saying is that, well, yeah, it would've worked anyways. You just didn't break it.

Eric Bogatin: 
Yeah. Right. And you know what? I remember a story. I think Istvan Novak told me this. We worked at Sun years ago and this was in the early days. Larry Smith and Istvan both worked at Sun and worked very closely together and really pioneered on a lot of the design principles for power integrity. And I was running the processor modules group. And there was a story they... I think it was Istvan told it. They had built a server board with some of the modules that my group was creating with some of the modules on there. And there were like a thousand decoupling capacitors on the board. And they wanted to know how many decoupling capacitors did they need. And so naively, they started taking the capacitors off and did it boot up? And darned if it didn't keep booting up and it kept working, even though they took off like 999 of the decoupling capacitors.

And so the conclusion, it wasn't Istvan's conclusion, he was telling the story, but the conclusion of the engineers that were taking the capacitor off was, "Oh, we don't really need decoupling capacitors." And part of it was the modules that had the processors on them... We had decoupling capacitors, so that helped the noise on the processors. But the other is, there's a difference between... This goes back to the question, what does it mean to work? If it boots up, that doesn't necessarily mean it's going to work when you're running real code and you're running five different applications at the same time. And so it may work initially or in a very limited case, but it doesn't mean it's a robust design. And oftentimes with design products for not necessarily worst case, but cases that are extreme cases that could reasonably occur and you have to have the right test factors in order to have confidence that this product is going to work under typical customer applications.

Zach Peterson:
Yeah. It sounds like there was not a very good definition of success there.

Eric Bogatin:
Right, exactly.

Zach Peterson:
Right. If your measure of success is, "Well, it turns."

Eric Bogatin:
Yeah. And, "Hey, it boots up."

Zach Peterson:
Okay.

Eric Bogatin:
Because that's not necessarily the worst case. You're old enough to remember the blue screen of death that we would get sometimes with some of the old-

Zach Peterson:
Oh, yeah.

Eric Bogatin:
... processor boards and running Microsoft office. I am convinced that a lot of those problems were PDN problems that were worst case because it was only when you're driving just the right combination of applications when they all happened to be doing something at the same time, it was very unreproducible. And it happened only periodically. But typically it was when you were doing a number of things in parallel, I think that's just the right combination of code is really, really hard to reproduce, but you have to stress the product under test in order to see the behavior.

Zach Peterson:
I never would've considered that, but it sounds like I'm going to have to go into my mom's garage and do that to some computers.

Eric Bogatin:
Okay. Here's my other theory of... Because I see a lot of products fail. My TV will hang up sometimes. Everything has a microcontroller in it these days. And every now and then I will see the TV or I'll see a laptop or not an Apple, but other phones, they'll lock up. And I think a lot of these problems are two-bit errors because so many of our products and communications paths, which do parody checks all the time in data sets. So we can detect single-bit errors really well. The probability of a one-bit error is low. The probability of a two-bit error in a packet is really low. But with so many products and so many hours being on, I think a lot of times when things hang up and they stop working, I think it's because it encountered a two-bit error that changed a registry value somewhere. And uh-oh, suddenly, it's, it's often never, never land, or it's trying to execute some other command or it's waiting for something that's never going to arrive.

And that's why if you turn the product off and on again, it works because you're resetting to the default register state. I think there's a lot of two-bit errors going on that if we could only... really hard to detect, but if we only looked for them, that we might find them more often.

Zach Peterson:
And so your contention would be, this is a noise problem related to signal integrity just from that [crosstalk 00:32:08].

Eric Bogatin:
Signal integrity or something else going on and a bad connector.

Zach Peterson:
Power integrity becoming signal integrity.

Eric Bogatin:
Yeah. But it's some source of noise. It could be cosmic ray too. I've seen a couple reports of... Unless it's rad-hard, our electronics is sensitive to cosmic rays or muons I guess, coming in flipping bits. And if you get two bits flipped by some burst, I think that will create an error that's really hard to detect and hard to correct for.

Zach Peterson:
Yeah. You brought up rad-hard. I was actually talking with someone who works at a certain commercial space company and he said he had to learn about all of this stuff with rad-hard and how to make designs more reliable. And I think it goes into this whole other area of reliability that most designers might not experience.

Eric Bogatin:
Yeah, right. We have a program here at CU. CU is very big in the aerospace. We have a large aerospace department and do a lot of... In fact, right now today... We have an organization, the Laboratory for Atmospheric Space Physics. And right now today, every single planet in our solar system either has a CU instrument orbiting around it or on the surface or has just passed by. We do a lot of space science stuff, a lot of aerospace stuff. And we have a program for undergraduates to build cube satellites at our space grant consortium. I've been talking with a number of student groups that are building electronic circuit boards for space applications. And that's one of the issues is it's got to be really reliable. And these are skills that are very different from building a laptop or a little IoT sensor node that's going to go on your balcony to tell you what the weather's like. These space rated... They're not man-rated, but they're space-rated products are a different set of design requirements that are needed.

Zach Peterson:
Yeah. And speaking of high reliability, we're actually hoping to have someone from an aerospace company come on the podcast in the coming weeks and talk to us about that type of thing, seeing as how commercial space is becoming such a huge area in technology just recently. I'm not sure what the big catalyst is. I think it's just so much money sloshing around in the system and Elon Musk speaking-

Eric Bogatin:
Well, speaking of Elon Musk, and I mean this is the nicest way, I think the other place that I'm really worried about reliability, maybe software more than electrons, autonomous vehicles that-

Zach Peterson:
Oh, absolutely.

Eric Bogatin:
I heard a talk, Todd Hubing gave, and you might grab him and get him on your show here. He talked about, how do you evaluate the reliability of automotive electronics? And he said that right now today, there are 30 people killed each day in car accidents. And 99% of the time, the root cause of the accident is considered human error, driver error. And so he says when we start having more autonomous vehicles, then we're not going to have the human error to blame anymore. And are we going to have 33 deaths a day? And how many, if we have one death because of an autonomous vehicle that, that creates an alarm. And, oh my gosh, someone was killed autonomously. 33 people are killed every day because of human drivers. And if we have autonomous, we can't blame the driver. Are we going to be seeing a lot of electronic failures or software failures because of that? So reliability is going to be an increasingly more important topic for automotive systems, I think.

Zach Peterson:
Yeah. And just this past year, we've been asked to clone a number of radar reference designs for some startups that are working on unique radar for vehicles. And the EMI concerns are usually at the end of it. I think part of that is because reference designs try and make it really easy to just design something, not really design something that's going to be ultra-reliable or ultra EMI immune or zero noise, but just to get you started and get you going and to buy their product. So it's good and it's bad. It's good if you're getting into a new area. It's bad if you are going to start relying on it as a production-grade system. And we've been guilty of this. And I think a lot of folks in the automotive industry are guilty of this is that the EMI considerations are at the back end and not at the front end. I agree with you. Once you start having autonomous vehicles and there is that risk of electrical failure and finding who do we blame-

Eric Bogatin:
Yeah. That's exactly.... before it goes to the deaths? It's going to fall on the EMI reliability, all of those areas of the design.Yeah. I think you're right. I think EMI is going to be a big issue. And it's not just the EMI, but the susceptibility as well from all of the rest of the electrical systems, especially the electric vehicles, you get some pretty large current transients in there.

Zach Peterson:
Yeah. Well, maybe everything will go fiber in vehicle and you can eliminate a lot of those problems. There's actually been some studies on it. I did a paper on it for a magazine and yeah, there, there are people who are looking at fiber in vehicle and fiber base radar. Interesting.

Eric Bogatin:
I think it's all going to come back to the cost.

Zach Peterson:
Oh, of course.

Eric Bogatin:
There are, what is it, like six or seven cameras distributed around a lot of the autonomous vehicles now, especially the EV cars, even though they're not autonomous. And the data rates for the camera feeds are all raw data. There's no encryption in them. So there's a lot of high-speed signals floating around throughout the body of the car. And you're right. Going fiber would certainly limit a lot of the interference issues on those signals, especially if they're used to make intelligent decisions, you don't want glitches coming up or distortion. Maybe there is an argument for more fiber communication links in a car.

Zach Peterson:
Yeah. Well, with fiber, one of the bottlenecks is just the size of those transceivers and getting the fiber to go from an electrical signal to an optical signal. And that's an area where I'm passionate about, I hope will receive a lot more pretension, which is Silicon Photonics, maybe that will be part of the solution. Or EPICs, Electronic Photonic Integrated Circuits. So you can have photonic interconnects connecting to the chip. You have an electrical interface that can take that data in from a vision system, like a camera, like LIDAR, even if it's radar vision, whatever it may be. And then you can send the data around a vehicle with fiber. I don't know, futuristic visionary type stuff, but it does fit in with the reliability and noise problems that I think you've rightfully pointed out, may be problematic for futurist future technologies like autonomous vehicles.

Eric Bogatin:
Yeah.

Zach Peterson:
We've got a few minutes left. What I definitely want to do right now is tell everyone to go register for all Altium Live right now, if you haven't. You'll have a chance to see Eric Bogatin in person and hear some of his very enlightening talks. Definitely going to be very interesting. But there's one last thing I want to ask you, and it's probably going to be like dropping a nuclear bomb on the podcast. But there's one last thing I want to ask you because I want to try and ask all of the very experienced designers this because it is controversial. What do you think about right-angle traces?

Eric Bogatin:
Okay. Actually, in Signal Integrity Journal, we've had a series of articles about this. The quick answer is folks should go to the SI journal and type in, I think, Corners or Right Angle Bends. And you'll see a series of articles we've had. The bottom line is, first question is, do 90-degree bends cause signal integrity issues? I have to get the right word. Do they do right-angle bends cause reflections? And the answer is absolutely. We can predict them. We can estimate them. We can measure them really easily. The second question is, is it a problem? And the answer is unless you're dealing into the 56-gigabit NRZ signals, probably not a problem to worry about, but very noticeable. And we do one of the examples in our class. We have the students build boards with straight lines, with 90-degree bends, and with rounded corners. We have a TDR and they get to measure them. And then they do an estimate beforehand of what they expect the impact of the corner to do to the estimate of the capacitance.

And we measure it from the TDR. And darned if they aren't within about 20% or 30% of each other. And that means once you know how to predict it, you can scale it down. And you can ask, "Okay, when I go to a really narrow line, a 50M narrow line, what's going to be the impact of the capacitance in the corner?" And it comes out to five Mil wide line. You'll have about 20 femtofarads of capacitance. And now you can ask the question, is 20 femtofarads of excess capacitance an important problem in my design? And if the answer is yes, worry about corners. If the answer is no, go into more important problems. But SI Journal is the place to find the series of articles that we've posted there.

Zach Peterson:
Very great point. It sounds like it's just an effective return loss.

Eric Bogatin:
It's a question of how much reflection will you get and how much is important. But while we're talking about resources... I'm going to do one other plug as well.

Zach Peterson:
Go for it.

Eric Bogatin:
This topic of what do you worry about and why? And you brought up the point of, it's not enough to have a guideline. It's important to understand the underlying assumptions for it so that you can know when to apply those generalizations. I cover a lot of that in some of the courses that I've taught. And we've taken all those courses, we recorded them. We've posted on what we call the Teledyne LeCroy Signal Integrity Academy. And normally it's a subscription fee, but for Altium listeners and for your viewers, and we'll do this at Altium Live as well, special offer. Operators are standing by. Anybody interested in getting a free subscription, a three-month subscription to the SI Academy. You just go to bethesignal.com. You select the three-month subscription. You fill a little from. And there's a place for a promo code. And the promo code to type in is ALT21 on. So Altium, ALT 21, you type that in and you'll get a three-month free subscription at SI Academy. You can view all of the live lectures that I used to do that are recorded.

And I have a whole section there about this content and corners. And when do you worry about reflections from corners? I just want to off for that little plug for all of our Altium viewers out there.

Zach Peterson:
Absolutely. Thank you so much. I'm definitely going to check it out myself. And I hope the listeners who are interested in some of the more advanced aspects of signal integrity will check it out as well. Well, thank you so much for being here, Dr. Bogatin. It's always a pleasure. We haven't talked a lot, but let's talk more. I have an article I owe you for Signal Integrity Journal.

Eric Bogatin:
We look forward to that.

Zach Peterson:
Absolutely.

Eric Bogatin:
Hey-

Zach Peterson:
Thank you so much.

Eric Bogatin:
Great chatting with you, Zach.

Zach Peterson:
Absolutely.

Eric Bogatin:
And look forward to seeing you at Altium Live.

Zach Peterson:
Thank you. Yes, I'll see you there too. And to all the listeners out there, don't stop learning and stay OnTrack.