Specification-based toolkit generation method and toolkit generation program
Patent Information
- Application Number
- PCT/KR2026/003544
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-04-15
- Filing Date
- 2026-03-05
- Publication Date
- 2026-10-22
Smart Images
Figure KR2026003544_22102026_PF_FP_ABST
Abstract
Description
Spec-based toolkit creation method and toolkit creation program
[0001] The present disclosure relates to a method for generating a toolkit and a program for generating a toolkit. More specifically, the present disclosure relates to a specification-based method for generating a toolkit and a program for generating a toolkit designed to reduce software development costs and improve development speed.
[0002] Network on Chip (NoC) is a core communication technology in high-performance semiconductor designs, such as Multiprocessor System on Chip (MPSoC), and is used to efficiently exchange data between multiple computing nodes and devices (processors, memory, I / O interfaces, etc.) within the chip.
[0003] This technology emerged to overcome the limitations of existing bus-based communication structures and plays an important role in systems requiring parallel computing and high-speed data transmission.
[0004] The specifications of the NoC (Network on Chip) product can be configured as shown in Fig. 1.
[0005] A specification is a document that defines the settings and configurations of the various hardware elements that make up a NoC product. Based on the written specification, the process of implementing the hardware elements and software of the NoC product is required. The types of hardware elements are diverse, including Router, Network Interface (NI), Arbiter, Decoder, PMU, Event Monitor, AXI-5 Port, AXI-4 Port, etc.
[0006] The hardware settings and configuration of each hardware element may include the following:
[0007] 1. Parameters constituting the hardware element
[0008] 2. Characteristics of each parameter (type, constraint, default, etc.)
[0009] The setup and configuration of these hardware elements can vary significantly depending on the objectives of the NoC product. For example, when the product lineup consists of a NoC product targeting mobile devices (a), a NoC product targeting autonomous vehicles (b), and a NoC product targeting high-performance servers (c), power consumption and area constraints become less restrictive as one moves from (a) to (c), while high performance is required instead.
[0010] For example, parameters such as data width or buffer size have their constraints and default values set larger as one moves from (a) to (c). Additionally, if a customer requests the addition of new features or some customization, the specifications of the product must be modified; in this case, new parameters may be added for each product to implement specific functions.
[0011] NoC hardware engineers write the architecture description of the NoC, which consists of these hardware elements, reflecting the client's requirements. Subsequently, NoC software engineers develop and manage a software toolkit that takes the specifications and architecture description as input to generate IP deliverables (RTL, testbenches, etc.).
[0012] Meanwhile, since each hardware element has thousands of parameters, it is impossible for a hardware engineer to configure them individually; therefore, the setting and optimization of parameter values based on the structure and relationships of the architecture description are performed by a software toolkit.
[0013] An example of a method for developing and managing a software toolkit is illustrated in Fig. 2.
[0014] Referring to Fig. 2, assuming that a company has first released a NoC product for mobile devices (NoC product #1 toolkit in Fig. 2), the toolkit sets parameters such as buffer size, multiple outstanding values, and data width according to the specifications. Subsequently, when a customer wants to increase the buffer size and data width of the product—that is, when they want to change the functionality—hardware engineers must modify the constraints and default values of the specifications, and software engineers must change the logic for setting the buffer size and data width of the toolkit.
[0015] Alternatively, this client may request the addition of new features to the product, in addition to modifications to existing functions. For example, the client may want to add functional safety features, as illustrated in Fig. 2, to ensure safe operation even in the event of a product system error. In such cases as well, hardware engineers must define the added features and design the logic, while software engineers must modify internal scripts or code to enable the toolkit to configure the new features. (Change to the NoC Product #1-1 toolkit in Fig. 2)
[0016] Next, if this company intends to launch a NoC product for high-performance servers (NoC Product #2 toolkit in Fig. 2), high-performance servers have fewer constraints on area and power consumption than mobile devices, but require high bandwidth and minimal latency for high performance. Therefore, the parameters of the specifications must be significantly modified (buffer size, multiple outstanding, data width), parameters for new features (atomic transaction, QoS) must be added, and sometimes existing features must be removed (functional safety). Software engineers must also significantly modify the toolkit accordingly.
[0017] In other words, since adding, modifying, or removing features from a product involves the process of reconfiguring and verifying all software included in the toolkit, the NoC software toolkit ecosystem becomes highly complex and difficult to manage in an integrated manner as client requests for feature additions and customization increase and product lineups expand. This ultimately leads to the problem of increased development time.
[0018] While creating a single, massive integrated software toolkit capable of handling all specifications could be an alternative, this approach makes performance optimization difficult and inevitably results in slow execution speeds. Furthermore, as product specifications increase, the software becomes more complex, making it extremely difficult to add or modify features in the future.
[0019] One embodiment of the present disclosure aims to provide a toolkit generation method and a toolkit generation program that can automatically generate a toolkit optimized for a specification once the product specification is determined.
[0020] However, the problems to be solved in this disclosure are not limited to those mentioned above, and other unmentioned problems may be clearly understood based on the description below.
[0021] One embodiment of the present disclosure is a method for generating a toolkit executed on a computing device, comprising: a specification interpretation step of interpreting a Domain-Specific Language (DSL) containing a specification of a design target to extract required function and parameter values; a code block calling step of searching for and calling code blocks to perform the function required by the specification in a code library in which code blocks for implementing the function are stored; a code block organizing step of organizing the execution order of the code blocks; and a code block assembly step of assembling the organized code blocks to finally generate the toolkit.
[0022] Alternatively, the code library may store specification-dependent code blocks for implementing each function required by the specification.
[0023] Alternatively, the above DSL may include a field defined to call a code block stored in the code library.
[0024] Alternatively, the code block assembly step may integrate the core logic of the toolkit with the code blocks organized in the code block cleanup step.
[0025] Alternatively, the core logic may include specification-independent code blocks related to parameters or logic that are commonly used regardless of the specification.
[0026] One embodiment of the present disclosure is a computer program stored on a computer-readable storage medium, wherein the computer program is a toolkit generation program that operates to generate a toolkit based on specifications required by a design target, and the operation may include: a specification interpretation step of interpreting a Domain-Specific Language (DSL) containing specifications of the design target to extract required function and parameter values; a code block calling step of searching for and calling code blocks to perform the functions required by the specifications in a code library in which code blocks for implementing the functions are stored; a code block organizing step of organizing the execution order of the code blocks; and a code block assembly step of assembling the organized code blocks to finally generate a toolkit.
[0027] One embodiment of the present disclosure automatically generates a toolkit by receiving code blocks specified in the specification from a code library and combining them when a specification according to a defined DSL grammar is input. Accordingly, there is no need to store and manage multiple versions of the toolkit, thereby improving ease of management.
[0028] In addition, one embodiment of the present disclosure receives code blocks specified in the specification from a code library when a specification according to a defined DSL grammar is input, and combines these code blocks to immediately generate a toolkit optimized for the specification. Accordingly, there is an advantage in that the product development cycle is shortened and the scalability of the product is increased.
[0029] The effects of the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the description in the claims.
[0030] Figure 1 is a diagram showing the specifications of hardware elements constituting an existing NoC product and an example of these specifications written in DSL format.
[0031] Figure 2 is a diagram illustrating the development and management methods of existing software toolkits.
[0032] FIG. 3 is a block diagram of a computing device in which a toolkit generation method according to one embodiment of the present disclosure is executed.
[0033] FIG. 4 is a block diagram of a toolkit generator that performs each step of a toolkit generation method according to one embodiment of the present disclosure.
[0034] FIG. 5 is a flowchart showing the flow of a method for creating a toolkit according to one embodiment of the present disclosure.
[0035] FIG. 6 is a diagram illustrating specification-dependent code blocks stored in a code library in a toolkit generation method according to one embodiment of the present disclosure.
[0036] FIG. 7 is a diagram illustrating an example in which a NoC product specification targeting a mobile device is written in DSL format in a toolkit generation method according to one embodiment of the present disclosure, and is intended to explain the meaning of a field additionally defined in the DSL.
[0037] FIG. 8 illustrates an example in which NoC product specifications targeting high-performance servers are written in DSL format in a toolkit generation method according to one embodiment of the present disclosure.
[0038] Embodiments of the present disclosure are described below with reference to the attached drawings so that those skilled in the art (hereinafter, those skilled in the art) can easily implement them. The embodiments presented in the present disclosure are provided to enable those skilled in the art to use or implement the contents of the present disclosure. Accordingly, various modifications to the embodiments of the present disclosure will be apparent to those skilled in the art. That is, the present disclosure may be embodied in various different forms and is not limited to the embodiments below.
[0039] Throughout the specification of the present disclosure, identical or similar reference numerals refer to identical or similar components. Additionally, to clearly explain the present disclosure, reference numerals in the drawings that are unrelated to the description of the present disclosure may be omitted.
[0040] The term “or” as used in this disclosure is intended to mean an implicit “or” rather than an exclusive “or.” That is, unless otherwise specified in this disclosure or its meaning is not clear from the context, “X uses A or B” should be understood to mean one of the natural implicit substitutions. For example, unless otherwise specified in this disclosure or its meaning is not clear from the context, “X uses A or B” may be interpreted as X using A, X using B, or X using both A and B.
[0041] The term “at least one of A or B” as used in the present disclosure should be interpreted as referring to A, B, and combinations of A and B.
[0042] The term “and / or” as used in this disclosure should be understood to refer to and include all possible combinations of one or more of the enumerated related concepts.
[0043] The terms “comprising” and / or “comprising” as used in this disclosure should be understood to mean the presence of certain features and / or components. However, the terms “comprising” and / or “comprising” should be understood not to exclude the presence or addition of one or more other features, other components and / or combinations thereof.
[0044] Where not otherwise specified in the present disclosure or where it is not clear from the context that the singular form indicates, the singular should generally be interpreted as including “one or more.”
[0045] The term “the N (N is a natural number)” used in this disclosure may be understood as an expression used to distinguish the components of this disclosure from one another according to certain criteria, such as functional perspectives, structural perspectives, or convenience of explanation. For example, components performing different functional roles in this disclosure may be distinguished as a first component or a second component. However, components that are substantially identical within the technical scope of this disclosure but must be distinguished for the convenience of explanation may also be distinguished as a first component or a second component.
[0046] Meanwhile, the terms "module" or "unit" used in this disclosure may be understood as referring to an independent functional unit that processes resources, such as a computer-related entity, firmware, software or a part thereof, hardware or a part thereof, or a combination of software and hardware. In this case, "module" or "unit" may be a unit composed of a single element, or a unit expressed as a combination or set of multiple elements. For example, in a narrow sense, "module" or "unit" may refer to a hardware element of a device or a set thereof, an application program that performs a specific function of software, a procedure implemented through software execution, or a set of instructions for program execution. Furthermore, in a broad sense, "module" or "unit" may refer to the device itself or the program itself executed on the device. However, since the above-described concepts are merely examples, the concepts of "module" or "unit" may be defined in various ways within a scope understandable to those skilled in the art based on the content of this disclosure.
[0047] The term “connection” as used in the present disclosure should be interpreted to include not only cases where the components are “directly connected,” but also cases where other components are “present” in between, and cases where they are “electrically connected” with other components in between.
[0048] The explanation of the foregoing terms is intended to aid in understanding the present disclosure. Accordingly, it should be noted that unless a foregoing term is explicitly stated as a matter limiting the content of the present disclosure, it is not to be used in the sense of limiting the technical concept of the content of the present disclosure.
[0049] FIG. 3 is a block diagram of a computing device in which a toolkit generation method according to one embodiment of the present disclosure is executed.
[0050] The computing device (1) may include a processor (11) and memory (12).
[0051] The processor (11) can be understood as a configuration unit comprising hardware and / or software that reads a computer program (toolkit generation program) programmed with a toolkit generation method and performs operations. That is, the processor (11) can execute the toolkit generation program. Here, the toolkit generation program may refer to a program that generates an optimized toolkit based on a Spec.
[0052] The processor (11) can perform each step of the toolkit generation method according to an embodiment of the present disclosure to be described below. The toolkit generator (100) to be described below may be composed of software components that perform each step of the method of generating a toolkit. Specifically, the toolkit generator (100) can generate an executable toolkit by interpreting the specifications of a design target written in an input Domain-Specific Language (DSL), searching for and calling code blocks from a code library to perform the functions required by the specifications, coordinating the execution order, and finally assembling them. Each component of the toolkit generator (100) may be responsible for steps such as interpreting the DSL, calling code blocks, coordinating the execution order, and assembling code blocks during this generation process.
[0053] The processor (11) may include a Central Processing Unit (CPU), a General Purpose Graphics Processing Unit (GPGPU), a Tensor Processing Unit (TPU), an Application-Specific Integrated Circuit (ASIC), or a Field Programmable Gate Array (FPGA).
[0054] However, since the above-described type of processor (11) is merely an example, the type of processor (11) can be configured in various ways within a range understandable to those skilled in the art based on the contents of the present disclosure.
[0055] Memory (12) can be understood as a configuration unit including hardware and / or software for storing and managing data processed by the computing device (1). For example, memory (12) can store and manage data required to run a toolkit generation program on the computing device (1).
[0056] Memory (12) can store a toolkit generation program. Memory (12) can further store DSL specification data, code libraries, code blocks in execution, generated toolkits, etc.
[0057] For example, memory (12) can store DSL spec files, code library files, memory data of the running toolkit, code block cache and optimization data, etc.
[0058] The memory (12) may include at least one type of storage medium among flash memory type, hard disk type, multimedia card micro type, card type memory, RAM (random access memory), SRAM (static random access memory), ROM (read-only memory), EEPROM (electrically erasable programmable read-only memory), PROM (programmable read-only memory), magnetic memory, magnetic disk, and optical disk. Additionally, the memory (12) may include a database system that controls and manages data in a predetermined system. Since the above-described types of memory (120) are merely examples, the types of memory (12) may be configured in various ways within a range understandable to those skilled in the art based on the contents of this disclosure.
[0059] Memory (12) can also structure and organize data, combinations of data, and program code executable on the processor (11) that are necessary for the processor (11) to perform toolkit generation operations. For example, when the processor (11) interprets the DSL to generate a toolkit, a code block called from the DSL can be loaded into memory (12) and executed.
[0060] Hereinafter, a method for generating a toolkit that can be executed by the computing device (1) described above will be explained in detail with reference to the drawings from Fig. 4 onwards.
[0061] FIG. 4 is a block diagram of a toolkit generator performing each step of a toolkit generation method according to one embodiment of the present disclosure, and FIG. 5 is a flowchart showing the flow of a toolkit generation method according to one embodiment of the present disclosure.
[0062] Referring to FIGS. 4 and FIGS. 5, a toolkit generation method according to one embodiment of the present disclosure (hereinafter abbreviated as 'method') may include a specification analysis step (S100).
[0063] The specification interpretation step (S100) is a step of interpreting a DSL containing the specifications of the design target to extract the required function and parameter values.
[0064] Here, the design target can be the NoC architecture, a validator for the NoC architecture, a NoC compiler, etc.
[0065] Here, DSL refers to a language having grammar and rules optimized for a specific domain, and in the specification of the present disclosure, it serves the role of describing the specifications of the design target. Through this, components and parameters of hardware or software can be structured and expressed, and a toolkit generator (100) can interpret this to assemble optimal executable code. According to the present disclosure, the specifications must be written in accordance with the syntax of a predefined DSL.
[0066] The specification interpretation step (S100) can be performed by a DSL interpreter (110) of the toolkit generator (100). The DSL interpreter (110) receives a DSL containing the specifications of the design target and can verify whether the specifications comply with DSL grammar. The DSL interpreter (110) corresponds to a component that parses the written specifications to extract specification information necessary for generating the toolkit. The DSL interpreter (110) extracts specification information (function information, parameter value information, operation information, etc.) of the design target specified by the user through the DSL from the semantics of the DSL.
[0067] In other words, the specification interpretation step (S100) can be understood as a process of obtaining information such as the type, constraint, and default of each parameter defined in the specification (see Table 7).
[0068] For example, when a specification is written in an xlsx file based on DSL syntax, the xlsx file is stored in memory (12), and when the toolkit generator (100) is executed, the DSL interpreter (110) can load and interpret the file. The DSL interpreter (110) can interpret the xlsx file to extract specification information and load data using an xlsx parsing library (pandas, openpyxl, etc.). The DSL interpreter (110) can analyze each field according to the DSL syntax.
[0069] A method according to one embodiment of the present disclosure may include a code block call step (S200).
[0070] The code block calling step (S200) is a step of searching for and calling code blocks to perform the functions required by the specification from a code library in which code blocks for implementing various functions are stored.
[0071] FIG. 6 is a diagram illustrating specification-dependent code blocks stored in a code library in a toolkit generation method according to one embodiment of the present disclosure.
[0072] A code library refers to a repository in which code blocks for implementing functions required by a specification are stored. A toolkit generator (100) can automatically generate an executable program by interpreting the DSL, searching for and calling code blocks that match the specification from the code library, and assembling them.
[0073]
[0074] As illustrated in Fig. 6, specification-dependent code blocks can be stored in the code library by being broken down into individual functional units. In this case, a code block broken down into individual functional units refers to a block implemented as a function that can individually set each parameter or function defined in the DSL specification. However, the functional unit may vary depending on the programming language or implementation method used for software implementation, and classes, namespaces, etc., may serve as functional units. That is, based on the existing toolkit, the logic constituting the toolkit can be separated into specification-dependent logic and specification-independent logic. Here, specification-dependent logic refers to logic related to parameters whose values change as the specification changes, or logic for implementing functions required by individual specifications. For example, parameters such as buffer_size, data_width, and multiple_outstanding are variable according to customer requirements for each product family and correspond to specification-dependent logic.
[0075] Specification-dependent logic can be further divided into functions, which are the smallest functional units, and managed as code blocks within the code library. Functions for setting the buffer_size parameter can be managed as separate code blocks: set_buffer_mobile (for mobile device target products), set_buffer_mobile_1 (for mobile device target products customized by customer request), and set_buffer_hpc (for high-performance server target products). Similarly, functions for setting multiple outstanding parameters and data width parameters can also be managed as individual code blocks for each product.
[0076] In contrast, specification-independent logic does not need to be managed by dividing it into functional units (functions), as such logic is used commonly across all toolkits and does not change according to specifications. For example, logic related to error handling, logging, data input / output (IO), and execution flow control is essential for all toolkits to operate correctly; however, since it is logic related to functions unrelated to individual specifications, there is no need to divide it into functional units and store it in the code library.
[0077] That is, in the present disclosure, a code library may be understood to mean a set of modularized functional blocks containing specification-dependent code and specification-independent code.
[0078] As such, when specification-dependent code blocks are divided into individual functional units and stored in a code library for management as described in the present disclosure, if one wishes to change the buffer size setting method of a mobile device target product (Product #1), one simply needs to modify the code block set_buffer_mobile stored in the code library. Alternatively, if one wishes to customize the mobile device target product (Product #1-2) at the customer's request and change the buffer size setting method, one can simply add and save a new code block set_buffer_mobile_2 in the code library or modify an existing code block.
[0079] Furthermore, since the logic for each function is clearly separated in this structure, any addition of new features or removal of existing ones only requires modifying the code blocks corresponding to those functions. For example, if a functional safety feature is added at the request of a client, it can be easily implemented by searching for and calling the relevant code blocks—such as enable_functional_safety, set_safety_level, and set_secded—from the code library and assembling them into the existing toolkit.
[0080] In other words, there is an advantage in that existing code and structure can be reused without the need to redevelop the entire existing toolkit, and even if changes in specifications occur, such as the addition of features according to customer requirements or the improvement of interface versions, the scope of change is limited to the code block of the corresponding function. The toolkit generator (100) can generate a new toolkit by selectively assembling only the necessary parts while maintaining the existing logic, thereby minimizing the time and resources required for the overall toolkit development and is also advantageous in terms of functional scalability.
[0081] The code block calling step (S200) can be performed by the DSL API (120) of the toolkit generator (100). The DSL API (120) can receive specification information from the DSL interpreter (110) and call the necessary code block from the code library.
[0082] FIG. 7 is a diagram illustrating an example in which a NoC product specification targeting a mobile device is written in DSL format in a toolkit generation method according to one embodiment of the present disclosure, and is intended to explain the meaning of a field additionally defined in the DSL.
[0083] The DSL defined in the method of the present disclosure for calling a function stored in a code library, as previously described, includes a field defined to call a code block stored in the code library. In other words, the field defined to call a code block can be understood as a field that defines a method for setting the value of a parameter.
[0084] Referring to Fig. 7, the eval_function field corresponds to this. For example, in the case of the buffer_size parameter, FUNC:set_buffer_mobile() is specified as eval_function, which means that the parameter is set by the set_buffer_mobile function of the code library.
[0085] The toolkit generator (100) interprets this specification and sets the buffer_size to a fixed value of set_buffer_mobile when generating the toolkit. The advantage of this method is that the buffer_size setting method can be easily changed by specifying a function. In addition, if it is necessary to modify set_buffer_mobile, only the corresponding code block in the code library needs to be modified, regardless of the individual specification or the toolkit generator (100).
[0086] In the case of the present disclosure, the setting method is fixed, and performance is approximately 6 to 7 times faster than the existing method of calculating various conditional expressions at runtime and changing the settings of the toolkit.
[0087] FIG. 8 illustrates an example in which NoC product specifications targeting high-performance servers are written in DSL format in a toolkit generation method according to one embodiment of the present disclosure.
[0088] When designing a NoC product targeting a high-performance server, according to the present disclosure, the specification is modified as shown in FIG. 8 and the toolkit generator (100) is executed. Referring to FIG. 8, the input value of the eval_function field of each parameter is changed so that a code block suitable for a NoC product targeting a high-performance server can be called. When the toolkit generator (100) is executed, code blocks that are pre-designed to be suitable for a NoC product targeting a high-performance server are called, and there is no longer a need to individually modify code related to constraints, defaults, etc.
[0089] The DSL API (120) refers to the syntax for retrieving a required code block from a code library. For example, a required code block from a code library can be called using the prefix FUNC.
[0090] A method according to one embodiment of the present disclosure may include a code block cleanup step (S300).
[0091] The code block cleanup step (S300) is a step for organizing the execution order of code blocks. The code block cleanup step (S300) can be performed by the code coordinator (130) of the toolkit generator (100).
[0092] The code coordinator (130) is a component that determines the overall execution flow of the toolkit by coordinating the execution order and details (variable names, etc.) of code blocks loaded from the code library.
[0093] That is, the code block cleanup step (S300) is a step for adjusting the execution order of code blocks called in the code block calling step (S200).
[0094] For example, in the code block sorting step (S300), the code coordinator (130) can arrange the called code blocks so that they are executed in the correct order. For example, it can determine the order of specific logic and arrange the code blocks so that they are executed according to this logic. As a specific example, a code block related to data transmission settings must be executed after a code block related to buffer size settings is executed first. The code coordinator (130) can automatically adjust this order to ensure a consistent execution flow.
[0095] For example, the code tuner (130) may also play a role in adjusting so that the variable names used by each code block do not conflict with each other. For example, if a specific variable is used in multiple code blocks, the variable names used in each code block can be appropriately modified to prevent conflicts. A method according to one embodiment of the present disclosure may include a code block assembly step (S400).
[0096] The code block assembly step (S400) is a step of assembling organized code blocks to finally generate the toolkit.
[0097] In the code block assembly step (S400), the core logic of the toolkit and the code blocks organized in the code block organization step (S300) are integrated. At this time, the core logic may refer to a specification-independent code block composed of parameters or logic that are commonly used regardless of the specification.
[0098] As explained earlier, specification-independent code blocks are stored in the code library, but they may be stored as a single common code rather than being separated and managed by functional unit.
[0099] The code block assembly step (S400) can be performed by the code assembler (140) of the toolkit generator (100). The code assembler (140) corresponds to a component that integrates the core logic of the toolkit and the code blocks generated by the code coordinator (130) into one to create an executable final program and unit tests of the program.
[0100] As described above, one embodiment of the present disclosure automatically generates a toolkit by receiving code blocks specified in the specification from a code library and combining them when a specification according to a defined DSL grammar is input. Accordingly, there is no need to store and manage multiple versions of the toolkit, thereby improving ease of management.
[0101] In addition, one embodiment of the present disclosure receives code blocks specified in the specification from a code library when a specification according to a defined DSL grammar is input, and combines these code blocks to immediately generate a toolkit optimized for the specification. Accordingly, there is an advantage in that the product development cycle is shortened and the scalability of the product is increased.
[0102] The effects of the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the description in the claims.
Claims
1. A method for generating a toolkit that runs on a computing device, A specification interpretation step for interpreting a Domain-Specific Language (DSL) containing the specifications of the design target to extract required function and parameter values; A code block calling step of searching for and calling code blocks to perform the functions required by the specification in a code library in which code blocks for implementing the above functions are stored; A code block cleanup step for organizing the execution order of the above code blocks; and A code block assembly step for assembling the above-mentioned organized code blocks to finally generate the toolkit; comprising How to create a toolkit.
2. In Paragraph 1, The above code library is characterized by storing specification-dependent code blocks for implementing each function required by the above specification. How to create a toolkit.
3. In Paragraph 1, In the above DSL, Characterized by including a field defined to call a code block stored in the above code library, How to create a toolkit.
4. In Paragraph 1, The above code block assembly step is, Characterized by the integration of the core logic of the toolkit and the code blocks organized in the code block organization step above. How to create a toolkit.
5. In Paragraph 4, The core logic above is, Characterized by including a specification-independent code block related to parameters or logic commonly used regardless of the above specifications, How to create a toolkit.
6. A computer program stored on a computer-readable storage medium, wherein the computer program is a toolkit generation program that operates to generate a toolkit based on the specifications required by the design target, and The above operation is, A specification interpretation step for interpreting a Domain-Specific Language (DSL) containing the specifications of the design target to extract required function and parameter values; A code block calling step of searching for and calling code blocks to perform the functions required by the specification in a code library in which code blocks for implementing the above functions are stored; A code block cleanup step for organizing the execution order of the above code blocks; and A code block assembly step for assembling the above-mentioned organized code blocks to finally generate the toolkit; comprising Computer program.