Method for generating source code

Abstract

The invention relates to a method for generating source code from one or more blocks of a block diagram comprising blocks and signal connections between blocks. The generation of source code comprises transforming the block diagram into an intermediate representation, gradually optimizing the intermediate representation, and translating the optimized intermediate representation into source code. The optimization according to the invention comprises detecting at least two parallel control flow branches, in each of which a multi-component variable is copied, in which case a single multi-component output variable results after the at least two control flow branches, checking whether a regular copy of values from a source variable into the output variables takes place in all parallel control flow branches, and replacing the output variables with a pointer to one of the source variables. Moreover, the invention relates to a method for configuring a controller, to a computer program product and to a computer system.

Description

[0001] AZ: 24-030-DE - 1 - October 30, 2024

[0002] Methods for generating source code

[0003] The invention relates to the generation of executable code from a block diagram, in particular for the programming of control units.

[0004] Electronic control units (ECUs) are used in a wide variety of applications to monitor physical process parameters and / or to influence a process via connected actuators; for example, they can be used to control the braking process via anti-lock braking. The time constants that determine the dynamic behavior of the process often necessitate cycle times of 1 ms or less, thus requiring real-time capability from the ECU. For cost reasons, ECUs often use microcontrollers with limited memory and processing power, making the size and efficiency of the executable code crucial.

[0005] To accelerate the design of electronic control units (ECUs), control strategies are often developed using models in a computational environment such as MATI_AB / Simulink. This allows the process and / or controller, or more generally the behavior of the ECU, to be simulated and the presence of desired characteristics to be verified. The models can be block diagrams, which comprise blocks that perform operations such as calculations. For example, a block might calculate an output signal from multiple input signals. Block diagrams are typically executed cyclically, with all blocks permanently stored in memory and each block executed once per journal. Specifically, a block in each journal can apply one or more operations to input signals from the preceding block to generate output signals for the current step.Block diagrams can also include a sub-model to describe discrete behavior, in which a number of states and transition conditions are defined.

[0006] Source code for programming the control unit can be generated directly from the models using a code generator. For example, see the document "Production Quality Code Generation from Simulink Block Diagrams", AZ: 24-030-DE - 2 - 30.10.2024.

[0007] Proceedings of the 1999 International Symposium on Computer Aided Control System Design, Kohala Coast, Hawai'i, by H. Hanselmann et al., a code generator for the production of source code is known.

[0008] When models are described in the form of a block diagram, where blocks are linked for exchanging data or forwarding signals via directed connections or signal connections, a common code generation approach is to create a variable in the source code for each output of a block, i.e., a block output variable is created for each outgoing signal. However, this has the disadvantage that it usually results in more block variables than are actually necessary. Therefore, optimization, as described in EP 2418577 A1, is typically performed afterward to reduce the number of block variables or, more generally, the code size. Due to unmet preconditions, depending on the model situation, restricted optimization often occurs.

[0009] Especially in the case of parallel control flow branches or conditional execution of model components, it can be unclear at code generation which branch will be executed because the conditions can only be meaningfully evaluated at runtime. This necessitates the creation of a temporary storage variable, which serves as the target for copy operations or calculations of the parallel control flow branches. If the temporary storage variable is a multi-component variable, such as a vector, increased stack consumption and runtime due to the copy operations will occur.

[0010] The previously unpublished EP application 24157503.4 offers improved optimization, for example, for model situations in which multiple parallel control flow branches write a variable, which is then accessed in an operation. If a cost criterion is met, the operation is moved from its original location to the locations where the variable was written. Meeting the cost criterion may require, in particular, that the code size of the operation or the code to be replicated is below a predefined threshold. After the move, it may be possible to completely eliminate the multi-component intermediate variable. However, this optimization is only applicable to certain model situations (AZ: 24-030-DE - 3 - 30.10.).If applicable in 2024, it may fail in particular because the intermediate storage variable is accessed in multiple operations, resulting in a significant increase in code size.

[0011] Against this background, it is an object of the present invention to further develop the state of the art and in particular to enable the generation of source code with increased execution speed and / or reduced stack consumption for further model situations.

[0012] This problem is solved by a method for generating source code according to claim 1, a computer program product according to claim 13, and a computer system according to claim 14. Advantageous embodiments are the subject of the dependent claims.

