Extensible vector library software architecture design method

Abstract

According to the extensible vector library software architecture design method, a vector library code module is divided into an accelerated part and a non-accelerated part according to whether a code needs to be matched with a specific hardware platform instruction or not when different hardware architectures are matched; according to the method, a set of function naming specifications on a hardware platform are defined for different hardware architectures, functions with the same function are named on different hardware platforms according to the naming specifications, function naming conflicts are avoided, and meanwhile accelerated implementation of the function on a specific platform is guaranteed; according to the method, a set of extensible hardware platform pre-compilation instructions are named in a standard mode, conditional compilation of codes on a specific platform is achieved, the compilation time of the whole program is effectively shortened, the consistency of external function names and parameters of an AcoreVEC vector library function compiled on all platforms and the vsipl standard is achieved, and the development efficiency is improved.

Description

Technical Field

[0001] This invention belongs to the technical field of embedded computing systems and devices, and particularly relates to a method for designing an extensible vector library software architecture. Background Technology

[0002] VSIPL (Vector Signal Image Processing Library) is a specification for vector signal image processing libraries on embedded systems, funded by the Defense Research and Security Programs Agency (DARRA) and developed under the leadership of the Hughes Research Laboratory. The VSIPL Consortium is responsible for developing the standard library, which features a unified industry-standard application programming interface (API). It provides a consistent C language API for scalar, vector, linear algebra, matrix, and signal processing functions for high-performance embedded computing. Its purpose is to enhance portability and code reusability when using the vector library interface across multiple platforms and software, allowing it to run on various VSIPL-compatible hardware systems without significant porting costs. This library is primarily used for high-end embedded signal, information, and image processing. With the rapid development of aerospace applications, the demands of complex missions require highly integrated and intelligent algorithms and processing in aerospace embedded software. The scale and complexity of software are further increasing, placing higher demands on the uniformity of software architecture and the reliability of the software.

[0003] Currently, the development of embedded software for aviation mainly adopts a task-customized development model. Due to the use of different software architectures, the inheritance between software models is weak, which affects the development efficiency, quality of software products, and code management. At the same time, software code integration and management are relatively cumbersome, resulting in a reduction in the overall development efficiency of the software.

[0004] In view of this, the present invention is hereby proposed. Summary of the Invention

[0005] The method for designing a scalable vector library software architecture provided by this invention solves the problem of low overall software development efficiency caused by traditional methods. The technical solution of this invention has many beneficial effects, as described below: A method for designing an extensible vector library software architecture, applicable to the construction of embedded software code integration and management for airborne avionics systems, the method comprising: S101: Obtain the vector library code of the avionics system, wherein the vector library code is divided into accelerable part code and non-accelerable part code according to preset rules; S102: Defines function naming rules for the accelerable code on different hardware platforms, where... The naming convention for the onboard ARM platform is to use the original function name and the suffix _neon. The naming convention for the onboard RISC-V instruction platform is to use the original function name and the suffix _rsv. The naming convention for the onboard GPU platform is to use the original function name and the suffix _gp. The non-accelerable code portion adopts the unconditional compilation rule applicable to the integration of embedded software code in airborne devices; S103: A set of pre-compilation directives is defined for different hardware platforms, and the corresponding pre-compilation directives are added to the code of the corresponding airborne hardware. When the ARM platform is 32-bit, the preprocessor directive is preset to HAVE_SIMD_1_32B. The preprocessor directive is added to the #define of the original function name and the suffix name _neon, and conditional compilation is performed according to the naming rules of the ARM platform through the preprocessor directive HAVE_SIMD_1_32B. When the ARM platform is 64-bit, the preprocessor directive is preset to HAVE_SIMD_1_64B. Adding the preprocessor directive to the #define of the original function name and the suffix name _neon allows for conditional compilation according to the naming rules of the ARM platform through the preprocessor directive HAVE_SIMD_1_64B, which can reduce the size of the vector library generated by the airborne platform and shorten the compilation time.

[0006] Compared with the prior art, the technical solution provided by the present invention has the following beneficial effects: With the emergence of new-generation processor architectures and SIMD-based computing architectures, vector library software needs to be developed and adapted to different hardware architectures to achieve higher real-time response on these hardwares. As the code size increases, the architecture design of the software code becomes particularly important for code integration and management. This invention addresses the lack of a universal software architecture for vector library software, improving software architecture reliability and the difficulty of code integration and management. It offers highly reliable vector library software architecture design with a clear logical structure, mature technology, and high reliability. It also boasts good scalability, allowing for adaptation and code integration management to other hardware platforms as needed for various tasks. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1This is a schematic diagram of the architecture of the scalable vector library software ACoreVEC of this invention. Detailed Implementation

