■ Why Choose the IAR Development Environment for RISC-V

1) Functional Safety Certified
2) Diverse and efficient debugging solutions
3) Static analysis tool (C-STAT)
4) CI/CD process (build server)

IAR Embedded Workbench for RISC-V is the first to achieve functional safety certification. This provides the optimal solution for customers preparing and conducting functional safety projects.

The scope of certification covers international standards (IEC 61508), automotive (ISO 26262), medical (IEC 62304), railway (EN 50128/50657), home appliances (IEC 60730), machine control (ISO 13849/IEC 62061), industrial standards (IEC 61511), and agriculture and forestry (ISO 25119).

The certificate is provided by IAR and can be submitted to organizations and companies requiring certification.





C-SPY, an IAR debugging feature, is intuitive, efficient, and offers a variety of features that can effectively reduce debugging time.

This is the point of difference from other development tools, and it goes beyond the debugging method of inserting break points and monitoring variables and status with output functions (printf), and provides various ways to utilize break points, output and monitoring without external devices such as serial communication, bug backtracking function using trace function, checking dynamic stack usage, providing call stack graph, checking resource occupancy using function profile function, checking whether a statement is executed through code coverage function, and visual monitoring through timeline window.g) Provides functions, etc.

More details are provided in the next chapter.





The static analysis tool (C-STAT) can analyze each rule quickly and easily at the same level as compiling (compiler) without requiring complex environment settings.

Additionally, the help function makes it easy to understand the violations and even provides examples.

CWE, CERT-C, and MISRA-C can all be analyzed for each item, and ultimately, they also have a report generation function.

The CI/CD process is now widely known for its meaning and functionality. CI stands for continuous integration, and CD stands for continuous delivery. Consider the software configuration management tools you use, and their functionality has become indispensable.

The same applies to CI/CD. Currently, decisions about adopting CI/CD are being made based on factors such as industry characteristics and project scale, but it's clear that in the near future, it will become an indispensable process, like configuration management tools. IAR provides a version for build servers for CI/CD processes called BXRISC-V.





■ Functional safety certification

○ What is functional safety?

First, it's necessary to distinguish between safety and functional safety. Safety is a standard for designing systems that are free from hazards, i.e., capable of preventing hazards in advance. Functional safety is a standard for detecting potential hazards and aims to reduce the serious consequences of hazards.

Adopting these functional safety standards can reduce product liability, product recalls, and the frequency of software updates. This improves a company's reputation and ensures compliance with international standards.

○ Functional safety standards

As previously explained, functional safety standards include international standards (IEC 61508), automotive (ISO 26262), medical (IEC 62304), railway (EN 50128/50657), home appliances (IEC 60730), machine control (ISO 13849/IEC 62061), industrial standards (IEC 61511), and agriculture and forestry (ISO 25119). The IAR Embedded Workbench for RISC-V covers all of these specifications.

○ Solutions for certified products

First, rather than a standard version, we provide a build tool that has completed functional safety processes and testing, along with a certificate. This certification was obtained through TÜV SÜD, a global technology services company that provides comprehensive technical services, including testing, certification, inspection, and training, to protect the safety of people, the environment, and property. Test reports and safety guides are provided through this organization.

■ Diverse and efficient debugging solutions

○ Using printf without an external device

Typically, it is used for debugging using a terminal program using serial communication (such as UART). Semi-hosting allows you to monitor internal variables and status using the printf function without external devices and terminals.





○ How to use various breakpoints

In addition to the regular code breakpoints, we also provide flash and log breakpoints.

While code breakpoints have a limited number of breakpoints depending on the system, flash breakpoints have no limit on the number, making them more convenient to use.

If you are unable to add any more breakpoints due to a limit on the number of breakpoints in use, you may want to consider using flash breakpoints.

Log breakpoints do not stop program execution when the breakpoint is passed, but only log the execution and continue execution.

At this time, the corresponding variable value at the breakpoint location can also be output simultaneously. This is often used within interrupt routines.

If the entire program operation stops at the interrupt routine, the overall operation logic may not be the desired logic during debugging.

Therefore, by using log breakpoints, we can monitor the values of variables within the interrupt routine while maintaining the overall operation of the program.





○ Check dynamic stack usage

You can use the debugging feature to check stack usage. This is very useful because it shows stack usage at the point where a breakpoint is inserted during program execution.

It also shows the maximum stack usage, so you can check for stack overflows or usage relative to the set stack size.

In the Stack 1 window below, the green line is the current (breakpoint insertion location) stack usage, and the gray bar is the maximum stack size used. It was confirmed that 5% (224 bytes) of the set stack size was used at maximum.





○ Visible monitoring function through the timeline window

