Verification Challenges of High Speed Interfaces

Manmohan Rana, Nitin Pant, Garima Jain, Gautham Harinarayan (Freescale Semiconductor)

Introduction

The SOCs designed these days have a wide range of functions and find use in a wide variety of applications. These SOCs are highly integrated so as to reduce the cost and number of board components required. In addition to several Digital IPs, they also contain on-chip Analog IPs like Power Management Controllers, Data Convertors and Clocking Circuits, etc.

They may also need to interface with external device like one or more Cameras, Flash drives, Radio Tuners, DDR memories, etc. This necessitates the need for High Speed I/O Interfaces like JESDPHY (used for Radio Interface in Infotainment chips), USB (Universal Serial Bus), MiPi (Camera Interface for active safety parts), DDR (Double data rate), etc. These interfaces are usually verified in a digital environment. But these interfaces also include critical analog components like PHYs, pads, transmission lines and termination resistors.

All these interfaces are data transfer mediums and hence rely on the accuracy of the data being sent and received. This data is prone to corruption through the communication path. This path is analog in real life, but is instead in digital in the usual verification environment. This leads to a loss of coverage, leaving critical unseen defects during pre-Silicon verification. Later, these bugs appear as unwanted surprises during post-Silicon validation.

A robust AMS verification methodology is required to check many electrical parameters of these analog components in an integrated SoC environment. With these analog elements in SPICE, SoC level AMS simulations become extremely slow when using non-Fast-SPICE simulators. This leads to impractically long run times and eventually limits the scope of verification. By using a Fast-SPICE simulator we were able to take part of the subsystem in SPICE at the standalone level. Such a setup provided very reasonable runtimes. This paper talks about the Pre-Si verification challenges of JESDPHY, USB PHY; the solutions we came up with; and the bugs that were caught in the early in the design cycle with our approach.

1. USB PHY Wakeup protocol and its verification

The remote Wake-Up protocol using USB involves the waking up of the SoC through specific Wake-Up pads. The stimulus for Wake-Up is received from the complementary device (or host) with which the host (or device) in the design is communicating. The USB PHY was simulated at the standalone level. A VCD (value change dump) was created from the stimulus provided at the pad level in the SoC Verification testbench.

This VCD stimulus was then given to the USB PHY at the standalone level. The complete wakeup protocol is a two way handshake process. On account of huge run-times, we limited ourselves to simulating only an initial wakeup stimulus to the PHY and reading its first response. This output from the USB PHY then goes to the controller and eventually to the processor. Using this approach, it is possible to verify that the first response of the PHY to a wakeup stimulus is correct. And so the intended outcome which is the waking up of the SoC through the Wake up pads does happen. In the real world the connection of the USB device at the available port, for instance in the Infotainment block of an automobile, makes the whole block come out of its low power states and makes it fully functional. This is possible also the other way, the connection of the host to a device can also be the source of a wakeup.

Figure-1.USB PHY - Top level block diagram of USB subsystem as part of the SOC

Figure-2.USB PHY - Top level block diagram of USB PHY and its components

2. JESD PHY, its design challenges and bugs found

In our case, the JESD PHY was used for data reception from one or more off-chip radio tuner devices in an infotainment chip. JESD subsystem follows a handshake based protocol. First a serial data stream is sent into the subsystem from a verification IP placed in the testbench. This initial serial data which is known before hand is sent into the subsystem to check that the system is ready for the reception of real data. When this data reaches the JESDPHY, the PHY gets locked onto this data. This lock is then propagated further into the JESD Controller as an indicator to complete the communication loop. Finally, a SYNC signal is created, that is used to convey to the VIP in the testbench that the subsystem within the SOC is ready for the reception of the actual data. In our verification environment we took the JESD PHY in SPICE and took the stimulus in the form of a VCD (value change dump) from the SOC level test cases. We verified the behavior of the lock signal which is the output of the JESD PHY.

Figure-3.JESD PHY - Top level block diagram of JESD subsystem as part of the SOC

Since the JESDPHY was a third party IP, circuit level design know-how was limited. On running SPICE simulations of this IP we understood the importance of the termination resistance. It was found that when this IP is enabled the end to end swing of the signals coming into the IP is made almost half. This was conveyed to IP owner. Refer to Figure-4.

Another issue found with the JESDPHY was that the lock signal (which is the output of the PHY) was found to unexpectedly toggle. This signal was later found to be dependent on the precision of clock frequency. Refer Figure-6.

Finally, it was also found that if the data goes to zero in the middle of the handshake communication, even then the lock signal did not de-assert. Figure-5 and Figure-6 are waveforms of this issue, the only difference between the two being in terms of the simulation accuracy settings; the waveform in Figure-6 is the one with higher accuracy.

At the subsystem level this lock signal is used by the JESD controller to complete the feedback loop. It then gives the final indicator to the Verification IP present in the testbench that the subsystem is ready for data transmission. So the lock signal is a very important part of the handshake protocol. If the lock signal does not de assert with zero data input to the PHY this would basically mean that during the handshake the controller remains oblivious of the fact that there is no data. Had these issues not been found in SPICE simulations in pre-Si verification they would have surfaced only during Post-Si validation.

3. Results

Figure-4. JESD PHY termination resistance impact and clock sensitivity

Figure-5. JESD PHY toggling of the lock signal

Figure-6. JESD PHY lock remains asserted with no data and then toggles.

​

4. Conclusions

We have discussed the importance of Pre-Silicon Verification in ensuring a highly functional silicon. We emphasized on the verification challenges of a couple of High Speed Interfaces, namely, JESD PHY and USB PHY.