The Verilab OCP uVC is a mixed language verification component for the Open Core Protocol (OCP) implemented using SystemVerilog and e verification languages. It can be used as an Open Verification Methodology (OVM) Verification Component (OVC) in SystemVerilog-only applications without the Specman layer (or license), or it can be used in Specman-based verification environments as a regular e Verification Component (eVC).

The datasheet for the OCP uVC can be downloaded here

The article uses the Verilab OCP uVC as an example. This uVC is a mixed-language OCP compliant verification component that supports a major subset of Open Core Protocol Specification 2.2. The OCP uVC is implemented using SystemVerilog and e verification languages and complies with both the Open Verification Methodology (OVM) and e Reuse Methodology (eRM). The verification component can be used in SystemVerilog only applications without the Specman layer (or license), or it can be used in Specman-based verification environments as a regular eVC.

The OCP-IP article can be downloaded here

The full whitepaper can be downloaded here

One particular statement in the Mentor paper caught my eye: "this model can still generate false errors: the waveforms show that input sequence A, B, C, D, E, F can result in output sequence A, B, E, E, E, where two consecutive inputs, C and D, are skipped". And this statement bothered me: I had spent a long time figuring out Mark’s model some while back, and while it was not at all intuitive to me, I did convince myself that it could never generate a simulated output sequence that was impossible in real hardware. So if the Mentor paper was correct, then I had missed something about Mark’s model, and I’ll be honest, I didn’t relish going back and studying it again.

Obviously I was just going to have to find a mistake in the Mentor paper instead. And to my considerable relief, I did. In fact, I found two:

1. The schematic (Fig 8, p.9) of Mark’s synchronizer model is missing a small but important feature.
2. The waveform (Fig 9, p.9) of data signal values input to the model is a somewhat misleading representation of an async input.

In the Mentor paper, the select inputs to both muxes are simply "$random()". In Mark’s original model (Fig 11, p.5), the select input of the input mux is indeed just "$random()", but the select input of the output mux is "@(m2 or m3) $random()".

The result of the modified select term is to make the "A,B,E,E,E" behavior impossible except under specific conditions. But under the right conditions, it is indeed a possible behavior in hardware.

The waveform of the d input signal in Fig 9 of the Mentor paper gives a false impression that d is actually synchronous, rather than asynchronous, to the sampling clock clk. The stability of a transitioning async input cannot be inferred forward or backward from the sampling clock. If two consecutive samples are not equal, it is unknown when the transition occurred - it is only known that a transition occurred. So if the sampled values B, C, D, E in simulation were 0, 1, 1, 0, it is entirely possible for hardware to exhibit the output sequence 0, 0, 0, 0.

The fact that samples C and D were both 1 in simulation does not mean that d was stable for two complete clk periods, as implied in Fig 9: The 0->1 transition B->C could have occurred momentarily before the C sampling clock edge, and the 1->0 transition D->E could have occurred momentarily after the D sampling clock edge. And if both transitions violated the sampling setup/hold window, then the metastability could settle to the B value at the C clock edge, and the E value at the D clock edge.

Consider the following:

class FooDataClass;
   integer D1;
   integer D2;
endclass

struct {
   integer D1;
   integer D2;
} FooDataStruct;

program test;
   FooDataClass  X[]  = new[5]; // array of classes
   FooDataClass  Y[];           // array of classes
   FooDataStruct A[]  = new[5]; // array of structs
   FooDataStruct B[];           // array of structs
   ...
   Y = X; // copy array of classes
   B = A; // copy array of structs
   ...
endprogram

In the case of the struct, it’s possible to copy the dynamic array A[] to B[], sizing B to the same as A automatically. It’s equivalent to:

B = new[A.size()];
foreach(A[i]) begin
   B[i].D1 = A[i].D1; // copy value of A[i].D1 to B[i].D1
   B[i].D2 = A[i].D2; // copy value of A[i].D2 to B[i].D2
end

Importantly, B[] has it’s very own copy of the values of variables D1 and D2 for each element in the array. So, if A[2].D1 was modified, B[2].D1 would not be.

In the case of the class, when we copy the dynamic array X[] to Y[], Y is still sized to the same as X automatically, but something subtly different happens (that often catches people out), with D1 and D2. When arrays of classes are copied, the references (aka handles) to the class are copied, not the values of the class members themselves. It’s equivalent to:

Y = new[X.size()];
foreach(X[i]) begin
   Y[i] = X[i]; // copy reference to class X[i] into Y[i]
end

This means that Y[] does not have its own copy of the values of variables D1 and D2 for each element in the array. If X[2].D1 was modified Y[2].D1 would also be modified. In fact they are the same variable, pointed to by the reference Y[2], which is equal to X[2]. That’s, most often times, not the desired behavior of the code. Coding errors like this can be tricky to track down and may stay hidden for some time.

Once you’ve created a class, people might start using it all over the place. People, who might not have access to modify your class code, only use it. This has an impact on the above mentioned difference between classes and structs. If you want to enable people to make copies of the data values, as opposed to just the references, then you (as the developer of the class), should provide a mechanism to “deep copy” the class. So with FooDataClass we might do:

function void FooDataClass::copy(FooDataClass c);
   this.D1 = c.D1;
   this.D2 = c.D2;
endfunction

Here we copy the values of another class of the same type into our class. It is now possible to make Y[] have its very own copy of the values of variables D1 and D2 for each element in the array. So, if X[2].D1 was modified, Y[2].D1 would not be. However, we still have to do something different for classes than we do for structs. Something like:

// copy of values of values in X[] to Y[]
foreach(X[i]) begin
   Y[i] = new;   // create new instance of the class
   Y[i].copy(X[i]); // copies *values* in class from X to Y
end

So, when you are reviewing code, it’s always prudent to look for places where classes or things containing classes are explicitly or implicitly copied.

Separately, John is compiling a list of DFT related links. If you’ve got some good ones to share head on over to his DFT Bookcase and or his DFT Forum and let him know!

I just got the stats for the fall 2007 meetings. 480 registered in total, 280 attended. Of the people surveyed (nearly everyone that attended the 5 meetings), 60% were using SystemVerilog today. Verification did pretty well out of that, with 67% of the share. Design got 10% and 23% said they used SystemVerilog for both design and verification. From a verification point of view another interesting stat was that 33% of the verification slice, were using the advanced testbench features of the language, and 32% were using SVA. It’s nice to see that more people are starting to use the HVL portion of the language for verification, not just writing assertions. I think this is due in no small to much better tool support and stability by all the vendors.

The growing attendance numbers of the SVUG meetings is a reflection of the interest and uptake of SystemVerilog by the design/verification community. I’m seeing an increase in our client projects using SystemVerilog Verification IP, and finding ways to hook SystemVerilog into their verification environments. Finally, it’s really beginning to feel like SystemVerilog is starting to make a bit of an impact.