[0013] A method for generating source code from one or more blocks of a block diagram is provided, comprising blocks and signal connections between blocks, in particular at least three blocks and at least two signal connections between blocks. The generation of source code includes transforming the block diagram into an intermediate representation, successively optimizing the intermediate representation, and translating the optimized intermediate representation into source code, wherein the transformation of a block includes creating a reference to a block output variable.According to the invention, at least two parallel control flow branches are detected, in each of which a multi-component source variable is copied to an output variable. A check is performed to ensure that a regular value copy from one of the source variables to the output variable occurs in all parallel control flow branches. The output variables are then replaced by a pointer to one of the source variables. In particular, the output variable in each of the parallel control flow branches is replaced by a pointer to the respective source variable. In the subsequent use of the output variables, a pointer to the source variable of the active control flow branch, or a selection pointer, is advantageously obtained, which can be dereferencing to obtain the desired value. AZ: 24-030-DE - 4 - 30.10.2024.

[0014] A signal connection allows data or signals to be transmitted. A first block outputs a value, or, depending on the definition, several related values. A second block receives these values ​​and uses them to determine one or more related output values ​​for the second block. Signals can contain scalar variables and / or structured data types such as arrays. For example, a bus signal becomes a structure variable in the generated code. If a block accesses a multi-component variable, or if a signal outputs a multi-component variable, eliminating the need for these variables can result in significant memory and execution time savings. This is achieved, for example, by eliminating the need to generate instructions for copying the individual components or elements of the variable in the code, thus preventing their execution at runtime.The multi-component variable can be a vector comprising a multitude of variables of the same data type, a matrix comprising a multitude of vectors, a structure comprising a multitude of variables of any data type, or a vector of structures or a matrix of structures.

[0015] The invention is based on the consideration that large intermediate variables or output variables, preferably of automatic storage duration, which can occur particularly as block output variables of signals comprising a multi-component variable, offer a high potential for savings in runtime and / or stack size. This is especially true when these intermediate variables are only needed to select a value from several possibilities. According to the prior art, these could generally not be eliminated because their content depends on a condition and they are used in operations that are not suitable for being moved to the various control flow branches (because otherwise a significant increase in code size would occur).Because the memory consumption of a pointer is significantly lower than that of a multi-component variable, such as a structure with a multitude of components or a vector with a multitude of elements, the optimization according to the invention, i.e., replacing the variables with a selection pointer, can enable significant savings in stack usage. Since copying the values ​​of the output variables is computationally intensive, especially in the case of a vector where it regularly occurs via a loop, significant savings in runtime and code size can also be achieved when a selection pointer is used instead of the output variables.This does not require modeling pointers in the block diagram; rather, the desired modeling in model-based development can focus on data flow and operations, and the identification of an optimizable situation is achieved by examining the code to be generated.

[0016] In embodiments of the invention, the output variable is generated as a block output variable of a switching block that toggles between multiple signals, or of a merging block that merges multiple signals. Alternatively or additionally, the output variable preferably has no fixed lifetime, allowing it to be automatically adjusted. The switching block can, in particular, be a switch block, wherein switch blocks have two or more inputs (switch blocks with multiple inputs are also referred to as multiport switches). The merging block can be a merge block, which, in particular, merges signals from multiple if-action subsystems. Thus, the value of the output variable results from a conditional control flow, or, if the activation of different subsystems occurs via preprocessor ifs, from conditional compilation.Two parallel control flow branches, in this context, refer specifically to code patterns consisting of two parallel rows of blocks with signal connections, which converge in a common block that selects or outputs one of the signals. Similarly, there can be a larger number of parallel control flow branches in which signals or variable values ​​are calculated and passed on independently. In a common block, all signals or variables from the control flow branches are received, and one of the signals is selected or output. Such a model situation can result, for example, in an If-Then-Else code structure or several nested If-Then-Else code structures.In this process, the respective source variable may be copied directly into the output variable in the various branches, or the respective source variable may be copied into a respective target variable, with the respective target variable then being copied into the source variable. AZ: 24-030-DE - 6 - 30.10.2024.

[0017] Preferably, an output variable is replaced by a pointer only if the output variable meets a size criterion, in particular if it exceeds a minimum size. By checking whether the output variable is larger than a pointer or exceeds a predefined minimum size, replacement can be avoided if it is not expected to reduce stack usage, runtime, and / or code size. The dereferencing required for pointers could also lead to increased program runtime in such cases, whereas it is negligible for large output variables.

[0018] The size criterion is particularly advantageous when the number of components of the output variable exceeds a dimension threshold and / or when the memory consumption of the output variable exceeds a size threshold. For vectors in particular, it can be useful to compare the number of elements or components of the vector with an integer dimension threshold. Alternatively or additionally, it may be possible to compare the memory consumption of the output variable with a size threshold that specifies a number of bytes; this can be particularly useful when a structure comprises few components but has a high memory consumption due to the size of those components.

