e Verification Environment for FlexRay Advanced Automotive Networks

By Stefan Schmechtig, IPextreme Inc.
Joern Ungermann, NXP Semiconductors
Christian Lipsky, IPextreme Inc.
Munich, Germany

Abstract:

FlexRay is the vehicle networking standard being backed by all major automotive manufacturers because it is fast and flexible while being reliable and deterministic. NXP (formerly Philips) Semiconductor is a founding member of the FlexRay Consortium and has invested heavily in a comprehensive e verification environment for FlexRay, which IPextreme is taking to market. This paper will explore how this recently announced environment can validate modifications to a FlexRay core and confirm correct operation of an SoC within a simulated FlexRay network. This eVC Kit has validated the FlexRay executable reference model that also serves as the basis for the FlexRay conformance test.

The Verification Challenge in a FlexRay system

A FlexRay network (cluster) consists of FlexRay nodes which exchange data (traffic) over at most two FlexRay channels. Figure 1 shows the general structure of such a FlexRay cluster and node (only single channel network depicted). Each node in the cluster must be compliant to the FlexRay protocol in order to ensure interoperability. The FlexRay consortium has defined an official suite of conformance tests ([1]). Passing those tests is required to obtain the FlexRay certificate. The partitioning of the Communication Controller (CC) into Controller Host Interface (CHI) and Protocol Engine (PE) sub-blocks separates the protocol specific PE logic that handles the FlexRay protocol from the host services supplied by the CHI for message transmit/receive and control. This approach is not required by the FlexRay Protocol Specification. More information about the architecture of FlexRay nodes can be found in [2].

The FlexRay standard defines more than 70 parameters ([3]), which results in a huge configuration space of global (cluster) and local (node) parameters. In addition, there are many interdependencies between these parameters, defined by 43 constraints within the protocol specification, which must be considered when setting up a FlexRay network (cluster). As a consequence, the validation of a FlexRay core or SoC in a simulated FlexRay network is much too complex for a simple verification methodology (e.g., using directed testing). A more sophisticated verification approach is required to ensure a high-quality, interoperable, fully-verified FlexRay product, while also considering time-to-market and development cost requirements.


Figure 1: FlexRay cluster and node

The verification target may be of different types:

• The Device Under Test (DUT) is a complete system with a FlexRay Communication Controller (CC) and a host.

• The DUT is a FlexRay Communication Controller without a host.

• Even single blocks like Controller Host Interface (CHI) or Protocol Engine (PE) can be the target of validation.

• The DUT is a FlexRay-related block or surrounding block outside of the Communication Controller (e.g., bus bridge to host bus system or memory controller). A typical use case for this kind of testing would be stress testing.

• The target of validation is a complete FlexRay bus system. This scenario can for instance be used to verify certain FlexRay network configurations or to perform stress testing. To save simulation time, RTL devices are replaced by faster simulation models.

Features Of An Ideal Verification Solution

What features would be offered by an ideal verification solution to address all of the verification challenges mentioned in the previous section? First of all, the different verification targets must be covered. A powerful methodology must guarantee the correct behavior of the DUT. The combination of reference simulation models, monitors, and checking mechanisms has already proven its power in many highly complex, highly sophisticated verification activities. The main functional blocks of this approach are:

• Reference model: Behaves exactly as defined by a given specification. It is assumed to always operate correctly.

• Monitors: Observe the DUT interfaces.

• Checking mechanisms: Ensure that only the expected behavior is observed at the DUT. A typical approach is to compare DUT behavior with that of the reference model; another is to develop a self-checking methodology.

• Strong test models: Create powerful stimuli.

Important considerations when designing a verification environment include:

• Reuse of existing verification components, especially such components that have already been in place in other verification projects and can therefore be seen as successfully proven.

• Providing a metric methodology that allows for statements about the quality of the verification results. At the end of the verification project, numbers must be presented about the quality of the tests that were executed.

• The setup of a FlexRay system communication schedule involves a huge configuration space. Complex dependencies exist which should be handled in a user-friendly way so that the verification engineer does not have to spend effort on writing thousands of tests covering all allowed parameter combinations and taking care of all the parameter dependencies. A sophisticated verification approach has built-in mechanisms to relieve the engineer of such tasks.

• The verification components should be easy to integrate into an existing system verification environment. Plug & Play can be achieved by using the same standard for the system test bench and the verification components to be added.

• A modular and scalable architecture of the verification solution allows upgrades and extensions. For instance, changing interface standards can be accomplished easily (e.g., evolutions of the FlexRay standard should be handled easily). This also facilitates maintenance of the components.

• The test bench should contain hooks to several different language standards (e.g., C, SystemC, SystemVerilog, and e). This enables reuse of existing code. For instance, routines that already exist as SystemC code do not need to be rewritten in e, although the surrounding verification component is written in e. The test bench supports all standard Hardware Description Languages (i.e., VHDL and Verilog). Furthermore, the complete test bench is compatible with all major simulators.

