OCP Comliance Checks_101905 - OCP-IP

OCP 2.0 / 2.1Compliance ChecksVersion 0.15OCP-IP Functional Verification Working GroupOCP-IP Confidential

OCP 2.0 / 2.1Compliance ChecksThe Overriding Document On OCP Certification Is the Current OCP SpecificationOCP-IP Confidential

Copyright © 2005 OCP-IPThis document contains material that is confidential to OCP-IP and its members and licensors. The user should assume that all materialscontained and/or references d in this document are confidential and proprietary unless otherwise indicated or apparent from the nature ofsuch materials (for example, references to publicly available forms or documents). Disclosure or use of this document or any materialcontained herein, other than as expressly permitted, is prohibited without the prior written consent of OCP-IP or such other party thatmay grant permission to use its proprietary material.The trademarks, logos, and service marks displayed in this document are the registered and unregistered trademarks of OCP -IP, itsmembers and its licensors.The copyright and trademarks owned by OCP-IP, whether registered or unregistered, may not be used in connection with any product orservice that is not owned, approved or distributed by OCP-IP, and may not be used in any manner that is likely to cause customerconfusion or that disparages OCP-IP. Nothing contained in this document should be construed as granting by implication, estoppel, orotherwise, any license or right to use any copyright without the express written consent of OCP-IP, its licens ors or a third party owner ofany such trademark.iiDISCLAIMERThis OCP -IP document is provided "as is" with no warranties whatsoever, including any warranty of merchantability, noninfringement,fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification or sample. OCP-IP disclaims allliability for infringement of proprietary rights, relating to use of information in this document. No license, express or implied, by estoppelor otherwise, to any intellectual property rights is granted herein.OCP International Partnership (OCP-IP) disclaims all warranties and liability for the use of this document and the information containedherein and assumes no responsibility for any errors that may appear in this document, no r does OCP-IP make a commitment to updatethe information contained herein.Contact the OCP-IP office to obtain the latest revision of this document.Questions regarding this document or membership in OCP-IP may be forwarded to:OCP-IPwww.ocpip.orgE-mail: admin@ocpip.orgPhone: +1 503-291-2560Fax: +1 503-297-1090OCP-IP Technical Supporttechsupport@ocpip.orgOCP-IP Confidential

Revision HistoryiiiVersion Date Author Comments0.1 08/05/20040.2 09/11/20040.3Samuel Dellacherie(TransEDA)Samuel Dellacherie(TransEDA)Original text-based proposaltakes into account :Sonics list of checksYogitech list of checksnew TransEDA list v1.5.4TI feedback (Jeroen Vliegen)Yogitech feedback (Natale Barsotti)0.419/11/2004Samuel Dellacherie(TransEDA)Reorganization of all properties for a better clarity0.50.6 14/02/20050.7 08/04/200508 30/04/2005Samuel Dellacherie(TransEDA)Samuel Dellacherie(TransEDA)Samuel Dellacherie(TransEDA)John Robiola(Sonics Inc.)Feedback from OCP-IP support and xls file from TIElimination of:cross-constraint sectionperformance propertiessampling propertiesIncludes corrections based on the final golden xls sheetfrom the FVWG. Follows the order of the golden xls list.Adds references to the OCP SpecificationMinor correctionsAdded summary table and formatted document to conform0.9 06/06/2005Samuel Dellacherie(TransEDA)0.10 05/07/2005 Samuel DellacherieFilled-in all blanks, added intro, changed section namesAdded Jeroen’s Intro and formattingCorrections based on Jeroen’s, Anshul’s and Ravi’sfeedbacks. Plus minor changes.0.11 04/08/20050.12 29/08/2005Jeroen Vliegen(Texas Instruments)Jeroen Vliegen(Texas Instruments)Incorporated feedback of Drew Wingard (Sonics/SWG)Rewrote introduction chapter for more clarityAdded acknowledgements1) Added Steven McMaster’s (Synopsys) feedback for theformal verification paragraph (new text)2) Added Anssi Haverinen’s (Nokia) feedback for property3.4.113) Added Christophe Sucur’s (TI) feedback4) Updated figure 1 and former core_rtl.conf paragraphbased on FVWG discussion of 16/08/20055) Added Yogitech’s feedback on document v0.116) Added the 2.1 OCP properties7) Added 2.1 specification references8) did some overall formattingOCP-IP Confidential

ivVersion Date Author Comments0.13 05/09/2005 Samuel Dellacherie1) mod ifications to the « dynamic verification » and « staticverification » sub-sections2) added section 2.3 on which parameters activate whichchecks3) checked Anshul’s feedback4) erased the “transaction” properties of 2.1 that wereduplicates of the 2.0 versionsMany updates. Mainly around 2.1 properties. Please referto “changes_v14.xls” for the entire list!0.14 22/09/2005 Jeroen VliegenAdd burst_hold_MTagInOrderChange name of … see email Samuel0.15 03/10/2005 Jeroen VliegenFinal review of FVWG required 2 changes:1. Add burst_hold_MTagInOrder property2. Changeburst_order_MTagID_when_MTagInOrder_zero toburst_hold_MTagID_when_MTagInOrder_zeroTables are updated / TOC is updated / d ocument is readyfor Tec Writer review !!OCP-IP Confidential

vContents1 Introduction 21.1 OCP Compliance Definition ............................................................................................................21.2 OCP Configurability...........................................................................................................................21.3 Verification Techniques....................................................................................................................21.4 This Document Contains .................................................................................................................21.5 Acknowledgements ...........................................................................................................................22 Compliance Checks Tables 22.1 Introduction...........................................................................................................................................22.2 Table of Checks ..................................................................................................................................22.3 Activation Table ..................................................................................................................................23 Compliance Checks Details 23.1 Introduction...........................................................................................................................................23.2 Dataflow Signals Checks .................................................................................................................23.2.1 signal_valid__when_reset_inactive ............ 23.2.2 request_valid_ ............................... 23.2.3 datahs_valid_ ................................ 23.2.4 response_valid_ .............................. 23.2.5 request_valid_MTagInOrder ............................ 23.2.6 response_valid_STagInOrder ........................... 23.2.7 request_valid_MTagID_when_MTagInOrder_zero ........... 23.2.8 datahs_valid_MDataTagID_when_MTagInOrder_zero ........ 23.2.9 response_valid_STagID_when_STagInOrder_zero .......... 23.3 DataFlow Phase Checks .................................................................................................................23.3.1 request_exact_SThreadBusy ............................ 23.3.2 request_hold_ ................................ 23.3.3 request_value_MCmd_ ......................... 23.3.4 request_value_MAddr_word_aligned ..................... 23.3.5 request_value_MAtomicLength_0x0 ...................... 23.3.6 request_value_MBurstSeq_ ................... 23.3.7 request_value_MBurstSeq_0x7 .......................... 23.3.8 request_value_MBurstLength_0x0 ....................... 23.3.9 request_value_MByteEn_force_aligned .................. 23.3.10 request_value_MThreadID .............................. 23.3.11 datahs_exact_SDataThreadBusy ......................... 23.3.12 datahs_hold_ ................................. 23.3.13 datahs_value_MDataByteEn_force_aligned ............... 23.3.14 datahs_value_MDataThreadID ........................... 23.3.15 response_exact_MThreadBusy ........................... 23.3.16 response_hold_ ............................... 23.3.17 response_value_SResp_FAIL_without_WRC ................ 2OCP-IP Confidential

vi3.3.18 response_value_SThreadID ............................. 23.3.19 request_hold_MTagInOrder ............................. 23.3.20 response_hold_STagInOrder ............................ 23.3.21 request_hold_MTagID_when_MTagInOrder_zero ............ 23.3.22 datahs_hold_MDataTagID_when_MTagInOrder_zero ......... 23.3.23 response_hold_STagID_when_STagInOrder_zero ........... 23.3.24 request_value_MTagID_when_MTagInOrder_zero ........... 23.3.25 datahs_value_MDataTagID_when_MTagInOrder_zero ........ 23.3.26 response_value_STagID_when_STagInOrder_zero .......... 23.3.27 datahs_order_MDataTagID_when_MTagInOrder_zero ........ 23.3.28 response_reorder_STagID_tag_interleave_size .......... 23.3.29 response_reorder_STagID_overlapping_addresses ........ 23.4 Dataflow Burst Checks .....................................................................................................................23.4.1 burst_hold_MBurstLength_precise ...................... 23.4.2 burst_hold_ .................................. 23.4.3 burst_hold__STRM ............................. 23.4.4 burst_phase_order_reqdata_together ................... 23.4.5 burst_sequence_MAddr_INCR ............................ 23.4.6 burst_sequence_MAddr_STRM ............................ 23.4.7 burst_sequence_MAddr_WRAP ............................ 23.4.8 burst_sequence_MAddr_XOR ............................. 23.4.9 burst_value__ ...................... 23.4.10 burst_value__SINGLE .......................... 23.4.11 burst_value_MAddr_INCR_burst_aligned ................. 23.4.12 burst_value_MAddr_INCR_no_wrap ....................... 23.4.13 burst_value_MBurstLength_ .................. 23.4.14 burst_value_MBurstLength_INCR_burst_aligned .......... 23.4.15 burst_value_MBurstPrecise_ ................. 23.4.16 burst_value_MBurstPrecise_INCR_burst_aligned ......... 23.4.17 burst_value_MBurstPrecise_SRMD ....................... 23.4.18 burst_value_MBurstSeq_UNKN_SRMD ...................... 23.4.19 burst_value_MCmd_ ........................... 23.4.20 burst_value_MDataLast_ ........................ 23.4.21 burst_value_MReqLast_MRMD ............................ 23.4.22 burst_value_MReqLast_SRMD ............................ 23.4.23 burst_value_SRespLast_ ......................... 23.4.24 burst_hold_MTagID_when_MTagInOrder_zero .............. 23.4.25 burst_hold_MTagInOrder ............................... 23.5 DataFlow Transfer Checks .............................................................................................................23.5.1 transfer_phase_order_datahs_before_request_begin ..... 23.5.2 transfer_phase_order_datahs_before_request_end ....... 23.5.3 transfer_phase_order_response_before_request_begin ... 23.5.4 transfer_phase_order_response_before_request_end ..... 23.5.5 transfer_phase_order_response_before_datahs_begin .... 2OCP-IP Confidential

3.5.6 transfer_phase_order_response_before_datahs_end ...... 23.5.7transfer_phase_order_response_before_last_datahs_begin_ SRMD_wr 23.5.8 transfer_phase_order_response_before_last_datahs_end_SRMD_wr .............................................. 23.6 DataFlow ReadEx Checks ..............................................................................................................23.6.1 rdex_hold_ ................................... 23.6.2 rdex_hold_ .................................. 23.6.3 rdex_lock_release_no_WR/WRNP ......................... 23.6.4 rdex_lock_release_no_burst_allowed ................... 23.7 Sideband Checks ...............................................................................................................................23.7.1 signal_valid_ ................................ 23.7.2 signal_valid_ when_reset_inactive ........... 23.7.3 signal_hold__16_cycles ....................... 23.7.4 signal_hold_Control_after_reset ...................... 23.7.5 signal_hold_Control_2_cycles ......................... 23.7.6 signal_hold_Control_ControlBusy_active ............... 23.7.7 signal_hold_ControlWr_after_reset .................... 23.7.8 signal_value_ControlWr_Control_transitioned .......... 23.7.9 signal_value_ControlWr_ControlBusy_active ............ 23.7.10 signal_hold_ControlWr_2_cycles ....................... 23.7.11 signal_value_ControlBusy ............................. 23.7.12 signal_hold_StatusRd_2_cycles ........................ 23.7.13 signal_value_StatusRd_StatusBusy_active .............. 2viiOCP-IP Confidential