[0019] Preferably, a regular value copy is assumed to occur in a control flow branch if the value of the multi-component target variable or the output variable results from a direct assignment that involves variable access to an addressable memory area, and if a value is assigned to each component of the target variable. A regular value copy can be performed, particularly in C, by a single direct assignment, multiple direct assignments, or using the `memcpy` function. A corresponding model situation exists, for example, when a first block completely forwards a signal to a second block, which then outputs it. Thus, the block output variable of the second block can be replaced by a pointer to the block output variable of the first block because the second block's output variable is completely written. AZ: 24-030-DE - 7 - 30.10.2024

[0020] According to a preferred embodiment of the invention, at least one optimization was applied to the intermediate representation before carrying out the method according to the invention. Replacing an output variable with a pointer can potentially complicate further optimizations and therefore preferably takes place after the intermediate representation has already been optimized using other methods.

[0021] According to a particularly preferred embodiment of the invention, applying at least one optimization to the intermediate representation includes checking for the presence of a code pattern in which several parallel control flow branches write a variable, with the variable subsequently being accessed in an operation. If the code pattern is present, a check is performed to ensure that a cost criterion is met, in which case the operation is moved from its original location to the locations where the variable was written. To reduce stack consumption, particularly with multi-component block output variables, operations can preferably be moved to control flow branches, provided that the preconditions, such as a sufficiently small code size for the operation, are met. By subsequently performing the optimization according to the invention, the stack consumption can be reduced for a multitude of further model situations.Code patterns where a shift was not possible will be reduced.

[0022] In embodiments of the invention, a check is performed to determine whether the lifetime of at least one source variable would need to be increased due to the replacement of the output variable with a pointer. If so, optimization is omitted if the size of the at least one source variable exceeds that of the output variable to be saved. The size can be compared based on the number of components of the variable and / or the memory consumption of the variable. The inventive replacement of an output variable with a pointer to a source variable leads to increased execution speed in almost all cases and can therefore also be advantageous when data flow relationships necessitate an increase in the lifetime of a source variable—which results in it remaining on the stack for a longer period. In cases where stack consumption is more important than execution speed, optimization can be omitted.

[0023] It is useful for the user to specify whether a check AZ: 24-030-DE - 8 - 30.10.2024 should be performed to assess increased stack consumption resulting from adjustments to the variable scope. This allows for an analysis of the variable dimensions: If one of the source variables is part of a larger overall variable, an increase in stack consumption can be expected because the memory requirement of the overall variable exceeds that of the potentially saved output variables.

[0024] Preferably, if a source variable is equipped with a data type qualifier, the optimization is only performed if the use of the output variable is compatible with the data type qualifier. The data type qualifier can be, in particular, "const", indicating that a value remains constant. In this case, the use of the output variable must also occur in an operation that is equipped with or compatible with the data type qualifier "const"—otherwise, a copy from the source variable with the data type qualifier to an intermediate variable without this data type qualifier must be performed, and the optimization is not applicable. Use of the output variable could, for example, include using its value in a function call or a calculation.

[0025] It is expedient to check whether, for all control flow branches, no write operation to the source variable occurs between the write operation to the respective target variable or the output variable and the subsequent use of the resulting output variable. Because no multiple write operations occur in the section of instructions relevant for optimization, the optimization according to the invention with selection pointers does not lead to undesirable changes in the data flow.

[0026] The invention further relates to a method for configuring a control unit, wherein the control unit comprises at least one processing unit and preferably at least one sensor and / or at least one actuator for acquiring data from a physical process and / or acting upon it. The method comprises the steps a. reading a block diagram, b. generating source code using a method according to the invention, AZ: 24-030-DE - 9 - 30.10.2024, c. compiling the source code for the processing unit so that executable code is generated, d. transferring the executable code to the control unit, and e. storing the executable code in non-volatile memory of the control unit and / or executing the executable code by the processing unit of the control unit.

[0027] Furthermore, the invention relates to a computer program product with a computer-readable storage medium, in particular a non-volatile data storage medium, on which instructions are embedded which, when executed by a processor, cause the processor to be configured to execute a method according to the invention.

[0028] Furthermore, the invention relates to a computer system comprising a human-machine interface, a non-volatile memory and a processor, wherein the processor is configured to execute a method according to the invention.

[0029] The invention is explained in more detail below with reference to the drawings. Similar parts are labelled with identical designations. The illustrated embodiments are highly schematic; that is, the distances and the lateral and vertical dimensions are not to scale and, unless otherwise indicated, do not exhibit any derivable geometric relationships to one another.

