Thanks everyone.



Thanks for joining Teledyne LeCroy today for our webinar on debugging PCI Express power management behaviors with presenter Dr. Patrick Connally.



Teledyne LeCroy offers a wide range of test tools for electrical, physical, logical and protocol layer testing.



We provide a broad array of test solutions for serial data standards and next gen technologies.



We also offer expert level testing services as well as world class training and educational services. We were founded in 1964 by Alabama native Walter LeCroy and our corporate headquarters is located in Chestnut Ridge New York while we have sales and service offices all across the United States as well as the rest of the world. Before I turn things over to Patrick I'd like to thank you for taking the time to join us today. During today's webinar we just ask that you please use the question section in your control panel to submit any questions.



We'll answer them at the end to keep us running on schedule and then as you exit the presentation a survey is going to pop up. Please take a minute to answer these 5 questions so that we can continue to provide valuable content to you. We know you're busy. We appreciate you being here.



I'll now turn things over to Patrick to begin.



Thanks a lot Hilary. Much appreciate the introduction. Welcome everybody. Thank you for joining us. Good morning good afternoon good evening depending on where you are in the world. My name is Patrick Connally.



I'm a product marketing manager with Teledyne LeCroy.



I work on our oscilloscope division on high bandwidth oscilloscopes and solutions for high speed serial technologies such as PCI Express.



This webinar was co-developed with a colleague of mine named Gordon Getty who is a technical marketing manager for solutions at our protocol solutions group.



So he works with our protocol analyzers. Gordon is currently on a plane to Taiwan for a PCI Express test event. Therefore he cannot join us today.



But I will endeavor to move forward in his absence.



So what we're going to talk about I'm going to go through a very brief overview of PCI Express as a in general as a technology.



I will talk about PCIe power management and L1 substates in a brief overview of those concepts.



What I really want to get into in this presentation is what we call debugging across interface layers. We occasionally use the term cross layer analysis.



PCI Express and particularly power management behaviors are a prime example of this where we have behaviors or issues or bugs that occur across multiple layers of the interface from physical layer through protocol layers and are notoriously difficult to measure or debug or validate.



And I'm going to give a couple of examples of that about measuring L1 sub state timing.



Sorry. It's measuring L1 sub state timing and measuring L1 sub state power consumption.



So I'm going to start off with a brief overview of PCI Express technology.



Some of this comes directly from PCI-SIG. PCI Express is a high performance general purpose IO interconnect defined for a wide variety of future computing and communication platforms.



Its attributes from the old PCI interface such as usage model software interfaces etcetera or maintain where but the parallel bus implementation is replaced by a fully serial interface. As I'm sure most of you know PCI Express has gone from Gen 1 which defines rates up to 2.5 GigaTransfers per second all the way up to Gen 6 which defines rates from 2.5 GigaTransfers per second all the way up to 64 GigaTransfers per second.



And PCI Express specifications are managed by the PCI-SIG or the PCI special interest group who also manage things like compliance programs, compliance workshops etcetera.



And both Gordon and I sit on several PCI-SIG committees.



So as I mentioned PCI Express is a layered topology as our most high speed serial technologies nowadays.



At the bottom we have the physical layer which is actually broken down in PCI Express into the electrical subblock and what we call the PHY-logical subblock. The electrical subblock really is all of the I'm an oscilloscope guy. That's the world I live in. And that's mostly what people think of when they think of the electrical subblock is voltage levels, jitter measurements eye diagrams, everything to do with wiggly lines and analog waveforms.



The PHY-logical subblock is where we see things like training sequences and ordered sets.



Further up we then have the data link layer transaction layer and above that the application layer.



If you want to cover that entire PCIe protocol stack traditionally you've needed 2 instruments to do so. They're both instruments that are made by Teledyne LeCroy.



For the PHY particularly the electrical subblock you need an oscilloscope to look at the quality of the signal, the voltage levels jitter values, emphasis levels things like that.



And the scope can provide some level of decode up through the PHY-logical and data link layers. For the higher layers from PHY-logical on up the tool of choice is a protocol analyzer.



And so you can cover the whole stack with these 2 tools but they each have advantages and drawbacks in various points of doing that coverage.



So if you look at a protocol analyzer its advantages are it captures the full bus width. You can get up to 16 lanes bidirectional.



It has much longer capture time than a scope.



Protocol analyzer has many GB recording memory and it is a protocol aware device. It's only storing the information in the packets.