1 IntroductionThis document contains the OCP 2.0 / 2.1 compliance checks. It was developed by leading industryexperts participating in the Open Core Protocol International Partnership Functional VerificationWorkgroup (OCP-IP TM FVWG).The purpose of this document is to empower Verification IP/VIP developers to create OCP compliancychecking solutions in the language and tool of their choice.The technical materials listed in this document are based on the OCP 2.0 / 2.1 specifications. They areguidelines to verify an IP/VIP for OCP 2.0 / 2.1 compliance. In all cases, the “Part I Specification” ofthe OCP 2.0 / 2.1 specifications is the definitive reference. Any reference made to “Part II Guidelines”of the OCP 2.0 / 2.1 specifications in this document is not definitive. The specification supersedes theguidelines.This document is maintained by the OCP-IP TM , a trade organization solely dedicated to OCP,supporting products and services. For all technical support inquiries, please contacttechsupport@ocpip.org. For any other information or comments, please contact admin@ocpip.org.OCP-IP Confidential

Introduction 21.1 OCP Compliance DefinitionThe OCP compliance definition is stated on page three (3) of the OCP 2.0 / 2.1 s pecifications.For a core to be considered OCP compliant, it must satisfy the following conditions:1. The core must include at least one OCP interface.2. The core and OCP interfaces must be described using an RTL configuration file with thesyntax specified in Chapter 6 of the OCP 2.0 / 2.1 specifications.3. Each OCP interface on the core must:a. Comply with all as pects of the OCP interface specification.b. Have its timing described using a synthesis configuration file following the syntaxspecified in Chapter 7 of the OCP 2.0 / 2.1 specifications.OCP-IP Confidential

Introduction 31.2 OCP ConfigurabilityThe main challenge in developing an OCP VIP lies in adequately contemplating the high degree ofconfigurability of OCP. Figure 1 shows the different inputs that can affect OCP configurability.OCP Interface ConfigurationTo properly define the OCP interface(s) of an IP/VIP, the following contexts must be considered:a) Open System ContextIn the context of an open system, upon delivery of an IP /VIP all the OCP interface(s) must bedescribed using the _rtl.conf syntax. The existence of the _rtl.conf file is a basicrequirement for OCP compliance and there is no exception. The metadata properties described in the_rtl.conf file are clearly specified in Chapter 6 of the OCP 2.0 / 2.1 specifications .For a configurable IP/VIP supporting multiple OCP configurations, several _rtl .conf files are tobe provided. If possible, these files may be produced with a generator.b) Closed S ystem ContextIn the context of a closed system, the verification of an IP /VIP with one (1) or more OCP interfacesmay, or may not, be driven from a _rtl.conf file. A vendor is free to implement any othersolution. For example, a VERA verification environment could have a VERA object to control the OCPstimuli generators in its VIP instead of a _rtl.conf file.However, if the IP/VIP is being developed in a closed system context for delivery in an open systemcontext, then the verification must include the _rtl.conf file(s) and, if applicable, the_rtl.conf generator which the IP/VIP is to be delivered with.OCP Configuration Parameters ExtractionDepending on the system context, the VIP must extract the OCP configuration parameters from the_rtl.conf file (open) or from any other solution (closed). Parameters for which the value is notexplicitly specified must be retrieved using the configuration parameter defaults summarized inTable 22 of the OCP 2.0 specification or Table 25 of the OCP 2.1 specification. Note that certainparameters are always needed in certain configurations, and for those, no default is specified. Forexample: addr_wdth must always be specified if addr == 1.OCP Configuration Parameters Cross-constraints CheckingOnce all the OCP configuration parameters are known, illegal OCP interface parameter configurationsmust be flagged. Chapter 4 of the OCP 2.0 / 2.1 specifications contains most of the cross-constraints.For example: if readex_enable is set to 1, write_enable or writenonpost_enable must be set to 1.Select the Relevant ChecksBased on the OCP configuration parameters, select a subset of the checks in the VIP OCP library.This subset will be used for the actual verification. Note that if a signal used by a check is notconfigured in the OCP interface and if no other tie-off value is specified, Table 12 of the OCP 2.0OCP-IP Confidential

Introduction 4specification or Table 13 of the OCP 2.1 specification specifies the inferred default tie-off values. Forexample: MBurstPrecise default tie-off value is ‘1’ or precise.Compliance CheckingCheck the compliance of the DUT OCP interface(s) using static or dynamic verification techniques. Formore details , s ee 1.3, Verification Techniques.OCP-IP Confidential

Introduction 5Figure 1: OCP ConfigurabilityOCP InterfaceConfigurationConfiguration Parameters DefaultsTable 22, OCP 2.0 specificationTable 25, OCP 2.1 specificationOCP Configuration ParametersOCPConfigurationParametersCrossConstraintsCheckingSignal Default Tie-off ValuesRelevantChecksTable 12, OCP 2.0 specificationTable 13, OCP 2.1 specificationSub-setDatabase ContainingALL OCP ComplianceChecksDynamicVerificationStaticVerificationOCP-IP Confidential

Introduction 61.3 Verification TechniquesDynamic VerificationThis verification technique relies on the following key elements:• A ‘good’ set of stimuli• Protocol checks• Functional + code coverageIn summary, the methodology consists of driving a set of stimuli through the OCP interface into theDUT. The VIP contains a monitor which traces the OCP interface activity. The traces must be checkedby a protocol checker to make sure that the protocol is never violated. The quality of the set of stimulimust be assessed using functional and code coverage.Note that the OCP configuration parameters determine:Stimuli• Which protocol checks must be active .• How the OCP functional coverage is defined.The ‘good’ set of stimuli is not described in this document. This decision was made because it is nottrivial for traditional directed-test methodologies to define a ‘golden’ set of stimuli for any OCP interfaceconfiguration. It is up to the Verification Engineer to implement a smart and efficient set of stimuli. Forexample, this may be done using constraint-driven random stimuli generation. As indicated before, thequality of the stimuli must be assessed using both functional and code coverage (see below).Protocol ChecksThe protocol checker is a passive component which monitors whether the OCP protocol is violated fora specific set of OCP configuration par ameters. The protocol checker can be written in severallanguages ; for example: HDL, PSL, SVA, E, VERA. The protocol checker must be instantiated oneach OCP interface of the DUT.Note that the names of the protocol checks must be matched with the names gi ven to the compliancechecks described in this document such that this document can easily be referenced by a VerificationEngineer.Functional CoverageThe quality of the set of applied stimuli must be measured with OCP functional coverage. Onehundred percent OCP functional coverage must be targeted. Additionally, code coverage must be runon the RTL to determine whether there are any verification holes such as uncovered FSM states ormissed branches. Based on the code coverage analysis, additional coverage metrics may be required.The guidelines for the OCP functional coverage will be given in the next release of this document.Additional coverage metrics needed , based on code-coverage analysis, are design dependent andtherefore are out of the scope of this document.OCP-IP Confidential

Introduction 7Static VerificationThis verification approach is also referred to as 'formal verification'. It relies on the following keyelements:• OCP protocol assertions (or protocol checkers).• OCP protocol constraints (optional).• OCP functional coverage.In this verification approach, the Verification Engineer will use a formal tool to prove that, given thestimulus limits defined by the OCP protocol constraints, the OCP interface of the DUT never violatesthe OCP protocol assertions. The formal proof may either be exhaustive (the assertions are neverviolated) or bounded (up to a certain depth of the state space the assertions are never violated). Nostimuli are needed; instead the tool relies on the 'all acceptable stimuli' definitions provided vi a theOCP protocol constraints.Note that the OCP configuration parameters determine:1. Which protocol assertions must be active.2. How the functional coverage must be defined.3. Which protocol constraints must be active.Protocol AssertionsFormal verification revolves around taking the protocol assertions and attempting to prove that theyare never violated. If a violation is found, the formal tool provides a test sequence that illustrates theviolation on the design. The assertions can be written in different languages such as HDL, PSL orSVA.Note that the names of the assertions must be matched with the names given to the compliancechecks described in this document such that this document can easily be referenced by a VerificationEngineer.Protocol ConstraintsIn order to place bounds on the stimuli the formal engine must consider, the design must be connectedto some protocol constraints or some form of generator description. The constraints can be specifiedusing the same language as for protocol assertions, typically in HDL, PSL, SVA, or OVA.A good set of protocol constraints for the OCP protocol is not described in this document and must beprovided with the formal tool or created by the Verification Engineer. The set of protocol constraintsshould not be under-constrained as this will cause some “false negative” test sequences and theprotocol assertions will be violated. This same set of protocol constraints should not beover-constrained or the protocol properties can be wrongly proved correct.Functional CoverageThe Verification Engineer must insure that all of the protocol assertions are verified to a reasonableextent, and that the protocol constraints are sound. To accomplish this, some functional coveragemust be added as a fun ction of the OCP configuration parameters.The functional coverage definition should cover:OCP-IP Confidential

Introduction 81. Which assertions warrant exhaustive proofs?2. Which assertions are ok with just bounded proofs, at what depth?3. Detect and correct an over -constrained environment.IMPORTANT: Note that the guidelines for the OCP functional coverage are not included in this releaseof the OCP 2.0 / 2.1 compliance checks. They will be added in the next release.OCP-IP Confidential

Introduction 91.4 This Document ContainsAs indicated before , the compliance checks listed in this document are extracted from theOCP 2.0 / 2.1 specifications. These compliance checks are guidelines to verify an IP for OCP 2.0 / 2.1compliance. In all cases the “Part I Specification” of the OCP 2.0 / 2.1 specifications is the definitiverefer ence. Any reference to “Part II Guidelines” of the OCP 2.0 / 2.1 specifications in this document isnot definitive. The specification supersedes the guidelines.The current release of this document contains:Chapter 2: Compliance Checks Tables• Table of ChecksThis table defines the full set of OCP 2.0 / 2.1 compliance checks. Each table entry consists ofa name and a concise description of the check in 'natural' English. English was chosen to beimplementation independent.• Activation TableThis table defines for each compliance check the set of OCP 2.0 / 2.1 parameters required forthe check to be activated.Chapter 3: Compliance Checks DetailsThis chapter provides more information for each compliance check: the nomenclature, a profoundEnglish description and OCP 2.0 / 2.1 specification references.The next release of this document will contain:1. Guidelines for OCP functional coverage.2. An o ptional chapter which summarizes all the OCP configuration parameter cross-constraints.OCP-IP Confidential

Introduction 101.5 AcknowledgementsThe following companies were instrumental in the development of the OCP 2.0 / 2.1 compliancechecks:• All OCP-IP Functional Verification Workgroup members, including participants from:MIPS Technologies, Inc.Sonics, Inc.Synopsys, Inc.Texas Instruments, Inc.TransEDAYOGITECH, SPA• All reviewers who participated in the General Member ReviewOCP-IP Confidential

2 Compliance Checks TablesOCP-IP Confidential

Compliance Checks Tables 122.1 IntroductionThe following table ‘Table of Checks’ gives at a glance the complete list of OCP compliance checks.The checks are divided into six main categories:1. Dataflow Signal Checks2. Dataflow Phase Checks3. Dataflow Burst Checks4. Dataflow Transfer Checks5. Dataflow ReadEx Checks6. Sideband ChecksFor each compliance check, the protocol version, a name and a short description are given. For anOCP 2.0 interface, only the 2.0 checks are relevant. For an OCP 2.1 interface, both the 2.0 and the 2.1checks are relevant.The compliance check names have been created using the following template:___In which:: signal, request, datahs, response, burst, transfer, rdex: valid, hold, value, exact, phase_order, lock_release, sequence, order, reorder: (optional) any OCP signal name that is impacted b y the compliance check: (optional) a short additional explanationOCP-IP Confidential

