ESSENTIAL OVM CONCEPTS

1. ESSENTIAL OVM CONCEPTS MXG APRIL 2011

2. WHY DID SYNCHRONOUS DESIGN BECOME POPULAR?

3. SYNCHRONOUS DESIGN • TRACTABLE • MANAGE RELATIONSHIPS TO THE CLOCK • AVOID DEALING WITH RELATIONSHIPS BETWEEN EACH PAIR OF SIGNALS • SCALABLE • ADD MORE THINGS THAT TRIGGER OFF CLOCK • REUSABLE • STANDARDIZED SYNCHRONOUS INTERFACES • ENABLES ABSTRACTION

4. VERIFYING DESIGNS IS HARD • DUH… • MULTIPLE INTERACTING STATE MACHINES • SHOW THAT ALL VALID STATES CAN BE REACHED ON ALL VALID PATHS • CONSIDER THREE FSMS WITH 8 STATES EACH • 8 x 8 x 8 = 512 STATES • O(n2) = 5122POSSIBLE TRANSITIONS • COMBINATORICS KILL US!

5. VERIFICATION METHODOLOGY • TRACTABLE • SCALABLE • REUSABLE • ABSTRACTABLE MUST EABLE US TO MANAGE COMPLEXITY IN OUR BRAINS

6. WHAT IS OVM? • VERIFICATION METHODOLOGY AND LIBRARY • PROVIDES A WAY TO APPROACH TESTBENCH CONSTRUCTION • AVOIDS “BLANK SHEET OF PAPER” SYNDROME • A WAY TO THINK ABOUT WHICH ELEMENTS YOU NEED, HOW THEY ARE RELATED TO EACH OTHER, AND HOW TO CONSTRUCT THEM • DOES NOT AUTOMATE TESTBENCH CONSTRUCTION • PROVIDES A MEDIUM FOR CREATING REUSABLE VIP

7. KEY QUESTIONS • DOES IT WORK? • DOES THE DEVICE FUNCTION ACCORDING TO ITS DESIGN SPEC? • ARE WE DONE? • HAVE WE EXERCISED ENOUGH OF THE DEVICE TO CLAIM VERIFICATION IS COMPLETE?

8. TWO LOOP FLOW VERIFICATION PLAN DESIGN SPEC TESTBENCH DESIGN SIMULATE MODIFY STIMULUS DEBUG DESIGN DOES IT WORK ? ARE WE DONE ? DONE

9. BASE PARADIGM TRANSACTION-LEVEL COVERAGE SCORE- BOARD COVERAGE STIMULUS/ RESPONSE STIMULUS/ RESPONSE TRANSACTORS MONITOR MONITOR RTL DRIVER DUT DRIVER

10. KEY POINTS • COVERAGE COLLECTORS COLLECT INFORMATION TO ANSWER “ARE WE DONE?” • SCOREBOARD DETERMINES FUNCTIONAL CORRECTNESS TO ANSWER “DOES IT WORK?” • INTELLIGENCE IS AT THE TRANSACTION LEVEL • SEPARATION OF CONCERNS • MODULARITY

11. TRANSACTIONS • A TRANSACTION IS A REPRESENTATION OF A SINGLE TRANSFER OF DATA OR CONTROL BETWEEN COMPONENTS • SYSTEM OPERATION CAN BE ABSTRACTED INTO STREAMS OF TRANSACTIONS read

12. TRANSACTION ABSTRACTION • TRANSACTION-LEVEL REFERS TO A FAMILY OF ABSTRACTIONS ABOVE RTL • MODEL OF DATA • MODEL OF TIME TOKEN LOOSELY TIMED APPROXIMATELY TIMED CYCLE ACCURATE

13. TRANSACTION COMMUNICATION PORT EXPORT • COMMUNICATION PERFOMED WITH FUNCTION CALLS INSTEAD OF NETS • NO SCHEDULER OVERHEAD • REQUIRES/PROVIDES LINKAGE • BLOCKING OR NONBLOCKING CALLS TARGET INITIATOR port.put(data); function put(T t); . . . endfunction INITIATE TRANSER EXECUTE TRANSACTION CALL FUNCTION IMPLEMENT FUNCTION REQUIRES PROVIDES

14. STIMULUS • ENCAPSULATED IN SEQUENCES • SEQUENCES ARE BEHAVIORS • INCORRECTLY NAMED • PROVIDE SEPARATION OF BEHAVIOR FROM STRUCTURE • NOT PART OF THE COMPONENT HIERARCHY • CAN BE TRANSIENT OR PERSISTENT

