Bluespec SystemVerilog™ Training

Lecture 10: Multiple Clock Domains

Copyright © Bluespec, Inc., 2005

Lecture 10: Multiple Clock Domains

The Clock type, and functions

Modules with different clocks

Clock families

Making clocks

Moving data across clock domains

Synchronizing interfaces

Copyright © Bluespec Inc. 2005 2

 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 power

management

Copyright © Bluespec Inc. 2005 3

 The simplest case

Only one clock

Need never be mentioned in BSV source


(Note: hasn’t been mentioned in any examples so far!)

Synthesized modules have an input port called CLK

This is passed to all interior instantiated modules

Copyright © Bluespec Inc. 2005 4

 The Clock type
Clock is an ordinary first-class type

May be passed as parameter, returned as

result 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

Copyright © Bluespec Inc. 2005 5
 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 on
implementation library—tool doesn’t care

Copyright © Bluespec Inc. 2005 6

 A special clock
Each module has a special “default” clock

The default clock will be passed to any interior module

instantiations (unless otherwise specified)

It can be exposed by using the following module

(defined in the Standard Prelude)

module exposeCurrentClock (Clock) ;

Usage (at top level of a module body):

Clock c <- exposeCurrentClock;

Copyright © Bluespec Inc. 2005 7

 Instantiating modules
with non-default clocks
Example: instantiating a register with explicit clock

Clock c = … ;
Reg# (Bool) b <- mkReg # (True, clocked_by c);

Note: also available in the shorthand form for module-

instantiation

Modules can also take clocks as ordinary dynamic

arguments, to be fed to interior module instantiations

(Examples later)

Copyright © Bluespec Inc. 2005 8

 The clockOf() function

May be applied to any BSV expression, and

returns a value of type Clock

If the expression is a constant, the result is the

special value noClock

The result is always well-defined


Expressions for which it would not be well-defined
are illegal

Copyright © Bluespec Inc. 2005 9

 The clockOf() function

Example

Reg# (UInt# (17)) x <- mkReg (0, clocked_by c);

let y = x + 2;
Clock c1 = clockOf (x);
Clock C2 = clockOf (y);

c, c1 and c2 are all equal

They may be used interchangeably for all
purposes

Copyright © Bluespec Inc. 2005 10

 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)

Copyright © Bluespec Inc. 2005 11

 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

There is no need for special domain-crossing

logic when the clocks involved are from the
same family

It’s all handled by implicit conditions

Copyright © Bluespec Inc. 2005 12

 Clocks and implicit conditions

The gating condition of an Action or

ActionValue method’s clock becomes one of
the method’s implicit conditions

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

Copyright © Bluespec Inc. 2005 13

 Clocks and implicit conditions

Example:

FIFO #(Int #(3)) f <- mkFIFO (clocked_by c);

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

Copyright © Bluespec Inc. 2005 14

 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

Copyright © Bluespec Inc. 2005 15

 Making gated clocks

Bool b = … ;
Clock c0 <- mkGatedClock ( b);

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

Copyright © Bluespec Inc. 2005 16

 Making gated clocks
Bool b = … ;
Clock c0 <- mkGatedClock ( b);

Bool b1 = …;
Clock c1 ();
mkGatedClock g1 (b1, c1, clocked_by c0);

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

Copyright © Bluespec Inc. 2005 17

 Other ways of making clocks
Bool g = … ; // gate condition
Reg #(Bit #(1)) osc <- mkReg (0);
rule oscillate;
osc <= invert (osc);
endrule
Clock new_c <- mkClock (osc, g);

mkClock is a primitive for converting an ordinary signal

into a Clock, safely

new_c is a clock running at half the speed of the

current clock, and is gated by g

More precisely, it’s running at half the speed of the clock of
register osc
Copyright © Bluespec Inc. 2005 18
 More Clock constructors
mkAbsoluteClock

(Integer start, Integer period);

mkClock

