Parameters, UVM, Coverage & Emulation Take Two and Call Me in the Morning

Transcription

1 Parameter, UVM, Coverage & Emulation Take Two and Call Me in the Morning Michael Horn Mentor Graphic Corporation Colorado, USA Bryan Ramirez Mentor Graphic Corporation Colorado, USA Han van der Schoot Mentor Graphic Corporation Ottawa, Canada Abtract- Parameterized IP continue to expand in uage. Parameterized IP alo continue to expand in ize which compound verification complexity. Previou DVCon paper have addreed iue related to uing parameter with UVM [1] and employing code, functional and aertion coverage with parameterized IP [2]. They focued on thee apect for conventional imulation. However, with the growing ue of emulation for hardware-aited imulation acceleration, additional conideration emerge. What capabilitie doe the ue of an emulator facilitate, or perhap impede? How can thi be exploited to verify parameterized IP fater and more efficiently? I. Introduction Semiconductor proce technology and FPGA platform continue to expand the number of tranitor and gate that are available for engineer to exploit. The only way to utilize thi additional capacity and till meet tight chedule for aggreive time-to-market window i via the ue of Intellectual Property (IP). Conequently, IP reue i eential to the expanion of the emiconductor indutry. Where doe all thi IP originate? It may come from companie dedicated to developing IP. It may come from FPGA vendor. It may be developed internally within a company. Regardle of origin, mot IP will be ued in more than one context. Thi drive IP creation to yield flexible deign that are parameterized to enable varying configuration to fit different intended ue cae. SytemVerilog parameter bring great modeling power, but they alo bring great reponibility to deign and verification engineer to enure that parameterized model function correctly. Some of the area of reponibility have already been invetigated in previou DVCon paper [1] [2]. One paper, entitled Parameter and OVM Can t They Jut Get Along? [1] dicued variou technique aociated with parameter and their interaction with an OVM baed environment. Do thee technique continue to work with UVM? What about when emulation i a requirement to accelerate UVM? The following ection will reviit the original paper and addre thee quetion. Thi involve uch apect a the configuration pace, parameterized tet, parameterized virtual interface and parameter paing while creating a ingle unified tetbench that can work in both imulation and emulation. Another paper, entitled Relieving the Parameterized Coverage Headache [2] explored the topic of coverage for parameterized IP. The paper content remain largely applicable in the context of both UVM and emulation, though ome adaptation are neceary. A pecific area of emphai i achieving parameter coverage within a dual domain environment a i required for emulation. Another area of exploration i the employment of SytemVerilog covergroup and cover directive on an emulator to achieve coverage cloure fater and more effectively. The work captured in thee earlier paper provide valuable leon, epecially when updated for UVM and coemulation. When an emulator i part of the verification trategy, what unique opportunitie doe it provide? The emulator bring order of magnitude improvement in run time performance. Thi i one of the reaon why an emulator become a requirement for a verification effort. The emulator i alo a huge reource of parallel execution unit. How can that parallelim be exploited? To acce the performance and capacity of an emulator, a dual top tetbench architecture mut be employed. How do two top level impact parameter uage in the deign and a UVM tetbench? With the emulator utilizing real hardware, more detailed analyi and compile are required which conequently take more time than imulation compile. Targeting real hardware alo bring certain limitation on what part of the SytemVerilog language can be harneed. How can thee conideration be mitigated to allow for full deign and parameter exploration? Thee quetion and more will be invetigated and anwered below. II. Parameter, UVM and Emulation The paper Parameter and OVM Can t They Jut Get Along? [1] explore the uage of OVM for verifying highly parameterized IP. It i expected that the reader be familiar with that paper a information i principally not duplicated here. Mot ection of the original paper will be viited and updated for both UVM and co-emulation with

