Challenges in HyperTransport Verification

Challenges in HyperTransport Verification
As HyperTransport technology becomes more mainstay in the communication sector, verification becomes a bigger issue for communication chip and equipment designers. Users must be aware of the adjustments that will be needed to create a viable test bench to verify designs employing HyperTransport.

To do so, they must build or purchase a solid bus functional model (BFM) and deal with HyperTransport specific issues such as transaction reordering, response delay and control, bus data monitoring, and transaction tracking. They must also have the tool flow in place to deal with these issues effectively.

In this article, we'll layout five key verification challenges that designers will face when implementing HyperTransport technology. During the discussion, we'll explore how a BFM can be used to address each one of these problems.

1. Testing Bus Initialization
One of the biggest challenges in verifying a HyperTransport device is testing initialization, including device enumeration, clock and bus width programming, configuration space testing, and address decode. At a software protocol level the HyperTransport bus appears nearly identical to PCI, but at the bus level, bus initialization and transaction protocols are new and challenging.

Cold and warm reset as well as the assertion of the LDTStop signal for clock and link width programming, are initialization protocols that are particular to HyperTransport. Clock speed and link width settings must work properly every time for a chip to function correctly, so these functions must be tested rigorously.

To ensure that bus initialization is working properly, it is important to build a mechanism into the BFM that enables robust testing of various clock frequencies and bus widths. One way to do this is to actually build the HyperTransport compatibility registers into the BFM, and include the ability to dynamically change the link width and clock programming.

2. Ordering Rules
The HyperTransport I/O ordering rules are one of the most interesting features of the interface. The protocol is versatile in that it allows chips to perform data reordering, split transactions, and packet insertion for bandwidth optimization, thus eliminating inefficiencies in data packet delivery and routing.

But potential problems can arise from misuse of these techniques. If a designer doesn't anticipate all potential problems that can arise, verification can be incomplete. A designer must anticipate all of the different ways that data can be delivered and proactively address them. Possible problems can include buffer overflow, incorrect delivery of data, or accidental over-writing of valid data.

To adequately deal with HyperTransport's distinct I/O ordering rules and address the potential problems of buffer overflow, incorrect data delivery, and over-writing of data, a comprehensive BFM should perform automatic packet reordering, random NOP/broadcast insertion, and random response packet insertion.

An example of how a BFM automatically reorders packets can be seen in Figure 1. In this figure, five non-posted writes occur with incrementing SrcTags to create a transaction stream. Due to various response delay timings, the target response transactions come back out of order.

Click here for Figure 1
Figure 1: To support HyperTransport's ordering rules, the BFM must provide a mechanism for reordering packets, such as the one shown here.

Response re-ordering can be controlled in a model via SrcTag and unit ID. The BFM can model response delay using a transaction's SrcTag and UnitID to select a specifically programmed response delay value, then delay the transaction by the appropriate amount. The response delay controller in Figure 1 shows the parallel nature of response delay buffer. This mechanism allows a user to simulate responses from fast and slow devices in the system.

For instance, a test could be written such that SrcTags 1-10 correspond to a slow IIC type peripheral device and SrcTags 20-31 correspond to a fast memory like an SDRAM. Transactions can come back out of order because reads from the IIC type device would come back very slowly whereas SDRAM reads and writes may come back very quickly.

3. Buffer Control,br> Buffer control is also a challenge in HyperTransport. If the HyperTransport host bridge is not functioning properly, it may cause data overflow in downstream buffers, or if a downstream device is malfunctioning, deadlock conditions may occur. Buffer control is a critical function that must be thoroughly verified.

Problems in testing buffer control will always be unique to a particular design and are often best found through random test generation. The more varied the stimulus used to test for buffer control, the higher the probability that all corner cases will be found. To thoroughly perform these tests, an application-specific test generation tool is necessary.

Figure 2 shows a test generation tool that has both tunnel and bridge interfaces. In this case, basic directed Verilog tests could be used to begin preliminary tests of the HyperTransport bus interface. Once base line functionality is demonstrated, the test generation tool can be used to create exhaustive random bus traffic.

