JP2015076007A - Board design assistance system and board design assistance method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a board design assistance system and a board design assistance method capable of providing assistance for an optimal board design in cooperation of hardware with software.SOLUTION: A board compliant with specifications is designed by executing: a first step of determining a hardware module and a software module for executing data flow processing to be executed by an application according to a model base design, and mounting the hardware module in a logical unit of the board and mounting the software module in a control unit of the board; and a second step of performing the data flow processing while setting each of the mounted modules as a processing unit by prototyping.

Description

  The present invention relates to a board design support system and a board design support method for supporting optimal board design by coordinating hardware and software.

  Various embedded devices are developed for each target application through dedicated LSI (Large Scale Integration) development using SOC (System On Chip), software development for specific CPU (Central Processing Unit), and a combination of both. Yes. In addition, development using a field-programmable gate array (FPGA), which is growing rapidly, is becoming mainstream as the cost, time, and risk of dedicated LSI development increase. For both dedicated LSI development and FPGA use, it is necessary to divide the target application or algorithm into hardware and software optimally and in a short period, that is, architecture design and implementation. In order to solve this problem, Patent Document 1 discloses an architecture design support system using a reusable hardware module and software module, and a generation method thereof.

JP 2001-202397 A

  In Patent Document 1, it is possible to support SOC design as a result of combining the functions and constraint conditions of the hardware module and software module. However, there is little consideration as to whether the designed SOC satisfies the initial required specifications as an application, and there has been a problem that it is not possible to develop a realistic SOC that meets the initial required specifications. In addition, since Patent Document 1 is based on the viewpoint of how to implement the specification description of the target algorithm in hardware and software, the feature of the target application is not considered, It is not necessarily designed by coordinating hardware and software in an optimal way.

  An object of the present invention is to solve the above-mentioned problems, for example, focusing on a unit of processing performed on an image frame, a communication packet, etc., for data flow processing such as image and communication, and hardware and software. It is an object of the present invention to provide a board design support system and a board design support method that support the optimum board design in cooperation.

  In order to solve the above-described problems and achieve the object, a board design support method according to the present invention is a board design support method for supporting the design of a board on which a hardware module and a software module are mounted in accordance with application specifications. A hardware module and a software module for executing a data flow process executed by an application are defined by a model-based design, the hardware module is mounted on a logic unit of the board, and the software module is mounted on a control unit of the board Designing a board that meets the above specifications by executing the first step of mounting in the second step and the second step of performing data flow processing using each mounted module as a processing unit by prototyping. Characteristic board design It is grasped as 援方 method.

  In addition, the present invention is a board design support system that supports the design of a board on which a hardware module and a software module are mounted according to the application specifications, and the hardware module that executes a data flow process executed by the application is mounted. A setting control unit that defines a logic unit and a control unit that implements a software module based on a model-based design, and an execution control unit that prototypes the board by performing data flow processing using each mounted module as a processing unit It is comprised as a board | substrate design support system characterized by this.

  According to the present invention, it is possible to support optimal board design by coordinating hardware and software.

