Multiple Clock Domains (MCD) Continued … Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology November.

Slides:



Advertisements
Similar presentations
Simulation executable (simv)
Advertisements

Lab 9: Matrix Keypad : ”No Key Press” Analysis Slide #2 Slide #3 ”Press and Hold Key 5” Analysis.
Synchronous Sequential Logic
Table 7.1 Verilog Operators.
An EHR based methodology for Concurrency management Arvind (with Asif Khan) Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology.
March, 2007http://csg.csail.mit.edu/arvind802.11a-1 Architectural Exploration: Area-Performance tradeoff in a Transmitter Arvind Computer Science.
ENGIN112 L20: Sequential Circuits: Flip flops October 20, 2003 ENGIN 112 Intro to Electrical and Computer Engineering Lecture 20 Sequential Circuits: Flip.
Embedded Systems Hardware:
CS 151 Digital Systems Design Lecture 20 Sequential Circuits: Flip flops.
ENGIN112 L26: Shift Registers November 3, 2003 ENGIN 112 Intro to Electrical and Computer Engineering Lecture 26 Shift Registers.
111/9/2005EE 108A Lecture 13 (c) 2005 W. J. Dally EE108A Lecture 13: Metastability and Synchronization Failure (or When Good Flip-Flops go Bad)
Asynchronous Pipelines: Concurrency Issues Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology October 13, 2009http://csg.csail.mit.edu/koreaL12-1.
September 24, L08-1 IP Lookup: Some subtle concurrency issues Arvind Computer Science & Artificial Intelligence Lab.
December 10, 2009 L29-1 The Semantics of Bluespec Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute.
Rabie A. Ramadan Lecture 3
March 4, 2009L13-1http://csg.csail.mit.edu/6.375 Multiple Clock Domains Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of.
September 3, 2009L02-1http://csg.csail.mit.edu/korea Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial.
Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
SEQUENTIAL CIRCUITS Component Design and Use. Register with Parallel Load  Register: Group of Flip-Flops  Ex: D Flip-Flops  Holds a Word of Data 
Multiple Clock Domains (MCD) Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology March 15, 2010.
March, 2007Intro-1http://csg.csail.mit.edu/arvind Design methods to facilitate rapid growth of SoCs Arvind Computer Science & Artificial Intelligence Lab.
1 COMP541 Sequential Circuits Montek Singh Feb 1, 2012.
March 6, 2006http://csg.csail.mit.edu/6.375/L10-1 Bluespec-4: Rule Scheduling and Synthesis Arvind Computer Science & Artificial Intelligence Lab Massachusetts.
IT253: Computer Organization Lecture 9: Making a Processor: Single-Cycle Processor Design Tonga Institute of Higher Education.
Constructive Computer Architecture: Guards Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology September 24, 2014.
Constructive Computer Architecture Sequential Circuits Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology
The UNIVERSITY of NORTH CAROLINA at CHAPEL HILL State Machines Anselmo Lastra.
September 8, 2009http://csg.csail.mit.edu/koreaL03-1 Combinational Circuits in Bluespec Arvind Computer Science & Artificial Intelligence Lab Massachusetts.
Constructive Computer Architecture Tutorial 4: Running and Debugging SMIPS Andy Wright TA October 10, 2014http://csg.csail.mit.edu/6.175T04-1.
Constructive Computer Architecture Sequential Circuits Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology September.
Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
Constructive Computer Architecture Sequential Circuits - 2 Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
Chapter 1_0 Registers & Register Transfer. Chapter 1- Registers & Register Transfer  Chapter 7 in textbook.
CS151 Introduction to Digital Design Chapter 5: Sequential Circuits 5-1 : Sequential Circuit Definition 5-2: Latches 1Created by: Ms.Amany AlSaleh.
ACCESS IC LAB Graduate Institute of Electronics Engineering, NTU 99-1 Under-Graduate Project Design of Datapath Controllers Speaker: Shao-Wei Feng Adviser:
REGISTER TRANSFER LANGUAGE (RTL) INTRODUCTION TO REGISTER Registers1.
March 1, 2006http://csg.csail.mit.edu/6.375/L09-1 Bluespec-3: Architecture exploration using static elaboration Arvind Computer Science & Artificial Intelligence.
Introduction to Bluespec: A new methodology for designing Hardware Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology.
RTL Hardware Design by P. Chu Chapter 9 – ECE420 (CSUN) Mirzaei 1 Sequential Circuit Design: Practice Shahnam Mirzaei, PhD Spring 2016 California State.
Counters and registers Eng.Maha Alqubali. Registers Registers are groups of flip-flops, where each flip- flop is capable of storing one bit of information.
6.375 Tutorial 3 Scheduling, Sce-Mi & FPGA Tools Ming Liu
Multiple Clock Domains (MCD) Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology.
Computer Architecture: A Constructive Approach Bluespec execution model and concurrent rule scheduling Teacher: Yoav Etsion Taken (with permission) from.
October 20, 2009L14-1http://csg.csail.mit.edu/korea Concurrency and Modularity Issues in Processor pipelines Arvind Computer Science & Artificial Intelligence.
1 COMP541 Sequential Logic – 2: Finite State Machines Montek Singh Feb 29, 2016.
Overview Logistics Last lecture Today HW5 due today
Introduction to Bluespec: A new methodology for designing Hardware
Introduction to Bluespec: A new methodology for designing Hardware
REGISTER TRANSFER LANGUAGE (RTL)
Clocks A clock is a free-running signal with a cycle time.
Folded Combinational Circuits as an example of Sequential Circuits
Scheduling Constraints on Interface methods
Sequential Circuits - 2 Constructive Computer Architecture Arvind
Sequential Circuits Constructive Computer Architecture Arvind
Sequential Circuits: Constructive Computer Architecture
ECE Digital logic Lecture 16: Synchronous Sequential Logic
Stmt FSM Arvind (with the help of Nirav Dave)
Clock Domain Crossing Keon Amini.
Combinational Circuits in Bluespec
Multirule Systems and Concurrent Execution of Rules
Constructive Computer Architecture: Guards
Sequential Circuits Constructive Computer Architecture Arvind
How does the CPU work? CPU’s program counter (PC) register has address i of the first instruction Control circuits “fetch” the contents of the location.
Modules with Guarded Interfaces
Sequential Circuits - 2 Constructive Computer Architecture Arvind
Introduction to Bluespec: A new methodology for designing Hardware
Stmt FSM Arvind (with the help of Nirav Dave)
Multiple Clock Domains
Constructive Computer Architecture: Guards
Introduction to Bluespec: A new methodology for designing Hardware
Presentation transcript:

Multiple Clock Domains (MCD) Continued … Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology November 12, 2009L21-1

Multiple Clock Domains in Bluespec The Clock type, and functions √ Clock families  Making clocks Moving data across clock domain Revisit the a Transmitter November 12, 2009L21-2

The Clock type Conceptually, a clock consists of two signals an oscillator a gating signal In general, implemented as two wires If ungated, oscillator is running Whether the oscillator is running when it is gated off depends on implementation library—tool doesn’t care November 12, 2009L21-3

BSV clock Often, big circuits do not do useful work until some boolean condition holds We can save power by combining the boolean condition with the clock (i.e. clock gating) Big Circuit clk input g g f f gating signal “BSV Clock” November 12, 2009L21-4

Clock families All clocks in a “family” share the same oscillator They differ only in gating If c2 is a gated version of c1, we say c1 is an “ancestor” of c2 If some clock is running, then so are all its ancestors The functions isAncestor(c1,c2) and sameFamily(c1,c2) are provided to test these relationships Can be used to control static elaboration (e.g., to optionally insert or omit a synchronizer) November 12, 2009L21-5

Clock family discipline All the methods invoked by a rule (or by another method) must be clocked by clocks from one family The tool enforces this The rule will fire only when the clocks of all the called methods are ready (their gates are true) Two different clock families can interact with each other only though some clock synchronizing state element, e.g., FIFO, register November 12, 2009L21-6