And because it's a protocol aware device it has sophisticated multistage protocol triggers. A PCI Express protocol analyzer like the Summit M616 I'm showing here is a...it speaks PCI Express is the way I put it.



So it can be aware at a protocol level of the behavior that's an activity that's going on on the link it's analyzing.



There are some limitations to a protocol analyzer in general which is that it doesn't have visibility into analog behavior so it can't see things like emphasis changes. And it also doesn't have analog triggering capabilities. What I'm showing you on the right there is a Teledyne LeCroy summit M616. That's our latest PCI Express protocol analyzer which has full analysis capability for PCIe 6 and CXL supports data rates all the way up to 64 GigaTransfers per second at full by 16 link width.



If you kind of flip the story around you get what an oscilloscope does which gives you all kinds of visibility into the analog signal behavior such as amplitude timing jitter and emphasis.



It does have some decode capabilities. You can decode the data link layer out to the transaction layer with a tool that we call ProtoSync where we can feed the data link layer information that we've decoded on the scope into the protocol analyzer software.



But there are some limitations as well. The oscilloscope has limited capture time of the order of tens or if you're lucky hundreds of ms compared to a protocol analyzer.



It can see a fairly small number of lanes. Your typical 4 channel scope allows you to see essentially 2 lanes in 1 direction and 2 lanes in the other direction if that's the way you're choosing to probe it.



And the trigger capabilities are limited.



Unlike the protocol analyzer the oscilloscope does not speak PCI Express. It is aware only of analog phenomena.



What I'm showing you there is the WaveMaster 8000HD which is our new flagship oscilloscope platform that we launched last week. Ranges up to 65 GHz bandwidth so it supports up to 64 GigaTransfers per second. I have not updated that source header yet.



And also has a leading capture time of up to 100 ms for looking at things like protocol mixed physical and protocol events.



So the way we started to look at this in the last few years is rather than just treating the separate layers in the interface as completely separate things that should be looked at separately by separate tools. If we link the tools we can cover the whole stack better.



And that that can be an advantage for quite a number of applications because we have found an increasing number of our customers who have problems they come to us with where the first question they tend to ask they tend to be asking in a debugger validation sense is is this problem occurring in the electrical layers and the in the low physical layer or is it somewhere is it a logical or protocol problem or is it a mix of the 2?



These issues become increasingly common as the speeds of the links increase because the ability to do things like train the link or power manage the link become increasingly important as well as increasingly difficult.



We have an entirely separate webinar on link on debugging link training. But in this one we're going to concentrate on power management behavior.



So I'm going to give a brief overview of PCI Express power management and L1 substates.



I will admit at the start that I am not the protocol guy. That's my colleague Gordon but I will do my best to give a good overview of this topic.



So L1 and L1 substates L1 is a more aggressive form of power management than L0s.



There are 2 mechanisms to enter an L1 substate ASPM and PCI PM.



They each have a different entry mechanism. So PCI PM uses a config write from the root complex to a register on the device to initiate the transition to L1. So the way you can think about this is this entry to this low power substate is being initiated by the host.



ASPM on the other hand the downstream component so essentially the endpoint is indicating the desire to enter the L1 state. So the difference between the 2 is fundamentally which side of the link is deciding I don't need to be running right now or I don't need that component to be running right now and we can lower its power consumption. We can essentially turn it off for a short period of time to lower power consumption.



So the device indicates its support of L1 substates in the configuration space and there are 3 of those substates L1.0 L1.1 and L1.2.



The L1 power management substate is considered enabled on a port but any combination of the bits that I have shown there or that are listed in the slide are set.



Since you use this clock request signal the clock request is asserted when it's low and clock request is asserted to indicate the exit from L1 substate. So either end of the link can assert that clock request signal to say hey. It's time to exit L1 substate and come back into an L0 operating mode.



So I'll just show you here.



This comes from a trace from one of our protocol analyzers.



And you can see here these specific bits in that L1 power management sub states capabilities register.



We've got L1.1 and L1.2 support through PCI -PM and L1.2 and L1.1 support through ASPM. So these are all in this case this device supports all of those all of those substates.



And you can see here that L1 this is showing an LTSSM view again from a protocol analyzer of where in the state machine the L1 substates live they're over here. So you go from L0 into L1 subs into L1 And then the link has to go back through recovery to come back to L0.



And you can see over here that L1.1 and L1.2 are then substates of L1.



So this transition sequence diagram here comes directly from PCI Express spec and it shows the sequence of events. In this case a downstream initiated transition to L1. So the downstream component wishes to enter the L1 state. It sends an active state request the L0p to the upstream component which then acknowledges it and then the link goes to electrical idle in both directions and the link is now an L1.