[0030] It shows:

[0031] Figure 1 shows a preferred embodiment of a computer system,

[0032] Figure 2 is a schematic representation of the preferably on a

[0033] computer system existing software components

[0034] Figure 3 shows a schematic flowchart of an embodiment of the inventive method for generating source code,

[0035] Figure 4 shows a block diagram with parallel control flow branches and runtime selection, and

[0036] Figure 5 shows a block diagram with parallel control flow branches and compile-time selection. AZ: 24-030-DE - 10 - 30.10.2024

[0037] Figure 1 shows an exemplary embodiment of a PC computer system. This system comprises a CPU processor, which can be implemented as a multi-core processor, RAM, and a bus controller. Preferably, the PC computer system is designed for direct manual operation by a user, with a monitor (DIS) connected via a graphics card (GPU) and a keyboard (KEY) and mouse (MOU) connected via a peripheral interface (HMI). In principle, the human-machine interface of the PC computer system could also be a touch interface. The computer system further includes a non-volatile data storage device (HDD), which can be implemented as a hard disk and / or solid-state drive (SSD), and a network interface (NET). A control unit (ES) can be connected via the network interface.In principle, one or more interfaces, especially wired interfaces, can be present on the PC computer system and each can be used for connection to a control unit ES. A network interface according to the Ethernet standard can be used expediently; the NET interface can also be implemented wirelessly, such as a WI_AN interface or according to a standard like Bluetooth.

[0038] The control unit ES can be implemented as a series control unit or as an evaluation board for a target platform. It expediently includes a NET interface for connection to the computer system (PC), a microcontroller (MCR) with an architecture different from that of the computer system's processor, RAM, and NVM non-volatile memory. With the ES control unit present, a processor-in-the-loop simulation of the generated code can preferably be performed.

[0039] Figure 2 shows a diagram of the software components preferably installed on the PC computer system. These use mechanisms of the operating system (OS) to, for example, access the non-volatile hard drive (HDD) or establish a connection to an external computer via the network interface (NET).

[0040] A Technical Computing Environment (TCE) enables the creation of models and the generation of source code from these models. In a modeling environment MOD AZ: 24-030-DE - 11 - 30.10.2024, models of a dynamic system can preferably be created via a graphical user interface. These models can be, in particular, block diagrams comprising multiple blocks and describing the temporal behavior and / or internal states of a dynamic system. At least some of the blocks are connected by signals, i.e., directed connections for the exchange of data, which can be scalar or composite. Blocks can be atomic, meaning they form a single unit from the perspective of the surrounding blocks, where all input signals must be present at the beginning of a computation step and all output signals must be present at the end of a computation step.

[0041] When block diagrams are hierarchical, a multitude of blocks at a lower level can describe the structure of a block at a higher level. Hierarchical or composite blocks, even if atomic, can contain a multitude of blocks at a lower level. Composite blocks can, in particular, be subsystems; subsystems can have additional properties, such as being implemented in a separate function and / or having their execution triggered by a dedicated signal. Special blocks can be arranged within subsystems to further specify their properties. The computational environment (TCE) includes one or more libraries (BIB) from which blocks, or building blocks, can be selected to construct a model. In a scripting environment (MAT), instructions can be entered interactively or via a batch file to perform calculations or modify the model.The TCE computing environment also includes a SIM simulation environment, which is configured to interpret and execute the block diagram in order to investigate the system's temporal behavior. These calculations are preferably performed using high-precision floating-point numbers on one or more cores of the computer system's CPU microprocessor.

[0042] From a created model, source code, preferably in a programming language like C, can be generated using a code generator (PCG). Additional information about the model, especially the block variables, is usefully stored in a definition data set (DDT). Value ranges and / or scales are usefully assigned to the block variables to enable calculations of the model using fixed-point arithmetic. AZ: 24-030-DE - 12 - 30.10.2024

[0043] To support instructions, the Definition Data Collection (DDT) can be used. Desired source code properties, such as compliance with a standard like MISRA, can also be configured or stored in the DDT. It is advantageous for each block variable to be assigned a predefined variable type, and one or more desired properties, such as the permissibility of optimizations like variable merging, are set. The Code Generator (PCG) preferably evaluates the settings of the DDT and takes them into account when generating the source code. The DDT can have a tree structure or be stored as a simple file in the computer system's memory; alternatively, it can be intended that the definition data be stored in a dedicated database system. The DDT can have a program interface and / or import / export functions.

