Programming cells: towards an automated 'Genetic Compiler'

Abstract

One of the visions of synthetic biology is to be able to program cells using a language that is similar to that used to program computers or robotics. For large genetic programs, keeping track of the DNA on the level of nucleotides becomes tedious and error prone, requiring a new generation of computer-aided design (CAD) software. To push the size of projects, it is important to abstract the designer from the process of part selection and optimization. The vision is to specify genetic programs in a higher-level language, which a genetic compiler could automatically convert into a DNA sequence. Steps towards this goal include: defining the semantics of the higher-level language, algorithms to select and assemble parts, and biophysical methods to link DNA sequence to function. These will be coupled to graphic design interfaces and simulation packages to aid in the prediction of program dynamics, optimize genes, and scan projects for errors.

Figure 1. The compiler is focused on assembling the circuitry that links the inputs and outputs of a larger project

The inputs include genetic sensors that can respond to diverse signals, such as temperature, light, stress, or metabolites. The circuitry encodes the logic and dynamics. The output of the circuits control actuators, such as a metabolic pathway, the activation of cell-cell communication, or a stress response. The inputs and outputs tend to be problem-specific and the diversity of biological applications makes this difficult to encompass in a single simulation package. In contrast the circuitry can be reconfigured to build programs relevant to diverse problems in biotechnology.

Figure 2. A Genetic Compiler

The compiler automatically converts a higher-level language to a DNA sequence. Ideally, the designer would be completely blind to these steps (gray box). Simulations aid the debugging of the program, but the debugging would occur within the higher-level language.

Figure 3. Semantics of genetic programs

The plasmid map (A) and Eugene code (B) for a genetic oscillator [94] is shown (B). The author of the Eugene code is Adam Liu [41].

Figure 4. Automated program design using logic minimization algorithms

An example of a multi-input single-output truth table is shown. The truth table is converted to an equation F, which is a function of the four inputs (a,b,c,d). Each term corresponds to each row of the truth table where the output is 1 and the prime (′) is shorthand for the NOT function. Logic minimization algorithms, such as ESPRESSO [49], can be used to simplify the full equation to its minimal form (simplest sum of products). This equation is then converted to circuit diagrams using programs such as Logic Friday [51], which can also implement constraints. For example, the large wiring diagram consists of only 2-input NOR gates (top), whereas the smaller wiring diagram was built allowing for multiple-input OR/NOR/AND/NAND gates. Biological constraints, such as gate availability and DNA size can then be applied to search for the optimal diagram.

Figure 5. Connecting genetic circuits

(A) A simple program is shown consisting of a sensor and circuit. The sensor turns on a promoter in response to an INPUT. A RBS controls a translation initiation rate S that then serves as an input to the circuit. The circuit consists of an activator that turns on a promoter that serves as the output. (B) If the transfer function of the sensor is too low (blue) or the basal level is too high (black), then it will not cross the dynamic range to turn on the circuit (dotted lines). When the sensor output crosses that which is required to trigger the circuit, then the program is functional (red). (C) Experimental data is shown where the RBS is modified in the connection of a sensor to an AND gate. The solid line is the predicted fitness curve derived from the transfer functions of the sensor and circuit measured in isolation of the program.