Using Extended Logical Primitives for Efficient BDD Building

Abstract

Binary Decision Diagrams (BDDs) have been used to represent logic models in a variety of research contexts, such as software product lines, circuit testing, and plasma confinement, among others. Although BDDs have proven to be very useful, the main problem with this technique is that synthesizing BDDs can be a frustratingly slow or even unsuccessful process, due to its heuristic nature. We present an extension of propositional logic to tackle one recurring phenomenon in logic modeling, namely groups of variables related by an exclusive-or relationship, and also consider two other extensions: one in which at least n variables in a group are true and another one for in which at most n variables are true. We add XOR, atLeast-n and atMost-n primitives to logic formulas in order to reduce the size of the input and also present algorithms to efficiently incorporate these constructions into the building of BDDs. We prove, among other results, that the number of nodes created during the process for XOR groups is reduced from quadratic to linear for the affected clauses. the XOR primitive is tested against eight logical models, two from industry and six from Kconfig-based open-source projects. Results range from no negative effects in models without XOR relations to performance gains well into two orders of magnitude on models with an abundance of this kind of relationship.

1. Introduction

Formal methods use logical representations of models to enable complex analyses. One such representation are Binary Decision Diagrams (BDDs), an evolution of Binary Decision Trees [1]. BDDs can represent the solutions of a propositional logic formula in a way which allows to easily compute properties of the solutions. In this regard, BDDs are a competing technology to SAT-solvers and #SAT-solvers. A SAT-solver is a program that takes a propositional formula and determines if it is satisfiable. It does so by running a heuristic tree search over the variables in the formula. #SAT-solvers go further and compute the number of satisfying assignments (i.e., the number of solutions to the problem). SAT and #SAT-solvers have enjoyed much attention in the past years due to the so-called SAT revolution during which great progress (of several orders of magnitude) was made in terms of performance.

A BDD compiles the information about the formula in a graph that can be traversed to compute sophisticated analyses of the model. The advantage of BDDs is that, for many problems, a single traversal of the graph can produce the solution, while SAT-solver technology often requires creating many slightly different formulas and calling the solver for each one of the variants, with the subsequent loss of efficiency. Another interesting property of BDDs is that its construction does not require the input to be in Conjunctive Normal Form (CNF) as opposed to SAT-solvers. Conversion to CNF can produce an exponentially longer formula, which is a bad start for an NP-complete problem such as SAT [2]. The main disadvantage of BDDs is that the construction of the graph, also known as BDD synthesis, may explode in terms of time and space, and finding an optimal graph is also an NP-complete problem [3]. There are several variations of BDDs, but the most widely employed is Reduced Ordered Binary Decision Diagrams (ROBDDs), to the point that they are usually just called BDDs. These BDDs are ordered in the sense that there is an ordering of the variables that cannot be violated (i.e., for each parent and child nodes, the variable of the parent appears earlier in the ordering than the variable of the child). BDDs are known to be very sensitive to the ordering of the variables, so that different orders can produce BDDs with very different numbers of nodes. Just as SAT-solvers rely on heuristic search, BDD synthesis relies on heuristics to find a good ordering. So far, there has been no BDD revolution, so interest in BDDs has been declining.

This paper hopes to spur back interest in BDDs by providing a performance improvement of several orders of magnitude for some models. Instead of delving into the waters of heuristic orderings, our aim is to exploit common structures in logical models, namely atLeast-n, atMost-n and XOR constraints over variables x${}_1$, x${}_2$, …, x${}_m$ meaning that at least n variables are true, at most n variables are true and that exactly one of the variables has to be true, respectively. Instead of translating these constructions to propositional logic, which would produce a combinatorial explosion of clauses (a clause is a disjunction of literals. A literal is a variable v or its negation $\neg v$), our approach consists in creating new primitives; atLeast-n, atMost-n and XOR, thereby extending our logic representation.