Clocks and implicit conditions Each action is implicitly guarded by its clock’s gate; this will be reflected in the guards of rules and methods using that action So, if the clock is off, the method is unready So, a rule can execute only if all the methods it uses have their clocks gated on This doesn’t happen for value methods So, they stay ready if they were ready when the clock was switched off November 12, 2009L21-7

Clocks and implicit conditions Example: If c is switched off: f.enq, f.deq and f.clear are unready f.first remains ready if the fifo was non- empty when the clock was switched off FIFO #(Int #(3)) f <- mkFIFO (clocked_by c); November 12, 2009L21-8

The clocks of methods and rules Every method, and every rule, has a notional clock For methods of primitive modules (Verilog wrapped in BSV): Their clocks are specified in the BSV wrappers which import them For methods of modules written in BSV: A method’s clock is a clock from the same family as the clocks of all the methods that it, in turn, invokes The clock is gated on if the clocks of all invoked methods are gated on If necessary, this is a new clock The notional clock for a rule may be calculated in the same way November 12, 2009L21-9

Multiple Clock Domains in Bluespec The Clock type, and functions √ Clock families √ Making clocks  Moving data across clock domain Revisit the a Transmitter November 12, 2009L

Making gated clocks c0 is a version of the current clock, gated by b c0’s gate is the gate of the current clock AND’ed with b The current clock is an ancestor of c0 Bool b = … ; Clock c0 <- mkGatedClock (b); November 12, 2009L

Making gated clocks c1 is a version of c0, gated by b1 and is also a version of the current clock, gated by (b && b1) current clock, c0 and c1 all same family current clock and c0 both ancestors of c1 Bool b = … ; Clock c0 <- mkGatedClock (b); Bool b1 = …; Clock c1 <- mkGatedClock (b1, clocked_by c0); November 12, 2009L

More Clock constructors mkGatedClock (Bool newCond) mkAbsoluteClock (Integer start, Integer period); mkClockDivider #(Integer divider) ( ClockDividerIfc clks ) November 12, 2009L

Clock Dividers interface ClockDividerIfc ; interface Clock fastClock ; // original clock interface Clock slowClock ; // derived clock method Bool clockReady ; endinterface module mkClockDivider #( Integer divisor ) ( ClockDividerIfc ifc ) ; Divisor = 3 Fast CLK Slow CLK CLK rdy November 12, 2009L

Clock Dividers No need for special synchronizing logic The clockReady signal can become part of the implicit condition when needed November 12, 2009L

Multiple Clock Domains in Bluespec The Clock type, and functions √ Clock families √ Making clocks √ Moving data across clock domains  Revisit the a Transmitter November 12, 2009L

Moving Data Across Clock Domains Data moved across clock domains appears asynchronous to the receiving (destination) domain Asynchronous data will cause meta-stability The only safe way: use a synchronizer clk d q Meta-stable data Setup & hold violation November 12, 2009L

Synchronizers Good synchronizer design and use reduces the probability of observing meta-stable data Bluespec delivers conservative (speed independent) synchronizers User can define and use new synchronizers Bluespec does not allow unsynchronized crossings (compiler static checking error) November 12, 2009L

2 - Flop BIT-Synchronizer Most common type of (bit) synchronizer FF1 will go meta-stable, but FF2 does not look at data until a clock period later, giving FF1 time to stabilize Limitations: When moving from fast to slow clocks data may be overrun Cannot synchronize words since bits may not be seen at same time sClkdClk sDINdD_OUT FF0 FF1FF2 November 12, 2009L

