1 / 17

Jasper Design Automation

Jasper Design Automation. Verifying OCP-based Design IP DATE 2006. Agenda. Seven Steps of Formal Testplanning OCP -I2C Example. Methodical and Systematic Verification for OCP. Successful verification of OCP-based design IP is not ad hoc in nature

sydnee
Télécharger la présentation

Jasper Design Automation

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. Jasper Design Automation Verifying OCP-based Design IP DATE 2006

  2. Agenda • Seven Steps of Formal Testplanning • OCP-I2C Example

  3. Methodical and Systematic Verification for OCP • Successful verification of OCP-based design IP is not ad hoc in nature • Success depends on methodical verification planning combined with systematic verification processes. • The key to this success is the verification testplan.

  4. Verification Testplan • A project’s functional verification testplan is the specification for the verification process. • Developing this testplan usually involves the entire engineering team • architects, designers, and verification engineers • In general, the verification testplan defines exactly • what functionality will be verified, • how it will be verified • the verification strategy and resource allocation • when the verification process is complete • metrics for measuring progress or completion criteria

  5. Identify good candidates Englishlist assert_never (); Formal description Requirements inputs outputs Block Seven steps of a formal testplan 1 identify describe 2 Defineinterface 3 Requirementschecklist 4 Formaldescription 5 Verificationstrategy 6 Coveragegoals 7

  6. High-Level Requirements Strategy Formal Testplan Examples Advanced Techniques Formal Testplanner™ Jumpstarts Verification

  7. Jasper OCP verification IP • Interface protocol verification is an important first step in the verification process. • Formal Testplanner includes IP for formal verification of OCP protocols. • The IP exists in the form of a set of properties that checks all aspects of the OCP protocol including: • Configuration validity • Signal stability checks relative protocol phases • Signal value checks relative protocol configuration • Burst control handling • Burst address generation correctness • Sideband checks

  8. IP Integration in JasperGold • Jasper is in the process of doing a tighter integration of the OCP verification IP into JasperGold. • The current IP consists of a configurable property set that has been designed to cover all OCP cases. • Future integration will allow users to generate the exact set of checkers needed for a specific OCP instance. • Instance specific checker generation will have a number of benefits: • Easier to optimize for formal verification purposes • Improved ease-of-use • Reduced chance for human errors • Auto generation will be based on the OCP configuration file format.

  9. Great candidate for formal! OCP to I2C Example Bridge I/O Merge OCP I2C clk_en d[31:0] SCL i2c_data_vld i2c_data_out a[31:0] d_ready SDA i2c_data_in size bridge_ready i2c_data_start One bit serial connection High speed, high bandwidth bus I2C Clocking Bridge (with 64 byte write FIFO)

  10. Step 2. Describe Intent The commands flow one direction from OCP to I2C, but the data flows both ways. For the write direction, data are written into a FIFO. When the FIFO is full, the OCP signal SCmdAccept is deasserted until there is room in the FIFO again. Upon receiving the write data, as long as there is room in the FIFO, the OCP bus is free for other devices sharing the OCP to proceed to their transactions. A read-cycle, however, will hold up the bus until the data is ready. Therefore,the readtransaction has priority over the writetransaction exceptwhen there is a coherencyissue. For example, if a readaddress matchesthe write address of one of the entriesin the. . . . .

  11. RequirementModel inputs outputs DUT Step 3. Define Interfaces

  12. Step 4. Requirements Checklist • OCP interface requirements. • All verification directives are taken from the OCP verification IP. • SRespLast must be asserted for a single transfer requiring a response. • The FAIL response is legal only for WriteConditional commands. • . . . • I2C interface requirements. • SDA should remain stable when SCL is high • There should not be another start after a start until an end occurs in the I2C bus. • The data between a start and an end should be divisible by 9 (8 bit/transfer + 1-bit ack) • . . . • End-to-end requirements. • Data is not dropped, duplicated, or corrupted for a read-cycle • Data is not dropped, duplicated, or corrupted for a write-cycle • …

  13. Step 5. Formalize Requirements • To demonstrate the formal specification process, we convert the • following I2C requirement into both PSL and SVA: • There should not be another start after a start until an end • occurs in the I2C bus. • NOTE: In this example, i2c_start and i2c_end represent modeling code • associated with the assertion, composed of SCL and SDA. • default clock = HCLK; • A_no_start:assert (always i2c_start -> next(~i2c_start until i2c_end)) abort (~RESETn); PSL • property P_no_start; •    @(posedge HCLK) disable iff (~HRESETn) •      i2c_start |=> ~i2c_start[*0:$] ##1 i2c_end; • endproperty • A_no_start:assertproperty (P_no_start); SVA

  14. Step 6. Strategy • In this step, you will define the verification plan and proof strategy. • For example, you might choose to prove certain requirements by initially applying a set of restrictions • Add constraints to restrict the explored behavior to only read-mode transaction, or only write-mode transactions. • This approach lets you focus the verification on specific modes of operation, and simplifies the verification process. • Once the various modes function correctly, the restrictions are removed and the IP is verified under all modes of operation.

  15. Step 6. Strategy • Compositional Reasoning • Partitioning • Strict Mode • Applying restrictions initially, and then loosening them over a sequence of steps • Abstraction

  16. Step 7. Coverage • Define a set of coverage goals that must be met during the verification process. • To ensure that you are verifying what you think you are verifying, check that constraints on specific states in your requirements model have not over-constrained the states. • The checking procedure varies depending on your verification process. • For formal verification, you can check to see if specific states in your requirement model are reachable. • For simulation-based approaches, you can apply functional coverage to various states or sequences of states in the requirements model.

  17. Step 7 Coverage (cont’d.) Set 1: Input coverage – Read/write access with different burst types, sizes, and lengths, and with SCmdAccept asserted and deasserted. Set 2: Output coverage – Read/write with acknowledgment, no acknowledgement. Set 3: Internal main state-machines – I2C state-machines, OCP state-machines where they can enter and exit each state.

More Related