Automotive vehicles are not only fast moving, but also have various systems comprising a variety of advanced technologies. Increasing complexities of these systems need much more sophisticated components and interactions.
Amongst the various standards that target the automotive IP section, CAN holds a unique place. CAN (controller area network) is a communication protocol which uses a single, shared serial bus and supports distributed real time multiplexing for use within a variety of road/space applications.
Various nodes that connect on the bus can have different oscillator frequencies but all coordinate in a manner such that a network-wide time quantum and, eventually, bit time is achieved.
Designing of such a system is sophisticated, but the verification of a CAN node or CAN system brings many more challenges and complications.
This article explains the challenges in the verification of a CAN node and how CAN Questa® Verification IP combats those.
Fast moving vehicles have even faster moving technology and complex systems. Increased complexity of the system is due to sophisticated components and complicated interactions between them. In an automotive environment, where the IP is supposed to be fast as well as very precise, the need for perfect verification increases.
The more advanced version of automotive protocols is found in space and aeronautic applications where the precision needed increases by many folds.
The automotive industry protocols include Controller Area Network (CAN), Local Interconnect Network (LIN), Flexray, and others. All these have an in-built similarity in their architectures.
All have a serial bus, which is shared between various nodes, master/slaves, and, for the case of multiple transmitters at a particular time, arbitration mechanisms
We will keep the description and details limited to Controller Area Network (CAN) in this article.
Controller area network is a serial communication protocol which supports distributed real-time control and multiplexing for use within road vehicles and other control applications.
Before the advent of CAN, the designs of automotive IP were very complex (Figure 1):
Figure 1: Designs before CAN
As the technology of CAN came and started being used, these systems became much more simplified (Figure 2):
Figure 2: Designs after CAN
A CAN system typically consists of various nodes connected on a shared bus (typically bit-wise AND-ed) on which frames are transmitted. The frames can contain a maximum of 8 bytes of data. There can be multiple nodes transmitting their frames at the same time. In such a case, bit-wise arbitration resolves the conflict: the winning node continues transmission and the losing node stops transmitting and becomes a receiver of that message. The node that lost arbitration can retry the message at a later point.
The widespread usage of CAN resulted in a demand for more bandwidth at greater speed. In order to realize this, a new protocol, CAN-FD, was introduced which could carry a data payload of up to 64 bytes and support an option to carry the data at a higher speed.
Another important characteristic of a CAN system is the timing and re-synchronizations that enable a number of nodes with different oscillator frequencies to work together in a system with a shared bus.
The next section describes in detail the challenges associated with CAN system verification.
From the previous section, we saw that a CAN system simplifies the connections, design, and organization of the system manifolds, but the verification of CAN nodes still remains a challenging task.
There are multiple challenges involved in the verification of the CAN bus.
- The first basic requirement is to correctly follow the synchronizations and re-synchronizations happening on the bus so that the data sampled by a verification component is the actual value of data rather than being a false sample due to incorrect sampling. It is a major requirement to correctly achieve this synchronization as there may be multiple nodes with different oscillator frequencies.
- The correct verification of a CAN interface requires covering all interesting scenarios so as to check the functionality of the bus in each and every corner case. Missing any of these may leave a possible bug in the IP. The possibility of a potential failure presents a very big risk due to the presence of the IP in components that carry human lives (CAN is used in automotive space or military/aeronautics) or cost intensive projects (space requirements) where it is extensively used.
- A node may be error active or error passive. A node’s behavior on the bus is dependent on this. Hence, it is very important to verify that the node works fine in all the corner cases for both scenarios.
- Even if a particular node of a system is a passive error node, the other nodes of the system could still be in active mode. In such a case, the amalgam of the activity on the interface gives rise to an even greater number of interesting scenarios which are necessary to verify.
- Error handling, which is a very big factor in the verification of any IP, holds an even greater importance in CAN. There are various error conditions supported in CAN. A verification component must subject the CAN IP under verification with all such possible stimulus and at the same time create combinations of these erroneous situations with various bit fields and/or node situations.
- Because a node losing arbitration will become a receiver of the frame, it needs to be thoroughly verified for the continuous correct flow of information.
- The CAN specification allows different behaviors for the transmitter and receiver of a frame. This difference can be seen in valid bit values, inter frame gaps, error handling, and so on.
- When CAN-FD enabled nodes are verified, its combination with classical and CAN-FD tolerant nodes needs to be checked. A CAN-FD node must be able to correctly decode as well as generate both classical and FD frames.
Apart from the above major challenges, the other general challenges of set up of a re-usable verification environment, quick turn-around times, efficient utilization of the bus, and others still hold true.
Considering these and other challenges confronting the fast growing automotive industry, it is inevitable that a comprehensive and precise verification solution is needed.
This article goes through a solution provided by Questa® Verification IP (QVIP) that targets all the issues specified above so that a verification engineer is able to verify their design effectively.
The first and foremost requirement for a verification engineer is to set up a testbench that can verify their DUT. QVIP provides easy bring up components and APIs for this testbench.
When using a QVIP based solution, an inbuilt GUI is provided, which does all the connections and configuration settings for the testbench and also generates the testbench code along with scripts which can be used directly. One or multiple instances of QVIP can be instantiated directly and each of them individually configured through a simple GUI-based interactive system. Once the desired configurations and connections are done as needed, the testbench is generated. The generated testbench has two different flavors. One is a UVM framework based testbench and the other is a simple UVM based testbench.
The configurator hides behind the hood the full manual set up which would otherwise require writing code. The steps that would have been in that are described further.
As a first step, the wires of the DUT need to be connected to a verification component. Although this is a simple step here because the advent of CAN brought simplicity in connections for systems. The system is now composed of a single bidirectional wire which is bit wise AND-ed and shared by all nodes.
The DUT could also have an interface with separate unidirectional pins of transmission (TX) and receiving (RX). The presence of such an interface brings an ability of verifying the IP with a greater insight.
QVIP requires simple steps to do the connections. It provides separate connection modules that are categorized for bidirectional and unidirectional usage each.
When using a bidirectional interface, a single shared bus signal (which would be of a “wand” type) is passed to the instance of QVIP.
When a unidirectional interface is available in the DUT, the same can be additionally connected to the QVIP’s unidirectional monitor module instance. This monitor instance would contain a greater power to check the functionality of the DUT as it would have a greater insight on the actual value transmitted and received by the DUT.
In both cases, an active instance of the QVIP can be connected and configured to send the stimulus as per the need of verification.
Figure 3: Connecting multiple CAN unidirectional DUTs with QVIP
Once the connections are complete, the next step is to create a UVM testbench.
The QVIP provides easy to use, protocol specific agents for every protocol in its library. The protocol specific agents do the quick set up work with minimal effort from the side of a verification engineer (Figure 4).
Figure 4: Designs after CAN
Various static time functionalities are easily controlled via the agent itself. For example, in order to configure the QVIP to behave as an active agent, the setting of a simple switch is required. Here, a node can be configured as a CAN classical/CAN-FD/CAN-FD tolerant node.
Further examples are present in the QVIP library that explain all the use cases.
In addition to the above connection and configuration, which is elemental for all verification components alike, CAN verification needs some important information about the bit timings of the system. This is needed as it is elemental to the correct sampling of bits and, hence, eventually the functionality of the system. By providing these values, the user does not need to take care about the bit timing synchronizations any further. The biggest challenge in the verification of a CAN DUT is simply taken care by the QVIP automatically.
These are made as configurations in the CAN QVIP BFM, which can be easily specified as per the desired value and the set up of the testbench is now complete.
This three step process for the verification set up is made in a way that the simple parts of verification set up are quickly done.
Stimulus generation is the critical part of CAN DUT verification. QVIP takes a lead here by providing an extensive sequence library with a list of sequences that traverse the specification with even the minutest of details.
With this easily usable set of sequences in the sequence library, one of the most difficult parts of CAN node verification is now a cake-walk. A verification engineer simply picks the desired sequence, or runs all of them together. In this way, they achieve various scenarios and test the receiver side of their DUT.
The next level of interesting scenarios involves the verification of correct functionality of the DUT reacting to scenarios in which multiple nodes (even the DUT) are transmitting at the same time. Here again, QVIP does its part very cleanly. The generation of frames by QVIP can be precisely controlled as per the need of a user. Again the sequences provided in the sequence library can be utilized here.
For systems that are CAN–FD enabled, there is a separate set of sequences provided that exercise all flavors of the CAN-FD specification. The CAN classical sequences are also needed as a part of the complete verification of a CAN-FD node.
As repeatedly asserted before, error handling is a very critical part in the verification of a CAN node. The CAN QVIP comes with a list of sequences which generate all kinds of error scenarios that can easily subject the DUT to a variety of erroneous scenarios.
Verification engineers just need to pick the ones that they want and the error scenario gets generated.
This ready-made sequence library takes away the headache of writing the sequences for the verification engineer. The verification cycles can rather be spent in thinking of more and more ways of stress-testing the DUT and thinking of more complicated and interesting scenarios.
Once a user starts writing the test cases, the question arises: “When is it time to say that the verification is complete?” The coverage collector plays a critical role here. The QVIP coverage collector extensively targets all the features of the specifications. All kinds of frames, frame attributes, the control variety, interesting data values, and various other flexibilities shall be verified for correct functionality as per the protocol.
The coverpoints and crosses target the specification extensively and make sure that the design can be called completely verified if it achieves 100% coverage.
In order to perform the verification in a systematic manner, the QVIP also provides a verification plan in the form of an XML file along with the coverage example. This clearly maps individual sections of the respective protocol specifications.
Typically, when debugging some issues, an engineer may not want to keep coverage enabled. QVIP provides an opportunity to enable/disable coverage collection as required, using a simple switch.
The CAN specification describes a whole set of erroneous scenarios as well as the mechanisms to recover from them.
The first requirement of a verification component is that the interface activity is checked for protocol compliance and error messages are given in case of protocol violation.
CAN QVIP provides an elaborate list of protocol checking assertions with the following features:
- Error messages given alongside the assertion firing contain a detailed description about what part of the interface activity violated the specification. The error messages are tagged with proper references given for the specification section that defines the correct behavior.
- Ability to enable/disable individual/all assertions. Ideally speaking, none of the assertions should be disabled, but when specific negative scenarios are being targeted, it comes useful to disable the specific error checks.
- SystemVerilog Assertion (SVA) capabilities such as wave-level debug and assertion coverage.
- Transaction-level items which contain the erroneous part of the violation get highlighted when seen in the GUI. This makes the debug and analysis of assertions easier by many folds.
# ** Error: (vsim-60007) MVC @ 3202 ns: /top/node1/can_if rx_field: CAN_STUFF_ERR_DETECTED:21 - CAN node detected a stuff error. Refer ISO 11898-1 CAN specification, section 10.11
# ** Error: (vsim-60007) MVC @ 3202 ns: /top/node2/can_if rx_field: CAN_STUFF_ERR_DETECTED:21 - CAN node detected a stuff error. Refer ISO 11898-1 CAN specification, section 10.11
Figure 5: shows a sample error message from the QVIP
The checkers are a typical feature of all verification IP. What demarks the QVIP from others is the amount of debug options that come with the QVIP which makes the identification as well as the resolution of issues easier.
Checkers and their additional flexibilities given by the QVIP come really handy in CAN where this can be used to see that all type of erroneous scenarios get exercised and perform various kinds of detailed analysis of the failing cases.
There are multiple issues/challenges faced in the debugging of CAN interface issues:
- A single bit does not traverse the interface in one clock unit (time quantum). It takes multiple time quanta (TQ) to send one bit across the interface. The number of TQs increase/decrease slightly on the account of synchronizations/resynchronizations. Hence it becomes hard to keep track of the number of actual bits traversed if a verification engineer tries to debug just with the signals.
- With the large number of frames involved in a simulation, the frame boundaries need to be correctly identified, and this adds to the debug difficulty.
- An added flavor of complexity comes from the fact that a node may be transmitting but loses arbitration from some other currently running node. This needs to be correctly tracked as the behavior of many features change if a node was the transmitter of the previous frame.
The CAN QVIP deals with all these issues very gracefully. While debugging a CAN simulation, transaction-level items can be seen in the GUI that traverse one complete nominal or data bit (as the case may be). Also, the frame sequence items show complete boundaries of their time of existence on the interface. Another useful feature is a parent-child relationship between the frame items and the fields and thereafter the individual bits that constitute the frame.
QVIP maintains a complete track of the arbitration wins/losses (when a unidirectional interface is available), so that a verification engineer gets a deeper insight into the current happenings on the bus. This and various other status variables track numerous on-going activities with which a complete description of the interface activities can be extracted out.
As well, there is an option to enable debug messages denoting the completion of a frame on the interface. This can be enabled or disabled as required.
Figure 6: Debugging issues with waveform
With the simplification of designs in the automotive industry made possible by the advent of CAN, a greater onus is put on verification of these designs. Increased number of nodes, traffic requirements, and various other factors make the verification of a CAN system a challenging task.
Looking at all the above steps, it is needless to say that verifying a display component is a tough task. But as seen, Questa Verification IP provides easy to use, highly organized steps to make the verification experience an easy task.
- ISO 11898-1 second edition 2015-12-15
- BOSCH CAN specification Version 2.0
- BOSCH CAN with flexible data rate Specification Version 1.0
- UVM – Universal Verification Methodology Cookbook
Back to Top