Sequential structure extraction by functional specification

A method and apparatus for structure analysis of a circuit design are described. In one exemplary embodiment, a functional specification of a circuit design is received, where the functional specification is defined based on a behavior layer abstraction. In addition, design codes for the circuit design are received, wherein in each design code of the design codes is defined based on the behavior layer abstraction. Furthermore, the design codes are searched, which is performed in the behavior layer abstraction, for one or more of the design codes that satisfy the functional specification. Each of the design codes that satisfy the functional specification is therefore recognized.

FIELD

The disclosed embodiments relate to circuit design, and more particularly to the structure analysis of a circuit design.

BACKGROUND

Traditional circuit static analysis works on netlists generated by logic synthesis. This circuit analysis attempts to identify structure patterns by traversing the netlists generated by logic synthesis. A netlist describes the connectivity of an electronic design. Netlists usually convey connectivity information and can provide instances, nets, and perhaps some attributes. Netlists have an abstraction layer that is structural, because netlists describe connectivity of an electronic design. The major ingredients of the netlists are logic elements, such as the flip-flops and the combinatorial gates, and their connectivity.

Current circuit structure analysis tools work on netlists synthesized from codes in hardware description language. The structure pattern matching procedures are implemented manually. One has to develop matching algorithms for each structure pattern. This approach is not flexible. Given the design variants and the differences in synthesizers, it is easy to miss or falsely recognize some structure patterns.

SUMMARY

A method and apparatus for structure analysis of a circuit design is described. In one exemplary embodiment, a functional specification of a circuit design is received, where the functional specification is based on a behavior layer abstraction. In addition, design codes for the circuit design are received, where the each of the design codes is based on a behavior layer abstraction. Furthermore, the design codes are searched for one or more design codes that satisfy the functional specification. This search is performed in the behavior layer abstraction, in one embodiment. Each of the design codes that satisfy the functional specification is stored, in one embodiment.

DETAILED DESCRIPTION

Embodiments of the present invention disclose improved methods and apparatuses for performing structure analysis of a circuit design by performing a sequential structure extraction by functional specification. In one embodiment, the structure analysis is performed by receiving a function specification of the circuit design as well as a number of design codes for that circuit design. The functional specification is checked to see if this specification is realizable. If the functional specification is realizable, a Mealy machine for the functional specification is created. In addition, corresponding Mealy machines are created for each of the design codes. The Mealy machines for the functional specification and the design codes are based on the behavior layer abstraction, which describes the behavior of the circuit. With the Mealy machine for the functional specification and the design codes, a search is performed to determine which Mealy machines of the design codes refine the Mealy machine of the functional specification. The design codes that refine the functional specification are identified. In one embodiment, these design codes are stored for later use. While in one embodiment, a Mealy machine is created for the functional specification and each of the design codes, in alternate embodiments, different types of state machines may be used for the functional specification and/or the design codes (Moore machines, etc.).

A circuit structure analysis tool can work on netlists synthesized from codes in a hardware description language. Given the design variants and the differences in synthesizers, this tool can miss or falsely recognize some structure patterns.

FIG. 1illustrates a process flow diagram of a process100for performing a workflow of a clock-domain-crossing synchronizer detection. InFIG. 1, process100begins by receiving a register transfer level (RTL) design abstraction at block102. In one embodiment, the RTL is a design abstraction which models a synchronous digital circuit in terms of the flow of digital signals (data) between hardware registers, and the logical operations performed on those signals. In this embodiment, the RTL abstraction is used in hardware description languages (HDLs) to create high-level representations of a circuit, from which lower-level representations and ultimately actual wiring can be derived.

At block104, process100infers the hardware. For example and in one embodiment, process100runs a hardware inference on the RTL design codes following the industry standards, such as IEEE 1364.1-2002, 1076.6-1999, etc.

At block106, process100generates the netlists. In one embodiment, process100generates the netlists for the RTL design abstracts. In one embodiment, netlists have an abstraction layer that is structural, because netlists describe connectivity of an electronic design. Process100determines the clock origin or domain inference at block108. In one embodiment, a clock domain is a part of a design that has a clock that operates asynchronous to, or has a variable phase relationship with, another clock in the design. At block110, process100extracts the clock domain crossing (CDC) information. In one embodiment, process100extracts the CDC information by identifying clock domain crossing paths and linking related paths into groups (e.g., data path and control paths of a mux-synchronizer).

