86
7 Designing Application-Specific Architectures
7.2 Motivation and Notation for Application-Specific
Architectures
In order to overcome the problems of the architectures considered thus far, this
chapter proposes the design of application-specific architectures for a given set
of experiments. These application-specific architectures not only have to support
the execution of all desired experiments but also have to consider further physical
constraints, which are predetermined by the technology. For example, bifurcations
restrict the number of successor channels to two. Moreover, the architecture may
not contain cycles since they would lead to undesired flow conditions. Besides these
physical constraints, further design objectives such as the number of modules and
channels exist (these objectives are discussed in more detail later in Sect. 7.3).
In order to realize an application-specific architecture, which implements a set
of experiments in as less as possible steps and without the need of re-injecting the
payload droplet at the MPU, multiple instances of modules may be applied. This is
discussed by the following example.
Example 7.2 Figure 7.1b shows an application-specific architecture, which is
supposed to realize the same experiments as considered in Example 7.1. The
graphical notation is the same as for ring architectures. In case a module has
multiple incoming edges, the corresponding channels merge into a single input
channel of the module. Furthermore, a module can have at most two successor
edges, which can be physically implemented by a bifurcation of the outgoing channel
of the module.
Although this architecture includes multiple (but still limited) instances of modules realizing the same operation (for d and m, two instances each exist), it allows
for conducting each experiment in four steps only (which is the minimal number of
steps). Moreover, the MPU never has to re-inject a payload droplet because each
of the experiments is completed when the payload flows back to the MPU. When
executing all experiments, φ 1 , φ 2 , and φ 3 , overall this architecture requires 12 steps
only and no payload re-injection (in contrast to the ring architecture which requires
overall 26 steps and two payload re-injections).
The remainder of this section introduces the notion used to describe architectures
and states the underlying design problem. Based on that, this chapter focuses on
how to generate an optimized architecture for a given set of experiments as well as
constraints and objectives from the designer.
An architecture has to be generated which realizes a set of experiments given
by . Each experiment is accomplished by driving a droplet through a sequence of
operations from a set O [23, 24].
Definition 7.1 Let := {φ 1 , φ 2 , . . .} be the set of experiments to be realized.
Further, let O := {m, s, f, d, h, . . .} be the set of operations used in the experiments
. Then, an experiment φ ∈ is a sequence of operations with φ ∈ O n , where
n ∈ N is a natural number defining the number of operations in the experiment.
7 Designing Application-Specific Architectures
7.2 Motivation and Notation for Application-Specific
Architectures
In order to overcome the problems of the architectures considered thus far, this
chapter proposes the design of application-specific architectures for a given set
of experiments. These application-specific architectures not only have to support
the execution of all desired experiments but also have to consider further physical
constraints, which are predetermined by the technology. For example, bifurcations
restrict the number of successor channels to two. Moreover, the architecture may
not contain cycles since they would lead to undesired flow conditions. Besides these
physical constraints, further design objectives such as the number of modules and
channels exist (these objectives are discussed in more detail later in Sect. 7.3).
In order to realize an application-specific architecture, which implements a set
of experiments in as less as possible steps and without the need of re-injecting the
payload droplet at the MPU, multiple instances of modules may be applied. This is
discussed by the following example.
Example 7.2 Figure 7.1b shows an application-specific architecture, which is
supposed to realize the same experiments as considered in Example 7.1. The
graphical notation is the same as for ring architectures. In case a module has
multiple incoming edges, the corresponding channels merge into a single input
channel of the module. Furthermore, a module can have at most two successor
edges, which can be physically implemented by a bifurcation of the outgoing channel
of the module.
Although this architecture includes multiple (but still limited) instances of modules realizing the same operation (for d and m, two instances each exist), it allows
for conducting each experiment in four steps only (which is the minimal number of
steps). Moreover, the MPU never has to re-inject a payload droplet because each
of the experiments is completed when the payload flows back to the MPU. When
executing all experiments, φ 1 , φ 2 , and φ 3 , overall this architecture requires 12 steps
only and no payload re-injection (in contrast to the ring architecture which requires
overall 26 steps and two payload re-injections).
The remainder of this section introduces the notion used to describe architectures
and states the underlying design problem. Based on that, this chapter focuses on
how to generate an optimized architecture for a given set of experiments as well as
constraints and objectives from the designer.
An architecture has to be generated which realizes a set of experiments given
by . Each experiment is accomplished by driving a droplet through a sequence of
operations from a set O [23, 24].
Definition 7.1 Let := {φ 1 , φ 2 , . . .} be the set of experiments to be realized.
Further, let O := {m, s, f, d, h, . . .} be the set of operations used in the experiments
. Then, an experiment φ ∈ is a sequence of operations with φ ∈ O n , where
n ∈ N is a natural number defining the number of operations in the experiment.