Jump to content

vishal.jain

Members
  • Content count

    13
  • Joined

  • Last visited

About vishal.jain

  • Rank
    Junior Member
  • Birthday 03/06/1975
  1. Cadence UVM_RGM2.7.5 release

    Version

    1,703 downloads

    UVM_RGM2.7.5 is the UVM version of the Cadence Register and Memory package that has been tested by multiple users on all major commercial simulators. Bug Fixed: Fixed issue with backdoor read for special read fields Fixed issue with sync for special read fields Guarded exclude names with empty string match Fixed filtering by breaking immediately when condition matches Walking one built-in-seq did not create the regOp when writing. Mode based register enum field macro having wrong case statement Typo in DPI file (vhpiHandleT changed to vpiHandle) Check for address overlap for indirect / shared and mode-based corrected Modified the burst rd-wr testcase to have response Include / exclude addresses, get_config_object issue with reference handle pass Enhancements: Added support for mode based registers having separate storage Added stand-alone examples for mode-based registers Fixed the typo in sequence macro file when it error Shared register treated as RW register when filtering using condition Shared-indirect register not handled correctly by built-in-sequences Missing clone bit in get_config_object of address_range in sequence library
  2. Use set_addressing_width_in_bytes(2)
  3. http://www.uvmworld.org/contributions-details.php?id=125&keywords=Cadence_UVM_RGM2.7.2_release
  4. uvm_rgm_2.7 won't compile

    Hi Wavy, Are you sure you are using >UVM1.0 version and not UVM1.0ea? If you are passing -uvm option to irun, irun picks default UVM version which is 1.0ea. UVM_RGM would only work on released accelera UVM >= 1.0. -Vishal
  5. Cadence UVM_RGM2.6.1 release

    Version

    1,189 downloads

    UVM_RGM2.6.1 is the UVM version of the Cadence Register and Memory package that has been tested by multiple users on all major commercial simulators. Bug Fixed: Fixed issue with syncing to VHDL. Register overlap check error with end address Backdoor read of register fields was not properly masked Filtering of registers having unknown value is now only for rd_all regs seq Enhancements: Allowed backdoor write to read-only fields Allowed register's reset value over-ride using plusArgs Added register array delete at the end of built-in-seq Added support field-level backdoor access for shared register Modified shared_reg_backdoor example and added ipxact file Removed all uvm deprication warnings from examples Added support for VHDL backdoor std_ulogic_[ports |signals | vectorSignals] Modified all headers of XML files to get schema from http Added objection to built-in-sequences Added a global field to mask-out comparison of all non-read-write fields Added a global field to enable warning when accessed address is outside container
  6. Grab, Ungrab lock and unlock for sequences

    Grabbing a sequencer - If sequencer is doing some sequence and based on some external events if user wants sequencer to pause the current sequence, he/she can grab sequencer and start another sequence. Once the started sequence finishes sequencer can resume the normal operation, upon ungrab. This mechanism is generally used to mimic CPU behavior, where CPU is doing a normal bus operation and when interrup comes, CPU needs to suspend the normal operation and start interrupt handling. Once interrupt handling is over, CPU should resume the normal operation from where it was suspended. p_sequencer is a handle to parent sequence inside sequence. Since sequences are dynamic objects, they cannot be accessed hierarchically. If inside a sequence, one needs to access hierarchical paths (mostly parent sequencer), p_sequencer can be used. While p_sequencer returns a extended (typed) parent sequencer, m_sequencer returns base sequencer handle type. In short, if there is a 'field' in extended sequencer, sequence can access that field using 'p_sequencer.field'.
  7. uvm_set -config *axi_top.axi_system_env.master[0].sequencer.main_phase default_sequence axi_intermediate_master_sequence
  8. Hi, The main issue here is that there is no clear separation between driving and shadow. If predictor strictly works on 'mirrored' values then this problem will go away. This whole issue pops up because predictor uses 'desired' value for predicting which is dangerous. This has been raised to the Accelera committee. Lets see how it goes. Otherwise, your solution of keeping a separate copy is good. Only thing is it should not hurt performance. If there are large number of registers, you would begin to feel it. -Vishal
  9. Hi, One way to get around this is to create a base sequence where flow is defined in separate tasks. build calling pre_main -> main -> post_main tasks. Base sequence can add objections to pre_main and post_main. main is now left for users to implement. -Vishal
  10. Hi MEIXIAO, You should declare parameterized interface as below : interface ubus_if_parameter #(int DATAMSB=32); ... endinterface:ubus_if_parameter ubus_if_parameter #(.DATAMSB(64)) vif_para(); virtual interface ubus_if_parameter#(64) vif_para=vif_para; uvm_config_db#(virtual ubus_if_parameter#(64))::set(uvm_root::get(), "*", "vif_para", vif_para); -Vishal
  11. UVm Macro usage

    Hi Sankey, uvm_object class should be used to code normal transfer objects which are dynamic in nature. uvm_compponent class would be used to create your UVC hierarchy. All your quasi static objects like monitor / driver / sequencer / environment / test class etc should be extended from uvm_component class. That way you can use config mechanism to set/get component's filed values. Please refer to UBUS example inside UVM library to get a working example. -Vishal
  12. Packing from multiple classes

    Hi Frodus, One approach that I took in similar application was to flatten out all packets in singe class. Depending on class type (another field in class), I would do packing of required fields. Pros: Simplified code for coverage / automation / generation Cons : Debug might become a slight issue. Depending on protocols, flattening can results into the class being always huge -Vishal
  13. Hi Ranjisan, I guess update on 'register' will happen irrespective of mirrored value. What you described happens when user tries to do 'block' (register file) update. If registers desired value equals the expected value, that particular register would get dropped from update. -Vishal
×