1 / 50

Time Abstraction in Simulation-Based Hardware Verification

RAS. ISP. Summer School on Software Engineering and Verification (SSSEV) July 17-27, Moscow, Russia. Time Abstraction in Simulation-Based Hardware Verification. Alexander Kamkin kamkin@ispras.ru. Institute for System Programming of the Russian Academy of Sciences (ISPRAS)

mahina
Télécharger la présentation

Time Abstraction in Simulation-Based Hardware Verification

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. RAS ISP Summer School on Software Engineering and Verification (SSSEV) July 17-27, Moscow, Russia Time Abstraction in Simulation-Based Hardware Verification Alexander Kamkin kamkin@ispras.ru Institute for System Programming of the Russian Academy of Sciences (ISPRAS) http://hardware.ispras.ru

  2. Agenda • Introduction • Digital hardware design • Simulation-based verification • Time abstraction in hardware modeling • Main part • Time abstraction levels • Model-based reaction checking • Error diagnostics • Conclusion • C++TESK testing toolkit • Future work • Questions & answers Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  3. Time • Time is a part of measuring system used to sequence events, to compare the durations of events and the intervals between them… Wikipedia • The only reason for time is so that everything doesn’t happen at once Albert Einstein Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  4. Abstraction • Abstraction is the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances Webster’s Dictionary • Abstraction captures only those details about an object that are relevant to the current perspective Wikipedia • Time abstraction is (1) generalization of events ordering relationship and (2) factorization of time intervals between them This Presentation Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  5. Hardware design in a nutshell • Hardware is designed using hardware description languages (HDL), like VerilogandVHDL • The result is a software model that can be executed in an HDL simulator • The main approach to verify a design is to test the HDL model (simulation-based verification) • To automate simulation-based verification, reference models are used (C/C++) Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  6. Clock Inputs, outputs, and system clock Clock Outputs Inputs Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  7. Hardware description language (HDL) CLK input S; output R1, R2; void design() { while(true) { wait(S); delay(6); R1 = 1; delay(1); R1 = 0; delay(1); R2 = 1; delay(1); R2 = 0; V1 = 1; }} S R1 R2 6 cycles Concurrent assignments Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  8. Simulation-based verification S2 Stimuli S1 S3 Reactions R3 Generation R2 R1 Checking Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  9. Target Design Stimulus Generator Test Coverage Reaction Checker Simulation-based verification tasks • Stimuli generation • Reaction checking • Coverage tracking Stimulus Generator Reaction Checker Coverage Tracker Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  10. Reaction checking Functionality • Number of reactions is correct • Each reaction is correct • Order of reactions is correct • Time intervals between reactions are correct Timing Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  11. Design modifications Requirements are not time-accurate; design’s timing constantly changes Timing  Interface Function Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  12. Model abstraction + + +   Abstract models are easier to develop and to maintain Abstract models are more stable (reusable) Abstract models are less error-prone Abstract models provide lower verification quality Abstract models are less deterministic and predictable Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  13. # # # # # R1 R1 R1 R1 R1 S S S S S # R2 R2 R2 R2 R2 R2 R1 S S R1 R2 R2 # # # Time abstraction S Stimulus Concrete event sequence S #6 R1 #2 R2 Abstract specification S #+ R1 #* R2 More abstract specifications S ((#+ R1 #* R2) | (#+ R2 #* R1)) S ((#+ R1) || (#+ R2)) R2 Events Reactions R1 Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  14. Time abstraction in practice • Hardware design modeling • Development of reference models at different abstraction levels (specification of time properties) • Change of abstraction level (refinement of time properties) • Reference model adaptation • Adaptation of abstract (untimed) reference models for co-simulation in a time environment • Tuning time properties being checked without changing a reference model (reaction arbitration, etc.) Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  15. To be continued…Questions? Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  16. Agenda • Introduction • Digital hardware design • Simulation-based verification • Time abstraction in hardware modeling • Main part • Time abstraction levels • Model-based reaction checking • Error diagnostics • Conclusion • C++TESK testing toolkit • Future work • Questions & answers Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  17. Time abstraction levels • Time-accurate (cycle-accurate) models … • Time-inaccurate (time-approximate) models … • Untimed (functional) models Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  18. Cycle-accurate models input bool val_in_data; input uint8_t in_data; output bool val_out_data; output uint8_t out_data; void store_word() { uint32_t data = 0; uint32_t temp = 0; for(int i = 0; i < 4; i++) { data |= in_data << (i << 3); delay(1); } temp = memory; delay(1); memory = data; delay(1); val_out_data = 1; for(int i = 0; i < 4; i++) { out_data = (temp >> (i << 3)) & 0xff; delay(1); } val_out_data = 0; } input bool val_in_data; input uint8_t in_data; output bool val_out_data; output uint8_t out_data; void store_word() { uint32_t data = 0; uint32_t temp = 0; while(true) { wait(val_in_data); for(int i = 0; i < 4; i++) { data |= in_data << (i << 3); delay(1); } temp = memory; delay(1); memory = data; delay(1); val_out_data = 1; for(int i = 0; i < 4; i++) { out_data = (temp >> (i << 3)) & 0xff; delay(1); } val_out_data = 0; }} Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  19. Modeling concurrency Operation Operation Operation delay(1) delay(1) delay(1) delay(1) Operation delay(1) delay(1) delay(1) delay(1) delay(1) return delay(1) return Time return return Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  20. Functional (untimed) models:time interval abstraction input in_iface<uint32_t>; output out_iface<uint32_t>; void store_word() { uint32_t temp = memory; memory = recv(in_iface); // delay([0,)) = #* send(out_iface, temp); } uint32_t store_word(uint32_t data) { uint32_t temp = memory; memory = data; return temp } Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  21. Functional (untimed) models (cont.) input bool val_in_data[ ]; input uint8_t in_data[4]; output bool val_out_data[ ]; output uint8_t out_data[4]; void store_word() { uint32_t data = 0; uint32_t temp = 0; for(int i = 0; i < 4; i++) { data |= in_data[t1] << (i << 3); delay(1); } temp = memory; delay(1); memory = data; delay(1); val_out_data = 1; for(int i = 0; i < 4; i++) { out_data[t2] = (temp >> (i << 3)) & 0xff; delay(1); } val_out_data = 0; } input in_iface<uint32_t>; output out_iface<uint32_t>; void store_word() { uint32_t data = 0; uint32_t temp = 0; data = recv(in_iface); temp = memory; memory = data; send(out_iface, temp); } t1++ t2++ Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  22. Functional (untimed) models:events ordering abstraction input in_iface <uint32_t>; output out_iface1<uint32_t>; output out_iface2<uint32_t>; void store_word() { uint32_t temp = memory; memory = recv(in_iface); // Order of events is undefined send(out_iface1, temp); send(out_iface2, memory); } Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  23. Time-approximate models input in_iface<uint32_t>; output out_iface<uint32_t, FIFO>; // Reactions ordering void store_word() { uint32_t data = 0; uint32_t temp = 0; data = recv(in_iface, in_data); temp = memory; delay([0, 3]); // Delays are approximate memory = data; delay([1, 4]); // Delay=(0+1)=1, Timeout=(3-0)+(4-1)=6 send(out_iface, temp); } Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  24. Package Data Data Data Data Transaction-level modeling (TLM) TLM is a hardware modeling approach that separates communication among design units from the functional description of those units TLM is data transmission encapsulation Wires/pins Channels/interfaces Discrete signals distributed in time Untimed data package (message) Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  25. 25 Data Data Data Data Data Data Data Model interface adapters Input interface#1 Output interface#1 Target Design (HDL Model) input in_iface<uint32_t>; output out_iface<uint32_t>; void store_word() { uint32_t temp = memory; memory = recv(in_iface); ... send(out_iface, temp); } Input interface#N Output interface#M Reaction Checker Input Interface Adapters (Serializers) Output Interface Adapters (Deserializers) Reference Model (TLM) Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  26. Problems caused by time abstraction • Design state uncontrollability • Design|Model is not deterministic  Problems in stimulus generation & coverage tracking • Reaction order ambiguity • Order of reactions is unpredictable  Problems in reaction checking Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  27. Design state uncontrollability Design’s Inputs/Outputs S R1 R2 Design’s State Uncontrollable actions Model’s State PreImpl(S’)=false S’ PreImpl(S’)=true S’ Nondeterministic behavior Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  28. Reaction order ambiguity Model Execution Trace recv(in_iface, S); ... Output Interface’s Queue send(out_iface, R1); Failed: R2  R1 ... R2 R1 Passed: R2  Queue send(out_iface, R2); Design’s Inputs/Outputs S R2 R1 Different order Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  29. Agenda • Introduction • Digital hardware design • Simulation-based verification • Time abstraction in hardware modeling • Main part • Time abstraction levels • Model-based reaction checking • Error diagnostics • Conclusion • C++TESK testing toolkit • Future work • Questions & answers Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  30. To be continued…Questions? Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  31. Reaction arbitration • Reaction arbiter finds a model reaction corresponding to a reaction received from the target design • Reaction checking accuracy depends not only on the model abstractness, but on reaction arbitration as well • Each output interface has its own reaction arbiter • Reaction arbiters encapsulates all reaction ordering aspects of the reaction checker Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  32. Model-based reaction checker Target Design Reaction Checker Reference Model Model’s Reactions Reaction Arbiters Input Interface Adapters Output Interface Adapters Stimuli Reaction Comparators Design’s Reactions Verdict Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  33. Reaction arbiter types • Deterministic model-based arbiters arbiter: 2Reaction Reaction  {fail} • Adaptive arbiters arbiter: 2Reaction Feedback  Reaction  {fail} • Two-level arbiters arbiter(reactions)  arbiter2(arbiter1(reactions), feedback) • Nondeterministic model-based arbiter arbiter1: 2Reaction 2Reaction : arbiter1(reactions)  reactions • Adaptive arbiter arbiter2: 2Reaction Feedback  Reaction  {fail} Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  34. ✕ Deterministic model-based arbiter S R Model’s Reactions send(R1); Order is defined ... R2 R1 Reaction Arbiter send(R2); FIFO Design’s Reactions R1 R2 R1 Comparison Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  35. ✕ Adaptive arbiter S R Model’s Reactions send(R1); R1 Order is undefined ... Reaction Arbiter send(R2); R2 Get(R1) Design’s Reactions R1 R2 R1 Comparison Feedback Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  36. ✕ Two-level arbiter S R Model’s Reactions send(R1); R1 Order is partially defined Candidates ... Arbiter #1 send(R2); R2 Arbiter #2 Get(R1) Design’s Reactions R1 R2 R1 Comparison Feedback Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  37. Reaction checking algorithm On model reaction R on interface out: Reactionsout := Reactionsout {R} wind(TimerR) On model reaction’s time-out: return “Missing reaction” On design’s reaction R’ on interface out: Candidateout := Reactionsout if(|Candidateout|  2) { Candidateout := Arbiter1out(Reactionsout) if(|Cadidatesout|  2) Candidatesout := Arbiter2out(Reactionsout, R’); } assert(|Cadidatesout| < 2) if(Cadidatesout = ) return “Unexpected reaction” if(R’  get(Candidatesout))) return “Incorrect reaction” Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  38. Simple error classification • “Missing reaction” The reference model generates a reaction, but the design’s reaction is not appeared in time • “Unexpected reaction” The target design produces a reaction, but it is not expected by the reference model • “Incorrect reaction” Both the reference model and the target design generate reactions, but those reactions are different Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  39. Classification of abstraction levels •  Cycle-accurate models G (out |Reactionsout| < 2) • Cycle-accurate models (Time(R) = 0) • Quasi cycle-accurate models (otherwise) •  Order-accurate models G (out |Reactionsout| < 2  |Arbiter1out(Reactionsout)| < 2) • Order-accurate models (Arbiter1out = FIFO) • Quasi order-accurate models (otherwise) • Order-inaccurate models otherwise Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  40. Error diagnosis problem 0xf953e8d83a9b9209  0x19c3827ab2920e58 0x19c3827ab2920e58  0xf953e8d83a9b9209 Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  41. Error diagnosis approach ○,■ ○, ●,● □,□ ○,○ ,○ ○,○ ●,● ○, ●,● ,□ ●,■ ■,■ ●,○ □,○ ●,○ ○,● ○,● ●,○ □,□ ■,■ Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  42. Control errors model • , =  • ○,○  , • ○,● + ●,○  ○,○ + ●,● • ○,■ + ●,○  ○,○ + ●,■ • ○, + ,○  ○,○ + , • ○,● + ●,  ○, + ●,● • ○,● + ,○  ,● + ○,○ Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  43. Functional errors model • ○,□  ○,○ • ○,■ + ●,□  ○,□ + ●,■ • ○, + ,□  ○,□ + , • ○,■ + ●,  ○, + ●,■ • ○,● + ,□  ,● + ○,□ Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  44. Agenda • Introduction • Digital hardware design • Simulation-based verification • Time abstraction in hardware modeling • Main part • Time abstraction levels • Model-based reaction checking • Error diagnostics • Conclusion • C++TESK testing toolkit • Future work • Questions & answers Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  45. C++TESK testing toolkit • Development of hardware models at different abstraction levels and model adapters • Description of test coverage and test scenarios • Report generation (coverage and errors) • Automated test sequence generation based on state graph exploration • Test execution parallelization based on distributed state graph exploration Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  46. C++TESK testing toolkit (cont.) Web: http://forge.ispras.ru/projects/cpptesk-toolkit E-mail: cpptesk-support@ispras.ru Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  47. Conclusion • Time abstraction hides control logic (timing) of a design (pipelining, arbitration, queuing, etc.) • Time-abstract models are easier to develop and sufficiently easier to maintain (timing is changeable) • Time-abstract models reduce verification efforts and allow creating reusable tests (quality is reduced also) • Verification quality can be increased by refining time properties of a model (events ordering, durations, etc.) Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  48. Conclusion (cont.) • Interface transformation • serialization(S): S inputs • deserialization(R’): outputs R’ • Reaction queuing • send(R) is asynchronous: enqueue(R) • Reaction arbitration • arbiter1(queue)  candidates • arbiter2(candidates, R’)  R R, R’ • Reaction comparison • compare(R, R’)  status • Error diagnosis • diagnose({Ri, Ri’}i=1,n)  diagnosis Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  49. Contacts • Institute for System Programming of RAS (ISPRAS)http://www.ispras.ru • Hardware Verification R&D @ ISPRAShttp://hardware.ispras.ru • Alexander Kamkinkamkin@ispras.ru Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

  50. The EndThank you! Questions? Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia

More Related