1 system aspects integration need for upfront complete specifications behavioral vs structural...
Post on 11-Jan-2016
216 Views
Preview:
TRANSCRIPT
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
top related