Bluespec’s 2-Flop Bit-Synchronizer The designer must follow the synchronizer design guidelines: No logic between FF0 and FF1 No access to FF1’s output sClkdClk send()read() FF0 FF1FF2 mkSyncBit interface SyncBitIfc ; method Action send ( Bit#(1) bitData ) ; method Bit#(1) read () ; endinterface November 12, 2009L

Use example: MCD Counter Up/down counter: Increments when up_down_bit is one; the up_down_bit is set from a different clock domain. Registers: Reg# (Bit#(1)) up_down_bit <- mkReg(0, clocked_by ( writeClk ) ); Reg# (Bit# (32)) cntr <- mkReg(0); // Default Clk The Rule (attempt 1): rule countup ( up_down_bit == 1 ) ; cntr <= cntr + 1; endrule Illegal Clock Domain Crossing November 12, 2009L

Adding the Synchronizer SyncBitIfc sync <- mkSyncBit( writeClk, writeRst, currentClk ) ; rule transfer ( True ) ; sync.send ( up_down_bit ); endrule rule countup ( sync.read == 1 ) ; cntr <= cntr + 1; endrule clocked by writeClk clocked by currentClk Split the rule into two rules where each rule operates in one clock domain November 12, 2009L

MCD Counter module mkTopLevel#(Clock writeClk, Reset writeRst) (Top ifc); Reg# (Bit# (1)) up_down_bit <- mkReg(0, clocked_by(writeClk), reset_by(writeRst)) ; Reg# (Bit# (32)) cntr <- mkReg (0) ; // Default Clocking Clock currentClk <- exposeCurrentClock ; SyncBitIfc sync <- mkSyncBit ( writeClk, writeRst, currentClk ) ; rule transfer ( True ) ; sync.send( up_down_bit ); endrule rule countup ( sync.read == 1 ) ; cntr <= cntr + 1; endrule We won’t worry about resets for the rest of this lecture November 12, 2009L

Different Synchronizers Bit Synchronizer FIFO Synchronizer Pulse Synchronizer Word Synchronizer Asynchronous RAM Null Synchronizer Reset Synchronizers Documented in Reference Guide November 12, 2009L

Multiple Clock Domains in Bluespec The Clock type, and functions √ Clock families √ Making clocks √ Moving data across clock domains √ Revisit the a Transmitter  November 12, 2009L

Transmitter Overview ControllerScramblerEncoderInterleaverMapper IFFT Cyclic Extend headers data Clock speed f f/13 f/52 November 12, 2009L

The Transmitter without MCD module mkTransmitter(Transmitter#(24,81)); let controller <- mkController(); let scrambler <- mkScrambler_48(); let conv_encoder <- mkConvEncoder_24_48(); let interleaver <- mkInterleaver(); let mapper <- mkMapper_48_64(); let ifft <- mkIFFT_Pipe(); let cyc_extender <- mkCyclicExtender(); // rules to stitch these modules together How should we 1. Generate different clocks? 2. Pass them to modules? 3. Introduce clock synchronizers and fix the rules? November 12, 2009L

Step 1: Introduce Clocks module mkTransmitter(Transmitter#(24,81));... let controller <- mkController(); let scrambler <- mkScrambler_48(); let conv_encoder <- mkConvEncoder_24_48(); let interleaver <- mkInterleaver(); let mapper <- mkMapper_48_64(); let ifft <- mkIFFT_Pipe(); let cyc_extender <- mkCyclicExtender(); // rules to stitch these modules together let clockdiv13 <- mkClockDivider(13); let clockdiv52 <- mkClockDivider(52); let clk13 = clockdiv13.slowClock; let clk52 = clockdiv52.slowClock; November 12, 2009L

Step 2: Pass the Clocks module mkTransmitter(Transmitter#(24,81)); let clockdiv13 <- mkClockDivider(13); let clockdiv52 <- mkClockDivider(52); let clk13 = clockdiv13.slowClock; let clk52 = clockdiv52.slowClock; let controller <- mkController(clocked_by clk13); let scrambler <- mkScrambler_48(clocked_by clk13); let conv_encoder <- mkConvEncoder_24_48(clocked_by clk13); let interleaver <- mkInterleaver(clocked_by clk13); let mapper <- mkMapper_48_64(clocked_by clk13); let ifft <- mkIFFT_Pipe(); let cyc_extender <- mkCyclicExtender(clocked_by clk52); // rules to stitch these modules together Default Clock Now some of the stitch rules have become illegal because they call methods from different clock families Introduce Clock Synchronizers November 12, 2009L

Step 3: Introduce Clock Synchronizers module mkTransmitter(Transmitter#(24,81)); let m2ifftFF <- mkSyncFIFOToFast(2,clockdiv13); let ifft2ceSF <- mkSyncFIFOToSlow(2,clockdiv52); … let mapper <- mkMapper_48_64(clocked_by clk13); let ifft <- mkIFFT_Pipe(); let cyc_extender <- mkCyclicExtender(clocked_by clk52); rule mapper2fifo(True); //split mapper2ifft rule stitch(mapper.toIFFT, m2ifftFF.enq); endrule rule fifo2ifft(True); stitch(pop(m2ifftFF), ifft.fromMapper); endrule rule ifft2fifo(True); //split ifft2ce rule stitch(ifft.toCycExtend, ifft2ceFF.enq); endrule rule fifo2ce(True); stitch(pop(ifft2ceFF), cyc_extender.fromIFFT); endrule November 12, 2009L

The Transmitter (after) module mkTransmitter(Transmitter#(24,81)); let clockdiv13 <- mkClockDivider(13); let clockdiv52 <- mkClockDivider(52); let clk13th = clockdiv13.slowClock; let clk52nd = clockdiv52.slowClock; let m2ifftFF <- mkSyncFIFOToFast(2,clockdiv13); let ifft2ceSF <- mkSyncFIFOToSlow(2,clockdiv52); let controller <- mkController(clocked_by clk13th); let scrambler <- mkScrambler_48(… " …); let conv_encoder <- mkConvEncoder_24_48 (… " …); let interleaver <- mkInterleaver (… " …); let mapper <- mkMapper_48_64 (… " …); let ifft <- mkIFFT_Pipe(); let cyc_extender <- mkCyclicExtender(clocked_by clk52nd, …); rule controller2scrambler(True); stitch(controller.getData, scrambler.fromControl); endrule rule mapper2fifo(True); stitch(mapper.toIFFT, m2ifftFF.enq); Endrule rule fifo2ifft(True); stitch(pop(m2ifftFF), ifft.fromMapper); endrule Synchronizers for clock domain crossing? November 12, 2009L

Did not work... bsc -u -verilog Transmitter.bsv Error: "./Interfaces.bi", line 62, column 15: (G0045) Method getFromMAC is unusable because it is connected to a clock not available at the module boundary. Need to fix the Transmitter’s interface so that the outside world knows about the clocks that the interface methods operate on. (These clocks were defined inside the module) November 12, 2009L

The Fix – pass the clocks out interface Transmitter#(type inN, type out); method Action getFromMAC(TXMAC2ControllerInfo x); method Action getDataFromMAC(Data#(inN) x); method ActionValue#(MsgComplexFVec#(out)) toAnalogTX(); interface Clock clkMAC; interface Clock clkAnalog; endinterface November 12, 2009L

Summary The Clock type, and type checking ensures that all circuits are clocked by actual clocks BSV provides ways to create, derive and manipulate clocks, safely BSV clocks are gated, and gating fits into Rule- enabling semantics (clock guards) BSV provides a full set of speed-independent data synchronizers, already tested and verified The user can define new synchronizers BSV precludes unsynchronized domain crossings November 12, 2009L