The standard way of synthesying BDDs applies one clause at a time to the BDD. We will prove that for the encoding of atLeast, atMost and XOR, this creates at least one new node for each clause, many of which are not used in the final BDD. Apart from speeding up the translation, our approach can be directly implemented in the graph, meaning that only the necessary nodes are created. In the case of the XOR, this means a reduction in the creation of nodes from quadratic to linear for the parts of the model which display this pattern. We will look for the XOR constructions in two different realms; Feature models and the translation to logic of Kconfig language configuration files, and show that our approach builds BDDs significantly faster (up to two oders of magnitude) when XOR groups are identified and imposes no penalty if there are none.

Since BDD synthesis often relies on heuristics and different parameters, speeding up the process is not only useful for pursuing a specific application, but also for the advancing of the systematic knowledge about which techniques work best in particular scenarios, as it allows to try more approaches in the same amount of time.

The remainder of the paper is structured as follows: Section 2 covers related work. Section 3 deals with translating some FM notations to propositional logic. Section 4 shows how to extend a BDD engine to build XOR groups efficiently and proves some lower bounds on the number of nodes created. Section 5 explains the experimental evaluation performed and Section 6 discusses the conclusions and future work.

2. Related Work

One field in which both SAT-solvers and BDDs have been employed is Software Product Lines (SPLs). A SPL is an engineering effort to produce families of related software products reusing assets, also known as features. SPLs are often described using Feature Models (FMs) [4]. Figure 1 shows the FM for a smart home. A FM uses a predetermined notation to represent a product line. Mandatory nodes represent features which are always present. Optional nodes can be present or not in a product. Any of the children of an or-node can be selected. Finally, exactly one of the children of a xor-node can be present in a product. Feature models can also depict constraints among the features, in this case, there are three of them:

• Viewer requires Reflective Data Structure
• Execute Tests requires Deploy Tests
• Authorization requires Authentication

These relationships have been graphically shown as arrows in the diagram. The XOR and OR constructions in the feature model match exactly the logical XOR and atLeast-1 extensions, respectively. For example, the Test subtree has two OR descendants, which is equivalent to atLeast-1(Deploy Tests, Execute Tests). Furthermore, Execute Tests requires Deploy Tests. Therefore, there are only three valid configurations for this subtree:

• {$\neg$Test, ¬Deploy Tests, ¬Execute Tests}
• {Test, Deploy Tests, ¬Execute Tests}
• {Test, Deploy Tests, Execute Tests}

It is worth noting that Feature Oriented Display Analysis (FODA) [4] supports representing the same semantics in different graphical ways, depending on the modeler’s intentionality. For example, an interchangeable Test subtree would have Deploy Tests as mandatory and Execute Tests as optional.

Product line analysis of a FM can be used to determine a great deal of properties about the product line, for instance features that are never used (i.e., dead features) [4,5,6], or features that are always used (i.e., core features) [5,6], as well as the probability of any particular feature being present in a product [7].

So far, product line analyses have been restricted to small models, simplified models, superficial analyses or a combination thereof [8,9,10,11,12,13,14,15] due to the computational complexity of dealing with formulas involving large numbers of variables with complex relations between them, as well as the need to perform a large number of calls to the logic engine of choice.

Suppose, for instance, that you need to know the probability of a particular feature in a product line. This can be useful to create a random sample of products, as well as to assess the uniformity of the sampling approach [16]. A common approach is to call a model counter once to get the total number of products of the model $\varphi$, and then once again for each feature f, with the argument $\varphi \wedge f$, and divide the latter by the former to obtain the probability of f.

However efficient model counters are, this involves repeating a great deal of the heuristic search. For this reason, it is much more efficient to use BDDs to compute all the probabilities in one traversal of the graph [7]. However, synthesizing the BDDs can be a resource-consuming task.

BDD synthesis has traditionally been a complicated issue in which, lacking a general approach, each underlying domain has relied upon different techniques. BDDs have been used to represent fault trees in plasma reactors [17,18,19,20] perform circuit optimization and verification [21,22,23,24,25,26,27,28,29,30,31,32,33,34] and in software product lines [6,7,11,15,35,36,37,38,39,40,41,42,43,44,45]. The circuit domain can sometimes add additional hypotheses, such as gates, which are represented by variables that occur only once in the model formula to obtain better bounds or even optimal algorithms. Nevertheless, some ordering heuristics, both static and dynamic, have enjoyed the benefit of being useful across the board, such as FORCE [46], MINCE (Min Cut Etc.) [47] among the static ones and sifting [48,49] as a dynamic reordering heuristic.

