Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Erling last won the day on July 18 2015

Erling had the most liked content!

About Erling

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Is this a bug or does the LRM state that an initializer for a static member is not in the scope of the member's class? Erling
  2. Is this really correct? The expression c=a+1 refers to a, and the rule is then that a must have been declared already. The initializer for a is part of the declaration of a, thus the value is known already to be 3 at point of declaration of c, and the initializer for c should therefore be 4. What do you mean the value could be 1? One should think that one reason for merging initialization with the declaration was to avoid this confusion. In C++ for example, where the two steps are separated, the initializers can be listed in an order that isn't the actual initialization order (which is the d
  3. The slave monitor having a uvm_blocking_peek_imp means it is implementing a peek member task for someone else to call through a uvm_blocking_peek_port, which in this case sits in the sequencer. A sequence can then call peek() on the sequencer port, i.e p_sequencer.addr_ph_port.peek(). The peek call will be forwarded to the peek task of the monitor since the slave agent has connected the peek port of the sequencer to the monitor peek imp. At that point, peek() of the monitor will pend on the address_phase_grabbed event and return trans_collected to the sequence in the trans output parameter whe
  4. >But suppose i need the status of a particluar signal to cal a sequence inside a virtual sequencer, is there a way other than peek/poke the interface signals. Yes, the interface signals can be abstracted away. The status needed can be given a name, and providing that named status can be put as a requirement on the top level environment, i.e. simply assert that a testbench for my_dut shall provide status this and status that. When the test, in turn, is implemented by means of the testbench, it can just ask the testbench for status between sequences as needed, without direct reference to int
  5. >If it does, then how create an instance of the semaphore via new()? Could you give the example codes? Just declare the semaphore with an initializer in the interface, for example: interface fifo_if ... semaphore lock = new(1); endinterface >The situation is like this, a_item is used to config the duv, b_item and c_item >are different types of packet, such as b_item is a "nap" packet, c_item is a >"dma" packet. but a_item, b_item and c_item all need to transfer to duv via the >same interface, which is fifo interface or pcie packet interface. Is it >difficult for uvm
  6. >Maybe I can do like this: Individual semaphores on the items isn't going to help. If you want to serialize access to the interface, have a single semaphore in the interface for this purpose. >But I have one question about this, will the uvm report compile error or >runtime error while assigning data to the same interface's data in the write() >task in different drivers in uvm??? The last written data will be driven. >...how will the driver be blocked when it cann't get the semaphore while another driver is doing write task? Unless the drivers have idle work to do, they cou
  7. If the driver is parameterized on my_item, it can also accept any transaction extended from my_item. A sequence producing my_item's could be configured to produce some other item extended from my_item (by means of instance overrides for example). The driver would then have to downcast to determine the actual item type. Erling
  8. You could have a_item, b_item, etc extend from my_item, and transfer them as my_item through the agent, with the driver downcasting my_item to reveal the actual request. If the transactions aren't related in any way, it would seem better, as you point out, to have separate agents for them. Not sure what you mean by "how does it arbitrates the drivers". If the drivers are going to work with the same interface, but can't do that concurrently for some reason, a semaphore in the interface could be used to enforce serialization. Erling
  9. Yes, I'd hoped there were more than a lonely num I have many settings too, but they need not be visible in all sequences. If all knobs need to be visible everywhere, I'd suspect there is something unfortunate going on that isn't related to knobs. Also, if sequences indeed need access to many external settings, then it is always possible to aggregate and get hold of them in one operation. If you're concerned about performance, I'd recommend to fix the problem at one place, instead of distributing caches with direct access. Erling
  10. Not necessarily. Starting sequences could be delegated, without reference to sequencers. What often has to be dealt with, though, is the little things in between sequences, necessary to orchestrate operations, but it is not obvious to me that the sequencer should be involved in this (either). Another option could be to implement virtual sequences by means of the environment, and leave the sequencers an implementation detail. For example, if a piece of information is needed, and all the sequence has to talk to is the sequencer, then it is necessary for the environment to cache the information o
  11. It seems to me this would be reinventing global variables. I believe it is better to encapsulate related properties in components and sequences and strive to make them standalone and decoupled. If you need additional behavior later on, it may be better to extend instead of if-else-ing the original class on global knobs. Yes, but there are other solutions to this problem. For example, the good little monitor could handle interrupts as events, and transfer any additional info, if necessary, through the event. A sequence could fetch the event of interest from a pool setup by the environmen
  12. If num in your sample code is meant to be configurable, why not get hold of it explicitly at point of usage? This can be reduced to a one-liner with support from a common base class for sequences. The sub-sequence could go like this for example: class MySubSeq ...; rand int num; function void pre_randomize(); if (IsConfigInt("N", num)) num.rand_mode(0); endfunction endclass The inherited IsConfigInt() could first check the command line for +N=value, and if not found, try read an int resource named "N" in scope of the sequence. If a value was found in this way, randomization of
  13. Why is it you want to have the config settings on the sequencer? What problem does this solve? Erling
  14. I recommand putting your own uvm survival kit in a package and document it. In this case you could have a common base for all sequences, and that base can override get_full_name() to return whatever dot-separted list of strings that makes sense for you. Erling
  • Create New...