[0044] The PC computer system includes a COM compiler and a LIN linker, which are conveniently configured to generate executable binaries on an ECU and / or the PC computer system. In principle, multiple compilers can be present, particularly cross-compilers for different target platforms to support ECUs or evaluation boards with different processor architectures.

[0045] Figure 3 shows a schematic flowchart of an embodiment of the inventive method for generating source code. The method can be executed entirely by a processor of an exemplary implementation of the PC computer system; however, it can also be designed for execution in a client-server environment with an operator computer and one or more servers connected via a network, with computationally intensive steps being performed on the servers.

[0046] In step S1 (read block diagram), a block diagram is read in. The block diagram comprises at least two processing blocks connected by signals and can contain a large number of additional blocks. Advantageously, reading the block diagram also includes reading at least one block property and / or settings relevant for code generation, such as, for example, the data type of a variable from the definition data set DDT (AZ: 24-030-DE - 13 - 30.10.2024).

[0047] In step S2 (Transform into Intermediate Representation), the selected model is transformed from one or more blocks of the block diagram into an intermediate representation, preferably comprising one or more hierarchical graphs. This can be, in particular, a data flow graph, a control flow graph, or a tree structure. In addition to the block diagram, supplementary information from a definition data set (DDT) is also expediently considered or incorporated into the generation of the intermediate representation. This can also include situations in which elements are created based on information in the definition data set (DDT), or in which properties of elements or settings relevant for code generation, such as the data type of a variable, are extracted from the definition data set (DDT).

[0048] In step S3 (optimization of the intermediate representation), the hierarchical graphs of the intermediate representation are optimized to reduce the number of required variables, memory consumption, the number of operations or processor instructions, and / or the execution time of the source code. This optimization may involve several intermediate steps in which further intermediate representations between the model / block diagram and the source code / program text are generated. Specifically, each intermediate step may involve converting a set of original hierarchical graphs into a different set of modified hierarchical graphs, applying one or more optimization rules.

[0049] Various strategies, such as constant folding or dead code elimination, can be applied during the initial optimization of the intermediate representation. It is advantageous to check for the presence of a model situation in which multiple parallel control flow branches write a variable, which is then accessed in an operation. If this model situation exists, a cost criterion should be checked, in which case the operation is moved from its original location to the locations where the variable was written (e.g., AZ: 24-030-DE - 14 - 30.10.2024). Such a relocation of the operation is beneficial if the size of the corresponding code remains below a predefined threshold—which can be verified by checking whether the cost criterion is met. This optimization allows for a particularly significant reduction in stack consumption but is not recommended in many models.The method is not applicable to certain code situations. In such situations, such as nested conditional control flows, the method according to the invention can achieve a reduction in stack consumption and / or an increase in execution speed.

[0050] In step S4 (parallel branches?), it is checked whether there are further groups of operations with parallel control flow branches where optimization by using selection pointers is possible. In particular, this could involve the selection of a signal or a multi-component variable at runtime or during code generation or compilation.

[0051] In the description of Figure 4 and Figure 5 and the following listings, exemplary groups of operations are presented and explained for which an optimization according to the invention can be carried out.

[0052] If there is a previously unconsidered group of operations that is in principle suitable for optimization, step S5 follows; otherwise, execution continues in step S7 to translate the intermediate representation into source code.

[0053] In step S5 (Regular Copy?), it is checked whether a regular copy exists from a source variable to a target variable, where the target variable is specifically the output variable of the group of operations with parallel control flow branches. This check can be performed, for example, by verifying the following conditions for all control flow branches:

[0054] • A write access to the target variable or the output variable takes place as a direct assignment, on the right side of which there is a variable access to addressable memory.

[0055] • The target variable or the output variable is completely written by the write access. The source variable can be part of a larger variable; that is, the source variable can be a structural component, a row of a matrix, or an element of a matrix of structures. AZ: 24-030-DE - 15 - 30.10.2024

[0056] • The target variable or the output variable has an automatic storage duration, or it could have one because a write access precedes every read access to the target variable. If the potential target variable represents a state, replacing it with a pointer can cause faulty code, which is why the state variable must be preserved.

[0057] Replacing the target or output variable with a pointer does not change the data flow. Such a change could occur, for example, due to a branch in the data flow, such as a change in the execution order of the blocks. From a code perspective, a write operation to the output variable between copying the source variable and using the output variable would result in a data flow error.

[0058] • If the source variable has a data type qualifier, in particular “const”, then the operations that use the output variable also have the data type qualifier or are compatible with it.