The extension to logic that we propose in this paper could easily fit with small changes into what is known in the SAT community as Satisfiability Modulo Theories (SMTs) that is, using standard SAT techniques together with a black box that solves particular problems. Some examples of SMTs include the use of uninterpreted functions, different algebraic extensions to logic, and even XOR clauses, although this applies to bitwise XOR, i.e., checking if the number of 1s is odd, as often used in hashing and cryptography, not to the kind of cardinality constraint we have been discussing in this paper. However, this black-box approach is supposed to incur in a performance penalty. A more interesting approach would be to create a hybrid SAT, in this case, a conventional SAT solver that integrates XOR restrictions as a part of the Boolean Constraint Propagation (BCP) engine.

In any case, adapting the approach to SAT technology is outside the scope of this paper. There is compelling evidence that BDDs perform better than SAT when the BDD synthesis is possible, at least for some SPL engineering problems [6,7,50,51,52]. This is especially true w.r.t. #SAT solvers, which need to always traverse the whole search space.

Cardinality constraints are common in variability models. Figure 2 summarizes the percentage of XOR, atLeast-1 and atMost-1 constraints that Berger et al. [53] found after analyzing 128 variability models from 12 open-source projects specified with the languages SPLOT, CDL, and Kconfig. In general, the atLeast and atMost operators are expected to be found less commonly in logical models. However, the XOR construction is very common because, as Biere et al. [54] explain, it is the natural way to encode a variable, v, taking values in a discrete domain of values {$v_1$, $v_2$, …, $v_n$}. Another reason is that XOR is already the conjunction of atLeast-1 and atMost-1.

In this paper we associate high-level language constructions to patterns. An alternative approach is to look for the XOR, atLeast and atMost operators directly into the Boolean formula [54].

3. Translating FMs to Extended Propositional Logic

Feature models are an interesting application domain for testing the effectiveness of the approach. In this section, we apply the extended propositional logic to two important sources of FMs, namely FODA and Kconfig models.

3.1. FODA

FODA stands for Feature Oriented Domain Analysis [4], and it provides a notation to represent FMs graphically. In FODA, a model is represented by a tree of features with different relations between them. An example FODA model can be seen in Figure 1. We are interested here mostly in the XOR group cardinality, in which only one feature in a group is to be present in the product. In the example in Figure 3 we can see one of these XOR groups applied to the different ways of taking a screenshot in Ubuntu. FODA models can also incorporate cross-tree constraints (i.e., arbitrary logical constraints) between the features to further restrict the products in the product line.

The translation of FODA models to standard propositional logic is rather straightforward [37]. It can be summarized in the following steps:

• Every feature f, except the root feature, has a parent feature p, and the child must imply the parent: $f\to p$
• in the case of a mandatory feature, f, the parent, p, also implies the child: $p\to f$
• in the case of an Or group of n features, at least one of the features is selected. For $f_1$, $f_2$, …$f_n$: ${\bigvee }_{i=1}^n{f}_i$
• in the case of an XOR group of n features, exactly one of the features is true and the others are false. For $f_1$, $f_2$, …$f_n$: ${\bigwedge }_{i<j}\neg (f_i\wedge f_j)\wedge {\bigvee }_{i=1}^n{f}_i$
• The cross-tree constraints need not be translated, as they are already in logical format.

The problem with this translation lies in step 4. The disjunction of the features does not pose a problem, but the part of not more than one feature being true is more problematic, as the number of clauses grows very fast. For n features, this would translate in $n(n-1)/2$ clauses in the translation, a quadratic growth. It is not uncommon to find XOR groups with hundreds of features and in these cases the clauses related to XOR groups make up the vast majority of the translation. We propose to extend our set of logical primitives with a new one: XOR. This way, step 4 of the translation would simply read like this:

In the case of an XOR group of n features: $f_1$, $f_2$, …, $f_n$, the translation would be: XOR($f_1$, $f_2$, …, $f_n$).

3.2. Kconfig

Figure 4 shows a snippet of code in the Kconfig language, which is used to configure the Linux kernel, among other open source projects. The human configurator needs to answer a series of questions in order to assign values to a set of symbols which are used to configure the kernel before it is compiled. The language allows different value types for the symbols, namely bool, tristate, string, int and hex. The vast majority of symbols for the evaluated projects are bool, so we only translate those for simplicity. The choice construction in Kconfig means that the user must select exactly one of the options. In this case, some buffer needs to be allocated in memory and the user is given three choices as to the location. The kconfig language is complicated but its translation to logic has been extensively researched [55,56,57,58,59,60,61]. Suffice it to say that the meaning of the choice construct for Boolean symbols in Kconfig perfectly matches the XOR construction (i.e., one the options is true and the rest are false).

4. Building BDDs for Extended Logic

Our approach analyzes the model to identify parts equivalent to XOR, atLeast, and atMost. Then, it translates those parts into the extended logic constructs. This way, the size of the Boolean formula is reduced. Then, the new primitives in the formula are exploited to build the BDD more efficiently. For instance, consider again the code snippet in Figure 4. The translation to logic, which uses standard propositional logic, can be seen in Figure 5, while the translation using the XOR primitive is showed in Figure 6.

Figure 7 shows the BDD corresponding to an XOR primitive of variables $x_1,x_2,\dots ,x_n$. The edges going to node 0 and node 0 itself have been omitted for clarity. The solid lines represent setting the variable to true and connect the parent with the high child, and the dotted edges mean setting it to false, and connect the parent with the low child. This BDD only has $2n-1$ nonterminal nodes. The novelty of this approach is that the BDD can be created using exactly one call to the BDD engine per node. The pseudocode needed to generate this BDD is shown in Algorithm 1. The BDD graph is built in a bottom-up fashion. To do this, the list of variables must be first ordered in descending position order, so that the variables corresponding to the lower levels in the graph go first, and the variable in the top of the BDD is the last one treated. The algorithm relies on a function CreateOrFind(var, thenNode, elseNode), which looks for a node corresponding to variable $var$, with children $thenNode$ and $elseNode$. If such a node exists, it is returned, if it does not, it is created and returned. Luckily this function is already known in efficient BDD engine programming as it is the basis to build the unique table [62].

Algorithm 1: Direct construction of the BDD for an XOR primitive

Figure 8 shows the BDD for the atLeast-3 relation.The algorithm to compute the BDD for atLeast is slightly more complex than the XOR case and can be found in Algorithm 2.

Algorithm 2: Direct construction of the BDD for $\mathrm{atLeast}-n$ primitive

Computing the BDD for atMost relations can be reduced to the atLeast case because $\mathrm{atMost}$-n($x_1$, $x_2$, …, $x_m$) ≡ atLeast-(m-n)($\neg x_1$, $\neg x_2$, … $\neg x_m$). Algorithm 2 works with literals, so it can be used as is to compute this last expression.

We prove later in this section that the usual encodings of XOR, atLeast-n and atMost-n produce $1+\left(\genfrac{}{}{0pt}{}{m}{2}\right)$, $\left(\genfrac{}{}{0pt}{}{m}{n-1}\right)$ and $\left(\genfrac{}{}{0pt}{}{m}{n+1}\right)$ clauses, respectively, that have to be applied to the BDD iteratively, while the extended approach reduces this to a single clause. The final result is computed directly in the extended approach with node creation reduced to the strictly minimal, while the traditional one creates intermediary nodes that are later deleted as clause processing continues.

