Quality Reports, Vendor Models, & EDI CON

In this episode of the OnTrack Podcast, we have a chat with Benjamin Dannan, defense & aerospace contractor. We talk about power integrity, high amps, quality reports, vendor models, the importance of verification, and much more.

Listen to the Episode:

Download this episode.

Watch the Episode:

Show Highlights:

• Intro
• Ben's Background
• Power Integrity Considerations
• Vendor Models Quality & Accuracy
• Trust & Verify
• File Density Challenges
• Die (integrated circuit) Models & Packages
• "It's Easy to Miss Things."
• Lost in the Translation
• Ask for Quality Reports
• 2,000 Amp Challenges

Links and Resources:

• Watch Recent Related Episodes
  • PCB Packaging & the Future of Manufacturing
  • The Impact of the Defense Sector in the Electronic Industry Ecosystem
• Read Related Articles:
  • Designing for Military and Aerospace Embedded Systems Applications
  • Advantages of Flexible Circuits for Space Applications
• Connect with Benjamin Dannan on LinkedIn
• EDI CON Online 2023

Transcript:

Zach Peterson:

One of the challenges with dealing with vendor models is quality and accuracy. I saw you just roll your eyes a little bit.

Ben Danon:

Oh, yeah.

Zach Peterson:

I think this comes up way more often in the context of IBIS models, or possibly touchstone files, maybe if you're getting something from a connector vendor or something. But I don't think I've ever heard anyone bring this up in terms of models for the IP that is going to go onto the die, for example, a DDR4/5.

Ben Danon:

Yeah, you hit a soft spot. This is something very close, near and dear to my heart. This is why I created my LOC, just so I can address this gap, why I love working with Steve and Heidi. This is such a problem. Even where I work currently, we have our own measurement-based model library that we've created, because there's such a gap in vendor models today.

Zach Peterson:

Hello everyone, and welcome to the Altium OnTrack podcast. I'm your host, Zach Peterson. Today, we're talking with Ben Danon, who works at a major aerospace and defense contractor. He's also going to be speaking at EDICON in October, and I thought it would be a great time to have him on, to see what he's going to be speaking about, and learn more about what he does for work. Ben, thanks so much for joining us.

Ben Danon:

Hey, Zach, thanks for having me. It's a pleasure to be here.

Zach Peterson:

You have been brought up many times in my conversations with Heidi Barnes and Steven Sandler, and I know you've done some work with them. Also, if people follow you on LinkedIn, they probably know that you're a familiar face on conferences like DesignCon. So, maybe you can tell us what it is you do, and how you got involved in the electronics industry, and what you'll be speaking about at EDICON this year.

Ben Danon:

Yeah, okay, a lot to cover there. Heidi and Steve, we call ourselves the Three Musketeers. I am very grateful just to get to work with them. I started working with them back in the early 2020 time, 2021 timeframe, actually. We've done a bunch of EDICONs.

Zach Peterson:

I noticed that.

Ben Danon:

Yeah. A bunch of papers. We're doing another paper this year, at DesignCon. The paper at DesignCon this year, it's with Steve Sandler, Heidi Barnes, Iden Ezra from Broadcom and Yuni from Monolithic Power. And so that one is about designing a 2000 amp power supply and the challenges. And Steve Sandler at PICO Test is making a 2000 amp step load just to test this power supply. So that alone is a whole challenge in itself. So that should get your mouth watering, just thinking about how are you're going to build or even make something. I mean, there's water cooling, refrigerating, all sorts of things that he's doing just to make this thing. And so yeah, I'm just grateful to get to work with them. The EDICON topic, that is a paper that I'm doing with a good colleague, a great colleague actually, and a friend Jim.

Ben Danon:

He works at the same aerospace and defense contractor that I also work for. And the name of the EDICON paper is what is enough, BDDQ power integrity analysis with a TDR45. That is going to be a ton of fun. It's on October 4th and we are going to be presenting some of the challenges and a bit of a story that we kind wanted to share with folks on what do you need to consider when you're integrating a DDR5 with your package from another vendor? Because in actuality, most people aren't going to design their own DDR45. They're going to buy it and license it from a Cadence or Synopsys or somebody else.

Ben Danon:

And so when you integrate these DI models and you get these DI models, you want to do the power integrity analysis, you already have enough to worry about when it comes to doing end-to-end simulation and doing sign off of your package, let alone worrying about if the DI model is correct. And so the whole premise that we are presenting is, well, what happens if your DI model is not correct? What do you do? Your voltage margins are already getting smaller, and so you have to manage that. And how do you know if it's not correct? What are considerations?

Ben Danon:

So it's going to be a ton of fun, and that's just a bit of a teaser and kind of what we're going to talk about, and we can go into more of that if you'd like. And then on the electronic side, yeah, I have my own LLC, I have it signaled solutions, and the whole premise is to do measurement-based modeling simulation and EM. So I do it so I can play with folks like Steve and Heidi and others and grow and have fun because this industry, I love signal integrity and power integrity. It's a passion of mine.

Ben Danon:

And I've been doing this for a number of years, started my career off actually at another defense contractor. Then I went to Bosch, then I went to a robotics company, and now I am where I am and I have my own LLC. And so along the way I was in the military and served at a bunch of things and really kind of found my niche in the modeling and simulation space. So ultimately I'm just having a ton of fun and just happy to be able to play and work with these other folks, learn and grow. So it was a lot. Hopefully I covered everything, right?

Zach Peterson:

Yeah, I feel you on the having fun part, and I know with my background, it kind of made me naturally gravitate towards simulation and analysis more so than just pure design. So I definitely understand where you're coming from. You brought up with regards to your EDICON talk, you brought up the use of IP in some of these components for like DDR5. I think for most of our audience, they may not be aware of how this all works. And so really what you're looking at is not just the PCB and not just the PCB plus the package, but it's really from the bump all the way down to the board. And that's where we have to consider power integrity rather than just stopping at the PCB and then whatever the input is on the package.

Ben Danon:

Yeah. And that's really actually a challenge because when you integrate this IP, let's just say you work at a company designing a custom ASIC, like what I'm doing here. You might have pieces of that ASIC that is your design, your proprietary technology, but your team is only big enough. So you're going to integrate IP from other vendors or license it to meet those in functionality requirements performance and where you want to integrate that ASIC to perform. So maybe you need more memories. You're going to buy an ASIC DDR45 from somebody else and integrate that on your grid. And your point is very valid. Most of these IP vendors, these ASIC designers that are making these pieces of IP, they're specking the compliance point from a voltage perspective to the DI bumps, exactly what you said. So if you're designing a substrate or a package, you need to understand how to model it to the DI bumps and check compliance to that point.

Ben Danon:

And in this case, that's exactly what we're showing. And these ASIC designers and IP vendors can give very complex of requirements where in this instance, in the EDICON paper, they gave us two specs for the DDR45, the DI bumps. One was we had an overall ripple spec that was less than our clock. In this case, if it's say a DDR4, 2400, our clock is 1.2 gigahertz. And then we had a different tighter, smaller AC spec greater than our clock. And so that's not really intuitive for most designers from power integrity perspective, but you have to know how to filter that and then present that. And that's what I show you in the EDICON paper so you can check for compliance.

Zach Peterson:

I see. Okay. So one of the challenges I guess with dealing with vendor models is quality and accuracy. And this comes up, I saw you just roll your eyes a little bit.

Ben Danon:

Oh yeah.

Zach Peterson:

I think this comes up way more often in the context of IBIS models or possibly touchstone files, maybe if you're getting something from a connector vendor or something. But I don't think I've ever heard of anyone bring this up in terms of models for the IP that is going to go onto the DI for example a DDR45.

Ben Danon:

Yeah, you hit a soft spot. This is something very close, near and dear to my heart. This is why I created my LLC just so I can address this gap, why I love working with Steven, Heidi, because this is such a problem. Even at where I work currently, we have our own measurement based model library that we've created because there's such a gap in vendor models today. And it's not just us, right? Go ahead.

Zach Peterson:

Well, and you're right, it's not just you, but I see this come up pretty often on SI lists.

Ben Danon:

Yes, yes. I can tell you for a fact, the IBMs, the Intels, the AMDs of the world, they all have their own internal measurement based model library because there is no standard for things like capacitors and passive models. And so Morana just gives you these models for free, but there's no standard that says how they measured it and whether or not that additional path inductance is part of that model or not. For IBIS models, the standard is great, but the challenge is as integrators or designers, it's our job to hold these vendors accountable. And what the IBIS forum teaches you or teaches folks that are paying attention is ask for a quality report. They actually have whole presentations on the IBIS forum that says, what is a quality report? What is an IBIS quality report? Ask for it because there's a checklist. And most may not even know.

