Lec10 Multiple Clocks

8/8/2019 Lec10 Multiple Clocks

1/44

Copyright Bluespec, Inc., 2005

Bluespec SystemVerilog Training

Lecture 10: Multiple Clock Domains


2/44

Copyright Bluespec Inc. 2005 2

Lecture 10: Multiple Clock Domains

The Clocktype, and functions

Modules with different clocks

Clock families

Making clocks

Moving data across clock domains

Synchronizing interfaces


3/44


BSV point of view

Automate the simplest things

Make it easy to do simple things

Make it safe to do the more complicated things

Work with gated clocks, to enable powermanagement


4/44


The simplest case

Only one clock

Need never be mentioned in BSV source

(Note: hasnt been mentioned in any examples so far!)

Synthesized modules have an input port called CLK

This is passed to all interior instantiated modules


5/44


The Clocktype

Clock is an ordinary first-class type

May be passed as parameter, returned asresult of function, etc.

Can make arrays of them, etc.

Can test whether two clocks are equal

Clock c1;

Clock c = (b ? c1 : c2); // b must be known at compile time


6/44


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 reverse is true depends onimplementation librarytool doesnt care


7/44


A special clock

Each module has a special default clock

The default clock will be passed to any interior moduleinstantiations (unless otherwise specified)

It can be exposed by using the following module(defined in the Standard Prelude)

Usage (at top level of a module body):

module expose urrent lock ( lock) ;

lockc


8/44


Instantiating moduleswith non-default clocks

Example: instantiating a register with explicit clock

Note: also available in the shorthand form for module-instantiation

Modules can also take clocks as ordinary dynamicarguments, to be fed to interior module instantiations

(Examples later)

Clock c = ;

R g# (Bool) b


9/44


The clockOf() function

May be applied to any BSV expression, andreturns a value of type Clock

If the expression is a constant, the result is thespecial value noClock

The result is always well-defined

Expressions for which it would not be well-definedare illegal


10/44


The clockOf() function

Example

c, c1 and c2 are all equalThey may be used interchangeably for allpurposes

Reg# (UI t# (17))


11/44


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 theserelationships

Can be used to control static elaboration (e.g., to optionallyinsert or omit a synchronizer)


12/44


Clock family discipline

All the methods invoked by a rule (or byanother method) must be clocked by clocksfrom one family

The tool enforces this

There is no need for special domain-crossinglogic when the clocks involved are from the

same family Its all handled by implicit conditions


13/44


Clocks and implicit conditions

The gating condition of an Action orActionValue methods clock becomes one ofthe methods implicit conditions

So, if the clock is off, the method is unready

So, a rule can execute only if all the methods it useshave their clocks gated on

This doesnt happen for value methods So, they stay ready if they were ready when the

clock was switched off


14/44


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 whenthe clock was switched off

FIFO (Int (3)) f - mkFIFO (clocked by c);


15/44


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 methods 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 gatedon

If necessary, this is a new clock

The notional clock for a rule may be calculated in the same way


16/44


Making gated clocks

c0 is a version of the current clock, gated by b c0s gate is the gate of the current clock ANDed

with b

The current clock is an ancestor of c0

Bool b = ;

Clock c0


17/44


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


18/44


Other ways of making clocks

mkClockis a primitive for converting an ordinary signalinto a Clock, safely

new_cis a clock running at half the speed of thecurrent clock, and is gated by g

More precisely, its running at half the speed of the clock ofregister osc

Bool g = ; // gate conditionReg #(Bit #(1)) osc


19/44


More Clock constructors

mkAbsoluteClock (Integer start, Integer period);

mkClock

