Jump to content

karandeep963

Members
  • Content Count

    98
  • Joined

  • Last visited

  • Days Won

    5

karandeep963 last won the day on May 21 2016

karandeep963 had the most liked content!

About karandeep963

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    New Delhi

Recent Profile Visitors

1,041 profile views
  1. Great many thanks Tudor , I overlooked it . Also can you please also provide your expertise feedback on : Question 2: when we execute `uvm_do_on(eseq_inst[va],...) , so it creates an object and registers with factory. Does for every iteration it registers with factory the same name eseq_inst[va] instead of value eseq_inst[0]/eseq_inst[1]/eseq_inst[3]. as per UVM library : `uvm_do_on_with implicity calls `uvm_create which further calls create_item() as : { \ uvm_object_wrapper w_; \ w_ = SEQ_OR_ITEM.get_type(); \ $cast(SEQ_OR_ITEM , create_i
  2. class my_virtual_sequence extends uvm_sequence; `uvm_sequence_utils(my_virtual sequence,my_v_sequencer) exec_sequence eseq_inst[100]; ... virtual task body(); for(int i = 0 ; i <100 ; i++)begin fork automatic int var = i; // this is not allowed , getting compilation error `uvm_do_on(eseq_inst[var], p_sequencer.master_sequencer[var]) join_none end ..... some other piece of code ..... endtask: body endclass: my_virtual_sequence Hi , As per the above code, I wanted to parallely fire 100 transactions on 100 different masters_sequncers.
  3. Hi Folks, Interestingly today making some tweaks I faced a scenario with overrides. Suppose I add some variables in the extended class which are not present in the base class. Then I called the uvm_set_type_override from my top test. Interestingly I wanted to access those newly added variables in final_phase of some component , but during the simulator compile/elaboration phase it fails since the overrides are active during Simulation run-UVM_BUILD_PHASE. So my question is , if someone using some legacy code and wanted to update the stuff without re-writing again/or m
  4. Hi , I have a case in which my DUT only toggles the valid bits of data output and doesn't change the rest of the bits. At the receiever side its state machine decides what all are the valid bits. DUT is purely based on couple of state machines. I have a C model for the same which does not have that state machines though it every time toggless all the data fields. For an example , lets say DUT transmits 0101 at N cycles and has to transmit only 0x04 at N+1th cycle so it again transmits 0101. since the LSB is not valid in this case. In case of model , it tr
  5. One other way could be: Since binding of port can be possible with the components(which are supposed to be hierarchical members unlike sequence which associated during run-time). So you can create one port in your env and connect it to block_cfg_mngr import. Now in the sequence you might be already having the env pointer through config_db (if not set the port from env in the config_db) , get the pointer of env,port in your sequence and start accessing it. ///// Env Classs ///// class my_env extends uvm_env; uvm_tlm_b_initiator_socket #(uvm_tlm_gp) config_socket; fun
  6. I think UNIQUE KEYWORD does well , I have used it with Synopsys VCS, a quick example ::-> http://www.edaplayground.com/x/6AHE Not sure about cadence incisive, sometime back raised CCR for enhancement for this feature , not sure whether it is available. But yes, this unique keyword does much beautification to my code.
  7. It can be done in two ways: 1. Use reg callbacks pre_predict/post_predict to update the values. http://forums.accellera.org/topic/5107-uvm-register-implimentation-for-same-register-with-different-instances/ will be help you in a better way. Thanks to Tudor Timi for his kind help !! 2. The other way would be overload your predictor to do this stuff.
  8. As far as I understand Chip Select(CSbar) is active low in nature , so its the masters responsibility to control/enable/disable it while the slave has to respond to the command input. Slave must not drive CSbar. Slave must be active on CSbar low and process the input command and do the needful.
  9. Though its late to answer I guess, here is one solution: Create two packets in your monitor as follow; class any_monitor extends uvm_monitor; // rest things task run_phase (uvm_phase phase); my_packet previous_packet = my_packet::type_id::create("previous_packet"); my_packet current_packet = my_packet::type_id::create("current_packet "); // Processing the transaction // Do the needful and before sending the packet through monitor analysis port make a local copy for it as // since we send the packet through analysis port in the end where we are all done with our proce
  10. Let me try to understand the problem before proposing any solution. You wanted to access the 32bit and 64bit data-width registers via program bus whose datawidth 64 bits. In hardware we mimic such scenarios using byte_enable that decides the valid bytes in data_width and registers those are only 32bits valid fields implemented marked the rest with reserved bits. Same is done in the RAL as well , we only implement the valid fields for the register while non-implemented space treated as reserved. So while accessing the registers the respective values are updated. Let me take anot
  11. Agreed !! But the problem is that there isn't any post_predict(...) hook defined for uvm_reg, do need to make n number of callbacks for n/4 registers. Scarifying the vertical reuse for sake of using single callback for n registers. Indeed at deep of my heart I was feeling it not a good way, Thanks for pointing. Now I will for sure try to find some other way out. Implementing this behavior in predictor will help ??? I will try to check this implementing at predictor level. Thanks for your valuable feedback.
  12. Thanks Tudor for sharing your thoughts, it really helps. Posting here the implementation, might be helpful of someone someday (provided better ways would always be there ) --------------------// CALLBACK IMPLEMENTATION //--------------------------- class my_cb extends uvm_reg_cbs; `uvm_object_utils(my_cb) virtual task post_write( uvm_reg_item rw); uvm_reg my_reg; uvm_reg rg; int unsigned offset_addr; if (!$cast(my_reg ,(rw.element))) begin //TODO: remove this once able to use get_offset() api with rw.element `uvm_error("WRONG_TYPE","Provided casting failed")
  13. Thanks Tudor !! You exactly hit the right place. Indeed registered callback to reg only. I think what I wanted to acheive would have to be done in other way. I wanted to implement "SHARED VALUE" registers which are at different address space in same map. Lets say I have 0x0 REG 1 --> Type RW 0x4 REG 2 --> Type W1S 0x8 REG 3 --> Type W1T 0xC REG 4 --> Type W1C Now any change(write) to any register should be reflected(read) same in all the four. For this reason I planned to make a callback, register that with all the four reg, any writeaccess to an anyone will trigger the same c
×
×
  • Create New...