1 CDC

11/19/2016
1ClockDomainCrossing
1
ClockDomainCrossing
Overview
AsmodernSystemonChip(SoC)designscontinuetofaceincreasingsizeand
complexitychallenges,multipleasynchronousclockdomainshavebeenemployedfor
differentI/Ointerfaces.ACDCbased(ClockDomainCrossing)designisadesignthat
hasoneclockasynchronousto,orhasavariablephaserelationwith,anotherclock.A
CDCsignalisasignallatchedbyaflipflop(FF)inoneclockdomainandsampledin
anotherasynchronousclockdomain.Transferringsignalsbetweenasynchronousclock
domainsmayleadtosetuporholdtimingviolationsofflipflops.Theseviolationsmay
causesignalstobemetastable.Evenifsynchronizerscouldeliminatethemeta
stability,incorrectuse,suchasconvergenceofsynchronizedsignalsorimproper
synchronizationprotocols,mayalsoresultinfunctionalCDCerrors.Functional
validationofsuchSoCdesignsisoneofthemostcomplexandexpensivetasks.
Simulationonregistertransferlevel(RTL)isstillthemostwidelyusedmethod.
However,standardRTLsimulationcannotmodeltheeffectofmetastability.
Withinoneclockdomain,properstatictiminganalysis(STA)canguaranteethatdata
doesnotchangewithinclocksetupandholdtimes.Whensignalspassfromoneclock
domaintoanotherasynchronousdomain,thereisnowaytoavoidmetastabilitysince
datacanchangeatanytime.
AstheCDCerrorsarenotaddressedandverifiedearlyinthedesigncycles,many
designsexhibitfunctionalerrorsonlylateintheirdesigncyclesorduringpostsilicon
verification.Severalcoveragemetricsareproposedtomeasurethevalidation's
adequacyandprogress,suchascodebasedcoverage,finitestatemachinecoverage,
andfunctionalcoverage.Nevertheless,thesecoveragemetricsdonothavedirect
relationswithCDCissues.
Toaddressclockdomainproblemsduetometastabilityanddatasamplingissues,
designerstypicallyemployseveraltypesofsynchronizers.Themostcommonlyused
synchronizerisbasedonthewellknowntwoflipflopcircuit.Othertypesof
synchronizersarebasedonhandshakingprotocolsorFIFOs.Inalimitednumberof
casesitmaybeusefultoemploydualclockFIFObuffersorothermechanisms
optimizedfordomainswithsimilarclockfrequencies.
Toaccuratelyverifyclockdomaincrossings,bothstructuralandfunctionalCDC
analysisshouldbecarriedout.Structuralclockdomainanalysislooksforissueslike
insufficientsynchronization,orcombinationallogicdrivingflipflopbased
https://filebox.ece.vt.edu/~athanas/4514/ledadoc/html/pol_cdc.html
1/27
11/19/2016
synchronizers.Functionalclockdomainanalysisusesassertionbasedverificationto
checkthecorrectusageofsynchronizers.Assertionsmaybeusedtofindproblems
suchasdatastabilityviolationswhengoingfromafastclockdomaintoaslowerone.
AssertionsgeneratedinPSLorotherassertionlanguagessuchasOpenVeraor
SystemVerilog,canthenbeusedinformalmodelcheckingorsimulation.
Thischapterisorganizedinthefollowingsections:
BackgroundPreparesthebackgroundrequiredforfurtherdiscussions.
SynchronizationTechniquesDiscussesthesynchronizationtechniques.
CDCAnalysisDiscussesthevariousstepsofCDCanalysis.
LedaCDCFlowProvidesinformationonthebasicLedaCDCtoolflow.
AutomaticallyGeneratedCDCAssertionsProvidesadetailedspecification
oftheLedasupportedassertions.
CDCAEPRuleUsage&NamingConventionsforAutomaticallyGenerated
CDCAEPFilesProvidesfurtherdetailofassertionrelatedtopics.
Background
Clockdomain
Aclockdomainisapartofadesignthathasaclockthatoperatesasynchronousto,or
hasavariablephaserelationshipwith,anotherclockinthedesign.Forexample,a
clockanditsderivedclock(viaaclockdivider)areinthesameclockdomainbecause
theyhaveaconstantphaserelationship.But,50MHzand37MHzclocks(whosephase
relationshipchangesovertime)definetwoseparateclockdomains.Figure1illustrates
threedifferentclocksinadesign,butsynchronoustoeachother.CLK,itsinversion
andD1(derivedfromCLK)aresynchronoustoeachother.
Figure1:
SynchronousClock
Aclockdomaincrossingsignalisasignalfromoneclockdomainthatissampledbya
registerinanotherclockdomain.Moredetailsoftheclockorigin/domaininference
enginearegivenin[1].
Metastability
Everyflipflop(FF)thatisusedinanydesignhasaspecifiedsetupandholdtime,or
thetimeinwhichthedatainputisnotlegallypermittedtochangebeforeandaftera
samplingclockedge.Thistimewindowisspecifiedasadesignparameterpreciselyto
keepadatasignalfromchangingtooclosetoanothersynchronizingsignalthatcould
causetheoutputtogometastable.
Figure2:SetupandholdtimeofaFlipflop
However,ifsomeinput(saydinFigure2)violatesthesetupandholdtimeofaFF,the
outputoftheFF(qinFigure2)keepsoscillatingforanindefiniteamountoftime.This
unstablevaluemayormaynotnondeterministicallyconvergetoastablevalue
(either0or1)beforethenext
2/27
11/19/2016
(either0or1)beforethenext
samplingclockedgearrives.
ExampleConsiderthe1bit
CDCsignaladat,whichis
sampledbyregisterbdat1in
Figure3.Sinceadatcomesfrom
adifferentclockdomain(aclk),
itsvaluecanchangeatanytime
withrespecttobdat1'sclock
(bclk).Ifthevalueofadat
changesduringbdat1'ssetup
andholdtime,theregister
bdat1might/mightnotassumea
statebetween0and1.Inthisstate,theregisterissaidtobemetastable.Ameta
stableregistermay/maynot(unpredictably)settletoeither0or1,causingillegal
signalvaluestobepropagatedthroughouttherestofthedesign.
Figure3:Metastabilityscenario
Inamulti
clock
design,
meta
stabilityis
inevitable,
butthere
arecertain
design
techniques
thathelp
toavoid
thechance
ofgetting
meta
stable.Thefollowingsectionprovidesanoverviewofdifferentsynchronization
techniques.
SynchronizationTechniques
Themainresponsibilityofasynchronizeristoallowsufficienttimesuchthatany
metasableoutputcansettledowntoastablevalueinthedestinationclockdomain.
Themostcommonsynchronizerusedbydesignersistwoflipflop(2FF)
synchronizersasshowninFigure4.Usuallythecontrolsignalsinadesignare
synchronizedby2FFsynchronizers.
Figure4:A2FFsynchronizer
SynchronizationofControlSignalswith2FFSynchronizers
Ina2FFsynchronizer,thefirstflipflopsamplestheasynchronousinputsignalinto
thedestinationclockdomainandwaitsforafulldestinationclockcycletopermitany
metastabilityonthestage1outputsignaltodecay,thenthestage1signalis
sampledbythesameclockintoasecondstageflipflop,withtheintendedgoalthat
thestage2signalisnowastableandvalidsignalsynchronizedintothedestination
clock
3/27
11/19/2016
clock
domain.It
is
theoreticallypossibleforthestage1signaltostillbesufficientlymetastablebythe
timethesignalisclockedintothesecondstagetocausethestage2signaltoalsogo
metastable.
However,notethatthemetastabilityisaprobabilisticphenomenon.Themetastable
outputconvergestoastablevaluewithtime.Therefore,eveniftheinputtothe
stage2FFstillremainsmetastable,theprobabilitythattheoutputofthestage2FF
willremainmetastableforafulldestinationclockcycleisasymptoticallycloseto
zero.Thiscalculationoftheprobabilityofthetimebetweensynchronizationfailures
(MTBF)isafunctionofmultiplevariablesincludingtheclockfrequenciesusedto
generatetheinputsignalandtoclockthesynchronizingflipflops.Formost
synchronizationapplications,a2FFsynchronizerissufficienttoremovealllikely
metastability.
Evenifa2FFsynchronizerhelpstopreventpropagationofmetastablevalues,for
thecorrectoperationofthedesign,someotherissuesneedstobetackled.These
issuesareexplainedinthefollowingsections.
InputDataStabilitytoAvoidDataLoss
Asynchronizercircuitensuresavoidingpropagationofmetastabilityintothe
destinationclockdomain,butitcan'tensurepropagationofcorrectvalueasthemeta
stablesignalnondeterministicallyconvergestoanystablevalue(1or0).However,
forcorrectoperationofthedesign,everytransitionontheinputsignalneedstobe
correctlypropagatedtothedestinationdomain.Toensurepreventingdataloss(losing
inputtransitions),theinputsignalneedstoholditsvalueaminimumamountoftime
suchthatthereisatleastasingledestinationsamplingclockedge,whichsamplesthe
inputvaluecorrectly(Nosetup/holdviolationFigure5givessuchanexample).This
stabilityconditionontheinputsignalisusuallycheckedbyputtingassertions.For
moreinformation,seethesection"FlipflopSynchronizers".
Figure5:Stabilityofinputsignalvalue
Gray
EncodingtoAvoidDataIncoherence(ForVectorCDCControl
Signals)
Similartothecaseofsyncingasinglebitcontrolsignal,thenaturalwaytotransfera
vectorcontrolsignalistomodeleachbitofthevectortobeseparatelysynchronized
4/27
11/19/2016
byaFFsynchronizer.YouhavealreadyseenthatevenifyouuseFFsynchronizers,it
usuallytakesmorethanonecycletopropagatecorrectinputvaluestothedestination
domain.Nowconsideracasewhereeverybitofthevectortakesatransitionvery
closetothedestinationclockedge.Alsoassumethat,byvirtueofmetastability,only
someofthesetransitionsarecorrectlycapturedbythedestinationdomaininthefirst
cycle.Now,ifthebitvaluesofthevectordecidethestateofthedestinationdomain,
afterthefirstcycle,thedestinationdomainmaymoveintoaninvalidstate.
Figure6:ScenarioindicatingDataIncoherence
Example
Supposea
vector
control
signalSig
[2:0]
crosses
from
Domain1
toDomain
2.Signal
Sigalso
decides
thestate
ofDomain
2andyou
assume
thatthevalue"100"ofSig[2:0]indicatesaninvalidstateforDomain2.Now,thinkof
asituation,wherethesignalSigwantstochangeitsvaluefrom"000"to"101"(both
indicatevalidstates).ThisrequiresthetwobitsSig[0]andSig[2]totransit
simultaneously.Boththesetransitionoccursveryclosetothedestinationsampling
clockedge(seeFig6).Byvirtueofmetastability,transitiononSig[2]getscaptured
correctlyandthetransitiononSig[0]ismissed.Inthisway,inthefirstcycleofthe
destinationclock,thesystemmovestostate"100"whichisinvalid.
Thiscasewouldnothavehappened,ifchangingthestatesofthedesignrequires
changingonlyasinglebitofthevector(Siginthiscase).Incaseofasinglebit
transition,eitherthattransitionwouldbecapturedinthedestinationdomainornot.
Thiswaythedesigneitherstaysinthepreviousstateormovetoavalidstate.
Therefore,forvectorcontrolsignals(multibitsignals,suchasaddressbuses),the
usualsolutionistouseaGraycodewhencrossingaclockdomainboundary.AGray
codeensuresthatonlyasinglebitchangesasthebuscountsupordown.The
presenceofgraycodingonvectorcontrolsignalcanbecheckedbyusingassertions.
Formoreinformation,seethesection"GrayCodeEncodingforVectorControl
Signals".
SynchronizationofCDCDataSignals
Oneofthechallengesindesigningamulticlockbasedsystemistoenablecorrect
transferofdatabusesfromoneclockdomaintoanother.Thedifficultyarises,as
individualbitsofadatabuscanchangerandomlywhilechangingclockboundaries.
Usingsynchronizers/graycodetohandlethepassingofdatabusisgenerally
unacceptable.
Threecommonmethodsforsynchronizingdatabetweenclockdomainsare:
5/27
11/19/2016
UsingMUXbasedsynchronizers.
UsingHandshakesignals.
UsingFIFOs(FirstInFirstOutmemories)tostoredatawithoneclock
domainandtoretrievedatawithanotherclockdomain.
PassingDatathroughMUXSynchronizer
Asshowninthefollowingfigure(Figure7),inaMUXsynchronizer,thecontrolpathis
usuallyFFsynchronizedwhilethesyncedincontrolsignalisusedtosynchronizethe
datapaths.
Figure7:AMUXsynchronizer
HandshakingDatabetweenClockDomains
Datacanbepassedbetweenclockdomainsusingasetofhandshakecontrolsignals,
dependingontheapplicationandtheparanoiaofthedesignengineer.Whenitcomes
tohandshaking,themorecontrolsignalsthatareused,thelongerthelatencytopass
datafromoneclockdomaintoanother.Thebiggestdisadvantageinusing
handshakingisthelatencyrequiredtopassandrecognizeallofthehandshaking
signalsforeachdatawordthatistransferred.Figure8showsatypicalhandshake
synchronizer.
Figure8:AHandshakeSynchronizer
Formanyopenended
datapassing
applications,asimple
twolinehandshaking
sequenceissufficient.
Thesenderplaces
dataontoadatabus
andthen
synchronizesa"req"
signal(request)to
thereceivingclock
domain.Whenthe
"req"signalis
recognizedinthe
destinationclockdomain,thereceiverclocksthedataintoaregister(thedatashould
6/27
11/19/2016
havebeenstableforatleasttwo/threesamplingclockedgesinthedestinationclock
domain)andthenpassesan"ack"signal(acknowledgement)throughasynchronizer
tothesender.Whenthesenderrecognizesthesynchronized"ack"signal,thesender
canchangethevaluebeingdrivenontothedatabus.
PassingDatabyFIFObetweenClockDomains
Oneofthemostpopularmethodsofpassingdatabetweenclockdomainsistousea
FIFO.AdualportmemoryisusedfortheFIFOstorage.Oneportiscontrolledbythe
sender,whichputsdataintothememoryasfastasonedataword(oronedatabitfor
serialapplications)perwriteclock.Theotherportiscontrolledbythereceiver,which
pullsdataoutofmemoryonedatawordperreadclock.Twocontrolsignalsareused
toindicateiftheFIFOisempty,full,orpartiallyfull.Twoadditionalcontrolsignalsare
frequentlyusedtoindicateiftheFIFOisalmostfulloralmostempty.Intheory,
placingdataintoasharedmemorywithoneclockandremovingthedatafromthe
sharedmemorywithanotherclockseemslikeaneasyandidealsolutiontopassing
databetweenclockdomains.Forthemostpartitis,butgeneratingaccuratefulland
emptyflagscanbechallenging.
Figure9:AdualclockFIFOSynchronizer
Userdefined
Synchronizers
Sometimes,youmayspecify
somecellstobe
synchronizers.Ifthiscellis
foundonthepathbetween
theFF,thepathhastobe
consideredassynchronized.
Notethatthecellitselfmay
haveotherinputsthanthe
sourceflipflopasshownin
thefollowingillustration.Thewayofspecifyingasynchronizerisexplainedinchapter
2,section"UsingTclCommand'set_cdc_synchronizer'".
Figure10:UserdefinedSynchronizer
CDCAnalysis
Followingarethebasicstepsfor
CDCanalysisandchecking
(irrespectiveoftoolset
implementation):
StructuralAnalysisto
IdentifyCDCSignals
andAppropriate
Synchronizers
ThemostimportanttaskofanyCDCstructuralanalyzeristofindoutallthesignals
(CDC)thatcrossclockboundaries.InLeda,ruleNTL_CDC01(Formoreinformation,
seethesection"CDCRuleset"inchapter2.)reportsalltheunsynchronizedCDC
7/27
11/19/2016
paths.HoweveraCDCpathmaybesynchronizedinthedestinationclockdomain.
Thus,identificationofsynchronizationschemesisveryimportanttoavoidreporting
falseCDCreports.Automaticdetectionofsynchronizersisverytoughandmay
dependontheunderlyingdesignprinciple.Therefore,sometime,thedesignerneeds
toprovideadditionalinformationfortheunderlyingsynchronizationschemes.
OnceextractionofinformationforalltheCDCpaths(synchronizedandun
synchronized)isover,youneedtoseewhethertherearestructuraldefectsbeforeand
afterthesynchronizers.
StructuralAnalysistoIdentifyStructuralDefectsBeforeandAfter
Synchronization
Manydesignteamschooseafewsynchronizerstyles,applythemtoallsignals
crossingclockdomainsandenforcetheirusagebydesignstylerulesanddesign
reviews.Althoughpropersynchronizersareessentialformulticlockdesigns,theyare
insufficienttoavoidallpossibleproblemsregardingsignalscrossingclockdomains.
Considerableextracaremustbetakeninthedesignprocesstoavoidtheseproblems.
Someofthestructuralproblemsthatmaycausefunctionalerrorsinmulticlockbased
systemsareasfollows.
ConvergenceintheCrossoverPath
UsingcombinationalelementsinaCDCpathbeforesynchronizationcanleadto
functionalproblems.Forexample,itisimportantthatglitchesinthedrivingclock
domainnotbepropagatedintothereceivingclockdomain.Sincetheflipflopsinthe
receivingclockdomaincansamplethesignalsfromthedrivingclockdomainatany
point,thereisnowaythroughstatictiminganalysistoensurethattheglitchwillnot
bepropagated.Figure11showsanexampleofcombinationallogic(convergence)that
couldcauseaglitchtopassfromoneclockdomaintoanother.RuleNTL_CDC02
detectsthisissue.
Figure11:GlitchpropagationduetoconvergenceinCDCPath
DivergenceintheCrossoverPath
DesignstyleswhichallowdivergentlogiconaCDCsignaltomultiplesynchronization
paths,maycausefunctionalerrors.AsFigure12illustrates,asinglecontrolsignal
(Trans_en)fromthesourceclockdomain(clk1)isusedtoactivateboththe"addr"
and"data"transferunitinthedestinationclockdomain(clk2).Thepurposeisto
enableboththelogicsatthesametime.Tomodelthis,fanoutsofTrans_enhasbeen
usedbeforethesynchronizationtakesplace.However,duetothepropagationdelay
anddifferentmetastablesettlingtimes,thetwofanouts('addr_en'and'data_en')
couldreachtheAddressandDatatransferlogicsatdifferenttimes.Thereforethese
twologicsmaystartatdifferenttimecausingfunctionalerrors.Thistypeofstructure
shouldbeavoidedbyfanningoutasingleFFsynchronized'commonenable'signalto
thetwotransferlogics.RuleNTL_CDC03detectsthisissue.
Figure12:Divergenceinthecrossoverpath
DivergenceofMetastableSignal
Usingametastablesignalinadesigncanbeerroneous.Thereforemultiplefanoutof
theoutputofthefirstFFofaFFsynchronizercancausefunctionalerrors.Rule
NTL_CDC04detectsthisissue.
8/27
11/19/2016
Figure
13:
Divergenceof
metastablesignal
Re
convergence
of
Synchronized
Signals
Synchronization
andglitch
eliminationalone
arenotenoughto
ensurereliable
transferofdataacrossclockdomains.Whenasignalgoesmetastable,asynchronizer
settlesitdown,butcannotguaranteetheprecisenumberofcyclesbeforethevalid
signalisavailableinthereceivingclockdomain.Therefore,if(1)twoindependent
signalsor(2)bitsofamultibitsignalareindependentlysynchronized(usingsame
typeofsynchronizersordifferenttypesofsynchronizers),thebitsmayarriveinthe
receivingclockdomainskewedwithrespecttooneanother.Averysimpleformofre
convergenceisshowninFigure14.RuleNTL_CDC05andNTL_CDC07detectthis
issue.
9/27
11/19/2016
Figure14:The
simplestformof
reconvergence
Therefore,even
whenmetastability
doesnotoccur,any
pairofbitscanget
outof
synchronizationif
routingdifferences
andelectrical
effectscausethe
twobitstohave
differentdelays
beforereaching
theirrespective
synchronizers.Itis
possibleforone
synchronizerto
sampleitsinput
andcapturea
signalchange
beforetheother
synchronizer
capturesthe
change,atwhichpointthetwocopiesofthesignalwillbeskewedbyacycleandno
longercorrelated.
LedahassixrulesthatcheckalltheabovestructuralchecksforCDCsignals.The
purposeoftheserulesistoprovidethefollowinginformation.Detaileddescriptionof
alltheLedastructuralchecksisprovidedinchapter2.
a.NTL_CDC01ReportsalltheunsynchronizedCDCpathsinthedesign.
b.NTL_CDC02Reportsallconvergenceinthecrossoverpathsinthedesign.
c.NTL_CDC03Reportsalldivergenceinthecrossoverpathsinthedesign.
d.NTL_CDC04Reportsdivergenceofanymetastablesignalinthedesign.
e.NTL_CDC05/07Reportsallkindsofreconvergenceofsynchronizedsignalsinthe
design.ThereisasubtledifferencebetweenruleNTL_CDC05andNTL_CDC07.For
moreinformationaboutthedifference,seethesection"CDCRuleset"inchapter2.
DeterminationandValidationofAppropriatePropertiesforEvery
Synchronizer
Justhavingasynchronizationcircuitconnectedisonlypartofthesolutionthe
associatedlogicmustinteractcorrectlywiththesynchronizationcircuittoensurevalid
operation.Toensurethis,assertionsneedtobespecifiedthatcheckcorrect
functionalityofthesynchronizationcircuitsandvalidatescorrectuseofthe
synchronizersbytheenvironmentinwhichtheyareinstantiated.Youautomatically
specifythesepropertiesonceforeverysynchronizerandautomaticallyattachthemto
allinstancesofthecorrespondingsynchronizationbuildingblocks.Thesupported
propertychecksforCDCsynchronizationcircuitelementsaregivenasfollows.For
moreinformationaboutthesepropertyspecifications,seethesection"Automatically
GeneratedCDCAssertions".
10/27
11/19/2016
FlipflopSynchronizer
Controlsignalstabilityassertions
MUXSynchronizer
Datasignalstabilityassertions
HandshakeSynchronizer
Datasignalstabilityassertions
Handshakeprotocolcheckassertions
FIFOSynchronizer
Graycodedassertionsforreadandwritepointers
FIFOprotocol(full/emptycheck)assertions
Dataintegritychecks
AmorecompletedescriptionoftheCDCAEP(automaticallyextractedproperties)
usageisgiveninthesection"CDCAEPRuleUsage".
LedaCDCFlow
ThecompleteLedaCDCflowisgiveninFigure15.ThemainCDCrelatedmodules
havebeencolored.TheCDCverificationenginetakeshelpoftheMagellan/VCSfor
checkingtheLedaCDCassertions(statically/dynamically).
Figure15:ThecompleteLedaCDCflow
AutomaticallyGeneratedCDCAssertions
11/27
11/19/2016
StructuralanalysisprimarilycheckswhetherthereexistsasynchronizerintheCDC
paths.Havingasynchronizerconnectedonlysolvestheverificationproblempartially.
Youadditionallyneedtocheckthefollowingtwofeatures.
1.Theenvironment(associatedlogic)mustinteractproperlywiththesynchronizer.
2.Thesynchronizeritselfbehavescorrectly.
Thesetwochecksaremandatorytoensurevalidoperationinreallife.TheAEP
(automaticallyextractedproperties)engineofLedageneratesandbindsassertions
thatcheckcorrectfunctionalityofthesynchronizersandvalidatescorrectuseofthe
synchronizersbyitsenvironment.Toidentifythesynchronizers,theAEPengineuses
theLedastructuralanalyzer.Inthefollowingparagraphs,youwillcategorically
enumeratethesynchronizerrelatedchecksforABV(assertionbasedverification).
FlipflopSynchronizers
Description
TheFFsynchronizers(showninFig16)formthebasicbuildingblockformostofthe
existingsynchronizationcircuits.AsimpleFFsynchronizerconsistsofm(>1)FF
modeledasashiftregisterrunningonthe'destinationclock'.Oncethepresenceofa
FFsynchronizerhavingmstagesisdetected,thefollowingpropertyisgeneratedto
ensurethatthedevicefunctionscorrectlyinpresenceofthissynchronizer.
Ifnoassumptionsaremadeabouttherelationshipbetweenthe'source'and
'destination'clockdomains,thenthefollowingpropertyensuresthatallinputsignal
valuescanbereliablytransportedtothesynchronizeroutput.
Inputdatavaluesmustbestableform+1destinationclockedges.
Figure16:FlipflopSynchronizers
Implementation
ExampleSVAcodesfortheabovepropertiesaregivenasfollows.Thisassertion
verifiesthestabilityofdinasobservedinthedestinationclockdomain.Signalrstis
theresetsignal(ifany,withtheappropriatepolarity)extractedfromthesynchronizer
FF,dinisthesinglebitinputtothefirstFFofthesynchronizer.
propertyp_stability
disableiff(rst)
@(<appropriate_edge>dclk)
!$stable(din)|=>$stable
(din)[*m])
endproperty
A_p_stability:assertproperty(p_stability)
12/27
11/19/2016
MUXSynchronizers
Description
Designstypicallyhavebothcontrolanddatapaths.Asshowninthefollowingfigure
(Fig17),thecontrolpathsareusuallyflopsynchronizedwhilethesyncedincontrol
signalsareusedtosynchronizethedatapaths.Here,thesedatapathsusea
controlledsynchronizerMUXforcrossingclockdomains.ThesecontrolMUXsare
sometimescalledDMUX,MUXsynchronizer,orsyncMUX.
Figure17:MUXsynchronizers
TheMUX
synchronizerhasthefollowingfunctionalrequirementstoensurecorrectresults.
sreadymustbestableform+1numberofdestinationclockcycles(modeled
bypropertyp_stabilityasexplainedinthesection"FlipflopSynchronizers").
datashouldremainstableinthedestinationclockdomainduringthedata
transferphase(indicatedbythetimedreadyisassertedindclkdomainand
untildreadydeassertedindclkdomain).
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,butmostcomedown
tothefundamentalworkingprincipleofsynchronizingasinglebitrequestintothe
destinationclockdomainandwaitingforasynchronizedversionoftheacknowledgeto
13/27
11/19/2016
comeback.Thedifferencesinthearchitectureofthehandshakesynchronizerstake
placebecauseofthehigherlevelprotocolsfortheassociatedinterfaces,data
management,etc.
Thehandshakesynchronizersusetwomflipflopsynchronizerstogeneraterequest
andacknowledgesignals.Theassociatedpropertiesaregivenasfollows.
InputDataStabilityforthemflipflopSynchronizersInputdatavalues
mustbestableform+1destinationclockedges(Reuseoftheassertionin
6.a)
ProtocolcheckThesenderandthereceivershouldfollowthehandshake
protocolcorrectly.
DataStabilityThedatamustbepresentwhenrequestisassertedonthe
destinationandremainstableuntiltheacknowledgmentisgenerated.
Figure18:Handshakesynchronizers
Implementation
Thefollowingassertionscovertheproperuseofthemflipflopsynchronizers,the
handshakeprotocol,andthecorrespondingdatastability.
1.InputDataStabilityforthemflipflopsynchronizers
Requestsignal(sreq)ofthesenderandAcknowledgementsignal(dack)mustbe
stableform+1'dclk'and'sclk'cyclesrespectivelyasimplementedinthesection"Flip
flopSynchronizers".
2.Protocolcheck
a.Thesendershouldcontinuetoassertthesreqsignaluntilsackisassertedatthe
sourceclock(sclk)domain.
b.Thesendershouldnotassertanewrequest(sreq)untiltheacknowledgementfor
theprevioustransferisdeassertedinthesourceclock(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:
14/27
11/19/2016
assertproperty(src_conformance(sclk,srst,!sreq,!sack))
Similarpropertiesforthedestinationclockdomain(dclk)aregivenasfollows.
Thereceivershouldcontinuetoassertthedacksignaltilldreqisassertedatthe
destinationclock(dclk)domain.
Thereceivershouldnotassertanewacknowledgement(dack),untilanewrequest
isreceivedinthedestinationclock(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
Thereceivershouldcontinuetoreceivestabledatatillitassertsthe
acknowledgment.
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,whichisusedwhenthehighlatencyof
thehandshakeprotocolscannotbetolerated,isthedualclockasynchronousFIFOas
showninFig19.Althoughmanyimplementationvariationsexist,thebasicoperation
isthesamedataiswrittenintoadualportRAMblockfromthesourceclockdomain
andtheRAMisreadinthedestinationclockdomain.Graycodedreadandwrite
pointersarepassedintothealternateclockdomain(usingtwomflipflop
synchronizers)togeneratefullandemptystatusflags.Thefollowingpropertiesare
generatedforthedualclockasynchronousFIFO:
TheproducerneverwriteswhentheFIFOisfull.
TheconsumerneverreadswhentheFIFOisempty.
ReadandWritepointersmustbegraycodedatsource.
Checksfordataintegrity(FIFOpreservesOrderandDataValue).
Figure19:FIFOBasedSynchronizer
Implementation
ThefollowingSVAcodeprovidesapossibleimplementationofthesechecks.The
15/27
11/19/2016
p_data_integrityassertionstartsanewthreadwithauniquecntvaluewhenever
wdataiswrittentotheFIFOandcheckstherdatavalueagainstthelocaldatavariable
wheneverthecorrespondingreadoccurs.Thefirst_matchisrequiredin
p_data_integritytoensurethepropertychecksrdataonthefirstoccurrenceofaread
withthecorrespondingcnt,otherwiseitwaitsforeverforardatamatchatthercnt
value.YoushouldcreateamoduleM,whichcontainstheassertions.Itisthenbound
tothenearesttoplevelmoduleinstancecontainingtheFIFOcode.
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)|=>
16/27
11/19/2016
@(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)
thatoriginateinoneclockdomainwiththeclockingeventsclkandthenreconverge
inanotherclockdomainwiththeclockingeventdclkwithoutusinganyoftheabove
handshakebasedsynchronizationschemes.Suchsignalsmustallhavemflipflop
synchronizersandinadditiontheymustbeGreycodeencodedbeforeenteringthe
synchronizers.Inthisway,whenthereisachangefromonestateofthemultibit
signaltoanother,onlyonebitchangesatatime.Itensuresthatthedestinationside
willnotsampleinconsistentstatevaluesduetodifferentskewsandmetastability
delaysoneachbit.TheGraycodemaybedecodedonthedestinationside,afterthe
individualsynchronizers.
Figure20:MultibitDataTransfer
code.
Oncesuch
multibitsignals
areidentified,
thepurposeof
thefunction
checksisto
verifythatstate
changesonthe
sourceside
beforeentering
thebit
synchronizers
followtheGray
Implementation
Eachindividualmflipflopsynchronizermustsatisfythesignalstabilityproperties
indicatedin1.1.2.Inaddition,theGraycodeassertionverifiesthatwheneverthereis
achangeofvalueondata_inthenextvaluediffersfromtheprecedingoneonlyinone
bit.Thevectordata_inisformedbyconcatenatingallthevariablesthatarepartofthe
multibitsignal.
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))
17/27
11/19/2016
Inthefollowingsection,youwillreadhowLedageneratestheseassertionsandhow
tousetheseassertionsforverification.
CDCAEPRuleUsage
ClockDomainCrossingisaglobalproblemandLedacurrentlyhasaneffective
solutionforCDCverification.Inthissection,theCDCrulesthatgenerateassertions
forverifyingfunctionalityofeachoftheCDCsynchronizerrecognizedinthedesign
(NTL_CDC06,andNTL_CDC14NTL_CDC16)areelaborated.Inaddition,thereisa
ruleNTL_CDC08,whichchecksforthecorrectimplementationofgreycodingforeach
vectorCDCcontrolsignaldetectedinthedesign.
Thepurposeofaddingthesefiverulesistoprovidethefollowinginformation:
NTL_CDC06IndicatesthatFFsynchronizershavebeenusedinthedesign.
ForeachoftheseFFsynchronizers,Ledageneratesassertionforchecking
thesignalstabilitypropertyoftheassociatedCDCcontrolsignal.
NTL_CDC08IndicatesthatvectorCDCcontrolsignalshavebeenusedin
thedesign.ForeachofsuchvectorCDCcontrolsignal,Ledagenerates
assertionforcheckingwhethertheassociatedvectorhasbeengraycoded.
NTL_CDC14IndicatesthatMUXsynchronizershavebeenusedinthe
design.ForeachofsuchMUXsynchronizers,Ledageneratesassertionsfor
checkingsignalstabilityoftheassociatedcontrolanddatasignals.
NTL_CDC15IndicatesthatHandshake(Push/Pull)synchronizershavebeen
usedinthedesign.ForeachofsuchHandshakesynchronizers,Leda
generatesassertionsforcheckingsignalstabilityoftheassociatedcontrol
anddatasignals.Inaddition,itgeneratesassertionsforcheckingthe
correctnessoftheassociatedhandshakeprotocol.
NTL_CDC16IndicatesthatFIFOsynchronizershavebeenusedinthe
design.ForeachofsuchFIFOsynchronizers,Ledageneratesassertionsfor
checkingempty/fullcriterionoftheassociatedFIFO.Inaddition,it
generatesassertionsforcheckingthe(a)datasignalintegrityoftheFIFO,
and(b)graycodingoftheFIFOread/writepointers.
Furthermore,thedetailedstructuralanalysisstatisticsfortheCDCsynchronizers
(suchasthenumbers,locationsetc.)canbeaccessedinthefollowingways:
WhileusingTclmode(switchleda+tcl_shell),thereisacommandcalled
'report_cdc_info',whichdisplaysalltypesofdetectedCDCstructures.
Thereare7rules(NTL_CDC01,NTL_CDC01_0,NTL_CDC01_1,...,
NTL_CDC01_6)whichwhenselecteddisplaysalltypesofCDCstructures
(synchronized,unsynchronized)detectedinadesignbyLeda.
Thesection"CDCTclInterface"providesdetailsofthecurrentCDCTclinterface.
Additionally,eachoftheCDCassertionspecificrulesNTL_CDC14NTL_CDC16also
providessignalspecificinformationabouttheCDCsynchronizers.Anexampleis
providedinthesection"CDCAnalysis".
NamingConventionforAutomaticallyGenerated
CDCAEPFiles
Foreachoftherulesspecifiedinprevioussection,Ledageneratesaseparate
assertionfile.Thisfilecontainsthetemplate/definitionfortheassociatedassertion.
18/27
11/19/2016
Thenamingconventionoftheassertionfiles(alsodefinitions)followsthespecific
issueforwhichtheassertionhasbeengenerated.Forexample,'aep_signal_stability.v'
filecontainsassertiondefinitionforcheckingthecontrolsignalstability.Thegenerated
filenamesalongwiththeirpurposesaregivenasfollows:
aep_signal_stability.vCheckscontrolsignalstability.
aep_mux_data_signal_stability.vChecksdatasignalstabilityofaMUX
synchronizer.
aep_handshake_data_signal_stability.vChecksdatasignalstabilityofa
Handshakesynchronizer.
aep_handshake_protocol_check.vCheckshandshakeprotocolchecksfora
Handshakesynchronizer.
aep_fifo_validate_assertions.vChecksfifoproperties(full/empty,data
integrity)foraFIFOsynchronizer.
Eachoftheseassertiondefinitionfilesaregeneratedonlyonce.Aseverycomplex
synchronizer(MUX,FIFO,andHandshake)usesFFsynchronizersforsynchronizingthe
controlsignals,aep_signal_satbility.visalsoreusedforeachofthem.
BindingtheAssertionDefinitionstotheDesign
Thegeneratedassertiondefinitionsareattachedtothedesignsignalsusingasetof
'bind'statements.Thesebindstatementsaregeneratedinaseparatefilenamed
'leda_top_properties.v'.Astherecanbemultipleinstancesofaspecificsynchronizer,
foreachoftheseinstances,aseparatebindstatementisgenerated.Theinstance
nameoftheassertiondefinitions(usedinthebindstatements)isnumbered.
Thegeneralideaforgeneratingpropertiesistouseprepackagemodulescontaining
assertionsandbindthemtotheverifieddesign.Thebindshouldtrytobindthelowest
possiblemoduleinthedesignhierarchyinordertoallowreductionofthedesignsize
fortheformaltool.Thebindcommandwillhavethegeneralfollowingsyntax:
bind<property_module_name>#(<parameters>)<bind_instance_name>(
<port_list>)
where,<bind_instance_name>isoftheform:
i_<RULE_LABEL>_<INSTANCE_NUMBER>
ForexampleiftherearethreeFFsynchronizersdetectedinadesign,therewouldbe
onecontrolsignalstabilityassertiondefinitionandthreeseparatebindstatements
generatedwiththreeuniqueassertioninstancesnamelyi_NTL_CDC06_1,
i_NTL_CDC06_2,andi_NTL_CDC06_3.
Sometimes,ifyouwanttoavoidexplosionofthesimulationtimeorMagellanrunning
time,youcanalsoboundthenumberofpropertiesthataregenerated.The
set_max_propertiescommandplacedinthedesignconfigurationfileallowscontrolling
thisnumber.ThiscommandisnotspecifictotheCDCManageritispartofthe
propertygenerationmanager.
set_aep_max_propertiesvaluemax_value
UsingGeneratedAssertionsinVCSandMagellan
19/27
11/19/2016
Thegeneratedassertionscanbeverifiedonthedesignusing(1)VCS(simulation
basedverification)or(2)Magellan(formalverification).Tosimplifybuildingofthe
assertions,afile(namedleda_prop_file.lst)containingthelistofautomatically
generatedfilesiscreated.Asaresult,youonlyneedtoattachfile'leda_prop_file.lst'
totheassociatedcheckertool.
Thesetofassertionrelatedfilesaregeneratedinadirectorynaming'ForMG'.This
directoryislocatedbydefaultin.leda_workorincase.leda_workismissinginthe
'rundirectory.
Moreover,forMagellan,aprojectfiletemplate(named'LedaMgPrjFile.prj')isalso
generated.You(sometimes)mayneedtoaddadditionalinformationliketheclock
periods,theresetconfigurationsetc.inthistemplate.Youdon'tneedtouseany
switchforgeneratingtheassertions.Theassertionsandtheassociatedfilesare
createdbydefault.
FailureDebugging
IncaseofanyCDCassertionviolationsforadesign,youneedtousethedebugging
aidsoftheassociatedchecker(VCS/Magellan)forfindingtherootcauseofthefailure.
UsingPropertyGenerationforChecking
SomeoftheCDCrulescanidentifycertainsituationsandgeneratepropertiesfor
dynamicandformalverification.Differentrulesgeneratingpropertiesarewrittenin
thesameSystemVerilogfileLEDA_<top>_properties.sv.Youcancontrolthenumber
ofpropertiesgeneratedbytheCDCrulesusingthefollowingcommand:
Syntax
set_aep_max_propertiesvaluemax_value
Arguments
valueSpecifythevaluetocontrolthenumberofpropertiesgeneratedby
CDCrules.
Thegeneralideaforgeneratingpropertiesistouseprepackagemodulescontaining
assertionsandbindthemtotheverifieddesign.Thebindtriestobindthelowest
possiblemoduleinthedesignhierarchyinordertoallowreductionofthedesignsize
fortheformaltool.Thebindcommandwillhavethegeneralfollowingsyntax:
Syntax
bind<property_module_name>#(<parameter>)<bind_instance_name>
(<port_list>)
where,<bind_instance_name>isoftheform
<RULE_LABEL>_<FILENAME>_<LINENUMBER>
AssertionLibrary
Insteadofgeneratingassertionsorpropertiesforeachcheck,Ledausesanassertion
librarypackagedwiththetool.Eachchecknowbindstothemodulecontainingthe
prepackagedproperty.Thislibraryisasetofmodulescontainingthenecessary
properties.Thesemodulesmayalsohaveparameterstosetdifferentoptionsorbit
width.
20/27
11/19/2016
DataSignalStability
Thefollowingassertionisgeneratedfortheconditionthatdatasignalsmustbestable
whilethecontrolsignalisasserted(fromsourceofcontrolpathasserteduntiltarget
ofcontrolpathdeasserted):
bindtopaep_assert_data_stable#(2,"Error:CDCdatasignalSmust
bestablewhilecontrolsignalisasserted")CDC06_test_v_40(ck2,rst,
DataIn,CtrlSource,CtrlTarget)
GreyCoding
Thefollowingassertionisgeneratedbytherulethatchecksiftwoormoresignals
aregraycoded(forexample,multibitcontrolsignals).
bindtopaep_assert_gray_coding#(BitWidth,"Error:multibitcontrol
signalsmustbegraycoded")CDC08_test_v_40(ck1,rst,CtrlSig)
DetailedExplanationsforRulesNTL_CDC05and
NTL_CDC07
BothoftheserulescheckacommonCDCscenariocalledthe"reconvergenceof
synchronizedsignals".
Asexplainedearlier,lossofcorrelationcanalsooccurwhentwoapparently
independentsignalsaresynchronizedseparately,butultimatelyfedintothesame
logic.Thisscenario,sometimesdubbedreconvergence,isespeciallydifficulttodetect
bymanualinspectionofthesynchronizationschemesduringdesignreview.
Anotherformofcorrelationlosscanoccurwhenasignalhasfanoutsintomultiple
synchronizers.Thetwobranchesofthesignalcanhavedifferentdelaystheelectrical
androutingeffectscanalsocausedifferentdelaysintheclocksgoingtothetwo
synchronizers.Therefore,ifthetwosynchronizerssampletheirinputsatdifferent
timesthenthetwocopiesofthesignalcanbeskewedbyacycleandnolonger
correlated.
Topreventthesecorrelationlossscenarios,LedahastwoCDCrulesthatconfirmthat
thereisno"reconvergenceofsynchronizedsignals"inthedesign.
Thefirstone"NTL_CDC05"confirmsthattwosignalssynchronizedintwodifferent
synchronizers(thusformingtwodifferentCDCelements)neverconverge.
Ontheotherhand"NTL_CDC07"confirmsthatCDCpathssynchronizedbythesame
synchronizer(thusgroupedinasingleCDCelement)neverconvergesafterbeing
synchronizedinthetargetclockdomain.
Examples:
ForCDC05rule,twoonebitsignalsaresynchronizedbytwo2FFsynchronizersintwo
differenttargetdomains(CLK2andCLK3),thusformstwodifferentCDCelements.
Afterthesynchronizationisdone,thesetwosignalsconvergeinanANDgate.
ForCDC07rule,asinglebitsignalhasfanoutstwo2FFsynchronizers.Afterthe
synchronizationisdone(inthesingletargetdomainCLK2thusformingasingleCDC
element),thesetwosignalsconvergeinanANDgate.TheHDLcodesandrelatedCDC
errormessagesaregivenasfollows.
21/27
11/19/2016
Formoreinformationabouttheserules,seethechapter"ClockDomainCrossing
Rules".
CDCTclInterface
ThefollowingisthecommandreferenceinformationforbuiltinTclcommandsthat
youcanusetomanagetheCDCrules:
set_cdc_ignored_path
Usetheset_cdc_ignored_pathcommandtospecifyapathtobeignoredbyCDC
analysis.
Syntax
set_cdc_ignored_path[fromsource_ff_name]\
[totarget_ff_name]
Arguments
fromSpecifythesourceflipflopname.
toSpecifythetargetflipflopname.
Althoughfromandtoareoptional,atleastoneoftheoptionsmustbeused.Ifyou
don'tspecifyanyoneoftheoptions,thenit'svalueisconsideredas'any'.For
example:
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).
synchro_parametersSpecifytheparameterscorrespondingtothesynchronizer.
Forallthespecifiedsynchronizers,theparametersarealistofstringsthatspecify
somevalues.Thefollowingtableliststheparametersthatareapplicableforvarious
synchronizers.
Table2:Parametersofdifferentsynchronizers
22/27
11/19/2016
Parametersapplicable
toallsynchronizers
Parametersapplicable
toFIFOsynchronizer
Parametersapplicableto
handshakesynchronizer
source_clock
source_clock
source_clock
target_clock
target_clock
target_clock
write_signal
handshakekind(canbe
pushhanshakeor
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.This
commandenablesyoutocreateaCDCelementandspecifyadditionalinformationlike
synchronizationtype.Inotherwords,itallowsacompletespecificationoftheCDC
informationfromyou.ThiscommandisgeneratedbythedumpmodeoftheCDC.
AfterCDCinferenceindumpmode,alltheinferredinformationisdumpedusingthe
set_cdc_groupcommand.Ifyouwanttomodifytheinferredinformationorgrouping
ofthedifferentpaths,youneedtoeditthedumpedfileandadapttheinformation.
Therulesconcerningreconvergentpathsandgraycodingofcontrolpathsarehighly
dependentonthegrouping.So,makesurethatthegroupsareformedcorrectly.In
additiontotheautomaticinferencealgorithmandthepossibilitytodefine
synchronizer,LedaalsoofferstheflexibilitytofullycustomizetheCDCinformation.
TheCDCinferenceenginefirstusestheinformationfromtheset_cdc_group
command.Ifthisinformationisincomplete,thenittriestoautomaticallycompleteit.
Whenthecommandset_cdc_groupcontainsonlythepathsdirectiveandno
synchronizerinformation,thenthesynchronizerisrecognizedautomatically.Similarly,
ifyouprovideonlythesynchronizertypeinformation,thentheparameters(specially
forfifoandhandshake)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).
23/27
11/19/2016
handshake(forhandshakesynchronizers).
synchro_parametersSpecifytheparameterscorrespondingtothesynchronizer.
pathsSpecifythesetofpaths,whichisjustacollectionoftuplesrepresenting
differentpaths.
set_cdc_input_delay
Usetheset_cdc_input_delaycommandtospecifyaclockthatcontrolsthemodule
pinsorportsspecifiedwiththeoptionpin_port_list.Thishelpsyoutoanalyzethe
CDCissueinagivenmoduleandfocusondebugginginthatmodule.
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_MODULEthatcontainsthe
synchronizerasfollows:
moduleSYNCHRONIZER_MODULE(out_data,in_data,clk)
Youcaninstantiatethismoduleinadesignandspecifyanewclock,say"clk1"that
controlsthepinin_data.Toavoiddebuggingthewholedesignandtojustfocuson
thissynchronizermodule,youneedtospecifytheset_cdc_input_delaycommandin
theleda_clock_file.tclasfollows:
set_cdc_input_delayclockclk1delay_value1pin_port_list
{SYNCHRONIZED_MODULE.in_data}
set_cdc_output_delay
Usetheset_cdc_output_delaycommandtospecifytherelationshipbetweenanoutput
pinandaclockpinofahardIPcell.
create_cdc_clock
UsethecommandtospecifyagivenpinofthecellasaclockpinofahardIPcell.
Example
Theusageofthecommandsisasfollows:
YoucanspecifyhardIPblocksandprovideinformationabouttherelationbetween
clocksanddataportsoftheblock.Acellwhichisinstantiatedfromalibraryanddoes
notcontainanystatement(onlyportdefinition)isconsideredahardIPcell.Insuch
case,forefficientCDCchecking,youcanspecifytherelationshipbetweendatapins
andclockpins.
ThecommandtospecifyagivenpinofthecellasaclockpinofahardIPcellisas
follows:
24/27
11/19/2016
create_cdc_clock
The
following
commandsallowcreatingarelationshipbetweenaclockpinandadatapin.
set_cdc_input_delayclockclock_namedelay_valueport_pin_list
set_cdc_output_delayclockclock_namedelay_valueport_pin_list
IfsuchinformationisprovidedtothecheckerthenefficientCDCcheckingcanbe
performedevenondesignsusinghardIP.Else,nocheckingwillbepossiblesinceno
connectivityinformationisavailable.
Forexample,thepreviousillustrationshowsahardIPblockwithtwoclocks,twoinput
ports,andtwooutputports:
HeretheconnectionfromO1totheDinputofthethirdflipflophasaCDCissuethat
couldbedetectedifyouprovidethefollowingrelations:
create_cdc_clocknameCK1Top.HardCell.CK1
create_cdc_clocknameCK2Top.HardCell.CK2
set_cdc_output_delayclockCK110Top.HardCell.O1
set_cdc_output_delayclockCK210Top.HardCell.O2
Ifthecellhasonlyoneclock,allthepinswillbeconsideredtobecontrolledbythis
clock.Theclockwillbedetectedautomaticallybytheclockinferenceifitisconnected
tootherclocksignalsinthedesign.
extract_cdc_info
Usetheextract_cdc_infocommandtoruntheCDCinferencewithintheTclshellmode
inordertorefinethedifferentparametersforthisinference.
Syntax
25/27
11/19/2016
extract_cdc_info
Youneedtoexecutethiscommandonlyafterelaboration.Youcanthenusethe
report_cdc_infocommandtovisualizetheinferredCDCelements.Youmayexecute
thiscommandmanytimes,butitisimportanttoruntheclear_cdc_infocommand
beforeanycall.
report_cdc_info
Usethereport_cdc_infocommandtoprinttheinferredCDCelementsontheconsole
ortoafile.
Syntax
report_cdc_info[filefilename]
Arguments
fileSpecifythefilename.
ThiscommandreportsalltheCDCelementssetusingthecommandset_cdc_group
syntax.Thisallowsyoutovisualizetheinferredinformation.
Whenyouredirecttheoutputofthiscommandtoafile,theconsoledoesnotdisplay
anyinformation.
Youcancustomizeandsourcethisfilefromthetcl_shellorthedesign_configfileto
haveacleanCDCinference.
clear_cdc_info
Usetheclear_cdc_infocommandtoclearalltheinferredCDCinformations.
Syntax
clear_cdc_info
IntheTclshellmode,youmaybeinterestedtotryseveralparametersuntilyouget
thecorrectCDCinference.Inordertodothisincrementally,youcancallthe
clear_cdc_infocommandtoreseteverythingandstarttheinferencewithnew
parameters.
set_cdc_parameter
Usetheset_cdc_parametercommandtospecifyavaluefortheparametersforCDC
inference.
Syntax
set_cdc_parameter[parameterparameter_name][valuevalue]
Arguments
parameterSpecifytheparameter.
valueSpecifythevaluefortheparameter.
Thefollowingparametersshallbeusedwiththiscommand:
NB_FFS_FOR_SYNCHRONIZERUsethisparametertospecifythenumber
offlipflopstobeusedforsynchronization.Theminimumvalueofthis
26/27
11/19/2016
parameteris2.Thedefaultvalueis2.
ALLOW_BUF_INV_IN_SYNC_FFSThisparameterisusedtospecifyifthe
pathbetweenthesynchronizingflipflopscontainbuffersorinverters.Ifset
to1,thepathbetweenthesynchronizingflipflopsmaycontainbuffersor
inverters.Thedefaultvalueis1.
MAX_NB_PATHSThisparameterisusedtospecifythemaximumnumber
ofpathallowedinavalidCDCElement.Abovethisnumber,theCDC
elementismarkedinvalidandnottakenintoaccountbyanyCDCchecks.
MAX_NB_DISPLAYED_PATHSThisparameterisusedtospecifythe
maximumpathstobedisplayedinasingleCDCviolation.Thedefaultvalue
is10.
MAX_SYNCHRONIZATION_DEPTHTheCDCInferencealgorithmexplores
theinfluenceofcontrolsignalstofindthecontrolledpaths.Thisparameter
isusedtocontrolsthemaximumsequentialdepthtobeexploredbyLeda.
Thedefaultvalueofthisparameterissetto4,toallowLedatodetectall
kindsofsynchronizers.Inadesignusinglogicsynchronizers,itis
recommendedtolimitthisnumberto2or1.
27/27

1 CDC

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1 CDC

Enviado por

Direitos autorais:

Formatos disponíveis

11/19/2016

Você também pode gostar