Compliance Checks Tables 132.2 Table of Checks1. Dataflow Signal ChecksVersion Name Short Description2.0 signal_valid_ when_reset_inactiveMCmdMDataValidMThreadBusySDataThreadBusySRespSThreadBusy2.0 request_valid_ MAddrMAddrSpaceMAtomicLengthMBurstLengthMBurstPreciseMBurstSeqMBurstSingleReqMByteEnMConnIDMReqLastMThreadIDSCmdAccept2.0 datahs_valid_ MDataByteEnMDataLastMDataThreadIDSDataAccept2.0 response_valid_MRespAcceptSRespLastSThreadIDCheck every cycle that is not X orZ when reset inactiveCheck that is not X or Z during therequest phaseCheck that is not X or Z during thedatahandshake phaseCheck that is not X or Z during theresponse phase2.1 request_valid_MTagInOrder When tags>1 and taginorder=1, check thatMTagInOrder is not X or Z during therequest phase2.1 response_valid_STagInOrder When tags >1 and taginorder=1, check thatSTagInOrder is not X or Z during theresponse phase2.1 request_valid_MTagID_when_MTagInOrder_zero When tags>1, for tagged transactions[MTagInOrder=0], check that MTagID is notX or Z during the request phase2.1 datahs_valid_MDataTagID_when_MTagInOrder_zero When tags>1 and datahandshake=1. fortagged write transactions [MTagInOrder=0],check that MDataTagID is not X or Z duringthe datahandshake phase2.1 response_valid_STagID_when_STagInOrder_zero When tags>1, for tagg ed transactions[STagInOrder=0 ], check that STagID is notX or Z during the response phaseOCP-IP Confidential

Compliance Checks Tables 142. Dataflow Phase ChecksVersion Name Short Description2.0 request_exact_SThreadBusy Request phase is illegal if SThreadBusyand exact2.0 request_hold_ MAddrMAddrSpaceMAtomicLengthMBurstLengthMBurstPreciseMBurstSeqMBurstSingleReqMByteEnMCmdMConnIDMDataMDataInfoMReqInfoMReqLastMThreadID must hold for the request phase2.0 request_value_MCmd_ BCSTRDLWRCRDRDEXWRWRNPMCmd is illegal if is 02.0 request_value_MAddr_word_aligned MAddr must be OCP word aligned (LSB bitszero)2.0 request_value_MAtomicLength_0x0 MAtomicLength == 0 is an illegal value2.0 request_value_MBurstSeq_ DLFT1DLFT2INCRSTRMUNKNWRAPXORMBurstSeq is illegal if is 02.0 request_value_MBurstSeq_0x7 MBurstSeq == 0x7 is an illegal value2.0 request_value_MBurstLength_0x0 MBurstLength == 0 is an illegal value2.0 request_value_MByteEn_force_aligned MByteEn must be a 'legal' pow2 (seepatterns) if force_aligned2.0 request_value_MThreadID MThreadID must be < threads2.0 datahs_exact_SDataThreadBusy Data phase is illegal if SDataThreadBusyand exact2.0 datahs_hold_ MDataMDataByteEnMDataInfoMDataThreadIDMDataValidMDataLast must hold for the datahandshakephase2.0 datahs_value_MDataByteEn_force_aligned MDataByteEn must be a 'legal' pow2 (seepatterns) if force_aligned2.0 datahs_value_MDataThreadID MDa taThreadID must be < threadsOCP-IP Confidential

Compliance Checks Tables 152.0 response_exact_MThreadBusy Response phase is illegal if MThreadBusyand exact2.0 response_hold_ must hold for the response phaseSDataSDataInfoSRespSRespInfoSRespLastSThreadID2.0 response_value_SResp_FAIL_without_WRC SResp can only be FAIL for a WRC cmd2.0 response_value_SThreadID SThreadID must be < threads2.1 request_hold_MTagInOrder When tags>1 and taginorder=1,MTagInOrder must hold for the requestphase2.1 response_hold_STagInOrder When tags>1 and taginorder=1,STagInOrder must hold for the responsephase2.1 request_hold_MTagID_when_MTagInOrder_zero When tags>1, for tagged transactions[MTagInOrder=0], MTagID must hold for therequest phase2.1 datahs_hold_MDataTagID_when_MTagInOr der_zero When tags >1 and datahandshake=1, fortagged write transactions [MTagInOrder=0],the MDataTagID must hold for thedatahandshake phase2.1 response_hold_STagID_when_STagInOrder_zero When tags>1, for tagged transactions[STagInOrder=0 ], STagID must hold for theresponse phase2.1 request_value_MTagID_when_MTagInOrder_zero When tags>1, for tagged transactions[MTagInOrder=0 ], MTagID must be < tags2.1 datahs_value_MDataTagID_when_MTagInOrder_zero When tags>1 and datahandshake=1, fortagged write transactions [MTagInOrder=0],MDataTagID must be < tags2.1 response_value_STagID_when_STagInOrder_zero When tags>1, for tagged transactions[STagInOrder=0 ], STagID must be < tags2.1 datahs_order_MDataTagID_when_MTagInOrder_zero When tags >1 and datahandsha ke=1, fortagged write transactions [MTagInOrder=0],the datahandshake phase must observe thesame order as the request phase (MTagID -MDataTagID)2.1 response_reorder_STagID_tag_interleave_size Responses that are part of the sametransaction must stay together up to thetag_interleave_size2.1 response_reorder_STagID_overlapping_addresses Responses to requests with targetoverlapping addresses must not be reorderedwith respect to anotherOCP-IP Confidential

Compliance Checks Tables 163. Dataflow Burst ChecksVersion Name Short Description2.0 burst_hold_MBurstLength_precise MBurstLength must hold for precise bursts2.0 burst_hold_ MAddrSpaceMAtomicLengthMBurstPreciseMBurstSeqMBurstSingleReqMCmdMConnIDMReqInfoSRespInfo2.0 burst_hold_ _STRMMByteEnMDataByteEn must hold for all appropriatephases of the entire burst must hold for STRM bursts2.0 burst_phase_order_reqdata_together If reqdata_together, the request anddatahandshake phases of the first transferin a SRMD burst must begin and endtogether2.0 burst_sequence_MAddr_INCR Check MAddr sequence for INCR burst (++)2.0 burst_sequence_MAddr_STRM Check MAddr sequence for STRM bursts(constant)2.0 burst_sequence_MAaddr_WRAP Check MAddr sequence for WRAP bursts(++,wrap)2.0 burst_sequence_MAddr_XOR Check MAddr sequence for XOR bursts(see spec)2.0 burst_value_ _ must have at least 1 byte enabledMByteEn STRMfor MDataByteEn DFLT22.0 burst_value_ _SINGLE must be 1 for a SINGLE transferMReqLastMDataLastSRespLast2.0 burst_value_MAddr_INCR_burst_aligned INCR bursts with burst_aligned MAddr mustbe aligned with the burst length2.0 burst_value_MAddr_INCR_no_wrap INCR burst MAddr must never wrap aroundthe address space of the OCP interface2.0 burst_value_MBurstLength_ WRAPXOR bursts must have a pow2 burstlength2.0 burst_value_MBurstLength_INCR_burst_aligned INCR bursts with burst_alignedMBurstLength must be pow22.0 burst_value_MBurstPrecise_ bursts must be preciseWRAPXOR2.0 Burst_value_MBurstPrecise_INCR_burst_aligned INCR bursts with burst_aligned must beprecise2.0 Burst_value_MBurstPrecise_SRMD SRMD burst must be precise2.0 Burst_value_MBurstSeq_UNKN_SRMD If MBurstSingleReq is asserted, anMBurstSeq == UNKN is illegal (notpredictable by slave)OCP-IP Confidential

Compliance Checks Tables 172.0 burst_value_MCmd_ RDEXRDLWRC2.0 burst_value_MDataLast_ MRMDSRMD can not be part of a burstMDataLast must be 1 for the lastdatahandshake phase of a burst2.0 burst_value_MReqLast_MRMD MReqLast must ONLY be 1 for the lastrequest of a MRMD burst2.0 burst_value_MReqLast_SRMD MReqLast must be 1 whenMBurstSingleReq == 1 for a SRMD burst2.0 burst_value_SRespLast_ MRMDSRMDSRespLast must be 1 for the last responsephase for a burst2.1 burst_hold_MTagID_when_MTagInOrder_zero When tags>1, when MTagInOrder == 0,MTagID must remain constant for alltransfers of a burst2.1 burst_hold_MTagInOrder When tags>1 and taginorder=1,MTagInOrder must remain constant for alltransfers of a burstOCP-IP Confidential

Compliance Checks Tables 184. Dataflow Transfer ChecksVersion Name Short Description2.0 transfer_phase_order_datahs_before_request_begin Datahandshake phase cannot begin beforerequest phase begins2.0 transfer_phase_order_datahs_before_request_end Datahandshake phase cannot end beforerequest phase ends2.0 transfer_phase_order_response_before_r equest_begin Response phase cannot begin beforerequest phase begins2.0 transfer_phase_order_response_before_request_end Response phase cannot end before requestphase ends2.0 transfer_phase_order_response_before_datahs_begin Response phase cannot begin beforedatahandshake phase begins2.0 transfer_phase_order_response_before_datahs_end Response phase cannot end beforedatahandshake phase ends2.0 transfer_phase_order_response_before_last_datahs_begin_SRMD_wr2.0 transfer_phase_order_response_before_last_datahs_end_SRMD_wrResponse phase cannot begin before lastdatahandshake phase begins (SRMDwrites)Response phase cannot end before lastdatahandshake phase ends (SRMD writes)OCP-IP Confidential

Compliance Checks Tables 195. Dataflow ReadEx ChecksVersion Name Short Description2.0 rdex_hold_ MAddrMAddrSpace2.0 rdex_hold_ MByteEnMDataByteEn) must hold for a RDEX +WR/WRNP must hold for a RDEX +WR/WRNP2.0 rdex_lock_release_no WR/WRNP A RDEX must be followed by a WR/WRNPon the same thread2.0 rdex_lock_release_no_burst_allowed The unlocking WR/WRNP following a RDEXcannot be part of a burstOCP-IP Confidential

Compliance Checks Tables 206. Sideband ChecksVersion Name Short Description2.0 signal_valid_ MReset_nSReset_n2.0 signal_valid_ _when_reset_inactiveControlBusyControlWrMErrorSErrorSInterruptStatusBusyStatusRd2.0 signal_hold_ _16_cyclesMReset_nSReset_nCheck every cycle that is not X orZCheck every cycle that is not X orZ when reset inactiveIf active, must stay at least 16 cycles2.0 signal_hold_Control_after_reset Control must be held steady the cycle afterreset is de-asserted2.0 signal_hold_Control_2_cycles Control can only transition at most everyother cycle2.0 signal_hold_Control_controlbusy_active Control must not transition whileControlBusy is active2.0 signal_hold_ControlWr_after_reset ControlWr must not assert during the cycleafter reset becomes active2.0 signal_value_ControlWr_control_transitioned ControlWr must assert when Controltransitions2.0 signal_value_ControlWr_controlbusy_active ControlWr must not assert whenControlBusy is active2.0 signal_hold_ControlWr_2_cycles ControlWr can only assert at most everyother cycle2.0 signal_value_ControlBusy ControlBusy may only start to be assertedin a cycle after ControlWr is asserted orwhen reset transitions to inactive2.0 signal_hold_StatusRd_2_cycles StatusRd can only assert at most everyother clock cycle2.0 signal_value_StatusRd _statusbusy_active StatusRd must not assert when StatusBusyis activeOCP-IP Confidential