[0009] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0010] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this invention, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0011] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. The drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0012] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that aspects can be practiced without these specific details. To enable those skilled in the art to better understand the invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined as "first" and "second" may explicitly or implicitly include one or more of that feature. In the description of the invention, unless otherwise stated, "a plurality of" means two or more.

[0013] like Figure 1 The method for designing an extensible vector library software architecture shown is applicable to the construction of embedded software code integration and management for airborne avionics systems. It can serve as embedded software for airborne avionics systems, improving software code management. The method includes... S101: Obtain the vector library code of the avionics system. The vector library code is divided into accelerated and non-accelerated parts according to preset rules. Generally, the code that focuses on computational efficiency can be classified as accelerated code. This part of the code needs to be developed and designed for specific platform instructions and the function names need to be renamed. The non-accelerated code generally does not need to be renamed, nor does it need to be independently designed and developed on a specific hardware platform. This part of the code mainly consists of the vector library support functions, such as vector library management (initialization and termination), memory management, and the definition of various view functions.

[0014] S102: Defines function naming rules for the accelerable code on different hardware platforms, where... The naming convention for the onboard ARM platform is to use the original function name and the suffix _neon. The naming convention for the onboard RISC-V instruction platform is to use the original function name and the suffix _rsv. The naming convention for the onboard GPU platform (HAVE_GPU) is to use the original function name and the suffix _gp. The non-accelerable code adopts the rule of unconditional compilation, which is applicable to the integration of embedded software code in airborne devices; S103: A set of pre-compilation directives is defined for different hardware platforms, and the corresponding pre-compilation directives are added to the code of the corresponding airborne hardware. This achieves conditional compilation for code adaptation across different hardware platforms and standardization of the external interface of vector library functions. The pre-compilation directives are suitable for the design requirements of vector libraries to adapt to different heterogeneous hardware and meet the standard specifications of vector library interface functions, as detailed below. When the ARM platform is 32-bit, the preprocessor directive is HAVE_SIMD_1_32B by default. The preprocessor directive is added to the #define of the original function name and the suffix name _neon, and conditional compilation is performed according to the naming rules of the ARM platform through the preprocessor directive HAVE_SIMD_1_32B. When the ARM platform is 64-bit, the preprocessor directive is HAVE_SIMD_1_64B by default. Adding the preprocessor directive to the #define of the original function name and the suffix _neon allows for conditional compilation according to the naming rules of the ARM platform through the preprocessor directive HAVE_SIMD_1_64B, which can significantly reduce the size of the vector library generated by the airborne platform and shorten the compilation time.

[0015] Working principle: It is divided into an accelerable part and a non-accelerable part. The accelerable part is pre-compiled according to the platform's pre-compilation instructions, while the non-accelerable part is unconditionally compiled. A set of naming conventions for the implementation functions on different hardware architectures is defined for each hardware platform. Functions with the same function are named according to the naming conventions on different hardware platforms, which avoids function naming conflicts and ensures the accelerated implementation of functional functions on specific platforms. The specification defines a set of extensible hardware platform pre-compilation directives, enabling conditional compilation of code on specific platforms. This effectively shortens the overall program compilation time. For example, in the interface module, the pre-compilation directives are used to implement a one-to-one correspondence between the standard functions of the external vector library and the function definitions in the API module. This ensures that the function names and parameters of the AcoreVEC vector library functions are consistent with the vsipl standard after compilation on all platforms.

[0016] In one embodiment, the accelerable code includes a vector and element operation module, a linear algebra module, and a digital signal processing module, while the non-accelerable code includes a vector library support function module, a scalar function module, a random number function module, a print output function module, a vector and element operation module with a step size not equal to 1, a linear algebra module, and a digital signal processing module.

[0017] In one embodiment, the RISCV instruction platform includes the HAVE_SIMD_2_32B platform and the HAVE_SIMD_2_64B platform, and the precompiled instructions can also be: On the ARM platform, the naming convention for acceleration module functions is to append _neon to the naming convention for vector library functions. For example, the general vector library vector addition function vsip_vadd_f is named vsip_vadd_f_neon on platforms that support NEON instructions, vsip_vadd_f_sse on platforms that support SSE instructions, and vsip_vadd_f_gpu on platforms that support gpu instructions, etc. To minimize the size of the vector library generated on a specific hardware platform and shorten compilation time, the specification names a set of pre-compilation directives. For example, the pre-compilation directive is defined as HAVE_SIMD_1_32B for source code that supports 32-bit neon instructions, and as HAVE_SIMD_1_64B for source code that supports 64-bit neon instructions, thus enabling conditional compilation on a specific platform.

