1 / 18

Coverage Solutions on Emulators

Coverage Solutions on Emulators. Ravi P Gupta. Agenda. Functional Verification Overview (~5 Mins ) Traditional Verification Challenges Future requirements and Solutions Code coverage with PXP (~5 Mins ) Performance analysis with coverage enabled (~5 Mins )

joshwa
Download Presentation

Coverage Solutions on Emulators

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. Coverage Solutions on Emulators Ravi P Gupta

  2. Agenda • Functional Verification Overview (~5 Mins) • Traditional Verification Challenges • Future requirements and Solutions • Code coverage with PXP (~5 Mins) • Performance analysis with coverage enabled (~5 Mins) • PXP Code coverage Result analysis • Support of Functional coverage Presentation Title

  3. Functional Verification • Definition of a test plan. • Implementation using random test generators that produce a large number of test cases. • Comparing the result to the expected results in order to say if the test passed. • Analyze how much functionality of the design has been verified. • coverage tools – measures the percentage of design functionality covered. • Detect the occurrence of events in the test plan. • Provide information related to the progress of the test plan. • Analysis of the coverage reports allows the verification team to modify the directives for the test generators in Verification Presentation Title

  4. Challenges in Functional Verification • Around 70% of product development cycle time is consumed in verification activity. • Simulation based verification is very slow and no longer sufficient to meet the demands of a complex IPs and SOC. • Dedicated hardware solutions are too expensive to develop. • Considerable effort is invested in finding ways to close the loop of coverage analysis and test generation. Presentation Title

  5. Requirement & Solution Requirements • Accelerating functional verification • Closing verification process Solution • Hardware accelerated simulation Can verification closure be accelerated?? Hardware Accelerator Testbench Module 2 is synthesized & compiled into Custom processors Module 0 Module 1 Module 2 Presentation Title

  6. Hardware Accelerated Simulation • Pros • Much faster than simulation. • Provides simulation like verification flow. • Debugging is easier than customize hardware. • Cons (Obstacles to overcome) • Mapping RTL design into the hardware can be substantial longer. • SW-HW communication speed can degrade the performance. • Tool cost is much more than simulators. Presentation Title

  7. Idea!! • The addition of coverage to emulators can accelerates the detection of inadequate functional verification and augments the efficiency of the verification engineer in writing test cases by focusing on uncovered areas in the design. Presentation Title

  8. Metric driven verification flow Presentation Title

  9. Simulation vs. Emulation • Design has two main sub-module • Downstream • Upstream Presentation Title

  10. Steps to generate Toggle database • Instrumentation add +tcov and +tcovType+ to elaboration command • Run the design irun –R +ixccWorkDir+<> +ixccTest+<> • Report generation (Equivalent to .res file of internal solution) ixcc–inputDir <> -input <> -summary | tee <>.log NOTE: tcovType can be only portsor ports, Verilog & VHDL variables, Verilog nets & VHDL signals Presentation Title

  11. Result analysis (1/3) Presentation Title

  12. Result analysis (2/3) • Coverage results come in txt file as below : Instance Name: mem_tb.DUT File Name: mem.v Hit(Full) Hit(Rise) Hit(Fall) Signal 1 1 1 clk 0 1 0 rst <><><><><><><><><><><><><><><><><><><><><><><><><><><><> : Instance Name: mem_tb.DUT.addr_inst File Name: mem.v Hit(Full) Hit(Rise) Hit(Fall) Signal 1 1 1 a[7] 0 1 0 out[7] Presentation Title

  13. Result analysis (3/3) LOG = Local Overall Grade LOC = Local Overall Covered OG = Overall Grade OC = Overall Covered Instance LOG LOC OG OC --------------------------------------------------------------------------------------------------------------- mem_tb.DUT 81.5 44 / 54 87.5 77 / 88 mem_tb.DUT.addr_inst 97.1 33 / 34 97.1 33 / 34 • Merging of different test coverage database is possible. • iccr support likely to come in next release. Presentation Title

  14. Performance impact Presentation Title

  15. Steps to generate functional cov. database • Instrumentation add +sv and –functional coverage options to elaboration command • Run the design irun –R <irun options> • Report generation (Equivalent to .res file of internal solution) iccr –gui –cov.work/scope/test Presentation Title

  16. Conclusion • Palladium-XP is able to support most of the SV functional coverage constructs and toggle coverage • Coverage on Emulation without much penalty on performance & area utilization. •  Traditional flow for result analysis. PXP, not only just accelerate the verification but also verification closure. Presentation Title

  17. Presentation Title

  18. Presentation Title

More Related