You are on page 1of 44

Bluespec SystemVerilogΠTraining

Lecture 10: Multiple Clock Domains

m  
 
Lecture 10: Multiple Clock Domains

The m  type, and functions

Modules with different clocks

Clock families

Making clocks

Moving data across clock domains

Synchronizing interfaces

m  
   ÷
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

m  
   ©
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

m  
   a
The m  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

m 

m  
   u  
 u  u
m  
   
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

m  
   ¦
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)

u       

Usage Ôat top level of a module body):

    

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

m 
         

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)

m  
   ‰
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

m  
   ·
The clockOfÔ) function

Example

    !   


 " 
m  #$ 
m m  #$ 

c, c1 and c÷ are all equal


They may be used interchangeably for all
purposes

m  
   10
Clock families
All clocks in a ³family´ share the same oscillator
½ They differ only in gating

If c÷ is a gated version of c1, we say c1 is an


³ancestor´ of c÷
½ If some clock is running, then so are all its ancestors

The functions isAncestorÔc1,c÷) and


sameFamilyÔc1,c÷) are provided to test these
relationships
½ Can be used to control static elaboration Ôe.g., to optionally
insert or omit a synchronizer)

m  
   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

m  
   1÷
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

m  
   1©
Clocks and implicit conditions

Example:

XX   % $  uXX  


 

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

m  
   1a
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

m  
   1
Making gated clocks

  
m ! &' m  

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

m  
   1¦
Making gated clocks
  
m ! &' m  

  
m  
&' m    ! 

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

m  
   1Œ
Other ways of making clocks
 èè    
( ) ! 
 )( '
)( *) 
  
m    m ) 

um  is a primitive for converting an ordinary signal


into a m safely

 is a clock running at half the speed of the


current clock, and is gated by

½ More precisely, it¶s running at half the speed of the clock of


register  
m  
   1‰
More Clock constructors
mkAbsoluteClock
½ ÔInteger start, Integer period);

mkClock
½ ÔBit#Ô1) osc, Bool gate)

mkGatedClock
½ ÔBool newCond)

mkClockDivider
½ #ÔInteger divider) Ô Clock clkin )

m  
   1·
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  

clk

 t l vi lati n
d

q —  
m  
   ÷0
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)

m  
   ÷1
÷ - Flop Synchronizer

Most common type of Ôbit) synchronizer


FF1 will go meta-stable, but FF÷ 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 FF÷

sClk dClk

m  
   ÷÷
Bluespec¶s ÷-Flop Synchronizer
mkSyncBit

sendÔ) FF0 readÔ)


FF1 FF÷

sClk dClk

( $'+ ($
,-.( ) -(  (/'' 
,-( '- 
 -( $'

Synchronizer design guidelines are followed and


cannot be violated
½ No logic between FF0 and FF1
½ No access to FF1¶s output

m  
   ֩
Small Example
Up/down counter, where direction signal comes from
separate domain.
Registers:

( 0 - ( ! - '-m   

(   ! !




The Rule Ôattempt 1):

0 0 0 0 - ( 


  "
 -0 

m  
   ÷a
Adding the Synchronizer

+ ($)  + ('-m '-)0 m  

0 ' )$0 
) 1) -0 - ( 
 -0 

0 0 0 ) 1'- 


  "
 -0 

m  
   ÷
Full Example
-0  2* m '-m )'-) ($ 

( 0 - ( ! - '-m  


) '-)  

(   ! !


  

m 0 m  )m0 m 

+ ($)  + ('-m '-)0 m  

0 ' )$0 
) 1) -0 - ( 
 -0 

0 0 0) 1'- 


  "
 -0 

m  
   ÷¦
Other Synchronizers

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

Documented in Reference Guide

m  
   ÷Œ
Pulse Synchronizer

Synchronizes single clock width pulses

( $'+ 30 )$


,-.( ) - 
,- 0 ) 
 -( $'

m 

SendÔ)

m 

pulseÔ)

m  
   ÷‰
Pulse Synchronizer

-0 + 30 )m )m  ))) 


m -m  
+ 30 )$($ 

But two ³send´s may not be seen if they occur


too close together Ôfaster than ÷À m )

m  
   ÷·
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 Ô÷dstClk)
½ send to next send Ô÷dstClks+ ÷srcClk)

Details in Reference Guide

m  
   ©0
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

m  
   ©1
FIFO Synchronizer

Good for data buffering between clock domains

Usual FIFO interface Ôwithout a clear method)

m  
   ©÷
A Larger Example
( $'4-'-
111
,-(  -#0 
,- 0 )#0 [ 
 


 -( $'

( $'4-m0 ,
,-.( 0 ,( -'''- 
111
 -( $'

4-'-'- 4-'-
Objective: Connect  - '-m  
wordOut with ) '-)  
crunch.
4-m0 , - 0 , 4-m0 ,

m  
   ©©
Using Word Synchronizer

( )  + mm!'-m '-) 


111
0  '-+ '-10 )#0 
) 1 ('-1 -#0 ) '-1 -#0
 -0 
111
- 0 ,10 ,)  
111

Data loss possible if _write method of sync not


ready when pulse occurs
No guarantee that wrd_crunch sees data

m  
   ©a
Using FIFO Synchronizer
+ 55#$( )  $($ + 55#mm
6'-m '-) 

0  '-+ '-10 )#0 


)  $($1 '-1 -#0 
 -0 
111
- 0 ,10 ,)  $($1$() 
)  $($1-
111

Data loss still possible, will need to


change reader type

m  
   ©
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

m  
   ©¦
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

m  
   ©Œ
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

m  
   ©‰
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 X Xwith and À on different clocks

m  
   ©·
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

m  
   a0
Synchronizing Interfaces

-$+*70) $
111
$ -$ +* - ! 
111
$  $ m *6 -$ 

 À is clocked by 0
 is clocked by the current clock
³a´ is a parameter for the conversion
Ôthe depth of the FIFO)
  can be used exactly as  À ,
but in the current clock domain
m  
   a1
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

m  
   a÷
Summary
The m  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
À, 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.

m  
   a©
   

m