UP | HOME

# `ltlsynt`

## Table of Contents

- Basic usage
- Input options
- TLSF input
- Output options
- Internal details
- Other useful options
  - Printing games
  - Saving statistics in CSV
  - Verifying the output
- References

## Basic usage

This tool synthesizes reactive controllers from LTL/PSL formulas.

Consider a set \(I\) of input atomic propositions, a set \(O\) of output atomic propositions, and a PSL formula φ over the propositions in \(I \cup O\). A reactive controller realizing φ is a function \(c: (2^{I})^\star \times 2^I \mapsto 2^O\) such that, for every ω-word \((u_i)_{i \in N} \in (2^I)^\omega\) over the input propositions, the word \((u_i \cup c(u_0 \dots u_{i-1}, u_i))_{i \in N}\) satisfies φ.

If a reactive controller exists, then one with finite memory exists. Such controllers are easily represented as automata (or more specifically as Mealy machines). In the automaton representing the controller, the acceptance condition is irrelevant and trivially true.

Here is a small example where \(I=\{i_1,i_2\}\) and \(O=\{o_1\}\). The specification asks that \(o_1\) hold at some point if and only if \(i_1\) and \(i_2\) hold one after the other at some point.

    ltlsynt -f 'F(i1 & Xi2) <-> F(o1)'

    REALIZABLE
    HOA: v1
    States: 2
    Start: 0
    AP: 3 "i1" "o1" "i2"
    acc-name: all
    Acceptance: 0 t
    properties: trans-labels explicit-labels state-acc deterministic
    controllable-AP: 1
    --BODY--
    State: 0
    [!0&!1] 0
    [0&!1] 1
    State: 1
    [!0&!1&!2] 0
    [0&!1&!2] 1
    [1&2] 1
    --END--

The output is composed of two parts:

- The first part is a single line stating `REALIZABLE` or `UNREALIZABLE`; the presence of this line, required by the SyntComp competition, can be disabled with option `--hide-status`.
- The second part, only present in the `REALIZABLE` case, is an automaton describing the controller.

The controller contains the line `controllable-AP: 2`, which means that this automaton should be interpreted as a Mealy machine where `o0` is part of the output. Using the `--dot` option, makes it easier to visualize this machine.

    ltlsynt -f 'F(i1 & Xi2) <-> F(o1)' --hide-status --dot

The following example illustrates the case of an unrealizable specification. As `a` is an input proposition, there is no way to guarantee that it will eventually hold.

    ltlsynt --ins=a -f 'F a'

    UNREALIZABLE

## Input options

`ltlsynt` require two pieces of information two solve a reactive LTL/PSL synthesis problem: an LTL (or PSL) formula, and a partition of its atomic propositions as input and output.

The specification formula can be passed with `-f/--formula` or `-F/--file`. If multiple specifications formulas are passed, they will all be solved individually.

The input/output partition can be given in several ways. If it is not specified, `ltlsynt` assumes that input variables should start with `i`, and output variables should start with `o`.

Options `--ins` and `--outs` should be followed by a comma-separated list of input atomic propositions, or input regexes enclosed in slashes. E.g., `--ins=switch,/^in/,car`. If only one of these options is given, atomic propositions not matched by that option are assumed to belong to the other set.

Another way to specify the input/output partition is using a `*.part` file passed to the `--part-file` option. Such a file is used by several other synthesis tools. The format is space-separated list of words representing atomic-propositions. Two keywords `.inputs` and `.outputs` indicate the set of the atomic-propositions that follow. For instance:

    .inputs request cancel
    .outputs grant ack

Using `--part-file=THEABOVEFILE` is equivalent to `--ins=request,cancel --outs=grant,ack`.

As an extension to this simple `*.part` format, words enclosed in slashes are interpreted as regexes, like for the `--ins` and `--outs` options.

## TLSF input

`ltlsynt` was made with the SYNTCOMP competition in mind, and more specifically the TLSF track of this competition. TLSF is a high-level specification language created for the purpose of this competition. Fortunately, the SYNTCOMP organizers also provide a tool called `syfco` which can translate a TLSF specification to an LTL formula.

