1

System Aspects

• Integration

• Need for upfront complete specifications

• Behavioral vs structural specification

• On-line vs off-line evolution

• Languages for evolvable hardware

• Verification and validation

• Techniques to accelerate evolution

• Challenges, and open problems

2

devices

circuits

systems

• At the device level, evolution can assist in creating structures with desired functional characteristics. For example, the synthesis could be of a nanoelectronic device, such as a Resonant Tunneling Diode with the characteristic in Fig. 1 or the less common device with the characteristics in Fig. 2. Some of the parameters that determine this functions can be kept fix, while some (e.g., T1-T5, N1-N2 in Fig. 3) can be used as variables in the genetic search.

• At the system level, evolution can be used to bring together different building/functional blocks, such as an antenna and associated impedance matching electronics.

While optimal designs may be found individually for each component of the system, when considered functioning together, the optimal points may change and need recalculation.

T1 T5T2 T4T3 N1

N2Dop

ing

(1/c

m3)

Ene

rgy

Length

I

V

Fig. 1 I

V

Fig. 2Fig. 3

• At the circuit level, evolution can combine devices with specific functional characteristics to achieve an overall functionality. For example, given the choice of devices with characteristics in Fig. 1 and Fig. 2, find the optimal interconnections that provide the function of a 4-input NAND gate with minimum power consumption.

Evolution at device, circuit, and system level

3

Antenna/sensor

Signalconditioning

Transf.signal

processing

Compression Antenna

Consider the following signal information path, decomposed on functional blocks:

Alternatives:• Evolve each functional block independently • Evolve at a higher level, not being influenced by boundaries of functional block level.

Evolution by functional subsystem decomposition

4

Integration

Evolvable System: A programmable system that autonomously modifies its hardware.

Integration of various programmable and no-programmable resources into an evolvable system. Integration of homogeneous and heterogeneous resources.

Integration of an evolvable system as component of bigger system. Evolvable meta-system. Evolve the integrated system.

5

From programmable/reconfigurable to evolvable systems. Imaginary examples

• From fixed system to reconfigurable

• From reconfigurable to self-reconfigurable/evolvable

• Electronic sensing pill

• Cochlear implant

• Video cell phone

• UAV

• Satellite

• Sensory network

6

EHW SoC Platform Definition

ARM/ SPARC

Integer UnitI-cache D-cache

Debugsupport unit

AHBcontroller

AHB interface

FP

CP

Debugserial link

MemoryController

PROM SRAM I/O

8/16/32- bit memory bus

AHB/APBbridge

AMBA AHB

PCI

User I/O

IP 1 DSP

EA

RC1

RC2

7

Experiment Setup

8

Chip measurements

CPU Ext. memory

FLUKE 189

EVB: 0.35µm, 3.3V, 15MHz

Randomizers, digital EHW

•

Xilinx Virtex FPGA Board

D/A

Digital I/O

A/D

Aiming to enable automatic synthesis of complex digital functionality for flight computers at the FPGA hardware level

RNG

Completed design and validation of a VHDL implementation for a pseudo random number generator. The design is being

ported to the FPGA board.

Integrated the DIE HARD software suite that will be used in the evaluation of pseudo random generator into the EHW test bed

2000 - Digital EHW for Complex FunctionalitySynthesis of Random Number Generators on FPGAs.

Suitable task for evolution: no design guidelines, but measures of randomness exist

FPGA offer fast, parallel evaluation of candidate solutions.Encryption applications - DARPA and NSA

Long term goal - Evolvable flight computerWould leverage FPGA-based flight hardware and endowing it

with evolution capabilities

Execute the Genetic Algorithm and Evaluate sets of pseudo random

numbers using DIE HARD

software suite

Generate sets pseudo random

numbers

10

Interaction with an evolvable system

• Imagine a UAV which is launched for a routine recognition mission. New information demands a mission change. This is communicated in natural language, converted in a set of specific instructions:

• Follow from medium distance the target which is now (time T) located at GPS coordinates (X,Y,Z). Take/Send pictures of places it goes. Maximum priority with resolution and aurgency of transmission if targets stops. Second order priority for images with buildings passed by moving target. Lowest priority for images while vehicle moves at high-speed. Maximize your tracking based on available power.