To exemplify this behavior, consider the formula XOR(a, b, c). In traditional logic, the encoding has four clauses: $a\vee b\vee c$, $\neg a\vee \neg b$, $\neg a\vee \neg c$, $\neg b\vee \neg c$. Figure 9, shows how the BDD changes as each clause is applied. The orange nodes are nodes that have been created in that step. In Figure 9a, a node for each variable is created. In Figure 9b, a new node for b is created. Because nodes are created and identified by the variable they represent and its two children, the node for a has also been created because its high child has changed from 0 to the new node for b. In Figure 9c, there is a new node for c, which in turn needs a new node for b which prompts for a new node for a. In the last step, a new node for b is created to account for the change in its high child, which prompts the creation of a new node for a.

In total, during four steps, ten nodes have been created, of which only five where necessary. The extended logic approach involves one step, creates five nodes and does not create any unnecessary nodes. The traditional encoding is inefficient because it creates a quadratic number of nodes, more than $1+\left(\genfrac{}{}{0pt}{}{n}{2}\right)$, to retain only $2n-1$ at the end. The extended approach computes only the necessary nodes. We now establish a lower bound for the number of nodes created using the traditional encoding. The bound is not tight because different orderings of the clauses produce different amounts of intermediary nodes, even if the final BDD is the same.

Definition 1.

A node in a BDD is either the terminal node 0, the terminal node 1, which have no children, or it is a nonterminal node uniquely determined by the variable it represents together with two children nodes called low and high, which represent the effect of setting the variable to false and to true, respectively.

BDDs are reduced, which means there can be no two different nodes with the same variable and children so, the previous definition makes sense. The following lemma provides a lower bound to the creation of new nodes in a series of BDDs which mimicks the repeated use of the apply operation to create a BDD representing a set of clauses. Please note that we are interested in the creation of new nodes, not in the total number of nodes in the BDD, which may grow or shrink during the apply process, because a node created can be later discarded when it is no longer part of the BDD.

Lemma 1.

Let $V=\{x_1,x_2,\dots ,x_m\}$ be a set of variables, $C=\{c_1,c_2,\dots c_n\}$ a set of clauses over V, such that ${\bigwedge }_{j=1}^{i-1}{c}_j⊭c_i$, and its conjunction is satisfiable, and let $B=\{b_0,b_1,\dots ,b_n\}$ be a set of BDDs over V such that $b_0$ represents the formula ⊤ and $b_i$ with $i>0$ represents the formula ${\bigwedge }_{j=1}^i{c}_j$. Then, each BDD $b_i$, $1\le i\le n$ has at least a new node w.r.t its predecessor.

Proof. 

The proof uses induction over the succession of BDDs $b_i$ when $i>0$: $b_0$ has no nonterminal nodes. $b_1$ represents $c_1$ which is satisfiable and cannot be ⊤ or ⊥, so $b_1$ has at least one nonterminal node. We now assume that the lemma holds for all $b_j$, $1\le j\le k$ and proceed to prove that $b_{k+1}$ has at least one new node w.r.t. its predecessor. By the induction hypothesis we know that at least one new node is created at each apply step since the first, so $b_k$ has at least one nonterminal node, and so, there is a nonterminal node as the root. The change from $b_k$ to $b_{k+1}$ consists of applying $c_{k+1}$ to $b_k$. Since, by hypothesis, ${\bigwedge }_{j=1}^k{c}_j⊭c_{k+1}$, it means that the set of satisfying assigments for $b_{k+1}$ is a strict subset than that of $b_k$. Let $\sigma$ be one variable assignment that satisfies $b_k$ but not $b_{k+1}$. In $b_k$ there is one path from the root to node 1 which contains $\sigma$. $b_{k+1}$ also has a nonterminal root, since it represents neither ⊤ nor ⊥. Because $\sigma$ does not satisfy $b_{k+1}$, there is one path from the root of $b_{k+1}$ to 0 which contains $\sigma$. At least one of the nodes along this path is new w.r.t. $b_k$, otherwise they are present also in $b_k$ and that would contradict $\sigma$ satisfying $b_k$. □

Now we use the lemma to prove three theorems about the number of nodes created by the traditional encoding of the cardinality operators.

Theorem 1.