[0059] As part of the check to see if a regular copy exists, further additional conditions can also be checked. In particular, it can be checked whether the output variable fulfills a size criterion by exceeding a minimum size. This ensures that variables smaller than a pointer would be are not replaced.

[0060] If the checked conditions, such as the existence of a regular copy, are met, then step S6 follows; otherwise, execution continues in step S4 to check for the presence of further optimizable groups of operations.

[0061] If a regular copy exists, in step S6 (Replace with pointer to source variable) the output variable is replaced by a pointer to one of the source variables. In each control flow branch, the pointer is assigned the address of the source variable occurring in that branch.

[0062] The execution then continues in step S4 to process further potentially suitable groups of operations. AZ: 24-030-DE - 16 - 30.10.2024

[0063] In step S7 (Translate intermediate representation into source code), the optimized intermediate representation is translated into source code of a textual programming language, such as C code. Further optimization can also occur in this step, particularly by ensuring that the generated instructions represent a subset of the instructions inherently included in the language and / or that the generated control structures represent a subset of the control structures inherently included in the language. This allows for the fulfillment of precisely defined rules. Alternatively or additionally, it may be possible to generate supplementary information, such as a relationship between a program line and a block in the block diagram, and to integrate this information into the source code, especially in the form of comments, to improve the readability of the source code and / or simplify debugging.

[0064] During or after code generation, information about the current block diagram or code generation results, such as warnings, can be stored in the definition data collection. This information can be used, for example, to influence the compilation of the generated source code or to provide metadata for other tools, such as calibration information in ASAP2 format or information for generating an intermediate layer according to the AUTOSAR standard. In alternative embodiments of the invention, it may be possible to generate code in a hardware description language or a configuration of a programmable hardware component from the block diagram.

[0065] Exemplary embodiments of the invention are explained below.

[0066] Figure 4 shows a block diagram illustrating the selection of a signal from parallel control flow branches at runtime.

[0067] A signal containing a multi-component variable, Structln, is received via a first input port. A Boolean component, IsValid, is selected using a selector and then fed to a selection input of a switching block, ValidStruct. The switching block ValidStruct receives the signal Structln at its first input and an AZ: 24-030-DE - 17 - 30.10.2024 at its second input.

[0068] Signal fallback from a data store read block. If the `IsValid` component is true, the `Structln` signal is output at the first input; otherwise, the fallback signal from the other input is output. The output of the `ValidStruct` switching block is fed to a selector that outputs a `payload` component of the received signal.

[0069] The selector's output is connected to two static selection blocks, each of which is connected to the first and second inputs of a switching block called SelectedRow. A signal called Index is received via a second input port and fed to the Index input of the first static selection block. This Index signal is then fed to a subsystem called isInRange, which can check whether the Index value lies within a predefined range. A Boolean output signal, isInRange, from this subsystem is fed to the selection input of the switching block called SelectedRow. This selects either the column of the payload component selected by the Index signal or a predefined column of the same payload component from the original input signal, and this value is then output to the switching block called SelectedRow. The output signal of SelectedRow is converted into a vector and fed to the first input of a subsystem called WeightedProduct.A third input port receives a signal Vecln and feeds it to a second input of the WeightedProduct subsystem. The subsystem processes the input signals and outputs a vector signal WeightedProduct, which is displayed via an output port VecOut.

[0070] Without optimization according to the present invention, the source code shown in Listing 1 would be generated from the block diagram.

[0071] Listing 1 - Signal selection without optimization: void Selectionpointers ( const ParStruct_t * Structln, const Intl 6 Index, const Float32 Vecln

[0008] , Float32 VecOut

[0008] ) {

[0072] Float32 SelectedRow

[0008] ;

[0073] ParStruct_t ValidStruct ;

[0074] Int32 Aux_S32 ; if (StructIn->isValid) { ValidStruct = *StructIn;

[0075] } iron { AZ: 24-030-DE - 18 - 30.10.2024

[0076] ValidStruct Fallback;

[0077] } if ( (Index >= 0) && (Index < ( (Intl6) 5) ) ) { for (Aux_S32 = 0; Aux_S32 < 8; Aux_S32++) { SelectedRow [Aux_S32 ] = ValidStruct . payload [ Index] [Aux_S32] ;

[0078] }

[0079] } else { for (Aux_S32 = 0; Aux_S32 < 8; Aux_S32++) { SelectedRow [Aux_S32 ] = ValidStruct . ayload

[0000] [Aux_S32] ;

[0080] }}

[0081] WeightedProduct ( SelectedRow, Vecln, VecOut) ;

[0082] }

