*Laurence H. Cooke (Independent Consultant), Martijn Goossens (Philips Research, Netherlands), Paul Hoxey (ARM, UK), Takahide Inoue (Japanese Special Interest Group, VSIA), David Overhauser (Simplex Solutions, USA), Prashant Saxena (Intel Corp, USA), and Raminderpal Singh (IBM, USA)
In this article, we present a designer's perspective to the signal integrity issues that affect authors and integrators of blocks used in System-on-Chip designs. If you look at the typical process parameters used for such designs, you'll see signal integrity issues appearing in the form of power grid noise, interconnect crosstalk and substrate coupling. In each case, we describe the problem from the point of view of chip designers (both block authors and block integrators), and describe some of the standard techniques that can be used to alleviate the problem.
Certainly, SoC design has taken many meanings for IC designers. However, for all of them, the issues of Intellectual Property (IP) block integration and verification are important problems. As technologies scale, it becomes very difficult to both design (or "author") IP blocks and then integrate them. In this paper, a background is presented on the Signal Integrity (SI) problems - power grid noise, interconnect crosstalk, and substrate coupling - that designers face and the overall need to tackle them in SoC designs. Although much of the content in this paper involves a basic understanding of SI, advanced knowledge is not a prerequisite.
Today's semiconductor fabrication technology can manufacture chips containing tens of millions of gates, thus allowing full systems to be integrated onto a single semiconductor chip. Using current Electronic Design Automation (EDA) techniques, creating such SoCs from scratch would require an army of engineers. As a result, there has been considerable effort on the development of methodologies centered on design reuse in order to minimize the amount of re-engineering of each new chip. Most of these SoC methodologies involve the selection and integration of appropriate existing internal or third party IP blocks - called Virtual Components (VCs) - based on an architecture which meets the original product requirement.
This SoC methodology effort involves the specification of standard formats and interface requirements that will ensure the successful reuse and integration of such VCs. This allows the separation of VC creation and SoC integration, and has helped legitimize the emerging third party IP business. As a result, most SoC design methodologies focus on the creation of IP libraries containing appropriately collared VCs, along with the techniques to extract and integrate these existing, qualified VCs into an SoC. By the very nature of these methods, there is considerable data hidden within the VCs. The key to successful integration is the provision of sufficient information about each VC to the integrator to allow successful integration of these components.
If the components are all soft (i.e., in an RTL format such as VHDL or Verilog), such data hiding is minimized and the blocks may be physically implemented together. On the other hand, if the VCs are hard (i.e., polygons in a layout in, for example, GDSII format), a form of block-based implementation must be used. In this case, the VCs are viewed as black boxes that must be physically integrated together. Their functional, clock, test and physical requirements must be sufficiently delineated to properly integrate such VCs with the rest of the SoC design.
As a VC block author completes the design, there is a need to "package" the design so that it is useful to the integrator. In this packaging process, the design remains unchanged, but several data views are prepared for the design. It is these views that allow the integrator to understand and integrate the design into a larger system without requiring complete visibility into the design. As SI issues become increasingly important with process scaling, the SI view of the design is also becoming an important part of the VC design. This paper therefore focuses on the data transfer involved in the creation of this view, as well as on design issues in the integration of the VC block. Figure 1 shows some of the views required for successful integration of analog (and custom) VCs.
For a detailed background (excluding SI effects) to SoC design and verification, refer to 2 and 3. For a full detailed background to SI effects, refer to 1.
Figure 1: Packaging of an Analog VC
The Target Process
SoC designs tend to be a generation or two behind leading edge designs. To help provide some context for the process parameters within which such designs are created, Table 1 shows some data in terms of current and next generation process technologies, as well as its usage model for high-performance and cost-performance applications. Most of this data has been extracted from the 1998 version of the International Technology Roadmap for Semiconductors (4).
Table 1: Snapshot of Process Data Parameters for SoC Designs
The table clearly shows why there is a growing SI problem as designs move toward 0.13 micron processes. More of the wire surface is in the side walls (with aspect ratios growing from 1.8 to 2.1) and the pitch is reducing (from 0.56 to 0.39 microns) while the switching frequencies are increasing (from 30 to 40 GHz) and chip size, which is related to wire length, grows (from 340 to 430 mm2). All of these factors aggravate the already significant crosstalk issues in 0.18 micron processes. Similarly, the reduction in voltage (from 1.8 to 1.5 Volts) coupled with the increase in power (from 90 to 130 Watts) is equivalent to a 73% increase in current (from 50 to 87 amps). This coupled with a faster clock (from 1.2 to 1.6 GHz) further stresses power distribution design. Similarly, the tripling of the logic density (from 6.2M to 18M tranistors/cm2) and memory (from 256M to 768M transistors/cm2), and their associated increases in charge and current densities, further aggravates substrate coupling issues. Thus, as shown by these comparisons, all the parameters which are thought to be improving the semiconductor processing also unfortunately worsen the SI issues.
Problems with Scaling Technologies
Table 2 shows a snapshot of the SI effects designers experience (or expect to experience) in various design types and technologies. For System-on-Chip design, these problems refer to the various IP blocks that are provided for integration. As is evident from this table, problems that are considered "esoteric" and applicable only to high-end custom designs such as microprocessors often move successively to Application Specific Integrated Circuit (ASIC) designs within a couple of process generations. Thus, one can safely predict that signal integrity issues that have been plaguing high-end microprocessor designers for several years now will also become a significant headache for ASIC and SoC designers in the near future. Figure 2 shows a snapshot of interconnect performance parameters as technologies scale. This data helps show the relative importance of the delay of the interconnect compared to the gate delay, using Aluminum and Copper metal routing with SiO2 and Low-K dielectrics.
Table 2: Snapshot of SI issues for SoC Designers
Figure 2: Snapshot of Interconnect Performance Parameters for SoC Designs
(Printed with permission of Prof. Schutte-Aine, University of Illinois)
Dealing with the power grid
The trend of increasing design size and power consumption and decreasing supply voltage (thus increasing current) is resulting in an increase in the amount of power grid IR drop and ground bounce on chips. This trend is critical as the IR drop and ground bounce noise margins are decreasing along with the supply voltage. Chip failures due to power grid issues, whether IR drop or electromigration, are already being discovered by chip designers. Since these issues are related to the number and way components are assembled on a chip and are primarily a global phenomenon, power grid analysis is becoming a required addition to many design flows. Of course, not all designs require power grid analysis, but increasing numbers are susceptible to problems.
In many designs the approach is to overdesign the power grid of the chip at the cost of metal consumption, which would otherwise be used for signal routing. The challenge facing designers is in determining how much of a power grid is actually overdesign, especially if there is no testing of the grid. As the use of more and larger components increases, this challenge becomes greater. In fact, even overdesigned grids can experience problems if the logic under the grid is not sufficiently connected to the grid (for example, due to insufficient vias from the global grid to component pins).
When components of a design do not see the specified power rail voltage, functional or timing failures will result. Functional failures result from insufficient power for the component to operate properly. Timing failures result from gate delays increasing beyond the timing requirements of the paths (and ultimately cause setup or hold failures). These failures can be intermittent if the power voltage assumption is violated only under certain operating conditions. Electromigration failures could even result in the failure of the chip at a customer site. Because power grid issues are due to interactions between components and the global integration of components, a set of interface specifications are necessary to permit the verification of the power grid by the chip integrator.
Another signal integrity issue that will soon become significant while designing power grids is that of providing adequate current return paths to counter inductive coupling. Note that the operating frequency for the purposes of inductance analysis is decided by the signal rise time and not the clock period. As ASIC and SoC designs move towards the gigahertz domain and inductive reactances start becoming comparable to resistances, it will become important to extend the current role of the power grid as a capacitive crosstalk shield to also provide shielding for inductive noise. Although solutions as extreme as power planes that have been used in some high-end microprocessor designs will probably not migrate to ASIC and SoC methodologies, recent work on templated and interdigitated routing in which a track is reserved for power after every few signal tracks seems promising for inductive noise handling in these contexts.
Power Grid Design: IP Block Author's Perspective
Component authors generally have very little information about the quality of the power supply at the pins of the component. A common methodology for SoC designs is for the component author and component integrator to agree ahead of time on the voltage to be applied to the component pins given the maximum current required by the component. A typical approach is to assume a fixed level, say 5%, of power degradation to the component. The component author then ensures that the component operates to specifications under this assumption. As components increase in size and are constructed hierarchically, it is the responsibility of the component author to modify the power degradation assumption in order to ensure that the assumptions of the sub-components are maintained as they are used in the larger components. Assuming uniform power degradation, results in conservative design (in many cases) because not all components see the fully-degraded power supply voltage. As designs increase in frequency, this conservatism leads to challenges in meeting timing closure on the chip, because the resulting overly conservative gate delays inherently limit the operational frequency of the design. Of course, for hold-time checks, one should assume best-case IR drops rather than the worst case ones that are used to determine the operational frequency.
Components are also generally designed assuming that power enters only from the power pins. A growing trend today is that this assumption is not always valid -- power commonly flows through components as well. Since the amount of current flowing through a component cannot be determined until chip integration, it should be possible to specify current limits on the component pins to make sure electromigration limits of the component will not be violated when integrated in the design.
A model is required to represent the power grid behaviors of a component. The model is created by the component author and is applied by the chip integrator. The model must provide some visibility into the component's internals. Because IR drop issues can be investigated in either a static or dynamic sense, various models of a component are possible. In a static analysis, only power grid resistance data is required of the component. In a dynamic analysis, RC data of the component is required. The model of component power consumption must be a function of the loading on the component, so that the total power consumption of the component as well as any dynamic behaviors can be derived once the component environment is determined. The component model must also be able to specify acceptable ranges of input characteristics and output loading. Dynamic modeling will result in larger data sets to represent the model.
Power Grid Design: IP Block Integrator's Perspective
In general the design of the supply nets on chip level is based on a static DC model and guided by rules to avoid "hard to analyze" complications. Depending on the application, one might need some level of AC analysis but it is quite difficult to define a general approach.
Integrators have little knowledge of the internals of components, so they might not be aware of operating assumptions the component designer made when designing the component. A common assumption is that power comes into the component, and none passes through -- this is not true in practice and has been the source of some failures.
Another common source of disconnect is related to how power ports are specified for a component. If a large component has a single long power port passing over the component, there can be questions as to how the port should be used; the various options include only a single connection at one end, connections at both ends, or additional connectivity midway as well. Since the way the component is connected to the global grid can even alter the power grid characteristics in the component (for instance, a power rung of a component can be supplemented by additional metal by the integrator), there must be some way of resolving power port usage models.
Integrators need to be able to assume that if the power noise requirements for a component are met, then the component will function properly. In order to test this, the integrator needs appropriate models of the power grid of the components as well as how the components consume power about the component. The component author may also need to be able to provide specifications as to IR drop or electromigration at various points in the component. The integrator's need for tools that are fast enough in analyzing the behavior of the chip after the components are assembled is also of utmost importance.
Finally, the power hook-up for analog components are often separate from those of the digital blocks, as shown in Figure 3. This prevention methodology is very effective.
Figure 3: Hook-up of Power for Analog Components in SoC Designs
Dealing with interconnect crosstalk
Interconnect crosstalk can be defined as any deviation from the ideal signal waveform propagating in an interconnect wire caused due to the influence of signal transitions in other wires in the neighborhood. This influence is usually due to the capacitive coupling between the victim net and one or more aggressor nets, although inductive coupling is also beginning to show up in cutting edge custom designs. Since ASIC and SoC designs tend to lag cutting edge designs by a generation or two, inductive noise is not yet a problem for these designs. Therefore, we will focus solely on capacitive crosstalk in this section, since it is felt that the detailed analysis of inductive noise in the context of SoC designs over the next few years will be important only for power grid and clock design, with inductive noise in signals being adequately controllable by a fine-grained templated power grid.
Capacitive crosstalk is manifested either as a degradation of interconnect delays resulting in a lowered operating frequency for the chip, or in outright failure of the chip. When two neighboring signals transition simultaneously, they can affect each other's slew rate (and consequently, transition delay) depending upon their transition directions, relative driver strengths and wire parasitics. Thus, two signals transitioning in the same direction will tend to speed each other up, whereas two signals transitioning in opposite directions will slow each other down. Delay degradation on critical nets can lower the operating frequency of the chip appreciably. In contrast, the failure effect is caused by the voltage pulse induced on a quiescent victim net due to one or more aggressor nets switching in its neighborhood. This pulse can cause failure due to spurious transitions in non-restoring logic such as domino circuits. Failure can also occur due to hold time violations in sequential elements caused due to signals being sped up due to crosstalk, or these accelerated signals racing through open latches.
The problem of interconnect crosstalk is getting worse with each process generation due to non-ideal scaling of wires. Since wires grow relatively narrower and taller with each generation (in order to keep their resistance manageable), the ratio of the coupling capacitance of a wire to its total capacitance is increasing with each generation. Although the move from aluminum to copper can halt this deterioration for a generation, successive generations will again have to tackle the same issues. Therefore, it is becoming increasingly important to account for coupling during timing analysis. Besides forcing the timing analysis to deal with considerably more data (on neighboring nets), the unpredictability of the transition state of neighboring nets also has the secondary undesirable effect of widening the transition windows of the signals. Furthermore, the larger error margins required in successive generations because of larger fractions of the total capacitance being (unpredictable) coupling capacitance also makes the convergence of high performance designs more and more difficult. In contrast, the number of layers does not have much of an impact on the capacitive aspects of crosstalk noise (because of the relative shielding provided to a layer by adjacent layers). However, with increasing layer count, the analysis of current return paths and inductive noise becomes more complicated.
Interconnect Crosstalk: IP Block Author's Perspective
Crosstalk coupling can occur within any pair of adjacent signals, irrespective of whether they belong to the same logical/physical hierarchy or not. Thus, crosstalk noise can occur between IP block signals routed next to each other, between chip level wires lying next to each other, or between a chip level wire routed next to a IP block wire. It is the third of these three cases that is unique to SoC designs. In each of the other two cases, the designer/integrator has sufficient design visibility and available data to analyze the crosstalk effects completely (although she may still have to deal with the data overload issue). However, in the third case, the chip integrator may not have visibility inside the IP block, and the block author may not have knowledge about the chip level environment of the block.
From a designer's perspective, unexpected crosstalk coupling from outside the IP block shows up either through increased/decreased signal delays or in functional failures. The former effect arises due to simultaneous switching in a victim net within the block and one or more aggressor net(s) in the vicinity of the block, that results in the transition within the victim being slowed down or sped up due to the coupling between the nets. The failure effect arises due to the voltage pulse induced on a quiescent victim net within the block due to the switching in one or more aggressor net(s) in the vicinity of the block. All the usual problems of interconnect crosstalk are exacerbated in SoC designs, where IP block authors may not even be aware of the aggressors that will eventually lie in the vicinity of the block.
Although the techniques used to combat crosstalk noise vary from one design/integration house to another, it is possible to abstract the issues that are common to all interconnect crosstalk scenarios. The data that needs to be communicated for effective control of crosstalk noise effects across the boundary of the IP block can be listed at a level high enough to be largely independent of the signal integrity methodologies and algorithms employed by the designers and integrators. Ideally, it includes some metrics for the maximum permissible noise (including slew and transition window requirements) at the input ports and the maximum noise possible at the output ports (including slews and transition windows and their variation with external load). The IP block author can also specify external no-fly zone/shielding requirements or the locations of crosstalk sensitive interconnect polygons (and potential aggressors, if any, for external wires). The goal is to present a simplified yet reasonably accurate model for the IP block while still preserving its gray/black box nature. In a similar vein, although crosstalk due to the board and packaging is out of the scope of this document, it is important to note that some interface modeling may be required even for these levels of the hierarchy in order to analyze and optimize crosstalk accurately.
Interconnect Crosstalk: IP Block Integrator's Perspective
From the integrator's point of view, the main difficulties in analyzing the crosstalk noise effects accurately are the lack of visibility into the IP block and the massive amount of electrical and physical interconnect data and logical/timing window data required for accurate analysis. The second of these problems is not specific to the SoC context, and must be dealt with even in flat designs (or with soft/firm IPs). However, as outlined above, one can abstract the data that should be communicated between the IP block author and the integrator in order to enable the latter to get around the first problem (viz., lack of visibility) while analyzing crosstalk effects.
Since capacitive crosstalk noise is largely a local phenomenon, the physical design of the IP block has a huge impact on the seriousness of the noise problem. If the IP is firm or soft, there are two approaches that can be used to handle crosstalk noise issues. The conservative approach is to increase the delay error bars and flag every gate that can be a potential failure in the worst possible physical realization of the IP block. However, not only is this unduly pessimistic, but it also suffers from the fact that the "worst possible physical realization" can often not be identified easily. Thus, a more realistic approach to handling firm or soft IP is for the block author to identify the set of signals (if any) that the author feels may be critical, and then communicate maximum coupling ratio or required shielding constraints for them. The integrator must then take these constraints into account while doing the physical design of the chip; the integrator's added visibility into the IP blocks will allow the application of the standard crosstalk noise methodology to the entire chip (including the IP blocks).
General Techniques for Handling Interconnect Crosstalk
The basic approaches to handling crosstalk noise are either by controlling the signal slew (by driver/receiver sizing or repeater insertion), or by reducing the ratio of bad coupling capacitance of a net to its total capacitance (by wire engineering). The first approach is usually used for timing optimization of the circuit, with its noise optimization being a secondary objective function, whereas the second approach is used specifically for noise optimization when the sizing and repeater insertion is insufficient by itself to overcome noise effects. Wire engineering can include techniques like the insertion of additional power lines for use as shields, permutation of the order of the signals in a routing region to exploit logically or temporally exclusive signals as relative shields, wire spacing, and, to a smaller effect, wire tapering. (As with sizing, the primary role of tapering is to optimize the RC delay of the wire, with noise being a secondary objective if needed). Since exact analysis and optimization of each wire is often too expensive to be practical (and is often not possible across the boundary of the IP block due to lack of visibility/information about neighboring wires), coarse level techniques like reserving an entire layer as a shielding layer around the block, or identifying specific no-fly zones above the block can be used. Furthermore, feedthroughs (due to over the block wiring) in layers that are also used by the block may be restricted to tracks that have been expressly reserved for them and certified by the block author as being safe (rather than being routed opportunistically wherever tracks are available).
A general observation is that since coupling is only going to get worse with shrinking geometries, it is more important to have a design style that focuses on reducing coupling rather than relying on measuring it accurately and then fixing problems as they occur. As mentioned earlier, capacitive crosstalk can be handled at each stage from pre-layout sizing to global routing to detailed routing. In general, crosstalk problems are difficult to identify but easy to fix early on. In contrast, they become much easier to identify as one moves down the physical design flow; however, there is correspondingly less flexibility available to fix them at these later stages.
The primary problem in analyzing crosstalk effects accurately (especially during timing analysis) is dealing with a huge amount of data (pertaining to the neighbors of victim nets). This exacerbates the data overload problem significantly, requiring a practical tradeoff between accuracy and timing analyzer capacity. Since it is usually only the largest few aggressors that result in the majority of the coupling experienced by a victim, all but the largest few aggressors of a victim can usually be ignored. Similarly, given the error bars due to the unpredictability of worst case coupling, one can usually survive with simplified 2D models for coupling (except for the most critical nets or busses that may require 2.5D or 3D modeling). Decisions about the precise number of aggressors (or the precise percentage of coupling that should be accounted for by the aggressors selected from the list of aggressors sorted in decreasing order) usually vary from design to design. Similarly, the choice of the coupling model is also usually a proprietary issue with each design house. In fact, multiple models may be used within the same design based on net criticality. However, it is often useful to handle the majority of nets that are non-critical through a simplified static timing flow and just add a margin for coupling-caused delay/speedup. Accurate analysis of the timing effects of crosstalk is considerably difficult with the static timing tools widely deployed today; one is forced to rely on heuristic weighting of the couplings (through Miller Coupling Factors) to estimate the effect of crosstalk. Therefore, critical nets need to be analyzed in more detail using dynamic timing tools (although there is the non-trivial problem of ensuring that vectors used by the dynamic validation flow indeed correspond to the worst case).
Substrate noise coupling
Substrate coupling occurs in many types of circuits, from small Radio Frequency (RF) designs to large embedded memories. The key aspect of the problem is the flow of AC currents in the substrate. These currents are generated by fast-switching (typically) digital devices. For designers, typically designs where problems occur include embedded Data Converters or memories in large ASIC or ASSP ICs.
Many designers today still design with Standard BULK (EPI) heavily-doped CMOS processes to avoid latch-up, which leads to a substrate voltage equivalent to the digital ground bounce. However, as technologies scale below 0.18 microns, designers either are deciding to design around latch-up or the supply voltage is becoming so low that latch-up becomes very hard to occur. Therefore, many designers have now returned to high-ohmic bulk substrate material. The additional benefit, next to lower process costs, is that noise propagation through the substrate is much lower, and partly controllable by guard rings. However, the rapidly increasing need for higher levels of analog and RF block integration in SoC designs - especially functional blocks such as wireless communication RF receivers at 900+ MHz - drive the substrate coupling problem up rapidly.
With all this in mind, designers are faced with a difficult problem of authoring accurate analog blocks in a digital process which will function in unknown substrate environments. This problem inherently limits how aggressive the specifications of the analog blocks can be. Moreover, the integrator of the blocks must be able to verify that the substrate noise will not cause certain blocks to fail - or at least the verification of the integrated block must be accurate and efficient - before the integrator will consider integrating the block. Currently, very little technology exists in the way of CAD (EDA) tools and methodologies, that the designer can rely upon for verification of substrate coupling in the SoC design process. This is because SoC designs tend to be large IC's, and the extraction (and then analysis) problem is mathematically intense - and sometimes complex, depending on the substrate doping layers. Thus, the practice is to use design techniques, which are discussed in this section.
Substrate Coupling: IP Block Author's Perspective
A block author needs to be careful to plan for guard rings and provide clear guidelines for the integrator to follow to allow for more robust design (see Block Integrator's Perspective below). Each of these ideas has an associated dollar cost that makes them not always possible. Often, circuits are just designed to be robust (through overdesign and differential techniques) and a lot of slack is built into the required performance specifications. However, this is very difficult to do with upcoming standards such as Bluetooth and 3G where the analog and RF blocks are very difficult to design even by themselves (since they operate at 2.45 GHz).
Many foundries are introducing options such as triple-well process for isolation on their Standard CMOS process to allow Analog/RF block integration,. Such options are very practical, although expensive. The block author can stipulate such options to the integrator, but this may limit the number of customers for the block, since not all SoC design houses are willing/able to use such options.
Substrate Coupling: IP Block Integrator's Perspective
As integration levels rise for analog, RF, and sensitive custom digital blocks, the skill base of the integrator needs to change - from predominantly understanding issues in Standard Cell ASIC block integration, involving a small number of analog blocks, to understanding the multitude of intricate power, interconnect, and substrate issues with many highly sensitive blocks. The whole parasitic model for the IC (including the package and possibly the PCB back to the power supply) needs to be modeled. Figure 4 shows a simplified view of such a model. In practice, this means that designers, typically experienced in the timing-area trade-off, now need to be equally experienced in SI issues right from the initial spec-ing phase.
General Techniques for Handling Substrate Coupling
There are a number of useful methods for reducing substrate coupling in uniform non-EPI processes:
1. Place multiple guard rings around the sensitive IP blocks to isolate them. Note that these guard rings can be noise generators themselves if poorly designed (for instance, if they are left ungrounded).
2. Ground the guard rings on dedicated bond pads and even dedicated package pins. This is not always possible, but some intelligent hook-ups can still be made to avoid connecting sensitive and noisy nets.
3. Use floorplanning intelligently to keep noisy digital IP blocks away from sensitive blocks - see Figure 5.
4. Plan the frequencies of the noisy digital clock and the analog circuitry to be different (including possible overlaps in harmonics). This is possible in the substrate, but not so much in the supply rails.
Figure 4: Simple Model of the Parasitics in SoC Designs
Figure 5: A Simplistic Approach to Substrate-aware Floorplanning in SoC Designs
Acknowledgements And References
Much of the content of this paper has been derived from ongoing work in the Virtual Socket Interface Alliance (VSIA) on the determination of Signal Integrity Specifications and Standards for SoC designs 5. The authors would like to thank Henry Chang, Chair of the Analog Mixed-Signal Development Working Group of the VSIA, for supporting this work.
1 Signal Integrity Effects in Custom IC and ASIC Designs, edited by R. Singh, IEEE Press and Wiley & Sons. Details of the book can be found at http://www.parasitics.com
2 Surviving the SoC Revolution, by H. Chang et al, Kluwer Academic Publishers, 1999.
3 System-on-a-Chip Verification: Methodology and Techniques, by P. Rashinkar et al, Kluwer Academic Publishers, 2000.
4 International Technology Roadmap for Semiconductors, http://www.sematech.org.
5 Virtual Socket Interface Alliance, http://www.vsi.org.