So this slide shows the L1.1 timing diagrams again directly from the spec.



And this one shows the L1.2.



We're going to come back to one of these timing diagrams in a little bit and explain how one might actually validate the timings that are being shown here.



And this is how it looks up directing on protocol analyzer. So if I was just to look at one of these events on a protocol analyzer I'll see this is the L1 entry request.



The link enters electrical idle here. So both directions we've got an EIOS.



And then the clock request is deasserted here. There's some gap of time before the clock request is reasserted and then the link enters recovery. So like I referenced before in the LTSSM.



The thing you won't see here with protocol analyzer and I'll call back to this later is so we see the clock we see we see the link entering electrical idle.



Like here.



We see the clock request being deasserted. The thing we don't see is the reference clock actually switching off which is an important part of these L1 substates because that's one of the power saving measures that are implemented there.



Protocol analyzer can't see when the clock is valid or not valid. The oscilloscope on the other hand can. The thing the oscilloscope can't see is things like transitions to L0. And we're going to come back to that and kind of explain why that's a tricky problem to solve and how we go about how we go about debugging that.



But just to step back a little bit I want to talk about our toolset that we've come up with for doing these sorts of debugs debugging tool tasks across interface layers.



So a couple years ago we came up with a thing called CrossSync PHY.



At the high level CrossSync PHY is a technology that enables a protocol analyzer kind of oscilloscope to work together for complete link visibility. So you're not trying to pick which tool you're trying to use to look at the link and whether you want to look at the protocol right now or whether you want to look at the physical layer right now.



What you see on the right is kind of a conceptual diagram.



In the PCI Express sense it might look something like this.



And it consists of 3 parts. The first part is what we call cross probing.



So I need to take the signal that's going between the in this in the PCIe sense the system under test the root complex and the endpoint under test And I need to get that signal to both the protocol analyzer and the oscilloscope.



And the way that's traditionally been done in a protocol analyzer sense is to use an interposer that sits in between those 2. It passes the signal along in both directions as well as passing a copy of that signal to the protocol.



So we've actually come up with special CrossSync PHY capable interposers that have connections for oscilloscope probes on the interposer allowing us to pick off the signals and feed them both to the scope and to the protocol analyzer. So you can see here we have a couple of high speed differential probes. I have a photo of this and I'll show you in a little bit. High speed differential probes for the high speed signals. We can also look at things like power rails like reference clock signals. So it's not that we're not limited to just the high speed signals here. We're also looking at things like side bands power rails depending on what the application of choice is here.



In the example I'm going to go through today we're going to look at an M.2 interface specifically.



The reason being M.2 as a form factor is most commonly used in systems where things like tablets and laptops where power consumption is a is a really big concern. Of course a lot of you know M.2 is getting used in commercial desktops and things like that as well. But it does get used in a lot of battery powered and low power type of applications. So the ability to look at L1 substates in those applications is really important.



This is a top down view of this was our PCIe 4 interposer. We have a PCIe 5 capable M.2 interposer now. It looks basically the same.



So the M.2 device the endpoint under test would plug in here into this M.2 connector.



And there's a set of cables that stake out of this end to plug into the end into the root complex excuse me onto the motherboard.



We can do things like monitor excuse me monitor the 3.3 V power rail that's feeding the device. So this is actually connected directly to the rail so that the device is not being powered by the interposer.



The endpoint is still being powered by the host. That's a deliberate choice so that you can actually observe what's going on in that interaction and on that power rail. So you can see we have a little coaxial connector here that lets us probe the 3.3 V power rail. And we also have a current shunt over here so we can look at the current on the 3.3 V rail. And I'll show you why we might want to use that later on. We do have a buffered copy of the ref of the reference clock so we can see when the reference clock turns on when it turns off if there's any jitter on it. We can look at things like SSC profiles.



And then there are a whole bunch of sideband signals that also carry across the PCIe bus. We pulled those out on a set of pin headers here.



So things like the clock request that I mentioned is available to be probed here.



So your question now is well what about the high speed signals the actual data links? Well they're much faster. They're much higher bandwidth. And so what we have is a set of connections along the side here upstream downstream 0 1 2 and 3 and the same for upstream on the far side of the interposer.



And those have direct connection for our DH series active differential probes which connect to our higher bandwidth oscilloscopes.



