9/20/2016

1ClockDomainCrossing

1
ClockDomainCrossing
Overview
AsmodernSystemonChip(SoC)designscontinuetofaceincreasingsizeandcomplexitychallenges,multiple
asynchronousclockdomainshavebeenemployedfordifferentI/Ointerfaces.ACDCbased(ClockDomainCrossing)
designisadesignthathasoneclockasynchronousto,orhasavariablephaserelationwith,anotherclock.ACDCsignal
isasignallatchedbyaflipflop(FF)inoneclockdomainandsampledinanotherasynchronousclockdomain.Transferring
signalsbetweenasynchronousclockdomainsmayleadtosetuporholdtimingviolationsofflipflops.Theseviolations
maycausesignalstobemetastable.Evenifsynchronizerscouldeliminatethemetastability,incorrectuse,suchas
convergenceofsynchronizedsignalsorimpropersynchronizationprotocols,mayalsoresultinfunctionalCDCerrors.
FunctionalvalidationofsuchSoCdesignsisoneofthemostcomplexandexpensivetasks.Simulationonregistertransfer
level(RTL)isstillthemostwidelyusedmethod.However,standardRTLsimulationcannotmodeltheeffectofmeta
stability.
Withinoneclockdomain,properstatictiminganalysis(STA)canguaranteethatdatadoesnotchangewithinclocksetup
andholdtimes.Whensignalspassfromoneclockdomaintoanotherasynchronousdomain,thereisnowaytoavoid
metastabilitysincedatacanchangeatanytime.
AstheCDCerrorsarenotaddressedandverifiedearlyinthedesigncycles,manydesignsexhibitfunctionalerrorsonly
lateintheirdesigncyclesorduringpostsiliconverification.Severalcoveragemetricsareproposedtomeasurethe
validation'sadequacyandprogress,suchascodebasedcoverage,finitestatemachinecoverage,andfunctionalcoverage.
Nevertheless,thesecoveragemetricsdonothavedirectrelationswithCDCissues.
Toaddressclockdomainproblemsduetometastabilityanddatasamplingissues,designerstypicallyemployseveral
typesofsynchronizers.Themostcommonlyusedsynchronizerisbasedonthewellknowntwoflipflopcircuit.Other
typesofsynchronizersarebasedonhandshakingprotocolsorFIFOs.Inalimitednumberofcasesitmaybeusefulto
employdualclockFIFObuffersorothermechanismsoptimizedfordomainswithsimilarclockfrequencies.
Toaccuratelyverifyclockdomaincrossings,bothstructuralandfunctionalCDCanalysisshouldbecarriedout.Structural
clockdomainanalysislooksforissueslikeinsufficientsynchronization,orcombinationallogicdrivingflipflopbased
synchronizers.Functionalclockdomainanalysisusesassertionbasedverificationtocheckthecorrectusageof
synchronizers.Assertionsmaybeusedtofindproblemssuchasdatastabilityviolationswhengoingfromafastclock
domaintoaslowerone.AssertionsgeneratedinPSLorotherassertionlanguagessuchasOpenVeraorSystemVerilog,
canthenbeusedinformalmodelcheckingorsimulation.
Thischapterisorganizedinthefollowingsections:
BackgroundPreparesthebackgroundrequiredforfurtherdiscussions.
SynchronizationTechniquesDiscussesthesynchronizationtechniques.
CDCAnalysisDiscussesthevariousstepsofCDCanalysis.
LedaCDCFlowProvidesinformationonthebasicLedaCDCtoolflow.
AutomaticallyGeneratedCDCAssertionsProvidesadetailedspecificationoftheLedasupportedassertions.
CDCAEPRuleUsage&NamingConventionsforAutomaticallyGeneratedCDCAEPFilesProvidesfurtherdetail
ofassertionrelatedtopics.

Background
Clockdomain
Aclockdomainisapartofadesignthathasaclockthatoperatesasynchronousto,orhasavariablephaserelationship
with,anotherclockinthedesign.Forexample,aclockanditsderivedclock(viaaclockdivider)areinthesameclock
domainbecausetheyhaveaconstantphaserelationship.But,50MHzand37MHzclocks(whosephaserelationship
changesovertime)definetwoseparateclockdomains.Figure1illustratesthreedifferentclocksinadesign,but
synchronoustoeachother.CLK,itsinversionandD1(derivedfromCLK)aresynchronoustoeachother.
Figure1:SynchronousClock
Aclockdomaincrossingsignalisasignalfrom
oneclockdomainthatissampledbyaregister
inanotherclockdomain.Moredetailsofthe
clockorigin/domaininferenceenginearegiven
in[1].
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

1/15

9/20/2016

1ClockDomainCrossing

Metastability
Everyflipflop(FF)thatisusedinanydesignhasaspecifiedsetupandholdtime,orthetimeinwhichthedatainputis
notlegallypermittedtochangebeforeandafterasamplingclockedge.Thistimewindowisspecifiedasadesign
parameterpreciselytokeepadatasignalfromchangingtooclosetoanothersynchronizingsignalthatcouldcausethe
outputtogometastable.
Figure2:SetupandholdtimeofaFlipflop
However,ifsomeinput(saydinFigure2)violatesthesetupand
holdtimeofaFF,theoutputoftheFF(qinFigure2)keeps
oscillatingforanindefiniteamountoftime.Thisunstablevaluemay
ormaynotnondeterministicallyconvergetoastablevalue(either0
or1)beforethenextsamplingclockedgearrives.
ExampleConsiderthe1bitCDCsignaladat,whichissampledby
registerbdat1inFigure3.Sinceadatcomesfromadifferentclock
domain(aclk),itsvaluecanchangeatanytimewithrespectto
bdat1'sclock(bclk).Ifthevalueofadatchangesduringbdat1's
setupandholdtime,theregisterbdat1might/mightnotassumea
statebetween0and1.Inthisstate,theregisterissaidtobemeta
stable.Ametastableregistermay/maynot(unpredictably)settletoeither0or1,causingillegalsignalvaluestobe
propagatedthroughouttherestofthedesign.
Figure3:Metastabilityscenario
Inamulticlockdesign,metastabilityis
inevitable,buttherearecertaindesign
techniquesthathelptoavoidthechanceof
gettingmetastable.Thefollowingsection
providesanoverviewofdifferent
synchronizationtechniques.

SynchronizationTechniques
Themainresponsibilityofasynchronizeristo
allowsufficienttimesuchthatanymetasable
outputcansettledowntoastablevalueinthe
destinationclockdomain.Themostcommon
synchronizerusedbydesignersistwoflipflop
(2FF)synchronizersasshowninFigure4.Usuallythecontrolsignalsinadesignaresynchronizedby2FFsynchronizers.
Figure4:A2FFsynchronizer

