cloning before write()

[janick]

As I sit though the UVM Tutorial at DVCon, I have seen the following code presented two or three times already:

$cast(item_collected, tr.clone());
item_collected_port.write(item_collected);

It is a minor point that is not worth distracting from the topic of the presentation so I did not raise the point there, but you should not clone an object before sending it on an analysis port. The correct code is:

item_collected_port.write(tr);

Since the analysis port may not be connected to anything, always cloning before publishing will result in useless allocation and initialization of a new object instance that will be immediately garbage collected. And should none of the subscriber modify or hold the published object (as they should), the cloning was completely unnecessary and needlessly reduces run-time performance.

Further, cloning does not protect against the potential modification of the published object by one of the subscribers. It does protect the transaction instance in the publisher component, but if any subscriber modifies the cloned published instance, all of the other subscribers will be affected.

The proper semantics of using an analysis port is for subscribers not to modify the published objects and to complete their processing in zero-time.

function void write(the_transaction item_collected);
  if (!item_collected.compare(pending_transaction[0])) ...
  pending_transaction.pop_front();
endfunction

If a subscriber needs to hold a reference to the published object (e.g. to insert it in a queue inside a scoreboard) for some time or make modifications to the object, then and only then do they clone it.

function void write(the_transaction item_collected);
  the_transaction cpy;
  $cast(cpy, item_collected.clone());
  pending_transactions.push_back(cpy);
endfunction

Edited February 27, 2012 by janick

[mea1201]

Can the committee consider redefining the write prototype with a const argument, to enforce the semantic of subscribers that should never modify the published objects? Overall, this all makes perfect sense to me.

[uwes]

hi,

im not sure if the "const" is protecting you from modifying the object. the LRM says

---

An instance of a class (an object handle) can also be declared with the const keyword.

const class_name object = new(5,3);

In other words, the object acts like a variable that cannot be written. The arguments to the new method shall

be constant expressions (see 11.2.1). The members of the object can be written (except for those members

that are declared const).

-----

/uwe

[mea1201]

So, const would make the reference constant, but the object's members are still mutable within write. Oh well.

hi,

im not sure if the "const" is protecting you from modifying the object. the LRM says

---

An instance of a class (an object handle) can also be declared with the const keyword.

const class_name object = new(5,3);

In other words, the object acts like a variable that cannot be written. The arguments to the new method shall

be constant expressions (see 11.2.1). The members of the object can be written (except for those members

that are declared const).

-----

/uwe

[nndad]

Okay then in this case what does it mean when it says you cannot write to the object but the class members can be written to if not declared as const??

[janick]

It should really say "In other words, the object handle acts like a variable that cannot be written". You can change what a const handle refers to, not the handle itself.