Abstract:
A method is described that involves identifying a subset of operational scenarios for a circuit being designed. The family of equations are solved for the circuit over the subset and the solving produces numeric values for design parameters of the circuit. The family of equations enhanced with said numeric values are solved over a remainder of the scenarios and none of the remaining scenarios are identified as being infeasible scenarios. A design for the circuit that includes the numeric values is produced.

Description:
FIELD OF INVENTION 
     The present invention relates generally to electronic design automation and more specifically to chip design by active set solving. 
     BACKGROUND 
     Previous work, such as that described in U.S. Pat. No. 6,269,277 entitled “System And Method For Designing Integrated Circuits”, has demonstrated the ease with which a circuit design can be optimized against a critical parameter (also referred to as an “objective”) using geometric programming (GP) techniques. Here, each equation in a family of equations that describe the circuit&#39;s characteristics and/or behavior is expressed in monomial or posynomial form (which for purposes of this application includes convex form) as an equality or inequality in a computer readable format (e.g., in a text file). Equations may also be expressed in signomial form (or another analytical form) if the design process is targeted to a signomial problem solver (or another solver including a general-purpose numerical optimization solver). 
     Numeric values are plugged into the family of equations for a “scenario” of the circuit&#39;s operation that specifies its operating conditions (e.g., temperature, supply voltage, input voltage, pertinent manufacturing process parameters, input/output conditions, load conditions, switch settings, etc.) and desired functional characteristics (e.g., gain, bandwidth, etc.). Equation terms within the family of equations that specify transistor level netlist details (e.g., such as transistor gate dimensions, resistance values and capacitance values) are left as “unknowns” that need to be defined in order for the circuit to meet the objective (e.g., “minimized” power consumption or size) under the scenario. 
     The family of numerically enhanced equations is then provided to a signomial or geometric optimization problem solver or generic numerical optimization solver implemented on a computing system with program code. Execution of the optimization problem solving sequence returns specific numeric values for the transistor level unknowns that satisfy the objective (e.g., minimal power consumption or circuit size) for the desired number of scenarios. Thus, the solution provided by the optimization problem solver provides details sufficient to design a transistor level netlist for the circuit. 
     A problem however is that commercial applications demand that a circuit design meet certain behavioral characteristics over a large number of scenarios. As such, an optimization problem sequence must be undertaken across multiple scenarios in an effort to confirm the circuit&#39;s adaptability to varying conditions. Often times, because of the practical difficulties associated with optimization problem solving over large numbers of scenarios, one limits the number of scenarios over which the problem is solved. As a result, one or more of the original scenarios can be infeasible and a global transistor level definition for the circuit cannot be determined over the entire range of scenarios 
     Thus, a need exists for a circuit design process that utilizes optimization problem solving techniques to produce transistor level details for a circuit that “works” over a large number of different scenarios. 
     In the field of mathematics, “robust optimization” is an optimization approach that deals with uncertainty. Specifically, in order to deal with the uncertainty, different scenarios are solved that express numeric values across the uncertainty range. Also in the field of mathematics, a process known as an “active set method” partitions inequality constraints into two sets: an active set for immediate solution and an inactive set for subsequent solution. The inactive set of inequality constraints is ignored when the active set of inequality constraints is solved. Known prior art active set methods, however, do not: 1) express equalities in the set of constraints (i.e., only inequalities are used); or, 2) classify variables within the set of constraints as being unknown and scenario dependent. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
         FIG. 1  shows a methodology for designing an electronic circuit; 
         FIG. 2A  shows an exemplary circuit; 
         FIG. 2B  shows an exemplary family of equations for the circuit of  FIG. 2A ; 
         FIG. 3  shows exemplary scenarios for the circuit and equations of  FIGS. 2A and 2B ; 
         FIG. 4  shows an optimization problem for the circuit of  FIG. 2A , equations of  FIG. 2B  and scenarios of  FIG. 3 ; 
         FIG. 5  shows an embodiment of a computing system. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows a circuit design methodology that incorporates “active set” optimization problem solving principles. More specifically, as will become more apparent in the description that follows, the methodology of  FIG. 1  is capable of defining transistor dimensions (such as gate length, gate width and number of gate fingers) for a generic circuit design that is targeted to a specific manufacturing process and is expected to sustain certain performance criteria over a number of different operating scenarios. The methodology of  FIG. 1  will be explained using, as an example, the common source amplifier circuit of  FIG. 2A . 
     According to the design methodology of  FIG. 1 , a family of equations are first articulated for an electronic circuit&#39;s operation  101 . An exemplary set of equations for the common source amplifier of  FIG. 2A  are presented in  FIG. 2B . A description of these equations is provided immediately below. 
     Eqn. 1 specifies the gain of the common source amplifier as a function of: 1) k 1 , where k 1  is a constant that is particular to the manufacturing process that the circuit is targeted to; 2) (nW/L) 0.5  where nW is the effective gate width of the amplifier&#39;s transistor (specified as the product of the width (W) of a single gate finger and the number of gate fingers (n)) and 1/L where L is the length (L) of a single gate finger; 3) (IDS) 0.5  where IDS is the transistor&#39;s DC drain-to-source current; and, 3) R L  where R L  is the amplifier&#39;s load resistance. 
     Eqn. 2 specifies the unity gain bandwidth (UGBW) of the amplifier as a function of: 1) k 1 , (nW/L) 0.5 , (IDS) 0.5  and R L  as described above; and, 2) C L  where C L  is the amplifier&#39;s load capacitance. 
     Eqn. 3 specifies the power consumption of the amplifier circuit as V DD *I DS . Eqn. 4 specifies the steady state (DC) drain-to-source current, IDS, of the amplifier&#39;s transistor as a function of: 1) k 2  where k 2  is a second constant that is particular to the manufacturing process that the circuit is targeted to; 2) (nW/L) where n, W and L are described above for eqn. 1; 3) V IN  where V IN  is the amplifier&#39;s steady state input voltage; and, 4) V T  where V T  is the threshold voltage of the amplifier&#39;s transistor. 
     Eqn. 5 specifies the steady state drain-to-source voltage, V DS , of the amplifier&#39;s transistor as a function of V DD , I DS  and R L . 
     Eqn. 6 specifies the size of the amplifier circuit as a function of: 1) k 3 , k 4  and k 5  which are third, fourth and fifth constants that are particular to the manufacturing process that the circuit is targeted to; and, 2) n, W, L, R L  and C L . 
     Thus, referring to  FIGS. 1 ,  2 A, and  2 B, the family of equations of  FIG. 2B  define  101  the operation of the amplifier circuit of  FIG. 2A . It is pertinent to point out that additional equations may be added to the family of equations, e.g., to more completely define the circuit&#39;s operating characteristics. However, in order to not obfuscate the teachings of the present application and for the sake of simplicity, the present example assumes that  FIG. 2B  provides a sufficient listing of equations for the amplifier circuit of  FIG. 2A . Continuing with the present example, referring to  FIG. 1 , once a family of equations have been defined  101  for a particular circuit, a set of operational scenarios for the electronic circuit are defined  102 . 
       FIG. 3  shows a depiction of an exemplary set of scenarios for the amplifier circuit of  FIG. 2A . As observed in  FIG. 3  there are nine scenarios where each scenario has a unique “condition set” of: (1) manufacturing process “corner” defined by specific values of manufacturing parameters which in this case would affect the values of transistor threshold voltage (V T ) and the constants k1 and k2 observed in  FIG. 2   b ; (2) temperature (T) which also affects the values of transistor threshold voltage (V T ) and the constants k1 and k2 observed in  FIG. 2   b ; and, (3) supply voltage (V DD ). The manufacturing corner of the targeted manufacturing process can be defined, for example, by three parameters: SS, TT and FF for slow, typical and fast respectively. Inset  310  of  FIG. 3  shows where scenarios 1 through 9 are positioned on a three dimensional cube defined by their respective values for each of the manufacturing corner, temperature, and V DD  parameters. Thus, designing the circuit over scenarios 1 through 9 corresponds to an attempt to “harden” or “qualify” the amplifier&#39;s design against a spectrum of environmental and manufacturing conditions that may be realized if the amplifier is actually manufactured. 
     Referring back to  FIG. 1 , a set of variables x within the family of equations is identified as being “unknown” and “scenario-independent”  103 . Here, unknown means that an ensuing optimization problem solving sequence will attempt to solve for these variables (that is, the optimization problem solving sequence will attempt to provide a specific number to each such variable). Scenario-independent means that the variables represent features that do not change from scenario-to-scenario. For simplicity, the word “term” or “variable” corresponds to a component of an equation. Thus, terms and variables appear on the right hand side of the equations presented in  FIG. 2B . 
     Typically, a circuit&#39;s set of unknown, independent variables x include its transistor level details (such as gate length (L), gate finger width (W) and the number of gate fingers (n)). Thus, typically, L, W and n are variables for which specific numeric values are sought through the optimization problem solving sequence, yet, because these variables pertain to a manufactured structure (i.e., the dimensions of a transistor&#39;s gate node) they do not change from scenario to scenario. For purposes of this example, the amplifier&#39;s load resistance (R L ) is also left as an unknown, scenario-independent variable within the equation family of  FIG. 2B  (which, again, is dependent on the dimension of a manufactured structure). In general, for other types of circuits, there can be other types of unknown, independent variables, such as settings of switches in a circuit, number of stages in an amplifier/oscillator, etc. 
     Other terms appearing within the equation family of  FIG. 2B  can be classified as “unknown and scenario dependent”, “known and scenario independent” or “known and scenario dependent”. 
     In the case of terms that are “unknown and scenario dependent”, the optimization problem solving sequence provides specific numeric values for these terms, but, the numeric values provided by the problem solving sequence can change from scenario to scenario. Typically, unknown and scenario dependent terms correspond to operating voltages and currents within the circuit. The unknown and scenario dependent terms observed in  FIG. 2B  are I DS  (which appears in eqns. 1 thru 4) and V DS  (which appears in eqn. 4). Thus, the ensuing optimization problem solving sequence will solve for these terms, but, clearly, these values will change over the temperature, supply voltage and threshold voltage variations encompassed by the set of scenarios. The “unknown and scenario dependent” variables can be collectively referred to as yi, and, the I DS  and V DS  components of yi are identified as such in  FIG. 3 . In general there can be other types of unknown, dependent variables, such as device capacitances, transconductances and other device characteristics, etc. 
     Typically, “known and scenario independent” terms correspond to known details of the targeted semiconductor manufacturing process (or, at least terms that are based on such details) or a designer specified value that remain constant over design scenarios. Examples of known and scenario independent manufacturing process details include constants that determine physical dimensions of the circuit. The “known and scenario independent” terms observed in the equation family of  FIG. 2B  that pertain to the semiconductor manufacturing process include constants k 3  through k 5 . Also, for this example, the amplifier&#39;s load capacitance C L  is a known and scenario independent variable because it is designer specified and capacitance are assumed to not vary from scenario to scenario. Also, because the steady state and small signal input voltages (V IN  and v in ) are designer specified and assumed fixed for the present example, they are also identified as “known and scenario independent” terms. The “known and scenario independent” terms can be collectively referred to as u 0  and are identified as such in  FIG. 3 . 
     Typically, “known and scenario dependent” terms correspond to known details of the targeted semiconductor manufacturing process (or, at least terms that are based on such details) or a designer specified value that take different values over design scenarios. Examples of known and scenario dependent manufacturing process details include materials employed by the process, dopant levels, etc. The “known and scenario dependent” terms observed in the equation family of  FIG. 2B  that pertain to the semiconductor manufacturing process include constants k 1  and k 2 . Other known and scenario dependent terms include threshold voltage (V T ) and supply voltage (V DD ) (note that temperature can be introduced into a scenario definition through actual expressions of V T , k 1  and k 2 ). The “known and scenario dependent” terms can be collectively referred to as ui and are identified as such in  FIG. 3 . 
       FIG. 4  shows an exemplary embodiment of the specification for a scenario as it is presented to a optimization problem solver (such as a signomial problem solver or a geometric programming problem solver or general purpose optimization solver). Here, note that the behavioral characteristics of equations 1 through 3 of  FIG. 2B  are restated as inequalities. That is, the GAIN is restated to be any value greater than 2.0, UGBW is restated to be any value greater than 100 MHz and POWER is restated to be any value less than 10 mW. SIZE is stated as the objective. As such, in the present example, an attempt is being made to minimize the surface area consumption of the circuit in view of: 1) the designer specified “constraints” for GAIN, UGBW, POWER, CL (designer specified to be 2 pF in view of eqn. 8), V IN  (designer specified to be 1.0 V in view of eqn. 7) and v in  (designer specified to be 0.0 V in view of eqn. 9); 2) the remaining known scenario independent values u0 k 3  through k 5  (specified in equations 10 through 14); 3) the known scenario dependent values specified in equations 15 and 16 (and equations that include k1 or k2). 
     Here, if the specification of  FIG. 4  is presented to a optimization problem solver with the x and y terms left unspecified, the optimization problem solver will “solve” the specification for the scenario by calculating numeric values for the x and y terms that correspond to the minimum size of the amplifier where the designer specified behavioral constraints and the u0 and u1 constraints are not violated. 
     Thus, continuing with the discussion of the design methodology of  FIG. 1 , once the family of equations ( FIG. 2B ) and scenarios ( FIG. 3 ) are defined  101 ,  102  for the circuit under design, the unknown and scenario independent variables x within the circuit are identified  103  and a subset of the scenarios are identified  104 . Some degree of intelligent selection of scenarios may be used to identify the subset of scenarios. For example, according to one embodiment that uses the following scenario defining parameters: 
     A. Corner={Typical-Typical, Slow-Slow, Fast-Fast} 
     B. Temperature={Nominal, Hot, Cold} 
     C. V DD ={Nominal, High, Low} 
     D. Reference Current={Nominal, High, Low}, 
     the following seven scenarios are identified in Table 1 below as the initial subset of process  104 : 
                                                     TABLE 1                       1   2   3   4   5   6   7                       Corner   TT   SS   SS   SS   SS   FF   FF           Temp   N   H   H   C   C   H   C           Vdd   N   L   H   L   H   H   H           Iref   N   L   H   H   H   L   H                    
