adaptive and evolvable hardware

1 Stoica: Adaptive and Evolvable Hardware

JPL Co-PIs:Didier Keymeulen and Ricardo Zebulum

Adrian StoicaNASA Jet Propulsion Laboratory California Institute of Technology

Adaptive and Evolvable Hardware

[email protected]

11/28/2006DSRC Workshop on Adaptive Electronics


Outline

Vision, motivation Adaptive hardware characteristics Limitations Evolvable hardware Open problems Possible paths


Vision for adaptive, intelligent devices

Deploy 1 a miniature 2 device in an unknown environment 3.

Provide a high-level specification of intended function 4.

The device adapts itself to provide the function intelligentlyThe device adapts itself to provide the function intelligently55..

1 (drop, plug-in, etc); 2 (finger-nail size?); 3 (enemy field, remote planet, unknown computer);

4 (operation, mission); 5 (/optimally select/determine algorithms, protocols, resources to use, etc).

Adaptation

Environments

Mismatches in fabrication

Faults

New functionsNew users

Provide the function that is needed, when is neededProvide the function that is needed, when is needed

Vision, motivation


Real-world needs for adaptive HW

• Adaptive computing - problem/algorithm dependent efficient resource utilization (efficient algorithmic mapping, maximal speed, minimal power)

• Adaptive signal processing - optimization/improvements of adaptive compression, compressive sampling,

• Adaptive communications - optimizing bandwidth, avoiding jamming/EW, etc,

• Fault-tolerant computing - dealing with low reliability, imprecise/imperfect components, natural/terrorist induced catastrophes (EMG pulse, radiation) taking over functions from other resources that were damaged

Vision, motivation


Automatic in-situ synthesis of a totally new hardware configuration is needed:

• Dramatic changes in hardware/environment (e.g. from radiation and extreme temperatures), or• Need for new functions (e.g. in case of opportunistic science or mission changes)

NASA Motivation:Surviving longer missions (100+ years) and harsher environments

Survive,

Adapt,

Evolve

Environments

Faults/degradation

New roles

Aging

Causes of internal/external changes:

Vision, motivation


What kind of adaptation we want

• Continuous, no system down time/interrupts for adaptation

• Timely, as fast as needed, rapid reaction• Harmonious, correlated at different levels of system

hierarchy• User- Friendly in setting new adaptation objectives• Lean, with minimal overhead for adaptation

Vision, motivation


Adaptive and evolvable hardware

• In a restricted sense it means modifying its behavior under the control of an evolutionary algorithm

word ‘evolution’ indicates progress

Adaptive hardware characteristics

Adaptive hardware: hardware able to change itself (self-reconfigure) in order to optimize its behavior in response to an internal objective and external environment

Evolvable hardware – a special case of adaptive hardware mainly driven by internal objectives; performance consistently improves in time

word ‘evolution’ indicates technique


Characteristics of Adaptive Hardware

1. Hardware can change – reconfigurable HW (RH)

2. Has a decision-maker/controller that changes the hardware – reconfiguration algorithm (RA)

3. An objective function that guides the change; this could be built-in, passed-on by other hardware components, or by user



AutoAutoRe-custom.Re-custom.

Making hardware that can change: Industry has provided for increased post-

manufacturing customization

Dynamic Re-custom.

TriggeredRe-custom.

In-Situ Re-custom.

Field Custom.Lab. Custom.

Post-Manufacturing CustomizationPre-Manufacturing Customization

Man

ufa

ctu

rin

g

Re-custom.

Adapted after Plura-Tech presentation by Radu Andrei, AHS 2006

• In response to user needs • Rapid development• Upgrades to cope with standards/fixes

• As a solution to mitigate technology limitations• Manufacturing imperfections at lower feature size



Limitations of current reconfigurable devices

• No HW Decision-maker: Only SW implementations for for system-level adaptation

• Where hardware changes under SW control:– Simple objective functions– Time/resource consuming to reprogram the chip

• research in dynamic reconfiguration, partial reconfiguration, context switching

• Extreme overheads on current reconfigurable devices!

Limitations


Hardware changes – research devices

• Reconfigurable –configurations can be changed, by mapping a different topology (digital control)– switch based architecture (not always, e.g. reconfigurable robots)– functional change (not always, e.g. self-repair)– often by resource reuse

• Morphable – functional change without switches, by analog control, more gradual/continuous

• Adjustable/Tunable/Parametric –changes the parameters of a function

Changes in reconfigurable architectures - function in Configurable Blocks (CB)

– Digital or Analog Building block• Logic function • Transistor, OpAmp, dedicated circuits (filters, analog multipliers) • Heterogeneous Arrays

