verifying protocol without reference model

[shane]

I am new to verification.

 

Now I trying to verify a protocol like TCP/IP  stack(mainly TCP over IP, without UDP, ICMP etc.). 

My first idea is that a golden Reference Model is needed. I generate sequences, send them to DUT through a driver, and monitoring my driver, get each transaction to RM, then I collect the response from both DUT and RM and compare them. But building  such a RM would be very complex.

 

My question is, do I really need a RM? What if I verify my DUT without any RM? 

 

For example, to verify DUT's feature of opening as client, my sequence can simply act as a server and do such routine:

 

1, send OPEN AS CLIENT command to DUT.

2, wait response from DUT, which should be a SYN. if not, assume test fail and exit. 

3, send SYN ACK to DUT.

4, wait response from DUT, which should be an ACK. if not or wrong ACK, assume test fail and exit.

5, end, assume test pass.

 

 

 

[tudor.timi]

The problem with putting your checking code in your sequence is that that if you want to create a new version of that sequence you might end up doubling your checking code as well. You could do it, but it might require tricky partitioning of code, which is extra effort. Another problem is that if you want to do vertical reuse of a block verification environment, you won't be starting those sequences anymore because traffic will be provided by another RTL block. If you had a reference model that just monitors the DUT inputs then it would work regardless of the source of those inputs (UVM TB or other RTL block). I've seen colleagues implement some checks in their sequences, but they were doing full chip verification, so no need to consider vertical reuse.

 

The sequence of commands you expect could be very easily implemented in a reference model. You should anyway have a monitor that can recognize when an OPEN AS CLIENT command is sent and informs the RM. After that it's just a matter of implementing the same sequence of operations you just described (wait for response, check that it's a SYN, etc.).