What is the standard methodology of verifying HW when there are cases where RTL and Goldenmodel might produce different but correct output?

UVM
, , , ,
1

I’ve a UVM test bench (constrained random verification) for my hardware model. My golden model is written in systemC and c++. I have cases where my hardware result won’t match with software result but both of them can be potentially correct.

As an example, my HW does some memory management (allocating, deallocating resources) and this effects some other logic in the pipeline. Depending on “when” the HW gets an alloc or dealloc request and some time sensitive arbitration policy, it produces some outputs. In golden model there is no notion of time and in some cases it’s output won’t match with HW but both HW and golden model can be potentially correct.

What is the standard way to verifying this kind of scenarios? When both golden model and HW outputs are correct but they differ in value, I am not quite sure if score boarding might help to check correctness. I’m new to this field. So, any advice/pointers will be highly appreciated.

2

Well , all this depends on the packet granularity that your golden reference model(SystemC) works on.

  • Higher the granularity → higher the probability of mismatch → Higher simulation speed
  • Lower the granularity → result may closer to match → Simulation speed goes down{increasing the sampling events}

So, here decision is made on the basis of choice.

As let me discuss a case,

  1. a protocol implementing the data transfer on data bus running at clock1.
  2. another bus program bus running at clock2.

Now if data transfer on going , on the same time program bus access the status registers, hardware always gives different output from untimed model SystemC.

So here some ways are:
a. Tune the sequences as per the requirement , i.e, on model and hardware sync boundaries.
b. Build a wrapper on the top of SystemC Module and mimic the behavior of time {need not to model time just put the timing in terms of mathematical equations} and process the same.

Both the above will pollute.

But anyways , a friend of mine gives me suggestion to create cycle accurate model , as the rtl integrated env is already slow , so cycle accurate need not be exploiting the speed of simulation issue which is already slow.

Fortunately ,Ruchir Bharti STMicroelectronics**, may soon be publishing a paper on this. All the above suggestion are derived from his discussion. I would try posting the paper soon after the NASUG conference** {when published}.

Cheers,
Karandeep