© 2003-2009 ran ginosar048878 lecture 4: speed-independent control circuits 1 vlsi architectures...

© 2003-2009 Ran Ginosar 048878 Lecture 4: Speed-Independent Control Circuits 1

VLSI Architectures048878

Lecture 4

S&F Ch. 6: Speed-Independent Control Circuits


Control Circuits• Many methods, tools, assumptions,

frameworks

• Some tools generate both control and data-path

• We now consider one method / tool for control-only spec, verification and synthesis:

– Assumption: Speed independent control for speed independent bundled data

– Method: Signal Transition Graph • A special type of Petri net

– Tool: Petrify (mostly from Jordi Cortadella at UPC)


Delay Models• Fixed delay: d=c

• Min-max delay: choose d[m,M]

– Max delay: d[0,M]

– Low-bounded delay: d[m,)

• Unbounded delay: d[0,)

• Inertial delay: Glitches are filtered.

– We don’t assume inertial delays in async control design


Petri net, Signal Transition Graph (STG)

a+ b+

c+

a- b-

c-

a+ b+

c+

a- b-

c-


Separating Inputs, Outputs and Internals

a+ b+

c+

a- b-

c-

a+ b+

c+

a- b-

c-

INPUTS, OUTPUTSINPUTS, OUTPUTS


In the STG:• PN transition are signal transitions

• PN places and arcs are causal relations

• Simple places (one arc in, one arc out) are omitted

• MARKING

assignment of tokens to places

state of the circuit


Token Preservation (from Lecture #1)

• Tokens do not disappear

• Tokens do not appear (from nowhere)

• One token does not overtake another

• A transition with n inputs and m outputs:

– waits for n tokens on inputs

– Generates m tokens on outputs

n m


State Graph (SG)

abc 000State:

100 010

110

011 101

111

001

•SG more complex than STG

•What complexity?

•Bad for design spec

•Needed for synthesis

a+ b+

b+ a+

c+

a- b-

b- a-

c-


State Graph (SG)

Quiescent Region QR(c=0)


Excitation Region ER(c=R)

Excitation Region ER(c=F)

000

100 010

110

011 101

111

001

a+ b+

b+ a+

c+

a- b-

b- a-

c-


State Graph (SG)



Excitation Region ER(c=R)

Excitation Region ER(c=F)

000

100 010

110

011 101

111

001

a+ b+

b+ a+

c+

a- b-

b- a-

c-

SET C

RESET C

KEEP C=1

KEEP C=0


Synthesis: C Element• Two methods:

– Using gates

– Using SR latch


Synthesis: C Element using gates

000

100 010

110

011 101

111

001

a+ b+

b+ a+

c+

a- b-

b- a-

c-

SET C

KEEP C=1

0 0 R 0

F 1 1 1

0

1

00 01 11 10c\ab

c=ab+ac+bc

a

bc

!HazardousMaterial !


Hazardous Hazards

SLOW

a

bc

ac

ab

bc

a

b

c

acabbc (slow)


Hazardous Hazards• Hazards are no big deal in sync circuits

• Hazards may be deadly in (some) async circuits

• Now you know why you were taught about them in school…

• We can build hazard-free circuits

• We can (sometimes) make timing assumptions and add delays


Hiding Hazards Behind Delays

SLOW

a

bd

ac

ab

bc

c

a

b

c

acabbc (slow rise)

d

Do you like slowing your circuit ?


Avoiding Hazards with Complex Gates

ab c

c

a

b

a b

a

b

a b

c

cT1

•Theoretically, same hazard problem (e.g. T1 slow)

•Must use caution or delay output


RESET C

KEEP C=0

Synthesis: C Element using SR Latch

000

100 010

110

011 101

111

001

a+ b+

b+ a+

c+

a- b-

b- a-

c-

SET C

KEEP C=1

0 0 R 0

F 1 1 1

0

1

00 01 11 10c\ab

set=ab reset=ab

ab cS

R

Q


Synthesis using SR latches• Needs (mutually exclusive) SET, RESET

regions

• May use KEEP 0, KEEP 1 regions

• May use unreachable states (more later…)

• Area / performance / power may be more or less than gate circuits

• May use C elements instead of SR latches

• SR latches enable implementation with standard libraries


Implementation using Latches / Cel

S

R

Q

SETLOGIC

RESETLOGIC

C

SETLOGIC

RESETLOGIC


Generalized C Element

ab C

+

-cz set(z) = ab

reset(z) = b'c'

z

reset

setb

a

c

b

z

a

b

c

z

reset

setb

a

c

b

a

b

cset

reset

DYNAMIC (Pseudostatic) STATIC

z

b c

b a


More interesting PNs and STGs

FORKs

JOINs

(input) CHOICE

MERGE

CONTROLLEDCHOICE

MUTUALLYEXCLUSIVE

MUTUALLYEXCLUSIVE

x+

x+

x+

x+


STG with Input Choice

x+y+

z+ b+

y- x-

z- b-


(S&F Fig. 6.8)


(S&F Fig. 6.8)

dummy

2-Way Edge

Req=1 Ctl stableand controls dummy1/2


A “Simple” Choice Net

a

b

c

d

a

bcd

d+

a-

a+b+ c-

c+ b- b+

c+

d-

RR00b+

01R0c+

0F10

a+

b+

1R00

110R

c-

0F10b-

d+

11R1a-

F110

111Fd- c+

I II


Unreachable States

00

01

00 01 11 10cd\ab

x x x

x x x

x

11

10

RR00b+

01R0c+

0F10

a+

b+

1R00

110R

c-

0F10b-

d+

11R1a-

F110

111Fd- c+

0000b+

0100c+

0110

a+

b+

1000

1100

c-

0110b-

d+

1101a-

1110

1111d- c+


Regions and Maps

For c

00

01

00 01 11 10cd\ab

0 R 0 0

x x R x

x x 1 x

F 1 1 x

11

10

c=d+a’b+bc

set(c)=d+a’b

reset(c)=b’

RR00b+

01R0c+

0F10

a+

b+

1R00

110R

c-

00F0b-

d+

11R1a-

F110

111Fd- c+


c=d+a’b+bc

set(c)=d+a’b

reset(c)=b’

ab cd

C cab

d


Regions and Maps

For d

00

01

00 01 11 10cd\ab

0 0 R 0

x x 1 x

x x F x

0 0 0 x

11

10

d=abc’

set(d)=abc’

reset(d)=c

RR00b+

01R0c+

0F10

a+

b+

1R00

110R

c-

0F10b-

d+

11R1a-

F110

111Fd- c+


Walks on SG and KM

00

01

00 01 11 10cd\ab

x x x

x x x

x

11

10

I

II

I II

RR00b+

01R0c+

0F10

a+

b+

1R00

110R

c-

0F10b-

d+

11R1a-

F110

111Fd- c+


STG Rules• Any STG:

– Input free-choice—Only mutex inputs may control the choice)