Process100verifies the CDC at block112. In one embodiment, process100verifies the CDC using verification in the behavior layer at block118. In one embodiment, this verification uses the design, generated assertions, and user specified input/output environmental constraints. Process100, at block114, filters the results of the verification at blocks112and118for CDC violations.

In one embodiment, process100analyzes a results database to filter out false CDC structural violations. False CDC structural violations are those CDC violations that are identified by the verification, but that do not violate the actual constraints of the circuit. In one embodiment, the results database includes user-generated templates that are used to filter out false CDC structural violations. At block116, process100performs an error fix, to remove the false CDC structural violations from the filter. In one embodiment, an uncovered pattern may cause a false violation, and this can lead to lost time for debugging of the pattern and updating of the results database.

The workflow illustrated inFIG. 1has several shortcomings. In particular, the structure patterns of CDC synchronizers are hand-coded. This can mean that pattern matching procedures must be implemented for various kinds of structure patterns. In addition, an uncovered pattern may cause missing or false violations that take time to correct, by debugging the static verification tools and making patches. In addition, this determination is not self-contained. Without the behavior layer verification at block118, the static structure analysis tool gives a partial analysis. The use of the static structure analysis tool may require extra skills and processes for a user to have a complete static structure check.

Furthermore, the static structure analysis tool and behavior results verifier works on different abstract layers. The results verifier works on the behavior layer, but the traditional static structure analysis tool works on the netlist layer. On the one hand, the behavior layer describes the behavior of the electronic design. On the other hand, the netlist layer is a structural abstraction layer because netlists describe a circuit using the connectivity of an electronic design. In one embodiment, this can make it difficult to construct a finite state machine from the netlists for behavior verification. In addition, violation filtering occurs after violation detection. It would be better if the structure analysis can pass the acceptable structures during the violation detection stage, instead of detecting false negatives after the violation detection stage.

As described above, the current workflow for a static structure analysis tool has several shortcomings. The Sequential structure Extraction by Functional Specification (SEFS) aims at a search engine that determines which signals form design codes such that the driving machines of selected signals can enforce the satisfiability of a realizable specification. In one embodiment, the selected output signals are outputs of sequential logics. SEFS amounts to locating the driving machines of the selected outputs. As described above, the current circuit structure analysis tools work on netlists synthesized from codes in hardware description language. Given the design variants and the differences of synthesizers, the tool can miss or falsely recognize some structure patterns. SEFS brings flexibility to structure analysis by allowing more design freedom. SEFS ignores certain structural variants and still is confident in labeling machines with a design pattern, provided the behavior of the design pattern can enforce the specified functionality. Thus, SEFS promotes the abstraction layer of circuit structure analysis from netlists to behavior layer. In addition, if the user composes a specification of unwanted behaviors, SEFS can automatically locate the corresponding codes in this design. In one embodiment, SEFS can be used for reactive control circuits, such as reactive control circuits that implement a communication protocol. For example and in one embodiment, a CDC synchronizer is a reactive control circuit that implements a communication protocol.

In one embodiment, a SEFS process is as follows. SEFS checks the realizability of a controller specification. A controller specification is unrealizable if the working environment has a strategy to falsify the proposed behavior of the controller. If the controller has a functional specification that is unrealizable, SEFS does not continue further. For a realizable functional specification, there could be winning strategies with which the controller can enforce the satisfiability of the specification. The SEFS generates a Mealy machine, named as Master Plan, which encodes all the winning strategies of the controller. SEFS enumerates the machines in the design codes and checks whether the selected machines refine Master Plan by giving a stronger output letter on common input letters. In one embodiment, a letter refers to a value combination of variables under study. An input letter is a value of input variables. For instance, suppose the inputs are {a, b, c} and all of them range over {0, 1}, then <0, 1, 0> is an input letter denoting a=0, b=1, and c=0. One or more of the design codes that refine the Master Plan are labeled as instances of the specification. SEFS, in one embodiment, carries out the refinement reasoning on the products from the design machines and the Master Plan. While in one embodiment, a Mealy machine is created for the functional specification, in alternate embodiments, different types of state machines may be used for the functional specification (Moore machines, etc.).

