1 / 20

Processor Verification with Precise Exceptions and Speculative Execution

Processor Verification with Precise Exceptions and Speculative Execution. Presenter: Fu- Ching Yang Jun Sawada and Warren A. Hunt, Jr. Department of Computer Sciences, University of Texas In proceeding of 10th International Computer Aided Verification Conference, 1998

althea
Télécharger la présentation

Processor Verification with Precise Exceptions and Speculative Execution

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. Processor Verification with Precise Exceptions and Speculative Execution Presenter: Fu-Ching Yang Jun Sawada and Warren A. Hunt, Jr. Department of Computer Sciences, University of Texas In proceeding of 10th International Computer Aided Verification Conference, 1998 Vol. 1427, Pages 135-146

  2. Outline • Abstract • Motivation • Hardware specification • Backgroundknowledge • Proposed approach • Invariants conditions and correctness criterion • Conclusion

  3. Abstract • We describe a framework for verifying a pipelined microprocessor whose implementation contains precise exceptions, external interrupts, and speculative execution. We present our correctness criterion which compares the state transitions of pipelined and non-pipelined machines in presence of external interrupts. To perform the verification, we created a table-based model of pipeline execution. This model records committed and in-flight instructions as performed by the micro-architecture. Given that certain requirements are met by this table-based model, we have mechanically verified our correctness criterion using the ACL2 theorem prover.

  4. Motivation • What’s the problem • Exception mechanism and speculative execution verification are often simplified • Several verified microprocessors only contain one kind of exception • Speculatively executed instruction • Branch prediction • Goalsof verification • Speculative execution • External interrupts • Precise exceptions

  5. Hardware specification • Superscalar processor • Speculative execution • 12 instructions at most • Out of order execution • At most 15 instructions in pipeline • Multiple exceptions • Fetch errors, decode errors, data access errors and external interrupts • The machine may take a large number of cycles before it actually starts exception handling • Instructions precede the interrupted instruction must commit Block diagram of the pipeline machine design

  6. Background knowledge • Theorem proving • Instruction-set architecture (ISA) ?= Micro-architecture (MA) • ISA : Non-pipelined abstract machine • MA : Pipelined structure of actual implementation m-instruction ISA transition ... ... ISA0 ISAi ISAm ISA Instruction-level Abstraction function ... ... ... MA0 MAj MAk MAn MA Cycle level Flushed state Flushed state n-cycle MA transition

  7. Proposed approach • ISA • Instruction interpreter function : ISA-step() • Granularity : instruction level • Input : current ISA state, a instruction and an external interrupt • Output : next ISA state • Describe actions for external interrupt and interrupt exceptions • MA • Behavioral function : MA-step() • Granularity : Cycle level • Input : current MA state, external inputs • Output : next MA state • Exception mechanism, branch prediction unit and memory-write buffer

  8. Proposed approach - MAETT • A Micro-Architecture Execution Trace Table (MAETT) = A abstraction of MA state • Records all executed instructions at cycle level • Committed or in-flight instruction • A MAETT grows as more instructions are fetched • Shrinks when speculatively executed instructions are abandoned m-instruction ISA transition ... ... ISA0 ISAi ISAm ISA Instruction-level Abstraction function ... ... ... MA0 MAj MAk MAn MA Cycle level Only committed instructions Flushed state Flushed state Only committed instructions n-cycle MA transition

  9. The content of MAETT

  10. Explanation setup of a example • At state Mai • Instruction I1 is committed • Instruction I2 (store) is waiting for its memory operation to complete • Instruction I3 and I4 are being executed but not committed • Instruction I5 is not fetched yet Relations between MA and ISA sequences

  11. Invariants conditions and correct criterion • Definitions • MTk • The MAETT representing an MA state MAk • Contains instruction I1, …, Il • Inv(MTk, MAk) • Invariant condition for the following 6 requirements (the next 6 slides) Invariant condition : A state always holds if certain requirements is true EX : Inv(Cara arrives earlier than Carb)holds If the speed of Cara is faster than the speed of Carb A B

  12. Requirement 1 • If Inv(MTk, MAk) holds and MAk is a flushed pipeline state • Every instruction Ii in MTk is committed Relations between MA and ISA sequences 12/50

  13. Requirement 2 • If Inv(MTk, MAk) holds and MTk = (I1,…Il) • ﹁MAETT-speculative?(MTk) → MA-pc(MAk) = ISA-pc(ISAl) Relations between MA and ISA sequences

  14. Requirement 3 • If Inv(MTk, MAk) is true and Ii+1, i < l, is the first uncommitted instruction in MTk = (I1, …, Il) • MA-regs(MAk) = ISA-regs(ISAi) Relations between MA and ISA sequences

  15. Requirement 4 • If Inv(MTk, MAk) is true and Ii+1, i< 1, is the first memory store instruction whose memory write is not completed • MA-mem(MAk) = ISA-mem(ISAi) (str) Relations between MA and ISA sequences

  16. Requirement 5 • For an arbitrary flushed initial state MA0 and its MAETT MT0, Inv(MT0, MA0) holds Relations between MA and ISA sequences

  17. Requirement 6 • If self-modified code is executed • MA may not work correctly with respect to ISA • Suppose MAk+1 and MTk+1 are the next MA state and next MAETT • MAk+1 = MA-step(MAk, Inputsk) • MTk+1 = MAETT-step(MTk, MAk, Inputsk) • Inv(MTk, MAk) → Inv(MTk+1, MAk+1) V commit-self-modified-instr-p(MTk+1)

  18. External interrupt verification • The non-determinism at the ISA level introduced by external interrupts can lead to different final ISA states • Requires to dynamically construct corresponding ISA transitions Branching of ISA state sequence on an external interrupt Corresponding MAETT s

  19. Conclusion • A framework for verifying pipelined machine at MA level • Correct speculative execution and precise exception • Correctness criterion • Compare MA state transitions to the corresponding ISA state transitions • It defines an invariant condition that satisfies several requirement m-instruction ISA transition ... ... ISA0 ISAi ISAm ISA Instruction-level Abstraction function ... ... ... MA0 MAj MAk MAn MA Cycle level Flushed state Flushed state n-cycle MA transition

  20. Issues related to PEVT • Observations in precise interrupt in superscalar processor • The problem is to find which is the interrupted instruction • Instructions commit in order • This method needs great experience to write the requirement • 4000 lemmas for a processor • Hard for inexperience users • Take a lot of time

More Related