The challenge of verifying the evolving Ethernet standard
We all live in a sea of data these days, and transferring, manipulating and storing it presents an increasing challenge for network designers, system architects and SoC developers. The uptake of the Internet in an ever widening set of applications, ranging from home audio-video through cloud computing to automotive, is fueling demand for greater bandwidth.
The industry workhorse Ethernet standard has been regularly upgraded and extended, and now spans from 10Mbit/s up to 100Gbit/s and beyond – with the highest throughputs in demand for applications such as server virtualization, cloud computing, network fabric consolidation, and high-performance computing.
Working with such a rapidly evolving standard presents two challenges: developing blocks that can implement the standard in all its complexity and at very high data rates; and verifying its implementation both as a standalone block and as a block within an SoC.
Verifying fast Ethernet
How do you verify the adherence of your block and/or your SoC to all the detailed protocol and performance requirements of the Ethernet standard? In general, the process can be broken down into four steps.
First, build and configure a verification environment, and develop a test plan and the required test sequences. Second, check for protocol correctness, using a combination of complex scenarios, corner cases, rich protocol checks, and data-integrity validation schemes. Third, debug your design, for which you will need fast root-cause analysis, and checks on whether your results are matching your requirements. Fourth and finally, check for coverage closure, measuring your progress, identifying holes in your verification coverage, and developing strategies to close those holes.
You can build your own verification environment for Ethernet implementations, but with the standard’s complexity, it is probably better to use tried and tested verification IP (VIP) that has been tuned for performance and ease of integration.
Complex test scenarios
Why? A life-like test scenario for an Ethernet implementation needs to simulate the effect of running applications as diverse as VoIP, IPTV, Internet gaming, cloud computing and QoS management and more – simultaneously. A verification environment should be able to look at how this mix of protocols and traffic affects issues such as device resets, link loss, lane ordering, the deskew process, and clock jitter and drift resulting in loss of synchronization.
Verification schemes need to check end-to-end data integrity – to ensure that what was in the packet when it was sent is what is in the packet when it arrives – on a frame-by-frame basis. Verification also needs to be able to handle upper layers of the Ethernet protocol. Networking chip companies are now designing Layer 3 and 4 (network and transport) management in hardware, so verification schemes need to be able to generate such traffic and decode the resultant frames. For widest applicability, they should also handle proprietary and custom Ethernet frames.
It is also important to verify multi-lane packet processing, with lanes of varying widths, and the way in which QoS features for prioritizing time-sensitive data have been implemented. Flow control and low-power modes will also need checking, including features such as PAUSE commands and priority-based flow control that regulate traffic flow to ensure frames are not dropped.
Power-management features that enable an Ethernet-connected device to identify whether or not a link is active need verifying, as do lane synchronization and alignment features that enable devices to understand each other’s capabilities and set up communications. Verification IP should be able to generate corner cases on lane synchronization, and then check whether characteristics such as start of packet, block lock, and alignment markers are being handled correctly.
Scrambling algorithms are a key part of the PCS/PMA aspects of Ethernet, and are required for DC balancing. Since they are so foundational to the Ethernet link’s data integrity, these blocks should be validated early in the design bring-up.
VIP should also be able to validate approaches to link training and auto-negotiation, generating random auto-negotiation commands and checking that the subsequent handshaking is handled properly. Similarly, forward-error checking algorithms and transcoding strategies also need validating.
Why use VIP in such a scenario? Directed verification strategies, in which you write a test to cover one condition, and then write another test to cover the next condition, and so on, mean that you’re delivering results from the moment your first test runs. Constrained random verification strategies, on the other hand, involve undertaking some work upfront to create your verification environment, during which no results are delivered. However, once the environment is configured, you can make progress towards your verification goals much more quickly than with a directed approach. If you combine a constrained random strategy with the use of VIP, you get the double benefit of faster testbench setup times, and faster progress once configured.
Customers use Synopsys VIP for validating Ethernet implementations at both the block and SoC level (Synopsys uses it in its own IP development). With the increasing number of scenarios in which Ethernet can be applied within a block or SoC, and the rising complexity of the resultant serial interfaces, we’ve had to focus on four key performance aspects of Ethernet VIP: the time it takes to get to the first test; the time it takes to verify; the time to debug; and the time to achieve the required coverage.
Figure 1 The Synopsys approach to verification IP (Source: Synopsys)
We’re addressing ‘time to first test’ by including a configuration creation GUI, a built-in test plan, and sequence-collection features in the VIP to help people get to grips with a protocol with which they may not be familiar.
‘Time to verify’ has been addressed by writing our VIP in System Verilog, which means it can run natively in simulators, rather than having to be converted from other formats on the fly or run from within ‘wrappers’.
‘Time to debug’ is being reduced by including protocol-aware debug facilities in the VIP. And ‘time to coverage’ is addressed with built-in coverage metrics, tied into a verification plan and test suite.
Synopsys has a suite of Ethernet VIP and directed test suites that address the latest versions of the standard. To find out more, click here.
Watch a webinar on this topic here.
Shenoy Mathew is a senior corporate application engineer in the Verification Group, Synopsys. He joined Synopsys nearly 10 years ago and now helps support customers deploying verification solutions using advanced methodologies and tools. Mathew holds an MS in VLSI-CAD and a BS in electrical and electronic engineering from the Bangalore University in India.