• Generation and injection of dedicated erroneous behavior.

• Detailed, comprehensive documentation complements the ideal solution. Similar to a common standard that is applied for the code and architecture of the test bench and its verification components, the documentation follows a consistent format.

FlexRay eVC Kit verification solution

The following section describes how the FlexRay verification environment (eVC Kit) addresses all of the challenges mentioned earlier in this paper and tries to get as close as possible to the ideal solution.

The FlexRay verification environment is implemented in the “e” hardware verification language. e was developed by Verisity, Inc. (now Cadence Design Systems) and has been ratified as the IEEE 1647 standard ([4]). e offers unique Aspect-Oriented Programming features that allow for much easier reuse, scalability, and extendibility. e is currently supported by Cadence’s Specman Elite test bench automation solution, which works with all major simulators. A key feature of this test bench automation solution with e is the generation of constrained-random stimuli. That means that stimulus generation can be influenced by constraining in a smooth transition from totally random stimulus (no constraints applied) to directed testing (fully constrained). This ability is extremely helpful considering the wide configuration space spanned by the FlexRay configuration parameters. In this way, thousands of possible cluster/node configurations can be covered by only a handful of test files. The interdependencies and the allowed ranges of the parameters are automatically handled by the built-in constraint solver. This mechanism would immediately point out contradicting or disallowed configurations within a node or cluster. Furthermore, e offers a metric methodology, namely functional coverage, to generate information about the quality of the simulation results. For each simulation run, the coverage results are stored and can be visualized. For regressions consisting of several simulation runs, the results in all corresponding coverage files can be accumulated to contribute to an overall result.

The full power of this methodology is unleashed using a vPlan. A vPlan is a formatted list of all features of the verification target (e.g., a FlexRay Communication Controller), which typically have been extracted from the target’s specification. The vPlan defines the coverage goals for the verification target. The coverage items in the e code are mapped onto the vPlan, which results in a user-friendly and detailed overview of functional coverage results. In particular, uncovered features (coverage holes) can be detected immediately using this approach. The coverage results are strongly leveraged by applying constrained-random stimuli in contrast to directed testing.

In addition to e, Specman Elite supports the SystemC language. Hooks for C, VHDL, Verilog, and SystemVerilog are also available. This allows reuse of existing code in these languages. The Plug & Play requirement is addressed by the eRM (e Reuse Methodology) compliance and the eVC (e Verification Component) architecture of the verification components contained in the FlexRay Verification Environment. An eVC is a ready-to-use, configurable verification module typically focusing on a specific protocol or architecture (such as Ethernet, AHB, PCI, or USB) [5]. The methodology for developing these eVCs is known as eRM. eRM compliance ensures:

• Common architecture, terminology, packaging, installation, and configuration

• Seamless usability across block, chip, and system-level environments

• Reusability across projects

• No interference between eVCs

• Common interface for writing test cases

• Improved maintenance

• Uniform debug messages

• Documented cookbook approach

An eVC is sometimes referred to as Verification IP (VIP). The general architecture of an eVC is depicted in Figure 2. The eVC is encapsulated in the env block. For each interface with the DUT, an agent is responsible for interaction. Agents can be active or passive; i.e., they can drive stimuli into the DUT or just observe the DUT interface. Agents consist of standard components like Config, Signals, Sequence Driver, Monitor, and Bus Functional Model. The Sequence Driver directs the stimulus data, which is derived from user-defined test scenarios (sequences), to the Bus Functional Model. The BFM handles the interaction with the DUT interfaces. A Monitor observes DUT signals and forwards this information to other components in the agent. Monitors typically deliver the base information for checking mechanisms.

Figure 2: General eVC architecture

The modular architecture of an eVC enhances the scalability and reusability of the verification environment.

The FlexRay verification environment solution consists of a set of eVCs and is therefore referred to as the eVC Kit (shown in Figure 3).

The eVC Kit contains one eVC to model a subset of the CHI layer (CHI2PE eVC) and one eVC for the PE layer. The e model of the FlexRay channel has a much simpler architecture and an eVC structure would mean overhead here. The Configuration Manager handles cluster and node setup. It contains the Configuration Space (Cfg Space), which consists of lists of the global and local FlexRay parameters for the DUT and all simulated FlexRay nodes.

The CHI2PE eVC contains three BFMs, one for interfacing with an RTL implementation of the PE, one for interfacing to the SystemC reference model and the other one for interfacing with the PE eVC.

The PE eVC contains a reference model (PE model), which was used to validate the FlexRay executable reference model. As the core of that executable model was written in SystemC, the PE eVC contains hooks that permit interfacing with the SystemC model. During the development phase, these hooks were used to ensure the alignment between the e and the SystemC model. Interfacing to the SystemC model can be very helpful when extending or changing the e model.

 

Figure 3: FlexRay eVC Kit

