4

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.

newbie
  • 4,639
  • 10
  • 32
  • 45

2 Answers2

3

One of the goals of the UVM is to raise the level of test abstraction beyond the hardware pin-wiggle level. If you have the knowledge that for a given random stimulus, the output is correct, you need to put that knowledge into the scoreboard. Your monitor's job is to produce a transaction removing much of the time domain information, and sending it to the scoreboard for processing.

Take the simple case of an out-of-order scoreboard where you send packets into a DUT for routing, but they come out in a different order. Your reference model may produce different ordering, but all packets that went in must eventually come out after certain period of time. You scoreboard must check that the packets were received without checking the ordering, or it much check an ordering imposed by the requirements of the design.

dave_59
  • 39,096
  • 3
  • 24
  • 63
1

I like Dave's answers, but in cases where the correctness logic is too complex to put in the testbench, I have seen a different approach used as well.

  • Abstract all the non-determinism into a single 'decision' interface.
  • Capture the decisions taken by the HW, and feed that as input to the systemC model.
  • Have the systemC model check that the decision taken by the HW is legal, and then make the model take the same decision as well. i.e. the systemC model follows the HW.
  • Cross-check the rest of the interfaces as usual.

While this is not a perfect checker, by defining the interface, you are making explicit what is the allowed non-determinism in the system.

sgauria
  • 458
  • 2
  • 7