- interconnect between CBs: - On/off switches; also switched capacitors.

Programmable: that can be programmed/changed, e.g. Field Programmable Arrays

Evolvable Hardware


Hardware that changes – Examples of JPL Reconfigurable Analog Arrays

Field Programmable Analog Array

Self-Reconfigurable Analog Array

Anadigm JPL

Field programmable, switches

Field-programmable, switches, built-in algorithms

Under external control

Under internal control (self)

-40C to 85C -180 to 125C

No rad-tolerance Rad-hard

S7P1

S4

S1

P2

V+

S12

S5

P4

S14

S15

S22

N6

N8S24

S23N7

S20

N5S11

S18

S17

S6S9

S8

S2

S3P3

S13

S10

S16

S19S21

V-

FTPA-0 cell

N

E W

S

FTPA-2 cellFTPA cellular architecture

Evolvable Hardware


Implementing reconfiguration algorithms

• Model-based: • Memory-based: predetermined contexts stored in memory

configurations that correspond to various contexts;

• Calculate an (analytic) solution

• Search-based, HW in the loop: • Gradient-based search/optimization guides reconfiguration to

increasingly better performance;

• Population-based search (e.g. using evolutionary algorithms)- if there is no predetermination and no simple change algorithm

• Limitations: – it is computationally intensive– may go through states which are actually worse that where it was

started and can potentially harm the system if control is maintained from the reconfigurable analog area.

Evolvable Hardware


Evolutionary Algorithm Search on a population of chromosomes •select the best designs from a population• reproduce with variation• iterate till goal is reached

Evaluate responses, assess fitness

Targetresponseor quality metrics

Chromosomes101100110101110101101101101101

Control bitstrings

Conversion to a circuit description

Circuit response

Reconfigurable hardware

Monitor response. If not good, change/tune. Repeat

Evolution-based reconfiguration

Evolvable Hardware


Example of evolvable hardware in parametric correction (calibration/compensation) of OTA-based circuit functionality:

OUTAlgorithm determines correction needed

0 1 0 0 1 1 0 1 0 0 1

Configuration Bits

Gm 1

iB1

Gm 4

Gm2Gm3

IN

0 1 0 0 1 1 0 1 0 0 1 Register

Download

iB4

iB2

iB3

Calibration

Higuchi, (Japan) used this compensation circuit to improve yieldJPL used to a similar scheme to compensate for temperature

( Gm : Transconductance Amplifier )

Evolvable Hardware


Self-Reconfigurable Analog ArraysSRAA are reconfigurable analog arrays that are configured by

reconfiguration algorithms (mapped in digital circuits), which– detect circuit performance degradations due to faults/drifts caused by

temperature and radiation – compensate for those by changing to another, more appropriate

configuration, pre-determined or computed in-situ.

Digital part (more robust) provides correction controls for analog (more sensitive)

Reconfiguration Algorithm(digital)

Reconfigurable Analog Array

Self-reconfigurable analog array

Evolvable Hardware


Reconfigurable Analog Array (RAA) programming

• Correct drifts/deviations:• Evaluate deviation from specifications• Determine algorithmic correction • Apply it by changing:

• configuration (change of circuit topology)• programmable compensation (e.g. programmable current bias)

Configuration changeIn array of cells

Parameter change

Gcab

V1

V2

Vout

cell

Evolvable Hardware


0.5 1 1.5 2 2.5 3

0.0003

0.0002

0.0001

0.0001

0.0002

0.0003

0.0004

Iout

(A

)

22C

OTA drift at low temperature is recovered by change in bias voltage

Vdd:3.1V, V1:1.5V, V2:0-3.0V, V(Iout):2V

Vb: 1.0V

Vb: 0.9V

Vb: 0.5-0.75V

-180C

22C, Vb: 0.8V

Vb: 0.95V

Vb: 0.85V

-180C, Vb: 0.8V

0.5 1 1.5 2 2.5 3

0.0001

0.00005

0.00005

0.0001

0.00015

Iout

(A

)

22C0C

-30C-60C-90C

-120C-150C-180C

V1 V2

Vbias

Iout

Vbias:0.8V

OTA Sweep

Iout(u

A)0 0.5 1 1.5 2 2.5 3

-160

-120

-80

-40

0

40

80

120

160

200

240 25C/0.8V

-180C/0.85V

Increase Vbias from 0.8to 0.85V recovers curve atRoom temperature

Evolvable Hardware


Demonstrated Temperature Compensation by Reconfiguration/Tuning

• Entire system digital and analog demonstrated to survive from -180C to 120C

at 22C degraded -180C recovered -180C