2 the notable exception of the Coverage with Parameter ection from [1]. That topic i fully covered by the econd paper which i viited in Section IV. A. UVM Configuration Space The original paper [1] firt dicue the uage of the OVM configuration pace when parameter are ued with a DUT. Uage of SytemVerilog parameter i required in ome circumtance uch a to control bu and addre width. Parameter are alo ued in conjunction with generate tatement to control if a portion of a parameterized IP hould exit in a configuration of the deign or not. A originally recommended, if a configuration control mut be a parameter becaue of SytemVerilog rule [5] uch a generate tatement and bu width definition, then continue to ue a parameter. If a mechanim exit to have the deired controllability and functionality without uing a parameter, then avoid a parameter. The OVM configuration pace only allowed for tring, integral type and object handle. Thi limitation implie that configuration information had to be wrapped in an object to be placed into the configuration pace if it wa not a tring or integer. UVM doe not retrict the type of information that can be placed into the configuration pace thu providing more flexibility. However, even with the added flexibility, good practice i to ue an object to group configuration attribute together. Thi allow for eaier randomization of configuration value a well a cla-baed coverage ampling. B. Parameterized Tet In both OVM and UVM, clae are regitered with the factory to enable eay contruction and potential replacement. In both OVM and UVM, the factory provide both a type-baed and a tring-baed mechanim for maintaining the lit of regitered clae. The former i invoked when making a UVM call uch a <cla_name>::type_id::create() which i the primary uer API. A parameterized cla when regitered with the factory uing the `ovm_component_param_util() or `uvm_component_param_util() macro only regiter with the type-baed factory. run_tet() only ue the tring-baed factory when intantiating the tet elected to be run. A conflict exit here ince we have the type-baed factory ued for regitration, but the tringbaed factory i ued for contruction. A decribed in [1], we need to expand the macro and augment it to explicitly regiter a parameterized tet with both the type and the tring-baed factorie. By expanding the `uvm_component_param_util() macro for a hypothetical parameterized tet called tet1, we would end up with the following: cla tet1 #(int BUS_WIDTH = 16, int ADDR_WIDTH = 5) extend tet_bae_c; typedef uvm_component_regitry #( tet1 #(BUS_WIDTH, ADDR_WIDTH) ) type_id; tatic function type_id get_type(); return type_id::get(); endfunction virtual function uvm_object_wrapper get_object_type(); return type_id::get(); endfunction... endcla : tet1 Thi code then need to be modified to add in the econd parameter argument to the uvm_component_regitry typedef. Thi econd argument i what regiter the cla with the tring-baed factory which i exactly what i needed. We alo add a type_name data member and a function that return that type_name data member to be conitent with the unparameterized factory regitration. The needed addition are highlighted in blue.

3 cla tet1 #(int BUS_WIDTH = 16, int ADDR_WIDTH = 5) extend tet_bae_c; typedef uvm_component_regitry #(tet1 #(BUS_WIDTH, ADDR_WIDTH), "tet1") type_id; tatic function type_id get_type(); return type_id::get(); endfunction virtual function uvm_object_wrapper get_object_type(); return type_id::get(); endfunction cont tatic tring type_name = $formatf("tet1 #(%1d, %1d)", BUS_WIDTH, ADDR_WIDTH); virtual function tring get_type_name (); return type_name; endfunction // get_type_name... endcla : tet1 With the factory regitration updated for UVM, a typedef i now needed to pecialize the tet1 cla in the top level. For a imulation-only tetbench, a ingle top level module i generally ued. To create an emulation-ready tetbench, two top level are required [3] [4]. Since run_tet() i called from the HVL top level, that i alo where typedef need to be placed for any parameterized tet. The decription of how thi mechanim work i given in [1]. module hvl_top (); parameter BUS_WIDTH = 32; parameter ADDR_WIDTH = 4; dut #(.BUS_WIDTH(BUS_WIDTH),.ADDR_WIDTH(ADDR_WIDTH)) i_dut(...); typedef tet1 #(.BUS_WIDTH(BUS_WIDTH),.ADDR_WIDTH(ADDR_WIDTH)) tet1_t; initial begin run_tet("tet1"); end endmodule : hvl_top When more than one parameterized tet i defined, a i often the cae, each parameterized tet mut be pecialized with a typedef in the hvl_top module. With the pecialization in place, the tandard +UVM_TESTNAME mechanim can be ued to elect each parameterized tet from the command line. The name that i ued i the econd parameter paed to the uvm_component_regitry which in thi cae i tet1. C. Regreion Throughput Optimization Many option exit for etting parameter value for each imulation/co-emulation run [1]. The original option included uing `define and tool witche along with multiple run for a ingle parameter configuration. A pure imulation flow provide the mot flexibility. When uing a dual-top, emulation-ready tetbench architecture, additional conideration are in order. Longer compile time and reduced flexibility mut be pondered when determining how to et parameter value.