[0083] For both the ValidStruct and SelectedRow switching blocks, a block output variable is created, which, due to the signal dimensions, requires a significant amount of memory on the stack. Furthermore, depending on the signal present at the SelectedRow selection input, a copy operation in the form of a for loop must be performed, which increases the program's runtime.

[0084] Listing 2 shows source code optimized according to a method according to the invention.

[0085] Listing 2 - Signal selection with selection pointer: void Selectionpointers ( const ParStruct_t * Structln, const Intl6 Index, const Float32 Vecln[8] , Float32 VecOut[8] ) { const Float32 * pSelectedRow; / * Points to Float32 [8] * / const ParStruct_t * pValidStruct; if (StructIn->isValid) { pValidStruct = Structln;

[0086] } else { pValidStruct = &Fallback;

[0087] } if ( (Index >= 0) && (Index < ( (Intl6) 5) ) ) { AZ: 24-030-DE - 19 - 10 / 30 / 2024 pSelectedRow = pValidStruct->payload [ Index] ;

[0088] } else { pSelectedRow = pValidStruct->payload

[0000] ;

[0089] }

[0090] WeightedProduct (pSelectedRow, Vecln, VecOut ) ;}

[0091] According to the inventive method, the block output variables of the switching blocks ValidStruct and SelectedRow were each replaced by a pointer to a multi-component variable.

[0092] An optimization according to the present invention is also applicable in the case of a preprocessor control flow, as illustrated in the block diagram of Figure 5. A scalar signal ul is received via an input port InPortl and fed to the input of a preprocessor IF block, which outputs three signals. If ul = 0 (false), a first activation signal is output, which can trigger a first activatable subsystem if(~u 1). If ul > l, a second activation signal is output, which can trigger a second activatable subsystem elseif(ul > l). Otherwise, a third activation signal is output, which can trigger a third activatable subsystem else(). The first activatable subsystem receives a signal from input port Buslnport, the second activatable subsystem receives a signal from input port Buslnport3, and the third activatable subsystem receives a signal from input port Buslnport4.When one of the subsystems is activated, it forwards the incoming bus signal to its output. The outputs of the three activatable subsystems are connected to a merge block, which outputs a bus signal. Depending on the activated subsystem, this signal can be the bus signal present at BusInport, BusInport3, or BusInport4.

[0093] The output of the merge block is connected to a first selector and a first input of a switching block. The first selector selects components a and b of the bus signal and forwards component a to a first summing block and component b to a second summing block. The selection input of the switching block is connected to input port Inport2, and the second input of the switching block is connected to input port Buslnportl. Depending on whether the signal received via Inport2 is true or false, the switching block outputs either the bus signal received from the merge block or the bus signal received via Buslnportl. The output of the switching block is connected to a second selector. The second selector selects components a and b of the bus signal received by the switching block and forwards component a to a first summing block and component b to a second summing block.Thus, the first summation block calculates the sum of the received components a, and the second summation block calculates the sum of the received components b. The respective result is output by the first summation block via output port OutPort and by the second summation block via output port OutPortl.

[0094] Without optimization according to the present invention, the source code shown in Listing 3 would be generated from the block diagram.

[0095] Listing 3 - Preprocessor control flow without optimization: void tlss (void) {

[0096] StructWithVecComp Sal_Switch;

[0097] StructWithVecCornp Sal_Merge ;

[0098] #if ! ( Sal_InPortl )

[0099] Sal_Merge = Sal_Bus_Inport ;

[0100] #eli f Sal_InPortl > 1

[0101] Sal_Merge = Sal_Bus_Inport3 ;

[0102] #else

[0103] Sal_Merge = Sal_Bus_Inport4 ;

[0104] #endi fif ( Sal_InPort2 >= 0 ) {

[0105] Sal_Switch = Sal_Merge ;

[0106] } else {

[0107] Sal_Switch = Sal_Bus_Inportl ;

[0108] }

[0109] Sa l_Out Porti

[0110] Sal_OutPort = AZ: 24-030-DE - 21 - 30.10.2024

[0111] The block output variables Sal_Merge and Sal_Switch cause significant stack consumption. By replacing these intermediate memory variables Sal_Merge and Sal_Switch with pointers, stack consumption can be reduced. The optimized source code is shown in Listing 4.

