1. Verification Environment Architecture Sergey Nemanov December 21, 2005 Verification Leadership Seminar

2. 2 Content n Typical verification architecture n Tests n Refmodel n Checkers n Coverage n DUT behavioral model n Configuration Layer (Scripts) n FW-HW mixed environments

3. 3 Objectives of the architecture in Verification n Detection major issues on the early stage n Making separate parts usable independently n Clear user interfaces n Job partitioning n What do you think?

4. 4 7 units of verification environment

5. 5 Found your own dialect n Application-specific test language to be developed u Recognize routines u Major protocol events u Frequently-used operations u Transactors n Invest in user interfaces, where a border between teams passes. n Separate between internal and external interfaces.

6. 6 Documents n Documentation life cycle u One-time use documents for major reviews u Permanently supported documents n MAS - MicroArchitecture Specification of units u Per unit owner

7. 7 Idea of NFSM n NFSM - Non-deterministic final state machine n Representation of most upper protocol level as NFSM. u Building a robust generic test around NFSM. u Good level of randomness and easy focus on main flow.

8. 8 Generic Test Overview n מכיר מכונת מצבים הראשי n מבדיל בין פקודות: u Legal(הפקודה לגאלית ותקינה במצב הנתון) u Erroneous(הפקודה לגאלית אבל argument לא תקין או סדרת פקודות out-of-order) u Illegal(הפקודה לא לגאלית במצב הנתון) n גלובלי n בכל מצב n לכל פקודה

9. 9 Global parameter of the generic test n do generic keeping { it.rand_count == 500; it.legal_weight == 100; it.illegal_weight == 0; it.erroneous_weight == 0; it.mismatch_weight == 0; it.clock_burst_weight == 10; };

10. 10 Commands generation per state // when idle'state keep soft idle_pwr_up_legal_wt == 2; keep soft idle_cmd0_legal_wt == 2; keep soft idle_acmd41_legal_wt == 100; keep soft idle_acmd41_nonsupp_legal_wt == 0; keep soft idle_nocmd_wt == 100; keep soft idle_cmd8_legal_wt == select {10:0;80:[1..2];10:[3..15]}; keep soft rcv_stop_cmd_before_data_legal_wt == 20; keep soft rcv_stop_cmd_mid_data_legal_wt == 20; keep soft rcv_stop_cmd_in_crc_status_legal_wt == 20; keep soft rcv_stop_cmd_around_data_block_legal_wt == 20; keep soft rcv_stop_cmd_on_data_end_bit_legal_wt == 20; keep soft rcv_stop_cmd_card_busy_legal_wt == 20; keep soft rcv_stop_cmd_and_end_of_busy_legal_wt == 100;

11. 11 Reference Model Unit n Clock-accurate/transaction-accurate n Challenges: u Requirements Engineering for Verification required. u Fuzzy corners. 90/10 u Bugs bypasses

12. 12 Checkers unit n Detect problems. n Detect problems as soon as possible. n Based on refmodel, aspire not rely on design. u Scoreboard u Packet consistency checks u Status checks u X/Z/Pullup/Pulldown checkers u Low-level bus checkers n PSL assertions n Import Formal Verification environment and checkers. FoCs. n TB self checkers

13. 13 Coverage Unit “The value of coverage in analyzing it and driving it up.” Bob Bentley, Intel Corp. n Approach of core coverage items and dimensions n Cross-coverage of core coverage units with different dimensions. n Covering around bug scenarios. n Testing Coverage Unit.

14. 14 Behavioral DUT Model n Much faster than DUT (sometimes thousand times faster) n Much more universal than particular DUT n Independent from DUT. Prevents Bug-to-bug compatible environments. n Easily injects deliberate errors n Stub for compliment DUTs

15. 15 Configuration Layer Makefile Running scripts with developed options Connection to LSF/Netbach/OneGrid/Cluster Regression/Batch mode scripts Running from snapshots Utilities

16. 16 From Unit-level to System-level n Good idea to migrate to the upper verification layer after the bug peak in the lower layer passed

17. 17 FW-HW mixed environments n Stable architectural trend in chip design to delegate more functionality to embedded processors. n Integrating FW debugging tools in Verification Environment. n Creating/loading ROM/RAM images n FW initialization burden. Starting from snapshots.

18. 18 Features of C-oriented Verification 1. Sequential in nature Appropriate for software algorithms of all kinds, for instance, DSP, Encryption. 2. More packet-based. Emulators/accelerators like it. 3. Can easily adopt parts of FW. 4. Typically cheaper than Specman-like approaches 5. High-level architectural simulator

19. 19 Intrinsic problems of C-based verification n Sequential in nature. Heavily reflects a parallel nature of hardware. n Nightmare of scheduling, multithreading, synchronization n Bulky and restricting on clock-accurate level. n Requires a wide set of software tools. Large learning curve for ASIC team.

20. 20 Discussion