– 1-Bounded—Maximum 1 token per place

– Liveness—No deadlocks

• STG for Speed Independent circuits:

– Consistent state assignment—Signals strictly alternate between + and –

– Persistency—Excited signals fire, namely they cannot be disabled by another transition

• Synthesizable STG:

– Complete state coding—Different markings must represent different states


• We use the following circuit to explain STG rules:

req

ack

REQ

ACK


1-Bounded (Safety)• STG is safe if no place or arc can ever contain more than one

token

• Often caused by one-sided dependency

STG is not safe: If left cycle goes fast and right cycle lags, then arc ack+ REQ+ accumulates tokens. (REQ+ depends on both ack+ and ACK- )

Possible solution: stop left cycle by right cycle

REQ+ ACK+

REQ-ACK-

req+ ack+

req-ack-


Liveness• STG is live if from every reachable marking,

every transition can eventually be fired

• The STG is not live: • Transitions reset, reset_ok cannot be repeated.

• But non-liveness is useful for initialization

reset_ok-reset- req+ ack+

req-ack-


Consistent State Assignment• The following subset of STG makes no

sense:

a+ a+

a- a-


Persistency• STG is persistent if for all arcs a* b*, other arcs ensure that

b* fires before opposite transition of a* (* is either + or -)

• Non-persistency may be caused by one-sided relations

STG is not persistent (in addition to being unsafe): If left cycle goes fast and right cycle lags, then ack+ ack- before REQ+ .

Danger: Logic design may be REQ+ = ack+Exception: If a* b*, assume that the environment assures persistency.Possible solution: stop left cycle by right cycle.

REQ+ ACK+

