communities everywhere on the web want to share , store and query data .their motivations for data sharing are very diverse from entertainment or commercial activity to the desire to collaborate on scientific or artistic projects .the data involved is also varied , running the gamut from unstructured through semistructured to relational .the solutions used for data sharing are frequently custom - built for a concrete scenario ; as such , they exhibit significant diversity themselves . to name only a few prominent solutions ,wiki software has proved very successful for community management of unstructured data ; scientific portals such as birn and geon allow scientists to pool their datasets ; and an increasingly large number of vertical social networking sites include a topic - specific database that is maintained by the site s members .while the scenarios mentioned above vary widely in their parameters , they have in common many high - level properties that translate into concrete design desiderata for collaborative data integration ( cdi ) systems . in the youtopia project, we are building a system to address these desiderata and enable community data sharing in arbitrary settings .our initial focus is on relational data ; however , the ultimate goal is to include arbitrary data formats and manage the data in its full heterogeneity , as in dataspaces .cdi has three fundamental aspects that distinguish it from other paradigms such as classical data integration .first , a cdi system must enable _ best - effort cooperation _ among community members with respect to maintenance of the data and metadata .that is , no worthwhile contribution to the repository should be rejected because it is incomplete , as another community member may be able to supply the knowledge required to complete it .this means a cdi system must be equipped to deal with incomplete data and metadata , as well as providing a way for users to complete them at a later time .next , a cdi solution must _ manage disagreement _ regarding the data and schema or other metadata .finally , it must _ maximize data utility_.  these three aspects have clear tradeoffs in the extent to which they can be addressed ; as such , they define a design space within which we can situate existing solutions and youtopia .the structure of this design space also clarifies the relationship of cdi to classical data integration ; the latter is fundamentally an effort to maintain utility while permitting as much disagreement as possible .cdi builds on this by introducing the added element of best - effort cooperation , familiar from the web 2.0 model of enabling all users to create their own content on the internet .youtopia is a system that allows users to add , register , update and maintain relational data in a collaborative fashion .the architecture of youtopia is presented in figure [ fig : architecture ] .the storage manager provides a logical abstraction of the repository . in this abstraction ,the repository consists of a set of logical tables or views containing the data ; these are tied together by a set of mappings .the mappings are supplied by the users as the repository grows and serve to propagate changes to the data .thus , at the logical level youtopia is an _ update exchange _ system . in this paper , we introduce our update exchange model , which is designed to enable best - effort cooperation as far as possible ; in this it differs from previous update exchange work such as orchestra .a small youtopia repository is shown in figure [ fig : exampledata ] .it contains relations with travel and tourist information ; the relations are conected by a set of _ mappings _ or _ tuple - generating dependencies ( tgds)_. for instance , the tgd ensures that table ` r ` contains review information about all available tours of attractions , as explained in the following example .[ ex : fwdchase ] suppose company starts running tours to niagara falls and the tuple ` t`(`niagara falls ` , ` abc tours ` ) is added .the mapping will cause the new tuple ` r`(`niagara falls ` , ` abc tours ` , ) to be inserted by the update exchange module .the is a _ labelled null _ or _variable _ which indicates that some review for the tour should exist , but is unknown to the system .the review may subsequently be filled in manually by a user .this propagation of changes occurs through a process known as the ( tgd ) _ chase _  a simple mechanism for constraint maintenance in which the corrective operations required are relatively easy to determine and perform .tuple - generating dependencies and equivalent constraints such as glav mappings and conjunctive inclusion dependencies are frequently encountered in data integration .their ubiquity points to the fact that they are a very powerful formalism , applicable in a variety of subject domains . on the other hand ,it is not always trivial for a user to specify a mapping correctly .however , this problem has been addressed in some existing work and we are building on these solutions to set up an infrastructure to facilitate mapping creation .notably , youtopia allows users to cooperate and pool their understanding to set up and refine tgds .mapping creation is also made easier by the presence of subdomain - specific summary views : knowledgeable users can define such views which capture in their schema the essence of the subdomain .much as portals and topic lists in wikipedia can guide contributors in the categorization of their articles , such views can guide table owners in the placement of their mappings .the subdomain - specific summary views also assist in querying the repository ; thus , managing such views is related to collaborative query management .querying in youtopia involves a mixture of keyword search and structured queries .the query engine is equipped to handle data that is incomplete , inconsistent or both .this is done through the use of multiple query semantics : a _ certain _ semantics that guarantees correctness while potentially omitting some results , and a _ best - effort _ semantics that includes all potentially relevant results at the risk of some incorrectness .two key crosscutting concerns in youtopia are disagreement handling and data access control . as data and mappingsare added to the repository , disagreement is inevitable .youtopia provides mechanisms for disagreement resolution by the community , as well as supporting data inconsistency in the event that disagreement is not resolved .moreover , it provides facilities for community ranking of tables and data .finally , youtopia also has a social structure allowing users to establish a network of trusted acquaintances or friends , so that data , mappings , rankings and user - defined views can be shared to a varying extent .as we mentioned , the youtopia update exchange model is designed to maximize potential for best - effort cooperation .accordingly , there are no centralized constraints on the mappings , such as acyclicity .these restrictions are a bottleneck for extensibility , as users may not be able to determine how a cycle should be broken , particularly if the cycle is complex and includes mappings created by a large number of users .the reason such restrictions are common is that the standard model of update propagation via the chase requires them for termination .we argue that this chase model is not suitable for a cdi setting , as it is stronger than the propagation semantics which are intuitively desired by users when they set up mappings .the infinite chases that can arise are a symptom of this .  in the standard chase with tgds ,the system must correct any mapping violations _ completely _ , _ as soon as they occur _ , and _ without asking for additional information_. in youtopia , we lift all these requirements , as we believe they are too strong for cdi . users of a cdi system do not necessarily want mapping violations corrected immediately , particularly if they are not using the relevant part of the repository at the moment . on the other hand, they frequently have domain knowledge that they can supply to the system to aid in violation correction . based on these observations ,we propose a new chase model that is fundamentally cooperative .it turns out that in this model , cycles among mappings no longer cause a problem and can be permitted .  of course, human assistance can be slow in coming .to function in a practical setting , the youtopia system must remain usable as far as possible while violations are waiting for human assistance .this means that neither queries nor new chases can be blocked by an earlier chase that is waiting for human help .as soon as multiple chases are occurring in the system concurrently , it is possible for them to interfere , which affects overall correctness .the challenge is then to allow asynchronous , human - assisted correction of violations without locking down the entire system and while guaranteeing correct semantics for the entire process .our contributions in this paper are as follows .first , we present the youtopia update model and explain how it combines the classical chase with user intervention .the model introduces the novel concepts of _ frontier tuples _ and _ frontier operations _, where the former represent a point of ambiguity in the chase and the latter provide a means for a human to resolve this ambiguity .the frontier operations are designed to be simple for users who have the appropriate domain knowledge ; indeed , they are similar to intuitive data cleaning operations . for example , one of our frontier operations is a _ unification _ , wherein a user specifies that two tuples refer to the same real - world fact and should be collapsed into one .next , we outline the possibilities that arise for interference among multiple youtopia chases and provide a definition of serializability that can be used to prevent interference .we present a practical strategy for maintaining serializability : we give a concurrency control algorithm framework that can be instantiated in multiple ways .our general algorithmic approach is optimistic , that is , we allow new updates to set off chases even while older ones are awaiting human assistance . as with any optimistic concurrency control technique, the higher throughput gained comes at a cost : some chases may have to be aborted and restarted if a conflict occurs .we identify mechanisms for reducing the number of such aborts , which are particularly undesirable in the youtopia setting where a redo may require human intervention .we present experimental results to demonstrate that the number of aborts can indeed be reduced dramatically using our methods .finally , we discuss issues involved in the implementation of our algorithm in a real system where a scheduler must choose which chases to run and when .at the logical level , a youtopia repository is a database , i.e a set of relations containing constants and _ labeled nulls _ ( or variables ) .the relations are connected by _mappings _ or tuple - generating dependencies .a mapping specifies a desired relationship between the data in the relations which it connects .it has the form where is a conjunction of relational atoms over the sets of variables and constants and , while is a conjunction of relational atoms over and . the free variables are understood to be universally quantified .figure [ fig : exampledata ] shows an example of a small youtopia repository and mappings .mappings in youtopia may connect arbitrary relations , they may include features such as self - joins , and most importantly they may form cycles over the set of relations .for example , and form a cycle involving the relations ` c ` and ` s `.  when a tuple is inserted , deleted or modified by a user , some of the mappings between relations may no longer be satisfied , that is , violations may occur .[ def : violation ] let be a tgd that is not satisfied by database .use to denote the free variables of , the existentially quantified ones , the lhs subformula of and the rhsviolation _ is an assignment of values from the database domain to such that  ] .[ def : witness ] every violation of a mapping is associated with a _ witness _ - this is the set of tuples from the database that match the lhs of , but that do not have a corresponding set of tuples to match the rhs .youtopia uses a variant of the standard chase procedure to correct any new mapping violations . in this paper , we restrict ourselves to three kinds of user operations that may initiate a chase : tuple insertion , tuple deletion , and _ null - replacement _ replacement of all occurrences of a labeled null with the same constant value .if a violation is caused by a tuple insertion or by tuple change due to null - replacement , this must be because the new version of the tuple is part of this violation s witness .we call this type of violation an lhs - violation .it is clear why insertions only cause lhs - violations , but perhaps less so for null - replacements . in particular, this is _ not _ generally true for arbitrary tuple modifications .however , in null - replacements , all instances of a labeled null are changed simultaneously and consistently , and this ensures that only lhs - violations are possible .for example , if were to be replaced by ` abc tours ` , a violation of would not occur because the change would happen in both ` t ` and ` r ` .states that every city has a recommended airport . under , every airport is located in a city and serves a city . ensures that whenever a company offers tours of an attraction , the tour is reviewed .because of , convention attendees can receive recommendations for day trips based on the convention venue and available tours . ]  on the other hand , suppose a mapping is violated because of a tuple deletion .this must be because the deleted tuple used to be reflected on the rhs of some assignment of values , but now that the tuple is gone , no other matching tuple to the same rhs atom can be found .we call this type of violation an rhs - violation .the youtopia chase has two variants - _ forward _ and _ backward_. the forward chase corrects violations by supplying the missing rhs tuples for the violation witness , as in example [ ex : fwdchase ] .the backward chase corrects violations by removing at least one of the witness tuples .[ ex : backwardchase ] suppose the tuple ` r(geneva winery , xyz tours , great ! ) ` is deleted from our example database .a backward chase corrects the violation of by deleting either ` a(geneva , geneva winery ) ` or ` t(geneva winery , xyz tours ) ` .  in youtopia ,the choice of chase variant is dictated by the type of the violation .lhs - violations are always repaired by a forward chase , rhs - violations by a backward chase .our primary motivation in making this design choice is the assumption that the user s initial operation accurately reflects their intent with respect to the relation involved . as such, this operation should not be undone by the violation correction process ; for example , an insertion that created a lhs - violation should not immediately be undone by a backward chase aiming to correct the violation .  in a real - world setting, users will desire additional functionality on top of our violation repair semantics , particularly with respect to the handling of deletions .our handling of rhs - violations effectively cascades all deletions. this may be dangerous from an access control standpoint ; the system must check whether a deletion may cascade into a table where it would cause a permissions violation .in such a case , the original deletion should be rejected by the system .if the user still wishes the rejected deletion to occur on the original table , they are in effect requesting an exception to the mapping ; developing support for such exceptions is ongoing work. moreover , the user interface must make it easy for the user to determine whether they really intend to perform a deletion . in example[ ex : backwardchase ] , the user s intent may have been just to remove the review rather than delete the entire tuple ; if so , they should have replaced ` great ! ` by a fresh labeled null instead .this would have exactly the same result as performing the original deletion and repairing it with a _ forward _ chase ( i.e. , through regeneration ) .however , a regeneration implementation obscures the user s intent , whereas the direct replacement of a value by a null makes it clear .we note that while the names of our two chase methods may suggest a similarity to the _ chase and backchase ( c & b ) _ technique , there is not a close relationship between c & b and our work . in c & b ,the two chases proceed in distinct phases while ours are interleaved ; moreover , c & b is a mechanism for query optimization on a given database , while our chases serve to propagate changes to the data .superficially , the forward chase in youtopia is very similar to the standard tgd chase .a witness is identified : matching rhs tuples are generated , and in the example we have seen so far inserted into the database . however , if the insertion were always carried out , it would sometimes be possible to generate an infinite cascade of inserts .suppose jfk airport is added as a suggested access airport for ithaca .the tuple ` s(jfk , nyc , ithaca ) ` is added to the database . to satisfy mapping , we need to add tuple ` c(nyc ) ` .this in turn causes a violation of , which can be fixed by inserting ` s(x_3 , x_4 , nyc ) ` .this new insert causes a violation of , requiring the insertion of ` c`( ) , and so on .such cyclical firing of rules is a well - known problem and the main reason behind mapping acyclicity restrictions .however , tuple insertion is not the only way to repair a violation by supplying a matching rhs to the witness .sometimes it is possible to provide a matching rhs by _ unifying _ some labeled nulls with other values in the database .indeed , if a knowledgeable human were observing the infinite sequence of inserts mentioned previously , they would very likely step in and short - circuit the process .for example , they might supply the additional information that the suggested airport for nyc is itself in nyc .this is equivalent to indicating that the two tuples ` c(x_4 ) ` and ` c(nyc ) ` are referring to the same fact and should be collapsed .( lest the user s intervention should appear obvious and our entire example contrived , we observe that there is seldom a perfect correspondence between the airport(s ) in a city and those recommended for access to the city .a small city is often best served by airports in neighboring locations .further , an airport in city a may be recommended for travel to city b but not to a itself perhaps it is a minor airport with difficult access to downtown a but within short driving distance of b. thus , users may legitimately want to keep their mappings as flexible as and . )the youtopia forward chase model is a formalization of the above intuition .a forward chase starts out in the traditional way : we identify violations and their witnesses , generate new tuples and insert them .this chase s execution sequence can be represented as a tree , with inserted tuples as nodes and direct causality relationships as edges .if on any path the system detects nondeterminism such as was present in our example with respect to the tuple ` c(x_4 ) ` , the chase stops along that path and awaits human intervention . our notion of nondeterminismis based on the concept of the _ more specific than _ relation on tuples .[ def : specific ] a tuple is _ more specific than _ a tuple if the mapping defined as is a function and is the identity on constants ( i.e. values that are not labeled nulls )  we say that nondeterminism occurs on a chase path if a tuple belonging to relation is generated by the chase , but already contains a tuple which is more specific than . in this case , it is possible that is intended to represent the same fact as , and should be set aside for human inspection to determine whether this is the case . in the above example, the tuples ` c(nyc ) ` and ` s(x_3 , x_4 , nyc ) ` would be inserted by the chase , as no tuples more specific than these exist . on the other hand , the tuple ` c(x_4 ) ` would not be inserted , since more specific tuples do exist . in this way , the chase would stop even though a cycle of mappings exists .indeed , it is always the case that such a forward chase must stop sooner or later .[ lemma : fwdchasestops ] for any forward chase using the above algorithm , computation will stop along all paths in the chase tree after finitely many steps , unless the chase terminates before such a point is reached .once a chase has stopped , it is time for a human user to step in and assist the process .the user has access to all the tuples which were generated but not inserted into the database ; we refer to those as _ positive frontier tuples_. faced with a frontier tuple , a user may perform one of two _ frontier operations _ :  * _ expand _ , that is , insert into the database .* _ unify _ , that is , choose another tuple in the same relation as which is more specific than and perform variable unification between any labeled nulls in and . disappears after such an operation .given a suitable interface that provides meaningful provenance information for the frontier tuples , such frontier operations should be quite feasible for a knowledgeable human to perform . the user is simply presented with a frontier tuple and asked : `` is this a new tuple , or can you match it to a tuple already in the relation ? '' .if they answer yes to the first option , they are requesting expansion , and otherwise the matching tuple they indicate supplies the necessary unification information .the unification operation may cause changes to multiple tuples in the system if they contained one of the labeled nulls which disappeared in the unification .these changes may themselves cause further mapping violations .expansion may also generate new violations due to the insertion of .however , in both cases the new violations are guaranteed to be lhs - violations , so the chase can simply add them to its violation queue for future correction .a special case for frontier operations concerns tgds with multiple atoms on the right - hand side .the firing of such a tgd in a forward chase generates multiple frontier tuples that may share some labeled nulls . on such tuple sets , the frontier operations work as expected given that the shared labeled nulls must be treated consistently .  after a frontier operation ,the system may be able to carry out further deterministic chase steps ; if it can , it does so until it terminates or once again reaches a point where it must stop on all paths . at this pointit asks for user assistance again and the process repeats .a chase execution thus consists of a sequence of _ deterministic strata _ separated by periods of blocking and waiting for frontier operations .the full forward chase execution model is presented in algorithm [ alg : fwdchase ] .  `writeset ` : = initial user operation ` violqueue ` : = perform writes in ` writeset ` ` writeset ` : = ` violqueue.append`(violations just created ) choose ` v \in violqueue ` ` writeset ` : = set of corrective writes for ` v ` remove ` v ` from ` violqueue ` generate and store frontier tuples for ` v ` make nonblocking request to user for frontier op block while no frontier operations performed ` writeset ` : = result of first frontier operation received remove corresponding ` v ` from ` violqueue `   unlike a forward chase , a backward chase must eventually terminate , as it can not delete more tuples than exist in the database initially . however , backward chases come with their own flavor of nondeterminism which also requires human assistance to resolve .in example [ ex : backwardchase ] it was sufficient for one of the two tuples in question to be deleted for to be satisfied again ; the youtopia system recognizes this , but does not make a decision , deferring it instead to a user .  like the forward chase, the backward chase progresses deterministically as far as it can ; when it encounters a situation like the above , with a set of tuples any of which may be deleted , it marks all these tuples as _ negative frontier tuples _ and requests user assistance .faced with such a set of negative frontier tuples , a user may perform the _ negative frontier operation _ of deleting any subset of the tuples .once again , performing this frontier operation requires no technical knowledge from the user .they are simply presented with a set of tuples and requested to select the subset which is to be deleted based on their domain knowledge .we remark that the deletion frontier operation is in some sense the counterpart of the expansion operation on the positive frontier ; both cause the frontier to advance further .it is also possible to formulate a negative frontier operation that would be the counterpart of unification ; this would be a _ reconfirmation _ operation , where a user specifies for some proper subset of a set of negative frontier tuples that the subset is _ not _ to be deleted .determining whether such an operation would be useful in a cdi system and , if so , implementing support for it , is future work .as should be clear from the chase descriptions , the effects of a single user operation can propagate in a youtopia system for many steps .we define a _youtopia update _ to refer to all these consequences together .an _ update _ is the complete sequence of database modification operations induced by a single initial tuple insertion , deletion or null - replacement .this includes any frontier operations taken by a user on frontier tuples generated by the update .an update may be nonterminating .an update is _ positive _ if the initial operation was an insertion or null - completion , and _ negative _ if the operation was a deletion .the fundamental importance of human intervention to our chase models might appear to make them impractical in the real world .however , youtopia is carefully designed to minimize the system usability impact of waiting for human input .new updates are allowed to begin and proceed while older ones are blocking ; this raises potential interference issues , of course , and the remainder of our paper presents our solution for addressing those .moreover , the repository is available for querying at all those times when no chase is executing a deterministic stratum ( that is , almost all the time ) .of course , the mappings are not necessarily satisfied in the system , which might pose a problem for queries . however, if the system is in a state where all ongoing updates are waiting for frontier operations , it actually satisfies the mappings under a _weaker _ semantics .this semantics is based on epistemic logic and similar to the semantics for peer - to - peer data integration given in and .the positive frontier tuples are not certain with respect to their presence in the appropriate tables ; all tuples which are certain are present. a symmetric statement can be made about the negative frontier tuples .developing suitable query semantics for youtopia under these epistemic mapping semantics is ongoing work .we now introduce a definition of serializability for youtopia updates .we assume that the initial state of the system consists of a finite database that satisfies all mappings .there is a finite set of updates to be performed , and a total order on the priority of these updates is given .for example , the updates can be ordered by their timestamp or explicitly by the user ; we do not assume anything about the ordering beyond the fact that it is total , and updates with a lower number in the order have higher priority .defining serializability in youtopia is complicated by the fact that updates may never terminate .therefore , serializability can not be a property of complete excecution traces or schedules , as there are legal execution scenarios which never yield complete traces . instead, we define it as a property of a finite prefix of an execution schedule . our definition is based on the classical concurrency theory concept of _ final - state serializability _ ; however , it explicitly takes into account the semantics of the chase , in that we only consider ( prefixes of ) schedules which correspond to valid chase executions .we motivate our serializability definition with an example .consider the database in figure [ fig : exampledata ] and suppose the two following real - world events occur .first , company xyz discontinues tours to the geneva winery ; the owner of the ` r ` table learns about it and removes ` r(xyz , geneva winery , great ! ) ` .second , a new conference , ` math conf ` , is scheduled to take place in syracuse and the tuple ` v(syracuse , math conf ) ` is inserted .both these operations set off updates , numbered and respectively .suppose the following interleaving of events occurs :  1 . deletes ` r(xyz , geneva winery , great ! ) ` , causing a violation of .the violation can not be corrected deterministically , so the system marks ` a(geneva , geneva winery ) ` and ` t(geneva winery , xyz , syracuse ) ` as deletion candidates and requests a frontier operation . inserts ` v(syracuse , math conf ) ` .this causes a violation of which can be corrected deterministically . inserts ` e(math conf , geneva winery ) ` .4 .  receives a frontier operation directing it to delete ` t(geneva winery , xyz , syracuse ) ` .the resulting database is not the same as it would have been if had executed serially after .moreover , we can diagnose the problem before the schedule completes it is already apparent by step .update has decided prematurely that it should insert a tuple into , even though one of the tuples in the witness to the violation of was a deletion candidate .to ensure serializability , we must rule out all execution schedules which perform such premature operations .that is , we must exclude schedule prefixes for which there is a possible future scenario where  * all running updates terminate , but * the resulting schedule is not final - state serializable , and moreover the problem can be traced back to the current schedule prefix .we now work towards making the above intuition more formal .our first step is to model a youtopia update in a way that abstracts away the fact that human input is involved in its execution ; this is not relevant for our purposes .we only require a way to capture an update s interaction with the database .therefore , we move from the model in algorithm [ alg : fwdchase ] to a model where a chase is a sequence of _ steps_. each step may or may not include a blocking operation where input is requested from a user .algorithm [ alg : chasestep ] gives our model for execution of a single chase step .here and in the remainder of the paper , the term _ chase _ refers to any youtopia chase , forward or backward , unless explicitly specified otherwise .perform a set of write operations ` v_{\sigma } ` : = set of new violations of ` violqueue.append(v_\sigma ) ` ` nextviol ` : = choose ` nextviol ` from ` violqueue ` generate a set of corrective writes to repair ` nextviol ` ` violqueue.remove(v ' ) `  algorithm [ alg : chasestep ] exposes the write and read operations a chase step performs as it is executed .the write operations occur first , at the beginning of every step ; each write operation is either a tuple insertion , deletion , or an update which is part of a global replacement of a variable by a new value .subsequently , the update step may perform reads for two reasons : to determine what new violations were caused by the writes , and to correct the violation ` nextviol ` .this is explained in detail in section [ subsec : safety ] ; for now , note as an example that correcting a lhs - violation requires reading the database to determine whether it contains any tuples more specific than the frontier tuple .the presentation of algorithm [ alg : chasestep ] reflects our first simplifying assumption we assume all the writes are performed before the reads begin .this is reasonable : in the chase , the data read in a step is virtually certain to have been modified by the writes that were performed at the start of the same step .delaying the reads until the writes have completed is therefore necessary for correctness .an update s execution on the database can thus be completely described by a sequence of alternating sets of write and read operations .we call such a sequence a ( single - update ) _ schedule_. a schedule can be finite or infinite .we use to denote schedules ; if is a database , we denote by the database that results when is executed over .the notion of a schedule extends to a multi - update setting ; we can assume that each operation in the multi - version case is tagged with the priority number of the corresponding update .in the multi - update setting , arbitrary interleavings may occur between operation sets belonging to different updates ; we refer to a _ single - update projection _ of a schedule to mean the ordered portion of the schedule consisting only of the steps performed by a specific single update .a schedule is _ valid _ with respect to a database iff it represents an execution of the updates on that is syntactially and semantically correct with respect to all rules of the chase .  a _ terminating extension _ to a schedule for update with respect to database is a valid schedule consisting of operations belonging to , such that when completes its execution on , terminates .the _ serialization _ of a schedule , denoted , is a schedule obtained by sorting the operations in on the update number , in ascending order ( but retaining the ordering between operations of a single update ) .as indicated before , we define serializability on schedule prefixes . according to our definition ,the serializable schedule prefixes are exactly those which do not `` already '' contain a mistake that would make serialization impossible in some possible future where all updates terminate .to ensure the mistake can be traced back to the current schedule , the definition s scope is restricted to possible futures in which all updates execute and terminate serially .[ def : serializability ]  assume updates are running in the system . a youtopia schedule is _ final - state serializable_ if there exists an ordering of the updates such that for every extension , where is a terminating extension for update with respect to database , we have that is valid and . the schedule is serializable _ with respect to a given ordering _ if the above is true for the specific ordering desired .  in the case where already is a terminating schedule ,the set of possible is empty , so the condition reduces to testing that , which is exactly traditional final - state serializability .achieving serializability clearly requires restricting interleavings of operation sets that belong to different updates . definition [ def : serializability ] is very general and open to enforcement by a wide range of solutions . in standard concurrency control settings ,final - state serializability is usually enforced indirectly by maintaining stronger properties such as conflict serializability which are also easier to check in practice .our approach is similar ; we begin with restricting our system model and then present our algorithmic framework for enforcing properties that imply serializability .our solution draws on existing work on multiversion concurrency control protocols , notably the abort - based mvto and locking - based mv2pl .it also makes use of some ideas from predicate and precision locking .these are well - known protocols and algorithms ; our contribution in this paper is to show how they may be adapted to produce a complete solution for enforcing serializability in our new update exchange model .our first simplifying assumption is to place an interleaving restriction .we assume that interleavings are only permitted at the chase step granularity .that is , if an update has started a chase step and is performing writes , it can finish the writes and perform all the reads it requires in that step before any other update may proceed with any operation .this restriction need not actually be enforced to the letter physically , as long as the system maintains the illusion that it holds at the logical level .we consequently move to a model where we introduce a _ scheduler _ component that controls the execution of the updates in the system ( algorithm [ alg : chasescheduler ] .the scheduler may permit interleavings at the level of individual steps or allow updates to run an entire deterministic stratum before regaining control ; it may also use a wide variety of scheduling policies in choosing which update gets to run .  `writequeue ` : = initial writes of each update to be run choose a set of writes to schedule from ` writequeue ` run one or more chase steps for this update ( alg .[ alg : chasestep ] ) enqueue new writes to ` writequeue `  this interleaving restriction makes it possible to formulate a practical , simple concurrency control algorithm based on a notion of conflict - serializability .intuitively , it is clear that we need two properties to hold .first , given an update with number , s writes must not `` pollute '' the future reads of lower - numbered updates .second , should not read data items which will ( or may ) still be written by lower - numbered updates .we ensure the first property by using tuple _versions _ as is done in mvcc algorithms , and the second by defining and enforcing _ chase step safety_.  our use of versioning is relatively standard for multiversion algorithms . for each tuple ,the database maintains multiple versions .a version is created whenever the tuple is inserted , modified through a null - completion , or deleted .if an update operates on a tuple twice , two versions are created , the second with a higher number . at any time , for update with number the visible version of a tuple is the one with the largest number among those created by any update with ( priority ) number less than or equal to .the second half of enforcing serializability involves preventing premature reads .a precise definition requires formalizing the reads performed by a chase step .when an update executes a chase step , the set of tuples read depends on the contents of the database as well as the information known before the step begins ( i.e. , the writes in and the current violation queue ) .the same write , performed on different databases , will generate different new violations .because of this , we represent the set of tuples which are read in intensionally ; we identify it with the answers to a set of _ read queries _ that are performed by while executing this step .an update performs read queries for two reasons : to identify new violations caused by a write , and to obtain information required for violation correction . in the former case , the query to be asked for each mapping has the form :  .... select * from ( lhs query ) where not exists ( select * from ( rhs query ) ) ....  ` lhs query ` and ` rhs query ` are conjunctive queries whose structure is dictated by and bindings by the newly written tuple .we refer to this type of query as a _ violation query_.  [ ex : violationquery ] returning to our database in figure [ fig : exampledata ] , if the tuple ` r(xyz , geneva winery , great ! ) ` is deleted , the query to discover violations of is shown below .this query returns all the pairs of ` a ` and ` t ` tuples which have been affected by the deletion with respect to satisfying ..... select * from a , t  where a.name = t.attraction and and a.name = ' geneva winery ' and t.company = ' xyz ' and not exists ( select * from r         where r.company = t.company         and r.attraction = a.name ) ....  an update may also perform queries in order to determine how to correct a violation , with or without human help . in the case of rhs - violations ,no further reads are performed - the system or a human chooses a tuple to delete from one of the already - read witness tuples . for lhs - violations , however , additional reads may be performed because of the possibility of correction through unification . given a set of frontier tuples for a violation , the system must perform the following queries for each frontier tuple belonging to relation :  * find any more specific than * if such are found , for all labeled nulls in which were freshly generated when was created , find all other tuples in the database containing .if unification is chosen , all such tuples must be updated .we call these types of queries _ correction queries_.   with the notion of read queries in place , we can now define youtopia conflict - serializability .our definitions assume that interleaving only occurs at chase step granularity and that versioning is in place so that the only writes visible to an update are those of lower - numbered updates and its own .chase step is _ safe _ to perform for update with number on database iff for all , where each is a terminating extension for update number with respect to database , we have that for all read queries that may perform in step ,   safety is closely related to precision locking , since it brings together intensionally specified reads and extensionally specified writes .however , our definition is explicitly tied to the semantics of the youtopia chase .a schedule is _ conflict serializable _ iff no chase step is performed by an update until this step is safe .[ thm : safetygivesserializability ] any youtopia schedule that is conflict serializable is final - state serializable ( definition [ def : serializability ] ) .the order of serializability is the same as that used when determining safety .conflict serializability in youtopia can in principle be enforced in two ways . we can take a blocking approach , as in mv2pl , and prevent chase steps from proceeding until it is safe to do so .alternatively , we can take an optimistic approach where we are more permissive about chase step scheduling , but take the risk that conflicts may occur and may need to be resolved through aborts as in mvto .  the pure blocking approach is unlikely to be applicable in practice .first , the computational complexity of deciding whether a chase step is safe is currently unknown , and we suspect that it is high .second , there is always a real possibility that an update that is given permission to proceed by a blocking scheduler could itself block for a long time while awaiting frontier operations .this locks down the entire system and may last indefinitely .thus , an optimistic approach is necessary , to allow updates to proceed even while others are waiting for user input . of course, aborts are always undesirable , and particularly so in youtopia , where an update redo may require repeated frontier operations from users .thus , the number of aborts must be minimized .the core of our optimistic approach is algorithm [ alg : optimistic ] .chase steps are scheduled according to a suitable policy which maximizes performance ; we discuss this further below .each chase step s writes are allowed to proceed , and each write is checked to determine whether it changes the answer to a previously - posed read query by a lower - priority update .if so , the reader is aborted , together with any updates which themselves have read from the reader.  choose next chase step ` c ` to schedule execute ` c ` abort update number and any others who have read from it ` q ` : = read queries actually performed by ` c ` store ` q ` for future checks  in this algorithm , the scheduler s queue of updates that are ready to take a step is populated asynchronously , as updates complete frontier operations and return control to the scheduler .this means that chase steps may indeed be scheduled while another update s step is waiting for frontier operations .this may appear to violate our logical assumption that interleaving only occurs at chase step level .however , as we noted before , this is only a logical constraint , and it is not difficult to maintain .a chase step performs all its writes and violation read queries before asking for user input , so those can not pose a problem .a step of a backward chase performs no further reads .a forward chase step may perform some correction queries after the user has performed a frontier operation ; however , those queries can be logged by the scheduler and checked against any writes that occur properly after them .algorithm [ alg : optimistic ] enforces conflict serializability through a property which is strictly stronger than chase step safety ; we call this property _ strong safety _ :chase step is _ strongly safe _ to perform for update with number on database iff for all , where each is a terminating extension for update number with respect to database , we have that for all read queries that may perform in step , and all prefixes of ,   that is , a step is strongly safe to perform iff all the answers to its read queries have completely stabilized with respect to writes by lower - numbered updates .we briefly discuss the implementation of checking whether a write retroactively changes the result of a previously posed read query .because read queries come in three very specific forms , this is not hard .correction queries can be checked against writes without needing to access the database ; a given tuple write changes the answer to a correction query either on all databases , or on none .for example , if a correction query asks for all tuples containing variable , a write changes the answer iff the tuple written contains .violation queries are somewhat more complex , and here the check to be performed requires accessing the database .however , the process is still simple , as a write can only change the answer to a violation query in a limited number of ways .for example , an insert can do so in two ways .it can contribute to the creation of a join result among relations on the lhs of a mappings , so that a new witness appears .alternatively , it can provide the last tuple that makes a tuple appear in the join of relations on the rhs of some rule .if the new rhs join tuple matches a previously existing witness , a violation is removed .based on the type of the write ( insert or delete ) it is possible to perform the check by posing a single query which combines the original violation query with information about the new tuple .tuple modifications are ( conservatively ) treated as a delete followed by an insert .algorithm [ alg : optimistic ] is a template which can be instantiated in a variety of ways with respect to the scheduling policy used and how cascading aborts are determined .when an update number aborts , all other updates which have read data affected by its writes must abort as well .as aborts are highly undesirable , it is important to develop accurate algorithms for determining such dependencies between updates.  a nave , strawman algorithm ( ` nave ` ) would abort all updates numbered .this is sufficient to guarantee correctness , but is clearly not optimal .it is much better to keep track explicitly of dependencies between updates ; whenever update issues a read query , the system determines not just the answer to , but also a list of updates with numbers whose writes directly influence the answer , that is , updates on which update now has a _read dependency_.   computing read dependencies can be done in two different ways , one more precise and more expensive than the other .as before , correction queries are the easy case : given a logged list of all previous writes , it is easy to determine which ones change the result of a given query .if the list is kept in memory , the dependencies can be computed without querying the database .violation queries , however , can not be processed so simply without sacrificing precision .the simpler of our two algorithms , ` coarse ` , does not query the database to determine read dependencies caused by violation queries . when it processes a violation query that involves a set of relations , it assumes that any update which has previously written any tuple to one of the may be the source of a read dependency .this is a conservative overestimate of the real read dependencies , so correctness is guaranteed .  the second algorithm , ` precise ` , trades off run time for precision . `precise ` determines accurately , for each violation query , which previous writes have changed the answer to the query .that is , it finds all those updates that have performed some write such that the answer to would be different if the write had not yet been performed . as such , it comes very close to the theoretical optimum in detecting only true read dependencies .however , achieving this precision requires asking relatively complex queries on the database ; the queries are closely related to those used to determine conflicts in algorithm [ alg : optimistic ] .   `coarse ` has linear time complexity in the number of writes performed so far on the database by updates which may still be aborted . for ` precise `, the dominating contribution to the complexity is the cost of the joins in the queries ; these joins are dictated by the mappings ( as in example [ ex : violationquery ] ) . in the worst case , their time complexity is polynomial in the size of the database and exponential in the join arity , i.e. in the number of atoms per side of a mapping .however , since the join predicates are a function of the mappings and thus known up front , it is possible to improve performance by appropriate indexing and join implementation .ultimately , the performance of our concurrency control algorithm is measured in terms of throughput as well as the number and kind of aborts .the relative weighting of these two factors depends on the specific real - world setting that the youtopia repository operates in , and we expect it to vary .we are developing a general and flexible set of scheduling policies that will be applicable to a wide range of parameters . here , we mention some of the factors involved .  ideally , update steps should be scheduled as soon as possible , and with as few aborts as possible .this means that the number of conflicts must be reduced as far as possible .some form of static analysis of the updates with respect to their expected future reads and writes is likely to be helpful ; however , such analysis may not always yield meaningful results .it may be more useful for the scheduler to develop heuristics about expected operations , based on data such as previous update behavior in the system . based on these heuristics ,updates less likely to conflict can be allowed to interleave more aggressively and/or run in parallel .once an update is chosen to run , the scheduler has to decide how long it may run . in some cases ,it may be beneficial to allow updates to complete an entire deterministic stratum ; in others , strict step - by - step scheduling is best .when an update blocks awaiting a frontier operation , the scheduler may permit other updates steps to proceed , as explained earlier .the decision will depend on the expected costs and benefits ; for example , if the frontier operations involve a table that has a good track record in terms of fast user response , the scheduler may choose to block in anticipation of the frontier operation .this is particularly true if the blocking update is worth waiting for " because , for example , many of the other running updates are likely to read from the relations involved in its frontier tuples .our experiments compare the performance of the algorithms ` nave ` , ` coarse ` and ` precise ` with respect to the number of cascading aborts and execution time . since youtopia s paradigm of relational cdi is new and there are no real - world datasets for us to benchmark our algorithms against , we have used synthetic data and mappings , as explained below .further , we needed to find a way to simulate frontier operations .our code does this by choosing an option uniformly at random among all available alternatives for a frontier operation . in practice, this has the additional advantage of making all chases terminate , even when mappings have cycles : a unification ( rather than expansion ) operation is chosen sooner or later on every forward chase path .our experiments are run on a database of 100 relations , each randomly generated to have between one and six attributes .the relations are connected by mappings ; each mapping is created by choosing a random subset of one to three relations for the lhs and another for the rhs .smaller sets have higher probability , as humans are highly unlikely to create mappings with more than one or two atoms on either side .the remaining step in mapping generation is the choice of variables in the atoms ; this is done randomly , with care taken to ensure that the mappings contain inter - atom joins as well as constants .any constants used come from a small ( size 50 ) fixed set of random strings .  generating the initial databaseis performed using our update exchange techniques themselves , with simulated user interaction ; it is not easy to obtain an interesting database that satisfies an arbitrary , potentially cyclic , set of tgds using another method .we generate ten thousand initial tuples .the relations receiving those tuples are chosen uniformly at random , and the attribute values come from the same set of constants that was used in mapping generation . by keeping the domain of attribute values small ,we ensure that joins between relations are highly likely to be nonempty , and that mappings are consequently highly likely to fire if these tuples are inserted .we insert these initial tuples into the database ; each insertion sets off a forward chase which only ends when all constraints are satisfied .we test our algorithms in several settings which vary in the number of mappings .we vary this number from 20 ( a sparse setting ) to 100 ( a dense one ) .settings with denser mappings are likely to exhibit longer chase runs , more writes , and therefore more conflicts and aborts ; indeed , this is borne out by our results . in our runs , the set of mappings we used is monotonically increasing that is , our experiments with 40 mappings involve the mappings used for the run with 20 mappings as well as 20 others , and so on . in all cases ,the initial database is the same and satisfies all 100 mappings .we show results on two workloads , each of 500 updates .the first consists entirely of inserts , the second of eighty percent inserts and twenty percent deletes .each update in each workload is started by an insert or delete operation generated randomly and independently .first , the receiving relation is chosen uniformly at random . in the case of inserts ,the values in the inserted tuples are chosen with equal probability to be fresh or from the previously mentioned set of constants . in the case of deletes ,the tuple to delete is chosen uniformly at random from the relation . in the mixed insert/ delete workload , the order of the updates is then randomized to ensure that the runs do not involve alternating large batches of inserts and deletes .the scheduling algorithm used in all our experiments is a round - robin policy that interleaves chases at the level of individual steps .all runs are allowed to run to termination , and each data point is obtained as the average of 100 runs .our results are shown in figures [ fig : insertexp ] and [ fig : mixedexp ] .the first graph of each figure shows the total number of aborts encountered during the run .clearly , both ` coarse ` and ` precise ` outperform ` nave ` significantly .we only show the first few points for ` nave ` , as the huge performance difference is apparent even with very sparse mappings .the second graph shows the total number of _ cascading abort requests _ during each run .this is the number of times during the run that the algorithm requests an abort even though the update involved is not in direct conflict with a just - performed write .thus , this is the number of _ purely cascading _ aborts requested .it does not have a direct correspondence to the total number of aborts observed during the run .this is because aborts are not performed as soon as they are made necessary by a write , but only once control is returned to the scheduler . in the meantime , abort information related to various writes performed by a chase step is collected and collated .updates are frequently marked for abortion multiple times during that phase ; however , the scheduler only performs aborts based on the consolidated information .this metric clearly shows the difference between ` coarse ` and ` precise ` ; indeed , in scenarios with lower mapping density , ` precise ` requests _ no _ cascading aborts .the final figure shows the relative time penalty associated with the use of ` precise ` over ` coarse ` .this is the ratio of per - update execution times for each algorithm .the per - update execution time is obtained by dividing the total time for the run by the number of updates which actually ran ( i.e. , the original 500 plus the number of aborts ) . in this way , we adjust for the fact that runs with ` precise ` involve a lower number of total update executions .the graph shows the relative slowdown rather than the per - update execution times themselves .the actual execution time increases for each algorithm with the number of mappings , which is not surprising , since more mappings require more read queries and more writes to be performed .our purpose here is orthogonal to demonstrating this increase : we aim to show the overhead of using ` precise ` instead of ` coarse ` across a variety of mapping density settings .our experiments show that ` coarse ` and ` precise ` significantly alleviate the cascading abort problem . as expected , ` precise ` does best , but at the cost of an increase in execution time . in practice, we expect that the reduction in the number of aborts will be so important to youtopia users that the increased execution time of ` precise ` will be acceptable .however , if this time overhead should prove too large , it is also possible to use a hybrid policy combining ` coarse ` and ` precise ` on a per - update basis .an update which is particularly important and which should not be aborted spuriously perhaps because it has already aborted several times can have its read dependencies determined using ` precise ` , so that it only aborts when it absolutely needs to .for less important updates , ` coarse ` can be used .we also remark that the absolute number of aborts across all our experiments remains quite high ; this underscores the need for a good scheduling policy to minimize the number of aborts that are non - cascading , i.e. , due to genuine conflicts .sections 2 through 5 of the paper include specific references to related work where appropriate . here , we take a broader perspective and give a brief overview of existing solutions for cdi tasks .there is a growing body of work which adapts classical data integration ideas to the community setting , including substantial theoretical work .systems like orchestra , piazza , hyperion and the system introduced in focus on maintaining data utility despite significant disagreement .however , none of these enable best - effort cooperation to its fullest extent . they all come with some centralized logical component that is an extensibility bottleneck ; usually this is either a global schema or an acyclicity restriction on the mappings , or both .in addition , they do not provide facilities for users to manage the metadata collaboratively .best - effort cooperation is fundamental in projects such as cimpl and mobs .however , these are designed for settings where disagreement is relatively mild and there is a meaningful notion of an authoritative version on the data and metadata ; not all cdi scenarios fall into this category .wikipedia and related systems have been higly successful at addressing all three of the cdi aspects ; they are highly cooperative , have a robust disagreement handling infrastructure , and achieve great success because of the utility of the data they contain . however, they only work for unstructured or mildly - structured data .furthermore , wikipedia does not fully support integration , requiring most data cleaning and management tasks to be done by hand .google base is a very interesting point in the cdi design space .it allows best - effort cooperation by making it easy for anyone to add data , whatever its content or format ; further , it does not require any agreement on the data .this raises a potential utility problem how can one easily query the database if there is no global schema ?this is solved by forcing nave users to interact with the database through predefined views such as `` hotels '' , `` recipes '' , etc .nevertheless , google base does not perform full data integration , and there is no support for collaborative data management . on the other hand , scientific data sharing portals such as birn and geon allow significant cooperation , perform substantial integration and permit some disagreement , but are not lightweight general - purpose solutions that are as easy for nontechnical users to work with as google base .given the lack of an ideal cdi solution , real - world web communities often just use a shared database .this happens , for example , on many vertical social networking sites .even when the community members themselves are not technically savvy , the data they share can have fairly substantial structure , as on the craft site ravelry .shared databases provide good data utility , but can not handle disagreement or nontrivial cooperation .schema extensibility in particular is a real problem , even among nontechnical users .for example , recent months have seen a debate on ravelry about the site s ( current ) inability to meet users wishes for tables devoted to additional crafts .cdi and the youtopia system are highly compatible with the dataspaces vision .indeed , a youtopia repository can be seen as a dataspace .however , our initial focus is more restricted : we set out to enable relational data sharing among members of a relatively knowledgeable and motivated community .we believe this setting is associated with unique challenges and opportunities , and deserves a dedicated solution .such a solution could profitably be integrated into any other dataspace designed for a setting where highly structured data is shared .throughout the paper , we have mentioned possible extensions to our models and algorithm , as well as areas in which we have ongoing work already .we also plan to add support for arbitrary tuple modifications rather than just global null - replacements ; those pose new challenges as they can cause both lhs - violations and rhs - violations , thus setting off a forward and a backward chase simultaneously .there are many interesting foundational questions related to our new chase model .for example , can a database always be brought to a state where it satisfies all mappings using only a finite sequence of frontier operations ?p. rodrguez - gianolli , m. garzetti , l. jiang , a. kementsietsidis , i. kiringa , m. masud , r. j. miller , and j. mylopoulos .data sharing in the hyperion peer database system . in _ vldb _ , pages 12911294 , 2005 .

Abstract: youtopia is a platform for collaborative management and integration of relational data . at the heart of youtopia is an update exchange abstraction : changes to the data propagate through the system to satisfy user - specified mappings . we present a novel change propagation model that combines a deterministic chase with human intervention . the process is fundamentally cooperative and gives users significant control over how mappings are repaired . an additional advantage of our model is that mapping cycles can be permitted without compromising correctness .   we investigate potential harmful interference between updates in our model ; we introduce two appropriate notions of serializability that avoid such interference if enforced . the first is very general and related to classical final - state serializability ; the second is more restrictive but highly practical and related to conflict - serializability . we present an algorithm to enforce the latter notion . our algorithm is an optimistic one , and as such may sometimes require updates to be aborted . we develop techniques for reducing the number of aborts and we test these experimentally .


phase locked loops , used in various applications , are required to generate frequency with low power consumption , within low settling time and reduced spurious tones .but , in most pll architectures , the trade - off existing between jitter , lock time and power does not allow all pll performance parameters to be optimized simultaneously .figure of merit ( fom ) defined in , which is commonly used to benchmark pll performance , does not include effect of increase in settling time , while reducing loop gain to reduce jitter , as shown in eqn .( [ eqn : fom ] ) .\ ] ]  for example , pll design in , having low jitter and power values , has good figure of merit as per eqn .( [ eqn : fom ] ) .but , this architecture achieves low jitter ( 0.4ps ) and low power ( 2.8mw ) , at the cost of very high settling time ( 300 ) .this instance signifies that without considering settling time as a performance parameter , the figure of merit in eqn .( [ eqn : fom ] ) is inadequate for benchmarking pll performance .  in this regard ,the trade - off between lock time and jitter is analyzed in this work , for different pll architectures .accordingly , commonly used figure of merit for pll is modified , to benchmark pll performance with consideration to all important specifications i.e. lock time , power and jitter .this work is organized as follows .section [ sec : bbpll]-[sec : hybrid_pll ] analyzes trade - off between settling time and jitter for non - linear bang - bang phase detector based pll ( bbpll ) , time - to - digital converter ( tdc ) based linear pll , and hybrid pll with adaptive gain .theroretical analysis for trade - off inherent in these pll systems , is backed up by results from behavioral simulation of verilog - a model of pll architectures , with varied loop gain .based on settling time vs. jitter curve fitting equation , obtained from pll behavioral simulations , section [ sec : proposed_fom ] proposes a new figure of merit , modified to consider lock time also as pll performance parameter .section [ sec : fom_cmp ] uses results from existing pll designs - , to show that proposed figure of merit correctly rates pll performance , based on overall improvement in specifications of lock time , jitter and power .bang - bang phase detector quantizes phase error between reference clock and feedback clock to only two levels , similiar to signum function . being a non - linear system , bang - bang phase detector based pll has its response characteristics dependent on input phase / frequency error magnitude . unlike pfd or tdc based architectures , wherein output response could be characterized with linear system transfer function in frequency domain ; analysis for bbpll has to be done in time domain .so , for analyzing trade - off between lock time and jitter in this system , settling time is derived using time - domain equations , by tracing trajectory of phase - detector output .[ fig : bbpll_arch ]  [ sec : bbpll_tradeoff ]   considering a case , wherein , at initial time - step ( t = 0 ) , phase error input is and frequency error input is 0 ; method explained below illustrates derivation of settling time for bbpll , by tracing number of up / down pulses in loop s transient state .+  [ fig : bbpll_ts ]  * step 1 : calculate number of up pulses * +  + ( i ) _ at t = _ : initial phase error = + ( ii)_at t = _ : with loop correction , phase error decreases by increase in frequency : -   phase correction , due to incremental frequency correction : + ( iii ) _ at t = _ : phase correction , due to added frequency ( ) , is : - ( iv ) _ at t = _ : reference clock and feedback clock aligns in phase , if accumulated phase correction due to frequency correction done by loop in each reference cycle , becomes equal to initial phase error : -  rcl _ o & = & 2 ( )     + solving above quadratic equation gives value as ,  rcl [ eqn : nup ] n_up & = &  though , after cycles , phase of reference clock and feedback clock is aligned , but , resultant frequency error ( normalized w.r.t ) accumulates to:-  rcl & = & + & & = k_i - k_p  * step 2 : calculate number of down pulses *  due to resultant frequency error ( ) after cycles , phase error starts accumulating with time ; which results in sequence of asserted down cycles .+ if phase error ( ) becomes 0 after cycles , then , number of down pulses are calculated as : -  \nonumber\ ] ] therefore , to derive settling time , equation for and cycles has to be recursively calculated until frequency error becomes 0 , at phase error alignment : -   according to eqn.([eqn : nup])-([eqn : ndown ] ) , settling time decreases non - linearly with increase in filter proportional gain( ) , digitally controlled oscillator gain ( ) , and ratio of filter s integral gain to proportional gain ( ) .peak to peak jitter for bbpll , derived in as eqn.([eqn : bbpd_jitter ] ) , indicates that jitter reduces with decrease in loop gain parameters , which are ( i ) ( ii ) ( iii ) ratio .rcl [ eqn : bbpd_jitter ] & = & nk_pk_t   eqn .( [ eqn : nup])-([eqn : bbpd_jitter ] ) indicates that settling time and jitter holds inverse non - linear relation to filter parameters and digitally controlled oscillator ( dco ) sensitivity gain . for verifying this trade - off relation between settling time and jitter , verilog - a model of bbpll is simulated with different values of filter co - efficients . as shown in fig .[ fig : bbpll_tradeoff ] , settling time vs. jitter curve follows non - linear relationship , and that , jitter is reduced at the cost of increased settling time .this illustrates the need of adding lock time as a parameter to the commonly used fom .for analyzing tdc based pll with equivalent s - domain model ( analogous to charge pump pll ) , system transfer function is approximately given as : - +    considering decay constant from system transfer function , settling time for type-2 pll is approximately given as : - + eqn .( [ eqn : ts_adpll ] ) indicates that with decreasing dco gain and filter proportional gain , settling time increases linearly .when tdc - based pll locks to frequency corresponding to fractional value input to dco , control word oscillates between .so , with lower dco gain ( ) and filter proportional gain ( ) , jitter reduces linearly for output frequencies corresponding to fractional control word : -    behavioral simulation of tdc based pll model with varying dco gain , indicates linear trade - off between settling - time and jitter ( i.e. jitter increases and lock time decreases by same percentage with varied ) following linear curve fitting equation , as shown in fig.[fig : tdc_tradeoff ] .so , based on eqn.[[eqn : ts_adpll]]-[[eqn : jit_adpll ] ] and simulation results , figure of merit is proposed to be modified to include linear trade - off between settling time and jitter , by considering lock time in same ratio as jitter .hybrid pll , in fig .[ fig : adaptive_gain_pll ] , employs two different phase detector blocks for fast linear system response in transient state , and low jitter in settled state . here, linear phase - frequency detector ( pfd ) is activated in case of large input phase error , for fast coarse settling ; and binary phase detector is activated for small phase error , to avoid the dead zone issue .adaptive gain feature allows filter gain to be changed , according to input phase error magnitude .     during loop transient in hybrid pll ,linear pfd is active as error - detection block for major portion of settling time .this results in loop settling curve to follow linear response , as per eqn .( [ eqn : adpll_tf ] ) ( which represents system response for linear pll system ) .so , in case of hybrid pll also , linear trade - off between settling time and jitter is observed in behavioral simulation with varied , as shown in fig .[ fig : a1_pll_dco_tradeoff ] .   in hybrid pll , non - linear bang - bang phase detector is activated only when loop reaches near to locked state .therefore , reducing loop filter gain in bang - bang phase detection mode , can reduce jitter without significant linear increase in settling time .this overall performance improvement is verified by simulating hybrid pll verilog - a model , with varied filter coefficients in binary phase detection mode .simulation results in fig .[ fig : a1_pll_filt_tradeoff ] shows that jitter reduces with reduced filter gain ( while binary phase detector is active in settled state ) , without significantly increasing settling time ( since , lock time is mainly governed by loop parameters while pfd is active ) .so , this kind of pll design , wherein all the specifications ( lock time / jitter / power ) could be simultaneously improved , can be benchmarked as having higher figure of merit .pll performance analysis for different pll architectures , in sec .[ sec : bbpll]-[sec : hybrid_pll ] , shows inverse relation that settling time and jitter holds with loop gain . considering lock time vs. jitter performance observed in linear pll system ,it is proposed to include settling time in figure of merit equation , in same ratio as jitter , as shown in eqn .( [ eqn : fom_adpll ] ) .\ ] ]table-[tab : result_cmp ] uses results of existing pll architectures ( designed in 180nm-90 nm technology , with output frequency in 0.5ghz-1.8ghz range ) , to compare performance benchmarking done with commonly used figure of merit versus proposed figure of merit in this work .  in table-[tab :result_cmp ] , performance comparison for 130nm/90 nm designs , indicates that for pll achieving lowest jitter at the cost of large settling time , existing fom proves as an inadequate benchmark by ignoring lock time performance degradation .similarly , performance comparison for 180 nm designs , indicates that pll having lowest settling time at the cost of increased jitter is benchmarked for having lowest performance with fom defined in ( which does not considers reduced lock time as improved pll performance parameter ) .proposed figure of merit , on the other hand , correctly marks pll designs for their overall performance , by considering inverse relation existing between settling time and jitter ( as indicated in table-[tab : result_cmp ] ) ..perfomance benchmarking for pll architectures [ cols="^,^,^,^,^,^,^,^ " , ]   fig .[ fig : new_fom ] shows performance of existing pll designs , with consideration to lock time , along with output jitter and power dissipated by pll system .in this work , with analysis and behavioral simulation of different pll architectures , trade - off between settling time and jitter is shown . since, most pll designs are able to achieve low jitter only at the cost of increased settling time , therefore , it is proposed to include lock time also as performance parameter in figure of merit for pll .xiang gao ; klumperink , e.a.m . ; geraedts , p.f.j .; nauta , b. ; , `` jitter analysis and a benchmarking figure - of - merit for phase - locked loops , '' _ circuits and systems ii : express briefs , ieee transactions on _ , vol.56 , no.2 , pp.117 - 121 , feb .2009 . da dalt , n. ; , `` a design - oriented study of the nonlinear dynamics of digital bang - bang plls , '' _ circuits and systems i : regular papers , ieee transactions on _ , vol.52 , no.1 , pp .21- 31 , jan . 2005 .hu , j.r . ;ruby , r.c . ; otis , b.p . ; , `` a 1.56ghz wide - tuning all digital fbar - based pll in 0.13 m cmos , '' _ custom integrated circuits conference ( cicc ) , 2010 ieee _ , pp.1 - 4 , 19 - 22 sept . 2010 .deok - soo kim ; heesoo song ; taeho kim ; suhwan kim ; deog - kyoon jeong ; , `` a 0.3 - 1.4 ghz all - digital fractional - n pll with adaptive loop gain controller , '' _ solid - state circuits , ieee journal of _ , vol.45 , no.11 , pp.2300 - 2311 , nov . 2010 .vidojkovic , m. ; yao - hong liu ; huang , x. ; imamura , k. ; dolmans , g. ; de groot , h. ; , `` a fully integrated 1.72.5ghz 1mw fractional- n pll for wban and wsn applications , '' _ radio frequency integrated circuits symposium ( rfic ) , 2012 ieee _ , pp.185 - 188 , 17 - 19 june 2012 .i - ting lee ; yun - ta tsai ; shen - iuan liu ; , `` a fast - locking phase - locked loop using cp control and gated vco , '' _ vlsi design , automation , and test ( vlsi - dat ) , 2012 international symposium on _ , pp.1 - 4 , 23 - 25 april 2012 .kamath , a.s . ; chattopadhyay , b. ; , `` a 13mhz input , 480mhz output fractional phase lock loop with 1mhz bandwidth , '' _ circuits and systems ( iscas ) , proceedings of 2010 ieee international symposium on _ , pp.501 - 504 , may 30 2010-june 2 2010 .young - hun seo ; seon - kyoo lee ; jae - yoon sim ; , `` a 1-ghz digital pll with a 3-ps resolution floating - point - number tdc in a 0.18 cmos , '' _ circuits and systems ii : express briefs , ieee transactions on _ , vol.58 , no.2 , pp.70 - 74 , feb . 2011 .shih - yuan kao ; shen - iuan liu ; , `` a digitally - calibrated phase - locked loop with supply sensitivity suppression , '' _ very large scale integration ( vlsi ) systems , ieee transactions on _ , vol.19 , no.4 , pp.592 - 602 , april 2011 .chia - tsun wu ; wen - chung shen ; wei wang ; an - yeu wu ; , `` a two - cycle lock - in time adpll design based on a frequency estimation algorithm , '' _ circuits and systems ii : express briefs , ieee transactions on _ , vol.57 , no.6 , pp.430 - 434 , june 2010 .

Abstract: in most pll architectures , trade - off exists between settling time and jitter performance , which is ignored during figure of merit calculation . this work derives a new figure of merit for pll , which has settling time as added performance parameter , along with jitter and power . here , the trade - off between settling time and jitter is analyzed theoretically , and with behavioral simulations for ( i ) linear time - to - digital based pll ( ii ) non - linear bang - bang phase detector based pll ( iii ) hybrid pll with adaptive gain , to obtain settling time vs. jitter relation , based on which commonly used figure of merit is modified . to understand trade - off relation between settling time and jitter for bang - bang phase detector based pll , this work also derives settling time equation for non - linear pll , by using recursive time - domain equations .