It is a figure showing the whole substrate design support system composition in this embodiment. It is a figure which shows the logical structural example of the FPGA board which implement | achieves a data flow process with this system. It is a figure which shows the physical structural example of the FPGA board which implement | achieves a data flow process with this system. It is a figure which shows the concept of the data flow process by a control task using the structural example shown in FIG. FIG. 5 is a diagram illustrating an example of pipeline processing defined by the task illustrated in FIG. 4. It is a flowchart which shows the process sequence of the data flow process in this Embodiment.

  Exemplary embodiments of a substrate design support system and a substrate design support method according to the present invention will be explained below in detail with reference to the accompanying drawings.

  FIG. 1 shows the overall configuration of a board design support system in the present embodiment. The board design support system is a system for finally prototyping a board such as an FPGA board by coordinating hardware and software in data flow processing exemplified by images and communication. The board design support system includes a general PC 1 and a general-purpose FPGA board 2. The PC 1 is equipped with a model-based design tool and an FPGA development tool, and is executed by a CPU (not shown) included in the PC 1. The FPGA board 2 includes a storage unit 2A, a logic unit 2B, and a control unit 2C. The PC 1 and the FPGA board 2 are connected by a general-purpose high-speed interface such as Ethernet (registered trademark) or PCI (Peripheral Component Interconnect) -Express, and can exchange data with each other, and are also called FPGA in the loop. The storage unit 2A is, for example, a memory, the logic unit 2B is configured by, for example, an accelerator, and the control unit 2C is configured by, for example, a CPU. Hereinafter, the storage unit 2A may be expressed as the memory 2A, and the control unit 2C may be expressed as the CPU 2C.

  FIG. 2 is a diagram showing a logical configuration example of the FPGA board 2 that realizes data flow processing in the present system. As shown in FIG. 2, the FPGA board 2 has a PC interface unit 201 for connection to the PC 1, a storage unit 2A, a logic unit 2B, and a control unit 2C shown in FIG. 1 connected by a data bus and a control interface. Yes. The software processing is divided into several software modules and installed in each of the control unit 1 to the control unit m. Also, the hardware processing is divided into several hardware modules and mounted in the logic unit 1 to the logic unit n. These software processing and hardware processing are assigned to each control unit and each logic unit for each module for which the application performs data flow processing, and are executed by each assigned control unit and each logic unit. A task for executing and controlling data flow processing (control task) is implemented in CPU0. Although specifically described later, the control task monitors the execution state of the module assigned to each control unit and each logic unit, and when the execution of the process by the module in the task is finished, the next task is read and data Starts flow processing and pipelines each module.

  If CPU resources are small, CPU0 to CPUm may be shared. Data exchange is realized by a standardized data bus via a memory. Control when data flow processing is performed is realized by a standardized control interface including setting, activation, interrupt, log information, and the like between the CPU 0 and each unit (each control unit, each logic unit). The memory 2A stores data holding and log information exchanged between the respective units. In this way, by standardizing the data bus and the control interface and collectively managing the data flow processing by the control task, the following hardware and software cooperative prototyping design becomes possible. In this embodiment, the control task is assigned to one control unit. However, the number of hardware modules and software modules, or simultaneously started control tasks may be increased or decreased according to the resources of the FPGA board 2. .

  FIG. 3 is a diagram showing a physical configuration example (hardware and software module configuration example) of the FPGA board 2 that realizes data flow processing in this system. As shown in FIG. 3, the FPGA board 2 includes a memory 2A, a logic unit 2B (in FIG. 3, a logic unit 2B-1 and a logic unit 2B-2), and a control unit 2C (in FIG. 3, the control unit 2C- 0, control unit 2C-1, control unit 2C-2). The memory 2A stores data to be subjected to data flow processing, and stores log information output during the data flow processing. The control unit 2C-0 executes a control task, accesses the memory 2A for each task via each interface, and executes and controls data flow processing.

  The logic unit 2B-1 and the logic unit 2B-2 are each equipped with a module H1 and a module H2 that perform hardware processing. In addition, the control unit 2C-1 and the control unit 2C-2 are each equipped with a module S1 and a module S2 that perform software processing. Here, a plurality of modules for performing hardware processing and modules for performing software processing can be created as long as they can be mounted on the FPGA board 2.

  The memory 2A and the module H1 are connected by an interface 2A-A and an interface 2B-1A. The memory 2A and the module H2 are connected by an interface 2A-C and an interface 2B-2A. The memory 2A and the module S1 are connected by an interface 2A-B and an interface 2C-1A. The memory 2A and the module H2 are connected by an interface 2A-D and an interface 2C-2A.

  Further, the control unit 0 and the module H1 are connected by an interface 2C-0A and an interface 2B-1B. The controller 0 and the module H2 are connected by an interface 2C-0C and an interface 2B-2B. The controller 0 and the module S1 are connected by an interface 2C-0B and an interface 2C-1B. The control unit 0 and the module H2 are connected by an interface 2C-0D and an interface 2C-2B.

  FIG. 4 shows a concept of data flow processing by the control task using the configuration example shown in FIG. As shown in FIG. 4, the control unit 0 sequentially reads a plurality of tasks T to be processed and executes data flow processing. At this time, the control unit 0 stores the processing state in each module (modules H1 and H2 and modules S1 and S2) in the memory 2A. In FIG. 4, the state of processing in the module H1 is represented as a state H1. Similarly, processing states in modules H2, S1, and S2 are represented as states H2, S1, and S2, respectively. In the present embodiment, the control unit 0 monitors the state of processing in each module described above, and allocates resources such as the control units 1 to m, the logic units 1 to n, and the memory 2A shown in FIG. A plurality of tasks T are pipeline processed. It is assumed that the number of tasks activated simultaneously is preset in the memory 2A under the resource constraints of the FPGA board 2.

  FIG. 5 is a diagram showing an example of pipeline processing defined by the task T shown in FIG. In the example shown in FIG. 5, first, the first task (task 1) is set as a processing target, the processing in the module H1 is executed, the processing in the module H2 and the module S1 is executed, and then the processing in the module S2 is performed. Execute. When the processing in the module H1 is completed, the processing in the module H2 and the module S1 is executed, the next task (task 2) is set as the processing target, and the execution of the processing in the module H1 is started. Show. In addition, when it is set to start a plurality of tasks (for example, two tasks) at the same time, tasks 1 and 2 to be actually started are executed simultaneously. Hereinafter, similarly, the pipeline processing of the task T is executed by the control unit 0 until the task m ends. In FIG. 4, a state in which each module starts and executes processing is expressed as START, and a state from the end of processing to the start of processing of the next task is expressed as WAIT.

  As described above, when the process in the module H1 is started, the state is written in the memory 2A as the state H1, and then when the process being executed is completed, the state H1 is updated to the state. Similarly, the statuses of the modules H2, S1, and S2 are written in the memory 2A as the state H2, the state S1, and the state S2, respectively. Then, when the status of each module becomes WAIT, the control unit 0 starts processing the next task. As described above, in this embodiment, the control unit 0 controls each module so as to pipeline the task, and sequentially executes the data flow process.

  FIG. 6 is a flowchart showing a processing procedure of data flow processing in the present embodiment. In the following, each process from step S1 to S9 is performed based on information input by the input unit (not shown) such as a keyboard of the PC 1 from the user and input by the CPU (setting control unit) of the PC 1. Definitions and settings are made for the FPGA board 2 for data flow processing by model-based design, and processing of each step is executed. After that, after the user analyzes the processing result, the CPU (execution control unit) of the PC 1 prototypes the FPGA board 2 in each processing up to steps S10 to 13 in response to an instruction based on the analysis result. Have feedback.

  As shown in FIG. 6, the input unit receives an input of a data flow processing specification that is determined in advance and performed by the application, and the CPU reads the specification and analyzes what data flow processing is performed (step S1). ). For example, the CPU analyzes whether the input specification is image processing data flow processing or communication processing data flow processing.

  Next, the input unit accepts input of the number of tasks activated simultaneously in the data flow processing, and the CPU defines the number of tasks to be data flow processed at one time (step S2). For example, the CPU considers the resources of the FPGA board 2, and the task that is activated simultaneously among the plurality of tasks T shown in FIG. 4 such as one frame for image processing and one packet for communication processing. Define a number (eg, 2 tasks).

  Further, the input unit receives an input of definition of a data bus and interface used in the data flow process, and defines a data bus and interface used by the CPU in the data flow process (step S3). For example, the CPU uses a common data bus specification between each module (modules H1 and H2, modules S1 and S2) and the memory 2A shown in FIGS. Define a common control interface.

  Then, the input unit receives an input of a module for dividing the task, and the CPU configures the task with the input module (step S4). For example, the CPU defines the tasks shown in FIGS. 4 and 5 to be configured by modules (modules H1 and H2, modules S1 and S2).

  Furthermore, the input unit creates the hardware module or software module defined in step S4 in accordance with the task defined in step S2, the data bus or interface defined in step S3 (step S5). For example, the CPU creates hardware modules and software modules (modules H1 and H2, modules S1 and S2) in accordance with the definitions of various interfaces shown in FIG.

  Then, the CPU defines for each created module that the execution result of the module is output as log information (step S6). For example, for each module (modules H1 and H2 and modules S1 and S2), the CPU records the processing result as log information and defines to store in the memory 2A.

  Further, the CPU generates a control task for executing the module created in step S5 (step S7), and the hardware module, software module, and control task created in each of the steps described above are converted into the FPGA board 2 respectively. Are mounted on the control units 1 to m, the logic units 1 to n, and the control unit 0 (step S8). The creation and implementation of these modules can be automated and the hardware and software processing can be changed by using a model-based design and a tool for FPGA development that are installed in the PC 1 in advance.

  Next, the CPU determines whether or not mounting on the FPGA board 2 is physically possible (step S9). When it is determined that mounting is not possible (step S9; No), the CPU determines whether the upstream is available depending on the cause. Returning to each step, the subsequent processing is repeated according to the revised definition. The specific steps to return to and the parts to be modified depend on the situation where mounting on the FPGA board 2 is impossible. For example, when hardware resources are insufficient, the parallelism inside the hardware module It is conceivable to reduce the multiplicity of processing or change to processing by software.

  On the other hand, if the CPU determines that mounting on the FPGA board 2 is possible (step S9; Yes), the FPGA board 2 receives the instruction from the PC 1 and simultaneously executes the number of tasks determined in step S2. When the processing in each module ends, for example, as shown in FIGS. 4 and 5, data flow processing is sequentially executed in the pipeline (step S10). At this time, each module records log information in the memory 2A.

  When the processing in each module is completed, the CPU captures log information recorded on the FPGA board 2 (step S11). As log information, an operation history of the control unit 0 mounted on the FPGA board 2 is recorded. For example, the data processing time and resource allocation waiting time of each module, the bus bandwidth used by each module and the overall bus usage status are recorded, and the CPU can collect these information. In addition to the execution result of the control task executed by the control unit 0, log information unique to each module can be acquired by storing log information for each module in the memory 2A.

  The CPU analyzes the execution status of the data flow process based on the log information (step S12), determines whether the data flow process needs to be reviewed (step S13), and, similarly to the case of step S9, The process returns to each upstream step according to the cause determined that the review is necessary, and the subsequent processing is repeated according to the corrected definition. For example, the CPU does not satisfy the required application specifications because the execution result of data flow processing or the execution result of each module does not satisfy the required application specifications. If it is determined that the redefinition of the division method and the interface to be used is necessary, the process returns to steps S3 and S4 to display a message for prompting redefinition and the above-described log information on the display unit (not shown) of the PC1. Then, the user redefines the data flow process via the input unit according to the displayed message and log information.

  In this way, by implementing the above-mentioned steps repeatedly with the module to be implemented as the processing unit of the application, it is possible to design the board such as SOC and FPGA by coordinating the hardware and software optimal for the data flow processing. It becomes possible. For example, for data flow processing such as images and communication, focusing on the unit of processing performed on image frames and communication packets, etc., hardware and software are coordinated using model-based design methods and prototyping methods. This makes it possible to design an optimal FPGA board.

  In addition, data flow processing such as images and communications can be repeatedly implemented and operated on the hardware and software on the FPGA board, and the hardware and software optimally designed for the data flow processing can be designed in a short period of time. Can do. In addition, by processing a group of modules into a task and pipelining a plurality of tasks for each module as long as the resource permits, the data flow process can be processed at high speed. In addition, optimization of individual modules and interfaces, such as increasing the number of hardware modules and software modules and control tasks to be started at the same time according to the resources of the FPGA board to be used, and dedicated connection between modules without using memory By doing so, it is possible to design as a final form as well as prototyping.