REQ-ACK-

req+ ack+

req-ack-


Complete State Coding• STG has a complete state coding if no two different

markings have identical values for all signals.

REQ+ ACK+

REQ-ACK-

ack- req+

ack+req-

1000 1010req,ack,REQ,ACK:

1011

100110001100

0100

0000

00

01

00 01 11 10cd\ab

11

10

Disaster!


Complete State Coding• Possible solution: Add an internal state

variable

x- x+

req,ack,REQ,ACK,x:

REQ+ ACK+

REQ-ACK-

ack- req+

ack+req-

10000 10100

1000111001


Original STG• We have considered the following circuit

and STG:

REQ+ ACK+

REQ-ACK-

ack- req+

ack+req-

req

ack

REQ

ACK


A faster STG?

• Does it need an extra variable?

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-


Drawn by draw_astg


The SGreq,ack,REQ,ACK:

0000

r+1000a+ R+

1100 1010r-

0100

R+

1110a+ A+

1011A+

1111a+r-

0110

R+a-

a- A+

0111r-

0011a-

R-

1001R-

1101a+

R-

0101r-

0001a-R-

A-

1000A-

1100a+

A-

0100r-

a-A-1011

r+

1001r+R-

A-1111

a+

R-

1101a+

A-0111

r-

R-

0101r-

A-

a-

a-


The SGreq,ack,REQ,ACK:

0000

r+1000a+ R+

1100 1010r-

0100

R+

1110a+ A+

1011A+

1111a+r-

0110

R+a-

a- A+

0111r-

0011a-

R-

1001R-

1101a+

R-

0101r-

0001a-R-

A-

1000A-

1100a+

A-

0100r-

a-A-1011

r+

1001r+R-

A-1111

a+

R-

1101a+

A-0111

r-

R-

0101r-

A-

a-

a-

R+

R+

R+


Drawn by write_sg & draw_astg


Extra states inserted by petrify


Rearranged STG

ack-

req+

ack+

req-

c1-

c1+

c0-

ACK-

REQ+

ACK+

REQ-

c2-

c2+

c0+

Initial Internal State: c0=c1=c2=1


The new State Graph…


The SynthesizedComplex Gates Circuit

INORDER = r A a R csc0 csc1 csc2;

OUTORDER = [a] [R] [csc0] [csc1] [csc2];

[a] = a (csc2 + csc0) + csc1';

[R] = csc2 (csc0 (a + r) + R);

[csc0] = csc0 (csc1' + a') + R' csc2;

[csc1] = r' (csc0 + csc1);

[csc2] = A' (csc0' (csc1' + a') + csc2);


Technology Mapping

INORDER = r A a R csc0 csc1 csc2;OUTORDER = [a] [R] [csc0] [csc1] [csc2];[0] = R'; # gate inv: combinational[1] = [0]' A' + csc2'; # gate oai12: combinational[a] = a csc0' + [1]; # gate sr_nor: asynch[3] = csc1'; # gate inv: combinational[4] = csc0' csc2' [3]'; # gate nor3: combinational[5] = [4]' (csc1' + R'); # gate aoi12: combinational[R] = [5]'; # gate inv: combinational[7] = (csc2' + a') (csc0' + A'); # gate aoi22: combinational[8] = csc0'; # gate inv: combinational[csc0] = [8]' csc1' + [7]'; # gate oai12: combinational[csc1] = A' (csc0 + csc1); # gate rs_nor: asynch[11] = R'; # gate inv: combinational[12] = csc0' ([11]' + csc1'); # gate aoi12: combinational[csc2] = [12] (r' + csc2) + r' csc2; # gate c_element1:asynch


The Synthesized Gen-C Circuit

INORDER = r A a R csc0 csc1 csc2;OUTORDER = [a] [R] [csc0] [csc1] [csc2];[0] = csc0' csc1 (R' + A); [1] = csc0 csc2 (a + r); [2] = csc2' A; [R] = R [2]' + [1]; # mappable onto gC[4] = a csc1 csc2'; [csc0] = csc0 [4]' + csc2; # mappable onto gC[6] = r' csc0; [csc1] = csc1 r' + [6]; # mappable onto gC[8] = A' csc0' (csc1' + a'); [csc2] = csc2 R' + [8]; # mappable onto gC[a] = a [0]' + csc1'; # mappable onto gC


