Using HSPICE StatEye to Tackle DDR4 Rail Jitter

The world is a risky place, according to Scott Wedge, Principal R&D Engineer at Synopsys, who presented at the Synopsys HSPICE SIG on Feb 2[SUP]nd[/SUP] in Santa Clara. Indeed, the world circuit designers face can be uncertain. Dealing with risk and departure from ideal was a main theme in the fascinating talks at this dinner event, which is held every year in conjunction with DesignCon. Scott focused on how it is possible to overcome uncertainty through predictability.

Scott talked about new features in HSPICE that can help designers do their job better and work to manage that risk. Sources of uncertainty can come from variability and mismatch. Then over time MOS aging can contribute to reliability issues down the road. With smaller Vdd, circuits are more vulnerable to noise and jitter. The list goes on. Shortly I’ll get back to one of his items – noise effects that can lead to higher bit error rates in high speed data paths.

There were two customer presentations as well. One from Xilinx on how Synopsys worked with them to create new modeling methods to enable advanced node designs. The other customer presentation was from ARM where they discussed large scale Monte Carlo simulation methods.

John Ellis from the Signal and Power Integrity (SPI) Group at Synopsys gave an impressive presentation titled “Simulating Power Supply Induced Jitter Effects in Low BER DDR4 Interfaces Using StatEye”. While this is quite a mouthful, the title makes very clear what the subject matter of the talk was. With DDR4 and LPDDR4 there is now an explicit BER requirement. Brute force simulation of 10^16 bits leaves two choices: an eternity of SPICE runs, or the use of a Linear Time Invariant (LTI) environment in a statistical simulator. We are caught between the need for transistor level accuracy and the overwhelming time requirements of traditional SPICE.

John’s approach is to leverage HSPICE StatEye functionality to capture simultaneous switching output (SSO) effects – including rail jitter. StatEye at its most basic can rapidly capture the pulse response from an LTI system. This approach works well for modeling the datapath for LPDDR4. However, there is more at work here that the data path by itself. Fortunately, it is possible to use HSPICE StatEye to model nonlinear effects as well.

The question he posed is: Can we capture SSO performance adequately? His approach is to include the IO model in the StatEye simulation. By adding it to the channel, it is possible to include it in the pulse response – which will be affected by the IO voltage. Drawing the IO current from a non-ideal supply path with rail noise creates a nonlinear response with the output distorted by SSO noise.

SPICE simulations show differing edge response times for rise and fall when the model is nonlinear. Standard StatEye misses these effects. Synopsys StatEye can model nonlinearities with “Multi-Edge” or “Full Transient” mode. Each has its advantages and limitations.

Multiple Edge response requires one simulation for each edge. Each response can be saved for future use to shorten run times. Clearly with the addition of each edge response the HSPICE StatEye better matches the SPICE results.

Full Transient response gives a probability density function (PDF) based on an arbitrary bit stream. However, it cannot be saved and must be rerun for each case. This will serve as a good starting point to see how well we can model the effect of rail jitter on the data path. If this works, Multiple Edge Response is a possible route to increased flexibility and speed.

John’s presentation included details about the simulation model set up for DDR4. Then he showed how rail noise of around 13% will affect the reference SPICE runs. He compared the “Full Transient” mode of HSPICE to SPICE in predicting rail noise and saw good correlation. If this did not work, the subsequent analysis based on this nonlinearity would not be useful.

Next he compared HSPICE StatEye in Full-Transient mode for the full datapath including the rail noise to his SPICE results and saw good agreement in the horizontal and vertical openings. VREF was shifted somewhat. Next he worked to include more realistic triggering by factoring in DQS, including jitter. This does require two StatEye runs, but the results are impressive. The first run is used to generate the jitter function and the second one applies this to the full channel. The results are definitely better.

The next steps were to apply the Multiple Edge mode to the same case. Rather than attempt to cover the details here, I would suggest viewing the entire presentation, along with the others from the meeting.

The end results show that by applying HSPICE StatEye with its full capabilities to power and signal integrity problems like this can yield significant insight into system performance. This in turn, can help reduce risk in high speed designs by factoring in real world effects during the design and verification stages of product development.