VIP verifies PCI Express

At that time, I did wonder to myself "How would one go about verifying such a beast?" But what with "this and that" my musings drifted away onto my mental back-burner until I became aware of a rather cunning offering from Denali Software Inc.

Interestingly enough, although the majority of design engineers are aware of Denali, many tend to think of them only in the context of verification intellectual property ("verification IP", or VIP for short) as it pertains to memory interfaces, devices, and subsystems. And of course those engineers who focus on a design's core "secret sauce" logic have more than enough things to worry about without spending time wondering how the guys and gals working on memory subsystems perform their magic. As fate would have it, however, Denali's expertise in memory VIP has given them the basis for a jolly interesting VIP solution for interfaces.

Sad but true

Most of us have heard, and few would argue, that the functional verification of one of today's extremely large and complex digital integrated circuit designs can account for anywhere between 60% and 80% of the device's total development cycle. Considering this level of investment, it is somewhat surprising to hear that around 43% of design re-spins can be directly attributed to problems that remain undetected or overlooked by the functional verification process.

But we're already overworked (and underpaid), so what more do they — whoever "they" are — expect us to do? Well, as fate would have it, the vast majority of designs make use of standard interfaces and protocols. Such interfaces present a major opportunity to isolate and solve a large proportion of functional verification problems by leveraging interface-based VIP created by a third-party specialist with a high level of domain-specific knowledge.

Introducing PCI Express

One such interface is PCI Express, which is intended to provide the extreme data bandwidths required by high-end applications such as servers and 3D graphics subsystems.

The original peripheral component interconnect (PCI) standard defined a 32-bit (4-byte) bus running at 33.33 MHz, which could therefore provide a peak data transfer rate of only 133 megabytes-per-second (MB/s). This was later enhanced to a 32 or 64-bit bus running at 33.33 or 66.66 MHz, thereby providing a peak data rate of 533 MB/s.

In turn, this was followed by the peripheral component interconnect extended (PCI-X) standard, whose 64-bit bus running at 133.33 MHz offered a peak transfer rate of 1.06 gigabytes-per-second (GB/s). And this standard was eventually subsequently superceded by a "double pumped" version called PCI-X 266 (or PCI-X DDR), which offers a peak transfer rate of 2.13 GB/s.

The problem is that it's becoming increasingly difficult to route these multi-bit parallel busses at the circuit board level while keeping all of the tracks the same length and impedance. The solution is to move to a serial data communications technology such as PCI Express. A single PCI Express "lane" employs a brace of differential pairs to provide a point-to-point connection between two devices; one to transmit and the other to receive data (Figure 1).

Figure 1 — A single PCI Express "lane"

Depending on their requirements, some devices will be able to make do with a single lane. Such a lane can support up to 250 MB/s of real data communications in both directions simultaneously, which equates to a total bandwidth of 500 MB/s. Some devices may require two, four, or eight PCI Express lanes to provide additional bandwidth, while very high-end subsystems may demand 16 lanes. Known as 16x PCI Express, such an implementation provides a data bandwidth of 4 GB/s in both directions simultaneously, which equates to a total bandwidth of 8 GB/s.

Chips and cards based on the PCI Express interface are scheduled to appear on the market in 2005. Thus, all of the mayor system houses are currently designing PCI Express-based products. Not surprisingly, the PCI Express specification is complex and huge; comprising over 1,000 pages (500+ pages for the core specification and 500+ more pages in the form of underlying specifications, addendums to the main specification, and so forth).

In addition to requiring a tremendous amount of domain-specific knowledge, the task is compounded by the fact that each chip design may feature a different subset of the specification. This obviously makes verifying any particular implementation against other offerings extremely difficult. Even worse is the fact that, at the time of this writing, no one in the field actually has any working PCI Express silicon, which makes verifying that a given design will work with externally created devices and systems something of a problematic task.

A cunning PCI Express VIP solution

And so we come to Denali's offering, which comprises a number of different elements. First of all there is something called PureSpec, which we might think of as a bus functional model (BFM) on steroids.

At the core of PureSpec is a highly configurable (strongly parameterized) compiled C/C++ model. This model accepts high level transaction requests from the outside world in the form of the verification environment and converts them into the "bit twiddling" values used to drive the PCI Express interface. Similarly, the model will accept bit-level signals from the interface and translate them back into high level transactions that can be processed by the verification environment (Figure 2).

