Asynchronous {Pipelines, dataflow}Honors Discussion #5EECS 150 Spring 2010Chris W. Fletcher1UCB EECS150 Spring 2010, Honors #5Today• HSRA commentary• Clocking• Synchronizers• Dataflow in asynchronous systems2UCB EECS150 Spring 2010, Honors #5Big Picture• Last week: Synchronous pipelines & data transactions• This week: Asynchronous pipelines& data transactions• Next week: {Synchronous, Asynchronous} FIFOs3UCB EECS150 Spring 2010, Honors #5Clocking Basics 1• A clock signalUCB EECS150 Spring 2010, Honors #5 4Clocking Basics 2• A clock signal• Setup timeUCB EECS150 Spring 2010, Honors #5 5tsetupClocking Basics 3• A clock signal• Setup time• Hold timeUCB EECS150 Spring 2010, Honors #5 6tsetup tholdClocking Basics 4• A clock signal• Setup time• Hold time• clkQUCB EECS150 Spring 2010, Honors #5 7tsetup tholdtclkQClocking Basics 5Quiz: Can tsetup or thold to be negative?UCB EECS150 Spring 2010, Honors #5 8thold tsetuptclkQ• tsetup < 0: D can change after the clock edge and the new D will be recognized• thold < 0: D can change before the clock edge and the old D will be recognizedWhat about clkQ?Metastability 1• What happens when tsetup or thold are violated?UCB EECS150 Spring 2010, Honors #5 9tsetupmetastable resolutionoutinActiveActive???• Output unknown(somewhere between 0 and 1)… until “resolution” occursat which point “out” could be either 0 or 1!Metastability 2• When can tsetup or thold be violated?UCB EECS150 Spring 2010, Honors #5 10• One ClockDesign doesn’t meet timing(You have bigger problems)tsetup Logic• Two Clocks: different frequenciesWill almost always cause violationsThought Q: Exceptions to this?tsetup tclkQtclkQ???• Two Clocks: phase offsetMay or may not cause violationstsetup tsetup tclkQMetastability 3• Resolution must occur within trUCB EECS150 Spring 2010, Honors #5 11tr = tp – tclkQ-tcl - tsut s e t u pt pt c l k Qt c lt r• Good news: chance to leave metastability increases exponentially with time• Bad news:synchronization failure means… circuit failureSynchronizers 1• First flip-flop absorbs metastabilityUCB EECS150 Spring 2010, Honors #5 12Clock AClock BInputClock Domain A Clock Domain BLevel SynchronizerOutput1 2 3• Second flip-flop protects downstream logictr = tp – tclkQ- tsuSynchronizers 2• How can we do better? Increase trUCB EECS150 Spring 2010, Honors #5 13Clock AClock BInputClock Domain A Clock Domain BReliable SynchronizerOutput1 2 32+ Stage Shift Registertr = Nx(tp – tclkQ- tsu)Synchronizers 3• Another “reliable synchronizer”UCB EECS150 Spring 2010, Honors #5 14tr = Nxtp – tclkQ- tsuC lo ck AC lo ck BI np utR el ia bl e Sy nc hr on iz erO ut pu t1 2 3C lo ck D om ai n BC lo ck D om ai n ACloc k Di vi de r (b y N)Synchronizers 4• Synchronizer cost…– Area (but not much)– Cycle DelayUCB EECS150 Spring 2010, Honors #5 15• Where does this matter?Handshaking• Case Study:Asynchronous FIFOsAsynchronous Pipelines 1• Recall… the FIFO interface that we call Ready/ValidValidReady16UCB EECS150 Spring 2010, Honors #5• This worked in a single clock domain…• Why?ReadyValidClock1+ 1+ 1 0+Transfers @ edge, both parties see change at the same timeAsynchronous Pipelines 2• What happens in two clock domains?UCB EECS150 Spring 2010, Honors #5 17ValidReadyClock A Clock BData• First: we must avoid metastability. Ideas?Asynchronous Pipelines 3• Step #1: Add synchronizers (prevents metastability)UCB EECS150 Spring 2010, Honors #5 18ValidClock A Clock BClock A Clock BClock BClock AReadyAsynchronous Pipelines 4• Step #1: Add synchronizers (prevents metastability)UCB EECS150 Spring 2010, Honors #5 19ValidClock A Clock BClock A Clock BClock BClock AReadyDataData• Step #2: Add a hold register (does this help here?)Aside: Why not push data through parallel synchronizers?This still doesn’t work!Asynchronous Pipelines 5• Problem: – It takes multiple cycles for a message from the receiver to reach the senderUCB EECS150 Spring 2010, Honors #5 20• Solution– Add buffering to the receiver– Add “almost full” like in lecture• Why do we care? – What happens whenthe receiver says “stop?”(i.e. DataInReady = 0)ReadyValidClockSynchronizer delayWe wantWe getAsynchronous Pipelines 6• “Almost full” gives sender time to stopUCB EECS150 Spring 2010, Honors #5 21ValidClock A Clock BClock A Clock BClock BClock AReadyDataDataDataDataData• Same idea as what you saw in lecture• What is the receiver starting to look a lot like?Homework• Thought problem– Based on what you have seen in lecture & today:Draw a block diagram for a synchronous FIFO– (More) reading will be postedUCB EECS150 Spring 2010, Honors #5 22Acknowledgements & ContributorsSlides developed by Chris Fletcher (2/2010).This work is based on ideas and discussions with:Ilia Lebedev, Greg Gibeling, John Wawrzynek, Krste Asanovic, and other fellow Spring 2009 CS294-48 studentsThis work has been used by the following courses:– UC Berkeley CS150 (Spring 2010): Components and Design Techniques for Digital Systems 23UCB EECS150 Spring 2010, Honors
View Full Document
Unlocking...