The Pain Point for Automotive Software Developers
Automotive software is inflated and becoming more and more complex every day; therefore, the number of evaluation man-hours to ensure its quality is increasing. One of the issues that arises during the quality assurance process is it is very difficult for the hardware to always reproduce the same abnormal condition. This makes it very hard to test the software in that case for the customer.
What is the RH850 Virtual Platform (VPF)？
RH850 VPF is a simulation environment that enables software design without device samples. The simulator has the following features.
- It is a simulator based on SystemC and Transaction-level Modeling (TLM) which is a standard specification model I/F).
- It supports the instruction set (selectable High accuracy or High performance) and peripheral I/O modules.
- It can simulate the whole system with an outside model (CAN simulator, etc.).
- It can connect with the software debugger which is provided by a tool vendor as the software debug environment.
- It supports the following Renesas automotive devices: P1x, C1x, E1x, F1x, E2x, U2A, U2B, U2C.
Here are the main use case and benefits of using the RH850 VPF.
- Early software development before preparing the real MCU
- The customer can start software development in advance.
- Regression test
- It can plan efficiency of the work via the automatic test. In addition, it can easily expand the test environment by N times regardless of the hardware.
- Virtual network verification
- It can verify the quantitative bus occupancy rate.
- It can analyze the impact and operation when the customer changes the protocol of the automotive network.
RH850 VPF’s Solution for the Issue
RH850 VPF reproduces an abnormal condition with the following idea to solve the issue that it is difficult for the hardware.
- RH850 VPF doesn’t reproduce the hardware operation itself that detects the error.
- RH850 VPF reproduces the register values of the abnormal condition and error signal at any of the timings.
By omitting the hardware operation itself, we can provide VPF which can reproduce an abnormal condition for a customer in a short period of time.
Using ECC as an example, the difference between the RH850 hardware and VPF is explained.
ECC operation of the hardware is as follows.
When the master writes the value to the memory (ECCRAM), ECC creates the error correcting code and stores it in ECC part. ECC checks the error correcting code at the read access. If ECC detects the error, it requests the interrupt to INTC via ECM.
The following image shows RH850 VPF ECC.
To verify the abnormal operation of software, it is sufficient for the customer that RH850 VPF can move their software status to the abnormal condition. Then, RH850 VPF needs only two functions which can write the abnormal status to the registers and notify the error. Therefore, RH850 VPF doesn’t need “Encoder”, “Decoder”, and “ECC part” to detect the real error.
To notify the error at the suitable timing for the customer, RH850 VPF’s ECC supports the following APIs.
- Write operation API which can set the value at the register at any of the timings
- Notify error API which can output error at any of the timings
The software verifier can set the abnormal status and output error signal using those APIs. Then, they can start the simulation from the abnormal condition.
Here is an example of an ASTC VLAB case.
An API is called via command line to set the register value and notify error.
In this way, we develop the RH850 VPF with the viewpoint of what is necessary for the software verification. RH850 VPF provides the reproduction environment for an abnormal condition instead of supporting the hardware operation itself.
We continue to support the software verification environment which is difficult for the hardware to reproduce on the RH850 VPF.