Jump to content

vishal.jain

Members
  • Posts

    13
  • Joined

  • Last visited

Posts posted by vishal.jain

  1. 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'.

  2. 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

  3. 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

  4. 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

  5. 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

×
×
  • Create New...