This blog will focus on the error injection scenario enumeration thought process for bi-directional communication interface designs. 

Simplest representation of the verification environment for bi-directional communication interface is shown below.

Although there are unidirectional interfaces as well but they pose lesser challenge in terms of the error injection verification. The reason being there is no hardware recovery mechanism possible with the unidirectional interfaces. So they are not covered in this post.

Error injection scenario enumeration process may seem very discrete. When there is no clear thought process identified, one may randomly start listing the scenarios. This makes it difficult to judge whether all the key scenarios have been thought through. This confusion can lead to either bloated or inadequate listing.

Bloated list is a risk to schedule and inadequate list is risk to functionality of chip. Worst is bloated list with irrrelevant cases.

So, what is thought process that leads to effective enumeration of error injection scenarios?

This blog will show it. It will showcase: What are some of major parameters to be taken into consideration? How to establish the overall scope of error injection verification to enable assessing and questioning the completeness of listing?

Following set theory based diagram is basis for building a three step process.

Step #1: Populate sets 

For bi-directional communication interface, there are two sets of key parameters. First is direction and second is transaction.

The direction set has two elements: transmit and receive. Both elements of directions are applicable for error injection.

The transaction error injection set has two elements: field error injection and sequence error injection.

For field error injection element, list all the fields of the transaction that can be corrupted. For sequence error injection, list all the protocol violations possible which lead to sequence error injection.

Step #2:  Transaction x Direction

First step is combination operations on two sets. First set containing direction and second set containing transactions. Here the word transaction means any generic protocol data units used by any layer.

All the combinations of these two sets should to be listed for unique error injection cases listing completeness.

Step#3: Additional variations

Once the unique error injection combinations are listed, each error injection case will have to be questioned with following questions

• Are multiple errors simultaneously possible with this error injection case?
• Are back-to-back errors  possible with this error injection case?
• Are simultaneous errors on both directions possible for this error injection case  ?

Any YES answer will add additional cases which are combinations of the errors cases listed in the step#2.

This completes the process of enumeration. Let’s look into details as to what do these questions mean in detail.

Single versus Multiple Errors

Question here is, whether transaction should be injected with the single error or multiple errors?

As discussed in the “Definition of the sensible error handling verification plan” decision is mainly driven by the specification requirements.

Certain specifications do provide provision for dealing with the multiple errors taking place at the same time in a given transaction. If the specification allows it,  then it must also define the priority in which the errors should be dealt with. In such cases it’s good idea to exercise the multiple errors taking place at the same time.

If it’s not defined, it should be considered as lower priority activity. Without the proper priority definition the receiver handling of the multiple errors can become ambiguous.

Back to back errors

Question here is, whether to allow the back-to-back errors?

In some of the protocols, after the first error is detected further error detection mechanism is disabled until the first step of the expected error recovery sequence is completed successfully.  In such cases the further errors injected back-to-back beyond first error are ignored. So it may not add much value to verification and unnecessarily it will increase the complexity of the error injection logic implementation in the BFM.

If the receiver remains active beyond first error and responds differently to back-to-back errors then it’s effective to allow the back-to-back error injection. Although care should be exercised to ensure the right scenarios are allowed minimizing the complexity of the error injection logic implementation.

Decision on multiple errors at the same time and back-to-back error injection has significant implications on the BFM error injection complexity. So it should be carefully thought out.

Implementation

Transaction corruptions scenarios have to be thought out from both transmit and receive side. Many times the receive side corruption results in DUT seeing same response. Such cases can be grouped and covered by the single test case in implementation.

If multiple errors at same time,  back-to-back errors and error injection simultaneously on both directions are allowed they should be implemented as  additional variations of test cases rather than writing a test for each.

After all the error scenarios are enumerated which would be quite a big list for sure, refer to “Definition of the sensible error handling verification plan” as to how to prioritize it for execution.

Please do comment if you would like to add to it.