15. SEQUENCER • SEQUENCE/SEQUENCER INTERFACE • SEQ_ITEM_PULL INTERFACE • AKA SEQUENCER/DRIVER INTERFACE • PIN LEVEL INTERFACE SEQUENCE SEQUENCER DRIVER SEQUENCE SEQUENCE • GENERATE STREAMS OF TRANSACTIONS (AKA ITEMS) • OPTIONALLY, MANAGE RESPONSES • ARBITRATES AMONGST SEQUENCES • CONDUIT TO DRIVER • MANAGES RESPONSES • HAS A HIERARCHICAL LOCATION

16. AGENTS AGENT MONITOR COVERAGE SEQUENCE SEQUENCER DRIVER SEQUENCE SEQUENCE

17. AGENTS • REPRESENT A SPECIFIC PROTOCOL FOR A SPECIFIC INTERFACE • THREE INTERFACES • SEQUENCER, PIN, AND, ANALYSIS • REUSABLE ELEMENTS • PARAMTERIZED, CONFIGURABLE • IMPLIES MONITOR, DRIVER, ETC. ARE ALSO REUSABLE

18. A WORD ABOUT REUSE • REUSE CAN BRING BIG PRODUCTIVITY GAINS • REUSED CODE IS CODE YOU DON’T HAVE TO WRITE • SAVE TIME NOT WRITING CODE • REUSED CODE IS MORE RELIABLE THAN NEW CODE • REUSED ELEMENTS HAVE BEEN PROVEN IN AN APPLICATION • REUSED ELEMENTS HAVE BEEN THROUGH ONE OR MORE DEBUGGING CYCLES • REUSE HAS ARCHITECTURAL IMPLICATIONS • REUSE DOES NOT COME FOR FREE • YOU MUST CONSIDER DEGREES OF FREEDOM REQUIRED TO REUSE AN ELEMENT IN VARIOUS SITUATIONS

19. REUSE IN OVM • PARAMETERIZATION • CONFIGURATION • SEQUENCE LAYERING • PROTOCOL LAYERING

20. PARAMETERIZATION • PARAMETERS APPLIED AT COMPILE TIME • SYSTEMVERILOG PARAMETERS • APPLIES CONCEPTS OF GENERIC PROGRAMMING • PARAMETERS COULD BE SUCH THINGS AS: • BUS WIDTH • WORD SIZE • MEMORY SIZE • NUMBER OF MASTERS/SLAVES • ETC. class mem_agent #(int SIZE=1024) extends ovm_component; class bus_agent #(int DATA=16, int ADDR=8) extends ovm_component;

21. CONFIGURATION • PARAMETERS APPLIED AT RUN-TIME • OVM USES set_config()/get_config() INTERFACE TO STORE AND RETRIEVE CONFIGURATION PARAMTERS • TOPOLOGICAL OR MODAL MODAL TOPOLOGICAL if(!get_config_int(“slaves”, slaves)) ovm_report_error(…); for(i = 0; i < slaves; i++) begin name.itoa(i); name = { “slave_”, name }; slave[i] = new(name, this); end if(!get_config_int(“compress”, comp)) omv_report_error(…); if(comp) begin turn_on_data_compression(); end

22. SEQUENCE LAYERING BURST READ READ CONFIGURE TRANSMIT SCENARIO 1 BURST WRITE WRITE CONFIGURE RECEIVE SCENARIO 2 IDLE INITIATE TRANSFER SCENARIO 3 SCENARIO 4 DESIGN-SPECIFIC PROTOCOL-SPECIFIC SCENARIO LIBRARY TEST WRITER API COMPOSITE API PRIMITIVE API

23. PROTOCOL LAYERING PROTOCOL B SEQUENCES SEQUENCE PROTOCOL A AGENT PROTOCOL B Þ A LAYER SEQUENCE SEQUENCE LAYERING AGENT

24. MORE PROTOCOL LAYERING • CONVERT DUT TRANSACTIONS TO OPERATE OVER A BUS PROTOCOL • FRAMES Þ PACKETS Þ BYTES • REGISTER LAYERING REGISTER MAP SEQUENCE PROTOCOL AGENT ABSTRACT LAYER REGISTER LAYER SEQUENCE SEQUENCE PROTOCOL DEPENDENT TRANSACTIONS PROTOCOL INDEPENDENT TRANSACTIONS ABSTRACT SEQUENCES

25. SOC VERIFICATION REGISTER MAP MASTER SEQUENCES SLAVE DUT SLAVE BUS ADAPTER SEQUENCE REGISTER LAYER BUS PROTOCOL AGENT SLAVE SLAVE AGENT SEQUENCE SEQUENCE SLAVE

26. SUMMARY • OVM PROVIDES A METHODOLOGY FOR BUILDING TESTBENCHES THAT ANSWER “DOES IT WORK?” AND “ARE WE DONE?” • OVM ENABLES VERIFICATION TO BE TRACTABLE, SCALABLE, REUSABLE, ABSTRACTABLE • ABSTRACTION IS A KEY ELEMENT OF THE METHODOLOGY • OVM ENABLES BUILDING REUSABLE TESTBENCH ELEMENTS