[0112] Listing 4 - Preprocessor control flow with selection pointer: void tlss (void) { const StructWithVecComp * pSal_Merge; const StructWithVecComp * pSal_Switch;

[0113] #if! ( Sal_InPortl ) pSal_Merge = &Sal_Bus_Inport;

[0114] #elif Sal_InPortl > 1 pSal_Merge = &Sal_Bus_Inport3 ;

[0115] #else pSal_Merge = &Sal_Bus_Inport4 ;

[0116] #endif if (Sal_InPort2 >= 0) { pSal_Switch = pSal_Merge;} else { pSal_Switch = &Sal_Bus_Inportl ;

[0117] }

[0118] Sal_OutPortl = (Intl6) ( ( (UIntl6) pSal_Merge->b) + ( (UIntl6) pSal_Switch->b) ) ; Sal_OutPort = (Intl6) ( ( (UIntl6) pSal_Merge->a) + ( (UIntl6) pSal_Switch->a) ) ;

[0119] }

[0120] By replacing value copies with selection pointers, savings in stack consumption and execution time are possible.

Claims

AZ: 24-030-DE - 22 - 30.10.2024 Patent claims:

1. A method for generating source code from one or more blocks of a block diagram, which includes blocks and signal connections between blocks, wherein the generation of source code comprises transforming the block diagram into an intermediate representation, successively optimizing the intermediate representation, and translating the optimized intermediate representation into source code, wherein the transformation of a block comprises creating a block output variable, comprising the steps • Detect at least two parallel control flow branches, each copying a multi-component source variable to an output variable, verify that all parallel control flow branches perform a regular value copy from one of the source variables to the output variable, and • Replacing the output variables with a pointer to one of the source variables.

2. A method for generating source code according to claim 1, wherein the output variable was generated as a block output variable of a toggle block that switches between multiple signals or of a merge block that merges multiple signals and / or wherein the output variable does not have a defined lifetime.

3. A method for generating source code according to any of the preceding claims, wherein the multi-component variable is a vector comprising a plurality of variables of the same data type, a matrix comprising a plurality of vectors, a structure comprising a plurality of variables of any data type, a vector of structures, or a matrix of structures.

4. Method for generating source code according to one of the preceding claims, wherein the replacement of an output variable by a pointer only takes place if the output variable meets a size criterion, in particular exceeds a minimum size. AZ: 24-030-DE - 23 - 30.10.2024 5. Method according to claim 4, wherein the size criterion is met if the number of components of the output variable exceeds a dimension threshold and / or if the memory consumption of the output variable exceeds a size threshold.

6. A method according to any of the preceding claims, wherein a regular value copy from a source variable to a target variable is performed when the value of the target variable results from a direct assignment that includes variable access to an addressable memory area, and when a value is assigned to each component of the target variable.

7. Method according to one of the preceding claims, wherein at least one optimization was applied to the intermediate representation before carrying out the method according to the invention.

8. Method according to claim 7, wherein applying at least one optimization to the intermediate representation comprises checking for the presence of a code pattern in which several parallel control flow branches write a variable, the variable being subsequently accessed in an operation, and, if the code pattern is present, checking for compliance with a cost criterion, wherein in that case the operation is moved from the original location to the locations where the variable was written.

9. A method for generating source code according to one of the preceding claims, wherein a check is performed to determine whether the lifetime of at least one source variable would have to be increased due to the replacement of the output variable by a pointer, and wherein in this case the optimization is omitted if the size of the at least one source variable exceeds the size of the output variable to be saved.

10. Method for generating source code according to one of the preceding claims, wherein, in the case that a source variable is provided with a data type qualifier, the optimization is only performed if AZ: 24-030-DE - 24 - 30.10.2024 the use of the output variable is compatible with the data type qualifier.

11. Method for generating source code according to one of the preceding claims, wherein a check is performed to ensure that no write operation to the source variable takes place for all control flow branches between the write operation to the output variable and the subsequent use of the resulting output variable.

12. A method for configuring an electronic control unit (ECU), wherein the ECU comprises at least one processing unit and preferably at least one sensor and / or at least one actuator for acquiring data from a physical process and / or acting upon it, the method comprising the steps a. reading a block diagram, b. generating source code using a method according to any of the preceding claims, c. compiling the source code for the processing unit to generate executable code, d. transferring the executable code to the ECU, and e. storing the executable code in non-volatile memory of the ECU and / or executing the executable code by the processing unit of the ECU.

13. Computer program product comprising a computer-readable storage medium, in particular a non-volatile storage medium, on which instructions are embedded which, when executed by a processor, cause the processor to be configured to execute a method according to any of the preceding claims.

14. Computer system comprising a human-machine interface, non-volatile memory and a processor, wherein the processor is configured to execute a method according to any of the preceding claims.

Images