• Function 1. Focus on target. Parameters. Coordinates of target: X,Y,Z. Priority 5/5• Function 2. Follow/track: Parameters: 2/3 Priority 4/5• Function 3. Take pictures Parameters: Picture resolution. Frequency of pics.• Function 4. Compress pictures. Parameters: compression ratio and time for compression. • The UAV has a planning/scheduling optimization problem. In order to maximize pursuit

time it needs to minimize power consumption.

• Functions relevant to objective function and their priorities. • An evolvable system should receive information in order to set a new objective function.

11

A world controlled in natural language

Sensor web

High-level specs

Devices evolve for adaptation

Spec/requirement

constraints: weather, events

12

Tomorrow humans will only provide the high-level desired specs

Today the human is actively involved in many steps

Fitnesswriteschooses choosesEA /params

Stopping criteria

RHDesign

Spec language

Compiler

Fitnesschooses

Self-adapting EA

Morphable device

Automatic

EHW today and tomorrow

13

Open problem: Intelligent Compilation

Evolvable Hardware

Fitness Function

SamplingRate

Chromosome Mapping

ExcitationSignal

Intelligent Compilation

Behavioral Specification

in HDL

BuildingBlocks

Evolutionary Specifications

Environmental Conditions

14

Need for upfront complete specifications

• In many cases the specifications formulated by a human user are incomplete. They either assume background information, domain information, or common-sense.

• One of the greatest difficulties for autonomous systems/EHW is the lack of human-in-the-loop interaction/feedback, which allows user to guide the design process, do trade-offs, especially when the problem as formulated can not be solved: it provides satisfactory alternative solution domains.

15

Importance of complete specifications

Examples: A request for a functional AND gate did not specifically include:

- A request for its driving capability (an implicit assumption of user that that would work. Result: the evolved gate was functionally correct but could not drive another gate in normal conditions.- A request that it functions correctly at several time scales. Result: the evolved gate was functionally correct operating at the time scale for which it was tested during evolution (ms) but failed at microseconds.

16

Potential remedy

In2

Vdd

In1

Out

M1

M2

M3

M4

Potential problem:input applied to drainof transistor M1

Inserting more domain knowledge in the constraints.

Example : Force inputs to connect to transistor gates (high impedance) in the circuit that is evolved. Result: all evolved gates drove other gates.

17

Behavioral vs structural specification

• Behavioral (functional) specification indicates the targeted function of the module. It does not specify a way of implementing the module based on available primitive functions, sub-modules, or elements of the library, or resources available on the chip.

• Structural (synthesizable) specification indicates a possible implementation of the functional module in terms of sub-components (library elements, chip resources, etc).

18

Evolving from High Level Specifications

• Evolutionary- based Compilation from behavioral HDL to structural HDL (for both digital and analog)

• Evolutionary-based Synthesis of structural AHDL

Most of today’s Evolutionary Design, in particular for analog, is Behavior-Specified (often also Poorly-Specified).

One could decompose the process in two steps, 1. Compilation: from Behavioral Specifications to Structural

Specifications2. Synthesis: from Structural Specifications to a Structured

ImplementationThus, needed research, which can be approached by evolutionary

means:

19

Languages for evolvable hardware

• Language for specification of desired function on existing physical system

• Language for specification of an evolvable system (construction/design of an evolvable system) for a specific/class of problems

• Formal specifications, design for verification• Several languages and translators

• Vocabulary: includes primitive functions of evolutionary algorithms, eg {mutate(parameters[e.g.position, probability])}. Built-in operators.

• State machine specification or Genetic Programming for constructing evolvable systems. Evolvable meta-system?

20

On-line vs off-line evolution

• On-line: System evolves while it performs a useful function. Hard to deal with less fitted individuals; they may be disturbing the system. Imagine a UAV learning jet controls while flying. Safety measures may be needed. E.g.: try testing at very high altitude. Get a watchdog impeding dangerous actions.

• Off-line is more common. It is still intrinsic evolution, with physical hardware in the loop, but the evolvable subsystem is not responsible for the function of the system. For example chips tuned to compensate for fabrication mismatches are in the category.

• An in-between case is in the ping-pong architecture.

21

Structure of an evolvable system• Ping-pong architecture for evolution while operational. Real process data

comes to both inputs• Only one controls, while the other adapts, they can then swap. Either a Master

controller/optimizer or each has its own and they communicate.

IO

System 1has control

System 2

under evolution

Comms

Controller

22

Can we trust the solution?

• Can we rely on an evolved solution when we don’t understand how it operates and can not predict its behavior outside the tested domain? NN-like black box issue?

• Not all solutions are a la Thompson. Many solutions are choices of made with conventional, “trusted/reliable” components. For example evolutionary power-optimization of an implementation with conventional digital blocks.

• COTS and custom chips go through extensive silicon testing before intended operation. Would an evolved design be good? Tested, repetitive, accurate solutions vs less accurate but tunable. This is an issue of TESTING components.

23

Verification• Verification: making sure the solution satisfies the specification• A process to demonstrate the functional correctness of a design

Testbench: (VHDL,Verilog) a code used to create a pre-determined input sequence to a design, then optionally observe the response.

Verification over 70% of the design effort.Parellelism of effort, higher level of abstraction and automation

– Formal methods: equivalence checking and model checking

• Poor/incomplete specifications?

• Validation: making sure the solution satisfies the intent– Operation in real environment

Testbench

Design under test/ verification

24

Testing

• Testing is to verify that the design was manufactured correctly.

• Verification is to make sure that the design meets its functional intent

• Test is through test vectors. Their objective is not to exercise functions, It is to exercise physical locations in the design to ensure they can (in the case of digital circuits) go from 0 to 1 and from 1 to 0.

• Controllability and observability. Testing and test coverage depends on the ability to set internal physical locations to either 1 or 0 and then observe that they were really set.

25

Price of reconfigurability

• Switch-based reconfigurability:

• Switch on signal path – parasitic impedance and voltage drops

• Extra resources

• Still, small price to pay for flexibility and survivability

26

Techniques to accelerate evolution

• Simpler models

• Fuzzy topologies

• Reduced/Incomplete testing during evolution, test thoroughly only final solutions

27

Models of various accuracy

• Need for models of various accuracy and simulation speed in different contexts of design and analysis, or within different simulators;

• Models may be of similar or different nature, structural or behavioral.

• Traditional model development and tuning is manual;

• Simplification path flows from a model to a simpler one, which in turn generates a simpler one. It’s not guaranteed that this simpler equivalent model is consistent with the thing it models in the first place.

28

Our problem: automatic circuit design automatic model determination

From: Desired behavior

Model

Circuit design

Automated technique

Used for

Explore properties

Perform functions

We obtain:

Our problem – Electronic Circuits automatically determined in SW (simulations of models) not guarantied to work in HW (real-world) and vice-versa)