[0018] In the interface module, the API module implements a one-to-one correspondence between the standard functions of the external vector library and the function definitions based on the pre-compilation directives. For example, it implements the same functional code vsip_vadd_f_neon, vsip_vadd_f_sse, vsip_vadd_f_altivec, etc. on several platforms. During compilation, the vsip_vadd_f function is compiled by calling the function of the specific platform according to the pre-compilation directives, so as to realize the instruction adaptation of the vsip_vadd_f function on the specific platform.

[0019] The steps involved in the design process: First, the vector library code is divided into accelerable and non-accelerable parts. Generally, code focused on computational efficiency is classified as accelerable code. This part requires development and renaming of functions specifically for platform instructions. Non-accelerable code generally does not need renaming or independent design and development on specific hardware platforms. This part mainly consists of supporting functions for the vector library, such as vector library management (initialization and termination), memory management, and the definition of various view functions.

[0020] Secondly, a set of naming rules for vector library functions on different hardware platforms is defined for the accelerable parts. According to C language compilation rules, function names must be unique. Therefore, different function names should be used for the same function implemented on different hardware platforms. At the same time, in order to reflect the function's functionality and hardware platform characteristics, a set of naming rules for vector library functions with the same functionality implemented on different hardware platforms is defined to achieve standardized management of code for specific hardware platforms.

[0021] Finally, a set of pre-compilation directives for different hardware platforms was defined, and these directives were added to the corresponding hardware implementation code. This achieved conditional compilation for code adaptation across different hardware platforms and standardized the external interfaces of vector library functions. The aim was to: allow specific functions to be compiled at compile time, significantly reducing compilation time and the size of the generated static library; and define a set of conditional compilation rules between standard vector library functions and their implementations on different hardware platforms, ensuring the consistency of the external interfaces of vector library functions.

[0022] This method can be successfully applied to the integrated management of ACoreVEC code in general 32-bit and 64-bit systems, as well as ARM's 32-bit and 64-bit NEON instruction platform systems. Practical engineering applications demonstrate that this method is reliable, effective, logically clear, and easy to use, meeting practical engineering needs and possessing practical engineering value. It satisfies the requirements of the ACoreVEC vector library for adaptation across different hardware platforms. The architecture formed by this method divides the vector library code into accelerable and non-accelerable parts based on whether the code needs to be adapted to specific hardware platform instructions when adapting to different hardware architectures. A set of naming rules for vector library functions on different hardware platforms is defined, thereby avoiding naming conflicts between functions with the same functionality implemented on different hardware platforms.

[0023] The product provided by this invention has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to the invention without departing from the principles of the invention, and these improvements and modifications also fall within the protection scope of the invention claims.

Claims

1. A method for designing an extensible vector library software architecture, applicable to the construction of embedded software code integration and management for airborne avionics systems, characterized in that, The method includes, S101: Obtain the vector library code of the avionics system, wherein the vector library code is divided into accelerable part code and non-accelerable part code according to preset rules; S102: Defines function naming rules for the accelerable code on different hardware platforms, where... The naming convention for the onboard ARM platform is to use the original function name and the suffix _neon. The naming convention for the onboard RISC-V instruction platform is to use the original function name and the suffix _rsv. The naming convention for the onboard GPU platform is to use the original function name and the suffix _gp. The non-accelerable code portion adopts the unconditional compilation rule applicable to the integration of embedded software code in airborne devices; S103: A set of pre-compilation directives is defined for different hardware platforms, and the corresponding pre-compilation directives are added to the code of the corresponding airborne hardware. When the ARM platform is 32-bit, the preprocessor directive is preset to HAVE_SIMD_1_32B. The preprocessor directive is added to the #define of the original function name and the suffix name _neon, and conditional compilation is performed according to the naming rules of the ARM platform through the preprocessor directive HAVE_SIMD_1_32B. When the ARM platform is 64-bit, the preprocessor directive is preset to HAVE_SIMD_1_64B. Adding the preprocessor directive to the #define of the original function name and the suffix name _neon allows for conditional compilation according to the naming rules of the ARM platform through the preprocessor directive HAVE_SIMD_1_64B, which can reduce the size of the vector library generated by the airborne platform and shorten the compilation time.

2. The method according to claim 1, characterized in that, The accelerated code includes a vector and element operation module, a linear algebra module, and a digital signal processing module.

3. The method according to claim 1, characterized in that, The non-accelerable code includes a vector library support function module, a scalar function module, a random number function module, a print output function module, a vector and element operation module with a step size not equal to 1, a linear algebra module, and a digital signal processing module.

4. The method according to claim 1, characterized in that, It can meet the design requirements of vector libraries to adapt to different heterogeneous hardware and satisfy the standard specifications of vector library interface functions.

5. The method according to claim 1, characterized in that, The RISCV instruction platform includes the HAVE_SIMD_2_32B platform and the HAVE_SIMD_2_64B platform.

Images