Note that the above table refers to a more generic set of known scenario dependent parameters than the example being discussed herein in that, the above table refers to a circuit&#39;s reference current Iref value and the exemplary amplifier being discussed herein does not include a reference current (Iref) parameter. As such, note that embodiments to which the above table refers defines seven, specific scenarios from a larger field of scenarios at process  104  of  FIG. 1 .
 
     By contrast, the more simplistic amplifier example being discussed herein only includes three known, scenario dependent parameters (corner, temp and Vdd). Each of the seven scenarios identified in the above table are observed in  FIG. 3  however. As alluded to in more detail below, for the simple amplifier example of  FIG. 3 , a subset of the scenarios identified in the table above may be used in process  104  of  FIG. 1  rather than all seven (e.g., three scenarios from the above table may be selected from  FIG. 3  at process  104  of  FIG. 1 ). A common choice of scenarios for this simpler case would be scenario 1, 2 and 7 in the above table. Note that in general Iref is the reference bias which is used in many analog circuits to determine the bias point of the circuit. Note also that additional/different scenario dependent process parameters are possible (such as multiple reference currents, load values, etc.) in which case the table above would be expanded or modified. 
     After the subset of scenarios is identified, an optimization problem solving sequence is undertaken  105  that concurrently solves the family of equations over the limited subset of scenarios. Here, for instance, the solving process that transpires over the limited subset of scenarios  105  may be undertaken by submitting a specification, such as that observed in  FIG. 4 , to optimization problem solver for each of the scenarios (where equations 15 and 16 are refitted with new values for each scenario within the limited subset). 
     The solution provided by the optimization problem solver produces specific values for the x terms (which can be referred to in regards to the present example as W — 1, n — 1, L — 1 and RL — 1) and y terms. That is, at this point, the x terms can be tentatively labeled as “known” rather than “unknown”. For instance, if scenarios  1 ,  2  and  7  are identified in process  104  as the subset of scenarios, the result of the optimization problem solving sequence of process  105  may produce the following “optimal” results: W — 1=15 μm; n — 1=2; L — 1=1.8 μm; RL — 1=1.70 kΩ. 
     The family of equations within the scenario specifications are then adjusted to include these specific numeric values for the x terms and another optimization problem solving sequence  106  is undertaken over the remaining scenarios that were not identified in process  104  in order to check the feasibility of the solution for x provided by process  105 . The main goal in process  106  is to determine whether there is a value of y_i for each of the remaining scenarios that produces an optimal solution given the fixed set of values x found in process  105  (i.e., process  106  checks to see if “feasible” solutions exist for the remaining scenarios using the values for x determined in process  105 ). In this example, the remaining scenarios correspond to scenarios  3  through  6  and  8 . 
     The optimization problem of process  106  is different from the optimization problem of process  105  in the fact that process  105  solves all scenarios concurrently while process  106  solves each scenario individually (e.g., one after another). At the conclusion of the second optimization problem solving sequence  106 , either  107  all scenarios have been solved for optimally (in which case the design of the circuit is complete  109  because an optimal solution has been reached for all scenarios over a consistent set of scenario independent terms x and u0), or, an optimal solution could not be obtained for one or more of the remaining scenarios. Such scenarios are referred to as “infeasible” scenarios. For instance, assume that scenario 3 could not be optimally solved with the W — 1, n — 1, L — 1 and RL — 1 values specified above. 
     If infeasible scenarios exist, the infeasible scenarios are effectively added to the original set of scenarios identified in process  104  to create an expanded subset of scenarios. Continuing with this example, to form the expanded subset of scenarios, scenario 3 would be added to scenarios 1, 2 and 9. The expanded subset of scenarios (in this case scenarios 1, 2, 3 and 9) are then solved  105  with the x terms having been reverted back to unknown variables that the optimization problem solving sequence  105  solves for. Thus, a second set of specific numeric values are produced for the x terms (W — 2, n — 2, L — 2 and RL — 2) at the completion of the second execution of process  105 . Assume these are W — 2=17.4 μm; n — 2=2; L — 2=2.1 μm; RL — 2=1.77 kΩ. 
     Again, the family of equations within the scenario specification are adjusted to incorporate the numeric values for the W — 2, n — 2, L — 2 and RL — 2 terms and the family of equations are re-solved with an optimization problem solving sequence  106  over the remaining set of scenarios (in this case scenarios 4 through 8). Here, the remaining set of scenarios used for the second execution of process  106  (scenarios 4 through 8) is smaller than the set of scenarios used for the first execution of process  106  (scenarios 3 through 9) owing to the removal of the initially infeasible scenario(s) (scenario 3). The feasibility of the remaining scenarios is checked  107  and the process repeats. 
     As such, the design methodology revolves around generating (with process  105 ) specific numeric values for x terms by solving a family of equations over a subset of the total collection of applicable scenarios. The remaining scenarios are then solved (with process  106 ) with the newly calculated numeric values for the x terms incorporated into the family of equations to see if they “hold” (i.e., optimal solutions for the remaining scenarios are obtained). 
     If the numeric values for the x terms do not hold, the infeasible scenarios are added to the subset of scenarios used by process  105  to generate a new set of numeric values for the x terms and the process repeats. Here, by repeatedly expanding the subset of scenarios used to calculate numeric values for the x terms with scenarios for which an infeasibility was flagged, a form of feedback is introduced into the design methodology that either “zeroes in” on a set of numeric values for the x terms that work for all scenarios, or, results in the design being deemed infeasible when considered across the collection of scenarios. 
     It is pertinent to point out that the incorporation of equalities into a robust, active set optimization problem are believed to be novel, non obvious innovations by themselves. 
     A few implementation specifics are worth mentioning. Firstly, the manner in which the initial subset of scenarios is identified  104  may vary from embodiment to embodiment. According to a first approach, a designer (e.g., through a graphical user interface (GUI)) or automated software program simply guesses at one or more suitable scenarios. According to a second approach, a designer or automated software program identifies a scenario representative of nominal values (e.g., scenario 1 in  FIG. 3 ) or worst case values or combination of the two. 
     Additionally, referring to  FIG. 1 , processes  101  and/or  102  may involve some manual efforts (such as derivation of the equations specified in process  101  by hand and/or manual submission of specific scenarios or components thereof). However, each of processes  103  through  108  is capable of being fully performed in software through execution of program code on a computing system. Moreover, in assisting the automated software implementation of the teachings herein, the family of equations specified in process  101 , the set of operational scenarios of process  102  (including a scenario specification such as the scenario specification of  FIG. 4 ) can each be tangibly embodied (e.g., in a file and/or text document) stored on a machine readable storage medium as described further below Likewise, once the design methodology produces a consistent set of transistor level details for a circuit under design, the transistor level details can be incorporated into a transistor level description (such as a transistor level netlist) or mask set description (e.g., in GDS-II format) and stored on a machine readable storage medium. 
     Processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine that executes these instructions to perform certain functions. In this context, a “machine” may be a machine that converts intermediate form (or “abstract”) instructions into processor specific instructions (e.g., an abstract execution environment such as a “virtual machine” (e.g., a Java Virtual Machine), an interpreter, a Common Language Runtime, a high-level language virtual machine, etc.)), and/or, electronic circuitry disposed on a semiconductor chip (e.g., “logic circuitry” implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative to a machine or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code. 
     It is believed that processes taught by the discussion above may also be described in source level program code in various object-orientated or non-object-orientated computer programming languages (e.g., Java, C#, VB, Python, C, C++, J#, APL, Cobol, Fortran, Pascal, Perl, etc.) supported by various software development frameworks. The source level program code may be converted into an intermediate form of program code (such as Java byte code, Microsoft Intermediate Language, etc.) that is understandable to an abstract execution environment (e.g., a Java Virtual Machine, a Common Language Runtime, a high-level language virtual machine, an interpreter, etc.) or may be compiled directly into object code. 
     According to various approaches the abstract execution environment may convert the intermediate form program code into processor specific code by, 1) compiling the intermediate form program code (e.g., at run-time (e.g., a JIT compiler)), 2) interpreting the intermediate form program code, or 3) a combination of compiling the intermediate form program code at run-time and interpreting the intermediate form program code. Abstract execution environments may run on various operating systems (such as UNIX, LINUX, Microsoft operating systems including the Windows family, Apple Computers operating systems including MacOS X, Sun/Solaris, OS/2, Novell, etc.). 
     An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable storage media suitable for storing program code. 
       FIG. 5  shows an embodiment of a computing system (e.g., a computer). The exemplary computing system of  FIG. 5  includes: 1) one or more processors  501 ; 2) a memory control hub (MCH)  502 ; 3) a system memory  503  (of which different types exist such as DDR RAM, EDO RAM, etc,); 4) a cache  504 ; 5) an I/O control hub (ICH)  505 ; 6) a graphics processor  506 ; 7) a display/screen  507  (of which different types exist such as Cathode Ray Tube (CRT), Thin Film Transistor (TFT), Liquid Crystal Display (LCD), DPL, etc.; 8) one or more I/O devices  508 . 
     The one or more processors  501  execute instructions in order to perform whatever software routines the computing system implements. The instructions frequently involve some sort of operation performed upon data. Both data and instructions are stored in system memory  503  and cache  504 . Cache  504  is typically designed to have shorter latency times than system memory  503 . For example, cache  504  might be integrated onto the same silicon chip(s) as the processor(s) and/or constructed with faster SRAM cells whilst system memory  503  might be constructed with slower DRAM cells. 
     By tending to store more frequently used instructions and data in the cache  504  as opposed to the system memory  503 , the overall performance efficiency of the computing system improves. 
     System memory  503  is deliberately made available to other components within the computing system. For example, the data received from various interfaces to the computing system (e.g., keyboard and mouse, printer port, LAN port, modem port, etc.) or retrieved from an internal storage element of the computing system (e.g., hard disk drive) are often temporarily queued into system memory  503  prior to their being operated upon by the one or more processor(s)  501  in the implementation of a software program. Similarly, data that a software program determines should be sent from the computing system to an outside entity through one of the computing system interfaces, or stored into an internal storage element, is often temporarily queued in system memory  503  prior to its being transmitted or stored. 
     The ICH  505  is responsible for ensuring that such data is properly passed between the system memory  503  and its appropriate corresponding computing system interface (and internal storage device if the computing system is so designed). The MCH  502  is responsible for managing the various contending requests for system memory  503  access amongst the processor(s)  501 , interfaces and internal storage elements that may proximately arise in time with respect to one another. 
     One or more I/O devices  508  are also implemented in a typical computing system. I/O devices generally are responsible for transferring data to and/or from the computing system (e.g., a networking adapter); or, for large scale non-volatile storage within the computing system (e.g., hard disk drive). ICH  505  has bi-directional point-to-point links between itself and the observed I/O devices  508 . 
     It is believed that processes taught by the discussion above can be practiced within various software environments such as, for example, object-oriented and non-object-oriented programming environments, Java based environments (such as a Java 2 Enterprise Edition (J2EE) environment or environments defined by other releases of the Java standard), or other environments (e.g., a .NET environment, a Windows/NT environment each provided by Microsoft Corporation). 
     In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.