By

29

How to find consistent models

• A means to automate modeling and derive the two or more equivalent models simultaneously and consistent with each other;

System

Simpler Model

Even simpler Model

TrustedModel

M

M

m m

M M M

m m

•Use search algorithms to explore the space of possible solutions in different models’ search spaces, evaluating models of different type, and resulting in models that have consistent behavior.

Find the set of consistent models - model family

Mixed Model Search (MMS)•Candidate designs (circuit models) are evaluated during an automated search process (evolutionary algorithms);

• heterogenous mix of models of various types, e.g. of both high and low levels of resolution.

30

Mixed Model Search (MMS)

C1

C2

C3 . . .CN

M1 m1

M2 m2

M3 m3...MN mn

F1 f1

F2 f2

F3 f3...FN fn

Population of chromosomesor circuits Ci

High resolution model MiLow resolution model mi Pair of fitness functions

for two models Fi and fi

31

Fitness Assignment Alternatives

• For each candidate circuit (model family), the fitness functions of the various models of that circuit are combined in evaluating the candidate circuit.

• Employing only one model for each candidate circuit during any single iteration of the evolution process:

– Computational savings;

– After a number of iterations, each candidate circuit has been modeled with all levels of resolution.

32

Mixtrinsic Evolution (ME)

• Apply MMS by evolving on mixed/heterogeneous populations, composed partly by simulation models and partly by real HW;

• Constrain evolution to a solution that jointly simulates well in SW and performs well in HW, exploiting only the HW characteristics included in the SW model for producing the desired behavior.

33

Mixtrinsic evolution

Population of Software models

Parallel SearchAlgorithm SW1 SW2 SWn

Population of candidate solutions

...

Fig. 1. Extrinsic EHW: evaluations of software solutions