4 One option that i till poible in a co-emulation context i to utilize `define for controlling the parameter value. A before in [1], when `define are ued a recompile i required to change parameter value. With an emulator in ue, that mean re-launching two compile flow; one for the imulator ide and one for the emulator ide a hown in Figure 1. HVL Compile Optimize Adjut Parameter Run HDL Analyze HDL Compile Figure 1. Parameterization Change Uing Define The `define hould be placed into a ingle file that i hared between the HVL and HDL top level module. With that in place the flow i to elect a parameter configuration by etting the `define value, then compile, optimize, and ultimately imulate a uite of tet. Uing `define will do the job, but at the expene of a full recompile with every parameter configuration change. An alternative that can reduce ome of the compilation overhead would be to ue witche provided by tool vendor. Mot tool allow for parameter value to be pecified at optimization/hdl compile time. Thi mean that compiling the HVL code and analyzing the HDL code only ha to be done a ingle time. Thi i a potentially ignificant time aving when parameter value are changed a hown in Figure 2. HVL Compile Optimize Adjut Parameter Run HDL Analyze HDL Compile Figure 2. Parameterization Change Uing Tool Switche Uing tool witche to et a parameter configuration involve two tool flow. It would be advantageou to have a ingle place to pecify parameter value that are then paed to each tool flow. With the `define flow, a ingle file wa ued with `define value that wa then `included into each top level module. To get the ame functionality, everal option exit depending on tool upport. Parameter value could be controlled from a com cript and/or makefile. The cript/makefile would output file that are pecific to the HVL and HDL compile flow. Another option i if both HVL and HDL compile flow undertand the ame format for pecifying parameter value change, allowing a ingle file to be ued that can then be paed to both compile flow. Regardle of the choice between uing `define or tool witche, multiple run hould be performed with each iteration of the compile flow a illutrated in Figure 3. Thi can be accommodated by different SytemVerilog eed being upplied to the run command or different tet being choen uing the +UVM_TESTNAME pluarg. Such

5 flexibility i till available when uing an emulator becaue the eed value and tet election i done in the HVL top level which remain in a SytemVerilog compliant imulator. HVL Compile Optimize Adjut Parameter Run HDL Analyze HDL Compile Multiple Run Figure 3. Multiple Run Optimization D. Parameterized Virtual Interface If a bu ize of a deign port i controlled by a parameter, the tetbench will alo need to undertand any bu ize change to be able to communicate properly with the deign. SytemVerilog-baed tetbenche uually ue virtual interface handle pointing to interface to make the pin-level connection to the deign. Hence, thee interface will alo need to be parameterized and hare parameter value. How do you get the parameterized virtual interface handle firt defined and then ubequently paed to the tetbench? With OVM an object wrapper mut be created to pa the parameterized virtual interface handle becaue the OVM configuration databae only upport integral value, tring and object handle [1]. With UVM, the configuration databae allow for any type to be amaed including parameterized virtual interface handle. Thi mean that no pecial accommodation need to be made other than to get the correct parameter value to the correct location which i dicued further in ub-ection E. With parameterized virtual interface handle paing orted, it need to be determined what exactly the parameterized virtual interface handle will be pointing to. Thi i where emulation change the picture a bit. A illutrated in Figure 4, in pure imulation, a driver contain all pin-wiggling code and a ingle interface contain the pin. With emulation, the pin-wiggling code i extracted from the cla baed environment and placed into a interface (Monitor and Driver in Figure 4) to make it part of the HDL domain. The pin-wiggling code till interact with a pin interface that contain the pin to maintain proper eparation of concern [3] [4]. Conventional Simulation View Top New portable Co-Emulation View HVL Top Tak/Function/Pipe Monitor Driver Pin IF Pin IF DUT DUT Figure 4. Co-Emulation Agent HDL Top

6 With the UVM configuration mechanim and the additional SytemVerilog interface, two call are made to place itor and driver parameterized virtual interface handle into the configuration databae from the HDL ide. Thi reult in code that i imilar to the following: interface driver_bfm #(int BUS_WIDTH = 32, ADDR_WIDTH = 4) ( pin_intf #(BUS_WIDTH, ADDR_WIDTH) );... endinterface : driver_bfm interface itor_bfm #(int BUS_WIDTH = 32, ADDR_WIDTH = 4) ( pin_intf #(BUS_WIDTH, ADDR_WIDTH) );... endinterface : itor_bfm module hdl_top (); parameter BUS_WIDTH = 32; parameter ADDR_WIDTH = 4; pin_intf #(BUS_WIDTH, ADDR_WIDTH) i_pin_intf(...); driver_bfm #(BUS_WIDTH, ADDR_WIDTH) i_drv_bfm (i_pin_intf); itor_bfm #(BUS_WIDTH, ADDR_WIDTH) i bfm (i_pin_intf); initial begin import uvm_pkg::uvm_config_db; uvm_config_db #(virtual driver_bfm #(BUS_WIDTH, ADDR_WIDTH)) ::et(null, "*", "drv_bfm", i_drv_bfm); uvm_config_db #(virtual itor_bfm #(BUS_WIDTH, ADDR_WIDTH)) ::et(null, "*", "_bfm", i bfm); end endmodule : hdl_top Focu on the uvm_config_db call. The uvm_config_db cla i a parameterized cla with a parameter pecifying the SytemVerilog type that i employed. In thi cae the type i itelf a parameterized type that i a parameterized virtual interface handle. Each call of the et() function i now placing a parameterized virtual interface handle of the itor and the driver, repectively, into the configuration databae to be extracted by the tetbench at the appropriate location. The tetbench alo will be acceing a function defined in the uvm_config_db parameterized cla. Thi mean that the tetbench need to pecify the ame parameterized virtual interface handle with the ame parameter value to be able to acce value tored with a et() call. Thi look a follow:

7 cla itor #(int BUS_WIDTH = 16, int ADDR_WIDTH = 5) extend uvm_itor; `uvm_component_param_util( itor #(BUS_WIDTH, ADDR_WIDTH) ) virtual itor_bfm #(BUS_WIDTH, ADDR_WIDTH) m_bfm; function void build(); uvm_config_db #(virtual itor_bfm #(BUS_WIDTH, ADDR_WIDTH)) ::get(thi, "", "_bfm", m_bfm); endfunction : build endcla : itor The quetion i now how to get the parameter value to the itor, driver, agent, etc. to allow them to pull the correct parameterized itor and driver handle from the configuration databae. E. Parameter Paing A dicued in [1], the eaiet way to work with all the parameter and to pa them through the tetbench hierarchy tarting at the tet i to ue a et of three macro. The three macro are hown here: // Declaration `define param_declare #(int BUS_WIDTH = 16, int ADDR_WIDTH = 5) // Intantiation / Mapping `define param_map #(.BUS_WIDTH (BUS_WIDTH), ADDR_WIDTH (ADDR_WIDTH) ) // String Value `define param_tring $formatf("#(%1d, %1d)", BUS_WIDTH, ADDR_WIDTH) The firt macro expand to become the definition of all the parameter in the tetbench. The econd macro i ued when creating type and handle. Thi macro contain the mapping of all the macro from the object, module, or interface to the type or handle that i created within the object, module, or interface. The third macro provide a tring repreentation, which i ueful for creating meage. Uing the macro reult in more concie code. Following are the HVL and HDL top level re-coded to ue the macro: module hvl_top (); parameter BUS_WIDTH = 32; parameter ADDR_WIDTH = 4; dut `param_map i_dut(...); typedef tet1 `param_map tet1_t; initial begin run_tet("tet1"); end endmodule : hvl_top

8 module hdl_top (); parameter BUS_WIDTH = 32; parameter ADDR_WIDTH = 4; pin_intf `param_map i_pin_intf(...); driver_bfm `param_map i_drv_bfm (i_pin_intf); itor_bfm `param_map i bfm (i_pin_intf); initial begin import uvm_pkg::uvm_config_db; uvm_config_db #(virtual driver_bfm `param_map) ::et(null, "*", "drv_bfm", i_drv_bfm); uvm_config_db #(virtual itor_bfm `param_map) ::et(null, "*", "_bfm", i bfm); end endmodule : hdl_top Tetbench code alo become more concie a hown here: cla tet1 `param_declare extend tet_bae_c; typedef uvm_component_regitry #(tet1 `param_map, "tet1") type_id; tatic function type_id get_type(); return type_id::get(); endfunction virtual function uvm_object_wrapper get_object_type(); return type_id::get(); endfunction cont tatic tring type_name = {"tet1, `param_tring}; virtual function tring get_type_name (); return type_name; endfunction // get_type_name... endcla : tet1 The original paper did not conider UVM or emulation when defining thoe macro. Fortunately, no change are needed a the macro are completely orthogonal to OVM or UVM uage and they can be ued eamlely with both the imulation and emulation compilation flow. III. Parameter, Coverage and Emulation The paper Relieving the Parameterized Coverage Headache [2] explore all apect of coverage in the context of a parameterized deign and tetbench. The majority of the paper decribe how to develop coverage model when parameter are involved for a cla-baed tetbench. Thoe technique are till valid and upported ince the cla baed tetbench continue to reide and run in a SytemVerilog compliant imulator. Some technique for module-

