1. Clockless Logic: Asynchronous Pipelines
MOUSETRAP: Ultra-High-Speed Transition-Signaling Asynchronous Pipelines

2. MOUSETRAP Pipelines Simple asynchronous implementation style, uses…
transparent D-latches
simple control: 1 gate/pipeline stage
Target = static logic blocks
“MOUSETRAP”: uses a “capture protocol”
Latches …
are normally transparent: before new data arrives
become opaque: after data arrives (“capture” data)
Control Signaling: transition-signaling = 2-phase
simple protocol: req/ack = only 2 events per handshake (not 4)
no “return-to-zero”
each transition (up/down) signals a distinct operation
Our Goal: very fast cycle time
simple inter-stage communication

3. MOUSETRAP: A Basic FIFO
Stages communicate using transition-signaling:
Latch Controller
1 transition
per data item!
ackN-1
ackN En
reqN
doneN
reqN+1
Data in
Data out
Data Latch
Stage N-1
Stage N
Stage N+1
2nd data item flowing through the pipeline
1st data item flowing through the pipeline
1st data item flowing through the pipeline

4. MOUSETRAP: A Basic FIFO (contd.)
Latch controller (XNOR) acts as “phase converter”:
2 distinct transitions (up or down)  pulsed latch enable
Latch is re-enabled when next stage is “done”
Latch is disabled when current stage is “done”
Latch Controller
2 transitions per
latch cycle
ackN-1
ackN En
reqN
doneN
reqN+1
Data in
Data out
Data Latch
Stage N-1
Stage N
Stage N+1

5. MOUSETRAP: FIFO Cycle Time
reqN
ackN-1
reqN+1
ackN
Data Latch
Latch Controller
doneN
Data in
Data out
Stage N
Stage N-1
Stage N+1 En 3
Fast self-loop:
N disables itself 2 1 2
N re-enabled
to compute
N computes
N+1 computes
Cycle Time =

6. Detailed Controller Operation
Stage N’s
Latch Controller
ack from N+1
done from N
to Latch
One pulse per data item flowing through:
down transition: caused by “done” of N
up transition: caused by “done” of N+1
No minimum pulse width constraint!
simply, down transition should start “early enough”
can be “negative width” (no pulse!)

7. MOUSETRAP: Pipeline With Logic
Simple Extension to FIFO:
insert logic block + matching delay in each stage
Latch Controller
ackN-1
ackN
reqN
reqN+1
delay
delay
delay
doneN
logic
logic
logic
Data Latch
Stage N-1
Stage N
Stage N+1
Logic Blocks: can use standard single-rail (non-hazard-free)
“Bundled Data” Requirement:
each “req” must arrive after data inputs valid and stable

8. Special Case: Using “Clocked Logic”
Clocked-CMOS = C2MOS: eliminate explicit latches
latch folded into logic itself
pull-up
network
pull-down
“keeper” En
A General C2MOS gate
logic
inputs
output
“keeper” En A B
logic
output
C2MOS AND-gate

9. Gate-Level MOUSETRAP: with C2MOS
Use C2MOS: eliminate explicit latches
New Control Optimization = “Dual-Rail XNOR”
eliminate 2 inverters from critical path
Latch Controller
ackN-1 2
ackN 2 2 2 2
En,En 2
doneN 2 2
(En,En’)
(done,done’)
(ack,ack’)
reqN
reqN+1
pair of
bit latches
C2MOS logic
Stage N-1
Stage N
Stage N+1

10. Complex Pipelining: Forks & Joins
Problems with Linear Pipelining:
handles limited applications; real systems are more complex
fork
join
Non-Linear Pipelining: has forks/joins
Contribution: introduce efficient circuit structures
Forks: distribute data + control to multiple destinations
Joins: merge data + control from multiple sources
Enabling technology for building complex async systems

11. Forks and Joins: Implementation
req
req2
Stage N C
req1
ack
req
ack2
Stage N C
ack1
Join: merge multiple requests
Fork: merge multiple acknowledges

12. Day/Woods (’97), and Charlie Boxes (’00)
Related Protocols
Day/Woods (’97), and Charlie Boxes (’00)
Similarities: all use…
transition signaling for handshakes
phase conversion for latch signals
Differences: MOUSETRAP has…
higher throughput
ability to handle fork/join datapaths
more aggressive timing, less insensitivity to delays

13. Performance, Timing and Optzn.
MOUSETRAP with Logic:
Stage Latency =
Cycle Time =
MOUSETRAP Using C2MOS Gates:
Stage Latency =
Cycle Time =

14. Timing Analysis Main Timing Constraint: avoid “data overrun”
Data must be safely “captured” by Stage N
before new inputs arrive from Stage N-1
simple 1-sided timing constraint: fast latch disable
Stage N’s “self-loop” faster than entire path through previous stage
Stage N
Data Latch
Latch Controller
doneN
logic
delay
Stage N-1
reqN
ackN-1
reqN+1
ackN

15. Timing Optzn: Reducing Cycle Time
Analytical Cycle Time =
Goal: shorten (in steady-state operation)
Steady-state = no undue pipeline congestion
Observation:
XNOR switches twice per data item:
only 2nd (up) transition critical for performance:
Solution: reduce XNOR output swing
degrade “slew” for start of pulse
allows quick pulse completion: faster rise time
Still safe when congested: pulse starts on time
pulse maintained until congestion clears

16. Timing Optzn (contd.) “optimized” XNOR output “unoptimized”
N “done”
N+1 “done”
“optimized”
XNOR output
latch only partly
disabled;
recovers quicker!
(no pulse width
requirement)
“unoptimized”
XNOR output
N’s latch
disabled
N’s latch
re-enabled

17. Comparison with Wave Pipelining
Two Scenarios:
Steady State:
both MOUSETRAP and wave pipelines act like transparent “flow through” combinational pipelines
Congestion:
right environment stalls: each MOUSETRAP stage safely captures data
internal stage slow: MOUSETRAP stages to its left safely capture data
 congestion properly handled in MOUSETRAP
Conclusion: MOUSETRAP has potential of…
speed of wave pipelining
greater robustness and flexibility

18. Timing Issues: Handling Wide Datapaths
Buffers inserted to amplify latch signals (En):
reqN
reqN+1
doneN
Stage N
Stage N-1 En
Reducing Impact of Buffers:
control uses unbuffered signals
 buffer delay off of critical path!
datapath skewed w.r.t. control
Timing assumption:
buffer delays roughly equal

19. Preliminary Results Pre-Layout Simulations of FIFO’s:
do not account for wire delays, parasitics, etc.
careful transistor sizing/verification of timing constraints

20. Conclusions and Future Work
Introduced a new asynchronous pipeline style:
Static logic blocks
Simple latches and control:
transparent latches, or C2MOS gates
single gate control = 1 XNOR gate/stage
Highly concurrent event-driven protocol
High throughputs obtained:
3.5 GHz in 0.25, 1.9 GHz in 0.6
comparable to wave pipelines; yet more robust/less design effort
Correctly handle forks and joins in datapaths
Timing constrains: local, 1-sided, easily met
Ongoing Work:
more realistic performance measurement (incl. parasitics)
layout and fabrication