1 / 15

Proposal to donate Formal definition of OCP 2.0

Proposal to donate Formal definition of OCP 2.0. Existing Protocol definition carries risks. Protocol definition is traditionally by sample waveforms & ‘English’ explanation OCP 2.0 is 210 pages with 33 pages of example waveforms in Section 8

camden
Download Presentation

Proposal to donate Formal definition of OCP 2.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proposal to donate Formal definition of OCP 2.0 Proposal to donate formal protocol definition to OCP-IP

  2. Existing Protocol definition carries risks • Protocol definition is traditionally by sample waveforms & ‘English’ explanation OCP 2.0 is 210 pages with 33 pages of example waveforms in Section 8 • It isn’t possible for standardizing authorities to show examples of ALL corner cases • The user has to extrapolate from available information • There is always potential for ambiguity in his conclusions The worst scenario is where two groups draw different conclusions and don’t simulate the critical corner cases If blocks fail to communicate correctly, or lock-up, the chip may require an expensive re-spin with consequent project (time-to-market) delays Proposal to donate formal protocol definition to OCP-IP

  3. A simple example from OCP 2.0 • OCP is relatively good By comparison AHB is notoriously bad! • However the 2.0 spec doesn’t clearly & explicitly define the behaviour if a burst of transfers receives a FAIL or ERR response Some protocols terminate bursts early in these circumstances because they result from attempts to access non-existent memory • When preparing this example, Drew Wingard interpreted the spec as: “There is nothing particularly special about the ERR response” “Page 45 describes the semantics of single request bursts, with a transfer count that is not dependent on the SResp values in any way” • In hindsight the pipelining probably requires this, HOWEVER…. Proposal to donate formal protocol definition to OCP-IP

  4. Unambiguous Protocol definition • Conventional Protocol definition contrasts sharply with computer language definition • BNF defines every legal production in every circumstance • It ISN’T possible to use BNF to define a protocol because it doesn’t describe temporal relationships • It IS possible to use the Regular Expressions from Formal / Property / Assertion languages in a BNF-like manner • RE-based definitions are methodical They’re more likely to be complete than “waveform & English” or “set of requirement” • RE-based definitions are as legible as BNF The ultimate goal is to make them the PRIME form of definition “waveform & English” would be for illustration Proposal to donate formal protocol definition to OCP-IP

  5. Example BNF & PSL Regular Expressions - 1 • Figure 28 - page 118 - “Single Request Burst Read” Proposal to donate formal protocol definition to OCP-IP

  6. Example BNF & PSL Regular Expressions - 2 • We can define the protocol as the sum of the legal transfers Protocol ::= single_request_read_transfer | multi_request_read_transfer | multi_request_imprecise_read_transfer | single_request_write_transfer | multi_request_write_transfer | multi_request_imprecise_write_transfer | idle single_request_read_transfer ::= single_read_request ; not_last_read_response[*(length-1)] ; last_read_response single_read_request ::= (single_read_request_setup && ! ScmdAccept)[*] ; (single_read_request_setup && ScmdAccept) single_read_request_setup ::= ((MCmd == RD) && (MAddr == base_address) && (MBurstLength == length) && (MBurstSeq == INCR) && MBurstSingleReq && MBurstPrecise && MreqLast etc. …… Proposal to donate formal protocol definition to OCP-IP

  7. Example BNF & PSL Regular Expressions - 3 • We can expand the ‘single_request_read_transfer’ to a PSL Regular Expression ((MCmd == RD) && (MAddr == base_address) && (MBurstLength == length) && (MBurstSeq == INCR) && MBurstSingleReq && MBurstPrecise && MreqLast && ! ScmdAccept)[*] ; ((MCmd == RD) && (MAddr == base_address) && (MBurstLength == length) && (MBurstSeq == INCR) && MBurstSingleReq && MBurstPrecise && MreqLast && ScmdAccept) ; { ! SRespLast && (SResp == NULL)[*] ; { { ! SRespLast && (SResp == DVA) && (SData == data[actual_transfer_count]) } | { ! SRespLast && (SResp == FAIL) } | { ! SRespLast && (SResp == ERR) } } }[*(length-1)] ; SRespLast && (SResp == NULL)[*] ; { { SRespLast && (SResp == DVA) && (SData == data[actual_transfer_count]) } | { SRespLast && (SResp == FAIL) } | { SRespLast && (SResp == ERR) } } Proposal to donate formal protocol definition to OCP-IP

  8. A great combination • BNF-like RE-based Protocol definition has enormous scope • Has the expressive power to describe simple bus protocols such as APB up to complex packet-based serial protocols such as PCI-Express, Infiniband & Wireless networking Concurrency of multiple transactions / pipelines is fully supported • There is a very strong connection between definitions and FSM’s Virtual all interface hardware can be represented as FSM’s • The definitions are more likely to be complete than the ‘set of properties’ approaches • Unlike ‘set of properties’ they can be tested for completeness Every alternative path must be distinguishable All combinations of the signals that distinguish paths must be defined Proposal to donate formal protocol definition to OCP-IP

  9. The value to the user It delivers key advantages for users: • Improved quality Allows him to use accurate definitions direct from the standardizing authority Avoids multiple interpretations of potentially ambiguous specification • Easy to create a definition for an actual configuration from a master protocol definition #ifdef / `ifdef like constructs can be used to pre-process exact definitions based on standard OCP configuration parameters • Improved access to Verification IP The definitions are directly useable for IP generation Particularly important because of highly configurable nature of OCP Similar to use of yacc & bison as compiler construction tools Proposal to donate formal protocol definition to OCP-IP

  10. Applications for automatically generated IP • Automatic transactor generation for simulation • Protocol compliance monitor generation • Functional coverage measurement • Emulation • Formal Model checking Proposal to donate formal protocol definition to OCP-IP

  11. Supports shift in abstraction level • Transaction recognizers shown in use with Novas Debussy Proposal to donate formal protocol definition to OCP-IP

  12. SDV’s proposal We propose a phased approach: • SDV creates RE-based definition of OCP 2.0 Existing OCP configuration parameters would be used to select exact configuration • SDV works with OCP-IP group(s) to confirm definition The detailed methodology has to be established – see next slide • OCP-IP owns and publishes the RE-based definition Initially as an alternative to the existing “waveform & English” definition • OCP-IP maintains the RE-based definition as new versions of the protocol are released SDV contributes to and supports maintenance of definition Proposal to donate formal protocol definition to OCP-IP

  13. The proposed validation methodology RE-based definition must be compared with existing definition SDV proposes a coverage-driven simulation based approach For each of a representative sample of OCP configurations: • Generate Monitor Verification IP for the configuration • Instantiate monitor in standard OCP validation suite and run all available simulations Access to simulations that create faults is desirable • Resolve any errors reported by the SDV Monitor • Check Protocol-specific coverage Will also provide a metric for the OCP validation suite • Create additional simulation testcases to extend coverage Proposal to donate formal protocol definition to OCP-IP

  14. The deliverables • RE-based definition(s) for family(s) of OCP configurations Each definition would contain configuration switches using standard OCP names to create actual required definition User instructions for choosing correct family definition (if required) • Sample Monitor IP generated from RE-based definition, as necessary to validate the accuracy of the definition Typically supplied as source code for Verilog or SystemC/SCV simulation environments however other environments are feasible Supplied with Protocol Coverage instrumentation and transaction recording where supported Limited licenses for SDV Coverage reporting and analysis tools for platform(s) to be agreed Proposal to donate formal protocol definition to OCP-IP

  15. Summary of benefits to OCP Members • Improved Quality Reduced risk of multiple interpretations of ambiguous or incomplete definitions • Improved access to Verification IP for a range of disciplines OCP members not dependent on IP developers business models and quality Verification IP built for exact configuration in use Consistent interpretation of OCP across multiple simulation environments (Verilog, VHDL, SystemC, TLM etc.), emulation & Formal verification • Reduced time to market Improved access to Verification IP keeps development out of critical path Functional coverage allows better project planning & fewer surprises • Reduced project costs Reduced cost of IP Reduced project risk Proposal to donate formal protocol definition to OCP-IP

More Related