The following line shows how a TLSF specification called `FILE` can be synthesized using `syfco` and `ltlsynt`:

    ltlsynt --tlsf FILE

The above `--tlsf` option will call `syfco` (which must be on your `$PATH`) to perform the conversion and extract output signals, as if you had used:

    LTL=$(syfco -f ltlxba -m fully FILE)
    OUT=$(syfco --print-output-signals FILE)
    ltlsynt --formula="$LTL" --outs="$OUT"

## Output options

By default, the controller is output in HOA format, but it can be output as an And-Inverter-Graph in AIGER format using the `--aiger` flag. This is the output format required for the SYNTCOMP competition.

    ltlsynt -f 'F(i1 & Xi2) <-> F(o1)' --aiger

    REALIZABLE
    aag 5 2 1 1 2
    2
    4
    6 11
    8
    8 4 6
    10 3 9
    i0 i1
    i1 i2
    o0 o1

The above format is not very human friendly. Again, by passing both `--aiger` and `--dot`, one can display the And-Inverter-Graph representing the controller:

    ltlsynt -f 'F(i1 & Xi2) <-> F(o1)' --hide-status --aiger --dot

In the above diagram, round nodes represent AND gates. Small black circles represent inversions (or negations), colored triangles are used to represent input signals (at the bottom) and output signals (at the top), and finally rectangles represent latches. A latch is a one bit register that delays the signal by one step. Initially, all latches are assumed to contain `false`, and they emit their value from the `*_out` rectangles at the bottom. Their input value, to be emitted at the next step, is received via the `*_in` boxes at the top. In `ltlsynt`'s encoding, the set of latches is used to keep track of the current state of the Mealy machine.

The generation of a controller can be disabled with the flag `--realizability`. In this case, `ltlsynt`'s output is limited to `REALIZABLE` or `UNREALIZABLE`.

## Internal details

The tool reduces the synthesis problem to a parity game, and solves the parity game using Zielonka's recursive algorithm. The process can be pictured as follows.

LTL decomposition consist in splitting the specification into multiple smaller constraints on disjoint subsets of the output values (as described by Finkbeiner, Geier, and Passing), solve those constraints separately, and then combine them while encoding the AIGER circuit. This is enabled by default, but can be disabled by passing option `--decompose=no`.

The ad hoc construction on the top is just a shortcut for some type of constraints that can be solved directly by converting the constraint into a DBA.

Otherwise, conversion to parity game (represented by the blue zone) is done using one of several algorithms specified by the `--algo` option. The game is then solved, producing a strategy if the game is realizable.

If `ltlsynt` is in `--realizability` mode, the process stops here

In synthesis mode, the strategy is first simplified. How this is done can be fine-tuned with option `--simplify`:

    --simplify=no|bisim|bwoa|sat|bisim-sat|bwoa-sat
                           simplification to apply to the controller (no)
                           nothing, (bisim) bisimulation-based reduction,
                           (bwoa) bisimulation-based reduction with output
                           assignment, (sat) SAT-based minimization,
                           (bisim-sat) SAT after bisim, (bwoa-sat) SAT after
                           bwoa.  Defaults to 'bwoa'.
    --splittype=expl|semisym|fullysym|auto
                           Selects the algorithm to use to transform the
                           automaton into a game graph. Defaults to 'auto'.