FIG. 2illustrates a process flow diagram of a process200for performing a sequential structure extraction by functional specification, according to one embodiment. InFIG. 2, process200begins by receiving a functional specification at block210. In one embodiment, the functional specification describes the functions that are desired for the designed circuit. In this embodiment, the functional specification can include an interface for input and output, assumptive properties over the input ports, and guaranteed properties over the output ports. For example and in one embodiment, a functional specification of a controller describes the interface signals and the behavior properties. The behavior properties include the assumptions regarding the working environment of the controller and the guarantees, which guarantee how the controller will behave.

Listing 1 illustrates an exemplary functional specification of a synchronizer,

// always eventually there will be a request

// req should hold on if there is no grant

// req should be de-asserted one cycle after the assertion of grant

// grant should follow the rise of req

// the duration of holding grant is between 1 to 5 cycles

// no new assertion of grant until a new req

Listing 1. Example of a Functional Specification for a Controller

In Listing 1, the synchronizer has an input signal req and an output grant. It is also driven by a synchronous clock clk. The environment controls the input signals. The synchronizer updates the output signals. The assumptions A1, A2, and A3 specify the assumed properties over req, and the guarantees G1, G2, and G3 specify the behaviors of grant. In one embodiment, the sync_spec can be interpreted as the Equation (1)
(A1^A2^A3)=>(G1^G2^G3)  (1)

In this embodiment, the signals reg, grant, and clk are not bound with any actual signals in a design. Furthermore, in on embodiment, the sync_spec is a template. SEFS fills the template with a binding between the design signals and specification signals such that the behavior of the selected outputs can enforce the satisfiability of Equation (1). If there does exist such a signal binding, SEFS returns with an instance as illustrated in Equation (2),
sync_spec_instance_1 (.clk(test.LCLK), .req(test.req_0), .grant(test.grant_0))  (2)

In one embodiment, Equation (2) illustrates that once hclk, req, and grant are bound with actual signals LCLK, req_0, and grant_0 from design module test, then the selected signals LCLK, req_0, and grant_0 make up an instance of sync_spec.

At block212, process200checks the realizability of the functional specification. In one embodiment, a functional specification is realizable if there are winning strategies with which the controller can enforce the satisfiability of the specification. In contrast, a controller specification is unrealizable if the working environment has a strategy to falsify the proposed behavior of the controller. In this embodiment, process200does not have a way to figure out the controller for an unrealizable specification and process200does not need to look for machines for the specified functionality.

In one embodiment, the functional specification realizability check uses forward and backward algorithms to determine realizability. For example and in one embodiment, the backward algorithm is compact in representing the search space. In this example, the forward algorithm may not be that compact, but the forward algorithm is able to record the good actions against the input alphabets for the reachable states. In one embodiment, these algorithms assume that the controller plays first and the environment plays second. In this embodiment, a Mealy machine is synthesized from a realizable specification.

At block214, process200determines if the functional specification is realizable from the results of block212. If a specification fails the realizability check, process200reports the failure and exits at bock218.

If the specification passes the realizability check, at block216, process200generates a Mealy machine for the functional specification. In one embodiment, the Mealy machine for the functional specification is termed a Master Plan. This Master Plan is used for the proposition binding search of the Mealy machines generated at block206. In one embodiment, the proposition binding search is a Mealy machine comparison algorithm. In this embodiment, the Master Plan is a Mealy machine generated for a realizable specification. In one embodiment, the Master Plan is complete in the sense that it captures all the strategies of a controller to enforce the satisfiability of a functional specification.

In addition, at block202, process200begins by receiving design codes at block202. In one embodiment, process200receives the design codes that are in the form of a hardware description language (HDL). In one embodiment, the design codes are in the form of an HDL, such as Verilog, VHDL, SystemVerilog, and/or other hardware description languages, whether known in the art or later developed. At block204, process200converts the design codes to Mealy machines. In one embodiment, a Mealy machine is a finite-state machine whose output values are determined both by its current state and the current inputs. In one embodiment, process200stores the Mealy machines at block206. While in one embodiment, a Mealy machine is created for each of the design codes, in alternate embodiments, different types of state machines may be used for the design codes (Moore machines, etc.).