Compliance Checks Tables 212.3 Activation TableThe following table puts together the essential parameters that are needed for each check to fire. Thefollowing assumptions are made with respect to this table.1. The user of the document and the following tables is aware of the OCP protocol andunderstands that a combination of these parameters can lead to an illegal configuration.2. Every check in the tables below will only talk about the minimum parameters needed for eachcheck to be fired. Each configuration needs the parameters defined for each check in thistable and also every other parameter needed to make it a legal configuration to start with. Forexample, a check for INCR bursts would at the minimum need some command (read_enable,write_enable, etc.) parameters defined to test the check .1. Dataflow Signal ChecksVersion Name Activation Parameters2.0 signal_valid_ when_reset_inactiveMCmdMDataValidMThreadBusySDataThreadBusySRespSThreadBusy2.0 request_valid_ MAddrMAddrSpaceMAtomicLengthMBurstLengthMBurstPreciseMBurstSeqMBurstSingleReqMByteEnMConnIDMReqLastMThreadIDSCmdAccept2.0 datahs_valid_ MDataByteEnMDataLastMDataThreadIDSDataAccept2.0 response_valid_MRespAcceptSRespLastSThreadID-datahandshakemthr eadbusysdatathreadbusyrespsthreadbusyaddraddrspaceatomiclengthburstlengthburstpreciseburstseqburstsinglereqbyteenconnidreqlastthreads > 1cmdacceptmdatabyteendatalastdatahandshake & threads > 1dataacceptrespacceptresplastresp & threads > 12.1 request_valid_MTagInOrder taginorder2.1 response_valid_STagInOrder resp & taginorder2.1 request_valid_MTagID_when_MTagInOrder_zero tags > 12.1 datahs_valid_MDataTagID_when_MTagInOrder_zero datahandshake & tags > 12.1 response_valid_STagID_when_STagInOrder_zero resp & tags > 1OCP-IP Confidential

Compliance Checks Tables 222. Dataflow Phase ChecksVersion Name Activation Parameters2.0 request_exact_SThreadBusy sthreadbusy & sthreadbusy_exact2.0 request_hold_ MAddrMAddrSpaceMAtomicLengthMBurstLengthMBurstPreciseMBurstSeqMBurstSingleReqMByteEnMCmdMConnIDMDataMDataInfoMReqInfoMReqLastMThreadID2.0 request_value_MCmd_ BCSTRDLWRCRDRDEXWRWRNPcmdaccept & addrcmdaccept & addrspacecmdaccept & atomiclengthcmdaccept & burstlengthcmdaccept & burstprecisecmdaccept & burstseqcmdaccept & burstsinglereqcmdaccept & byteencmdacceptcmdaccept & connidcmdaccept & mdata & !datahandshakecmdaccept & mdatainfo & !datahandshakecmdaccept & reqinfocmdaccept & reqlastcmdaccept & threads > 1broadcast_enablerdlwrc_enablerdlwrc_enableread_enablereadex_enablewrite_enablewritenonpost_enable2.0 request_value_MAddr_word_aligned addr2.0 request_value_MAtomicLength_0x0 atomiclength2.0 req uest_value_MBurstSeq_ DLFT1DLFT2INCRSTRMUNKNWRAPXORburstlength & !burstseq_dflt1_enableburstlength & !burstseq_dflt2_enableburstlength & !burstseq_incr_enableburstlength & !burstseq_strm_enableburstlength & !burstseq_unkn_enableburs tlength & !burstseq_wrap_enableburstlength & !burstseq_xor_enable2.0 request_value_MBurstSeq_0x7 burstlength2.0 request_value_MBurstLength_0x0 burstlength2.0 request_value_MByteEn_force_aligned byteen & force_aligned2.0 request_value_MThreadID threads > 12.0 datahs_exact_SDataThreadBusy sdatathreadbusy & sdatathreadbusy_exact2.0 datahs_hold_ MDataMDataByteEnMDataInfoMDataThreadIDMDataValidMDataLastdataaccept & mdata & datahandshakemdatabyteen & dataaccept &datahandshakedataaccept & mdatainfo & datahandshakedatahandshake & threads > 1dataaccept & datahandshakedatalast & dataaccept & datahandshake2.0 datahs_value_MDataByteEn_force_aligned mdatabyteen & datahandshake &force_aligned2.0 datahs_value_MDataThreadID datahandshake & threads > 12.0 response_exact_MThreadBusy mthr eadbusy & mthreadbusy_exactOCP-IP Confidential

Compliance Checks Tables 232.0 response_hold_ SDataSDataInfoSRespSRespInfoSRespLastSThreadIDrespaccept & sdata & resp & (read_enable |readex_enable | rdlwrc_enable)respaccept & sdatainforespaccept & resprespaccept & respinforespaccept & resplastrespaccept & resp & threads > 12.0 response_value_SResp_FAIL_without_WRC resp & rdlwrc_enable2.0 response_value_SThreadID resp & threads > 12.1 request_hold_MTagInOrder cmdaccept & taginorder2.1 response_hold_STagInOrder resp & respaccept & taginorder2.1 request_hold_MTagID_when_MTagInOrder_zero cmdaccept & tags > 12.1 datahs_hold_MDataTagID_when_MTagInOrder_zero datahandshake & dataaccept & tags > 12.1 response_hold_STagID_when_STagInOrder_zero resp & respaccept & tags > 12.1 request_value_MTagID_when_MTagInOrder_zero tags > 12.1 datahs_value_MDataTagID_when_MTagInOrder_zero datahandshake & tags > 12.1 response_value_STagID_when_STagInOrder_zero resp & tags > 12.1 datahs_order_MDataTagID_when_MTagInOrder_zero burstlength & datahandshake & tags > 12.1 response_reorder_STagID_tag_interleave_size burstsinglereq & resp & tags > 12.1 response_reorder_STagID_overlapping_addresses resp & tags > 1 & (addr | addrspace |byteen)OCP-IP Confidential

Compliance Checks Tables 243. Dataflow Burst ChecksVersion Name Activation Parameters2.0 Burst_hold_MBurstLength_precise burstlength2.0 Burst_hold_ MAddrSpaceMAtomicLengthMBurstPreciseMBurstSeqMBurstSingleReqMCmdMConnIDMReqInfoSRespInfo2.0 Burst_hold_ _STRMMByteEnburstlength & addrspaceburstlength & atomiclengthburstlength & burstpreciseburstseq & burstlengthburstlength & burstsinglereqburstlengthburstlength & connidburstlength & reqinfoburstlength & respinfoburstlength & burstseq_strm_enable &byteen & burstseqMDataByteEnburstlength & burstseq_strm_enable &datahandshake & mdatabyteen & burstseq2.0 Burst_phase_order_reqdata_together reqdata_together & datahandshake2.0 Burst_sequence_MAddr_INCR burstlength & addr & burstseq_incr_enable& burstseq2.0 Burst_sequence_MAddr_STRM burstlength & addr & burstseq_strm_enable& burstseq2.0 Burst_sequence_MAddr_WRAP burstlength & burstseq_wrap_enable & addr& burstseq2.0 Burst_sequence_MAddr_XOR burstlength & burstseq_xor_enable & addr& burstseq2.0 burst_value_ _MByteEn STRMMDataByteEnMByteEnMDataByteEn2.0 burst_value_ _SINGLEMReqLastMDataLastSRespLastSTRMDFLT2DFLT2burstlength & burstseq_strm_enable &byteen & burstseqburstseq & burstseq_strm_enable &mdatabyteen & datahandshakeburstlength & burstseq_dflt2_enable &byteen & burstseqburstseq & burstseq_dflt2_enable &mdatabyteen & datahandshakereqlastdatalast & mdataresp & reslast2.0 Burst_value_MAddr_INCR_burst_aligned burstlength & addr & burstseq_incr_enable& burst_aligned & burstseq2.0 Burst_value_MAddr_INCR_no_wrap burstlength & burstseq_incr_enable & addr2.0 burst_value_MBurstLength_ WRAPXORburstlength & burstseq &burstseq_wrap_enableburstlength & burstseq_xor_enable &burstseq2.0 Burst_value_MBurstLength_INCR_burst_aligned burstlength & burstseq_incr_enable &burst_aligned & burstseq2.0 burst_value_MBurstPrecise_ WRAPXORburstprecise & burstseq_wrap_enable &burstlength & burstseqburstprecise & burstseq_xor_enable &burstlength & burstseq2.0 Burst_value_MBurstPrecise_INCR_burst_aligned burstaligned & burstprecise &burstseq_incr_enable & burstseqOCP-IP Confidential

Compliance Checks Tables 264. Dataflow Transfer ChecksVersion Name Activation Parameters2.0 transfer_phase_order_datahs_before_request_begin datahandshake2.0 transfer_phase_order_datahs_before_request_end datahandshake2.0 transfer_phase_order_response_before_request_begin resp2.0 transfer_phase_order_response_before_request_end resp2.0 trans fer_phase_order_response_before_datahs_begin resp & datahandshake2.0 transfer_phase_order_response_before_datahs_end resp & datahandshake2.0 transfer_phase_order_response_before_last_datahs_begin_SRMD_wr2.0 transfer_phase_order_response_before_last_datahs_end_SRMD_wrresp & datahandshake & burstsinglereqresp & datahandshake & burstsinglereqOCP-IP Confidential

Compliance Checks Tables 275. Dataflow ReadEx ChecksVersion Name Activation Parameters2.0 rdex_hold_ MAddrMAddrSpace2.0 rdex_hold_ MByteEnMDataByteEn)readex_enable & addrreadex_enable & addrspace2.0 rdex_lock_release_no WR/WRNP readex_enablereadex_enable & byteenreadex_enable & mdatabyteen &datahandshake2.0 rdex_lock_release_no_burst_allowed burstlength & readex_enableOCP-IP Confidential