SynchronizationofControlSignals
with2FFSynchronizers
Ina2FFsynchronizer,thefirstflipflop
samplestheasynchronousinputsignalintothe
destinationclockdomainandwaitsforafull
destinationclockcycletopermitanymeta
stabilityonthestage1outputsignaltodecay,
thenthestage1signalissampledbythesameclockintoasecondstageflipflop,withtheintendedgoalthatthe
stage2signalisnowastableandvalidsignalsynchronizedintothedestinationclockdomain.Itistheoreticallypossible
forthestage1signaltostillbesufficientlymetastablebythetimethesignalisclockedintothesecondstagetocause
thestage2signaltoalsogometastable.
However,notethatthemetastabilityisaprobabilisticphenomenon.Themetastableoutputconvergestoastablevalue
withtime.Therefore,eveniftheinputtothestage2FFstillremainsmetastable,theprobabilitythattheoutputofthe
stage2FFwillremainmetastableforafulldestinationclockcycleisasymptoticallyclosetozero.Thiscalculationofthe
probabilityofthetimebetweensynchronizationfailures(MTBF)isafunctionofmultiplevariablesincludingtheclock
frequenciesusedtogeneratetheinputsignalandtoclockthesynchronizingflipflops.Formostsynchronization
applications,a2FFsynchronizerissufficienttoremovealllikelymetastability.
Evenifa2FFsynchronizerhelpstopreventpropagationofmetastablevalues,forthecorrectoperationofthedesign,
someotherissuesneedstobetackled.Theseissuesareexplainedinthefollowingsections.

InputDataStabilitytoAvoidDataLoss
Asynchronizercircuitensuresavoidingpropagationofmetastabilityintothedestinationclockdomain,butitcan'tensure
propagationofcorrectvalueasthemetastablesignalnondeterministicallyconvergestoanystablevalue(1or0).
However,forcorrectoperationofthedesign,everytransitionontheinputsignalneedstobecorrectlypropagatedtothe
destinationdomain.Toensurepreventingdataloss(losinginputtransitions),theinputsignalneedstoholditsvaluea
minimumamountoftimesuchthatthereisatleastasingledestinationsamplingclockedge,whichsamplestheinput
valuecorrectly(Nosetup/holdviolationFigure5givessuchanexample).Thisstabilityconditionontheinputsignalis
usuallycheckedbyputtingassertions.Formoreinformation,seethesection"FlipflopSynchronizers".
Figure5:Stabilityofinputsignalvalue

GrayEncodingtoAvoidDataIncoherence(ForVectorCDCControlSignals)
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

2/15

9/20/2016

1ClockDomainCrossing

Similartothecaseofsyncingasinglebit
controlsignal,thenaturalwaytotransfera
vectorcontrolsignalistomodeleachbitofthe
vectortobeseparatelysynchronizedbyaFF
synchronizer.Youhavealreadyseenthateven
ifyouuseFFsynchronizers,itusuallytakes
morethanonecycletopropagatecorrectinput
valuestothedestinationdomain.Nowconsider
acasewhereeverybitofthevectortakesa
transitionveryclosetothedestinationclockedge.Alsoassumethat,byvirtueofmetastability,onlysomeofthese
transitionsarecorrectlycapturedbythedestinationdomaininthefirstcycle.Now,ifthebitvaluesofthevectordecide
thestateofthedestinationdomain,afterthefirstcycle,thedestinationdomainmaymoveintoaninvalidstate.
Figure6:ScenarioindicatingDataIncoherence
ExampleSupposeavectorcontrolsignalSig
[2:0]crossesfromDomain1toDomain2.
SignalSigalsodecidesthestateofDomain2
andyouassumethatthevalue"100"ofSig
[2:0]indicatesaninvalidstateforDomain2.
Now,thinkofasituation,wherethesignalSig
wantstochangeitsvaluefrom"000"to"101"
(bothindicatevalidstates).Thisrequiresthe
twobitsSig[0]andSig[2]totransit
simultaneously.Boththesetransitionoccurs
veryclosetothedestinationsamplingclock
edge(seeFig6).Byvirtueofmetastability,
transitiononSig[2]getscapturedcorrectlyand
thetransitiononSig[0]ismissed.Inthisway,
inthefirstcycleofthedestinationclock,the
systemmovestostate"100"whichisinvalid.
Thiscasewouldnothavehappened,ifchangingthestatesofthedesignrequireschangingonlyasinglebitofthevector
(Siginthiscase).Incaseofasinglebittransition,eitherthattransitionwouldbecapturedinthedestinationdomainor
not.Thiswaythedesigneitherstaysinthepreviousstateormovetoavalidstate.Therefore,forvectorcontrolsignals
(multibitsignals,suchasaddressbuses),theusualsolutionistouseaGraycodewhencrossingaclockdomain
boundary.AGraycodeensuresthatonlyasinglebitchangesasthebuscountsupordown.Thepresenceofgraycoding
onvectorcontrolsignalcanbecheckedbyusingassertions.Formoreinformation,seethesection"GrayCodeEncoding
forVectorControlSignals".

SynchronizationofCDCDataSignals
Oneofthechallengesindesigningamulticlockbasedsystemistoenablecorrecttransferofdatabusesfromoneclock
domaintoanother.Thedifficultyarises,asindividualbitsofadatabuscanchangerandomlywhilechangingclock
boundaries.Usingsynchronizers/graycodetohandlethepassingofdatabusisgenerallyunacceptable.
Threecommonmethodsforsynchronizingdatabetweenclockdomainsare:
UsingMUXbasedsynchronizers.
UsingHandshakesignals.
UsingFIFOs(FirstInFirstOutmemories)tostoredatawithoneclockdomainandtoretrievedatawithanother
clockdomain.

PassingDatathroughMUXSynchronizer
Asshowninthefollowingfigure(Figure7),inaMUXsynchronizer,thecontrolpathisusuallyFFsynchronizedwhilethe
syncedincontrolsignalisusedtosynchronizethedatapaths.
Figure7:AMUXsynchronizer

HandshakingDatabetweenClock
Domains
Datacanbepassedbetweenclockdomains
usingasetofhandshakecontrolsignals,
dependingontheapplicationandtheparanoia
ofthedesignengineer.Whenitcomesto
handshaking,themorecontrolsignalsthatare
used,thelongerthelatencytopassdatafrom
oneclockdomaintoanother.Thebiggest
disadvantageinusinghandshakingisthe
latencyrequiredtopassandrecognizeallof
thehandshakingsignalsforeachdataword
thatistransferred.Figure8showsatypical
handshakesynchronizer.
Figure8:AHandshakeSynchronizer
Formanyopenendeddatapassingapplications,asimpletwolinehandshakingsequenceissufficient.Thesenderplaces
dataontoadatabusandthensynchronizesa"req"signal(request)tothereceivingclockdomain.Whenthe"req"signal
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

isrecognizedinthedestinationclockdomain,thereceiver

3/15

9/20/2016

1ClockDomainCrossing

isrecognizedinthedestinationclockdomain,thereceiver
clocksthedataintoaregister(thedatashouldhavebeen
stableforatleasttwo/threesamplingclockedgesinthe
destinationclockdomain)andthenpassesan"ack"signal
(acknowledgement)throughasynchronizertothesender.
Whenthesenderrecognizesthesynchronized"ack"signal,
thesendercanchangethevaluebeingdrivenontothe
databus.

PassingDatabyFIFObetweenClock
Domains
Oneofthemostpopularmethodsofpassingdatabetween
clockdomainsistouseaFIFO.Adualportmemoryis
usedfortheFIFOstorage.Oneportiscontrolledbythe
sender,whichputsdataintothememoryasfastasonedataword(oronedatabitforserialapplications)perwriteclock.
Theotherportiscontrolledbythereceiver,whichpullsdataoutofmemoryonedatawordperreadclock.Twocontrol
signalsareusedtoindicateiftheFIFOisempty,full,orpartiallyfull.Twoadditionalcontrolsignalsarefrequentlyused
toindicateiftheFIFOisalmostfulloralmostempty.Intheory,placingdataintoasharedmemorywithoneclockand
removingthedatafromthesharedmemorywithanotherclockseemslikeaneasyandidealsolutiontopassingdata
betweenclockdomains.Forthemostpartitis,butgeneratingaccuratefullandemptyflagscanbechallenging.
Figure9:AdualclockFIFOSynchronizer