Petrify Environment

STG

EQNdraw_astg

ps

write_sg

SG

libpetrify


Petrify• Command line tool• petrify –h for help (flags etc.)• petrify –cg for complex gates• petrify –gc for generalized C-elements• petrify –tm for tech mapping• draw_astg to draw• write_sg to create state graphs

• Documented on line, incl. tutorial – See

www.lsi.upc.edu/~jordicf/petrify/home.html


Technical notes on Petrify• Have or install cygwin on Windows

– http://cygwin.com/

• Download dot.exe

– Linked from the petrify site

• Include the bin dir in your path

– In .bash_profile in the cygwin home dir. For example:export CLASSPATH=.export PATH=/cygdrive/c/cygwin/home/ran/petrify-4.2/bin:$PATH

• To draw_astg:draw_astg –Tdot file.g –o file.dotdot –Tps file.dot –o file.ps


A safer STG?

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-


A safer STG?


The safer STG is a serial circuit

INORDER = r A a R;

OUTORDER = [a] [R];

[a] = A;

[R] = r;

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

req

ack

REQ

ACK


Yet another STG?

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-


Yet another STG?


Output Handshake First

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-


Still a serial controller


SynthesisINORDER = r A a R csc0;OUTORDER = [a] [R] [csc0];[a] = csc0 A'; # gate and2_1: combinational[R] = r csc0'; # gate and2_1: combinational[2] = A' (csc0' + r'); # gate aoi12:

combinational[csc0] = [2]'; # gate inv: combinational

A

r

c0S

R

Q

Q

Aa

r R

c0

cA

r

c0

Aa

r R

c0

+

-=


A different STG

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

Redundant, will be ignored by petrify


A different STG


SynthesisINORDER = r A a R;OUTORDER = [a] [R];[a] = R; [1] = r A'; [2] = r' A; [R] = R [2]' + [1]; # mappable onto gCR = R(Ar’)’+A’r = R(A’+r)+A’r = A’r + RA’ +Rr

A

r Rca


Latch Control

req

ack

REQ

ACK

req

ack

REQ

ACK

Enable

Data-less fifo:

Latch:Lt

Enable=0:transparent


Constraints on sequence of events• Must keep input data available until

after it is latched

• Assume input data available only when req=1

• Once ack+, req- (and input data invalid) can follow very fast

• Lt+ before ack+


Latch Control: STG Fragments

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

req+ ACK-

REQ+

Lt+

ack+

req- ACK+

REQ-

Lt-

ack-


Latch Control: Combined STG

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

Lt+

Lt-


Latch Control: Combined STG


INORDER = Rin Aout Ain Rout Lt;OUTORDER = [Ain] [Rout] [Lt];[Ain] = Lt; [1] = Aout' Rin; [2] = Aout Rin'; [Rout] = Rout [2]' + [1]; # mappable onto gC[Lt] = Rout; R = R(Ar’)’+A’r = R(A’+r)+A’r = A’r + RA’ +Rr

A

r Rc

Lt

a


MUX Control• So far all examples are doable “by hand”

• A deceptively simple example:Control for 4-phase bundled data mux

PUSHchannels


4-phase Bundled-data Mux• We have already drawn this (dual-rail control):

yz

x

y zx

ctl.tctl.f

y-ackz-ack

x-ack

y-req

z-req

x-req

C

C

ctl

0

1

C

Cctl.f

ctl.t

ctl-ack

Easier to start with the dual-rail control


The environment• Four independent environments (rCf, rCt share aC)

• Must not specify any dependency by mistake:

a0-

r0+

a0+

r0-

a1-

r1+

a1+

r1-

aC-

rCf+

aC+

rCf-

A-

R+

A+

R-

In0 In1 Ctl.f Out

aC-

rCt+

aC+

rCt-

Ctl.t


The control

• A+ must precede a0+ or a1+ (make sure data passed through and were captured)

• In0 and In1 handshakes must be made MUTEX

• Choices are matches with Merges


a0+

a1+

r0+

A+

rCf+

rCt+

aC-

r1+

R+

Input Free Choice

P3 P1 aC+ P2

rCf-

rCt-

P4

r0-

r1-

P5

Controlled Choice

Merge

Duplicate arrow


mux.g


mux.gc

• Replicated transitions: R+, R+/1