Ben Danon:

Did you know that there's an IBIS quality checklist? So when you get an IBIS model-

Zach Peterson:

No. I didn't know that.

Ben Danon:

Yeah, there's actually a checklist and IBIS form is actually trying to teach and promote this, like saying, hey, you got an IBIS model, ask for the IBIS quality report, which shows they went through and checked all these different pieces of that model before they just released it to the wild. And that's important because how do you know that IBIS model is good? What did they do? What did they check it against? How did they build it? And these are simple things that can help prevent errors and mitigate any sort of human factor that comes into play. And that's what happened with this EDICON paper, right? I mean, there was no quality check. I'm not saying there's a standard, but that's one of the things I asked for a simple method when it comes to any sort of DI model because when we talk about DI models, there's two pieces.

Ben Danon:

There is the passive portion, which represents your CDI and RDI, and RDI is just the resistance to the grid, and you can extract that with DI modeling tools, both of those you can extract. Then there is the active portion, which can be represented a couple of different ways. You can represent that with a PIECEWISE linear waveform, a PWL waveform. You can use an IBIS model that's attached to your passive DI model that's generating those currents. And there's a couple other techniques, but those are the two biggest, most common. And so when I got this passive DI model, I looked at the value of CDI and I said, for a memory controller, there's no way this is right. Absolutely no way. I went back to the IP vendor and I said, hey, do you guys know your CDI value is really quite low?

Ben Danon:

It was 3.29 nano ferrets. And I said, that's really low for a CDI for a memory controller, and this is a by 72 memory controller, so it has to drive 72 DQ nets plus all the strobe, plus all the CAC nets, et cetera. And they're like, yeah, that's right. I'm like, can you just do a back of the napkin calculation? Very simple, right? We know C equals epsilon A over D. You can calculate the value of capacitance for any MIM caps or IDC caps on your FI and multiply that by the total number. And you usually find that what you extract and that number, what I call the back of the napkin calculation match, I've done this many times. And they're like, yeah, no, it's right. So I never got there. I'm like, oh man, they're going to make me really go through and show them this number's wrong.

Ben Danon:

So then I went and I grabbed and I talk about this specifically in the paper. I went and grabbed a micron SD RAM model and I pulled up the IBIS quality report, and then I even plotted because they give you the DI models with their IBISs models, so you can do this sort of analysis. Micron does a great job with this. And so I plotted the CDI and I showed the screenshot of the IBIS quality report, and it shows double the CDI for an SD RAM for a by 16 SD RAM, right? So it's only driving 16 DQ plus strobe, et cetera, and it's double a by 72 memory control. And I said, are you guys sure this is still right? You're still telling me this is right? Yeah, that's right. I'm like, okay, so you're going to make me go this step further. All right. So then I built the N-

Zach Peterson:

Sorry, real quick. You just would've reasonably expected that it would've been four and a half times larger, right? The CDI on this five-

Ben Danon:

Usually, typically I expect something anywhere from four to five times larger than that. With my experience with memory controllers, you can grab a good example, a versicle, the new Xilinx or AMD acap, right, they call it acap, but I still an old school and call it an FPGA. That has a hard DDR45 on there. I've looked at dime that C dime many times. I think it's like 15 nano ferrets. It's in that ballpark. So already an order of magnitude greater than what I had. And so for a memory controller, just knowing what it's doing versus a DRAM, something just didn't pass the smell check.

Zach Peterson:

Yeah. For sure.

Ben Danon:

And so I showed this to the IP vendor and they're like, yeah, yeah, it's right. And I'm like, okay, I'm clearly not talking to the right people. And it's like any billion dollar company, they're all big. We're all big. And so you just got to break down the right barrier. So finally I built and N model, our schedule's now slipping, and I showed, look, we're not passing the spec. In fact, you can see I have perfect transmission lines, which it's loading, right, the DI and everything and everything's perfect in match. There's nowhere passing the spec. In fact, we were violating their spec by two times. Twice. We were more than double their spec. And they're like-

Zach Peterson:

So double the ripple.

Ben Danon:

Exactly. And so that's the whole premise of this paper. And at the end of the day, I show a calculation how to calculate what the minimum CDI needs to be using their worst case, transient current from this model. And what you find or what I found, which makes sense, it goes back to this basic physics things that folks like Eric Bogatin and Larry Smith teach in one of their books that show how to calculate what the minimum CDI is based on the worst case, transient current. And actually, I referenced their book in this paper and I show that. And what I calculated was around 6.2 nano ferrets, the IP vendor came back and said, yeah, the CDI is actually 6.49 nano ferrets.

Zach Peterson:

Big surprise.

Ben Danon:

Go figure. Right? Exactly. So as soon as I put that in there, what do you know? We're passing spec. So it's a really fun story, but these things are not intuitive to a lot of folks and you have to really pick at the details. And to be honest, building a DDR end to end model like this is not easy. I used Keysight ADS to do it, and I use it for many reasons, but already it's complex enough. Not only do I have a memory controller, but I have nine DRAM. I have their dime models, I have the DI model for the DDR45, I have transmission lines loading all the DQ, CAC, strobe, clock nets, right? So I have that current, correct.

Ben Danon:

You have to have ODT. It's very complex model just to build to get it right and it takes time. And so that's the whole premise here. How do you do it? How do you know and how do you work through the process of understanding what to pick at? And so that's what we did. So I'm really excited to share the story. It's going to be a lot of fun.

Zach Peterson:

It's really a guide to complaining to your IP vendor then.

Ben Danon:

Yeah, I mean, the takeaway is ask for a quality report, ask for something, right? That's the takeaway at the end is if you're getting these models from these vendors, I always teach my mentees trust and verify. Don't just blatantly take that and put that in your simulation. It goes back to Eric Bogatin, rule number nine, what do you expect to see? And it's like, well, if it's not passing, I expect it to be passing. You got to be asking yourself why, because they gave us this model and it should be passing under the worst case condition. And if it's not, it's unlikely they design their fine correctly. That'd be a pretty bad thing.

Zach Peterson:

Well, on top of that, I think you look at the company that is providing the IP and the model, and you probably say, hey, these guys have big budgets. They hire smart people. They can't possibly be making a mistake. It's easy just on its face to look at who's coming from that position or who's giving you that model and saying, they know what they're doing. We must be doing something wrong.

Ben Danon:

That's the challenge. When you integrate IP from other vendors, or even if you work internally with your own ASIC team, the amount of files for a phi, let alone an entire ASIC is it's gigabytes and gigabytes of data. The deliveries you get, it's so easy for these things to get lost. And the problem is by the time you're ready to look at that data, because you're at that part in your design cycle, sometimes it's too late. And teams are only so big and it's hard to vet all the data that you're getting from these vendors to make sure it's right.

Ben Danon:

And so what ends up happening is these IP vendors, Cadence, Synopsis, doesn't matter, they're just compiling based on some contract that you have to license this IP and they're just giving it to you through some sort of secure drop. And it's hard to parse through all that all at once and know if this is right, unless your team is big enough and nobody's team is always big enough to go through that. And that's another challenge in itself. And that's where some of these kind of gaps come in, which is why I teach ask for some sort of quality report so that way you can at least help force them to do their due diligence upfront. It's not perfect, but it's a path forward, I think, in the right direction.

Zach Peterson:

Now, here's a hypothetical, suppose that you didn't notice this and you said, I need to throw whatever I can at the wall and see what sticks and get to a design that works within or at least as close as possible to spec. How would you do that? Because I bring that up because it seems that it's going to force you to get way over conservative when you have that kind of an incorrect model.

Ben Danon:

Yeah, that's a good question. And so I actually talked about that in EDICON paper also. Just to prove the point on how important getting that DI model correct is, right? And first we go big to small and talk about, okay, what does a DIME model? And then we go through what does a dime model look like with the package? And we all know, and if you don't know this, but we talk about this Bandini mountain, which is really that cue point that occurs between the package and the DI model, and it's a function of the inductance between the package and the DI. And so I show a simple case study where we've put say eight micros ferrites of unpackaged caps, and we have one nano ferrite of CDI, and I hit it with a step load. And you can see I have something like 130 millivolts of ripple, which is quite high.

Ben Danon:

And then what I do is I show the same step load, but instead of one nano ferrite of, I'm sorry, instead of eight micro ferrites of unpackaged capacitance, I go up to something egregious just to prove a point. I go up to a hundred milli ferrites. You would never ever design a package that way. In fact, the packaging team would shoot me and say, you're crazy, you shouldn't be in the packaging business if you're asking for this. And so reasonably eight micro ferrites is reasonable for a package for say a DDR45 power domain. And that's why I'm showing this example. But the point was is that with that step load and that egregious amount of unpackaged capacitance, the peak-to-peak ripple at the DI didn't really change. It changed by a fraction of a mill instead of 130, it was like 129 or something.

Ben Danon:

It's in the slides. It didn't change very much. And the point is that the inductance between the package and the DI is dominating, and this is showing the importance of having the right DI model. And the next instance, I just went back to that eight micro ferrite on package capacitance and just increase CDI by five times to five nano ferrites, and you can see a 50% improvement in the response. And then go to CDI at 10 nano ferrites with eight micro ferrites of unpackaged caps, and that's another 30% improvement. And so this is just proving the point to designers what you can do and what you can't do. And the takeaway is that CDI is really important to make sure it's right because not only does it impact your ripple, but it impacts your jitter. But there's only a limit on how much unpackaged capacitance you can put on there.

Ben Danon:

There's a point where then no matter what, if you have the perfect package in the world, you're always going to have inductance there and you're going to be fighting that. And it doesn't matter what you do, you can't get past a certain amount of inductance. And so to your point, to your question, what can you do? There's nothing at a certain point. If you don't have the right amount of on DI capacitance, there's nothing you can do. And this is a known thing, and this is where everything kind of lags the ASIC. And when it comes to packaging design, this is where you really need to make sure ASIC and the ASIC designers usually are really good about doing this, are putting the right amount of CDI on there, the right amount of M caps. Occasionally that gets missed and the package might be able to pick up some of the slack, but it's limited. It's very finite. Most of the time it can lead to another tape out on the ASIC to fix that.

Zach Peterson:

Well, that brings up another question here, right? Because when you see in the documentation that they give you that CDI is really low, I think the next thing that you think of is, well, okay, if they're saying the model is correct, did they really just put that low of capacitance on there? And if they did, and I need to have, like you said, four or five times as much, should I even be using this vendor?

Ben Danon:

Well, those are two very different loaded questions, but let's address the last one. Should you really only be using this vendor? There's only a few vendors out there, so you're going to rule out all your vendors very quickly if you go that approach. Going back to your first question, I find a lot of times there's just so much data and technology and models that are needed and developed and created to integrate these complex ASICs, whether it's a DDR45, a PCI EFI, or some sort of arm core, it doesn't matter. It's easy to miss things. And I see all the time. An ASIC designer I'm working with, we're working on generating some DI models for another MCM, another subrate design, and a simple script error in his tick script disconnected all the MIM caps when he extracted that power domain, so all the MIM caps. So we had 200 nano ferrites of on DI capacitance, but when he fixed that little one line where that connected those MIM caps to the grid, suddenly we went from 200 nano ferrites to 1.1 micro ferrites, which is a more realistic number for this core rail.

Ben Danon:

And so it's a very simple human error. These are all script-based DI modeling tools, and these things happen. And so this is where you go back to the ASIC designer or the IP vendor and you say, hey, how many MIM caps are on this power ? Okay, let's just say a hundred thousand. Okay, a hundred thousand, okay. What's the tech file say for the DK that you're using? Okay, it's DK of this. All right.

Ben Danon:

What's the height between the plates? Okay, it's this. What's the area of each MIM cap? Okay, got it. Okay. So C equals epsilon A over D, where epsilon is your DK and your E of R, which is 8.854 times 10 to the E to minus 12 ferrites per meter, right? Right. That whole long number. So you take that, you multiply that by the area of the MIM cap, divide that by the distance between the plates, you're going to get a value for one MIM cap. Multiply that by that a hundred thousand. Now you have a good approximation of the total amount of MIM caps on that grid. If that doesn't match what you extracted, usually it's simple things that you just need to work with these vendors. And I've seen this time and time again internally with our ASIC teams and even externally with other IP vendors where you just need to work with them to address it. And there's a lot of back and forth, and this is kind of part of the design process in my opinion.

Zach Peterson:

Yeah. So I guess the takeaway from that is they do actually know what they're doing in terms of building the ASIC. It's just something gets lost in the translation between the actual physical design and the documentation that they give you so you can do any kind of model.

Ben Danon:

And a great example, one IP vendor for this ASIC that I'm working on, it has a PCIE file on there. And so in the documentation, it actually says in the PCIE file, because you have PCIE, AVDDC, AVDDD, and then H, you have multiple power domains. It says the CDI for each of those power domains needs to be approximately this or greater. And so we're looking at the DI model and they actually documented it in this instance. Okay, it needs to be this or greater. We looked at DI model that we got, we're like, it's not that. It's less than this, less than that.

Ben Danon:

And so we went back to like, oh yeah, good catch. That's just an error. Here's the new DI model. And so that was a big deal because if we were to use those, there's no way we would've passed spec. And so these are just some... It varies from one IP group to another, but you see in that instance, they documented it. So here we could check and say, okay, it's clearly not right. This is how we address it. We ask them, we've got the new models. And it goes back to the earlier point, okay, maybe when they ran their script, whether it's tickle or whatever DI modeling tool they're using, they forgot to turn on a switch and include some things in their extraction. It happens.

Zach Peterson:

It sounds like at the end of it, you managed to get this figured out after plenty of headache and gnashing of teeth and emails back and forth with a five vendor just to get them to admit, oh yeah, we made a mistake. Here's the updated model.

Ben Danon:

Yep, that's correct. And so we even work with them to even loosen the spec, which is great. Sometimes these vendors can put things a little tight, and so the takeaway is it never hurts to ask. And so that goes back to what I was saying before, ask for quality report, ask, challenge, just don't blatantly trust the model just because you got it from this vendor. We're all humans at the end of the day. Not everything's running on AI yet and being generated by machines. So hopefully we're doing our due diligence in checking these models and it helps overdesign, right? And that's the whole premise here. Because there's only so much you can do with what you have. And so you need to really ask to make sure you have the right models.

Zach Peterson:

Yeah. And you mentioned loosening the spec after, I don't want to say complaining, but asking about it. Convincing them to loosen the spec. I guess it forces you to be less conservative with your design.

Ben Danon:

It does. Yeah.

Zach Peterson:

That's something I've had to deal with, not necessarily in the context of ASIC design, but having to ask a vendor, hey, do we really need to have this power level coming into this pin? This is an RF design. And they tell you, well, we're a little more conservative on that than we need to be. And they tell you, you can actually go as low as this, and we've had it work. And so that's always nice to know what your real limit is versus what they tell you the limit is.

Ben Danon:

Right. Right. Agreed. In this case, this FI that we were integrating is actually also a DDRR5 FI, and so it's made to run at DDR5 speeds, but the spec they put on you was for DDR5 speeds, which really not needed for the speed we're running at DDR4.

Zach Peterson:

I see.

Ben Danon:

But sometimes unless you ask, you wouldn't know, right?

Zach Peterson:

Sure, sure. So the other thing that you brought up, which I thought was really interesting, and I know we've been talking about ASIC design here, but you mentioned that working with Steve Sandler to work on a power supply at 2000 amps.

Ben Danon:

Yeah.

Zach Peterson:

Now usually when you hear numbers like power supply at 2000 amps, you're probably not thinking, oh, this is for a digital system. And I think a lot of people when they look at digital systems, they say, oh, it's a small device. It's only got some chips on it. It can't be using up that much power. But when you start to look at stuff like data center architecture, those power levels are becoming much more common. I actually just saw something recently from Reed Sami on LinkedIn, and they were showing an image of a board board that was running at a thousand amps, and you could see the socket for the processor and everything on it, and you had all the VRMs all the way around it with all the different phases. And so that's at a thousand amps, you guys are already at 2000 amps.

Ben Danon:

Yeah. So where this came from, right, Steve has a lot of customers that are at a thousand amps and 1500 amps. I think he has a couple at 2000 amps. I'll let him speak to that. But the whole premise is that Cisco, AMD, Nvidia, Intel, they're all making substrates for ASICs that are pulling a thousand plus amps, even Broadcom. And so the takeaway here is Steve needed to be ahead of the power curve to support those customers, and he wanted to create a step load to support that next generation of power testing for substrate level testing for your PDM. And we needed to create a power supply to support that. And so that's where this whole paper came about. And we're excited because how do you even design for 2000 amps? What are the challenges from a measurement perspective? And so if you think about, we're talking about 2000 amps for a core rail at sub one vol.

Ben Danon:

Okay, so that means we're talking about PDNs in that 30 to 40 micro ohm range. So okay, that's one thing if you're talking about measuring that with two connectors on patch to the PDN, but as soon as you use a probe, what I've learned working with Steve and Heidi is your common mode rejection ratio becomes dominant and you have to have a common mode rejection ratio well over a hundred DB. In fact, Steve just proved this and taught me this. Just to get down into that sort of impedance measurement range with a probe, you need to have a CMRR over a hundred DB. And so-

Zach Peterson:

Is that because the common mode noise just swamps out your receiver?

Ben Danon:

No, it's because there's common rejection ratio basically is how you mitigate the ground loop error, right?

Zach Peterson:

Okay.

Ben Danon:

And so Steve makes these injectors, he makes a diff amp, which is a great, I have both this and the passive one. The diff amp is an active one. It only has a CMRR of, I think it's like 60 DB or just under or right around 60 DB. And then he has a passive injection transformer, which is basically a, right? That one has less CMRR than the diff amp. And where you start to see this CMRR error creep in is towards the DC area of frequency range. And you don't see it until you get below so many micro ohms, right? When you run a hundred micro ohms, you won't see that CMRR error with the diff amp.

Ben Danon:

But when you run a hundred micro ohms and you're using that combo choke, you're going to see it because there's going to be a nice hump in your impedance from DC to a certain frequency, and that's the CMRR error. And the only way to get rid of that hump is you need to go to a device that has a better CMRR or you're not measuring down on that bandwidth range. And if you think about it from a PDN perspective, we want to be in that bandwidth range because our power supply where it's impacting the PDN, it's in that DC to that megahertz range. That's right where the PDN of the RM is really important. We want to see what the control loop's doing. If we want to see what our loop bandwidth is doing before our bulk caps are kicking in, that's right in the sweet spot. And so we really care about the CMRR being really, really high to mitigate that, especially in these low, low impedance measurements sort of applications.

Zach Peterson:

So at a thousand or 2000 amps, this is peak current or this is average current?

Ben Danon:

Oh, this would be average current, yeah.

Zach Peterson:

Average current. That's a lot of current.

Ben Danon:

Yeah. Pretty crazy, right? Yeah.

Zach Peterson:

Yeah, exactly. So you had said, I think you said that Steve was doing substrate design for those.

Ben Danon:

Oh, I won't speak too much of it, but yeah, he's making things that plug into sockets, things on Interposers. He's developing custom and semi-custom off the shelf stuff. He's got a whole new bunch of stuff that he's working on. It's very exciting. I won't spoil it, but it's going to be fun to play with these as these get to come out. I will say for the folks listening, just ask eco test if you're interested. Some of these products are really cool. It all kind of started with his first water cool probe that he came out with about a year ago now. He actually created the first GaN base water cooled probe. And the reason why it's water cooled is because he needed a better way to do PSNR or PSRR sort of measurements, right? So right now the line injector is limited in your bandwidth in terms of how high of a bandwidth you can measure your PSR, and that's because the ductus between the injector and the line and your duct.

Ben Danon:

And so what he did is he moved the line injector into the probe head so you can put it right there on your board and remove all that path inductance to increase your overall bandwidth. And so in doing that, not only increase your bandwidth, but you can increase your slew rate. And so there's lots of really cool benefits, but because he did that, he also had to think of ways how to manage it. You have GaN in the head, you're pulling watts in this little area. And we're talking like amps to tens of amps. How do you cool it?

Ben Danon:

So, refrigeration sort of solution. So I have one. the waterline coming out of the probe head and going into this pump. And so then you have your signal lines going to your function generator or your VNA depending on what you're using as your modulator. And then you have your RF coax coming out going to the other port. So it's very interesting, but it's really cool when you think about what we're going to have to move towards to do these complex measurements as our sensitivity from PSR gets lower and this is what you have to move towards. And that all kind of manifested, I think, for Steve into these next generation of more powerful step loads that he's created. Because he had to get past this to get to that. So it's really exciting if you're following what Pico test is doing.

Zach Peterson:

To everyone that's been out there listening, we've been talking with Ben Danon who works at a major aerospace and defense contractor. He's also going to be speaking at EDICON on October 4th. If you're watching on YouTube, make sure to hit the subscribe button, hit the like button. You'll be able to keep up with all of our tutorials and podcast episodes as they come out. And last but not least, don't stop learning, stay on track and we'll see you next time. Thanks everybody.