Tackling the HPC Design Productivity Gap

The complexity of automotive systems has been growing ever since electronics were introduced into vehicles. Functionally safe capabilities, such as X-by-wire, that were once the domain of expensive military and aerospace applications are, today, commonplace in the vehicle. However, over the past decade, the productivity gap in developing those Electronic Control Units (ECUs) has grown markedly.

One of the earliest references to the term Design Productivity Gap is found in the 2000s by the International Technology Roadmap For Semiconductors (ITRS) [1] . It noted the growing gap between silicon advancements, following Moore’s Law, and the available Electronic Design Automation (EDA) tools needed to design and verify the chips and fully leverage those advantages, stating:

Recent editions of the ITRS have noted a design productivity gap—the number of available transistors [is] growing faster than the ability to meaningfully design [integrated circuits using] them.

Today, the growing divide between the capability of high-performance computing platforms and software developers’ ability to leverage all of the available advantages shows similar signs of a design productivity gap. In a paper on the topic focusing on embedded systems [2], Maxime Pelcat provides an excellent definition of design productivity (DP), explaining that:

Design Productivity (DP) relates to a compromise between the efforts spent to build a system and the quality of the system resulting from these design efforts.

Design productivity can be improved in two ways. The first is to reduce the design effort by applying more appropriate design methodologies, something that typically requires support from new development tools. The second is to focus on increasing implementation quality for the same effort. This requires ‘better’ developers and a healthy portion of luck, both of which are difficult to define and provoke. Thus, it is preferable to focus on improving the design methodology to attain predictable and significant progress in DP.

Today, it is the SoCs that have been made possible by Moore’s Law that are causing DP issues for embedded automotive system developers. With their heterogeneous architectures, including hardware accelerators, they are fully capable of handling the complex demands required of them, such as high-performance computing (HPC) and cross-domain computing ECUs. However, the retention of existing software development methodologies and the tools used results in a deterioration of DP.

Admittedly, much is being done correctly. During the design phase, modeling is in place that breaks down the complexity of systems and makes them easier to manage. Software reuse plays a prominent role, too, as does the reuse of testing platforms and tools from one design to the next. Testing too is undertaken earlier and has been automated, allowing thousands of tests to run without human intervention and on a regular basis. But, despite all this, sporadic issues are still being discovered as late as final testing that are difficult to define and replicate, challenging to locate, and almost impossible to resolve.

Sensor fusion applications are dependent on a good understanding of system timing to avoid old measurements being used to make decisions.

Having supported customers in hundreds of automotive software projects, INCHRON has seen that these issues are almost always timing related. Scheduling issues, bursts of interrupts, variation of software execution times, or other similar corner case challenges results in a failure of the platform on rare occasions. Because these issues are often tightly coupled to architecture decisions made years before, they are often managed with a software fix rather than being resolved. The frustration is, these issues could have been designed out at the beginning of the project.

As teams move from single-core to multicore processors and then take the next step to SoCs with heterogeneous hardware and virtualization, the hardware and software processing capability grows rapidly. The question is: is there a software development methodology in place that fully benefits from it?

The approach that has proven, time and again, to improve DP follows INCHRON’s close focus on timing. Typically, most teams focus on the functionality of the platforms they are building. This is natural, as OEMs are expecting a product that fulfils the defined functional requirements. However, with multiple software suppliers involved, and exceptionally complex processors, memory buses, accelerators, and peripherals, ensuring the timing of each aspect of the solution is just as important. If timing is not considered from the outset, it will not be scrutinized in the design, deliberated during development, or tested for during integration and final test.

Using the toolkit provided in chronSUITE, development teams can model and analyze SoC-based designs with heterogeneous hardware to determine an optimized design architecture. As design decisions are made that rely upon carefully considered aspects of system timing, they are documented in the project specification together with the functional requirements. During the following stages of project development, software developers are then able to code to fulfil both requirement types. And, as the integration phase is undertaken, the aspect of timing is again given the same level of consideration as the platform’s functionality.

chronVIEW, part of the chronSUITE toolkit, allows teams to review the timing aspects of complex applications, including event chains and even when using a hypervisor.

The result is a significant improvement in DP for organizations. Firstly, the issue of timing is acknowledged as credible cause of failures. The timing data gathered during development and testing, both from model simulation or actual hardware, is used both internally and with external suppliers to pinpoint the cause of issues, rather than just highlighting the issue’s existence. Secondly, the methodology ensures that timing data remains a topic of conversation during design reviews and trouble-shooting meetings. This leads to an improvement in implementation quality and a clearer definition of the origin of sporadically occurring issues. Thirdly, by integrating chronSUITE with automated testing systems, issues caused by timing errors are discovered much earlier in the development process. The resultant HPC or cross-domain computer is also better able to utilize the fully performance of the SoC used, leading to a correctly functioning finished product that is delivered on time and within budget.

If you’d like a free trial of chronSUITE, would like pricing, or simply want to learn more, use the links or contact form below.