Mixed Population of Software and Hardware

Parallel SearchAlgorithm SW1 HW2 SWn

Population of candidate solutions

...

Fig. 3. Mixtrinsic EHW: evaluations of mixed populations comprised of both hardware and software solutions

Parallel SearchAlgorithm HW1 HW2 HWn

Population of candidate solutions

... Population of Hardware solutions

Fig. 2. Intrinsic EHW: evaluations of hardware solutions

Simulator

ModelReconfigurable

HW

StimulusData file

Path from chromosome to behavior data file a)extrinsic and b)intrinsic

HW evaluatortesting equipment

Configuration Parameters

Data file

b)a)

Portability problem...

34

Inputs and output for an AND gate

Samples (20 samples for 5 ms)

Vol

ts

S7P1

S4

S1

P2

V+

S12

S5

P4

S14

S15

S22

N6

N8S24

S23

N7S20

N5S11

S18

S17

S6S9

S8

S2

S3P3

S13

S10

S16

S19

S21

V-

In1 In2

Output

Extrinsically evolved circuit - its response in SW - its valid response in HW

35

1.8V

3.2V

S7P1

S4

S1

P2

V+

S12

S5

P4

S14

S15

S22

N6

N8S24

S23N7S20

N5S11

S18

S17

S6S9

S8S2

S3P3

S13S10

S16

S19S21

V-

In1 In2

Output

Fig. 9. Intrinsically evolved circuit, its response in HW and its invalid response in SW

3.2V

S7P1

S4

S1

P2

V+

S12

S5

P4

S14

S15

S22

N6

N8S24

S23N7S20

N5S11

S18

S17

S6S9

S8S2

S3P3

S13S10

S16

S19S21

V-

In1 In2

Output

Fig. 9. Intrinsically evolved circuit, its response in HW and its invalid response in SW

1.8V

1.8V

36

Fig. 10. Circuit obtained by mixtrinsic evolution, its valid responses in SW and in HW

Illustrated portability problem for Intrinsic and Extrinsic EHW

Mixtrinsic evolution uses heterogeneous populations of individuals some of which are evaluated extrinsic and some intrinsic.

• convergent mixtrinsic evolution reinforces similarities between SW and HW behavior.

• complementary (population is mixed within the same generation, each individual being randomly evaluated either in HW or SW)

• combined (each individual is evaluated both in HW and SW and a combined fitness is assigned).

• divergent evolution, in which case selection rewards the distinctions between HW and SW, e.g. forcing circuits that exploit HW characteristics not modeled in SW.

S7P1

S4

S1

P2

V+

S12

S5

P4

S14

S15

S22

N6

N8S24

S23N7S20

N5S11

S18

S17

S6S9

S8S2

S3P3

S13S10

S16

S19S21

V-

In1

In2

Output

37

Search may be faster with partly open switches

W=1.2uL=0.6u

W=3.6uL=0.6u

Vcontrol

V’control

• Our implementation of the FPTA architecture allows partial opening of the interconnection switches;

• Evolving through partly controlled interconnections speeds up evolution, sometimes 1-2 orders of magnitude.

Control Voltage (Open -> Close)

Swit

ch R

esis

tanc

e (O

hms)

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 51,000

10,000

100,000

1,000,000

1E+7

1E+8

1E+9

1E+10

1E+11

1E+122E+12

Rlow

Rhigh

38

Gray-level switches

FPTA switches interconnecting transistors are not ON/OFF but can be controlled gradually with analog voltages on the gates of transistors that make the switch.

In current implementation analog Low and High signals are the same for all switches on the chip. This allows to map the 1/0-based genetic code/program of the switch to a Low/High resistance, not only to ON/OFF (i.e. very low, and very high), but to a great number of in-between values.

Thus, the switches can be partly-open, allowing the signals to more freely propagate/spread over the topology.

39

Gradual morphing

