Efficient Verification of CAN based System

Rajesh T & Pitchumani G, Wipro Technologies
Bangalore India


Abstract :

CAN is widely used in the transportation industry. Verification of RTL models gets challenging without use of automated techniques. We have attempted development of a verification environment using ‘e’ language with SpecmanElite®. This paper explains the underlying concepts for the same.

Introduction

In this approach, advanced verification tool like SpecmanElite® is utilized. The verification environment is referred to as ‘e’ Verification Component (eVC).

The development stage of CAN eVC involves development of driver, receiver, agent, checkers, scoreboard, coverage monitors. A configuration file is used to instantiate the specified quantity of CAN agents, which are utilized by the system. Additional items like jitter-adders can be easily hooked to provide errors while transmission.

The CAN packet structure needs to be incorporated first. This involves the identifying all the fields in the CAN protocol. Next, the driver which have sequence needs to be developed. These sequences drive the packet as per the CAN protocol using appropriate methods in the BFM.
The receivers have appropriate methods which collect the packets on the CAN bus. They inform of any errors which have to be utilized by the drivers to re-send them at appropriate time.

Checkers are of two kinds. They are Data and Protocol checkers. The Data Checkers generally incorporate scoreboard. The protocol checkers
incorporate certain temporal checks where the protocol is verified.

All the checkers (Data and Protocol) need to be enabled throughout the simulation cycle.

Methodology

The methodology involved the following steps

• Understanding of Protocol to be implemented
• Understanding eVC objects
• Mapping of protocol to eVC

CAN Protocol

Controller Area Network (CAN) is a common small area network solution that supports distributed product and distributed system architectures. The CAN bus is used to interconnect a network of electronic nodes or modules. CAN is the leading type of small area network for the following reasons:

• Low connect cost
• Lost cost components
• Growing number of CAN chips
• Increasing knowledge base and integration service base
• Wide variety of CAN-based products
• Wide variety of off-the shelf tools available

• Potential Lower wiring cost.

The CAN protocol standard message frame format is given in figure 1.

The CAN protocol supports two message frame formats. The difference is the length of the identifier. The CAN standard frame is known as CAN 2.0A supports 11 bits for the identifier. The CAN extended frame called CAN 2.0B supports 29 bits for the identifier.

A CAN base frame message begins with the start bit called "Start Of Frame (SOF)", this is followed by the "Arbitration field" which consist of the identifier and the "Remote Transmission Request (RTR)" bit used to distinguish between the data frame and the data request frame called remote frame. The following "Control field" contains the "IDentifier Extension (IDE)" bit to distinguish between the CAN base frame and the CAN extended frame, as well as the "Data Length Code (DLC)" used to indicate the number of following data bytes in the "Data field". If the message is used as a remote frame, the DLC contains the number of requested data bytes. The "Data field" that follows is able to hold up to 8 data byte. The integrity of the frame is guaranteed by the following "Cyclic Redundant Check (CRC)" sum. The "ACKnowledge (ACK) field" compromises the ACK slot and the ACK delimiter. The bit in the ACK slot is sent as a recessive bit and is overwritten as a dominant bit by those receivers, which have at this time received the data correctly. Correct messages are acknowledged by the receivers regardless of the result of the acceptance test. The end of the message is indicated by "End Of Frame (EOF)". The "Intermission Frame Space (IFS)" is the minimum number of bits separating consecutive messages. Unless another station starts transmitting, the bus remains idle after this.

The priority at which a message is transmitted compared to another less urgent message is specified by the identifier of each message. The priorities are laid down during system design in the form of corresponding binary values and cannot be changed dynamically. The identifier with the lowest binary number has the highest priority.

Bus access conflicts are resolved by bit-wise arbitration on the identifiers involved by each station observing the bus level bit for bit. This happens in accordance with the “wired and” mechanism. Here the dominant state overwrites the recessive state. The competition for bus allocation is lost by all those stations (nodes) with recessive transmission and dominant observation. All those “losers” automatically become receivers of the message with the highest priority and do not re-attempt transmission until the bus is available again.

This protocol does not use acknowledgement messages but instead signals any errors immediately as they occur. For error detection the CAN protocol implements three mechanisms at the message level:

CRC: The data is transmitted with a CRC and recomputed at receiver to check the data integrity.
Frame Check: This mechanism verifies the structure of the transmitted frame by checking the bit fields against the fixed format and the frame size. Errors detected by frame checks are designated “format errors”
ACK errors: Frames received are acknowledged by all receivers through positive acknowledgement. If no acknowledgement is received by the transmitter of the message an ACK error is indicated.

Verification components

The following are the major components in the verification environment

• Agent
• Checkers (Data and Protocol)
• Coverage
• Configuration

Agent

A typical Agent comprises of Driver, Receiver and Bus Functional Model (BFM).

In the Driver unit, sequences which can generate and send all possible transactions on the BUS as per the protocol need to be developed. The packet structure can be constrained by using appropriate constraints. Sequences are called appropriately in the test-cases to send all possible patterns on the bus.
In the Receiver unit, certain methods (tasks) are written which tap the bus and form the received packets. The sanity of the received packets is certified by the data checkers.
The Driver and the Receiver units interact through the Bus Functional Model which on one side will be talking to the Device under Test (DUT) BUS and on the other side with these drivers and receivers.

Checkers

Checkers are important in the Verification cycle are of two categories: Data Checkers and Protocol checkers.
The checkers generally use events. The events are the struct members indicating something occurs.
The Data checkers employ scoreboard techniques to verify the data integrity. From the driver the generated packet is updated to the scoreboard.
The estimated packet at the receiver is computed from the input packet in the scoreboard and the configurations of the DUT. By computing the estimated packet, we almost will be having a behavioral model of the protocol. Separate methods are written to extract the received data on the CAN BUS. The extracted received data is packed into a received packet. The estimated packet is deep compared with the received packet and the results are declared. At each transaction, the packets are compared and verified. This results in sorting and debugging the failures easily.
The protocol checkers typically check sanity of the protocols
The Data and Protocol checkers need to be enabled through out the verification cycle.

Coverage Matrix

Identifying all the grid-points of the protocol in the CAN based system is an important task.  The functional coverage points need to be captured in a systematic way as shown below. All these coverage points can be coded in “e”. There could be 4 different types of functional coverage.
Basic coverage: Deals with the fundamental items
Cross coverage: Crossing of all the valid basic items
Transition coverage: This deals with all possible transitions (either in transactions or state transitions)
Scenario coverage: This deals with all the possible scenarios which can be evaluated in the system.

Typical coverage grid matrix is shown below:


Configuration

Configuring involves specifying the number of can agents needed to test, number of normal can packets to be sent, when to enable the jitters etc., constraints of the packets while sending the packets etc.,

Architecture

The architecture is as given in figure 2. The multiple agents are controlled through an arbiter. The RTL was hooked to the eVC through its TX/RX ports.


Figure 2: Architecture

Testcase Development

Once all these fundamental verification components are done, testcases or test sequences have to be developed. The testcases need to be written generically where the individual items can be randomized. By running these testcases in different random seeds, the coverage increases. At each stage the functional coverage report is analyzed. Directed tests have to written to cover the missing holes.

Implementation

Develop standalone without simulator linkup

• Define the Packet structure
• Develop the Driver and receiver units with methods
• Develop the Scoreboard (data checkers)
• Develop the Protocol temporal checkers
• Develop configuration file (define.e)
• Write Testcases/Test sequences
• Compute Coverage and analyze

Advantages over traditional flow

• Using the eVC technique, the verification cycle is methodical and this eVC can be reused across any CAN based Device.
• The Coverage technique helps us in catching all the possible issues/scenarios/ cases in the CAN based system.
• By proper configuring, easily multi user CAN system environment can be built.
• This verification environment is more automated by the use of checkers.
• The randomization is very convenient using specman, which will enable to catch as many issues/bugs and get the coverage up in short time.

Conclusion

Using a traditional approach the verification is tedious and error prone. With the approach that we have explained the verification is more automated and leads to isolation of more bugs in the design.

Acknowledgement

We would like to acknowledge the efforts of our colleagues at VSBU, Wipro Technologies. We appreciate Shaji KK for his technical review.

References

1. “Writing Testbenches” – Functional Verification of HDL models by Janick Bergeron

2. “Design Verification with e” by Samir Palnitkar

3. Verification Vault: https://verificationvault.com

4. CAN in Automation portal. http://www.can-cia.de/