by Amit Tanwar and Manoj Manu, Questa VIP Engineering, Mentor Graphics
Because of the complexities involved in the entire design verification flow, a traditional Verification IP (VIP) tends to overlook the subtle aspects of the physical layer (PHY) verification, often leading to costly debug phases later in the verification cycle.
In addition, because of the several possible topologies in a PHY implementation, completely exercising the role and related functionality of a PHY becomes challenging for a traditional VIP.
Furthermore, the analog signaling and the homologous functionality of the physical layer in serial protocols, led the industry to define a common PHY that multiple protocols could use and that segregates the PHY logic from that of the general ASIC. One such common PHY is used in PCI Express, USB 3.0 and 3.1, and SATA protocols. Similarly, M-PHY is used in SSIC, M-PCIe, and LLI protocols, among others.
This article describes the limitations of a traditional VIP for PHY verification, which can typically be resolved using an exclusive PHY verification kit.
The common PHY found in PCI Express, USB 3.0 and 3.1, and SATA devices help accelerate development of these devices by implementing the physical layer functionality as a discreet IC or macro cell, which can be easily included in ASIC designs.
In bus-based layered protocols, PHY typically provides the following functionality:
- Various serial data transmission rates
- 8, 16, or 32-bit parallel interface to transmit and receive data
- Recovery of data and clock from the serial stream
- Holding registers to stage transmit and receive data
- Direct disparity control to transmit compliance patterns
- Various encode/decode and error indications
- Receiver detection
- Beacon transmission and reception
- Low Frequency Periodic Signaling (LFPS) transmission
- Selectable Tx margining, Tx de-emphasis, and signal swing values
- COMINIT and COMRESET transmission and reception
- Multi-lane de-skew
A comprehensive PHY verification plan must verify all of the PHY functionality in various conditions. However, a traditional VIP tends to miss out verifying all the functionality.
Note: In this article, the PHY features are described in the context of PCI Express and USB protocols. However, in terms of the PHY verification methodology, this article applies to all serial protocols that use a common PHY.
PHY VERIFICATION ENVIRONMENT
Usually, a PHY verification environment requires one bus functional model (BFM) at the serial interface and another at the PIPE interface.
In the following figure, the VIP acts as the USB host or the PCIe RC at the PIPE interface and as the USB device or the PCIe EP at the serial interface.
|PIPE Interface - Serial Interface|
However, in the following figure, the connections are flipped.
|Serial Interface - PIPE Interface|
Note: The VIP refers to a model that has the BFM, stimulus generator, coverage collector, and a protocol checker.
For a comprehensive verification of PHY, the testbench must enable the same stimulus to run in both cases (figure 1 and figure 2) without any required changes in the testbench.
The limitations of a traditional VIP for PHY verification can be resolved with a comprehensive and exclusive PHY verification project comprising the following phases:
- Initial Phase
- Pin Connections
- Link Up and First Transaction
- Verification Phase
- Test Plan
- Test Case
- Test Run
- Regression Phase
- Regression Environment
- Coverage Metrics
A traditional VIP focuses more on the protocol verification and provides connections for the specific configurations of the serial and PIPE mode. Moreover, because of the variety of configurations possible when setting up the pin connections, a traditional VIP tends to ignore the intricacies of an accurate PHY connection. This is a problem in the following integral areas of a design:
- Protocol specification version
- PIPE specification version
- ECNs supported by PHY
- Signals supported by PHY
- Width of each signal
- Clock frequency required by PHY
- Reset mechanism
The PHY verification kit removes these limitations by focusing on PHY connections for all possible configurations. This minimizes the risk of issues that arise out of inaccurate connections.
The following are a few examples of the error-prone scenarios that might be encountered when setting up the pin connections:
- The data pin for a 16-bit PIPE with four lanes can be declared as a single pin of 64 bits or four separate wires of 16 bits each. In a case where the data pin is declared as a single pin of 64 bits, it is confusing to find out whether the [15:8] index represents the first byte of the second lane or the second byte of the first lane. So a wrong connection, in this case, might lead the connection to link up on a fewer number of lanes than required. Debugging this issue at a later stage in the verification cycle might cause unnecessary time and efforts.
- The signal width varies across different versions of the PIPE specification. For example, TxDeemph is an 18-bit signal in the latest specification, while it was a 1-bit signal in an earlier specification. So a common mistake, in this case, is to leave the signal unconnected or to a supply bit-wise OR of 18-bit TxDeemph to the PHY.
- On the PIPE interface, some signals are shared, while some are per-lane. For example, the PowerDown signal width is 3-bit in the latest specification while it was 2-bit in an earlier specification. In this case, issues in the connection link up may occur if this signal is per-lane in the DUT and is declared as a segregated signal for all lanes. A similar issue could occur for the Rate signal, which is 2-bit in the latest specification, while it was 1-bit in an earlier specification.
- PHY can generate the clock or, alternatively, the testbench can supply the clock externally. However, a problem occurs when either of the devices misses the clock connection or there are multiple drivers on the clock. Generally, the GEN1 clock is supplied externally. When the connection speed changes, the clock remains GEN1 and causes problems.
- Leaving reset unconnected, keeping reset always on, or keeping the reset duration too short or too large are some of the common issues in the reset connection.
Note: A connection file in the PHY verification kit contains special notes for the signals whose width changed across specification versions. These special notes provide guidelines to connect a signal that requires particular attention.
There can be many other error-prone scenarios depending on the design being verified. Using a PHY verification kit minimizes the occurrence of these error-prone scenarios but cannot eradicate all the issues completely.
The PHY verification kit enables engineers to focus on the main configuration problem in PHY verification, which is to enable VIP features that are not supported in PHY.
The following are a few examples of the error-prone scenarios that might be encountered during configuration:
1) The VIP is configured for a clock frequency transition when the PHY supports changing the PIPE width during speed change. This configuration causes deadlock.
2) In the PIPE width change configuration, the engineer forgets to set the initial PIPE width at which the link up must occur.
3) Generally, MAC performs data scrambling on the PIPE interface. However, if PHY is also configured for scrambling, this configuration leads to unrecognized data at the other end.
PIPE Interface (Unscrambled Data) - Serial Interface (Scrambled Data)
4) While configuring the loopback master, the engineer configures both VIPs at the serial and PIPE interface as the loopback masters. Generally, only the VIP at the PHY side is configured as the loopback slave. The VIP at the other side must be configured as the loopback master. A wrong configuration in this case causes problems in the loopback state.
5) Generally, the LTSSM timers are configured according to the protocol specifications. A faster simulation can be achieved by adjusting the timer values according to the PHY requirements.
Configuring or debugging issues because of an incorrect or unset PHY configuration requires considerable time later in the verification cycle. Therefore, it is always recommended to set the correct configuration right at the beginning. The PHY verification kit enables engineers to set all the relevant PHY configurations right at the beginning.
After the engineer finishes connecting the pins and setting up all the relevant configurations, the next objective is to ensure the connection link up and initiate the first transaction. More often than not, most link up issues occur in the initial PIPE signal handshaking; for example, the receiver detection.
The following are a few examples of the error-prone scenarios that might be encountered during the link up process:
- No receiver detection initiative from MAC occurs because PHY configured the Phystatus signal as low.
- PHY requires another receiver detection attempt.
- PHY does not respond to the receiver detection attempt because of a reset issue.
- PHY does not respond to the change in the PowerDown signal.
- Timing of the RxElecIdle signal is not correct, which causes even the valid packet to be truncated in the middle.
- During the first equalization process, PHY does not respond because of incorrect co-efficient values.
- During the first speed change, PHY does not respond to the change in the Rate signal from the MAC.
- PHY is unable to perform a speed change in the recovery speed because of a short timer value.
The PHY verification kit provides a comprehensive troubleshooting note that helps users debug several issues in the PHY link up process and also provides timing details for each signal.
In the verification phase, the real verification process begins. Engineers follow a test plan, write the test cases, and finally run the test cases.
Test Planning, Coding, Execution
A good test plan is required to have robust test cases. The process to write test cases for a PHY is slightly different than for the physical layer of a SoC.
For example, consider a VIP that provides a test-suite for all layers. Could only the physical layer test-suite be extracted to verify the PHY? Probably yes. However, can the extracted test-suite provide a comprehensive PHY verification? Probably not, because the physical-layer test-suite targets the protocol SoC, and, in some specific cases, particular tests might not cover stand-alone PHY verification requirements. In addition, specific test cases might be required to cover stand-alone PHY verification corner cases; for example, a test case to verify whether PHY performs the frequency compensation. A PHY verification kit removes these limitations by providing a test-suite with a test plan that targets 100 percent PHY verification.
The following are a few more examples of test cases targeting stand-alone PHY verification:
- To inject a disparity error from the serial side and expect decode or disparity error code in the RxStatus signal on the PIPE side.
- To configure the serial side as the loopback master and check if PHY performs loopback after seeing the asserted TxDetectRxLoopback signal from the MAC side.
- To create some frequency difference between the serial and PIPE clock and check whether PHY performs the SKP addition deletion.
- To check for the receiver underflow or overflow situation by creating frequency differences and stopping the SKP signal from the serial side.
- To configure the serial side to perform polarity inversions on the differential pin so that the MAC asserts the RxPolarity signal. Then check whether PHY performs the polarity inversion on the data received from the serial side.
- To exercise all the power saving states to check the behavior on the electrical idle state exit and entry.
A robust regression environment ensures the following:
- The design can be compiled independently.
- The testbench can be compiled independently.
- The individual tests can be run in parallel.
- Any test failures can be easily checked and reproduced.
- Log files and waveform file names show an association with the tests.
- Individual test coverage data is saved to the universal coverage database (UCDB) format for coverage metrics.
The PHY verification kit offers a robust regression environment that ensures that any change in the design or the testbench can be easily validated by running all the tests in one go. This saves time and eliminates manual effort.
Engineers can keep track of the verification objectives with the help of functional and code coverage metrics. They can track code coverage using switches in the simulator. To track the functional coverage, they can use covergroups, coverpoints, or crosses in the verification plan.
In the verification plan, which is an XML file, all the available covergroups, coverpoints, and crosses are mapped to individual sections of the protocol specifications.
Once the required covergroups are enabled, the coverage data needs to be saved to a UCDB format to view the coverage metrics in the Questa® simulator. The UCDB is a repository for all the coverage data (including code coverage, cover directives, cover points, and assertion coverage), which is collected during simulation by the Questa platform. The Questa verification platform also enables all the coverage results to be merged in the UCDB format, which is then accessible in the Questa GUI or in the form of a log file.
Engineers can also enhance or modify the verification plan XML file according to their requirements. The PHY verification can then be signed-off once the desired coverage goal is achieved.
The limitations of a traditional VIP can be resolved using an exclusive PHY verification kit that offers the following advantages:
- Faster link up with a concurrent focus on accurate connections and correct configurations with a large number of signals, varying widths across specification versions, and complex timer configurations.
- A specific test plan, which targets all PHY scenarios, to achieve a definitive closure on PHY verification.
- A standard regression environment to run all test cases in parallel and exclusively analyze test results.
Back to Top