Jump to content

Search the Community

Showing results for tags 'UVM'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Accellera Systems Initiative
    • Information
    • Announcements
    • In the News
  • SystemC
    • SystemC Language
    • SystemC AMS (Analog/Mixed-Signal)
    • SystemC TLM (Transaction-level Modeling)
    • SystemC Verification (UVM-SystemC, SCV)
    • SystemC CCI (Configuration, Control & Inspection)
    • SystemC Datatypes
  • UVM (Universal Verification Methodology)
    • UVM 2017 - Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • UVM Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM (Pre-IEEE) Methodology and BCL Forum
    • UVM 1.2 Public Review
  • Portable Stimulus
    • Portable Stimulus Pre-Release Discussion
    • Portable Stimulus 1.0
  • IP-XACT
    • IP-XACT Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • OCP (Open Core Protocol)
  • UCIS (Unified Coverage Interoperability Standard)
  • Commercial Announcements
    • Announcements

Categories

  • SystemC
  • UVM
  • UCIS
  • IEEE 1735/IP Encryption

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation


Company

Found 72 results

  1. oritk

    UVM-ML Open Architecture

    Version version 1.10

    3,734 downloads

    UVM-ML Open Architecture - version 1.10 Enabling Multi-Language and Multi-Framework Verification July, 2018 General Overview Universal Verification Methodology Multi-Language (UVM-ML) provides a modular solution for integrating verification components written in different languages into a unified and coordinated verification environment. It consists of an open source library that enables such integrations, and can be extended to support additional languages and methodologies. This release of the UVM-ML implementation is the result of collaboration work between Advance Micro Devices, Inc., and Cadence Design Systems, Inc. It expands on the mature technology provided by Cadence in Incisive and in previous UVM-ML postings on UVMWorld. It is provided as open source under the Apache 2.0 license. This distribution includes the following main elements Backplane implementation and API Example frameworks and adapters (three provided: UVM-SV, UVM-e, and UVM-SC) Several demos and high level examples (showing all frameworks interacting) and a few smaller feature examples (tests) Docs directory with a Reference manual, User Guide and reference HTML docs Information on all news and features can be found in the ml/docs/ directory. This UVM-ML package is intended to serve as a basis for the verification community to collaboratively expand and evolve the multi-language verification methodology. Please read the “Status, Use, and Disclaimers” section below for full details. Where to Find Information Where to start reading: point your web browser to ml/README.html The landing page provides links to installation directions, release notes, user guide, and more. For feedback or questions: send email to support_uvm_ml@cadence.com An easy installation and Setup video guide is available You can checkout the update of David I. Long form Doulos at DVCon 2016 in the US. It relates to UVM-ML (along with other updates). Blog series: Multi-Language Verification Environment—Getting First Run in Few Minutes Multi-Language Verification Environment (#2) – Passing Items on TLM Ports, Using UVM ML Multi-Language Verification Environment (#3) – Connecting UVM Scoreboard to a Multi-Language Environment Multi-Language Verification Environment (#4)—Multi-Language Hierarchy Debugging Multi-Language Verification Environments UVM-ML- Managers’ Freedom of Choice Platforms and Simulators This release of UVM-ML should run on any simulator supporting one or more of the standard languages: IEEE 1800 (SystemVerilog), IEEE 1647 (e), and IEEE 1666 (SystemC). It was tested on the Linux operating system with various combinations of simulators and languages. ------------------------------------------------------------------------------------------------------- UVM-ML Open Architecture: Status, Use, and Disclaimers This section provides guidance and status regarding the use of the UVM Multi Language Open Architecture solution. The UVM-ML Open Architecture package is an open source solution, developed jointly by AMD and Cadence. We welcome feedback including suggestions for improvements. For any feedback or questions, please contact support_uvm_ml@cadence.com Use and Disclaimers: Licensing: This package is an open source library, protected under the Apache license (see legal clause at the bottom). Access: This package is available as early access to the verification community, and therefore changes to its content and behavior should be expected. Backward compatibility cannot be guaranteed. Changes are expected to take place when the verification community jointly refines the solution, to fit user requirements. We will aim, however, to provide help in adjusting to changes. Quality: this package is still under development. It is being tested and regressed with all active versions of Incisive and with the Accellera OSCI simulator before being released. The user needs to be aware of the simulator version on which the solution is tested. AMD tested the open source solution on other commercial simulators. Issues reported to AMD and Cadence will be addressed. Standardization: This package is not a standard. However, it is available as open source to all potential users. Support: Since this is not a product, it does not have a committed level of product support. We will provide help via the UVMWorld community on Accellera where the source code is posted. For Cadence customers, Cadence will provide direct support as needed. Note: the model described above is similar to how the very successful OVM and UVM-1.0ea (early version) were provided in the beginning. We believe you can gain significant value from access to this solution, and also be able to participate in developing it to ensure it addresses your needs. ------------------------------------------------------------------------------------------------------- What's new in each version For the full listing and more details please see the release-notes.txt file at the top of the release package. Please note that the items in red might require some changes on the user's side while upgrading to this version, please read these items carefully in the release notes. 1.10: Fully qualified with IES version 15.2 and Xcelium 17.04-18.03. ASI (OSCI) 2.3.2 is supported. Support for OSCI 2.2 was dropped. Open source version can be accessed by pre-processor macros (SystemC only: UVM_ML_CURRENT_NUMERIC_VERSION and UVM_ML_NUMERIC_VERSION) or by a method (get_numeric_version) Enhancements and fixes in event propagation between frameworks Improved error handling Other fixes 1.9: Fully qualified with IES version 15.2 and Xcelium 17.04-17.10. In order to make it work with Xcelium 18.03, you can just comment the patch header in ml/adapters/uvm_e/sn_uvm_ml.e. Runtime phase synchronization between UVM-e to UVM-SV is now supported in UVM-ML OA (only with Xcelium 17.10). System C TLM2 convenience sockets (including passthrough_initiator/target_socket) are now supported by UVM-ML OA. 1.8 Fully qualified with IES version 15.2 and Xcelium 16.11-17.04. New debug command for tracing serialization in SV and e : uvm_ml trace_ser Moving from one Xcelium agile version to the other requires reinstallation of UVM-ML (running install_xclm.csh again) against the respective version) and no additional manual steps are needed 1.7: Fully qualified with IES version 15.2 and Xcelium 16.11-17.02. New debug command for observing matching types was added: "uvm_ml print_type_match". Support for multiple ML connections for SystemC TLM2 sockets. 1.6: Fully qualified with IES versions 14.2,15.1 and 15.2. UVM-SV 1.2 is now fully supported (please read RELEASE_NOTES.txt under ml directory for more details). When working with Incisive 15.2, the user can take some steps in order to skip compiling the e part of the adapter (this might be important for users that compile other e code on top of Specman, like VIP). The steps are documented in the UVM-ML OA user guide under: "Linking the Specman UVM-e Adapter From Incisive Version 15.2 On". OSCI 2.3.1 is now supported instead of OSCI 2.3, meaning that the supported OSCI versions are: 2.3.1 and 2.2. gcc 4.8.3 is now supported 1.5.1: Fully qualified with IES versions 14.1,14.2 and 15.1. Early adopters UVM-SV 1.2 support for IES (please read RELEASE_NOTES.txt under ml directory for more details). UVM-ML tcl commands are now available from Specman with all supported simulators. UVM-ML tcl commands are renamed (they all start with uvm_ml prefix, followed by a space and the command name, e.g uvm_ml print_tree). The old names are still supported. Pre-compiled UVM-SC parts for IES were eliminated. Examples are enhanced and extended. Updated the Backplane API version number. New debug commands in IES to print the UVM-ML tree, port connections, and port registrations. Brand-new documentation including User Guide, Reference Manual and more. Support for IES reset in UVM-ML environment. Support for sharing uvm_events and uvm_barriers between UVM-SV and UVM-SC. Support for +UVM_TESTNAME in all simulators and languages. Passing tlm_generic_payload transactions via analysis ports. Several ASI SystemC enhancements: Automated synchronization, ML-registering of SC TLM2 sockets. Reorganized examples to make them more useful. Enhanced and simplified installation and setup. 1.5: Fully qualified with IES versions 13.2, 14.1, and 14.2. "Phase Debug" feature, for setting breakpoints at the beginning or end of UVM-ML phases (see the Integrator User Guide for details). Currently this works only for IES. Added support for the generic UVM SV syntax, uvm_config_db#(T), so that it now works also for ML configuration Improved the way to run the demo examples and to learn how to run UVM-ML Reduced the amount of ML enabling modifications introduced into the local version of UVM-SV (1.1d), by enhancing the UVM-SV adapter implementation 1.4.4: The e macro uvm_ml_stub_unit now directly sets unit attributes hdl_path() and agent(), thus saving the user a need to add auxiliary string fields Improved the handling of UVM-ML bitness (once users select 32 or 64 bit mode, the library and all examples will run in that mode) Enhanced sequence layering capabilities Enhanced the test_env.csh script to provide more validity testing of the user's environment and to provide better suggestions how to fix issues irun_uvm_ml.*.f option files were reorganized (including a name change): IES irun invocation options were grouped into several option files, reflecting the usage context, and adding comments to clarify their meaning This release might require some changes on the user's code while upgrading to this version, see details in the release_notes.txt” 1.4.2: Fully qualified with IES version 14.1 Enables usage of Cadence UVM extensions on top of UVM-ML OA Support for UVM ML configuration tracing on the SV side, activated by the +UVM_CONFIG_DB_TRACE command-line option Added new backplane API functions enabling the time notification (wakeup) service and updated the backplane API version number Updated the sequence layering examples. The code is simplified and type conversion using mltypemap is demonstrated Eliminated the UVM SV warnings Mechanism to recognize whether OSCI was compiled with pthreads and compile the custom sc_simcontext.cpp accordingly 1.4.1: New examples showing basic TLM communication Default installation is 32bit instead of 64bit Setup and install scripts renamed UVM-SC has been updated with a standalone phase controller that can run through the common and UVM phases. In addition user defined schedules, which can be synchronized with the standard UVM phases, are supported as well. Enhanced UVM-SC to support run_test() in the SC-standalone mode (not collaborating with other frameworks) Methodology and examples for sequence layering across languages Enhancements in how unified hierarchy works 1.4: Support for uvm-1.1d (in place of uvm-1.1c) Addition of a portable UVM-SC adapter. Simulator independent and tested to run on several simulators Architected to be highly modular and extensible A new architecture providing a Backplane that connects Frameworks (where Frameworks can be of different languages or methodologies) Three examples of language frameworks are provided: UVM-SV, UVM-e, UVM-SC Enables creating a unified hierarchy of components of different frameworks 1.2.2: Multi-Language configuration Support of TLM1 and TLM2 communication between all the provided frameworks Enhanced synchronization of test phases and delegation of phasing control to a designated framework
  2. Hi All, I am working in verification. Where i have to generate reg_block for all the IP's using IPXACT. also top level reg_block which instantiates all the IP level register block using IPXACT. But i am not interested in Ports/Businterface/component. Please advise me what is the best method to do it. Thanks Saravanan
  3. Hi , To whom may correspond I think there is some kind of error in the UVM 1.1d register model. I have been experimenting with the UVM register model and i have seen the following code in uvm_reg_map.svh task uvm_reg_map::do_bus_write (uvm_reg_item rw, uvm_sequencer_base sequencer, uvm_reg_adapter adapter); uvm_reg_addr_t addrs[$]; uvm_reg_map system_map = get_root_map(); int unsigned bus_width = get_n_bytes(); uvm_reg_byte_en_t byte_en = -1; uvm_reg_map_info map_info; int n_bits; int lsb; int skip; int unsigned curr_byte; int n_access_extra, n_access; int n_bits_init; Xget_bus_infoX(rw, map_info, n_bits_init, lsb, skip); addrs=map_info.addr; // if a memory, adjust addresses based on offset if (rw.element_kind == UVM_MEM) foreach (addrs[i]) addrs[i] = addrs[i] + map_info.mem_range.stride * rw.offset; foreach (rw.value[val_idx]) begin: foreach_value uvm_reg_data_t value = rw.value[val_idx]; /* calculate byte_enables */ if (rw.element_kind == UVM_FIELD) begin int temp_be; int idx; n_access_extra = lsb%(bus_width*8); n_access = n_access_extra + n_bits_init; temp_be = n_access_extra; value = value << n_access_extra; while(temp_be >= 8) begin byte_en[idx++] = 0; temp_be -= 8; end temp_be += n_bits_init; while(temp_be > 0) begin byte_en[idx++] = 1; temp_be -= 8; end byte_en &= (1<<idx)-1; for (int i=0; i<skip; i++) void'(addrs.pop_front()); while (addrs.size() > (n_bits_init/(bus_width*8) + 1)) void'(addrs.pop_back()); end curr_byte=0; n_bits= n_bits_init; The code continues but the interesting part is already there. Lets assume we have a register with 4 bytes and 1byte per address granularity (byte_addressing). Now, we do a FIELD access of 8bits length (the first byte of a register). The field is configured "individual_accessible, so UVM should only access that FIELD. The reg2bus should generate that byte request to be written. In other words, the vector "addrs" should have only one byte address. Going to the code, i see that initially the addrs has the 4 address ( the whole register) and when it comes to the "if (rw.element_kind == UVM_FIELD) begin" and it will pop_back()/remove all the exceeding bytes that doesn't need to complete "n_bits_init" of the field access. The problem is here: UVM has //while (addrs.size() > (n_bits_init/(bus_width*8) + 1)) and i think it should be while (addrs.size() > ((n_bits_init-1)/(bus_width*8) + 1)) //ejonalv possible error in UVM? check That is because in case we want to write 8 bits, it will calculate 8/8+1=2 address in the UVM version, but in fact it should require only 1 address. This is of course applicable for the READ variation. Did i misunderstand something? It is very hard to go through the register model without proper documentation in the code. I am looking forward your answer Best Regards Jonathan
  4. I am new to Synopsys VCS. I have been trying to simulate the testbench developed in UVM using VCS in command mode (Linux environment). But, I am not able to get the info displays and the output displays. I am have written the makefile using perl scritps. Can soemeone please tell me where I can find the detail example of using the options in my makefile to run it succesfully while viewing the output displays in command mode
  5. Saw the UVM-SystemC-1.0-beta1 download link, try to install it, but according to the INSTALL file, I can't find "configure" in the package. How could I install it?
  6. I can't find any example in the uvm-systemc preview package which DUT has clock and reset signals. I tried to create clock with sc_clock in sc_main and connected it my dut's clock signal. But it looks the simulation will never finish. So would someone let me know what's the right way to handle the clock and reset signals?
  7. Hello All, I am working on SystemC-UVM based testbench. I have created UVM based testbench using UVM code generator. Here I am using three different agents in UVM generator which I have defined as a part of the configuration file which was further being provided to UVM code generator to generate test bench skeleton. And here, in of the agent driver, the code snippet is as: // Drive the inputs of the DUT UVM_INFO(this->name(),"Driving transaction:",0); req.print(); // TODO put your code here But when I try to read the value in my test-case, then I see an error as: And this error is observed inside print() function, once I comment the line "req.print()" from the above snippet the error is no more observed and my test-case runs fine.
  8. Hi, The purpose of this discussion is to understand different possibilities by which the simulation performance, memory usage can be increased. Scoreboard as we understand needs the data/packets/frames etc to be stored/buffered to do a comparison with the actual data out. This works out fine when we have small sized array ranging from few bytes to few thousands of bytes.. However imagine, if we have 100 thousands of bytes and above and there is a need to store them and lets say multiple of such lanes/flows , then this would take a hit on the simulation performance. And this gets worse if we have to reuse and port it to a subsytem/chip level simulations.. With this as the background, i am looking at alternate approach for scoreboards.. In a way is possible avoid scoreboard and check the data as it comes without the need to store the expected/input data. Approach that can be thought of : 1. Generating incremental data pattern and check at the output .. (Comes again with issues like aliasing etc.. and hence need to have longer patterns.) 2. Generation of PRBS stream as the payload of the frame.. and then have a PRBS checker at the output.. and see it remains locked.. (Debug would get worse with this.. if there is a mismatch) 3. Having a byte scoreboard.. something like that.. (Not sure how feasible this is). There are many challenges even with these approach.. I am just wondering if someone has already experienced such cases and what kind of challenges are thrown out.. Appreciate any input on this. Regards, svuvmuser !
  9. This is a online training batch taught by experts working in Semiconductor Industry. Course starts with System Verilog and covers advanced level UVM. Course schedule is for 2.5 hours on Sat and Sun for 7 weeks. Graduates and working professionals can benefit from this training. Next batch starting on July 11th, 2015! For more details please email vlsitraining@artoflivinghet.org Course schedule is for 2.5 hours on Sat and Sun for 7 weeks. Graduates and working professionals can benefit from this training. For more details please email vlsitraining@artoflivinghet.org
  10. Hi why does phase.find_by_name(.name(uvm_main_phase::get().get_name()), .stay_in_scope(0)); from run_phase and uvm_pkg::uvm_phase run_phase = phase.find_by_name(.name(uvm_run_phase::get().get_name()), .stay_in_scope(0)); from main_phase return null. Is this intentional? I have created a sample example to check, or you can use the attached file as well. https://www.edaplayground.com/x/5Py7 test.svh
  11. Let's say I have the following DUT. The UVM environment contains a chain of models/predictors. Input data flows down this chain and generates the expected CHIP output, which is compared to actual. Pros: verifies top-level functionality. Cons: Does not verify block level functionality. A good start, but I'd like to also verify the blocks in a system setting. So, I create block-level environments, then reuse them at the top level. Awesome, but wait a minute. I still need the top-level verification (Input-to-Output) like in the first example. However, all 3 of my block predictors are being used in their corresponding environments' scoreboards, hooked up to the RTL, via agents. How does one do both? Surely I'm not supposed to instantiate duplicate copies of my block level predictors to create the end-to-end model chain...
  12. Hi, I have a doubt regarding an interface "X" being defined as : Driver code of the VIP: *********************************************** protected virtual X ChipIf; function void connect phase(uvm_phase phase); Y vif_container; super.connect_phase(phase); // Assigning virtual interface assert(uvm_config_object::get(this, "","V_IF_CHIP", temp)); $cast(vif_container, temp); ChipIf = vif_container.get_v_if(); endfunction : connect_phase ********************************************************** From the tb_top of the SoC , where the above VIP pkg is imported along with uvm pkg:*,please let me know how can I "set" the virtual ChipIf?
  13. The VCS implementation of uvm_reg_bit_bash_seq UVM register bit bash sequence performs a model.reset() in the sequence body, before starting the core do_block() task. Due to this reset, any configurations made to the DUT before starting the bit bash sequence is lost in the mirror model, while the DUT still has the configuration intact. This is causing failures during the bit-bash process, resulting in a test fail. There is no knob to override the reset functionality, nor can I extend the sequence and bypass the reset. Any thoughts on this? Any work around for this? ~Chethan
  14. I'm trying out the example for UVM-Connect 2.3 and I can't get a successful compile. The error message is about the "undefined reference to `m__uvm_report_dpi'. I'm using: GCC 4.5.2 on CentOS 5.11 VCS 2015.09-SP2-3 SystemC 2.3.1 SCV 2.0.0 UVM 1.2 UVMC 2.3.0 Appreciate all the help!
  15. Version 2014.02

    362 downloads

    Fixed few enum type-cast issues. Moved around the file ordering as needed by compilers. Added extra target for Riviera-Pro Fixed few issues in reg_models. Added Makefile targets for all 3 major EDA tools Steps to use ----------- tar xvfz uvm_ref_flow_2014.02.tgz cd run_dir make vcs make qsta make cdn make rvra
  16. The cook book from Mentor tells following and in another thread, the moderator also suggested against using the sub phases of run. However in one of my projects, I do find the need for using them (and infact we had an internal implemention of something similar in our previous OVM version). Are there any thing happening on this front? Is there a risk in using the sub phases if some of that changes in a future version? "The Accellera UVM committee is still developing the use models and APIs for new UVM phasing as it relates to sequences and transactors. In the mean time, our recommendation is to wait until that work is done and the API is stable. There are a number of future articles in this section which will be available here at that time, and which will describe our recommendations for using this technology. These include: How to make your testbench phase aware [Not yet available] How to manage sequences in the context of phasing [Not yet available] How to design reusable transactors that work in the context of phasing [Not yet available] "
  17. Hi, We are using snps ralgen to generate the regmodel. It appears that the ralgen creates only the default map. We would like to have 2 maps for 2 separated if masters. Is there an online example for such case? A post gen script can do one of the following 2 options: 1. add another instance of uvm_reg_map and copy/clone the ready map after finished build 2. add another instance of uvm_reg_map, and duplicate any map1.add_reg and map1.add_submap to map2 Which is preferable? Thanks! Elihai
  18. I see uvm_sequencer_base::wait_for_grant (UVM 1.1d) is a virtual task but accesses a local int g_request_id - is this not a bad coding style? If I were to override this virtual method for debug with much of the code intact tool throws an error for his local bar in a derived SQR class. I extended a SQR class and copied all the code for wait_for_grant and started tweaking - couldn't proceed with that debug due to this member being local. Should it be protected instead of local? Thanks Srini wwww.go2uvm.org
  19. Is it possible to do a uvm_config_db::set() for an object of derived class type using the base class handle and later do a uvm_config_db::get() of same object using the derived class handle Since a base class handle can be used to point to a derived class object and later typecase, I thought this would work, but doesn't seem to be so. Any help will be appreciated? Here is an example class BaseA ; endclass class DerivedA extends BaseA endclass 1) Set config_db DerivedA a1; a1 = DerivedA::create() uvm_config_db#(DerivedA)::set(this, "" , "myobj", a1); 2) Get config_db BaseA a1; DerivedA a2; uvm_config_db#(BaseA)::get(this, "" , "myobj", a1); $cast(a2, a1);
  20. I need to have two uvm_tlm_target_socket in a class and I need to do different set of things with the data received via two sockets. I was thinking if it is possible to have two implementation of b_transport task. I am aware of how we can have multiple analysis port imp and use uvm_analysis_imp_decl(_something) and we can have a "write_something" implementation. Is something similar available for uvm_tlm_target_socket? Regards, Gautam
  21. aynsley

    The Easier UVM Coding Guidelines

    Version 2016-06-24

    316 downloads

    This document is a printable version of the Easier UVM Coding Guidelines from Doulos. You are free to use these guidelines directly, to merge them into your own company-specific UVM coding guidelines, or merely to borrow some of the ideas. These coding guidelines are offered by Doulos for the benefit of the UVM community. They are not officially endorsed by Accellera.
  22. Hi, I notice something interesting in the build_phase order of uvm_component. The uvm_component at the same level are build in the alphabetatical order of the instance name. I expect the build order would be the same as the order I call the factory create function. I am wondering is the alphabetatical build order an intended feature of UVM or just some artifact of the implementation? I couldn't find any reference to this behavior in the UVM user guide or the class reference library. Thanks. Horace
  23. I'm trying to run uvm-systemc on macosx. Link to download: http://accellera.org/images/downloads/drafts-review/uvm-systemc-1.0-alpha1.tar.gz In the install flow, ../configure works fine, but on make i get this error: Making all in macros CCLD libmacros.laar: no archive members specifiedusage: ar -d [-TLsv] archive file ... ar -m [-TLsv] archive file ... ar -m [-abiTLsv] position archive file ... ar -p [-TLsv] archive [file ...] ar -q [-cTLsv] archive file ... ar -r [-cuTLsv] archive file ... ar -r [-abciuTLsv] position archive file ... ar -t [-TLsv] archive [file ...] ar -x [-ouTLsv] archive [file ...]make[4]: *** [libmacros.la] Error 1make[3]: *** [all-recursive] Error 1make[2]: *** [all-recursive] Error 1make[1]: *** [all] Error 2make: *** [all-recursive] Error 1 I've looked online, and it seems that it is a makefile problem. However the uvm-systemc makefile is way to complex for me to comprehend where the issue could reside. Any ideas on why is this happening? Thanks
  24. In case of UVM ,config_db can be accessed in any component or object which helps mainly the dynamic creation of component/models.Whether any option is present in SYSTEM C ?
  25. Hi, I have a doubt about requirement of raise/drop_objection. Why does a compiler need objections in run_phase? Why can it not just wait for time given like 100ns as following example? Ex. task run_phase(uvm_phase phase); //phase.raise_objection(this); #100ns; //phase.drop_objection(this); endtask
×