CAMILA MOTTA DA SILVA W02699-1 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILA NASCIMENTO DA ROCHA C57814-7 ISENTOCAMILA NETTO PERES DOS SANTOS W12078-0 ISENTOCAMILA OLIVEIRA DA SILVA W11676-0 DIVERGENCIA/AUSENCIA DE DOCUMENTARIO COMPROBATORIACAMILA PACHECO GANDRA C56818-9 ISENTOCAMILA PAES DE JESUS W01033-0 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILA PAIVA LOURENCO W11243-7 DIVERGENCIA/AUSENCIA DE DOCUMENTARIO COMPROBATORIACAMILA PEREIRA DE SOUZA W09026-2 ISENTOCAMILA PIMENTA W13686-3 ISENTOCAMILA REGINA DOS SANTOS SIQUEIRA C52261-0 ISENTOCAMILA RENOVATO OLIVEIRA C57510-8 ISENTOCAMILA REZENDE COSTA MELRO W09146-8 ISENTOCAMILA RIBEIRO FRANCA W11781-9 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILA RODRIGUES DA SILVA W15211-2 ISENTOCAMILA ROSA CARVALHO W09905-6 ISENTOCAMILA ROSA DE SOUZA W09056-9 ISENTOCAMILA SABINO PALMA C53020-6 ISENTOCAMILA SANABIO RESENDE W13116-2 ISENTOCAMILA SANTOS DA SILVA W09724-1 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILA SANTOS TOFANO C51203-6 ISENTOCAMILA SILVA E SOUZA W02455-5 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILA SILVA GUEDES C57234-0 ISENTOCAMILA SILVA MENDES C50620-2 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILA SOARES DA SILVA C55786-6 NAO ISENTO POR RENDA ACIMA DO LIMITECAMILA SOARES DE MIRANDA W12827-2 ISENTOCAMILA SODRE CARDOSO W04880-5 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILA SONIA CHAGAS BORGES C57097-3 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILA SOUZA BOTELHO W13053-0 ISENTOCAMILA SOUZA DA SILVA C52654-1 NAO ISENTO POR RENDA ACIMA DO LIMITECAMILA TRINDADE DA SILVA C55874-2 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILA VASCONCELLOS WERHAHN W10666-1 ISENTOCAMILLA BAPTISTA DE OLIVEIRA CORDEIRO W09436-6 ISENTOCAMILLA CAMPOS DIAS W04697-6 ISENTOCAMILLA CASTRO DE ASSIS W04937-7 ISENTOCAMILLA COSTA RAMOS W08328-5 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILLA DA SILVA PRADO C50106-7 ISENTOCAMILLA DANNIELE SILVA VIANA W02536-5 ISENTOCAMILLA DAYANE FERNANDES LIMA W00681-8 DIVERGENCIA/AUSENCIA DE DOCUMENTARIO COMPROBATORIACAMILLA DE ABREU E SILVA W04267-1 ISENTOCAMILLA DE SOUZA VERISSIMO W03005-3 ISENTOCAMILLA DIAS ARAUJO W12371-9 ISENTOCAMILLA DO NASCIMENTO BERNARDO W13127-4 ISENTOCAMILLA ELISABETE SERRADOR FERREIRA W03980-6 ISENTOCAMILLA FERNANDES DA SILVA W06712-2 DIVERGENCIA/AUSENCIA DE DOCUMENTARIO COMPROBATORIACAMILLA FIGUEIREDO DA COSTA MALHEIRO C50603-0 DIVERGENCIA/AUSENCIA DE DOCUMENTACAO COMPROBATORIACAMILLA JACINTO BOMFIM W00418-5 ISENTOCAMILLA MARCELLINO THEODORO C50559-1 ISENTOCAMILLA MESQUITA DE CARVALHO W08773-9 ISENTOCAMILLA NUNES COSTA W06696-7 ISENTOCAMILLA OLIVEIRA SARDINHA W03204-6 ISENTOCAMILLA PEREIRA DE SOUZA W08567-0 ISENTOCAMILLA ROBERT DA SILVA W07427-0 DIVERGENCIA/AUSENCIA DE DOCUMENTARIO COMPROBATORIA

3 Compliance Checks DetailsOCP-IP Confidential

Compliance Checks Details 313.2 Dataflow Signals Checks3.2.1 signal_valid__when_reset_inactiveNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeReset activityDataflowMCmd, MDataValid, MThreadBusy, SDataThreadBusy,SResp, SThreadBusyX, ZDescriptionReferencesWhen reset is inactive, the following signals should never have an X or Z value on the risingedge of the OCP clock:MCmd MDataValid MThreadBusySDataThreadBusy SResp SThreadBusyOCP Specification, Release 2.0 referencesp166, section “Signal Testing”OCP Specification, Release 2.1 referencesp194, section “Signal Testing”OCP-IP Confidential

Compliance Checks Details 323.2.2 request_valid_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequest phaseDataflowMAddr, MAddrSpace, MAtomicLength, MBurstLength, MBurstPrecise,MBurstSeq, MBurstSingleReq, MByteEn, MConnID, MReqLast,MThreadID, SCmdAcceptX, ZDescriptionReferencesThe following signals should never have an X or Z value on the rising edge of the OCP clockduring a request phase:MAddr MAddrSpace MAtomicLengthMBurstLength MBurstPrecise MBurstSeqMBurstSingleReq MByteEn MConnIDMReqLast MThreadID SCmdAcceptThe following exception applies: if datahandshake=1 and mdatabyteen=1 then MByteEn canbe invalid for write accesses during the request phaseOCP Specification, Release 2.0 referencesp166, section “Signal Testing”OCP Specification, Release 2.1 referencesp194, section “Signal Testing”OCP-IP Confidential

Compliance Checks Details 333.2.3 datahs_valid_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeDatahandshakeDataflowMDataByteEn, MDataLast, MDataThreadID, SDataAcceptX, ZDescriptionReferencesThe following signals should never have an X or Z value on the rising edge of the OCP clockduring a datahandshake phase:MDataByteEn MDataLast MDataThreadIDSDataAcceptOCP Specification, Release 2.0 referencesp166, section “Signal Testing”OCP Specification, Release 2.1 referencesp194, section “Signal Testing”OCP-IP Confidential

Compliance Checks Details 343.2.4 response_valid_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflowMRespAccept, SRespLast, SThreadIDX, ZDescriptionReferencesThe following signals should never have an X or Z value on the rising edge of the OCP clockduring a response phase:MRespAccept SRespLast SThreadIDOCP Specification, Release 2.0 referencesp166, section “Signal Testing”OCP Specification, Release 2.1 referencesp194, section “Signal Testing”OCP-IP Confidential

Compliance Checks Details 353.2.5 request_valid_MTagInOrderNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – tag extensionsMTagInOrderX, ZDescriptionReferencesMTagInOrder should not be X/Z during the request phase.OCP Specification, Release 2.1 referencesp154, section “Tags”OCP-IP Confidential

Compliance Checks Details 363.2.6 response_valid_STagInOrderNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflow – tag extensionsSTagInOrderX, ZDescriptionReferencesSTagInOrder should not be X/Z during the response phase.OCP Specification, Release 2.1 referencesp154, section “Tags”OCP-IP Confidential

Compliance Checks Details 373.2.7 request_valid_MTagID_when_MTagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – tag extensionsMTagID, MTagInOrderX, ZDescriptionReferencesIf MTagInOrder is 0 during the request phase, MTagID should not be X/Z during the requestphase.OCP Specification, Release 2.1 referencesp154, section “Tags”OCP-IP Confidential

Compliance Checks Details 393.2.9 response_valid_STagID_when_STagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflow – tag extensionsSTagID, STagInOrderX, ZDescriptionReferencesIf STagInOrder is 0 during the response phase, STagID should not be X/Z during the responsephase.OCP Specification, Release 2.1 referencesp154, section “Tags”OCP-IP Confidential

Compliance Checks Details 403.3 DataFlow Phase Checks3.3.1 request_exact_SThreadBusyNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – thread extensionsMCmdValueDescriptionReferencesIf sthreadbusy_exact = 1, when a given slave thread is busy, the master must stay idle on thisthread.OCP Specification, Release 2.0 referencesp37, section “Ungrouped Signals”p169, section “Request Phase Checks”OCP Specification , Release 2.1 referencesp39, section “Ungrouped Signals”p156, section “Threads”p197, section “Request Phase Checks”OCP-IP Confidential

Compliance Checks Details 413.3.2 request_hold_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsRequestDataflowMAddr, MCmd, MData, MAddrSpace, MByteEn, MDataInfo,MReqInfo, MAtomicLength, MBurstLength, MBurstPrecise,MBurstSeq, MBurstSingleReq, MReqLast, MConnID,MThreadIDAssertion typeHoldDescriptionOnce a request phase has begun, the following signals may not change their value until theOCP slave has accepted the request.Basic SignalsMAddrMCmdMDataSimple ExtensionsMAddrSpaceMByteEnMDataInfoMReqInfoBurst ExtensionsMAtomicLengthMBurstLengthMBurstPreciseMBurstSeqMBurstSingleReqMReqLastThread ExtensionsMConnIDMThreadIDThe following exception applies: If datahandshake=1 and mdatabyteen=1 then MByteEn canchange for write accesses during the request phase.OCP-IP Confidential

Compliance Checks Details 42ReferencesOCP Specification, Release 2.0 referencesp167, section “Signal Retraction Testing”OCP Specification, Release 2.1 referencesp138, section “Request Phase”p195, section “Signal Retraction Testing”OCP-IP Confidential

Compliance Checks Details 433.3.3 request_value_MCmd_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – basic signalsMCmdValueDescriptionThe following is illegal if the corresponding is set to 0.CommandBCSTRDRDEXRDLWRWRCWRNPReferencesParameterbroadcast_enableread_enablereadex_enablerdlwrc_enablewrite_enablerdlwrc_enablewritenonpost_enableOCP Specification, Release 2.0 referencesp168, section “Request Phase Checks”OCP Specification, Releas e 2.1 referencesp196, section “Request Phase Checks”OCP-IP Confidential

Compliance Checks Details 443.3.4 request_value_MAddr_word_alignedNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – basic signalsMAddrValueDescriptionReferencesSignal MAddr must be OCP word aligned as follows:data_wdth = 16 and MAddr[0] = 0data_wdth = 32 and MAddr[1:0] = 0data_wdth = 64 and MAddr[2:0] = 0data_wdth = 128 and MAddr[3:0] = 0OCP Specification, Release 2.0 referencesp169, section “Request Phase Checks”OCP Specification, Release 2.1 referencesp197, section “Request Phase Checks”OCP-IP Confidential

Compliance Checks Details 453.3.5 request_value_MAtomicLength_0x0NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – burst extensionsMAtomicLengthValueDescriptionReferencesDuring a request phase, MAtomicLength must be non zero.OCP Specification, Release 2.0 referencesp18, section “Burst Extensions”OCP Specification, Release 2.1 referencesp19, section “Burst Extensions”OCP-IP Confidential

Compliance Checks Details 463.3.6 request_value_MBurstSeq_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – burst extensionsMBurstSeqValueDescriptionThe following is illegal if its corresponding is set to 0.Burst typeDLFT1DLFT2INCRSTRMUNKNWRAPXORReferencesParameterburstseq_dflt1_enableburstseq_dflt2_enableburstseq_incr_enableburstseq_strm_enableburstseq_unkn_enableburstseq_wrap_enableburstseq_xor_enableOCP Specification, Release 2.0 referencesp47, section “Optional Burst Sequences”p170, section “Burst Checks”OCP Specification, Release 2.1 referencesp51, section “Optional Burst Sequences”p198, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 473.3.7 request_value_MBurstSeq_0x7NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – burst extensionsMBurstSeqValueDescriptionReferencesDuring a request phase, the MBurstSeq signal cannot take value 0x7.OCP Specification, Release 2.0 referencesp196, section “Burst Checks”OCP Specification, Release 2.1 referencesp198, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 483.3.8 request_value_MBurstLength_0x0NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – burst extensionsMBurstLengthValueDescriptionReferencesDuring a request phase, the MBurstLength signal cannot take value 0x0.OCP Specification, Release 2.0 referencesp172, section “Burst Checks”OCP Specification, R elease 2.1 referencesp172, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 493.3.9 request_value_MByteEn_force_alignedNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – simple extensionsMByteEnValueDescriptionIf force_aligned=1 , the Byte Enable values during a request phase are restricted to thefollowing patterns for data_wdth ≥ 32:data_wdth=32 and MByteEn has one of the following values:00010010010010000011110011110000data_wdth=64 and MByteEn has one of the following values:00000001000000100000010000001000000100000010000001000000100000000000001100001100001100001100000000001111111100001111111100000000data_wdth=128 and MByteEn has one of the following values:000000000000000100000 0000000001000000000000001000000000000001000OCP-IP Confidential

Compliance Checks Details 50000000000001000000000000001000000000000001000000000000001000000000000001000000000000001000000000000001000000000000001000000000000001000000000000001000000000000001000000000000000000000000000011000000000000110000000000001100000000000011000000000000110000000000001100000000000011000000000000110000000000000000000000000011110000000011110000000011110000000011110000000000000000000011111111111111110000000011111111111111110000000000000000The following exception applies: If datahandshake=1 and mdatabyteen=1 then MByteEn can changefor write accesses during the request phase.ReferencesOCP Specification, Release 2.0 referencesp48, section “Byte Enable Patterns”p168, section “Request Phase Checks”OCP Specification, Release 2.1 referencesp51, section “Byte Enable Patterns”p197, section “Request Phase Checks”OCP-IP Confidential