Input

OutputDegraded

outputPartial

recovery

-15

-10

-5

0

5

10

15

20

1.00E+01 1.00E+02 1.00E+03 1.00E+04 1.00E+05 1.00E+06

Frequency (Hz)

Ga

in (

dB

)

Room Temperature

Degraded at -180C

Recovered at -180C

Thermal testing stationDegraded output and recovery

Evolvable Hardware


Movie 2


System-level block diagrams SRAA

MonitorMonitor BlockBlock

ModelModelBasedBasedComp.Comp.(SRAM)(SRAM)Glue LogicGlue Logic

Analog ASIC

Test Fixture

RACArray

FAC ArraySwitchBox (SB) Array

and Configuration Logic

Digital ASIC

Genetic Algorithm Engine (GA)

Memory Module

Main ControllerModule

User GA parameters

System Monitoring

Module

Fitness EvaluationModule 2 (FEM2)

Digital Control2(DC2)

Digital Control1(DC1)

FPGA

Fitness EvaluationModule 1 (FEM1)

GA/GD

Model-based Compensation Module

Current Temperature

• Honeywell SOI-5 SRAA-2 and Digital ASIC

In1

2In2Out

In1

1In2Out

In1

4In2Out

In1

3In2OutQuad

OpAmp

In1

6In2Out

In1

5In2Out

In1

8In2Out

In1

7In2OutHV

OpAmp

In1

10In2Out

In1

9In2Out

In1

12In2Out

In1

11In2OutPing-pong

OpAmp

In1

14In2Out

In1

13In2Out

In1

16In2Out

In1

15In2OutHigh Speed

Comparator

17Iout

CurrentSource 18

Iout19

Iout

20Iout

In1

22In2Out

In1

21In2Out

In1

24In2Out

In1

23In2OutComp2

Evolvable Hardware


Lessons Learned - RH

• Characteristics needed by evolvable devices:– Can be reconfigured many times– All configurations are safe for the device (No configuration that

harms the device can be programmed)– Repeatability: Similar behavior every time for same configuration

• Commercial devices have been used only moderately but there is an increasing trend for their use.– Advantages:

• Available and affordable• Complex enough to do real world applications easily

– Disadvantages:• Better ones (easier to program, direct access to lowest levels, possibly protected by company secrets, development kits, SDKs) would be useful• Somehow complex to program to do a full application

Evolvable Hardware


Lessons Learned - RA

• All (almost all) evolutionary techniques work on simple problems, efficiency depends on the problem

• None was demonstrated on really difficult problems

• EAs require to many iterations for really complex problems (the main time is usually spent in evaluating the RH in each iteration) so are slow

• Not only they are slow but may go through undesirable states if RH is used in direct loop to control a real system

• Use of domain knowledge helps

• But many real world problems – require application specific designs, but the search problems themselves may not always be hard

Evolvable Hardware


Challenges related to reconfiguration mechanisms and evolution

1. Scalability – without hierarchy – divide and conquer works but can we determine fitness for subproblems automatically – automatic hierarchical partitioning without a library of building blocks of various granularity

2. On-line evolution: Going through undesirable states – ping pong architectures

3. Reduce system overhead, e.g. for fitness evaluation/ reconfiguration

4. Integration in accepted design (…) flows.

5. Means to specify an evolvable system component at system level, behavioral models

Open Problems

–Solution is guarantied only where tested


Challenges related to reconfigurable hardware

• Current overhead and cost for building more flexible devices goes up• DoD needs a solution that is economically attractive for the industry – overhead must go down

• One needs to tale customization of a system to a lower level– System block level customization

– Hardware block level customization

– Transistor level customization

– ………Task

Funct. 1

Funct. 2

Funct. n

Funct. 1.1

Funct. 1.2

Funct. 1.n

Funct. 1.1.1

Funct. 1.1.2

Funct. 1.1.n

System Block (SW/HW)

Hardware Block (HW/FW)

Manufacturing Layers

Transistor (HW)

Open Problems


Objective: higher efficiency of adaptability

FPGA-level Adaptability

Number of building blocks

Inef

ficie

ncy

leve

l (lo

gar

ithm

ic

scal

e)

building block inefficiency (500-600%)

customization

inefficiency

Transistor-level Adaptability

Number of building blocks

building block inefficiency (~10%)

Inef

ficie

ncy

leve

l (lo

gar

ithm

ic

scal

e)customization inefficiency (~10%)

• FPGA-level adaptability– Building blocks use a number of basic elements

(transistors)• Creates a 500-600% overhead

– Heterogeneous structure (building blocks have pre-determined functions)