The other thing that's worth noting is if I kinda look inside under the hood a little bit this is the M.2 connector that we have right here. These chips that you can just see behind the probes damping resistors are the amplifiers that amplify that signal along to the other resistors are the amplifiers that amplify that signal along to the other side of the PCIe link as well as amplifying it out to the protocol analyzer. We're probing the signal before it hits that amplifier. So we are actually looking at the signal as it came out of the device not after it's been amplified through the interposer.



This of course is 1 of a family of interposers. We also support CEM and U.2 U.3 and EDSFF form factors for this CrossSync PHY technology.



So that's kind of the first piece of what we talk about with CrossSync PHY.



The next thing is okay. I've gotten the same signal into both instruments.



Now I need to trigger them both at the same time.



So we have a cross triggering aspect to this technology as well where we can use the protocol analyzer to selectively trigger scope acquisitions only on events of interest. The protocol analyzer has 2 advantages here in the triggering side of things. Number 1 it speaks PCI Express. It is a protocol aware device.



Therefore it can trigger on all kinds of high level PCIe interactions that the scope is not intrinsically aware of as well as having more as well as being able to acquire more time simply by the nature of the protocol analyzer.



So we can use the protocol analyzer as a very smart trigger to trigger the scope not just once but multiple times on multiple different types of events happening in the link which allows us to make better use of the acquisition time of the scope.



And of course now that our newer scope has up to 100 ms of acquisition time we could take even more advantage of that. So I've taken the same signal. I've got it into the protocol analyzer and into the scope at the same time. I've triggered them both at the same time.



Now I need to analyze that. So we have a cross analysis feature as well which is that we have CrossSync PHY software that pulls the data from the scope and the data from the protocol analyzer in together and then allows you to navigate those 2 in a time correlated fashion. So I can know that the electrical signals I'm looking at on the scope interface and the protocol interaction I'm looking at protocol analyzer interface happened at the same time. Everything is time correlated and aligned.



And this is what a typical cross layer debug setup would look like. What I'm showing you here is with a CEM form factor.



So you've got your host your device kinda like I showed before. This in between is the interposer.



It's got in this case 16 lanes going to a by 16 protocol analyzer as well as we have a couple of high bandwidth active differential probes a voltage rail probe and a passive probe all connected from the scope to the interposer.



For the purposes of the examples I'm going to show you in this webinar we're going to look at this M.2 this M.2 device. So the host under test is this laptop on the left. The device for testing is an SSD that's plugged into the interposer and you can see those blue cables then plug from the interposer into the host.



The interposer sends a copy of the data to the protocol analyzer.



Protocol analyzer in this case that's a Gen 5x4 analyzer used for M.2 interfaces.



That captures the protocol traces and like I said does the triggering on complex protocol events. High bandwidth oscilloscope this is our older WaveMaster 8ZI model captures the analog waveforms and acts as the host PC for the protocol analyzer and CrossSync PHY.



And the scopes the probes on the scope connect as you can see from here on the scope the probes are connected there and then these are our 2 high bandwidth differential probes here. So in this case I'm looking at lane 0 upstream lane 0 downstream as well as monitoring that power rail that I told you about that 3.3 V rail in this case as well as looking at one of the signals with a passive probe. And on the scope we're running CrossSync PHY software that combines views and manages the timing relationship between the 2 the the 2 instruments. So that's what this looks like.



You can see the scope traces on the left the protocol analyzer software on the right. If I was to move either of those traces in time the other one will move along with it. So I know that I'm looking at the same window of time on both instruments.



On the top of the screen is a timeline. The purple line is the data we've captured on the protocol analyzer and the 2 yellow blocks are 2 separate stretches of time that we've captured on the scope. So we can see where the various scope captures live in relation to the protocol analyzer capture in on a time.



So I just wanted to kinda give a quick overview of what the actual test setup looks like and how the technology works before I get back into how would I use this to do something like measure L1 sub state time.



Well I'll give this example. Imagine I wanted to look at this as I'm trying to remember if this is a host or endpoint initiated entry to L1. But if I want to measure the timing exiting L1 so the time between the clock request being asserted the reference clock becoming valid and then the link finishing recovery and entering L0 entering actual active link operation.



How would I do that? And this is a measurement and a task that we've had several of our customers tell us they spent a lot of time trying to figure out how to do this.



For some reasons I'm going to explain in a little bit. So what I did was I set the triggers up like this. So on the right is the protocol analyzer screen. On the left is the scope screen. And I said when you see the clock request be deasserted so when 1 side of the link wants to enter L1 trigger the protocol analyzer to start capturing and send the trigger to the scope.



