1 / 10

Post-Silicon Debugging of Transactional Memory Tests

Post-Silicon Debugging of Transactional Memory Tests. Ophir Friedler , Wisam Kadry, Amir Nahir, Vitali Sokhin {ophirf, wisamk, nahir, vitali}@il.ibm.com.  Carla Ferreira, João Lourenço {carla.ferreira, joao.lourenco}@fct.unl.pt. IBM Research. Universidade Nova de Lisboa. Post Silicon.

jackson-daugherty
Download Presentation

Post-Silicon Debugging of Transactional Memory Tests

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. Post-Silicon Debugging of Transactional Memory Tests Ophir Friedler, Wisam Kadry, Amir Nahir, Vitali Sokhin {ophirf, wisamk, nahir, vitali}@il.ibm.com  Carla Ferreira, João Lourenço {carla.ferreira, joao.lourenco}@fct.unl.pt IBM Research Universidade Nova de Lisboa WTM’13, Prague, April 14, 2013

  2. Post Silicon Post-silicon validation elements: Stimulating the design under test Detecting erroneous behavior Localizing the root cause of the problem Providing a fix. WTM’13, Prague, April 14, 2013

  3. Stimulation Test generation Execution Consistency checking Repeat… Forever! Exerciser Image (Threadmill) Test Template Topology ArchitecturalModel Generation Accelerator Execution Silicon Checking OS services WTM’13, Prague, April 14, 2013

  4. Detection Consistency checking Run the same test-case from the same initial architectural state. Expect the same final architectural state ori r10,r0,170 stb r10,0(r6) lbz r11,0(r6) ... Initial State R0 = 0x1, R1 = 0x2 … Final State R0 = 0xA, R1 = 0xB … Micro-architectural state varies! Caches, page misses, pre-fetching, thread priorities WTM’13, Prague, April 14, 2013

  5. Detection And what if two different final states are manifested? ori r10,r0,170 stb r10,0(r6) lbz r11,0(r6) ... ori r10,r0,170 stb r10,0(r6) lbz r11,0(r6) ... Initial State R0 = 0x1, R1 = 0x2 … Initial State R0 = 0x1, R1 = 0x2 … Final State R0 = 0xC, R1 = 0xB … Final State R0 = 0xA, R1 = 0xB … Final State R0 = 0xA, R1 = 0xB … Final State R0 = 0xC, R1 = 0xB … MIS-COMPARE WTM’13, Prague, April 14, 2013

  6. Localization approach • 1. A test-case that produces a mis-compare is found • 2. Fast-forward to that test-case on a software simulator • (a.k.a. Reference model) • 3. Execute test case on the reference model • instruction by instruction and extract information WTM’13, Prague, April 14, 2013

  7. Localization Reduce number of resources and instructions that might be the root cause of the mis-compare Study the effect of transactions in the test-case on the final state. Justification: Force erroneous behaviour on reference model and re-create the mis-compare results WTM’13, Prague, April 14, 2013

  8. = suspicious instruction subset Localization R2 R3 R4 R1

  9. Concluding remarks Debug automation effectively reduces the debugging effort. Graph analysis holds the potential automate the localization of suspicious resources and instructions Future work: Study the impact of escaped stores in transaction aborts experiment with larger (real-world) cases WTM’13, Prague, April 14, 2013

  10. Questions WTM’13, Prague, April 14, 2013

More Related