The traditional encoding to create a BDD for atMost-m($x_1$, $x_2$, …$x_m$) creates at least $\left(\genfrac{}{}{0pt}{}{m}{n+1}\right)$ nodes.

Proof. 

The encoding for atMost-n has $\left(\genfrac{}{}{0pt}{}{m}{n+1}\right)$ clauses, namely,

$$C=\{\neg y_1\vee \neg y_2\vee \dots \vee \neg y_{n+1}|y_k\in V,1\le k\le n+1,y_i\ne y_j\mathrm{if}i\ne j\}$$

Let $\sigma$ be a variable assignment with at most n variables set to true and let c be a clause in C. C has n+1 variables so at least one of them is assigned false in $\sigma$, which means that $\sigma$ satisfies c. Now let M be a model for C and let be $\tau$ be a variable assignment from M. At most n variables in $\tau$ are true, because if there are n+1 variables assigned to true, there is one clause in C which is not satisfied, which contradicts M being a model of C.

The conditions of the Lemma 1 apply to C, whichever the order of the clauses, so at least $\left(\genfrac{}{}{0pt}{}{m}{n+1}\right)$ nodes are created. □

Theorem 2.

The traditional encoding to create a BDD for atLeast-n($x_1$, $x_2$, …$x_m$) creates at least $\left(\genfrac{}{}{0pt}{}{m}{n-1}\right)$ nodes.

Proof. 

The encoding for atLeast-n has $\left(\genfrac{}{}{0pt}{}{m}{n-1}\right)$ clauses, which is equal to $\left(\genfrac{}{}{0pt}{}{m}{m-n+1}\right)$, namely,

$$C=\{y_1\vee y_2\dots \vee y_{m-n+1}|y_k\in V,1\le k\le m-n+1,y_i\ne y_j\mathrm{if}i\ne j\}$$

Let $\sigma$ a variable assigment with at least n variables assigned to true. That means that at most $m-n$ variables are set to false, so if we choose any group of $m-n+1$ variables, at least one is true, so all the clauses in C are satisfied by $\sigma$. Now let M be a model of C and $\tau$ a variable assignment from $\tau$. At least n variables from $\tau$ must be assigned to true, otherwise there is a group of $m-n+1$ variables in $\tau$ which are assigned to false, and then one clause in C would not be satisfied.

Again, the conditions of Lemma 1 are met regardless of the order of the clauses, so at least $\left(\genfrac{}{}{0pt}{}{m}{n-1}\right)$ nodes are created. □

Theorem 3.

The traditional encoding to create a BDD for XOR($x_1$, $x_2$, …$x_m$) creates at least $1+\left(\genfrac{}{}{0pt}{}{m}{2}\right)$ nodes.

Proof. 

The traditional encoding has $1+\left(\genfrac{}{}{0pt}{}{m}{2}\right)$ clauses, namely,

$$C=\{x_1\vee x_2\dots \vee x_m\}\cup \{\neg x_i\vee \neg x_j|y_i\ne y_j\mathrm{if}i\ne j\}$$

The first part corresponds to atLeast-1 and the second to atMost-1, according to the two previous theorems. These clauses can be applied in any order, but they meet the conditions of Lemma 1. Since there are $1+\left(\genfrac{}{}{0pt}{}{m}{2}\right)$ steps, there at least as many nodes created along the process. □

5. Experimental Validation

5.1. Research Questions

Our experimental evaluation targets three research questions:

• RQ1: Boolean formula size-reduction. Does extended logic decrease the Boolean formula number of clauses in practice?
• RQ2: Time for obtaining extended logic formulas. How much time does it take to translate an input model into a Boolean formula with extended logic compared to the non-extended logic translation?
• RQ3: BDD synthesis time. Does extended logic reduce BDD build time in practice?

5.2. Experimental Setup

For the evaluation, we compared the building process of BDDs with and without using the XOR connective for a number of software projects. We did not find any occurrences of atLeast-n or atMost-n with n bigger than one. All occurrences of atMost-1 and atLeast-1 occurred together, so we considered them as XOR.

