Fixing Signal Integrity Issues in Software?

Thursday, August 9, 2018

Yes, you read that right. Unheard of? Read on.

The history of electronics is checkered with many things that should have caught on, and others – like the internet – that surprised us with their ubiquity. This post is about something I expected to become one of the greatest boons for Signal Integrity (SI): SerDes Equalization Settings (SES, only accessible through software). I was wrong.

You’d be surprised to learn how many of my customer’s SI issues – particularly those in the field - I’ve fixed in software. Crosstalk issues even; can you believe it? Yet to me, even more surprising has been the overwhelming majority who are uninterested in optimizing and programming the settings. You see, after 30+ years of solving SI issues in hardware (e.g., terminations, 3D solvers, controlled impedance, length matching, etc.), sheer momentum has prohibited us from recognizing a gift horse when it came along. You adapt the hardware to the I/O and not the other way around, right?

Because the SES wound up as bits in firmware their power is rarely exploited. There have been those who bravely tried to adjust the SES, yet were unable to navigate their company’s Hardware/Software organizational divide to get a couple bits flipped in the bowels of a mysterious register – the power of which was understood only by the SI engineer. If the SES were hardware pin strappings accessible to the schematic team no doubt they’d be used more often.

So why are all those SES there? Thousands of combinations even? They are the fodder of brilliant SerDes designers who set out to make a single IO that could handle a variety of system implementations and serial standards. Oddly enough, making the SerDes enormously adaptable was substantially simpler than understanding the system requirements. And then there’s the FPGA SerDes Transceiver that has to handle any and every system scenario anyway.

In my observation, success in using the SES has been limited to the very small or very large companies; the former because the same engineer manages both the PCB and the firmware, and the latter because achieving 150% more design margin in their high-volume products is relevant amidst a myriad of manufacturing tolerances. Perhaps you will be among those who succeed as well. My hope is to motivate you to do so.

 

What’s more important? …Hardware or Software?

You don’t have to work in electronics very long to wind up in that debate. In this section, I’ll ask that question as it relates to serial links. You might be surprised by the answer.

Part of why my company specializes in Serial Links is because I have found them to be robust, extensible, and even elegant technology – particularly when compared with their uglier cousin, DDRx. I have found the hardware/software aspects of the technology to be quite interesting, and have felt for a while now that – while there are a few important things to know and do in hardware (the subjects of my other posts) – the dominant factor affecting performance is the software, or the SES. To illustrate my point, I constructed a simple serial link using modern PCB materials (Dk=3.4, Df=0.008). Driving the link at 8 Gbps with one default-ish post-cursor of Tx equalization (30%) and no Rx EQ, Figure 1 shows eye performance to be essentially flat as the link grows from 2” to 20”. What?! That’s a 10x variation in the hardware’s trace length. After years of trying to shorten and/or match traces to 5 mils, here’s technology that doesn’t seem to care much about length.

 
 

Figure 1: Eye Height/Width vs Channel Length, Hardware Flexibility

 

While Figure 1 suggests the layout team can miss by an order of magnitude, Figure 2 shows that the software team must be much more careful. Suppose there’s a firmware update in which the software team innocently flips a bit or two and incorrectly applies the default Tx “post” cursor EQ to the “pre” cursor, perhaps mis-reading a spec intended for the “+1” tap and gives it to the “-1” tap. After all, what do “taps” have to do with a software stack anyway? In this scenario, Figure 2 shows a 3x decrease in performance throughout the same channel length variation of Figure 1.
 

Figure 2: Eye Height/Width vs Channel Length, Software Inflexibility

 

So let’s see, a 7% performance variation against a 10x change in hardware (Figure 1) versus a 300% performance variation due to a couple register bits in software (Figure 2). How could that be? Is this really a fair comparison? You can decide for yourself, but after working with these technologies for a couple decades I believe it is. Either way, if I’ve spurred you to manage both the hardware and software aspects of link performance we both win.

 

Using Software to Improve SI Performance and/or Fix Problems

The examples above illustrate the power hiding in the SES; power you can unleash to substantially improve or fix your design. In this section, instead of thinking about what can go wrong when adapting the SES let’s have a look at what can go right.

Freezing the channel in the above examples at a typical length of 4”, the first eye in Figure 3 (left) reveals the channel is significantly over-equalized with the default SES. This is generally the case in many shipping systems that use default SES, as IC companies have found over-equalization to offer ~acceptable – albeit non-optimal – performance that is impervious to hardware implementation variation, as shown in Figure 1. The unfortunate side effect is over-driven (noise=crosstalk) signals that sacrifice performance and power. This is illustrated in Figure 3, as turning off the SES either doubles eye margin (center) or cuts power in half with 20% better eye margin (right) when reducing Tx voltage amplitude to 50%.

 

Figure 3: Using Software to Achieve 2x Eye Margin or Power Reduction.

 

As the improvements shown in Figure 3 can be achieved in most systems, why is this not happening? True to the history of SI, many hardware teams need to get stung before applying repellent, while others simply do not realize how much SI performance optimization is hiding inside the chip (SES=Software). For this reason, we documented how adapting the SES can achieve performance gains up to 200% across a wide variety of channels (slides 11-18) or 3x-5x improvements when using PAM4 (slide 19). We also teach a class at DesignCon that helps you learn how to optimize the SES through understanding which types of EQ to apply when, using techniques described in this paper (pages 15-18).

 

In Conclusion

It’s important for Hardware and SI Engineers to understand how to optimize SerDes Equalization Settings (SES) to both fix problems and improve system performance. While some standards and systems aspire to automagically optimize the SES using software routines at boot-up, experience suggests human beings are more successful. Why not give it a try? Assuming you have access to QCD, download the Project file I used to create the Figures above and explore software’s (SES) impact on hardware performance. It’s simpler than you think.

          
Donald Telian, SiGuys - Guest Blogger 8/9/2018

Add your comments:

Items in bold indicate required information.