Figure 2 — Core PureSpec functionality

The verification environment can also query and modify the state of the model, including register and memory values, queues, and data packets, and it can also inject errors to see how the target interface responds. (PureSpec also includes interfaces to transaction and coverage databases.)

In addition to addressing every functional aspect of the PCI Express specification, PureSpec also comes equipped with a library of 1,000+ assertions defined using Accelera's property specification language (PSL). (Additional user-defined assertions can be imported as required.)

One key aspect of this PureSpec model is that different features can be configured or turned on or off to implement any allowable subset of the PCI Express specification. The mechanism by which this is achieved is rather clever. Let's assume that you are creating your own PCI Express interface from the ground up, and that you wish to implement your own particular subset of features. In this case, you would start off by accessing a generic "all-singing-all-dancing" configuration file from the Denali website.

This XML-based configuration file is in a format known as a specification of modeling architecture (SOMA). You then use the PureView application from Denali to access the contents of this file and to configure, enable or disable the various features so as to define the subset of the specification in which you are interested. You also use PureView to select the HDL of interest (Verilog or VHDL) and the simulation engine that is to be used (ModelSim, NC-Sim, VCS).

PureView uses this information to generate a new SOMA file containing any modifications made to the original SOMA file along with an RTL shell in the language of your choice tuned for the simulator of your choice. In addition to the pin/port definitions and a reference "pointing" to the corresponding SOMA file, this shell contains a call to the PureSpec utility by means of the appropriate programming language interface (PLI), foreign language interface (FLI), or VHDL procedural interface (VHPI) as dictated by your target language and simulator (Figure 3).

Figure 3 — Using the PureView GUI

Now this is where things start to get really cunning. Let's assume that you are designing an ASIC that contains a big chunk of your "secret sauce" logic and your PCI Express block, both captured in RTL (there would of course be other data and memory interfaces, but let's keep things simple). If we also assume that the PCI Express subset you've decided to implement is called Subset-A, then the first thing you might do is to invoke a single PureSpec instantiation based on a corresponding Subset-A SOMA file (Figure 4).

Figure 4 — A simple PureSpec scenario

As we've already noted, you could use your existing verification environment to pass high level transaction requests into the PureSpec model, which will then perform the "bit twiddling" communications with your PCI Express interface logic block specified in RTL.

But wait! PureSpec also comes equipped with an associated automatic test generation application called PureSuite. This little rascal — which can work in conjunction with your test environment or as a pure standalone utility — comes equipped with 5000+ base tests, each of which can be enabled or disabled (via a control file) individually, as classes, using wildcards, and so forth.

Furthermore, PureSuite looks at your Subset-A SOMA file and customizes its tests accordingly so as to employ only those tests that actually make sense. In this context, the phrase "make sense" obviously refers to generating tests that "stay inside the bounds" of your interface subset, but it also includes tests that "go outside the bounds" in order to verify the DUT's responses to error conditions.

OK, now let's consider a slightly more complex scenario, which is that you intend to connect your ASIC to a PCI Express interface from another system house who have implemented some "Subset-B" of the specification. The idea here is that, in the same way that memory vendors provide SOMA files corresponding to their devices, system houses will provide (via Denali) SOMA files corresponding to their PCI Express subsets.

The end result in this new scenario is that you may end up with two PureSpec instantiations. One of these will be a fully-fledged model using the Subset-B SOMA file to implement the third-party's interface. The other instantiation — customized using your Subset-A SOMA file — might be attached to your RTL block as a shadow monitor model (SMM). In this case, PureSuite will customize its tests based on what makes sense for these overlapping subsets (Figure 5).

Figure 5 — A more sophisticated PureSpec scenario

Of course there are a number of PCI Express VIP solutions around with varying levels of sophistication. At the present time, however, the folks at Denali say that PureSpec solution has been adopted by 9 out of 10 design IP vendors along with 23 out of the 25 top system houses who are currently designing their own PCI Express interface blocks. This obviously means that Denali is doing something right, which is why PCI Express is only the first of many high-end interface specifications that they are going to address using this methodology.

As one final point to consider, Denali notes that specification committees defining next-generation interfaces may consider using this approach to define and proliferate executable specifications so as to speed the deployment and adoption of these interfaces. All of which has given me much food for thought, so I have no hesitation in awarding PureSpec (and its compatriots) an official "Cool Beans" from me. Until next time, have a good one!

Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.