9 baed coverage are alo decribed [2] which are reviited here in particular becaue the module end up being part of the HDL top level code bae that will go onto the emulator. A. Module-Baed Coverage Module-baed coverage i generally ued when covering internal apect of a deign [2]. Such coverage might be compoed of SytemVerilog covergroup or SytemVerilog aert and cover propertie. The module that contain thee contruct are generally bound into a deign uing the SytemVerilog bind tatement. Additionally, thee module can contain generate tatement that conditionally declare a covergroup, aertion and/or cover directive. The ame name can be retained for each of the item in the generate option which then allow for merging with different parameter value a illutrated in [2]. Since the merge algorithm i not defined in the SytemVerilog LRM [5], a avvy tool choice will give the bet reult. With an emulator a part of the flow, again a avvy tool choice i required to enure that tatement uch a bind, generate, aert, cover, etc. are upported by the emulator and the emulator tool flow. When the emulator i part of the verification effort, additional thought mut go into the creation and ampling of the coverage model in the yntheizable HDL domain. With emulator hardware, the ynthei tep i performed to tranform HDL code including coverage code to fit into the hardware. In general, hardware ynthei place modeling limitation on all apect of the SytemVerilog language including the coverage contruct which mut be conidered when defining the HDL ide coverage model. A avvy emulator choice will facilitate thi by providing upport for a rich ubet of the coverage contruct. In a pure imulation environment, it i generally not an iue to pa data collected via a module or interface bound into the deign to the UVM-baed tetbench a the entire deign and tetbench all live in the ame memory footprint. With an emulator in the picture, the deign live in the emulator and the tetbench live in memory on a erver. To get coverage data to the tetbench i now not jut a imple matter of paing a pointer around. Intead, the entire coverage data et mut be paed from the emulator to the imulator which reult in additional overhead and potentially lower co-emulation run time. To eliminate thi iue, ome coverage data that ued to reide in a tetbench cla, hould now alo be moved to a module/interface o that it can be bound into the deign hierarchy and become part of the emulator image. Thi remove the overhead while till allowing for ampling of the required coverage data. At the end of the co-emulation run, a ingle tranfer of the coverage data will take place intead of contant tranfer throughout the imulation. IV. Parameter and Emulation When working to verify a parameterized IP with an emulator, the benefit of an emulator hould be maximized. A dicued earlier, an emulator run fat, though time mut be pent up front to compile and target the emulator hardware. Conequently, trategie mut be devied where the deign can be compiled once while enabling a many emulation run a poible. A. Multiple Configuration Compiled Together When working at a parameterized IP level, the deign i generally going to be maller than the capacity of an emulator. A natural thought i how thi capacity can be more fully utilized to give more verification throughput. One approach i to intantiate multiple configuration of the ame parameterized IP in the ame top level that would reult in code like the following: module hdl_top (); parameter BUS_WIDTH1 = 32; parameter ADDR_WIDTH1 = 4; parameter BUS_WIDTH2 = 16; parameter ADDR_WIDTH2 = 2; param_deign #(BUS_WIDTH1, ADDR_WIDTH1) i_dut1 (...); param_deign #(BUS_WIDTH2, ADDR_WIDTH2) i_dut2 (...); endmodule : hdl_top