UserdefinedSynchronizers
Sometimes,youmayspecifysomecellstobesynchronizers.Ifthis
cellisfoundonthepathbetweentheFF,thepathhastobe
consideredassynchronized.Notethatthecellitselfmayhave
otherinputsthanthesourceflipflopasshowninthefollowing
illustration.Thewayofspecifyingasynchronizerisexplainedin
chapter2,section"UsingTclCommand'set_cdc_synchronizer'".
Figure10:UserdefinedSynchronizer

CDC
Analysis
Followingare
thebasic
stepsforCDC
analysisand
checking
(irrespective
oftoolset
implementation):

StructuralAnalysistoIdentifyCDCSignalsandAppropriateSynchronizers
ThemostimportanttaskofanyCDCstructuralanalyzeristofindoutallthesignals(CDC)thatcrossclockboundaries.In
Leda,ruleNTL_CDC01(Formoreinformation,seethesection"CDCRuleset"inchapter2.)reportsalltheunsynchronized
CDCpaths.HoweveraCDCpathmaybesynchronizedinthedestinationclockdomain.Thus,identificationof
synchronizationschemesisveryimportanttoavoidreportingfalseCDCreports.Automaticdetectionofsynchronizersis
verytoughandmaydependontheunderlyingdesignprinciple.Therefore,sometime,thedesignerneedstoprovide
additionalinformationfortheunderlyingsynchronizationschemes.
OnceextractionofinformationforalltheCDCpaths(synchronizedandunsynchronized)isover,youneedtoseewhether
therearestructuraldefectsbeforeandafterthesynchronizers.

StructuralAnalysistoIdentifyStructuralDefectsBeforeandAfterSynchronization
Manydesignteamschooseafewsynchronizerstyles,applythemtoallsignalscrossingclockdomainsandenforcetheir
usagebydesignstylerulesanddesignreviews.Althoughpropersynchronizersareessentialformulticlockdesigns,they
areinsufficienttoavoidallpossibleproblemsregardingsignalscrossingclockdomains.Considerableextracaremustbe
takeninthedesignprocesstoavoidtheseproblems.Someofthestructuralproblemsthatmaycausefunctionalerrorsin
multiclockbasedsystemsareasfollows.

Convergence
ConvergenceintheCrossoverPath
UsingcombinationalelementsinaCDCpathbeforesynchronizationcanleadtofunctionalproblems.Forexample,itis
importantthatglitchesinthedrivingclockdomainnotbepropagatedintothereceivingclockdomain.Sincetheflipflops
inthereceivingclockdomaincansamplethesignalsfromthedrivingclockdomainatanypoint,thereisnowaythrough
statictiminganalysistoensurethattheglitchwillnotbepropagated.Figure11showsanexampleofcombinationallogic
(convergence)thatcouldcauseaglitchtopassfromoneclockdomaintoanother.RuleNTL_CDC02detectsthisissue.
Figure11:GlitchpropagationduetoconvergenceinCDCPath
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

4/15

9/20/2016

1ClockDomainCrossing

DivergenceintheCrossoverPath
Designstyleswhichallowdivergentlogicona
CDCsignaltomultiplesynchronizationpaths,
maycausefunctionalerrors.AsFigure12
illustrates,asinglecontrolsignal(Trans_en)
fromthesourceclockdomain(clk1)isusedto
activateboththe"addr"and"data"transfer
unitinthedestinationclockdomain(clk2).The
purposeistoenableboththelogicsatthe
sametime.Tomodelthis,fanoutsof
Trans_enhasbeenusedbeforethe
synchronizationtakesplace.However,dueto
thepropagationdelayanddifferentmeta
stablesettlingtimes,thetwofanouts
('addr_en'and'data_en')couldreachthe
AddressandDatatransferlogicsatdifferent
times.Thereforethesetwologicsmaystartat
differenttimecausingfunctionalerrors.This
typeofstructureshouldbeavoidedbyfanning
outasingleFFsynchronized'commonenable'
signaltothetwotransferlogics.Rule
NTL_CDC03detectsthisissue.
Figure12:Divergenceinthecrossoverpath

DivergenceofMetastableSignal
Usingametastablesignalinadesigncanbe
erroneous.Thereforemultiplefanoutofthe
outputofthefirstFFofaFFsynchronizercan
causefunctionalerrors.RuleNTL_CDC04
detectsthisissue.
Figure13:Divergenceofmetastablesignal

ReconvergenceofSynchronizedSignals
convergence
Synchronizationandglitcheliminationalonearenot
enoughtoensurereliabletransferofdataacrossclock
domains.Whenasignalgoesmetastable,a
synchronizersettlesitdown,butcannotguaranteethe
precisenumberofcyclesbeforethevalidsignalis
availableinthereceivingclockdomain.Therefore,if(1)
twoindependentsignalsor(2)bitsofamultibitsignal
areindependentlysynchronized(usingsametypeof
synchronizersordifferenttypesofsynchronizers),the
bitsmayarriveinthereceivingclockdomainskewed
withrespecttooneanother.Averysimpleformofre
convergenceisshowninFigure14.RuleNTL_CDC05and
NTL_CDC07detectthisissue.
Figure14:Thesimplestformofreconvergence
Therefore,evenwhenmetastabilitydoesnotoccur,any
pairofbitscangetoutofsynchronizationifrouting
differencesandelectricaleffectscausethetwobitsto
havedifferentdelaysbeforereachingtheirrespective
synchronizers.Itispossibleforonesynchronizerto
sampleitsinputandcaptureasignalchangebeforethe
othersynchronizercapturesthechange,atwhichpoint
thetwocopiesofthesignalwillbeskewedbyacycle
andnolongercorrelated.
Ledahassixrulesthatcheckalltheabovestructural
checksforCDCsignals.Thepurposeoftheserulesisto
providethefollowinginformation.Detaileddescription
ofalltheLedastructuralchecksisprovidedinchapter
2.
a.NTL_CDC01ReportsalltheunsynchronizedCDC
pathsinthedesign.
b.NTL_CDC02Reportsallconvergenceinthe
crossoverpathsinthedesign.
c.NTL_CDC03Reportsalldivergenceinthecrossover
pathsinthedesign.
d.NTL_CDC04Reportsdivergenceofanymetastablesignalinthedesign.
e.NTL_CDC05/07Reportsallkindsofreconvergenceofsynchronizedsignalsinthedesign.Thereisasubtledifference
betweenruleNTL_CDC05andNTL_CDC07.Formoreinformationaboutthedifference,seethesection"CDCRuleset"in
chapter2.
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

5/15

9/20/2016

1ClockDomainCrossing