• Inserted state variable to retain In0 vs. In1 info


“Compact” state graph


Mux Control SynthesisINORDER = r0 r1 rCf rCt A a0 a1 aC R csc0 csc1;OUTORDER = [a0] [a1] [aC] [R] [csc0] [csc1];[0] = r0 csc0; [a1] = csc1 r1; [2] = csc1 (A + csc0); [3] = rCt' rCf' csc1'; [aC] = aC [3]' + [2]; # mappable onto gC[R] = a0' csc0' csc1 r0 + csc0 csc1'; [6] = a0' csc1 A r0 + csc1' r1 A'; [7] = aC (r0' + a0); [csc0] = csc0 [7]' + [6]; # mappable onto gC[9] = r0 A' + csc0 A; [10] = r0' csc0' r1'; [csc1] = csc1 [10]' + [9]; # mappable onto gC[a0] = a0 r0 + [0]; # mappable onto gC


Another Mux (4p ctl, bd) (Fig 6.24)


SG for the Fig 6.24 mux


All-bundled Mux


All-bundled Mux SynthesisINORDER = In0Req OutAck In1Req Ctl CtlReq In1Ack In0Ack OutReq

CtlAck csc0;OUTORDER = [In1Ack] [In0Ack] [OutReq] [CtlAck] [csc0];[In1Ack] = OutAck csc0'; [In0Ack] = OutAck csc0; [2] = CtlReq (In1Req csc0' + In0Req Ctl'); [3] = CtlReq' (In1Req' csc0' + In0Req' csc0); [OutReq] = OutReq [3]' + [2]; # mappable onto gC[5] = OutAck' csc0; [CtlAck] = CtlAck [5]' + OutAck; # mappable onto gC[7] = OutAck' CtlReq'; [8] = CtlReq Ctl; [csc0] = csc0 [8]' + [7]; # mappable onto gC


Reduced concurrency mux


A simple filter: specification

y := 0;loop x := READ (IN); WRITE (OUT, (x+y)/2); y := x;end loop

RinAin

Aout Rout

ININ

OUTOUT

filter

Following slides borrowed from Jordi Cortadella, UPC


A simple filter: block diagram

x y+

controlRin

Ain

Rout

Aout

Rx AxRy Ay Ra Aa

ININOUTOUT

• x and y are level-sensitive latches (transparent when R=1)• + is a bundled-data adder (matched delay between Ra and Aa)• Rin indicates the validity of IN• After Ain+ the environment is allowed to change IN• (Rout,Aout) control a level-sensitive latch at the output


A simple filter: control spec.

x y+

controlRin

Ain

Rout

Aout

Rx AxRy Ay Ra Aa

ININOUTOUT

Rin+

Ain+

Rin-

Ain-

Rx+

Ax+

Rx-

Ax-

Ry+

Ay+

Ry-

Ay-

Ra+

Aa+

Ra-

Aa-

Rout+

Aout+

Rout-

Aout-


A simple filter: control impl.

Rin+

Ain+

Rin-

Ain-

Rx+

Ax+

Rx-

Ax-

Ry+

Ay+

Ry-

Ay-

Ra+

Aa+

Ra-

Aa-

Rout+

Aout+

Rout-

Aout-

C

Rin

Ain

Rx Ax RyAy AaRa

Aout

Rout


Control: observable behavior

Rx+

Rin+

Ax+ Ra+ Aa+ Rout+ Aout+ z+ Rout- Aout- Ry+

Ry- Ay+Rx-Ax-Ay-

Ain-

Ain+

Ra-

Rin-

Aa-z-

C

Rin

Ain

Rx Ax RyAy AaRa

Aout

Rout

z


Rx+

Rin+

Ax+ Ra+ Aa+ Rout+ Aout+ z+ Rout- Aout- Ry+

Ry- Ay+Rx-Ax-Ay-

Ain-

Ain+

Ra-

Rin-

Aa-z-

Rin+

Ain+

Rin-

Ain-

Rx+

Ax+

Rx-

Ax-

Ry+

Ay+

Ry-

Ay-

Ra+

Aa+

Ra-

Aa-

Rout+

Aout+

Rout-

Aout-

z+

z-

Backward Annotation


Homework• Design an async controller and data path for

computing the Fibonacci series (fn=fn-1+fn-2, f0=f1=1). It starts with a Req and generates the sequence infinitely.

• Implement the controller with Petrify, using:

– Complex gates

– Generalized C elements

– SR latches

• Compare the three solutions. Decide which three comparison criteria to use


Data Validity


Four Channel Types


2 phase protocols• When are the data valid?


4 phase push protocols• Four different possibilities:


Precharged CMOS Needs Extended-Early

• Input data valid during evaluate phase (REQ_IN=1)

REQ_IN

REQ_IN

REQ_IN

f

t

REQ_OUT?

From Lecture 6


Hierarchical Order of Data Validity

• Broad can be used when any other type needed (etc.)

• Handshake-transparent circuits (function blocks):

– Strength(outputs) Strength(inputs)

• Latch:

– Strength(outputs) Strength(inputs)

BROAD

EXTENDED EARLY

EARLY LATEweak

strong


Validity Example: Join• Extended early inputs, early outputs

ya-

yr+

ya+

yr-

za-

zr+

za+

zr-

xa-

xr+

xa+

xr-

y-ackz-ack

x-ack

Cy-reqz-req

x-req

y z1x z0

Why?


Validity Example: Latch• Early inputs, extended early outputs

req

ack

REQ

ACK

Enable

Lt

Enable=0:transparent ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

Lt+

Lt-


4 phase pull protocols


Latch Decoupling


Simple Muller Pipeline with Latches

• Only half full (spread = 2)

• Stage i+1 must be empty before stage i can latch new data


Decoupled Pipeline with Latches

• We need a new controller

• Want to get spread=1


Latch Control Revisited

• Lt+ waits for REQ+

• REQ+ waits for previous ACK-

• Result: Next stage must be EMPTY before we can latch.

• Wish to decouple the two sides.

req

ack

REQ

ACK

Enable

Lt

Enable=0:transparent ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

Lt+

Lt-


ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

Lt+

Lt-

Semi-Decoupled Latch Control

• All stages can be filled (spread=1)

– [Furber & Day (1996), Furber and Liu (1996)]

• But ack- waits for ACK+ may slow a pipeline

• Add a second state variable fully decouple input and output

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

A+

Lt+

A-

Lt-

EarlyInput

ExtendedEarlyoutput

EarlyInput

Earlyoutput


Fully-Decoupled Latch Control

• ack- decoupled from ACK+

• But output validity too short – not good for holding data for function blocks

EarlyInput

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

A+

Lt+

A-

Lt-

B+

B-Earlyoutput

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

A+

Lt+

A-

Lt-

EarlyInput

Earlyoutput


Broad Decoupled Latch Control

• Complex control decoupled pipeline latch

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

A+

Lt+

A-

Lt-

EarlyInput

Broadoutput

B+

B-EarlyInput

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

A+

Lt+

A-

Lt-

B+

B-Earlyoutput


CSC

Input validity: early, output: broad (maybe convert output to early?)

LD=1 latch transparent

Pulsed Ld. Input validity: broad, output: broad


Normally Opaque Latch Control

• Latch opens only when new data arrive [Sparso et al., 1998]

• Lt- REQ+ delay must be > Lt- data out delay

ack-

req+

ack+

req-

ACK-

REQ+

ACK+

REQ-

Lt-

A+

Lt+

A-

EarlyInput

Broad++output


Normally Opaque Latch Control


Doubly-Latched Pipeline

• “ultimate” decoupling

– [Branover (1998), Kol & Ginosar (1997)]

• Neighbor stages are fully independent

• Cost: 2 latches

CL CL CL

control

LM LS

control

LM LS

control

LM LS

Ro

Ri Ao

Ai

Ro

Ri

Ao

Ai

Ro

Ri

Ao

Ai


Pipeline Schedule

A B

Task

1

Task

2

Task

3

A 1 1 2

B 2 1 1

A

B

1 2 3 4 5 6 7 8

A

B

1 2 3 4 5 6 7 8

A

B

1 2 3 4 5 6 7 8

1 2 3

1 2 3

1 2 3

1 2 3

1 2 3

1 2 3

synchronous

fully-decoupled

DLAP

© 2003-2009 ran ginosar048878 lecture 4: speed-independent control circuits 1 vlsi architectures...

Documents

speed independent control

c slide

ran ginosar048878 lecture

c set c reset c

c element

async control design

circuit slide

upc slide