10 More than two intance could be created if capacity and epecially deign configuration flexibility allow. The latter factor into our available option for how to timulate and check the deign functionality. 1) Optional Functionality In many cae a deign operate exactly the ame irrepective of parameter configuration with the exception of ome functionality that i conditionally preent baed on generate tatement in a deign. For example, a deign might have a parity bit or a CRC calculation in one configuration with ome imple logic to check/generate the parity and report any error that are detected. If the ret of the deign behave the ame, then why not inject the ame timulu into two verion of the ame deign. HVL Top / Tetbench Scoreboard 2 Scoreboard 1 HDL Top parameter PARITY = 1 eq e q r 1 2 drv drv drv p i n p i n param_deign #(.PARITY(1)) parameter PARITY = 0 param_deign #(.PARITY(0)) p i n p i n 1 2 Figure 5. Same Stimulu, Different Analyi A hown in Figure 5, the ame timulu i applied to two different driver intance. The driver are parameterized to undertand if parity need to be generated or not. To get the ame timulu to two different require ome modification in the driver. The driver now mut have handle to all of the driver and end data to each driver a it come in from the equencer. Thi may not be the mot performance optimal mean of ditributing the timulu to multiple driver ince it require two round trip call between the imulator and the emulator. Depending on the timulu, a torage tructure could be created on the emulator ide to accept a full timulu tranaction and then ditribute the tranaction on the emulator ide. The analyi portion of the tetbench alo ha to undergo modification. With two (or more) configuration of the deign are being exercied imultaneouly, two independent coreboard need to be in place to enure that any problem with a deign intance are iolated. Coverage will be deign dependent. In ome cae, two coverage intance will be required and in other cae a ingle coverage intance hould be collecting coverage for both intance of the deign. More detail on uage of each cae i available in [2]. If the coverage hould be combined, then a uvm_component derived cla will need to be defined that can handle data from both deign and then ample a ingle covergroup. The type_option.merge_intance = 1 control could alo be ued to get combined coverage when multiple intance of a covergroup are ued. 2) Non-Overlapping Configuration Often a parameterized deign can not have the ame timulu applied to it with the ame timing. A imple example would be tranferring a 1024-bit packet of data over a 32-bit bu or a 16-bit bu. The ame data i tranferred, but the 16-bit bu verion will take twice a long a the 32-bit bu verion. If a cheme wa ued a hown in Figure 5, then there would be very large gap between data tranfer when ending data to a 32-bit bu. Thi would not fully exercie any back-to-back corner cae that may exit in the deign when parameterized to 32-bit. In cae where the