At block208, process200performs a proposition binding search using the Mealy machines of block206and the Master Plan from block216. In one embodiment, the proposition binding search enumerates the output bindings. For each binding, process200verifies that the binding refines the Master Plan. In one embodiment, process200performs a Mealy machine refinement check after the calculation of the dependency context. The algorithm for Mealy machine refinement check determines if Mealy machine M1refines Mealy machine M2if each reachable state q of the product machine from M1and M2has an output letter for each input letter. Process200further reduces the check to the satisfiability check. In one embodiment, ForwardExp gives the next state of <q1, q2> under the input letter σI2. If the expression is unsatisfiable, in this embodiment, there is no output letter leading to a next state of <q1, q2> under σI2That means the product machine <M1, M2> cannot move forward under σI2starting from <q1, q2>. And M1fails in refining M2. Embodiments of the proposition binding search are further described inFIG. 4-6below.

As noted in connection withFIG. 1, the traditional static structure analysis workflow is a workflow that works on different abstract layers. In contrast, the sequential structure extraction by functional specification process ofFIG. 2is a process that works on entities in the behavior abstract layer. In one embodiment, the sequential structure extraction by functional specification can be applied to a workflow of clock-domain-crossing (CDC) synchronizer detection.FIG. 3illustrates a process flow diagram of a process300for performing a workflow of detecting a CDC synchronizer with a sequential structure extraction by functional specification, according to one embodiment. In one embodiment, process300utilizes the sequential structure extraction by functional specification of process200to perform the workflow.

Process300begins by receiving the functional specification for the CDC synchronizer. In one embodiment, the functional specification describes the functions that are desired for the designed circuit. For example, a functional specification of a CDC synchronizer describes the interface signals and the behavior properties of the synchronizer. The behavior properties include the assumptions over the working environment of the CDC synchronizer and the guarantees, how the controller should behave. Process300transforms the behavior described by the functional specification for the properties at block312provided the specification is realizable. In one embodiment, the functional specification behavior transformation can be done using a functional specification behavior transformation tool or algorithm as known in the art.

In addition, in one embodiment, process300receives the RTL design abstraction for the circuit at block302. At block304, process300transforms the received RTL to the behavior layer. In one embodiment, the behavior layer describes the behavior of the elements in the circuit design. Process300performs the clock domain extraction at block306. In one embodiment, process300performs the clock domain extraction by identifying clock domain crossing paths and linking related paths into groups (e.g., data path and control paths of a mux-synchronizer).

At block308, process300performs the sequential structure extraction by functional specification using the clock domain extraction information of block306and the transformed functional specification from block312. In one embodiment, process300performs a SEFS search as described inFIG. 2above. For example and in one embodiment, process300performs an SEFS by checking the realizability of a CDC synchronizer specification. A CDC synchronizer specification is unrealizable if the working environment has a strategy to always falsify the proposed behavior of the controller. If the synchronizer has an unrealizable specification, SEFS does not continue further.

For a realizable functional specification, there could be winning strategies with which the synchronizer can enforce the satisfiability of the specification. The SEFS generates a Mealy machine, named as Master Plan, which encodes the winning strategies of the controller. As another example and in another embodiment, SEFS enumerates the machines in the design codes and checks whether the selected machines refine Master Plan by giving stronger output letter on common input letters. The design codes that refine the Master Plan are labeled as instances of the specification. SEFS carries out the refinement reasoning on the products from the design machines and the Master Plan.

At block314, process300stores the instances of the CDC synchronizer. In one embodiment, the instances of the CDC synchronizer are the results of the SEFS search from block312above. For example and in one embodiment, the instances of the CDC synchronizer are design codes that refine the Master Plan of the functional specification.

The use of SEFS for structure analysis gives more flexibility and independence to structure analysis. For tool developers, it is not necessary to code the netlist structure patterns and pattern matching algorithms manually. A user of SEFS specifies the behavior properties, which is faster and easier than coding the pattern-matching algorithms. In addition, a user can propose their own controllers to be searched by functional specifications. Furthermore, SEFS promotes the abstraction layer of circuit structure analysis from netlists to behavior layer. This enables a static analysis tool to ignore structural variants and still be confident in labeling machines with a design pattern provided their behavior can enforce the specified functionality. SEFS additionally benefits the user with a shorter workflow and more consistent check results. For example, SEFS does not require the double check pass in the current workflow as illustrated inFIG. 1for advanced netlist check (e.g., blocks112,114, and118ofFIG. 1above).