(Bit#(1) osc, Bool gate)

mkGatedClock (Bool newCond)

mkClockDivider #(Integer divider) ( Clock clkin )


20/44


Moving Data Across Clock Domains

Data moved across clock domains appearsasynchronous to the receiving (destination)domain

Asynchronous data will cause meta-stabilityThe only safe way: use a synchronizer

clk

d

q Meta-stable data

Set l vi lati n


21/44


Synchronizers

Good synchronizer design and use reduces theprobability of observing meta-stable data

Synchronizers needed for all crossings

Bluespec delivers conservative (speedindependent) synchronizers

User can define and use new synchronizers

Bluespec does not allow unsynchronizedcrossings (compiler static checking error)


22/44


2 - Flop Synchronizer

Most common type of(bit) synchronizer

FF1 will go meta-stable, but FF2 does not look at datauntil 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 sametime

sClk dClk

sDIN dD_OUTFF0 FF1 FF2


23/44


Bluespecs 2-Flop Synchronizer

Synchronizer design guidelines are followed andcannot be violated

No logic between FF0 and FF1

No access to FF1s output

sClk dClk

send() read()FF0 FF1 FF2

mkSyncBit

interface SyncBitIfc ;

method Action send ( Bit#(1) bitData ) ;

method Bit#(1) read () ;

endinterface


24/44


Small Example

Up/down counter, where direction signal comes fromseparate domain.

Registers:

Reg# (Bit#(1)) u _down_bit


25/44


26/44


Full Example

module mkTo Level( Clock readClk, Reset readRst, To ifc );

Reg# (Bit# (1)) u _down_bit


27/44


Other Synchronizers

Pulse Synchronizer

Word Synchronizer

FIFO Synchronizer

Asynchronous RAMNull Synchronizer

Reset Synchronizers

Documented in Reference Guide


28/44


Pulse Synchronizer

Synchronizes single clock width pulses

interface SyncPulseIfc ;

method Action send () ;

method Bool pulse() ;endinterface

Send()

pulse()

sClk

dClk


29/44


30/44


Handshake Pulse

A Pulse Synchronizer with an added handshakeprotocol

The send method is ready after the pulse is

received and an acknowledge returned.Also called double-stage

Latency:

send to read is (2*dstClk)

send to next send (2*dstClks+ 2*srcClk)

Details in Reference Guide


31/44


Register/Word Synchronizer

Uses common Reg#(a) interface

However, write method has (implicit) ready

condition, to allow time for data to be received

No guarantee that destination reads the data,only that it arrives


32/44


FIFO Synchronizer

Good for data buffering between clock domains

Usual FIFO interface (without a clear method)


33/44


A Larger Example

interface WordReader;

...

method Bit#( 2) wordOut () ;

method Bool pulseOut() ; // Pulses at new data

endinterface

interface WordCruncher;method Action crunch( Bit#( 2) dataRead ) ;

...

endinterface

WordReaderreader


34/44


Using Word Synchronizer

Data loss possible if _write method of sync notready when pulse occurs

No guarantee that wrd_crunch sees data

Reg# (Bit# ( 2)) sync


35/44


Using FIFO Synchronizer

Data loss still possible, will need tochange reader type

SyncFIFOIfc# (Bit# ( 2)) sync_fifo


36/44


Advantages of Bluespecs synchronizers

Bluespec provides a full set of speed-independent data synchronizers, with stronginterface semantics preventing their misuse

But good design practices are still needed


37/44


Some Good Multi-Clock Design Practices

Identify different clock domains early in design

Partition design such that there is one clock

per module

Keep the synchronizations to the interfaces

Limit number of signals which cross clockdomains


38/44


Specialized Synchronizers

(Topic for Advanced Training)

Above synchronizers work for any clock relations

If there are known relations between clock edges, thensynchronizer can be removed

Bluespec provides some synchronizers for clocks withcoincident edges, e.g., divided clocks.

Users can create their own synchronizers or importtheir current ones into Bluespec


39/44


Synchronizing Interfaces

The previous examples show a hardwareapproach to clock-domain crossing:

Designers instantiate a module having differentclocks for different methods, and connect it upexplicitly

E.g. a FIFOwith enq and deq on different clocks


40/44



BSV also has an alternative linguisticapproach, to convert an interface from oneclock domain to another

mkConverter converts an existing interface toanother one of the same type, but on different clock

In this style, more of the details are implicit


41/44



oldIfcis clocked by c0

newIfcis clocked by the current clock

4 is a parameter for the conversion(the depth of the FIFO)

newIfccan be used exactly as oldIfc,but in the current clock domain

typedef Server#(QueryType,RespType) IfcType;

...

IfcType oldIfc


42/44



Not all interfaces are convertible The following are defined to be convertible in the

BSV library

Get and Put interfaces

Client and Server interfaces Tuples of convertible interfaces

Convertible interfaces form a typeclass

ClockConv Other instances can be added by the user

Need only to define mkConverter, in terms of existingprimitives


43/44


Summary

The Clocktype, and strong type checking ensures that all circuits

are clocked by actual clocksBSV provides ways to create, derive and manipulate clocks, safely

BSV clocks are gated, and gating fits into Rule-enabling semantics

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

Roadmap: tool will generate SDC constraints identifying all clocks,clocks associated with signals, false paths at clock-domaincrossings, etc.


44/44

C i ht Bl I 2005

End of Lecture

Documents

Lec10 Multiple Clocks