Compliance Checks Details 513.3.10 request_value_MThreadIDNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – thread extensionsMThreadIDValueDescriptionReferencesMThreadID value is always < threads.OCP Specification, Release 2.0 referencesp169, section “Request Phase Checks”OCP Specification, Release 2.1 referencesp197, section “Request P hase Checks”OCP-IP Confidential

Compliance Checks Details 523.3.11 datahs_exact_SDataThreadBusyNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeDatahanshakeDataFlow – thread extensionsMDataValidValueDescriptionReferencesIf sdatathreadbusy_exact = 1, when a given slave data thread is busy, the master must notpresent a data phase on this thread.OCP Specification, Release 2.0 references169, section “Datahandshake Phase”OCP Specification, Release 2.1 referencesp197, section “Datahandshake Phase”OCP-IP Confidential

Compliance Checks Details 533.3.12 datahs_hold_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsDatahandshakeDataflowMData, MDataValid, MDataByteEn, MDataInfo, MDataLast,MDataThreadIDAssertion typeHoldDescriptionReferencesOnce a datahandshake phase has begun, the following signals may not change their valueuntil the OCP slave has accepted the data.Basic SignalsMDataMDataValidSimple ExtensionsMDataByteEnMDataInfoBurst ExtensionsMDataLastThread ExtensionsMDataThreadIDOCP Specification, Release 2.0 referencesp167, section “Signal Retraction Testing”OCP Specification, Release 2.1 referencesp196, section “Signal Retraction Testing”OCP-IP Confidential

Compliance Checks Details 543.3.13 datahs_value_MDataByteEn_force_alignedNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeDatahandshakeDataflow – simple extensionsMDataByteEnValueDescriptionIf force_aligned=1, the Data Byte Enable values during a datahandshake phase are restrictedto the following patterns for data_w dth ≥ 32:data_wdth=32 and MDataByteEn has one of the following values:00010010010010000011110011110000data_wdth=64 and MDataByteEn has one of the following values:00000001000000100000010000001000000100000010000001000000100000000000001100001100001100001100000000001111111100001111111100000000data_wdth=128 and MDataByteEn has one of the following values:0000000000000001000000000000001000000000000001000000000000001000OCP-IP Confidential

Compliance Checks Details 563.3.14 datahs_value_MDataThreadIDNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeDatahandshakeDataflow – thread extensionsMDataThreadIDValueDescriptionReferencesMDataThreadID value must be < threads.OCP Specification, Release 2.0 referencesp20, section “Thread Extensions”OCP Specification, Release 2.1 referencesp23, section “Thread Extensions”OCP-IP Confidential

Compliance Checks Details 573.3.15 response_exact_MThreadBusyNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflow – thread extensionsSRespValueDescriptionReferencesIf mthreadbusy_exact = 1, when a given master thread is busy, the slave must not present aresponse on that thread.OCP Specification, Release 2.0 referencesp169, section “Response Phase”OCP Specification, Release 2.1 referencesp197, section “Response Phase”OCP-IP Confidential

Compliance Checks Details 583.3.16 response_hold_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeRespons eDataflowSData, SResp, SDataInfo, SRespInfo, SRespLast, SThreadIDHoldDescriptionOnce a response phase has begun, the following signals may not change their value until themaster has accepted the response.Basic SignalsSDataSRespSimple ExtensionsSDataInfoSRespInfoBurst ExtensionsSRespLastThread ExtensionsSThreadIDReferencesOCP Specification, Release 2.0 referencesp167, section “Signal Retraction Testing”OCP Specification, Release 2.1 referencesp196, section “Signal Retraction Testing”OCP-IP Confidential

Compliance Checks Details 593.3.17 response_value_SResp_FAIL_without_WRCNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflow – basic signalsSRespValueDescriptionReferencesThe FAIL response can occur only on a WRC request.OCP Specification, Release 2.0 referencesp40, section “Transfer Effects”p169, section “Transfer-Based Checks”OCP Specification, Release 2.1 referencesp42, section “Transfer Effects”p198, secti on “Transfer-Based Checks”OCP-IP Confidential

Compliance Checks Details 603.3.18 response_value_SThreadIDNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflow – thread extensionsSThreadIDValueDescriptionReferencesSThreadID value must be < threads.OCP Specification, Release 2.0 referencesp169, section “Response Phase”OCP Specification, Release 2.1 referencesp197, section “Response Phase”OCP-IP Confidential

Compliance Checks Details 613.3.19 request_hold_MTagInOrderNomenclatureProtocol version 2.1Protocol hierarchySign al groupCritical signalsAssertion typeRequestDataflow – tag extensionsMTagInOrderHoldDescriptionReferencesIf taginorder = 1, the MTagInOrder signal cannot change until accepted by the OCP slave(SCmdAccept = 1) .OCP Specification , Release 2.1 referencesp195, section “Signal Retraction Testing” , Table 43OCP-IP Confidential

Compliance Checks Details 623.3.20 response_hold_STagInOrderNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflow – tag extensionsSTagInOrderHoldDescriptionReferencesIf taginorder = 1, the STagInOrder signal cannot change until it is accepted by the master(MRespAccept = 1).OCP Specification, Release 2.1 referencesp196, section “Signal Retraction Testing”, Table 45OCP-IP Confidential

Compliance Checks Details 633.3.21 request_hold_MTagID_when_MTagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – tag extensionsMTagID, [MTagInOrder]HoldDescriptionReferencesIf tags > 1, the MTagID signal cannot change until accepted by the OCP slave (SCm dAccept =1).OCP Specification, Release 2.1 referencesp195, section “Signal Retraction Testing”, Table 43OCP-IP Confidential

Compliance Checks Details 643.3.22 datahs_hold_MDataTagID_when_MTagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeDatahandshakeDataflow – tag extensionsMDataTagID, [MTagInOrder]HoldDescriptionReferencesWhen tags > 1, during a datahandshake phase corresponding to a non in-order request phase(MTagInOrder = 0), the MDataTagID signal cannot change value until accepted by the OCPslave (SDataAccept = 1).OCP Specification, Release 2.1 referencesp196, section “Signal Retraction Testing”, Table 44OCP-IP Confidential

Compliance Checks Details 653.3.23 response_hold_STagID_when_STagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeRespons eDataflow – tag extensionsSTagID, [STagInOrder]HoldDescriptionReferencesIf tags > 1, the STagID signal cannot change until it is accepted by the master (MRespAccept= 1).OCP Specification, Release 2.1 referencesp196, section “Signal Retraction Testing”, Table 45OCP-IP Confidential

Compliance Checks Details 663.3.24 request_value_MTagID_when_MTagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeRequestDataflow – tag extensionsMTagID, [MTagInOrder]ValueDescriptionReferencesThe MTagID signal must always be < tags.OCP Specification, Release 2.1 referencesp197, section “Request Phase Checks”, bullet 8OCP-IP Confidential

Compliance Checks Details 673.3.25 datahs_value_MDataTagID_when_MTagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeDatahandshakeDataflow – tag extensionsMDataTagID, [MTagInOrder]ValueDescriptionReferencesThe MDataTagID value must always be < tags .OCP Specification, Release 2.1 referencesp197, section “Datahandshake Phase Checks”, bullet 5OCP-IP Confidential

Compliance Checks Details 683.3.26 response_value_STagID_when_STagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflow – tag extensionsSTagID, [STagInOrder]ValueDescriptionReferencesThe STagID signal must always be < tags.OCP Specification, Release 2.1 referencesp197, section “Response Phase”, bullet 2OCP-IP Confidential

Compliance Checks Details 693.3.27 datahs_order_MDataTagID_when_MTagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeDatahandshakeDataflow – tag extensionsMDataTagID, [MTagInOrder]Data_orderDescriptionReferencesWhen datahandshake = 1, for tagged write transactions, the datahandshake phase mustobserve the same order as the request phase.OCP Specification, Release 2.1 referencesp48, section “Ordering Restrictions”, first paragraphOCP-IP Confidential

Compliance Checks Details 703.3.28 response_reorder_STagID_tag_interleave_sizeNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflow – tag extensionsSTagIDReorderDescriptionReferencesThe slave must ensure that responses that are part of the same transaction stay together upto the tag_interleave_size. When tags > 1, the tag_interleave_size parameterizes theinterleaving permitted for responses associated with packing burst sequences.OCP Specification, Release 2.1 referencesp48, section “Ordering Restrictions”, third paragraphp53, section “Burst Interleaving with Tags”OCP-IP Confidential

Compliance Checks Details 713.3.29 response_reorder_STagID_overlapping_addressesNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeResponseDataflow – tag extensionsSTagIDReorderDescriptionReferencesResponses to requests that target overlapping addresses (as determined by MAddrSpace,MAddr and MByteEn) must not be re-ordered with respect to another. Note that this propertydoes not need take into account the value of MTagInOrder.OCP Specification, Release 2.1 referencesp10, section “Tags”, third paragraphp49, section “Ordering Restrictions”, fourth paragraphOCP-IP Confidential

Compliance Checks Details 723.4 Dataflow Burst Checks3.4.1 burst_hold_MBurstLength_preciseNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataFlow – burst extensionsMBurstLengthHoldDescriptionReferencesFor precise bursts, MBurstLength must hold its value during all request phases of the entireburst.OCP Specification, Release 2.0 referencesp44, section “Constant Fields in Bursts”p171, section “Burst Checks”OCP Specification, Release 2.1 referencesp47, section “Constant Fields in Bursts”p199, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 733.4.2 burst_hold_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – burst extensionsMAddrSpace, MAtomicLength, MBurstPrecise, MBurstSeq,MBurstSingleReq, MCmd, MConnID, MReqInfo, (SRespInfo)HoldDescriptionThe following signals must hold the same value on all request phases of the entire burst:MAddrSpaceMAtomicLengthMBurstPreciseMBurstSeqMBurstSingleReqMCmdMConnIDMReqInfoDescriptionThe hold requirements for SRespInfo in a burst are different for the 2.0 versus 2.1specifications.In the OCP 2.0 specification p44 it is stated that: “SRespInfo must be held steady by the slavefor every transfer in a burst”.In the OCP 2.1 specification p47 it is stated that: “If possible, slaves should hold SRespInfosteady for every transfer in a burst”OCP Specification, 2.0 referencesp44, section “Constant Fields in Bursts”p171, section “Burst Checks”OCP Specification, Release 2.1 referencesp47, section “Constant Fields in Bursts”p199, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 743.4.3 burst_hold__STRMNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – simple extensionsMByteEn, MDataByteEnHoldDescriptionReferencesFor streaming bursts, MByteEn / MDataByteEn must hold the same value on all request /datahandshake phases of the entire burst.OCP Specification, Release 2.0 referencesp43, section “Byte Enable Restrictions”p172, section “Burst Checks”OCP Specification, Release 2.1 referencesp46, section “Byte Enable Restrictions”p200, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 753.4.4 burst_phase_order_reqdata_togetherNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – basic signalsMCmd, MDatavalidOrderingDescriptionReferencesFor Single Request Multiple Data bursts, if reqdata_together = 1, the master must present therequest and first write data in the same cycle.OCP Specification, Release 2.0 referencesp50, section “Phase Options”OCP Specification, Release 2.1 referencesp54, section “Phase Options”OCP-IP Confidential