In addition to the components depicted in Figure 3, the verification environment solution contains a Traffic Generator eVC, which is used to generate FlexRay traffic stimuli at the Host-CHI interface (see Figure 5). The CHI block is specific for each FlexRay Communication Controller and offers different services to control the transmission and reception of messages. The eVC component acts as a host system for the Communication Controller.

Furthermore, the eVC Kit comes with a vPlan for all FlexRay-related features to be verified. This vPlan maps the coverage items of the eVC Kit to the tests of the FlexRay conformance test suite. The test suite ensures that all of those items are covered. A powerful fault injection, which makes best use of the aspect oriented nature of the e language, allows  to cover special bad case scenarios that are defined in the conformance test suite (e.g. a transmission across slot boundary violation).

The FlexRay verification environment solution addresses several verification scenarios differing in their verification targets. The covered scenarios are:

• PE verification

• CHI verification

• Communication Controller verification

• FlexRay system and configuration verification

• System-level software verification

Figure 4 shows the test bench environment for PE verification. The DUT is an RTL implementation of a FlexRay PE. The Sequence Driver contained in the CHI2PE eVC takes the content of the test files, which define dedicated sequences, and generates corresponding stimuli for the DUT. These sequences can be user-defined or predefined in the given test cases. The CHI2PE eVC can connect to a PE interface as given in the PE implementation developed by Freescale and also verified by NXP with the eVC models. A PE eVC can be used as a reference model and checker, which ensures aligned (i.e., correct) behavior of the DUT. It is possible to hook multiple RTL nodes (of any variety) into the cluster, which actually reduces the amount of test runs. Other nodes are implemented as eNodes, i.e. nodes that completely consist of e components. These nodes serve as simulation models for the emulation of traffic on the FlexRay channel.

Figure 4: PE verification environment

A test bench environment as depicted in Figure 5 can be used to validate the CHI layer only. In this example, the CHI RTL implementation is the target of validation. The Traffic Generator eVC is used to convert the sequences contained in the test cases into stimuli that correspond to the requirements defined for the DUT interface. The Traffic Generator eVC supports several different interface standards like AHB or OCP. Due to its modularity, the eVC can easily be extended to support additional user-specific interfaces.

 

Figure 5: CHI verification environment

Figure 6 shows the verification environment for validation of a Communication Controller that contains RTL implementations of the CHI and PE. In this scenario, the CHI-PE and the PE-FlexRay bus interfaces are monitored to check the correct behavior of the DUT.

Figure 6: CC verification environment

Another scenario that can be addressed with the FlexRay verification environment solution involves a DUT that acts as a complete FlexRay node with the CC and host implemented in RTL. Figure 7 shows how such an environment might look. In this test bench, the FlexRay node under test is stimulated by software running on the host. The Configuration Manager is capable of dumping configuration files, that can be read by the host. In addition, the host requires some CHI-specific configuration data in order to communicate with the FlexRay CC. The stimulus data for the FlexRay node under test is generated by appropriate software running on the host. All other nodes in the cluster are eNodes driven by the user-defined or pre-defined test cases via the sequence generator that is contained in the CHI2PE eVC.

For simulation environments without nodes containing RTL code, the cluster simply consists of multiple instances of eNodes. As mentioned earlier, this is a useful approach for stress testing of surrounding RTL logic, configuring complex clusters, collecting stimulus data, or software validation via simulation.

Figure 7: FlexRay system verification environment

Conclusion

The verification environment for validation of a FlexRay node or a layer (PE, CHI) of a node must fulfill certain requirements in order to allow for high-quality, interoperable products, first-time-right results, fast time-to-market, and reasonable development costs. The FlexRay verification environment solution developed by NXP and offered by IPextreme has validated the FlexRay executable reference model and offers many features to fulfill those requirements. The eRM compliant implementation in the e language leads to typical advantages of eVCs, like modular, reusable, extendable architecture, ease of use, and Plug & Play. Typical FlexRay demands like the coverage of the huge configuration space, taking into consideration the interdependency of parameters, are answered by the random-constrained stimulus generation feature of e.

The eVC Kit solution addresses a wide range of possible validation targets like CHI, PE, CC, complete node system with host, or surrounding logic only. The modularity and the clearly defined interfaces allow rapid adaptation of the FlexRay verification environment to the user’s demands. The predefined test suite contains the FlexRay conformance tests and is extendable to user-specific test cases.

References:

1. FlexRay Communications System, Data Link Layer Conformance Test Specification, Version 2.1, 2006

2. Stefan Schmechtig, FlexRay – The Hardware View, 2006

3. FlexRay Communication System Protocol Specification, Version 2.1a, 2006

4. IEEE 1647-2006 -- IEEE Standard for the Functional Verification Language 'e'

5. Samir Palnitkar, “Design Verification with e”, 2004, Prentice Hall Modern Semiconductor Design Series