DeterminationandValidationofAppropriatePropertiesforEverySynchronizer
Justhavingasynchronizationcircuitconnectedisonlypartofthesolutiontheassociatedlogicmustinteractcorrectly
withthesynchronizationcircuittoensurevalidoperation.Toensurethis,assertionsneedtobespecifiedthatcheck
correctfunctionalityofthesynchronizationcircuitsandvalidatescorrectuseofthesynchronizersbytheenvironmentin
whichtheyareinstantiated.Youautomaticallyspecifythesepropertiesonceforeverysynchronizerandautomatically
attachthemtoallinstancesofthecorrespondingsynchronizationbuildingblocks.ThesupportedpropertychecksforCDC
synchronizationcircuitelementsaregivenasfollows.Formoreinformationaboutthesepropertyspecifications,seethe
section"AutomaticallyGeneratedCDCAssertions".
FlipflopSynchronizer
Controlsignalstabilityassertions
MUXSynchronizer
Controlsignalstabilityassertions
Datasignalstabilityassertions
HandshakeSynchronizer
Controlsignalstabilityassertions
Datasignalstabilityassertions
Handshakeprotocolcheckassertions
FIFOSynchronizer
Controlsignalstabilityassertions
Graycodedassertionsforreadandwritepointers
FIFOprotocol(full/emptycheck)assertions
Dataintegritychecks
AmorecompletedescriptionoftheCDCAEP(automaticallyextractedproperties)usageisgiveninthesection"CDCAEP
RuleUsage".

LedaCDCFlow
ThecompleteLedaCDCflowisgiveninFigure15.ThemainCDCrelatedmoduleshavebeencolored.TheCDCverification
enginetakeshelpoftheMagellan/VCSforcheckingtheLedaCDCassertions(statically/dynamically).
Figure15:ThecompleteLedaCDCflow

AutomaticallyGeneratedCDC
Assertions
Structuralanalysisprimarilycheckswhetherthere
existsasynchronizerintheCDCpaths.Havinga
synchronizerconnectedonlysolvestheverification
problempartially.Youadditionallyneedtocheckthe
followingtwofeatures.
1.Theenvironment(associatedlogic)mustinteract
properlywiththesynchronizer.
2.Thesynchronizeritselfbehavescorrectly.
Thesetwochecksaremandatorytoensurevalid
operationinreallife.TheAEP(automaticallyextracted
properties)engineofLedageneratesandbinds
assertionsthatcheckcorrectfunctionalityofthe
synchronizersandvalidatescorrectuseofthe
synchronizersbyitsenvironment.Toidentifythe
synchronizers,theAEPengineusestheLedastructural
analyzer.Inthefollowingparagraphs,youwillcategoricallyenumeratethesynchronizerrelatedchecksforABV(assertion
basedverification).

FlipflopSynchronizers
Description
TheFFsynchronizers(showninFig16)formthebasicbuildingblockformostoftheexistingsynchronizationcircuits.A
simpleFFsynchronizerconsistsofm(>1)FFmodeledasashiftregisterrunningonthe'destinationclock'.Oncethe
presenceofaFFsynchronizerhavingmstagesisdetected,thefollowingpropertyisgeneratedtoensurethatthedevice
functionscorrectlyinpresenceofthissynchronizer.
Ifnoassumptionsaremadeabouttherelationshipbetweenthe'source'and'destination'clockdomains,thenthe
followingpropertyensuresthatallinputsignalvaluescanbereliablytransportedtothesynchronizeroutput.
Inputdatavaluesmustbestableform+1destinationclockedges.
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

6/15

9/20/2016

1ClockDomainCrossing

Figure16:FlipflopSynchronizers

Implementation
ExampleSVAcodesfortheabovepropertiesare
givenasfollows.Thisassertionverifiesthestability
ofdinasobservedinthedestinationclockdomain.
Signalrstistheresetsignal(ifany,withthe
appropriatepolarity)extractedfromthesynchronizer
FF,dinisthesinglebitinputtothefirstFFofthe
synchronizer.
propertyp_stability
disableiff(rst)
@(<appropriate_edge>dclk)
!$stable(din)|=>$stable
(din)[*m])
endproperty
A_p_stability:assertproperty(p_stability)