And then when you see the link when you see the clock request being asserted again so now somebody wants to come out of L1 trigger the scope again.



So even if the scope has relatively sophisticated high speed serial triggering it doesn't speak PCI Express and it certainly is not capable of saying I want to trigger once when this thing happens and another time when this other thing happens. This is far too high level of the protocol stack for the scope for any oscilloscope to be able to see your trigger on.



But with a CrossSync PHY setup we can pretty easily do this because it's a trivial matter for the protocol analyzer.



I want to end up with something that looks like this. So just to walk through what you're seeing here channel 1 the yellow one is the clock request signal. So I probed that with a very simple passive probe.



2 and 3 so pink and blue is the upstream PCIe. So lane 0 I just picked 1 lane out of the 4. I'm looking at lane 0 upstream to see what's coming from the endpoint and lane 0 downstream which is what's coming from the host.



And I'm also looking down here in green on channel 4 at the system ref clock. So that's being pulled out of 1 of those buffer ref reference clock outputs that I showed you on the interposer.



I'm acquiring all 4 of those signals in the scope. And what you can see here is there's actually a gap in between. I can just about see the clock request being deasserted and I can see it being reasserted here. Because those are the 2 things I said I wanted to trigger the scope of.



But I set the scope up. There's a lot of time in between like about 10 ms where basically nothing happened. So I told the scope I would like you to use sequence mode please and just acquire 1 segment to memory when you see the first trigger and the other segment when you see the second trigger. Because the entry to L1 and the exit from L1 are the 2 times I care. When nothing is happening in between I don't care. I don't want to waste the scope's acquisition area. So entry to L1 we can see on both of the traces so that here on the scope and here on the protocol analyzer is where the L1 entry happened.



And the same with L L1 exit. So I'm going to look a little closer at the L1 exit timing in this example.



So I'm going to go to my marker on the protocol analyzer that was saved when I triggered on the L1 exit.



So now we're zooming in a little closer.



So I've got some zooms going on the scope screen so we can zoom in on specific events.



And what I've done is I've zoomed this is where the clock request was being deasserted. So it's this point here in the timing diagram.



And I put a cursor there. And then I put a cursor when on the reference clock where the reference clock turned on and became valid again.



Now just making this measurement with a scope on its own would be fairly trivial. I could trigger the scope on the reference clock becoming with the reference excuse me the clock request being asserted and I could measure that to the reference clock coming live. And I would see 301 µs and that would be fine. That would be my T_ L10_ref_clock_on.



Where it gets a lot harder is if I want to measure from the valid reference clock to the start of recovery. Actually even that's not too bad.



I can see here I can put a cursor on the reference clock on the scope here and I can use the analyzer to see where my starter recovery happens.



And I can measure between those 2 times because the time stamps on the protocol analyzer and the time stamps on the scope or the time base on the scope are synchronized with one another.



Where it gets really tricky is if I want to measure from the valid reference clock to the start of L0 because the scope has no way of knowing when the analyzer has gone from recovery to the start of L0. We could try and decode the whole thing on the scope but I might be decoding tens of hundreds of ms of time to do that which is functionally impossible for most scopes or or potentially very difficult.



But with CrossSync PHY it's easy because I can go into the scope. I could put 1 cursor right at the start of the reference plot becoming live.



I can make note of when that time was and then I can go to the protocol analyzer search for the start of data stream packet and I can compare that time stamp to the time stamp when the reference clock started up.



And that in this case gives me a time difference of 384 µs which is pretty fast for this particular application.



But again that's that that could be a highly variable timing depending on the different hosts different endpoints.



And it's the kind of thing that is extremely painful to measure if you don't have a toolset that allows you to see the both the protocol and the electrical behavior at the same time.



So that's 1 problem we can solve by looking across multiple layers with a test setup.



Another 1 could be this. How much is my device? How much power is my device consuming in L1 compared to when it is in active use? So if I look at the timing diagram again when the link is in L0 you're going to expect fairly high power consumption. You have a reference clock. You've got high speed transceivers going in both directions on multiple lanes etcetera.



And the entire purpose of having an L1 substate is to reduce that power consumption when the device isn't run or isn't needed.



And so what I'd like to do here is understand how much power does my device consume in each state.



So in this case I'm just going to make the trigger simpler. I'm going to trigger both the protocol analyzer and the scope on entry to L1.



I'm going to configure the scope to capture a long time base.