1 PC (computer)
2 FPGA board 2A Memory 2A-D Interface (memory)
2B logic unit 2B-1A, 2A interface (memory side of hardware module)
2B-1B, 2B interface (Hardware module controller)
2C control unit 2C-1A, 2A interface (memory side of software module)
2C-1B, 2B interface (software module controller side)
2C-0A to D interface (control unit).

Claims (10)

A board design support method for supporting design of a board on which a hardware module and a software module are mounted according to an application specification,
A hardware module and a software module for executing data flow processing executed by an application are determined by model-based design, and the hardware module is mounted on the logic unit of the board and the software module is mounted on the control unit of the board. A first step;
A board that meets the above specifications is designed by executing a second step of performing data flow processing using each mounted module as a processing unit by prototyping.
A board design support method characterized by the above. In the first step, the processing unit is determined according to the specification,
In the second step, a data flow process is executed in a processing unit determined according to the specification.
The substrate design support method according to claim 1. In the first step, a control task for controlling the data flow process is implemented in the control unit,
In the second step, the control task executes the data flow processing in the processing unit, and pipelines the data flow processing for each processing unit based on the processing state of each module.
The substrate design support method according to claim 1, wherein In the second step, a log that records the execution result of the module is output and the output result is analyzed, and the hardware module or the software module is redefined in the first step.
The substrate design support method according to any one of claims 1 to 3. In the second step, the log is output for each module, and each module is redefined based on the log output for each module in the first step.
The substrate design support method according to claim 4, wherein: In the first step, at least one of a module configuration for executing the data flow processing, the processing unit, and the number of control tasks is repeatedly determined based on an analysis result in the second step.
6. The substrate design support method according to claim 4 or 5, wherein: A board design support system that supports the design of a board on which a hardware module and a software module are mounted according to application specifications,
A setting control unit that defines a logic unit that implements a hardware module that executes a data flow process executed by an application and a control unit that implements a software module based on a model-based design;
An execution control unit for prototyping the board by performing data flow processing on each mounted module as a processing unit;
A board design support system comprising: The substrate includes a memory, and the logic unit and the control unit are connected to the memory through an interface,
The setting control unit further implements a control task for controlling the data flow processing in the control unit,
The execution control unit accesses the memory in the processing unit via the interface by the control task, and executes the data flow process.
The board design support system according to claim 7, wherein: The execution control unit outputs a log recording the execution result of the module to the memory and analyzes the output result,
The setting control unit redefines each module based on the output log.
The board design support system according to claim 8, wherein: The setting control unit repeatedly determines at least one or more of a module configuration for executing the data flow process, the processing unit, and the number of control tasks based on an analysis result by the execution control unit.
The substrate design support system according to claim 9.

Images