MUXSynchronizers
Description
Designstypicallyhavebothcontrolanddatapaths.Asshowninthefollowingfigure(Fig17),thecontrolpathsare
usuallyflopsynchronizedwhilethesyncedincontrolsignalsareusedtosynchronizethedatapaths.Here,thesedata
pathsuseacontrolledsynchronizerMUXforcrossingclockdomains.ThesecontrolMUXsaresometimescalledDMUX,
MUXsynchronizer,orsyncMUX.
Figure17:MUXsynchronizers
TheMUXsynchronizerhasthefollowing
functionalrequirementstoensurecorrect
results.
sreadymustbestableform+1numberof
destinationclockcycles(modeledbyproperty
p_stabilityasexplainedinthesection"Flipflop
Synchronizers").
datashouldremainstableinthedestination
clockdomainduringthedatatransferphase
(indicatedbythetimedreadyisassertedindclk
domainanduntildreadydeassertedindclk
domain).

Implementation
StabilityofData
propertyp_data_stable
disableiff(drst)

@(<appropriateedge>dclk)
((dready)|=>($stable(data)||
(!dready))
endproperty
A_p_data_stable:assertproperty(p_data_stable)

HandshakeSynchronizers(Push)
Description
Therearedifferenttypesofhandshakesynchronizersinpractice,butmostcomedowntothefundamentalworking
principleofsynchronizingasinglebitrequestintothedestinationclockdomainandwaitingforasynchronizedversionof
theacknowledgetocomeback.Thedifferencesinthearchitectureofthehandshakesynchronizerstakeplacebecauseof
thehigherlevelprotocolsfortheassociatedinterfaces,datamanagement,etc.
Thehandshakesynchronizersusetwomflipflopsynchronizerstogeneraterequestandacknowledgesignals.The
associatedpropertiesaregivenasfollows.
InputDataStabilityforthemflipflopSynchronizersInputdatavaluesmustbestableform+1destination
clockedges(Reuseoftheassertionin6.a)
ProtocolcheckThesenderandthereceivershouldfollowthehandshakeprotocolcorrectly.
DataStabilityThedatamustbepresentwhenrequestisassertedonthedestinationandremainstableuntil
theacknowledgmentisgenerated.
Figure18:Handshakesynchronizers

Implementation
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

7/15

9/20/2016

1ClockDomainCrossing

Thefollowingassertionscovertheproperuse
ofthemflipflopsynchronizers,the
handshakeprotocol,andthecorresponding
datastability.
1.InputDataStabilityforthemflipflop
synchronizers
Requestsignal(sreq)ofthesenderand
Acknowledgementsignal(dack)mustbestable
form+1'dclk'and'sclk'cyclesrespectivelyas
implementedinthesection"Flipflop
Synchronizers".
2.Protocolcheck
a.Thesendershouldcontinuetoassertthe
sreqsignaluntilsackisassertedatthesource
clock(sclk)domain.
b.Thesendershouldnotassertanewrequest
(sreq)untiltheacknowledgementfortheprevioustransferisdeassertedinthesourceclock(sclk)domain.
ASVApropertythatcoverstheabovetwochecksisgivenasfollows.
propertysrc_conformance(clk,rst,ssig,dsig)
disableiff(rst)

@(<appropriateedge>clk)
ssig&&!dsig|=>ssig
endproperty
A_src_conformance_req:assertproperty(src_conformance(sclk,srst,
sreq,sack))
A_src_conformance_new_req:

assertproperty(src_conformance(sclk,srst,!sreq,!sack))
Similarpropertiesforthedestinationclockdomain(dclk)aregivenasfollows.
Thereceivershouldcontinuetoassertthedacksignaltilldreqisassertedatthedestinationclock(dclk)domain.
Thereceivershouldnotassertanewacknowledgement(dack),untilanewrequestisreceivedinthedestinationclock
(dclk)domain.
ASVApropertythatcoverstheabovetwochecksisgivenasfollows.
propertydest_conformance(clk,rst,ssig,dsig)
disableiff(rst)

@(<appropriateedge>clk)

ssig|=>dsig
endproperty
A_dest_conformance_req:assertproperty(dest_conformance(dclk,drst,
dreq,dack))
A_dest_conformance_new_req:

assertproperty(dest_conformance(dclk,drst,!dreq,!dack))
3.Datastability
Thereceivershouldcontinuetoreceivestabledatatillitassertstheacknowledgment.
ThefollowingSVApropertyimplementstheabovetwoscenarios.
propertydata_stability(clk,rst,dreq,dack,data)
disableiff(rst)

@(<appropriateedge>clk)(dreq&&!dack)=>$stable(data)
endproperty
A_data_stability_dest:

assertproperty(dest_stability(dclk,drst,dreq,dack,data))
ThechecksforPullsynchronizersaresimilar.

DualClockFIFOSynchronizers
Description
AnothercommonCDCsynchronizationcircuit,whichisusedwhenthehighlatencyofthehandshakeprotocolscannotbe
tolerated,isthedualclockasynchronousFIFOasshowninFig19.Althoughmanyimplementationvariationsexist,the
basicoperationisthesamedataiswrittenintoadualportRAMblockfromthesourceclockdomainandtheRAMisread
inthedestinationclockdomain.Graycodedreadandwritepointersarepassedintothealternateclockdomain(using
twomflipflopsynchronizers)togeneratefullandemptystatusflags.Thefollowingpropertiesaregeneratedforthe
dualclockasynchronousFIFO:
TheproducerneverwriteswhentheFIFOisfull.
TheconsumerneverreadswhentheFIFOisempty.
ReadandWritepointersmustbegraycodedatsource.
Checksfordataintegrity(FIFOpreservesOrderandDataValue).
Figure19:FIFOBasedSynchronizer

Implementation
ThefollowingSVAcodeprovidesapossibleimplementationofthesechecks.Thep_data_integrityassertionstartsanew
threadwithauniquecntvaluewhenever
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

8/15

9/20/2016

1ClockDomainCrossing

wdataiswrittentotheFIFOandchecksthe
rdatavalueagainstthelocaldatavariable
wheneverthecorrespondingreadoccurs.The
first_matchisrequiredinp_data_integrityto
ensurethepropertychecksrdataonthefirst
occurrenceofareadwiththecorresponding
cnt,otherwiseitwaitsforeverforardata
matchatthercntvalue.Youshouldcreatea
moduleM,whichcontainstheassertions.Itis
thenboundtothenearesttoplevelmodule
instancecontainingtheFIFOcode.
NoLoadonFull&NoReadonEmpty
propertyp_bad_access(clk,inc,flag)
@(<appropriate_edge>clk)inc|>!flag

endproperty:p_bad_access
//Propertyforbadwriteaccess
A_p_bad_access_write:assertproperty(p_bad_access(wclk,winc,wfull))
//Propertyforbadreadaccess
A_p_bad_access_read:assertproperty(p_bad_access(rclk,rinc,rempty))
OrderandDataPreservation

//Thefollowingcodemimicsthegreycodedreadandwritepointers.If
youhave
//thosepointersautomaticallyidentifiedfromthedesign,thisisnot
required
bit[$bit(waddr)1:0]rcnt=0,wcnt=0
always@(posedgewclkornegedgewrst_n)begin
if(wrst_n)wcnt<=0
elseif(winc)begin
wcnt=wcnt+1
end
end
always@(posedgerclkornegedgerrst_n)begin
if(rrst_n)rcnt<=0
elseif(rinc)begin
rcnt=rcnt+1
end
end
propertyp_data_integrity
intcntlogic[$bits(wdata)1:0]data
disableiff(!wrst_n||!rrst_n)

@(posedgewclk)
(winc,cnt=wcnt,data=wdata)|=>
@(posedgerclk)
(first_match(##[0:$](rinc&&(rcnt==cnt)))|>

(rdata==data))
endproperty:p_data_integrity
A_p_data_integrity:assertproperty(p_data_integrity)

GrayCodeEncodingforVectorControlSignals
Description
Thischeckaddressesmultibitsignals(bitvectorsoracollectionofindividualsignals)thatoriginateinoneclockdomain
withtheclockingeventsclkandthenreconvergeinanotherclockdomainwiththeclockingeventdclkwithoutusingany
oftheabovehandshakebasedsynchronizationschemes.Suchsignalsmustallhavemflipflopsynchronizersandin
additiontheymustbeGreycodeencodedbeforeenteringthesynchronizers.Inthisway,whenthereisachangefrom
onestateofthemultibitsignaltoanother,onlyonebitchangesatatime.Itensuresthatthedestinationsidewillnot
sampleinconsistentstatevaluesduetodifferentskewsandmetastabilitydelaysoneachbit.TheGraycodemaybe
decodedonthedestinationside,aftertheindividualsynchronizers.
Figure20:MultibitDataTransfer
Oncesuchmultibitsignalsareidentified,the
purposeofthefunctionchecksistoverifythatstate
changesonthesourcesidebeforeenteringthebit
synchronizersfollowtheGraycode.

Implementation
Eachindividualmflipflopsynchronizermustsatisfy
thesignalstabilitypropertiesindicatedin1.1.2.In
addition,theGraycodeassertionverifiesthat
wheneverthereisachangeofvalueondata_inthe
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

9/15

9/20/2016

1ClockDomainCrossing

nextvaluediffersfromtheprecedingoneonlyinonebit.Thevectordata_inisformedbyconcatenatingallthevariables
thatarepartofthemultibitsignal.
propertyp_gray_coded(clk,rst,data)
disableiff(rst)

@(<appropriate_edge>clk)!$stable(data)|>($onehot
(data^$past(data))
endproperty
A_p_gray_coded:assertproperty(p_gray_coded(dclk,rst,din))
Inthefollowingsection,youwillreadhowLedageneratestheseassertionsandhowtousetheseassertionsfor
verification.

CDCAEPRuleUsage
ClockDomainCrossingisaglobalproblemandLedacurrentlyhasaneffectivesolutionforCDCverification.Inthis
section,theCDCrulesthatgenerateassertionsforverifyingfunctionalityofeachoftheCDCsynchronizerrecognizedin
thedesign(NTL_CDC06,andNTL_CDC14NTL_CDC16)areelaborated.Inaddition,thereisaruleNTL_CDC08,which
checksforthecorrectimplementationofgreycodingforeachvectorCDCcontrolsignaldetectedinthedesign.
Thepurposeofaddingthesefiverulesistoprovidethefollowinginformation:
NTL_CDC06IndicatesthatFFsynchronizershavebeenusedinthedesign.ForeachoftheseFFsynchronizers,
LedageneratesassertionforcheckingthesignalstabilitypropertyoftheassociatedCDCcontrolsignal.
NTL_CDC08IndicatesthatvectorCDCcontrolsignalshavebeenusedinthedesign.Foreachofsuchvector
CDCcontrolsignal,Ledageneratesassertionforcheckingwhethertheassociatedvectorhasbeengraycoded.
NTL_CDC14IndicatesthatMUXsynchronizershavebeenusedinthedesign.ForeachofsuchMUX
synchronizers,Ledageneratesassertionsforcheckingsignalstabilityoftheassociatedcontrolanddata
signals.
NTL_CDC15IndicatesthatHandshake(Push/Pull)synchronizershavebeenusedinthedesign.Foreachof
suchHandshakesynchronizers,Ledageneratesassertionsforcheckingsignalstabilityoftheassociatedcontrol
anddatasignals.Inaddition,itgeneratesassertionsforcheckingthecorrectnessoftheassociatedhandshake
protocol.
NTL_CDC16IndicatesthatFIFOsynchronizershavebeenusedinthedesign.ForeachofsuchFIFO
synchronizers,Ledageneratesassertionsforcheckingempty/fullcriterionoftheassociatedFIFO.Inaddition,it
generatesassertionsforcheckingthe(a)datasignalintegrityoftheFIFO,and(b)graycodingoftheFIFO
read/writepointers.
Furthermore,thedetailedstructuralanalysisstatisticsfortheCDCsynchronizers(suchasthenumbers,locationsetc.)
canbeaccessedinthefollowingways:
WhileusingTclmode(switchleda+tcl_shell),thereisacommandcalled'report_cdc_info',whichdisplaysall
typesofdetectedCDCstructures.
Thereare7rules(NTL_CDC01,NTL_CDC01_0,NTL_CDC01_1,...,NTL_CDC01_6)whichwhenselecteddisplays
alltypesofCDCstructures(synchronized,unsynchronized)detectedinadesignbyLeda.
Thesection"CDCTclInterface"providesdetailsofthecurrentCDCTclinterface.Additionally,eachoftheCDCassertion
specificrulesNTL_CDC14NTL_CDC16alsoprovidessignalspecificinformationabouttheCDCsynchronizers.Anexample
isprovidedinthesection"CDCAnalysis".

NamingConventionforAutomaticallyGeneratedCDCAEPFiles
Foreachoftherulesspecifiedinprevioussection,Ledageneratesaseparateassertionfile.Thisfilecontainsthe
template/definitionfortheassociatedassertion.Thenamingconventionoftheassertionfiles(alsodefinitions)follows
thespecificissueforwhichtheassertionhasbeengenerated.Forexample,'aep_signal_stability.v'filecontainsassertion
definitionforcheckingthecontrolsignalstability.Thegeneratedfilenamesalongwiththeirpurposesaregivenas
follows:
aep_signal_stability.vCheckscontrolsignalstability.
aep_mux_data_signal_stability.vChecksdatasignalstabilityofaMUXsynchronizer.
aep_handshake_data_signal_stability.vChecksdatasignalstabilityofaHandshakesynchronizer.
aep_handshake_protocol_check.vCheckshandshakeprotocolchecksforaHandshakesynchronizer.
aep_fifo_validate_assertions.vChecksfifoproperties(full/empty,dataintegrity)foraFIFOsynchronizer.
Eachoftheseassertiondefinitionfilesaregeneratedonlyonce.Aseverycomplexsynchronizer(MUX,FIFO,and
Handshake)usesFFsynchronizersforsynchronizingthecontrolsignals,aep_signal_satbility.visalsoreusedforeachof
them.

BindingtheAssertionDefinitionstotheDesign
Thegeneratedassertiondefinitionsareattachedtothedesignsignalsusingasetof'bind'statements.Thesebind
statementsaregeneratedinaseparatefilenamed'leda_top_properties.v'.Astherecanbemultipleinstancesofa
specificsynchronizer,foreachoftheseinstances,aseparatebindstatementisgenerated.Theinstancenameofthe
assertiondefinitions(usedinthebindstatements)isnumbered.

https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

10/15

9/20/2016

1ClockDomainCrossing

Thegeneralideaforgeneratingpropertiesistouseprepackagemodulescontainingassertionsandbindthemtothe
verifieddesign.Thebindshouldtrytobindthelowestpossiblemoduleinthedesignhierarchyinordertoallowreduction
ofthedesignsizefortheformaltool.Thebindcommandwillhavethegeneralfollowingsyntax:
bind<property_module_name>#(<parameters>)<bind_instance_name>(
<port_list>)
where,<bind_instance_name>isoftheform:

i_<RULE_LABEL>_<INSTANCE_NUMBER>
ForexampleiftherearethreeFFsynchronizersdetectedinadesign,therewouldbeonecontrolsignalstabilityassertion
definitionandthreeseparatebindstatementsgeneratedwiththreeuniqueassertioninstancesnamelyi_NTL_CDC06_1,
i_NTL_CDC06_2,andi_NTL_CDC06_3.
Sometimes,ifyouwanttoavoidexplosionofthesimulationtimeorMagellanrunningtime,youcanalsoboundthe
numberofpropertiesthataregenerated.Theset_max_propertiescommandplacedinthedesignconfigurationfileallows
controllingthisnumber.ThiscommandisnotspecifictotheCDCManageritispartofthepropertygenerationmanager.
set_aep_max_propertiesvaluemax_value

UsingGeneratedAssertionsinVCSandMagellan
Thegeneratedassertionscanbeverifiedonthedesignusing(1)VCS(simulationbasedverification)or(2)Magellan
(formalverification).Tosimplifybuildingoftheassertions,afile(namedleda_prop_file.lst)containingthelistof
automaticallygeneratedfilesiscreated.Asaresult,youonlyneedtoattachfile'leda_prop_file.lst'totheassociated
checkertool.
Thesetofassertionrelatedfilesaregeneratedinadirectorynaming'ForMG'.Thisdirectoryislocatedbydefaultin
.leda_workorincase.leda_workismissinginthe'rundirectory.
Moreover,forMagellan,aprojectfiletemplate(named'LedaMgPrjFile.prj')isalsogenerated.You(sometimes)mayneed
toaddadditionalinformationliketheclockperiods,theresetconfigurationsetc.inthistemplate.Youdon'tneedtouse
anyswitchforgeneratingtheassertions.Theassertionsandtheassociatedfilesarecreatedbydefault.

FailureDebugging
IncaseofanyCDCassertionviolationsforadesign,youneedtousethedebuggingaidsoftheassociatedchecker
(VCS/Magellan)forfindingtherootcauseofthefailure.

UsingPropertyGenerationforChecking
SomeoftheCDCrulescanidentifycertainsituationsandgeneratepropertiesfordynamicandformalverification.
DifferentrulesgeneratingpropertiesarewritteninthesameSystemVerilogfileLEDA_<top>_properties.sv.Youcan
controlthenumberofpropertiesgeneratedbytheCDCrulesusingthefollowingcommand:
Syntax
set_aep_max_propertiesvaluemax_value
Arguments
valueSpecifythevaluetocontrolthenumberofpropertiesgeneratedbyCDCrules.
Thegeneralideaforgeneratingpropertiesistouseprepackagemodulescontainingassertionsandbindthemtothe
verifieddesign.Thebindtriestobindthelowestpossiblemoduleinthedesignhierarchyinordertoallowreductionof
thedesignsizefortheformaltool.Thebindcommandwillhavethegeneralfollowingsyntax:
Syntax
bind<property_module_name>#(<parameter>)<bind_instance_name>(<port_list>)
where,<bind_instance_name>isoftheform<RULE_LABEL>_<FILENAME>_<LINENUMBER>

AssertionLibrary
Insteadofgeneratingassertionsorpropertiesforeachcheck,Ledausesanassertionlibrarypackagedwiththetool.Each
checknowbindstothemodulecontainingtheprepackagedproperty.Thislibraryisasetofmodulescontainingthe
necessaryproperties.Thesemodulesmayalsohaveparameterstosetdifferentoptionsorbitwidth.

DataSignalStability
Thefollowingassertionisgeneratedfortheconditionthatdatasignalsmustbestablewhilethecontrolsignalis
asserted(fromsourceofcontrolpathasserteduntiltargetofcontrolpathdeasserted):
bindtopaep_assert_data_stable#(2,"Error:CDCdatasignalSmust
bestablewhilecontrolsignalisasserted")CDC06_test_v_40(ck2,rst,
DataIn,CtrlSource,CtrlTarget)

GreyCoding

https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

11/15

9/20/2016

1ClockDomainCrossing

Thefollowingassertionisgeneratedbytherulethatchecksiftwoormoresignals
aregraycoded(forexample,multibitcontrolsignals).
bindtopaep_assert_gray_coding#(BitWidth,"Error:multibitcontrol
signalsmustbegraycoded")CDC08_test_v_40(ck1,rst,CtrlSig)

DetailedExplanationsforRulesNTL_CDC05andNTL_CDC07
BothoftheserulescheckacommonCDCscenariocalledthe"reconvergenceofsynchronizedsignals".
Asexplainedearlier,lossofcorrelationcanalsooccurwhentwoapparentlyindependentsignalsaresynchronized
separately,butultimatelyfedintothesamelogic.Thisscenario,sometimesdubbedreconvergence,isespeciallydifficult
todetectbymanualinspectionofthesynchronizationschemesduringdesignreview.
Anotherformofcorrelationlosscanoccurwhenasignalhasfanoutsintomultiplesynchronizers.Thetwobranchesof
thesignalcanhavedifferentdelaystheelectricalandroutingeffectscanalsocausedifferentdelaysintheclocksgoing
tothetwosynchronizers.Therefore,ifthetwosynchronizerssampletheirinputsatdifferenttimesthenthetwocopiesof
thesignalcanbeskewedbyacycleandnolongercorrelated.
Topreventthesecorrelationlossscenarios,LedahastwoCDCrulesthatconfirmthatthereisno"reconvergenceof
synchronizedsignals"inthedesign.
Thefirstone"NTL_CDC05"confirmsthattwosignalssynchronizedintwodifferentsynchronizers(thusformingtwo
differentCDCelements)neverconverge.
Ontheotherhand"NTL_CDC07"confirmsthatCDCpathssynchronizedbythesamesynchronizer(thusgroupedina
singleCDCelement)neverconvergesafterbeingsynchronizedinthetargetclockdomain.
Examples:
ForCDC05rule,twoonebitsignalsaresynchronizedbytwo2FFsynchronizersintwodifferenttargetdomains(CLK2and
CLK3),thusformstwodifferentCDCelements.Afterthesynchronizationisdone,thesetwosignalsconvergeinanAND
gate.
ForCDC07rule,asinglebitsignalhasfanoutstwo2FFsynchronizers.Afterthesynchronizationisdone(inthesingle
targetdomainCLK2thusformingasingleCDCelement),thesetwosignalsconvergeinanANDgate.TheHDLcodesand
relatedCDCerrormessagesaregivenasfollows.
Formoreinformationabouttheserules,seethechapter"ClockDomainCrossingRules".

CDCTclInterface
ThefollowingisthecommandreferenceinformationforbuiltinTclcommandsthatyoucanusetomanagetheCDCrules:

set_cdc_ignored_path
Usetheset_cdc_ignored_pathcommandtospecifyapathtobeignoredbyCDCanalysis.
Syntax
set_cdc_ignored_path[fromsource_ff_name]\
[totarget_ff_name]
Arguments
fromSpecifythesourceflipflopname.
toSpecifythetargetflipflopname.
Althoughfromandtoareoptional,atleastoneoftheoptionsmustbeused.Ifyoudon'tspecifyanyoneofthe
options,thenit'svalueisconsideredas'any'.Forexample:
set_cdc_ignored_pathfromtop.rst
Fortheabovecommand,anyCDCpathfromtop.rstwillbeignored.

set_cdc_synchronizer
Usetheset_cdc_synchronizercommandtospecifyasynchronizercell.
Syntax
set_cdc_synchronizernamename\
[synchro_typetype[synchro_parameters{..}]]
Arguments
nameSpecifythenameofthesynchronizercell.
synchro_typeSpecifythesynchronizertype.Itcantakeoneofthe
followingvalues:
simple(forflipflopsynchronizers).
logic(forlogicsynchronizers).
complex(forcomplexsynchronizers).
fifo(forfifosynchronizers).
handshake(forhandshakesynchronizers).
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

12/15

9/20/2016

1ClockDomainCrossing

synchro_parametersSpecifytheparameterscorrespondingtothesynchronizer.
Forallthespecifiedsynchronizers,theparametersarealistofstringsthatspecifysomevalues.Thefollowingtablelists
theparametersthatareapplicableforvarioussynchronizers.
Table2:Parametersofdifferentsynchronizers
Parametersapplicabletoall
synchronizers

ParametersapplicabletoFIFO
synchronizer

Parametersapplicabletohandshake
synchronizer

source_clock

source_clock

source_clock

target_clock

target_clock

target_clock

write_signal

handshakekind(canbepushhanshakeor
pullhandshake)

read_signal

transmit_signal

fifo_full

receive_signal

fifo_empty
write_reset_signal
write_read_signal
data_signal

set_cdc_group
Usetheset_cdc_groupcommandtooverridetheautomaticCDCinference.ThiscommandenablesyoutocreateaCDC
elementandspecifyadditionalinformationlikesynchronizationtype.Inotherwords,itallowsacompletespecificationof
theCDCinformationfromyou.ThiscommandisgeneratedbythedumpmodeoftheCDC.AfterCDCinferenceindump
mode,alltheinferredinformationisdumpedusingtheset_cdc_groupcommand.Ifyouwanttomodifytheinferred
informationorgroupingofthedifferentpaths,youneedtoeditthedumpedfileandadapttheinformation.
Therulesconcerningreconvergentpathsandgraycodingofcontrolpathsarehighlydependentonthegrouping.So,make
surethatthegroupsareformedcorrectly.Inadditiontotheautomaticinferencealgorithmandthepossibilitytodefine
synchronizer,LedaalsoofferstheflexibilitytofullycustomizetheCDCinformation.
TheCDCinferenceenginefirstusestheinformationfromtheset_cdc_groupcommand.Ifthisinformationisincomplete,
thenittriestoautomaticallycompleteit.Whenthecommandset_cdc_groupcontainsonlythepathsdirectiveandno
synchronizerinformation,thenthesynchronizerisrecognizedautomatically.Similarly,ifyouprovideonlythesynchronizer
typeinformation,thentheparameters(speciallyforfifoandhandshake)iscomputedautomatically.
Syntax
set_cdc_groupnamegroup_name\
[synchro_typetype[synchro_parameters{...}]]\
paths{{s1t1}{s2t2}...{sntn}}
Arguments
nameSpecifythenameofthesynchronizercell.
synchro_typeSpecifythetypeofsynchronizer.Itcantakethe
followingvalues:
simple(forflipflopsynchronizers).
logic(forlogicsynchronizers).
complex(forcomplexsynchronizers).
fifo(forfifosynchronizers).
handshake(forhandshakesynchronizers).
synchro_parametersSpecifytheparameterscorrespondingtothesynchronizer.
pathsSpecifythesetofpaths,whichisjustacollectionoftuplesrepresentingdifferentpaths.

set_cdc_input_delay
Usetheset_cdc_input_delaycommandtospecifyaclockthatcontrolsthemodulepinsorportsspecifiedwiththeoption
pin_port_list.ThishelpsyoutoanalyzetheCDCissueinagivenmoduleandfocusondebugginginthatmodule.
Syntax
set_cdc_input_delayclockuser_clock_namedelay_valuedelay_value\
pin_port_list{PIN_PORT_LIST}
Arguments
clockSpecifytheclockname.
delay_valueSpecifythedelayvalue.Ledaactuallydiscardsthisvalue
andsoyoucanspecifyanyvalue.
pin_port_listSpecifythelistofpinsorportsthattheclockcontrols
Forexample,ifyouhaveamoduleSYNCHHRONIZER_MODULEthatcontainsthesynchronizerasfollows:
moduleSYNCHRONIZER_MODULE(out_data,in_data,clk)
Youcaninstantiatethismoduleinadesignandspecifyanewclock,say"clk1"thatcontrolsthepinin_data.Toavoid
debuggingthewholedesignandtojustfocusonthissynchronizermodule,youneedtospecifytheset_cdc_input_delay
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

13/15

9/20/2016

1ClockDomainCrossing

commandintheleda_clock_file.tclasfollows:
set_cdc_input_delayclockclk1delay_value1pin_port_list
{SYNCHRONIZED_MODULE.in_data}

set_cdc_output_delay
Usetheset_cdc_output_delaycommandtospecifytherelationshipbetweenanoutputpinandaclockpinofahardIP
cell.

create_cdc_clock
UsethecommandtospecifyagivenpinofthecellasaclockpinofahardIPcell.
Example
Theusageofthecommandsisasfollows:
YoucanspecifyhardIPblocksandprovide
informationabouttherelationbetweenclocks
anddataportsoftheblock.Acellwhichis
instantiatedfromalibraryanddoesnot
containanystatement(onlyportdefinition)is
consideredahardIPcell.Insuchcase,for
efficientCDCchecking,youcanspecifythe
relationshipbetweendatapinsandclockpins.
Thecommandtospecifyagivenpinofthecell
asaclockpinofahardIPcellisasfollows:
create_cdc_clocknameclock_namesource_objects
Thefollowingcommandsallowcreatinga
relationshipbetweenaclockpinandadata
pin.

set_cdc_input_delayclockclock_namedelay_value
set_cdc_output_delayclockclock_namedelay_value
Ifsuchinformationisprovidedtothechecker
thenefficientCDCcheckingcanbeperformed
evenondesignsusinghardIP.Else,nocheckingwillbepossiblesincenoconnectivityinformationisavailable.
Forexample,thepreviousillustrationshowsahardIPblockwithtwoclocks,twoinputports,andtwooutputports:
HeretheconnectionfromO1totheDinputofthethirdflipflophasaCDCissuethatcouldbedetectedifyouprovidethe
followingrelations:

create_cdc_clocknameCK1Top.HardCell.CK1
create_cdc_clocknameCK2Top.HardCell.CK2
set_cdc_output_delayclockCK110Top.HardCell.O1
set_cdc_output_delayclockCK210Top.HardCell.O2

Ifthecellhasonlyoneclock,allthepinswillbeconsideredtobecontrolledbythisclock.Theclockwillbedetected
automaticallybytheclockinferenceifitisconnectedtootherclocksignalsinthedesign.

extract_cdc_info
Usetheextract_cdc_infocommandtoruntheCDCinferencewithintheTclshellmodeinordertorefinethedifferent
parametersforthisinference.
Syntax
extract_cdc_info
Youneedtoexecutethiscommandonlyafterelaboration.Youcanthenusethereport_cdc_infocommandtovisualize
theinferredCDCelements.Youmayexecutethiscommandmanytimes,butitisimportanttoruntheclear_cdc_info
commandbeforeanycall.

report_cdc_info
Usethereport_cdc_infocommandtoprinttheinferredCDCelementsontheconsoleortoafile.
Syntax
report_cdc_info[filefilename]
Arguments
fileSpecifythefilename.
ThiscommandreportsalltheCDCelementssetusingthecommandset_cdc_groupsyntax.Thisallowsyoutovisualize
theinferredinformation.
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

14/15

9/20/2016

1ClockDomainCrossing

Whenyouredirecttheoutputofthiscommandtoafile,theconsoledoesnotdisplayanyinformation.
Youcancustomizeandsourcethisfilefromthetcl_shellorthedesign_configfiletohaveacleanCDCinference.

clear_cdc_info
Usetheclear_cdc_infocommandtoclearalltheinferredCDCinformations.
Syntax
clear_cdc_info
IntheTclshellmode,youmaybeinterestedtotryseveralparametersuntilyougetthecorrectCDCinference.Inorder
todothisincrementally,youcancalltheclear_cdc_infocommandtoreseteverythingandstarttheinferencewithnew
parameters.

set_cdc_parameter
Usetheset_cdc_parametercommandtospecifyavaluefortheparametersforCDCinference.
Syntax
set_cdc_parameter[parameterparameter_name][valuevalue]
Arguments
parameterSpecifytheparameter.
valueSpecifythevaluefortheparameter.
Thefollowingparametersshallbeusedwiththiscommand:
NB_FFS_FOR_SYNCHRONIZERUsethisparametertospecifythenumberofflipflopstobeusedfor
synchronization.Theminimumvalueofthisparameteris2.Thedefaultvalueis2.
ALLOW_BUF_INV_IN_SYNC_FFSThisparameterisusedtospecifyifthepathbetweenthesynchronizingflip
flopscontainbuffersorinverters.Ifsetto1,thepathbetweenthesynchronizingflipflopsmaycontainbuffers
orinverters.Thedefaultvalueis1.
MAX_NB_PATHSThisparameterisusedtospecifythemaximumnumberofpathallowedinavalidCDC
Element.Abovethisnumber,theCDCelementismarkedinvalidandnottakenintoaccountbyanyCDCchecks.
MAX_NB_DISPLAYED_PATHSThisparameterisusedtospecifythemaximumpathstobedisplayedinasingle
CDCviolation.Thedefaultvalueis10.
MAX_SYNCHRONIZATION_DEPTHTheCDCInferencealgorithmexplorestheinfluenceofcontrolsignalstofind
thecontrolledpaths.ThisparameterisusedtocontrolsthemaximumsequentialdepthtobeexploredbyLeda.
Thedefaultvalueofthisparameterissetto4,toallowLedatodetectallkindsofsynchronizers.Inadesign
usinglogicsynchronizers,itisrecommendedtolimitthisnumberto2or1.

https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html

15/15