The Design Activity

We have seen that both digital and analogue design styles are, in practice, restricted as to what kinds of circuits can be produced. Digital designs must be made of signal-restoring elements regimented into subcircuits of simple dynamics, with constrained moments of communication. Analogue designs are made mostly of standard building blocks, with the rare creation of a completely novel design usually being restricted by design-difficulty to the level of these small subcircuits.

Further practical design constraints arise from the choice of design flow. A design flow starts with high-level design decisions about the gross structuring of the system, and ends with exact details of how it should be implemented. In-between are stages of problem decomposition, and a progression from considering the problem at a highly abstract level, through to reifying the design to the concrete details of implementation. The particulars of a design flow are strongly influenced by the computer-aided design (CAD) tools available for each step, and the ease with which different tools can be integrated.

Design-automation tools are highly developed for digital systems, and far less so for analogue. Rutenbar [28] sees the impediment to analogue design automation as the difficulty of providing a library of `standard cells' adequate to implement an arbitrary user design fully. A standard cell is an implementation building block, completely specifying component details, placement, and routing to achieve a precise function: this is different from the more generic architectural design building blocks mentioned above. We have already indicated that it is inherent in an analogue design process that it is more difficult to abstract function from implementation, than for digital systems.

Evolutionary algorithms have been applied as design-automation tools at various levels of abstraction: Table I gives some examples for a digital design flow. Top-down design of this sort is ubiquitous, and almost indispensable for large systems, but does impose constraints of its own on what circuits can be produced. `Abstraction' implies the suppression of some details; design at an abstract level therefore requires constraint of those neglected details upon progression towards the concrete implementation.

Table I: Some steps in a digital design flow to which EAs have been applied.

Design activity	EA example	Level
Partitioning into hardware and software modules	[29]	Abstract
Design of a network of high-level functions	[30]	$\big\Downarrow$
Function behaviour $\longmapsto$ Net of logic gates	[31]	$\big\Downarrow$
Net of logic gates $\longmapsto$ Choice from a library of physical components	[19]	$\big\Downarrow$
Net of physical components $\longmapsto$ Placed and routed VLSI layout	[32] [33]	Concrete (implementation)

For the current enterprise, we seek to explore design-space as freely as possible, even if in doing so we can only work with relatively small circuits in practice. Once the potential of new territories in design space is ascertained, this knowledge can be fed back into the domain of top-down design, perhaps as additions to the designer's `cookbook' of subcircuit ideas. The variation operators, or the representation of the circuit on which they operate, may be designed to encourage modularity and repeated structures, aiding the evolutionary process in the production of large systems [34,35]. For the present, we apply evolutionary algorithms in a bottom-up fashion, with the EA's variation operators manipulating the structure at the finest level of implementation detail available. Constraints associated with the conventional digital or analogue paradigms are resisted as being prejudicial for evolution. In general, the circuits are continuous-time, continuous-value dynamical systems; digital, analogue, and hybrid circuits are all included in this repertoire of possibilities. No claim is made that more of design space can practically be surveyed (that may or may not be the case), but rather new regions.

Here, there is no distinction between design and implementation: the process of evolutionary design happens at the implementation level. As well as avoiding abstraction constraints, this facilitates the integration of nonbehavioural and behavioural requirements. Many nonbehavioural requirements, such as size or power-consumption, are closely coupled both with general design decisions, and with details of the implementation. In a top-down design flow, implementation details are not fully contemplated during the early -- more abstract -- stages, making design for nonbehavioural requirements problematic. An example of integrating a fault-tolerance (nonbehavioural) requirement with embedded behavioural requirements will be given in §III-C. It is partly the ability to embrace nonbehavioural requirements during all stages of an evolutionary design process, in combination with an exploration of new circuit structures and dynamics, that provides the opportunity for better circuits to arise through evolution (H3).

By diagnosing the constraints of conventional design -- from the analogue and digital design paradigms, and from top-down design flows -- hypothesis H1 is shown. It is also deduced that an evolutionary approach, in principle, can explore some regions in design space that are beyond the scope of conventional methods. This is not sufficient for hypothesis H2: we need to go on to demonstrate an evolutionary algorithm exploring new regions. That is done through a pair of case studies carefully formulated for the purpose, presented in the next two sections. During these case studies, the need to deal with a realistic set of requirements is temporarily neglected. In the final section, ongoing work to address this is described, moving towards hypothesis H3: the practical evolution of robust unconventional electronics.