Table 1. Number of features and XOR-groups for each system.

System	#Features	#XOR-Groups
Toybox	10	0
axTLS	64	6
DellSPLOT	118	13
Fiasco	122	18
$\mu$Clibc	303	27
BusyBox	604	8
EmbToolKit	2325	130
Automotive02	17,365	1161

shows the systems used as test-bed. The systems chosen vary in size from very small to very large, so the scalability of the approach may be adequately assessed. Furthermore, the systems were drawn from two different sources, namely open-source projects using the Kconfig configuration system, and two feature models from industry using the SPLOT format.

The SPLOT repository (http://www.splot-research.org) contains over a thousand feature models in an XML format that has become a standard for FODA-like projects. This splot file format is widely used elsewhere, so we developed the tool splot2model that translates a splot file to two files, one to contain the order of variables and another one to hold the formulas. This tool has an option to use the XOR connective or not. We chose an automotive model from [63] and a Dell laptop model from [64]. For Kconfig files, we developed a similar approach, with a tool called Kconfig2Logic with an option to use the XOR construction.

All the tools and data needed to replicate the experiments can be found in: https://github.com/davidfa71/Extending-Logic.

The BDD engine used was the CUDD package (https://github.com/vscosta/cudd), for which we coded the extension discussed in the previous section. The FindOrCreate function is already builtin in CUDD and is called UniqueTable. The experiments were run in an HP Proliant Server with 2 Xeon E5-2660v4 CPUs (2.0 Ghz).

5.3. Results

5.3.1. Boolean Formula Size-Reduction (RQ1)

Each logical model is the conjunction of a number of clauses. We compared the number of clauses produced in both of the translations of the projects. The results can be seen in Figure 10.

There is a significant reduction in the number of extended clauses, except for Toybox, which does not include any XOR-group at all, and BusyBox, which has a very low proportion of XOR-groups related to its number of features. The most extreme cases are Fiasco and Automotive02. For Fiasco, the standard translation has 2364 clauses, and the extended translation has 186 clauses, a reduction of 92.14%. For Automotive02, the translations have 321,933 and 5616 clauses respectively, a reduction of 99.98%.

5.3.2. Time for Obtaining Extended Logic Formulas (RQ2)

The next question was to assess if the extended logic imposes a time penalty when translating the model in its original form (Kconfig code or SPLOT format) to logic. Figure 11 shows the results.

The extended logic translation was faster in all cases, except for Toybox for which both translations are the same. For the biggest models, the translation was much faster with the extended logic, notoriously for Fiasco and Automotive02, for which the extended approach was seven and sixteen times faster, respectively, which indicates that performance gains correlate well with the number of XOR constraints relative to the number of features.

5.3.3. BDD Synthesis Time (RQ3)

The last research question, which is the most important one, refers to whether extended logic helps to speed up BDD construction. Figure 12 shows the results.

The build times for the four smaller models are very similar for both approaches, but for the four biggest (the second row in the plot) the performance gains are considerable: for Fiasco, building the BDD with the extended logic was almost 10 times faster, and for Automotive02, it was 205 times faster than using the standard logic translation, from 1 h and 20 min to 23 sec, so the answer is yes, especially if the model contains a lot of exclusive-or cardinality restrictions.

6. Conclusions and Future Work

Efficient building of BDDs is of paramount importance to its widespread use. A long building phase can easily offset the benefits of fast analysis algorithms. In this paper, we have identified a major obstacle in BDD building and developed a mitigation strategy with a complexity reduction from a quadratic number of created nodes to a linear one for the occurrences of the XOR primitive, which can amount to a sizable amount of the translation of a model. Our experimental evaluation has confirmed the theoretical gains with an improvement of building times of up to two orders of magnitude for real-life models, which indicates that BDDs have still a lot of untapped potential. We also considered two other primitives, atLeast-n and atMost-n, for which we proved good theoretical properties, but found no real models that used them. An interesting extension would be to use the XOR implementation to simplify the translation of string, int, and hex values in Kconfig files, which suffer from exactly the same problems as described for the choice construction.