As described above, process200ofFIG. 2performs a proposition binding search using the stored mealy machines.FIG. 4illustrates an exemplary pseudo code400for signal binding search, according to one embodiment. In one embodiment, process200performs pseudo code400for the proposition binding search. In one embodiment, the input to the signal binding search is the set of design code Mealy machine (D), the functional specification (S), and the Master Plan Mealy machine, MPs. At line1, the pseudo code400creates a union of output ports union ODfrom the design codes D. Pseudo code400creates a set of input designs (ID) that gives the real input ports of a design, where the intermediate output ports are excluded at line2.

At line3, pseudo code400performs an outer loop (lines3-8) by enumerating of all bindings between design outputs and specification outputs. For the current output binding, bo, pseudo code400calculates the dependent outputs and stores this into DepOut at line4. At line5, pseudo code400determines the set of Mealy machines, DepMac, that drive the output. In one embodiment, the set of Mealy machines that drive the output are determined from the Mealy machines that are machines which drive some output ports from DepOut. At line6, pseudo code400calculates the input mapping, Depin, from the union of Mealy machines from DepMac that is the intersection of Ijand ID. In one embodiment, the intersection of the Ijand IDgives the real input ports of machine Mj, as Ijis the input port of Mj. Pseudo code400performs an inner loop (lines7-8) to enumerate over the binding in Depin to determine which bindings represent a refinement machine. At line8, pseudo code400performs the routine is_a_refinement on the current binding to determine if the current binding, bI, is a refinement of the Master Plan Mealy machine, MPs. If the current binding, bI, is a refinement, there is a Mealy machine that is a refinement of MPsand pseudo code400recognizes bIunder bOas an instance of a solution and adds <bI, bO> to the output of the check result. Determining whether the current binding, bI, is a refinement is further described inFIG. 5below. The inner and outer loops end at line8.

FIG. 5illustrates an exemplary pseudo code500for a Mealy machine refinement check, according to one embodiment. In one embodiment, pseudo code500performs the routine is_a_refinement routine of pseudo code400. The input for pseudo code500includes the output binding bO, the input binding bI, the design Mealy machine M1, and the specification Mealy machine M2. The pseudo code500begins at lines1-2, where pseudo code500determines if a condition gives the constraint on refinement reasoning. Process500works on M1and M2if M1has fewer input ports and more output ports. If this is not the case, pseudo code500does not carry out the refinement check, because a machine with more input ports and fewer output ports is more nondeterministic in behavior. If this condition exists, pseudo code500returns false as M1is not a refinement of M2.

If the condition does not exist, at line3, pseudo code sets the variable M to a tuple that is a cross product of M1and M2. In one embodiment, the tuple is <Q, I2, O2, qini, T>. At line4, pseudo code500initializes Frontier to {qini}. In one embodiment, the Frontier is the set of states to be explored. The initial Frontier has one state, the qini. Pseudo code500stores the new reachable states that are not encountered before in New_Frontier (line16), and replace Frontier with New_Frontier at line17. Therefore, the second iteration of Frontier includes the states reachable directly from qini. By this approach, Frontier is the set of states newly reached and should be explored in the next iteration. The process continues until there are no more new reachable states, where New_Frontier is empty. Consequently, the next Frontier is empty as well (line5).

Pseudo code500performs a loop (lines5-17) to determine if M1is a refinement of M2. In one embodiment, pseudo code500determines if M1is a refinement of M2, by checking the reachable states of product machine of M1and M2. For example and in one embodiment, M1refines M2if each reachable state q of the product machine from M1and M2has an output letter for each input letter. In one embodiment, pseudo code500enumerates over the Frontiers and breaks the loop when a Frontier is empty. Pseudo code500initializes a New_Frontier at line6.

Pseudo code500performs a further loop (lines7-16) to enumerate over the Frontiers and performs another loop (lines8-16) to enumerate over all input values. At line9, pseudo code500computes the ForwardExp, which is the forward expression for the input and output bindings. In one embodiment, the ForwardExp value for the input and output bindings are calculated based on the binding expression, BindExp, the active expression, ActiveExp, and the delta of the expression, DeltaExp. These values are further described below inFIG. 6. If the forward expression, ForwardExp, is un-satisfiable, pseudo code500returns false. In one embodiment, if the ForwardExp is false, then M1does not refine M2.

If the forward expression, ForwardExp, is satisfiable, pseudo code500computes the new reachable state at line12. Pseudo code500performs a further loop (lines13-16) for each state in the next Frontier to determine if the state has been visited. If the state q has not been visited, it will be added to the Visited list (line15), and the New_Frontier (line16). The three inner loops end at line16. Pseudo code500, at line17, updates Frontier with New_Frontier. In this way the process determines whether each identified binding is a refinement of the Master Plan.