Compliance Checks Details 763.4.5 burst_sequence_MAddr_INCRNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – basic signalsMAddrOrderingDescriptionReferencesWithin an incrementing burst, the address increases for each new master request by the OCPword size.OCP Specification, Release 2.0 referencesp171, section “Burst Checks”OCP Specification, Release 2.1 referencesp200, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 773.4.6 burst_sequence_MAddr_STRMNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – basic signalsMAddrOrderingDescriptionReferencesWithin a streaming burst, the address remains constant on all request phases of the burst.OCP Specification, Release 2.0 referencesp171, section “Burst Checks”OCP Specification, Release 2.1 referencesp199, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 783.4.7 burst_sequence_MAddr_WRAPNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – basic signalsMAddrOrderingDescriptionReferencesWithin a wrapping burst, the address increases for each new master request by the OCP wordsize, and wraps on the burst length x OCP word size.OCP Specification, Release 2.0 referencesp171, section “Burst Checks”OCP Specification, Release 2.1 referencesp200, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 793.4.8 burst_sequence_MAddr_XORNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow –basic signalsMAddrOrderingDescriptionReferencesWithin an XOR burst, the address increases for each new OCP master request as follows:BASE is the lowest byte address in the burst, which must be aligned with the total burst size.FIRST_OFFSET is the byte offset (from BASE) of the first transfer in the burst.CURRENT_COUNT is the count of current transfer in the burst starting at 0. WORD_SHIFT isthe log2 of the OCP word size in bytes.The current address of the transfer is BASE | (FIRST_OFFSET ^ (CURRENT_COUNT

Compliance Checks Details 803.4.9 burst_value__NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – simple extensionsMByteEn, MDataByteEnValueDescriptionReferencesWhen mdatabyteen = 0, during STRM or DFLT2 bursts, MByteEn should never take the value0.When mdatabyteen = 1, during read-type STRM or DFLT2 bursts, MByteEn should never takethe value 0.When mdatabyteen = 1, during write-type STRM or DFLT2 bursts, MDataByteEn should nevertake value 0.OCP Specification, Release 2.0 referencesp43, section “Byte Enable Restrictions”OCP Specification, Release 2.1 referencesp46, section “Byte Enable Res trictions”OCP-IP Confidential

Compliance Checks Details 813.4.10 burst_value__SINGLENomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeSingleDataflow – burst extensionsMReqLast, MDataLast, SRespLastValueDescriptionReferencesSignal MDataLast must be 1 for the datahandshake phase of a single write-type request.Signal MReqLast must be 1 for any single request.Signal SRespLast must be 1 for the response to a single request.OCP Specification, Release 2.0 referencesp45, section “MReqLast, MD ataLast, SRespLast”p170, section “Burst Checks”OCP Specification, Release 2.1 referencesp45, section “MReqLast, MDataLast, SRespLast”p198, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 823.4.11 burst_value_MAddr_INCR_burst_alignedNomenclatureProtocol version 2.0Protocol hierar chySignal groupCritical signalsAssertion typeBurstDataflow – basic signalsMAddrValueDescriptionWhen burst_aligned=1, the first burst request of an incrementing burst must have its addressaligned. The equation/example below indicates which MAddr bits must be 0.EquationMAddr [(size-1)+BL:0] = 0ExampleReferencesWhere:size = log2(bytes(data_width))for data_width > 1 byteBL = log2(burst_length) for burst_length > 1For an interface with data_width=32, size=2 and:burst_length = 2 : MAddr[2:0] = 0burst_length = 4 : MAddr[3:0] = 0OCP Specification, Release 2.0 referencesp48, section “Burst Alignment”p171, section “Burst Checks”OCP Specification, Release 2.1 referencesp51, section “Burst Alignment”p199, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 833.4.12 burst_value_MAddr_INCR_no_wrapNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – basic signalsMAddrValueDescriptionReferencesAn incrementing burst can never cross the address space boundary.OCP Specification, Release 2.0 referencesp171, section “Burst Checks”OCP Specification, Release 2.1 referencesp199, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 843.4.13 burst_value_MBurstLength_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – burst extensionsMBurstLengthValueDescriptionReferencesThe length of a wrapping or XOR burst must be a power of two.OCP Specification, Release 2.0 referencesp42, section “Burst Address Sequence”p171, section “Burst Checks”OCP Specification, Release 2.1 referencesp45, section “Burst Address Sequence”p199, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 853.4.14 burst_value_MBurstLength_INCR_burst_alignedNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBustDataflow – burst extensionsMBurstLengthValueDescriptionReferencesWhen burst_aligned = 1, the length of an incrementing burst must be a power of two.OCP Specification, Release 2.0 referencesp48, section “Burst Alignment”p171, section “Burst Checks”OCP Specification, Release 2.1 referencesp48, section “Burst Alignment”p199, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 863.4.15 burst_value_MBurstPrecise_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – burst extensionsMBurstPreciseValueDescriptionReferencesWrapping and XOR bursts can be issued only as precise bursts.OCP Specification, Release 2.0 referencesp42, section “Burst Address Sequence”p171, section ‘Burst Checks”OCP Specification, Release 2.1 referencesp45, section “Burst Address Sequence”p198, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 873.4.16 burst_value_MBurstPrecise_INCR_burst_alignedNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – burst extensionsMBurstPreciseValueDescriptionReferencesWhen burst_aligned = 1, incrementing bursts can be issued only as precise bursts.OCP Specification, Release 2.0 referencesp42, section “Burst Address Sequence”p171, section “Burst Checks”OCP Specification, Release 2.1 referencesp42, section “Burst Address Sequence”p198, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 883.4.17 burst_value_MBurstPrecise_SRMDNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – burst extensionsMBurstPreciseValueDescriptionReferencesSingle Request Multiple Data transfers can be issued only as precise bursts.OCP Specification, Release 2.0 referencesp45, section “Single Request / Multiple Data Bursts”OCP Specification, Release 2.1 referencesp47, section “Single Request / Multiple Data Bursts”OCP-IP Confidential

Compliance Checks Details 893.4.18 burst_value_MBurstSeq_UNKN_SRMDNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – Burst ExtensionsMBurstSeqValueDescriptionReferencesAn unknown burst sequence (value UNKN) is illegal during a Single Request Multiple Datatransfer.OCP Specification, Release 2.0 referencesp35, section “Phases in a Transfer”OCP Specification, Release 2.1 referencesp30, section “Signal Configuration”OCP-IP Confidential

Compliance Checks Details 903.4.19 burst_value_MCmd_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – basic signalsMCmdValueDescriptionReferencesThe RDEX, RDL, and WRC commands cannot be part of a burst.OCP Specification, Release 2.0 referencesp42, section “Burst Definition”p170, section “Burst Checks”OCP Specification, Release 2.1 referencesp44, section “Burst Definition”p198, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 913.4.20 burst_value_MDataLast_ NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – burst extensionsMDataLastValueDescriptionReferencesThe MDataLast signal must be 0 for all datahandshake phases in a write -type burst (either aMRMD or SRMD), except on the last one where it must be 1.OCP Specification, Release 2.0 referencesp45 , section “MReqLast, MDataLast, SRespLast”p171, section “Burst Checks”OCP Specification, Release 2.1 referencesp47 , section “MReqLast, MDataLast, SRespLast”p198, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 923.4.21 burst_value_MReqLast_MRMDNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – burst extensionsMReqLastValueDescriptionReferencesThe MReqLast signal is 0 for all request phases of a MRMD burst, except on the last onewhere it must be 1.OCP Specification, Release 2.0 referencesp45, section “MReqLast, MDataLast, SRespLast”p172, section “Burst Checks”OCP Specification, Release 2.1 referencesp47, section “MReqLast, MDataLast, SRespLast”p199, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 933.4.22 burst_value_MReqLast_SRMDNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – burst extensionsMReqLastValueDescriptionReferencesThe signal MReqLast must be 1 for any single request (SRMD being active or not).OCP Specification, Release 2.0 referencesp45, section “MReqLast, MDataLast, SRespLast”p172, section “Burst Checks”OCP Specification, Release 2.1 referencesp47, section “MReqLast, MDataLast, SRespLast”p199, section “Burst Checks”OCP-IP Confidential

Compliance Checks Details 943.4.23 burst_value_SRespLast_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – burst extensionsSRespLastValueDescriptionReferencesThe signal SRespLast must be 0 for all response phases in a MRMD burst, except on the lastone where it must be 1.The signal SRespLast must be 1 for any single response (with SRMD active or not).OCP Specification, Release 2.0 referencesp45, section “MReqLast, MDataLast, SRespLast”p172, section “Burst Checks”OCP Specification, Release 2.1 referencesp47, section “MReqLast, MDataLast, SRespLast”p199, section “Burst ChecksOCP-IP Confidential

Compliance Checks Details 953.4.24 burst_hold_MTagID_when_MTagInOrder_zeroNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – tag extensionsMTagID, [MTagInOrder]HoldDescriptionReferencesThe MTagID signal must remain constant for all transfers of a burst when MTagInOrder iszero. The master cannot interleave requests [or datahandshake] phases with different tagswithin a transaction. Note that this check should only focus on the request phase. Thedatahandshake phase is covered by phase property “datahs_order_MDataTagID_when_MTagInOrder_zero”. This last property checks that the datahandshake phase observes thesame order as the request phase.OCP Specification, Release 2.1 referencesp48, section “Ordering Restrictions”, first paragraphOCP-IP Confidential

Compliance Checks Details 963.4.25 burst_hold_MTagInOrderNomenclatureProtocol version 2.1Protocol hierarchySignal groupCritical signalsAssertion typeBurstDataflow – tag extensionsMTagInOrderHoldDescriptionReferencesThe MTagInOrder signal m ust remain constant for all transfers of a burst.OCP Specification, Release 2.1 referencesp48, section “Ordering Restrictions”, first paragraphOCP-IP Confidential

Compliance Checks Details 973.5 DataFlow Transfer Checks3.5.1 transfer_phase_order_datahs_before_request_beginNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeTransferDataflow – basic signalsMDataValid, MCmdOrderingDescriptionReferencesFor each thread, for each transaction tag, a datahandshake phase cannot begin before theassociated request phase begins, but can begin in the same clock cycle.OCP Specification, Release 2.0 referencesp35, section “Phase Ordering Within a Transfer”OCP Specification, Release 2.1 referencesp38, section “Phase Ordering Within a Transfer”OCP-IP Confidential

Compliance Checks Details 983.5.2 transfer_phase_order_datahs_before_request_endNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeTransferDataflow – basic signalsMDataValid, MCmdOrderingDescriptionReferencesFor each thread, for each transaction tag, a datahandshake phase cannot end before theassociated request phase ends, but can end in the same clock cycle.OCP Specification, Release 2.0 referencesp35, section “Phase Ordering Within a Transfer”OCP Specification, Release 2.1 referencesp38, section “Phase Ordering Within a Transfer”OCP-IP Confidential

Compliance Checks Details 993.5.3 transfer_phase_order_response_before_request_beginNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeTransferDataflow – basic signalsMCmd, SRespOrderingDescriptionReferencesFor each thread, for each transaction tag, a response phase cannot begin before theassociated request phase begins, but can begin in the same clock cycle.OCP Specification, Release 2.0 referencesp35, section “Phase Ordering Within a Transfer”p169, section “Response Phase”p169, section “Transfer-Based Checks”OCP Specification, Release 2.1 referencesp38, section “Phase Ordering Within a Transfer”p197, section “Response Phase”p197, section “Transfer-Based Checks”OCP-IP Confidential

Compliance Checks Details 1003.5.4 transfer_phase_order_response_before_request_endNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeTransferDataflow – basic signalsMCmd, SRespOrderingDescriptionReferencesFor each thread, for each transaction tag, a response phase cannot end before the associatedrequest phase ends, but can end in the same clock cycle.OCP Specification, Release 2.0 referencesp35, section “Phase Ordering Within a Transfer”p169, section “Response Phase”p169, section “Transfer-Based Checks”OCP Specification, Release 2.1 referencesp38, section “Phase Ordering Within a Transfer”p197, section “Response Phase”p197, section “Transfer-Based Checks”OCP-IP Confidential

Compliance Checks Details 1013.5.5 transfer_phase_order_response_before_datahs_beginNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeTransferDataflow – basic signalsMDataValid, SRespOrderingDescriptionReferencesFor each thread, for each transaction tag, w hen datahandshake = 1, the response phasecannot begin before the associated datahandshake begins, but can begin in the same clockcycle.OCP Specification, Release 2.0 referencesp35, section “Phase Ordering Within a Transfer”p169, section “Response Phase”p169, section “Transfer-Based Checks”OCP Specification, Release 2.1 referencesp38, section “Phase Ordering Within a Transfer”p197, section “Response Phase”p197, section “Transfer-Based Checks”OCP-IP Confidential

Compliance Checks Details 1023.5.6 transfer_phase_order_response_before_datahs_endNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeTransferDataflow – basic signalsMDataValid, SRespOrderingDescriptionReferencesFor each thread, for each transaction tag, when datahandshake = 1, the response phasecannot end before the associated datahandshake ends, but can end in the same clock cycle.OCP Specification, Release 2.0 referencesp35, section “Phase Ordering Within a Transfer”p169, section “Response Phase”p169, section “Transfer-Based Checks”OCP Specification, Release 2.1 referencesp38, section “Phase Ordering Within a Transfer”p197, section “Response Phase”p197, section “Transfer-Based Checks”OCP-IP Confidential

Compliance Checks Details 1033.5.7 transfer_phase_order_response_before_last_datahs_begin_SRMD_wrNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeTransferDataflow – basic signalsMDataValid, SRespOrderingDescriptionReferencesFor each thread, for each transaction tag, w ith a write -type SRMD, the response phase cannotbegin before the last datahandshake phase begins , but it can begin in the same clock cycle.OCP Specification, Release 2.0 referencesp35, section “Phase Ordering Within a Transfer”p169, section “Response Phase”p169, section “Transfer-Based Checks”OCP Specification, Release 2.1 referencesp38, section “Phase Ordering Within a Transfer”p197, section “Response Phase”p197, section “Transfer-Based Checks”OCP-IP Confidential

Compliance Checks Details 1043.5.8 transfer_phase_order_response_before_last_datahs_end_SRMD_wrNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeTransferDataflow – basic signalsMDataValid, SRespOrderingDescriptionReferencesFor each thread, for each transaction tag, w ith a write -type SRMD, the response phase cannotend before the last datahandshake phase ends, but it can end in the same clock cycle.OCP Specification, Release 2.0 referencesp35, section “Phase Ordering Within a Transfer”p169, section “Response Phase”p169, section “Transfer-Based Checks”OCP Specification, Release 2.1 referencesp38, section “Phase Ordering Within a Transfer”p197, section “Response Phase”p197, section “Transfer-Based ChecksOCP-IP Confidential

Compliance Checks Details 1053.6 DataFlow ReadEx Checks3.6.1 rdex_hold_NomenclatureProtocol hierarchySignal groupCritical signalsAssertion typeReadExDataflow – Basic SignalsMAddr, MAddrSpaceHoldDescriptionReferencesThe unlocking command following a ReadEx must retain the same address and addressspace values.OCP Specification, Release 2.0 referencesp39, section “Transfer Effects”p42, section “Burst Definition”p172, section “Read Exclusive Transaction Checks”OCP Specification, Release 2.1 referencesp42, section “Transfer Effects”p44, section “Burst Definition”p200, section “Read Exclusive Transaction Checks”OCP-IP Confidential

Compliance Checks Details 1063.6.2 rdex_hold_ NomenclatureProtocol hierarchySignal groupCritical signalsAssertion typeReadExDataflow – Simple ExtensionsMByteEn, MDataByteEnHoldDescriptionReferencesWhen mdatabyteen = 0, the unlocking command following a ReadEx must retain the sameMByteEn value.When mdatabyteen = 1, the unlocking command following a ReadEx must retain forMDataByteEn the value given to MByteEn during the ReadEx command. If MByteEn isabsent, MDataByteEn must be all 1’s.OCP Specification, Release 2.0 referencesp39, section “Transfer Effects”p42, section “Burst Definition”p172, section “Read Exclusive Transaction Checks”OCP Specification, Release 2.1 referencesp42, section “Transfer Effects”p44, section “Burst Definition”p200, section “Read Exclusive Transaction Checks”OCP-IP Confidential

Compliance Checks Details 1073.6.3 rdex_lock_release_no_WR/WRNPNomenclatureProtocol hierarchySignal groupCritical signalsAssertion typeReadExDataflow – Basic SignalsMCmdOrderingDescriptionReferencesIf a ReadEx is issued on an address on a particular thread, no other request with the sameaddress can be issued on any other thread until the ReadEx is unlocked.The command following the ReadEx on the same thread must be a write command (WR orWRNP). This command unlocks the ReadEx.OCP Specification, Release 2.0 referencesp39, section “Transfer Effects”p42, section “Burst Definition”OCP Specification, Release 2.1 referencesp42, section “Transfer Effects”p44, section “Burst Definition”OCP-IP Confidential

Compliance Checks Details 1083.6.4 rdex_lock_release_no_burst_allowedNomenclatureProtocol hierarchySignal groupCritical signalsAssertion typeReadExDataflow – Basic SignalsMBurstLengthValueDescriptionReferencesThe unlocking command following a RDEX must have MBurstLength = 1.OCP Specification, Release 2.0 referencesp39, section “Transfer Effects”p42, section “Burst Definition”p172, section “Read Exclusive Transaction Checks”OCP Specification, Release 2.1 referencesp42, section “Transfer Effects”p44, section “Burst Definition”p200, section “Read Exclusive Transaction Checks”OCP-IP Confidential

Compliance Checks Details 1093.7 Sideband Checks3.7.1 signal_valid_NomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeReset ActivitySideband – ResetMReset, SResetX, ZDescriptionReferencesSignals MReset_n and SReset_n are never X or Z.OCP Specification, Release 2.0 referencesp166-167OCP Specification, Release 2.1 referencesp194OCP-IP Confidential

Compliance Checks Details 1103.7.2 signal_valid_ when_reset_inactiveNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeReset ActivitySidebandControlBusy, ControlWr, MError, SError, SInterrupt, StatusBusy,StatusRdX, ZDescriptionReferencesWhen reset is inactive, the following signals should never have an X or Z value on the risingedge of the OCP clock:ControlBusy ControlWr MErrorSErrorSInterruptStatusBusy Statu sRdOCP Specification, Release 2.0 referencesp166-167OCP Specification, Release 2.1 referencesp194OCP-IP Confidential

Compliance Checks Details 1113.7.3 signal_hold__16_cyclesNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritica l signalsAssertion typeReset ActivitySideband – ResetMReset, SResetHoldDescriptionReferencesIf they are active, signals MReset_n and SReset_n must stay active at least 16 consecutivecycles.OCP Specification, Release 2.0 referencesp38, section “Reset”p172, section “Reset Checks”OCP Specification, Release 2.1 referencesp40, section “Reset”p200, section “Reset Checks”OCP-IP Confidential

Compliance Checks Details 1123.7.4 signal_hold_Control_after_resetNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeControlSideband – ControlControlHoldDescriptionReferencesThe Control signal must be held steady the first cycle after reset is de-asserted.OCP Specification, Release 2.0 referencesp38, section “Status and Control”p172, section “Control Checks”OCP Specification, Release 2.1 referencesp41, section “Status and Control”p200, section “Control Checks”OCP-IP Confidential

Compliance Checks Details 1133.7.5 signal_hold_Control_2_cyclesNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeControlSideband – ControlControlHoldDescriptionReferencesThe Control signal must be held steady for a full cycle after the cycle in which it hastransitioned.OCP Specification, Release 2.0 referencesp38, section “Status and Control”p172, section “Control Checks”OCP Specification, Release 2.1 referencesp41, section “Status and Control”p200, section “Control Checks”OCP-IP Confidential

Compliance Checks Details 1143.7.6 signal_hold_Control_ControlBusy_activeNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeControlSideband – ControlControlValueDescriptionReferencesIf the ControlBusy signal was sampled active at the end of the previous cycle, the Controlsignal must not transition in the current cycle.OCP Specification, Release 2.0 referencesp38, section “Status and Control”p172, section “Control Checks”OCP Specification, Release 2.1 referencesp41, section “Status and Control”p200, section “Control Checks”OCP-IP Confidential

Compliance Checks Details 1153.7.7 signal_hold_ControlWr_after_resetNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeControlSideband – ControlControlWrHoldDescriptionReferencesThe ControlWr signal must not be asserted in the cycle following a reset.OCP Specification, Release 2.0 referencesp172, section “Control Checks”OCP Specification, Release 2.1 referencesp200, section “Control Checks”OCP-IP Confidential

Compliance Checks Details 1163.7.8 signal_value_ControlWr_Control_transitionedNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeControlSideband – ControlControlWrValueDescriptionReferencesIf signal Control transitions in a cycle, signal ControlWr must be driven active on that cycle.OCP Specification, Release 2.0 referencesp38, section “Status and Control”p172, section “Control Checks”OCP Specification, Release 2.1 referencesp41, section “Status and Control”p200, section “Control Checks”OCP-IP Confidential

Compliance Checks Details 1173.7.9 signal_value_ControlWr_ControlBusy_activeNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeControlSideband – ControlControlWrValueDescriptionReferencesThe ControlWr signal must not be asserted if ControlBusy is active.OCP Specification, Release 2.0 referencesp172, section “Control Checks”OCP Specification, Release 2.1 referencesp200, section “Control Checks”OCP-IP Confidential

Compliance Checks Details 1183.7.10 signal_hold_ControlWr_2_cyclesNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeControlSideband – ControlControlWrHoldDescriptionReferencesThe ControlWr signal must not remain asserted for two consecutive cycles.OCP Specification, Release 2.0 referencesp172, section “Control Checks”OCP Specification, Release 2.1 referencesp200, section “Control Checks”OCP-IP Confidential

Compliance Checks Details 1193.7.11 signal_value_ControlBusyNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeControlSideband – ControlControlBusyValueDescriptionReferencesThe ControlBusy signal can only be asserted in a cycle after the ControlWr signal is assertedor after the reset transitions to inactive.OCP Specification, Release 2.0 referencesp173, section “Control Checks”OCP Specification, Release 2.1 referencesp200, section “Control Checks”OCP-IP Confidential

Compliance Checks Details 1203.7.12 signal_hold_StatusRd_2_cyclesNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeStatusSideband – StatusStatusRDHoldDescriptionReferencesIf the StatusRd signal was asserted in the previous cycle, it must not be asserted in the currentcycle.OCP Specification, Release 2.0 referencesp39, section “Status and Control”p173, section “Status Checks”OCP Specification, Release 2.1 referencesp41, section “Status and Control”p201, section “Status Checks”OCP-IP Confidential

Compliance Checks Details 1213.7.13 signal_value_StatusRd_StatusBusy_activeNomenclatureProtocol version 2.0Protocol hierarchySignal groupCritical signalsAssertion typeStatusSideband – StatusStatusRDValueDescriptionReferencesThe StatusRd signal must not be asserted while StatusBusy is asserted.OCP Specification, Release 2.0 referencesp173, section “Status Checks”OCP Specification, Releas e 2.1 referencesp201, section “Status Checks”OCP-IP Confidential

OCP-IP Association5440 SW Westgate Drive, Suite 217Portland, OR 97221Ph: 503-291-2560Fax: 503-297-1090admin@ocpip.orgwww.ocpip.orgThe Overriding Document On OCP Certification Is the Current OCP Specification