• Topological inflexible structure (building block position determined before manufacturing)

• Utilization rate decreases exponentially with the number of building blocks

• Can be marginally improved through topological rearrangement of building blocks

• Transistor-level adaptability– Building blocks use one single basic element

(transistor) • Overhead should be not bigger than 10%

– Homogeneous structure (building block functionality is programmable after manufacturing)

• Utilization rate can theoretically stay at full level, regardless of number of building blocks

Possible paths


Reducing flexibility/adaptability overheads - classical DARPA-hard problems

• Flexibility/configuration overhead – From current over 5-10x penalty (area)

• To 0.1x for flexible devices (100 times)

• + ~ 0.1x for self-configuration/adaptation

• Transistor-level or below

• Self-reconfiguration overhead – From current computing of reconfiguration solution in minutes

• To ms and below (1000x)

• Distributed architecture

• No A/D and D/A for monitoring signal changes

Possible paths


Diffusing intelligence to fine HW levels in Intelligent Integrated Microsystems (I2M)

• Embedded intelligence is needed to use flexibility – and achieve adaptation/evolution

• It empowers the HW, making use of HW flexibility (e.g. configurability, at various levels of reconfigurable hardware) to obtain more performance than what is possible with software-only solutions.

Fine HW levels, flexible, configurable

Algorithms/built-in mechanisms for optimization (adaptation/evolution)

•Within/between •Types of HW: electronics, MEMS/BioMEMS, Optical, Antennas• Modules in info processing chain: sensing, pre-processing, ADC, compression, etc.• Levels of granularity: function block, gate, transistor, below transistor

Final remarks


Additional slides


Evolution on SABLES

• Evolution of a Half-wave rectifier circuit: Excitation input of 2kHz sine wave of amplitude 2V– 9% elite percentage, 70% crossover, 4% mutation; 100

individuals population;– 20 seconds experiments

• Stimulus-Response wave form during the evaluation of a population in one generation (left) and for 3 individuals in the population (right)

Evolution Cycle

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 0.005 0.01 0.015 0.02

Time [sec]

Vo

lts

Input (offset by 2V) Output

Generate New Population


Half-wave rectifier convergence

a) b)

c) d)

• Results of the evolution of a halfwave rectifier during and after evolution are shown

• 100 individuals are evaluated (elite 9% set aside, 70% rate for crossover, 4% for mutation) on two cells

A B

C D

Best individuals of generations #1, 5, 50 & 82 (A - D respectively)

Input (2kHz) and solution at generation 82


Frequency Specifications for the IF filter: tuning

420 430 440 450 460 470 480 490

Frequency (kHz)

0

-10

-20

-30

-40

-50

-60

-70

Gai

n (

dB)

0

-4

-8

-12

-16

-20G

ain

(dB

)

440 445 450 455 460 465 470Frequency (kHz)

Spec. ( -3dB Points)

Ideal ResponseIdeal Response

From presentation by T. Higuchi, Japan, at EH-2003


Self-Reconfigurable Electronics in Extreme EnvironmentsDigital System – A High Level View

RAC = Reference Analog CellFAC = Functional Analog Cell

Two Compensation Modes Model Look-Up Table based compensation

Implementation of a pre-characterized correction voltages for each RAC

Genetic Algorithm based compensationImplements an evolutionary approach to

find the best set of Vbias values (initial population is random)

Find best set ofbias voltages (Vbest)

Select Next RAC

Excite & Evaluate

Satisfactory?Yes

No

Apply Vbest to FACs

Initialize

Monitor

Compensate

DigitalASIC

Reconfigurable AnalogArray(RAA)

Digital ASIC FunctionalityContinuous Monitoring of Analog Function


System-level integration- board-level SRAA

RAA IC

FPGAVII Pro

PCFor experiment set-up and data monitoring display

ADCLTC1745

DACAD9772

DACAD9772

RAA Digital Control

Scope

Ext

rem

e E

nvi

ron

men

t

Xilinxproto-board

running reconfiguration

algorithms

VBias0

VBias1

Vin0

Vout5V

3.3V

Filtered signal

R[3:0] C[2:0] Nandc Data

RAAboard

DACAD9772

3.5V

1.5VVref0

14

14

14

CLK

4 3

CLK_OUT

ENC

12RS232


SRAA board level integration

DAC

Monitoring and Compensation

DAC DAC

ADC

PowerRAA

FPGA

VbiasControl for RAA

AnalogFiltering

SignalExtraction

RAA TopologyControl (from FPGA)

ExcitationSignal for

RAA

SerialInter-face


1:20-03:00

adaptive and evolvable hardware

Documents