FIG. 6illustrates an exemplary pseudo code for components used to calculate the value of ForwardExp, according to one embodiment. At line1, pseudo code600illustrates the calculation of the function BindExp(b). In one embodiment, the binding for b between proposition sets U and V encodes the equivalency relationship over propositions as illustrated in line1ofFIG. 6. At line2, pseudo code600illustrates the calculation of the function ActiveExp(q1) that encodes the configuration of Q when q is active as illustrated in line1ofFIG. 6. In one embodiment, ActiveExp(q1) encodes the configuration of Q where q1is an element of Q. At line3, pseudo code600illustrates the calculation of the function TransExp( ) In one embodiment, for state q⊂Q and an input letter σεΣI, TransExp(q, σI) encodes the transition of q on σI, and DeltaExp(q) encodes all the transitions of q.

FIG. 7illustrates a block diagram of a circuit design system700that performs sequential structure extraction by functional specification and a clock-domain-crossing synchronizer detection using a sequential structure extraction by functional specification according to one embodiment. In one embodiment, circuit design system700includes an input mechanism702, processor704, and memory706. In one embodiment, the input mechanism receives the inputted design codes and comprises receive design codes modules708and receive functional specification module710. In one embodiment, receive design codes module802receives the design codes as described inFIG. 2, block202above. In one embodiment, the receive functional specification module710as described inFIG. 2, block210above.

In one embodiment, the processor704includes the SEFS module712and CDC synchronizer module714. In one embodiment, the processor704is one or more microprocessors, such as the one or more microprocessors1003as described inFIG. 10below. In one embodiment, the SEFS module712performs a SEFS that aims at a search engine, which automatically picks out signals from design codes such that the driving machines of selected signals can enforce the satisfiability of a realizable specification as described in blocks204,206,208,212,214,216, and218ofFIG. 2above. The CDC synchronizer detection module714performs a CDC synchronizer detection using the SEFS module702as described inFIG. 3above.

In one embodiment, the memory706is memory as described inFIG. 10below. In one embodiment, the memory706further includes one or more design codes that satisfy the functional specification of the circuit design.

FIG. 8illustrates a block diagram of a SEFS module712according to one embodiment. In one embodiment, SEFS module712includes Mealy machine conversion module802, store Mealy machine804, proposition binding search module806, realizable check module808, functional specification realizable module810, create master plan module812, and report module814. The Mealy machine conversion module802coverts the design code to Mealy machines as described inFIG. 2, block204above. The store Mealy machine804stores the Mealy machines as described inFIG. 2, block206above. The proposition binding search module806performs a proposition binding search as described inFIG. 2, block208above. The realizable check module808calculates the realizability of the functional specification as described inFIG. 2, block212above. The functional specification realizable module810determines if the functional specification is realizable as described in FIG.2, block214above. The create master plan module812generates the Mealy machine for the functional specification as described inFIG. 2, block216above. The report module814generates the report as described inFIG. 2, block218above

FIG. 9illustrates a block diagram of a CDC synchronizer detection module714to perform clock-domain-crossing synchronizer detection with a sequential structure extraction by functional specification, according to one embodiment. In one embodiment, the CDC synchronizer detection module704includes receive RTL module902, transform behavior module904, extract clock domain module906, SEFS communication module908, received CDC specification module910, transform behavior property module912, and store CDC synchronizer instances module914. The receive RTL module902receives the RTL as described inFIG. 3, block302above. The transform behavior module904transforms the behavior of the RTL as described inFIG. 3, block304above. The extract clock domain module906extracts the clock domain information as described inFIG. 3, block306above. The SEFS communication module908communicates with the SEFS module702to perform a SEFS search as described inFIG. 3, block308above. The received CDC specification module910receives the CDC specification as described inFIG. 3, block310above. The transform behavior property module912transforms the CDC specification for properties as described inFIG. 3, block312above. The store CDC synchronizer instances module914stores CDC synchronizer instances as described inFIG. 3, block314above.

This description and drawings are illustrative of embodiments and are not to be construed as limiting the invention. Numerous specific details are described to provide a thorough understanding of the disclosed embodiments. However, in certain instances, well known or conventional details are not described in order to avoid obscuring the description of the disclosed embodiments. References to “an” or “one” embodiment in the present disclosure are not necessarily to the same embodiment; such references mean at least one embodiment.