A temperature parameter is high at the beginning of evolution and decreasing to null over generations. When it is “hot” there is a lot of “thermal movement” and the Low/High values for the resistance of the switch, are close to each other, somewhere in the middle range (say 2M/20M). As the temperature decreases the two separate, low becoming lower, high becoming higher (e.g. (1k/30k), (500/100k) ending up for example at (10/10G). Using this annealing promising individuals showed up much earlier in the search and led to accelerate evolution, in some experiments over 10 times.

On a physical FPTA chip we could stop evolution early, since solutions usually show up in the first few generations and are fully operational.

For ASIC or patents evolution has to maintain the acquired solution while “cooling” to ON/OFF connectivity.

T=0T=100Gen=0 Gen=100

R

RHigh

RLow

40

Fuzzy topologies

The gradual opening seems to permit signal propagation to points where OFF switches in a traditional ON/OFF Boolean search may prevent it, making it more a “needle in-the-hay” search problem. Another way of looking at the circuits connected by gradual switches is to see not one, but several superimposed (conventional/Boolean) topologies at once –a fuzzy topology. These superposition/fuzziness allows for a more parallel search.

41

• It is still hard to evolve complex circuits, although we can evolve now orders of magnitude faster.

• It is hard to prove a solution is stable, robust, and hard to predict its behavior outside the domain in which it was evolved.

• The difficulty is in writing fitness functions and guiding evolution for complex systems

• Complete upfront Specifications are required

• The challenge of conventional design is replaced with that of designing an evolutionary process that automatically performs the design in our place. This may be harder than doing the design directly, but makes autonomy possible.

Revisiting Challenges and open Problems

42

On-chip search may suffer from Transient Solutions and Memory Effects

Example of transient behavior. Degradation shown over ~ 1 s.

• Circuit under evaluation my require a certain amount of time to achieve steady state, while faster evaluation may evaluate a transient behavior

• FPTA-state dependence: Behavior exhibited in the evaluation can be influenced by the circuit downloaded previously ;

• Artifacts due to parasitic as well as static capacitors in the chip which can be charged during one configuration period and not discharged before the next configuration is tested;

• Observation: GA usually eliminates transient solutions after some generations.

43

Solution is guarantied only where tested

Response of the half-wave rectifier for a frequency sweep from 500Hz to 5kHz(left). Deteriorated response at 50kHz.

Circuit evolved at 2kHz does not work at more than 10kHz

Circuit behavior should be evaluated for the overall frequency domain in which it is expected to work

44

Evolution does not work on implicit assumptions

Time (Micro-seconds)

Inpu

t1(V

olts

)

0 2.5 5 7.5 100

1

2

3

4

Time (Micro-seconds)

Inpu

2(Vo

lts)

0 2.5 5 7.5 100

1

2

3

4

Time (micro-seconds)

Out

put (

Volts

)

0 2.5 5 7.5 100

1

2

3

4

Time (Seconds)

Inpu

t1 (V

olts

)

0 25 50 75 1000

1

2

3

4

Time (Seconds)

Inpu

t2 (V

olts

)

0 25 50 75 1000

1

2

3

4

Time (Seconds)

Out

put (

Volts

)

0 25 50 75 1000

1

2

3

4

Evolved NAND gate evaluated inthe timescale of microsecond (until 10-5 sec)

microsecond secondEvolutionary design requires explicit formulation

of assumptions often implicit to human designers. For example:

• evolved logic gates tested with slow signals were naturally slow• Evolution in small timescales: transient solutions;• Evolution in large timescales: slow gates;

Solutions:• Mixtrinsic evolution: using combined excitation modes;• Increase the duration of transient analysis to ‘catch’ operating point;• Decrease step of transient analysis: check circuit behavior after transition;• Increase output load to ensure a fast gate.

45

Challenges …and how we address them

• Scalability

• Existence/convergence

of optimal solution

• Satisfying real world requirements

– loads, power

• Low reliability/safety of evolved solution

• Understandability

• Complete specifications

• Hardware Artifacts

• Hierarchy

• Representations, adaptive GA parameters

• Smart fitness

• Evolve sensors rather than controls

Q

Q

D

Clk

46

Addressing complexity by hierarchical design

• Design and reuse

Evolve a simpler function, encapsulate the result, reuse- use as primitive.

3-bit DAC

4-bit DAC

• Use a standard higher-level building block (e.g. OA)Still, it’s not always clear how to select higher-level BB or how to encapsulate sub-circuits obtained by evolution.

47

Divide and conquer: evolving a scalable design

Time (s)

Out

put (

mA

)

0 0.001 0.002 0.003 0.004 0.005 0.006 0.007 0.008 0.009 0.010

0.04

0.08

0.12

0.16

0.2

0.24

0.28

Time(s)

Cur

rent

(A)

0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.020

0.0004

0.0008

0.0012

0.0016

0.002

0.0024

0.0028

Time (s)C

urre

nt(m

A)

0 0.004 0.008 0.012 0.016 0.02 0.024 0.028 0.032 0.036 0.040

2.5

5

7.5

10

12.5

15

17.5

2Bit DAC 3Bit DAC 4Bit DAC

We demonstrated a scalable approach based on encapsulation and block reuse

48

4-bit DAC

Building blocks: 3 bit DAC, Current Mirrors(CM) and Adders.

49

4-bit DAC Response

Time (ms)

Cur

rent

(mA

)

0 0.004 0.008 0.012 0.016 0.02 0.024 0.028 0.032 0.036 0.040

2.5

5

7.5

10

12.5

15

17.5

Digital Input

DN

L (L

SB

)

0 1.5 3 4.5 6 7.5 9 10.5 12 13.5 15-0.1

0

0.1

0.2

0.3

0.4

0.5

0.6

Time (s)

Cur

rent

(mA

)

0 0.004 0.008 0.012 0.016 0.02 0.024 0.028 0.032 0.036 0.040

2.5

5

7.5

10

12.5

15

17.5

Digital Input

DN

L (L

SB

)

0 1.5 3 4.5 6 7.5 9 10.5 12 13.5 15-0.02

0

0.02

0.04

0.06

0.08

0.1

0.12

Circuit Response

DifferentialNon-Linearity

Parametric Optimization(W,L)

0.5 0.11

50

Reconfigurableanalog circuits (on a chip)

Reconfiguration algorithm (e.g. evolutionary algorithm)running externally on computer

Evolvable Hardware

Evolvable reconfigurablesensor electronics

Proposed effort:

Concurrent effort

Reconfigurableanalog circuits

Reconfigurationalgorithm integrated on the chip

Evolvable Circuits - Evolvable Chip

Transducer

Reconfigurableanalog circuits

A/D conversion

Communication

Reconfiguration algorithmrunningexternally

Various Transducers

EVOLVABLEanalog circuits

A/D conversion

Communication

Evolvable Sensor Chips

Detector/transducer

Dedicated analog circuitsA/D conversion

Communication

Sensor on a chip

State-of-the-art:

Future:

Evolvable sensing • Multipurpose• Adaptive• Self-configurable

E-eye, e-nose, e-skin

Replace conventional fixed analog circuits with self-reconfigurable ones

51

Evolvable vision sensors

Photo-detector

Dedicated analog circuitsA/D conversion andvideo readout

Vision-orientedreconfigurable analogcircuits

Neuromorphic circuitsimplementing localvision algorithms

Evolvable programmabletransistor array (FPTA)circuits

Interfacing constraints

Evolutionary constraints

Inspirationfrom retina-like circuitry

Con

trol

lo

gic

DA

C

Ro

w

dec

od

e r

Ro

w

log

ic

Pixel Array

Analog readout

ADC

Column decoder

Reg

iste

rs

Parallel/serial

Digital Out

GND

VDD

Digital in

CLK

Amplifier

Difference Analog Out

COL BUSRST

SEL

SHSSHR

CSCR

VDD

VLN

Min

Msel

Mld

PD

52

Evolution of filters

Frequency(Hz)

Gai

n(dB

)

10 100 1,000 10,000 100,000 1,000,000-60

-50

-40

-30

-20

-10

0

10

An example of a band-pass filter evolved on the 4 FPTA cells

- Wide Band Filter: Gain of 10 dB between 100kHz and 1MHz with roll-off of 40 dB/decade before 100kHz and -20 dB/decade after 1Mhz.

- Narrow Band Filter: Gain of 2 dB between 1kHz and 10kHz with roll-off of -35dB/decade. Stop band below 100Hz and above 100kHz.

Frequency(H z )

Am

pli

tud

e (

dB

)

1 0 0 1 ,0 0 0 1 0 ,0 0 0 1 0 0 ,0 0 0 1 ,0 0 0 ,0 0 0 1 E +7-9 0

-7 5

-6 0

-4 5

-3 0

-1 5

0

1 5

Roll-offOf 40 dB/decade

Roll-off of35 dB/decade

Roll-off of-20 dB/decade

Input Output