Finally, the strategy is encoded into AIGER. The `--aiger` option can take an argument to specify a type of encoding to use: by default it is `ite` for if-then-else, because it follows the structure of BDD used to encode the conditions in the strategy. An alternative encoding is `isop` where condition are first put into irredundant-sum-of-product, or `both` if both encodings should be tried. Additionally, these optiosn can accept the suffix `+ud` (use dual) to attempt to encode each condition and its negation and keep the smallest one, `+dc` (don't care) to take advantage of don't care values in the output, and one of `+sub0`, `+sub1`, or `+sub2` to test various grouping of variables in the encoding. Multiple encodings can be tried by separating them using commas. For instance `--aiger=isop,isop+dc,isop+ud` will try three different encodings.

## Other useful options

### Printing games

You can also ask `ltlsynt` to print to obtained parity game into PGSolver format, with the flag `--print-pg`, or in the HOA format, using `--print-game-hoa`. These flags deactivate the resolution of the parity game. Note that if any of those flag is used with `--dot`, the game will be printed in the Dot format instead:

    ltlsynt -f '(i1 & i2) <-> F(o1 & X(!o1))' --print-game-hoa --dot

### Saving statistics in CSV

For benchmarking purpose, the `--csv` option can be used to record intermediate statistics about the resolution.

For instance the following command builds controllers (when they exist) for the 23 demonstration specifications from Lily 1.0.2 while saving some statistics in `bench.csv`. (If you compare our results with theirs, keep in mind that Lily uses Moore's semantics, while `ltlsynt` uses Mealy's semantics.) We use `-q` to hide the constructed controllers, as we are only interested in the statistics.

    genltl --lily-patterns | ltlsynt --algo=acd --aiger -q --csv=bench.csv

After execution, `bench.csv` contains a table like the following:

source | subspecs | algo | split | total_time | sum_trans_time | sum_split_time | sum_todpa_time | sum_solve_time | sum_strat2aut_time | aig_time | realizable | max_trans_states | max_trans_edges | max_trans_colors | max_trans_ap | max_game_states | max_game_colors | max_strat_states | max_strat_edges | sum_strat_states | sum_strat_edges | max_simpl_strat_states | max_simpl_strat_edges | sum_simpl_strat_states | sum_simpl_strat_edges | aig_latches | aig_gates
--- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---
-:1 | 2 | acd | auto | 0.000320991 | 0.000129116 | 1.6671e-05 | 1.8534e-05 | 1.1738e-05 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 3 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
-:2 | 2 | acd | auto | 0.000353622 | 0.000229783 | 1.4917e-05 | 1.8634e-05 | 6.499e-06 | 9.597e-06 | 0 | 0 | 5 | 8 | 0 | 1 | 10 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 0 | 0
-:3 | 1 | acd | auto | 0.00125981 | 0.000984204 | 3.8433e-05 | 1.7435e-05 | 1.5131e-05 | 8.357e-06 | 5.1179e-05 | 1 | 12 | 46 | 1 | 3 | 26 | 1 | 5 | 5 | 5 | 5 | 2 | 2 | 2 | 2 | 1 | 0
-:4 | 1 | acd | auto | 0.00123126 | 0.000908726 | 6.4512e-05 | 2.0261e-05 | 1.4524e-05 | 9.313e-06 | 5.918e-05 | 1 | 15 | 62 | 1 | 3 | 33 | 1 | 6 | 6 | 6 | 6 | 3 | 3 | 3 | 3 | 2 | 8
-:5 | 1 | acd | auto | 0.000891092 | 0.000505694 | 6.1232e-05 | 2.2561e-05 | 1.6638e-05 | 1.9591e-05 | 0.000132405 | 1 | 20 | 88 | 1 | 3 | 47 | 1 | 8 | 9 | 8 | 9 | 6 | 7 | 6 | 7 | 3 | 46
-:6 | 1 | acd | auto | 0.000933909 | 0.000464414 | 6.9769e-05 | 4.3845e-05 | 2.0212e-05 | 2.3922e-05 | 0.000126763 | 1 | 24 | 111 | 1 | 3 | 55 | 1 | 11 | 12 | 11 | 12 | 7 | 9 | 7 | 9 | 3 | 46
-:7 | 1 | acd | auto | 0.000675931 | 0.000374554 | 3.8341e-05 | 1.5119e-05 | 1.2263e-05 | 8.817e-06 | 9.2388e-05 | 1 | 11 | 38 | 1 | 3 | 26 | 1 | 7 | 8 | 7 | 8 | 6 | 7 | 6 | 7 | 3 | 34
-:8 | 1 | acd | auto | 3.4274e-05 | 2.386e-06 | 0 | 0 | 0 | 0 | 1.1427e-05 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0
-:9 | 1 | acd | auto | 0.000560809 | 0.000351975 | 3.9723e-05 | 3.4505e-05 | 1.5317e-05 | 7.919e-06 | 2.4143e-05 | 1 | 6 | 19 | 2 | 2 | 16 | 2 | 2 | 3 | 2 | 3 | 2 | 3 | 2 | 3 | 1 | 1
-:10 | 1 | acd | auto | 4.4259e-05 | 1.491e-06 | 0 | 0 | 0 | 0 | 1.6081e-05 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0
-:11 | 1 | acd | auto | 5.842e-05 | 1.5936e-05 | 4.451e-06 | 3.469e-06 | 3.709e-06 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 3 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
-:12 | 1 | acd | auto | 4.8399e-05 | 1.642e-06 | 0 | 0 | 0 | 0 | 2.4458e-05 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0
-:13 | 1 | acd | auto | 0.000219513 | 0.000124616 | 9.721e-06 | 7.674e-06 | 4.58e-06 | 4.954e-06 | 2.3556e-05 | 1 | 2 | 3 | 1 | 2 | 5 | 1 | 2 | 2 | 2 | 2 | 1 | 2 | 1 | 2 | 0 | 0
-:14 | 1 | acd | auto | 0.000290299 | 0.00018355 | 9.95e-06 | 1.2376e-05 | 5.379e-06 | 4.221e-06 | 1.7885e-05 | 1 | 1 | 3 | 2 | 2 | 4 | 1 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 1 | 0
-:15 | 1 | acd | auto | 0.000861834 | 0.000481313 | 5.5281e-05 | 2.912e-05 | 1.4934e-05 | 1.0337e-05 | 0.000140533 | 1 | 8 | 40 | 2 | 4 | 30 | 1 | 7 | 12 | 7 | 12 | 5 | 10 | 5 | 10 | 3 | 38
-:16 | 1 | acd | auto | 0.00300404 | 0.00146546 | 0.000415902 | 9.9481e-05 | 0.00010336 | 4.8806e-05 | 0.000544158 | 1 | 22 | 225 | 3 | 6 | 103 | 1 | 22 | 40 | 22 | 40 | 17 | 36 | 17 | 36 | 5 | 326
-:17 | 1 | acd | auto | 0.000410485 | 0.000264114 | 1.2253e-05 | 1.4345e-05 | 5.644e-06 | 4.69e-06 | 2.7107e-05 | 1 | 1 | 4 | 3 | 3 | 6 | 1 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 2 | 3
-:18 | 1 | acd | auto | 0.000567955 | 0.000395818 | 1.585e-05 | 1.6624e-05 | 5.882e-06 | 5.098e-06 | 3.3982e-05 | 1 | 1 | 5 | 4 | 4 | 8 | 1 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 2 | 5
-:19 | 1 | acd | auto | 0.000408608 | 0.000264854 | 2.1314e-05 | 2.5679e-05 | 1.0258e-05 | 4.904e-06 | 1.6295e-05 | 1 | 4 | 15 | 2 | 3 | 11 | 2 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0
-:20 | 1 | acd | auto | 0.0103053 | 0.00754481 | 0.00167321 | 0.000570732 | 0.000251017 | 1.3702e-05 | 6.9975e-05 | 1 | 311 | 3488 | 2 | 5 | 1002 | 2 | 10 | 10 | 10 | 10 | 6 | 8 | 6 | 8 | 3 | 30
-:21 | 1 | acd | auto | 0.063367 | 0.0583399 | 0.000922163 | 8.0125e-05 | 0.000116328 | 0.000119106 | 0.00221522 | 1 | 75 | 546 | 1 | 8 | 371 | 1 | 74 | 228 | 74 | 228 | 71 | 213 | 71 | 213 | 7 | 1299
-:22 | 1 | acd | auto | 0.00194138 | 0.00102867 | 0.000142 | 5.0546e-05 | 4.6196e-05 | 2.6233e-05 | 0.00030442 | 1 | 30 | 161 | 2 | 4 | 86 | 1 | 22 | 25 | 22 | 25 | 15 | 19 | 15 | 19 | 4 | 194
-:23 | 1 | acd | auto | 0.000453103 | 0.000290944 | 1.5142e-05 | 1.4568e-05 | 9.288e-06 | 7.394e-06 | 3.5057e-05 | 1 | 7 | 16 | 1 | 2 | 17 | 1 | 5 | 6 | 5 | 6 | 3 | 4 | 3 | 4 | 2 | 10

The subset of columns output is adjusted according to the task performed by `ltlsynt`. For instance with `--realizability`, the CSV file will not include statistics about the winning strategies or the AIG circuits. When reading a game with `--from-pgame`, columns giving statistics about LTL translation will be omitted.

The names of the columns should be mostly self explanatory. The decomposition of the specification into multiple sub-specifications makes it slightly incoveniant to track statistics in a run. The column `subspecs` indicates how many sub-specifications were found in the original specification. Columns with names of the form `sum_*` accumulate their statistics over all subspecifications. Columns with names of the form `max_*` keep only the largest statistics. The following statistics are gathered:

- `source`: location of the specification in the form FILENAME:LINE (FILENAME is `-` when reading from standard input as in the above example).
- `formula` (if requested with option `--csv-with-formula`): is the actual LTL formula used for the specification, is usually makes the CSV file very large
- `subspecs`: the number of sub-specifications resulting from the decomposition
- `algo`: the name of the approach used to construct game, as specified with the `--algo` option
- `split`: the name of the approach used to split the automaton into input and output steps, as specified with the `--split` option
- `total_time`: total time measured by `ltlsynt` to solve the problem once the problem has been loaded (parsing of the formula, conversion from TSLF, or parsing of a parity game are all excluded)
- `sum_trans_time`: sum of the translation time used to obtain an automaton from each subspecification.
- `sum_split_time`: sum of the times used to split the automata
- `sum_todpa_time`: sum of the times used to paritize the automata
- `sum_solve_time`: sum of the times used to solve the game for each subspecification
- `sum_strat2aut_time`: sum of the time needed to extract the strategies
- `aig_time`: time used to encode all strategies into one AIG circuit
- `realizable`: whether the specification is realizable
- `max_trans_states,max_trans_edges,max_trans_colors,max_trans_ap`: Size of the largest automaton constructed for a subspecification. The largest size is actually the largest quadruple of the form (states,edges,colors,ap), so those maximum values are not independent.
- `max_game_states`: maximum number of state in any game constructed
- `max_game_colors`: maximum numbers of colors in any game constructed (might not be the same game as for `max_game_states`)
- `max_strat_states,max_strat_edges`: size of the largest strategy found. The largest size is the largest pair (states,edges), so those two values are not indeendent.
- `sum_strat_states,sum_strat_edges`: sum of the states/edges in strategies for all subspecifications
- `max_simpl_strat_states,max_simpl_strat_edges`: size of the largest simplified strategy.
- `sum_simpl_strat_states,sum_simpl_strat_edges`: sum of the states/edges in simplified strategies for all subspecifications
- `aig_gates,aig_latches`: Size of the AIG circuit, if requested.

In this example table, some of the intermediate processing times are listed as `0` (e.g., for input 8, 10, 12) because the specifications can be found to be realizable trivially without building any game.

### Verifying the output

The `--verify` option requests that the produced strategy or aiger circuit are compatible with the specification. This is done by ensuring that they do not intersect the negation of the specification.

## References

The initial reduction from LTL to parity game is described in the following paper:

- Reactive Synthesis from LTL Specification with Spot, Thibaud Michaud, Maximilien Colange. Presented in SYNT@CAV'18. (pdf | bib)

Further improvements are described in the following paper:

- Improvements to `ltlsynt`, Florian Renkin, Philipp Schlehuber, Alexandre Duret-Lutz, and Adrien Pommellet. Presented at the SYNT'21 workshop. (pdf | bib)

Simplification of Mealy machines is discussed in the following papers:

- Effective reductions of Mealy machines, Florian Renkin, Philipp Schlehuber-Caissier, Alexandre Duret-Lutz, and Adrien Pommellet. Presented at FORTE'22. (pdf | bib)
- The Mealy-machine reduction functions of Spot, Florian Renkin, Philipp Schlehuber-Caissier, Alexandre Duret-Lutz, and Adrien Pommellet. Science of Computer Programming, 230(102995), August 2023. (bib | pdf)

A more recent paper covering many aspects of `ltlsynt` is the following

- Dissecting ltlsynt, Florian Renkin, Philipp Schlehuber-Caissier, Alexandre Duret-Lutz, and Adrien Pommellet. In Formal Methods in System Design, 2023. (bib | pdf)