Many of the methods of the disclosed embodiments may be performed with a digital processing system, such as a conventional, general-purpose computer system. Special purpose computers, which are designed or programmed to perform only one function, may also be used.

FIG. 10shows one example of a typical computer system or data processing system that may be used with the disclosed embodiments. For example, in one embodiment the processes described with respect toFIGS. 2-6is operational through the example computing system. However, it is noted that whileFIG. 10illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components but rather provides an example representation of how the components and architecture may be configured. It will also be appreciated that network computers and other data processing systems that have fewer components or perhaps more components may also be used with the disclosed embodiments. The computer system ofFIG. 10may be any computing system capable of performing the described operations.

As shown inFIG. 10, the computer system1000, which is a form of a data processing system, includes a bus1002, which is coupled to one or more microprocessors1003. In one embodiment, computer system1000includes one or more of a read only memory (ROM)1007, volatile memory (RAM)1005, and a non-volatile memory (EEPROM, Flash)1006. The microprocessor1003is coupled to cache memory1004as shown in the example ofFIG. 10. Cache memory1004may be volatile or non-volatile memory.

The bus1002interconnects these various components together and in one embodiment interconnects these components1003,1007,1005, and1006to a display controller and display device1008. The computer system1000may further include peripheral devices such as input/output (I/O) devices, which may be mice, keyboards, modems, network interfaces, printers, scanners, video cameras and other devices which are well known in the art. Typically, the input/output devices1010are coupled to the system through input/output controllers1009.

The volatile RAM1005is typically implemented as dynamic RAM (DRAM) which requires power continually in order to refresh or maintain data in the memory. The non-volatile memory1006is typically a magnetic hard drive, magnetic optical drive, an optical drive, a DVD RAM, a Flash memory, or other type of memory system which maintains data even after power is removed from the system. Typically, the non-volatile memory will also be a random access memory although this is not required.

WhileFIG. 10shows that the non-volatile memory is a local device coupled directly to the rest of the components in the data processing system, it will be appreciated that the disclosed embodiments may utilize a non-volatile memory which is remote from the system, such as a network storage device which is coupled to the data processing system through a network interface such as a modem or Ethernet interface.

The bus1002may include one or more buses connected to each other through various bridges, controllers and/or adapters as is well known in the art. In one embodiment the I/O controller1009includes a USB (Universal Serial Bus) adapter for controlling USB peripherals, and/or an IEEE-1394 bus adapter for controlling IEEE-1394 peripherals.

It will be apparent from this description that aspects of the disclosed embodiments may be embodied, at least in part, in software (or computer-readable instructions). That is, the techniques, for example the processes ofFIGS. 1 and 4may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM1007, volatile RAM1005, non-volatile memory1006, cache1004or a remote storage device. In various embodiments, hardwired circuitry may be used in combination with software instructions to implement the disclosed embodiments. Thus, the techniques are not limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system. In addition, throughout this description, various functions and operations are described as being performed by or caused by software code to simplify description. However, those skilled in the art will recognize what is meant by such expressions is that the functions result from execution of the code by a processor, such as the microprocessor1003.

A machine readable storage medium can be used to store software and data which when executed by a data processing system causes the system to perform various methods of the disclosed embodiments. This executable software and data may be stored in various places including for example ROM1007, volatile RAM1005, non-volatile memory1006and/or cache1004as shown inFIG. 10. Portions of this software and/or data may be stored in any one of these storage devices.

Thus, a machine readable storage medium includes any mechanism that stores any information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.). For example, a machine readable medium includes recordable/non-recordable media (e.g., read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.).

The detailed description of embodiments makes reference to the accompanying drawings in which like references indicate similar elements, showing by way of illustration specific embodiments of practicing the invention. Description of these embodiments is in sufficient detail to enable those skilled in the art to practice the invention. One skilled in the art understands that other embodiments may be utilized and that logical, mechanical, electrical, functional and other changes may be made without departing from the scope of the present invention. The detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims.

References within the specification to “one embodiment” or “an embodiment” are intended to indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. The appearance of the phrase “in one embodiment” in various places within the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not other embodiments.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present disclosure, discussions utilizing terms such as “receiving” or “storing” or “searching” or “determining” or “converting” or the like, refer to the action and processes of a computer system, or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories and other computer readable media into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.