Click here for Figure 2
Figure 2: Test generation too with both a tunnel and bridge interface.

The test generation tool highlighted here employs a multi-threaded test engine for creating very random test behaviors and performs automatic read and write checking via a shadow memory. It provides simple file based control via weighted tasks, random seeds, and other methods, as well as statistical reports with transactional coverage metrics. Verification languages add features to ease test bench development, but the test bench still must be developed.

4. Broadcast tracking
Broadcast tracking presents yet another verification challenge for designers turning to HyperTransport technology. HyperTransport devices signal interrupts using interrupt packets to the host bridge. A HyperTransport host bridge signals End Of Interrupt (EOI) using unique packets called broadcasts. These broadcasts must be passed from the host bridge to every device on the HyperTransport fabric. And if an upstream device does not propagate the broadcast downstream, communication failures may occur. Therefore, it is critical verification that engineers run tests to confirm that all broadcast packets are properly received by all devices.

To test for broadcast tracking, a BFM should provide random no operation (NOP)/broadcast insertion as well as broadcast delivery-checking capabilities. If you are testing a tunnel device where the test bench includes a host bridge model and a single-link model connected at either end of the tunnel device, it is critical to test that all broadcast packets are delivered successfully. The tunnel device must accept the broadcast packet as well as forward it downstream.

Figure 3 shows how random NOP/broadcast insertion and broadcast delivery checking can help in HyperTransport verification. In this figure, a user test performs a double word write followed by a non-posted double word read and then another non-posted double word read. What might actually appear on the transmit bus is the WriteDW header, followed by the ReadDW header, then part of the WriteDW data, followed by automatically inserted NOP and broadcast packets. A read response from a prior transaction is also inserted, and so on.

Click here for Figure 3
Figure 3: Example of a BFM delivering NOP/broadcast insertion and broadcast delivery checking capabilities.

Figure 3 shows that through a comprehensive model, a user can write a very simple transaction, and the model will automatically insert the other transactions necessary for thorough verification. The user test stays simple, but the transaction can be quite complex. The BFM can allow users to enable or disable the various packet insertion modes.

A model should also allow users to control the rate of NOP and broadcast packet insertion, controlling how read responses are inserted. By default, read responses can be aggressively inserted at legal packet boundaries.

5. Skew Testing
Skew testing can also be a big headache during the HyperTransport verification process. HyperTransport allows for a significant amount of clock skew between clock and data and between adjacent byte lanes, as well as between clock and control signals.

Clock skew is caused by a long signal propagation time from sender to receiver. It is critical at these high speeds that engineers ensure signals are skewed across the allowed range to prove that the bus is properly receiving signals and data on the proper bus cycles. These propagation delays do not exist in a typical simulation environment and therefore must be proactively introduced into the simulation environment.

A good BFM should give the engineer programmable clock skew control so it can be randomized in their test suite. It should allow the verification engineer to dynamically vary the clock skew from clock to clock, clock to control, and clock to data.

Wrap Up
We've addressed just a few of the challenges presented to engineers when verifying HyperTransport-based designs. When verifying any design, a team must decide whether to create or purchase the verification tools it will use. If the required verification tools don't exist, the decision is simple. Several different vendors offer verification tools for HyperTransport designs, so it isn't necessary for a team to develop the tools themselves, but some teams may still decide to do so.

As designs become more and more complex, and as interconnect standards and buses more plentiful, verification becomes increasingly more challenging. Designers can't be experts with every standard and its unique challenges. And considering the challenges particular to HyperTransport, purchasing the verification IP that has been tested and proven is probably the wisest decision.

About the Author
Ty Sell is a senior member of the technical staff at TransEDA. Prior to joining TransEDA, he served as a senior member of the technical staff at iMODL and president of Bolder Design Labs. Ty holds a BS in electrical engineering technology from DeVry University and can be reached at ty.sell@transeda.com.