Error injection capabilities of bus functional models

This blog will discuss what are the expected capabilities from the bus functional models (BFM) for the error injection support.

Before we jump into details of support required in the bus functional models, in the post “Error injection scenario enumeration thought process” we understood that the error injection is primarily modeling the manifestations of imperfections of physical line. Now one may question, why not just model it like that?  That is model a wire to do random corruptions of the data passing through it. Simple solution, why go add error injection capability in the bus functional models?

Answer may seem bit too obvious for veterans but for the benefit of newcomers bringing this point up. Good news is, yes you can. It will create the valid scenarios as well. But remember in the functional verification we want all the cases that real life usage can create but in the controlled environment. With the random data corruption if we want to specifically corrupt some field of a protocol data unit, it will become tedious to do so. Also it’s not just sufficient to corrupt we also need to check if it’s handled correctly by DUT.

This means, test will have to figure out when is this transaction going out by decoding data going out on the physical line, corrupt the right data and then pass the information about corruption to BFM, if its implementing any checks.  It’s not impossible but it will demand more effort and process is error prone. To overcome this, control is desired at higher level of abstraction. This means test should be able to indicate at higher level to corrupt a specific field of specific protocol data unit. This type of interface is critical to close the error injection functional verification. That’s reason it’s modeled in the bus functional models instead of the physical lines.

Now that we are clear why we need the error injection capabilities in the bus functional model let’s explore what should we expect from it?

Functional requirements for error injection:

Bus functional model should be able to meet the test case requirements identified following thought process outlined in the blog “Error injection scenario enumeration thought process”. It should support :

• BFM Transmit side error injection
• BFM Receive side error injection
• For multi layer protocol, should allow error injection in every layer
• Allow single and multiple error injection based on requirement
• Allow back-to-back error injection based on requirement
• Error response checking  for line side response should be built-in
• Allow simultaneous error injections in both directions

This blog will assume bus functional models implemented using object oriented programming interface. It’s assumed primarily due to ease of information abstraction. If the abstraction can be achieved through other mechanisms the concepts will still hold true.

BFM’s Error injection interface

Before we jump into the interface details, let’s understand what needs to be communicated to BFM’s for doing error injection.

Error injection requires specifying two types of information:

• Type of error injection  
  • Field or sequence error injection
• Selection of possible variations
  • For field corruption the corrupted value of the field to be used for corruption
  • For sequence corruption the protocol data unit replacements to be used for corrupting the sequence

Both of these information together is typically abstracted as error configuration.

Where should this error configuration information be specified?

In multi layer protocol every layer will have its protocol data unit. Each protocol data unit should support field and sequence corruptions. Typically this is protocol data unit is modeled using a class. This class will contain all the fields as the class properties.

There are two possibilities to specify the error configuration related to this protocol data unit:

1. Implement the error configuration in the same class as the protocol data unit

2. Implement the error configuration in a separate class

It’s recommended to choose the second approach of implementing the separate class for error configuration. For simpler protocols it may not make big difference but for the complex protocol it will yield good returns by it’s cleanliness of division.

How to program error configuration in BFM?

BFM should provide the APIs for programming this error configuration. As per the error configuration specification BFM should corrupt the selected protocol data unit.

This could be separate API or error configurations can be attached with the protocol data unit to be corrupted. In case of separate API it’s important to also specify the protocol data unit to be selected for the corruption.

How  do we control the selection of the protocol data unit to be corrupted?

There are two popular approaches possible:

1. BFM provides the protocol data unit through call back. Test attaches the error configuration to that specific protocol data unit and then BFM injects the specified error as per the error configuration
2. BFM provides simple API as to corrupt the next protocol data unit. To detect if the next protocol data unit is the transaction of interest BFM provides the events

If the second approach is used the test code flow will look linear. Whereas due to callback usages in the first approach the code flow will not look linear. Linear code are simple to understand and maintain.  Both the approaches will accomplish the objective.

In multi layer protocol it’s advisable to keep the error configuration for individual layers separate. This keeps the implementation clean and allows scope for incorporating the expansion of the protocol in future.

Directed vs Constrained random error injection

Error injection should allow exercising error injection in both of the following modes:

• Directed error injection
• Constrained random error injection

Directed error injection should allow creation of any error injection scenario. In order to be able to create very specific scenarios the test needs to understand what is happening inside the bus functional models. The state and various events about the internals of the BFM should be provided to the test through the events and callbacks. Through these events, callbacks or any other mechanism the test should be able to achieve the necessary synchronization and then exercise the error injection to create the specific scenario of interest. In this case test generate traffic and uses the error configuration to specify the error to be injected.

Constrained random error injection is kind of the hands free mode of the operations. In this case test would only generate the traffic and BFM would do constrained random error injection of enabled error injections. One of the effective control for error injection enabling in constrained random mode is through percentage specification.  BFM should allow the specification of percentages for either any specific error or category of errors.  This would allow user to mix different types of the errors with the different weights as per the requirement. Now it’s important to do the selected errors in constrained error injection. Typically the best to consider the innermost circle of the errors indicated in the “Definition of the sensible error handling verification plan” for constrained random error injection.

Debugging help

Error injection debugs can get really crazy. Logging is one of the key interfaces through which the BFM’s provide the debug information.

BFM should be able to clearly identify following through the logging interface:

• Whether the protocol data unit logged is corrupted or not
• If corrupted corrupted the details of the error configuration associated with the corruption
• In case of corruption it’s better to provide the information about the uncorrupted protocol data unit as well along with the corrupted protocol data unit. This eases the analysis in many debugs.

In the course of the error injection there is high probability that the DUT’s will misbehave. This would be caught by the checks implemented in the BFM. The checks should have meaningful message to guide the debug in right direction.

Flexibility in error response checking

Certain error injection scenarios can  result in multiple possible responses from the DUT. These possibilities could manifest as different response or missing response or additional protocol data units from DUT.

Error configuration should allow user to override the expected responses. By default it can implement most likely response but it should provide the flexibility to specify a different response for checking.

Also BFM should have capabilities to downgrade certain checks. This is not to be used as a  long term solution but for work around during the DUT development. In certain cases, it may be interesting to see how the DUT behaves further beyond a check failure for understanding the scenario better. Check downgrading will be useful in this case as well.