11 functionality and or timing doe not align, a different option can be explored. The overhead of compilation for the emulator can till be minimized by intantiating multiple verion of the deign, but now with a muxing cheme inerted to allow for election of the deign configuration a tetbench will exercie. Thi will enable more coemulation run without having to recompile. HVL Top / Tetbench Scoreboard From Tetbench HDL Top eq e q r drv drv p i n param_deign #(.BUS_WIDTH(32)) param_deign #(.BUS_WIDTH(16)) p i n Figure 6. Muxe Control Deign Activation With the muxe in place, the tetbench now utilize a ingle driver and a ingle itor. With the example from above, the will be built to handle the maximum ize of data tranfer available in a deign configuration which mean that bue and logic will utilize the maximum ize. The will then be configured from the tetbench to undertand how much of a bu i actually valid to be ued in the pecific tetcae. Thi information i paed acro from the tetbench during initialization time a the tetbench now determine which deign configuration will be active. The tetbench will alo control which deign configuration i connected to the. On the analyi ide, a ingle checking path exit that again mut be aware of the deign configuration being exercied. Thi information can eaily be paed in a configuration object a decribed in both [1] and [2]. Coverage can alo utilize the ame configuration object to determine what need to be ampled and how. Other mechanim uch a SytemVerilog pluarg could alo potentially be ued to control the mux elect line. B. Parameter Sharing When working with an emulator, two top level module are created. How are parameter hared between the two top level and between the two compile flow? A dicued above, `define could be ued a well a tool witche. Another option that i uually available i to place parameter in a SytemVerilog package. The SytemVerilog package can then be hared and compiled for both top level. Thi reult in a ingle location where parameter can be defined and manipulated. C. Staged Configuration In mot cae an emulator i a hared reource that i not in abundant upply. With that in mind, it i advantageou to have the emulator performing verification run a much a poible. Thi i in contrat to Linux baed erver that are generally highly available. Engineer can ue thi ituation to their advantage. Looking at the abtracted compile flow a hown in Figure 3, the only time the emulator i involved in the effort i when it come time to actually run. Everything before that tep i baed on executing oftware on Linux-baed erver. Thi lead to the trategy of precompiling a many different configuration of a deign and tetbench a poible and having them taged and ready to run on an emulator when it i available. V. Concluion With the contant puh to create fater deign more quickly, properly verified parameterized IP become extremely valuable. Enuring that all the valid and viable configuration of parameterized IP i exercied in a hort a time a poible greatly aid the overall goal of chip development with increaed productivity and reduced rik. When a modern UVM tetbench with a complete coverage model i married with emulation, they provide unmatched peed and hence parameterized IP can be verified more effectively than ever before.

12 Reference [1] Bryan Ramirez and Michael Horn (2011) Parameter and OVM Can t They Jut Get Along? DVCon [2] Chritine Lovett, Bryan Ramirez, Stacey Secatch and Michael Horn (2012) Relieving the Parameterized Coverage Headache DVCon [3] Han van der Schoot, Anoop Saha, Ankit Garg and K. Sureh (2011) Off to the Race With Your Accelerated SytemVerilog Tetbench DVCon [4] Han van der Schoot and Ahmed Yehia (2015) UVM & Emulation: How to Get Your Ultimate Tetbench Acceleration Speed-Up DVCon Europe [5] IEEE Standard for SytemVerilog: Unified Hardware Deign, Specification and Verification Language, IEEE Std [6] Open Verification Methodology (OVM) - [7] Univeral Verification Methodology (UVM) -