(Bit#(1) osc, Bool gate)

mkGatedClock

(Bool newCond)

mkClockDivider

#(Integer divider) ( Clock clkin )

Copyright © Bluespec Inc. 2005 19

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

Setup & hold violation

d

q Meta-stable data
Copyright © Bluespec Inc. 2005 20
 Synchronizers

Good synchronizer design and use reduces the

probability of observing meta-stable data
Synchronizers needed for all crossings

Bluespec delivers conservative (speed

independent) synchronizers
User can define and use new synchronizers
Bluespec does not allow unsynchronized
crossings (compiler static checking error)

Copyright © Bluespec Inc. 2005 21

 2 - Flop 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

sDIN FF0 dD_OUT

FF1 FF2

sClk dClk

Copyright © Bluespec Inc. 2005 22

 Bluespec’s 2-Flop Synchronizer
mkSyncBit

send() FF0 read()

FF1 FF2

sClk dClk

interface SyncBitIfc ;
method Action send ( Bit#(1) bitData ) ;
method Bit#(1) read () ;
endinterface

Synchronizer design guidelines are followed and

cannot be violated

No logic between FF0 and FF1

No access to FF1’s output

Copyright © Bluespec Inc. 2005 23

 Small Example

Up/down counter, where direction signal comes from

separate domain.
Registers:

Reg# (Bit#(1)) up_down_bit <- mkReg(0, clocked_by ( readClk ) );

Reg# (Bit# (32)) cntr <- mkReg(0); // Default Clk

The Rule (attempt 1):

c k
C lo i ng
rule countup ( up_down_bit == 1 ) ;
a l s s
eg ro
cntr <= cntr + 1;
Ill C
endrule ain
o m
D
Copyright © Bluespec Inc. 2005 24
 Adding the Synchronizer

SyncBitIfc sync <- mkSyncBit( readClk, readRst, currentClk ) ;

rule transfer ( True ) ;

sync.send ( up_down_bit );
endrule

rule countup ( sync.read == 1 ) ;

cntr <= cntr + 1;
endrule

Copyright © Bluespec Inc. 2005 25

 Full Example
module mkTopLevel( Clock readClk, Reset readRst, Top ifc );

Reg# (Bit# (1)) up_down_bit <- mkReg(0, clocked_by( readClk ),

reset_by( readRst) ) ;

Reg# (Bit# (32)) cntr <- mkReg (0 ) ; // Default Clocking

Clock currentClk <- exposeCurrentClock ;

SyncBitIfc sync <- mkSyncBit ( readClk, readRst, currentClk ) ;

rule transfer ( True ) ;

sync.send( up_down_bit );
endrule

rule countup ( sync.read == 1 ) ;

cntr <= cntr + 1;
endrule

Copyright © Bluespec Inc. 2005 26

 Other Synchronizers

Pulse Synchronizer
Word Synchronizer
FIFO Synchronizer
Asynchronous RAM
Null Synchronizer
Reset Synchronizers

Documented in Reference Guide

Copyright © Bluespec Inc. 2005 27

 Pulse Synchronizer

Synchronizes single clock width pulses

interface SyncPulseIfc ;
method Action send () ;
method Bool pulse() ;
endinterface

sClk

Send()

dClk

pulse()

Copyright © Bluespec Inc. 2005 28

 Pulse Synchronizer

module mkSyncPulse (Clock sClkIn, Reset sRstIn,

Clock dClkIn,
SyncPulseIfc ifc ) ;

But two “send”s may not be seen if they occur

too close together (faster than 2*dstClk)

Copyright © Bluespec Inc. 2005 29

 Handshake Pulse

A Pulse Synchronizer with an added handshake

protocol
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

Copyright © Bluespec Inc. 2005 30

 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

Copyright © Bluespec Inc. 2005 31

 FIFO Synchronizer

Good for data buffering between clock domains

Usual FIFO interface (without a clear method)

Copyright © Bluespec Inc. 2005 32

 A Larger Example
interface WordReader ;
...
method Bit#(32) wordOut () ;
method Bool pulseOut() ; // Pulses at new data
endinterface

interface WordCruncher ;
method Action crunch( Bit#(32) dataRead ) ;
...
endinterface

WordReader reader <- mkWordReader (

Objective: Connect clocked_by( readClk ),
wordOut with reset_by( readRst ) ) ;
crunch.
WordCruncher wrd_crunch <- mkWordCrunch;

Copyright © Bluespec Inc. 2005 33

 Using Word Synchronizer

Reg# (Bit# (32)) sync <- mkSyncRegToCC (0, readClk, readRst) ;

...
rule loadSync( reader.pulseOut ) ;
sync._write( reader.wordOut ) ; // or sync <= reader.wordOut ;
endrule
...
wrd_crunch.crunch( sync );
...

Data loss possible if _write method of sync not

ready when pulse occurs
No guarantee that wrd_crunch sees data

Copyright © Bluespec Inc. 2005 34

 Using FIFO Synchronizer

SyncFIFOIfc# (Bit# (32)) sync_fifo <- mkSyncFIFOToCC

(4, readClk, readRst) ;

rule loadSync( reader.pulseOut ) ;

sync_fifo.enq( reader.wordOut ) ;
endrule
...
wrd_crunch.crunch(sync_fifo.first);
sync_fifo.deq ;
...

Data loss still possible, will need to

change reader type

Copyright © Bluespec Inc. 2005 35

Advantages of Bluespec’s synchronizers

Bluespec provides a full set of speed-

independent data synchronizers, with strong
interface semantics preventing their misuse

But good design practices are still needed

Copyright © Bluespec Inc. 2005 36

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 clock

domains

Copyright © Bluespec Inc. 2005 37

 Specialized Synchronizers
(Topic for Advanced Training)

Above synchronizers work for any clock relations

If there are known relations between clock edges, then

synchronizer can be removed

Bluespec provides some synchronizers for clocks with

coincident edges, e.g., divided clocks.

Users can create their own synchronizers or import

their current ones into Bluespec

Copyright © Bluespec Inc. 2005 38

 Synchronizing Interfaces

The previous examples show a “hardware

approach” to clock-domain crossing:


Designers instantiate a module having different
clocks for different methods, and connect it up
explicitly


E.g. a FIFO with enq and deq on different clocks

Copyright © Bluespec Inc. 2005 39

 Synchronizing Interfaces

BSV also has an alternative “linguistic

approach”, to convert an interface from one
clock domain to another


mkConverter converts an existing interface to
another one of the same type, but on different clock


In this style, more of the details are implicit

Copyright © Bluespec Inc. 2005 40

 Synchronizing Interfaces

typedef Server#(QueryType,RespType) IfcType;

...
IfcType oldIfc <- mkServer (clocked_by c0);
...
IfcType newIfc <- mkConverter(4, oldIfc);

oldIfc is clocked by c0
newIfc is clocked by the current clock
“4” is a parameter for the conversion
(the depth of the FIFO)
newIfc can be used exactly as oldIfc,
but in the current clock domain
Copyright © Bluespec Inc. 2005 41
 Synchronizing Interfaces

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 existing
primitives

Copyright © Bluespec Inc. 2005 42

 Summary
The Clock type, and strong 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

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-domain
crossings, etc.

Copyright © Bluespec Inc. 2005 43

End of Lecture

Copyright © Bluespec, Inc., 2005