And the setup is going to look something like this. So I'm still using channel 2 and channel 3 which are pink and blue to look at lane 0 upstream and lane 0 downstream because I want to see when the high speed link is active and when it is not active.



But I've moved channels 1 and 4 which are yellow and green to the connectors here which are the ones I talked about before that are connected to the voltage rail.



So channel 1 is looking at the actual rail voltage itself and then channel 2 is looking at the rail current. So we have a little shunt in there that gives 1 V to 1 Amp. And I've actually rescaled channel 4 appropriately so it's giving a measurement in Amps.



Then what I've done is using the math functions inside the scope I've multiplied those 2. So I have this trace down here F2 which is actually you can see it's shown in Watts here because it's the power consumption. So it's the rail current times the rail voltage.



And now I can look at how much power the link is consuming alongside the high speed lane behaviors on channels 2 and 3. But even cooler than that because I'm using CrossSync PHY I can actually look at the instantaneous power consumption at any point in the protocol trace. So on the right I have what's happening in the protocol captured by protocol analyzer. And on the left I have what's happening electrical electrically captured on the scope.



And I could even go and turn out some of my measurements. And what I know is that the average power consumption during this set of protocol interactions is about 2.144 Watts.



And this is when the link is still at L0. You can see both of the upstream and downstream signals are both running.



Now when I get actually into L1.2 we know the link is an electrical idle the reference clock is off.



And so for this whole period the power consumption has actually dropped for this 16 ms time to about just a little bit under 200 mW. So it's really reduced by more than a factor of 10.



And I can even look at the sequence of things coming back live again. Because if I look here now we're exiting L1.2. But the downstream port has become active first.



Now the thing that we're measuring the power consumption of is the endpoint which is not the thing powering the downstream port. It's powering the upstream port which is still idle. So we can see the power consumption has gone up a little bit to 520 mW. It's about 0.5 Watts now but it's not jumped all the way back up to the full operating power consumption in L0 which it does a little bit later. We're back to a little bit over 2 Watts again.



But again this is all time correlated. So everything I see on the scope side everything I see in terms of power consumption is completely correlated to what you're seeing on the right hand side in the protocol analysis window.



So those are 2 examples of how you can look across multiple layers in the PCIe interface to solve some problems or validate some behaviors or make some measurements that really are difficult or kind of functionally impossible to do with a single instrument.



Some other applications we have and we have other webinars on these are dynamic link behavior. So if you want to characterize a boot sequence look at speed changes in electrical and protocol domain. So what I'm showing you there is a link speed change from 8 GT/s to 16 GT/s.



So that's the and that's another question I've been asked very regularly. It's like how can I trigger my scope on a speed change in the PCIe link? And the answer that I had to give up until a couple years ago was unless you have active control over 1 of the 1 side of the link and could produce some sort of trigger which is something that happens in compliance testing for things like link utilization.



But if you don't have that, if you're looking at a live link between 2 devices there's no really good way to trigger on the speed change. You could potentially trigger the scope on that electric live period between the 2 speeds but the issue is that you don't know if that's actually the speed change you're looking for or if it's just some other random speed change like the ramp up from 2.5 to 5 or 5 to 8 or whatever.



Another classic one is link training. So if I wanted to see okay. My link is telling me 1 side of the link is requesting that the other side of the link change its transmitter equalization preset to P6.



The other side of the link is saying it's doing it but is it actually doing?



And the protocol analyzer does not have visibility into the actual signal shape as would be changed by an equalization request or an equalization change but the scope does. So now with CrossSync PHY I can look at both the protocol level interaction that's driving the link change behavior and the link change itself. And now that we have our new WaveMaster 8000HD we can capture 1 or even more full link training operations since they tend to take about 24 ms or potentially even longer.



So those are some examples of other things you can do with this technology and we do have other webinars on that topic.



And our webinar event and training schedule is located there TeledyneLeCroy.com/events. So you can see on demand webinars if you want to watch this again or any of our other topics. You can log in there. There's lots of great content there.



And with that I will see if we have any questions.



Thanks Patrick. Thanks everyone for attending. Before we get into the questions, just want to remind everyone that as you exit today's webinar a survey is going to pop up and we would appreciate you taking a minute to just answer those 5 questions.



If you do have any questions please go ahead and send them in. I don't see any which means you've done a really good job or they are still processing.



So if anyone has a question please go ahead and send it to me, Hilary Lustig.



You have my email address on all the confirmations and invites. So thanks everyone. We hope to see you online again soon.



Yep. Thank you everyone for joining. Much appreciated.