The Timeline window is powerful. It graphically displays the data you want. The image below shows variable value changes and the call stack. Furthermore, when analyzed with the function profiler, you can check the resource usage of each function.





○ Check function execution time using the function profile function

Function profiling allows you to check function execution times. Every developer is interested in knowing how long a function they designed takes. You can easily check the time using IAR's function profile feature.





○ Bug trace function using trace function

As the name suggests, trace is a tracing function. This function stores program execution information at the instruction level, allowing you to accurately pinpoint the location of the problem by backtracking from the point where the bug occurred. For more detailed information, please refer to the previous webinar on debugging methods on the IAR website or contact the IAR Korea branch.





○ Check whether a statement is executed using the code coverage function

The code coverage feature provided by IAR is syntax coverage. This indicates which lines were executed and which were not executed during actual program execution. Based on these execution results, you can verify whether your designed program is operating as intended. In the picture below, green indicates that it has been performed, and red indicates that it has not been performed.





■ Static analysis tool (C-STAT)

The static analysis tool (C-STAT) can analyze each rule quickly and easily at the same level as compiling (compiler) without requiring complex environment settings.

Additionally, the help function provides an easy-to-understand overview of violations and even provides examples. CWE, CERT-C, and MISRA-C all allow for individual analysis and ultimately, a report generation function is also provided.





■ CI/CD process (build server)

○ Why a CI/CD process is needed

The day before software distribution, the atmosphere in the development room is hectic. There are many situations: people focused on their computers to meet their quotas, colleagues engaged in heated discussions about version conflicts, pointing fingers at each other to fix them, people waiting for their colleagues to finish after completing their quotas, and people demanding the verification team to respond quickly with software-level verification results. To improve this atmosphere, how about implementing an automated build server and CI/CD process?

As previously explained, the CI/CD process is now widely known for its meaning and functionality. CI stands for continuous integration, and CD stands for continuous delivery. Consider the software configuration management tools you use, and their functionality has become indispensable.

The same holds true for CI/CD. While decisions about implementing CI/CD are currently being made based on factors such as industry characteristics and project scale, it's clear that in the near future, it will become an essential process, like configuration management tools. IAR offers a build server version for CI/CD processes, called BXRISC-V.

○ What is the CI/CD process?

CI is an automated process for building and testing code for version control as changes continuously occur among team members, i.e., as they are updated to the server. Previously performed manually, this process reduces numerous secondary tasks, resulting in a faster workflow. It also prevents conflicts between multiple developers using a software version control server. Any developer who has experienced conflicts between themselves as they upload (commit/push) their completed code to the server during the process of completing software development and distributing it to the test team will understand the need for the CI process.

CD, an extension of CI, is a process for rapid deployment of modified software. This involves automatically uploading developer changes to the server after bug testing, aiming to deploy new software with minimal effort. This also automates a series of tasks previously performed manually by the testing team, providing a faster process.





The left side of Figure 12 illustrates the concept of CI, and the right side illustrates the concept of CD. These stages exist in pairs: Code - Develop, Commit - Build, Build - Test, Test - Deliver, and Notify - Monitor. Code was developed, uploaded to a configuration management tool, then a build was performed, the resulting release was tested by the test team, and issues were reported. Developers then monitored and fixed the issues. This process has traditionally been done manually. However, according to the CI/CD process, that is, the automated process, these procedures are automated by tools belonging to each step.

○ What if IAR CI/CD build tools are applied?

Figure 13 shows a development process with CI/CD applied, and the dotted line (---) is an automated process based on CI/CD.

Developers upload (commit) completed code to Gillab. The branch being uploaded is the development branch, not the production branch for deployment. This means that only code approved by the project manager, in accordance with the CI/CD development flow, can be uploaded to the product branch.

In the past, each team would have uploaded their completed code to a single branch and distributed it to the testing team.

However, in the CI/CD process, deployment can only be done if the compilation results are problem-free, there are no conflicts between developers, and there are no violations of coding rules as determined by the company or client through static analysis.

When changes are uploaded to the development branch, they are immediately reported to the project manager and compiled by the IAR build tool (BXRISC-V) on the build server, and the results are reported back to the project manager.

At this time, when code is uploaded by multiple developers, continuous integration is performed to automatically build and check whether there are any problems with the compiled results and whether there are any conflicts between codes modified by multiple developers. By linking with IAR's static inspection tool, C-STAT, after the build, you can find basic code defects and improve quality before the code is uploaded to GitLab.





■ Conclusion

IAR is a leading provider of RISC-V software development environments and has developed most of the features you need. We hope this information has been helpful to those seeking to implement RISC-V. If you need further technical support, including information on this article, please contact IAR.

thank you

View the video and details related to the contribution: https://register.gotowebinar.com/recording/7851496407429895952