JP2007524156A - Block processing of input data in a graphical programming environment - Google Patents

Abstract

  A method and system for performing block processing of input data in a graphical programming environment is disclosed. The input data to be processed is divided into a plurality of blocks. Each block of the input data is sent to a data processing device for processing each block of the input data. The plurality of processed blocks of data are combined to produce output data. When the size of the output data is smaller than or equal to the size of the input data, the present invention may perform in-place processing of the input data in which the output data is overwritten on the input data. In the in-place process of the input data, the output data may share a memory area with the input data so that a memory area when the input data is processed in the block process is saved.

Description

Related applications

  This application claims the benefit of US patent application Ser. No. 10 / 744,654, filed Dec. 22, 2003, the contents of which are incorporated herein by reference.

  The present invention relates generally to a graphical programming environment, and more particularly to a method and system for performing block processing of input data in a graphical programming environment. In the block processing of the input data, the input data is divided into a plurality of data blocks which are smaller portions of the input data, and the plurality of data blocks are processed.

  There are various types of block diagrams that describe computations that can be performed on application specific computing hardware such as computers, microcontrollers, FPGAs, and custom hardware. Such various block diagrams include time-based block diagrams such as Simlink (registered trademark) manufactured by The MathWorks of Natick, Massachusetts, and states such as Stateflow (registered trademark) manufactured by The MathWorks of Natick, Massachusetts. A base flow chart and a data flow chart are included. These various forms of block diagrams are common in that they describe how to perform these diagrams.

  To date, engineers and scientists have used time-based block diagrams to learn, design, debug, and improve dynamic systems in many scientific fields, such as feedback control theory and signal processing. A dynamic system having a characteristic that behavior changes with time is a system that represents many systems in the real world. With the advent of software packages such as Simulink, time-based block diagram modeling has become increasingly important over the last few years. The rich support tools included in the sophisticated software platform provided by these packages enable efficient, systematic and low-cost analysis and design of dynamic systems.

  A dynamic system (whether it is natural or artificial) is a function whose response is applied at any given time, its current state and current time. It is a system that is. Such systems range from simple systems to highly complex systems. Physical dynamic systems include falling objects, earth rotation, biomechanical systems (such as muscles and joints), biochemical systems (such as gene expression and protein pathways), weather and climate pattern systems, etc. It is. Examples of artificial or engineered dynamic systems include bouncing balls, springs with weights attached to one end, automobiles, aircraft, control systems for large appliances, communication networks, audible signal processing, nuclear reactors, stock markets, etc. included. Experts from various fields, such as engineering, natural sciences, education and economics, try to better understand changes in the behavior of the system over time by building mathematical models of the dynamic system. To do. Such mathematical models help to build “better” systems, where “better” means, for example, quality, time to market, cost, speed, size, power consumption, It can be defined by criteria of various properties such as robustness. These mathematical models also support analysis, debugging and repair of existing systems (such as human or automotive anti-lock braking systems). These models may serve the purpose of educating others based on the principles governing the physical system. These models and results are often used as a medium for scientific communication between humans. The term “model-based design” is used to mean the use of a block diagram model in the development, analysis and verification of dynamic systems.

  A graphical programming environment may provide a tool for implementing a data processing system consisting of a plurality of cascaded components that perform a series of data operations that input data to obtain a desired output data set. In many applications, such a data processing system is required to perform input data processing in real time to produce output data.

  In many applications, including image or video processing systems, the input data has a multidimensional matrix and contains a large amount of data to be processed. Large memory capacity is required to temporarily store a processed copy of such a large amount of signal. Alternatively, the above operation can be performed by dividing the input signal into smaller segments called data blocks, performing the same processing on each data block, and reconstructing the processed signal. is there. This type of processing is known as block processing. In block processing, the size of the data block is much smaller than the input signal, so the memory capacity required for temporary storage is greatly reduced.

SUMMARY OF THE INVENTION The present invention provides a method and system for performing block processing of input data in a graphical programming environment. In the block processing of the present invention, the input data may have any number of dimensions. The input signal to be processed is divided into a plurality of data blocks. The user may specify the method of dividing the input data into data blocks. For example, by designing the size of the input data to be processed and the size of the data block, the input signal can be divided into a total number of data blocks to be processed. It may be divided. A user may specify a data processing function for processing each block of input data. Multiple blocks of processed data are reconstructed to produce output data. If the size of the output data is less than or equal to the size of the input data, the present invention performs in-place block processing of the input data, where the processed data block is overwritten with the input data block Is possible. The output data and the input data may share the memory area so that the memory area required for the input data processing in the block processing of the present invention is saved.

  According to one aspect of the invention, a method is provided for performing block processing of input data in an electronic device that provides a graphical programming environment. Graphic elements are displayed on the display of the electronic device, and data can be input to the graphic elements. The graphic element represents a block processing model for executing block processing of input data. A user interface is provided for inputting control data of the block processing model in response to an operation of the graphic element by the user. The control data sets an operation mode of the block processing model. The block processing model executes block processing of the input data based on the control data of the block processing model.

  According to another aspect of the invention, a method is provided for performing block processing of input data in an electronic device that provides a graphical programming environment. The input data is divided into a plurality of blocks based on the control data input by the user. In order to identify a block in the input signal, an index is generated for the block of the input data. The data block is selected and processed based on the index of the block. The processed data is assigned to a position in the output data, but the position of the processed data in the output data is determined by the index of the block.

  According to still another aspect of the present invention, a system for executing block processing of input data is provided. The system is implemented in an electronic device that provides a graphical programming environment. The system includes an iterator for receiving the input data and dividing the input data into a plurality of data blocks. The system also includes a data processing device for processing one block of the input data. The iterator allows the data processing device to repeat data processing of the input data for each of the plurality of blocks.

  According to yet another aspect of the invention, a system is provided for performing block processing of input data in an electronic device that provides a graphical programming environment. The system includes a pointer generator for repeatedly generating a pointer for each block of the input data. The system also includes a data processing device for processing each block of the input data specified by the pointer. The pointer represents the position of each data block in the memory area.

  The present invention enables processing of a large amount of data in real time by block processing of input data. Furthermore, the present invention enables in-place processing of the input data when the size of the input data is greater than or equal to the size of the output data. As a result, the present invention saves a memory area required for processing the input data.

DETAILED DESCRIPTION OF THE INVENTION Embodiments of the present invention relate to a graphical programming environment, such as a block diagram programming environment provided by an electronic device. A block diagram is a representation of a system in the real world using a plurality of nodes (called blocks) containing diagrams connected to each other by arcs (called lines). A block is a functional entity that performs operations on data processed by the system. Lines represent the transmission of data (called signals) between the various blocks. Those skilled in the art will appreciate that a block diagram is an example of a graphical programming environment and that the present invention is applicable to other types of graphical programming environments, such as a state flowchart programming environment.

  The graphical programming environment of an embodiment of the present invention provides a block processing block that performs block processing of input data. A block processing block is a functional node in the block diagram environment, and does not process the entire input data at once, but processes the input data in units of sections (smaller portions of the input signal) called data blocks. The block processing block receives the input data and divides the input data to be processed by the block processing block into a plurality of blocks. The block processing block repeatedly processes each block of the input data, and generates output data by combining a plurality of blocks of processed data generated as a result. In the embodiment of the present invention, the block processing block is provided in a single block. However, the block processing may be executed in units of a plurality of blocks which may include a plurality of components of the block processing block. Those skilled in the art will appreciate that.

  The block processing block executes data processing of input data in a plurality of blocks based on selection of an operation mode of the block processing block by the user. The operation mode of the block processing block is determined by a user who inputs parameters of the block processing block such as the size of the data block and the size of input data to be processed. When the size of the output data is smaller than or equal to the size of the input data, the block processing block may execute in-place processing of the input data. In the in-place block processing of input data, the processed data block is overwritten with the input data block. As a result, since the output data shares the memory area with the input data, the memory area required for the output data is saved.

  FIG. 1 is an example of a graphical programming environment in which multiple blocks are utilized to represent a model of an embodiment of the present invention. The environment 100 includes a block library block 110, an editor 120, a simulator 130, and a code generator 140. The code generator 140 may generate source code for the model of the embodiment of the present invention.

  The block library 110 includes a plurality of blocks of application specific models that support system modeling and simulation. A plurality of blocks in the block library 110 are incorporated into a model of the system designed using the modeling and simulation tool 130. The blocks supplied from the block library 100 are represented by rectangular blocks in the embodiment of the present invention. Those skilled in the art will appreciate that the model may be represented by other graphic or character symbols. The model block supplied from the block library 110 includes a block processing block 300 (see FIG. 3) for processing input data in units of blocks. The block library 110 may further include a plurality of component blocks of block processing blocks that can be combined to perform block processing functions. It will be understood by those skilled in the art that the block processing of the embodiment of the present invention may be executed in units of a plurality of blocks that may include a plurality of components of the block processing block. Examples of the block library 110 include the Simulink Blockset series DSP Blockset, Fixed-point Blockset, and Communications Blockset manufactured by The MathWorks of Natick, Massachusetts. The Blockset series provides models and utilities for developing and incorporating models for target systems and subsystems of the target systems.

  Editor 120 and simulator 130 provide a graphical simulation and prototyping environment for modeling, simulation and analysis of the target system. The editor 120 incorporates a plurality of blocks supplied from the block library 110 into the target system. The target system designed by the editor 120 is simulated by the simulator 130 in order to analyze the behavior of the designed target system. An example of editor 120 and simulator 130 is Simulink (registered trademark) manufactured by The MathWorks of Natick, Massachusetts. Blockset operates on Simulink (registered trademark).

  Simulink® allows the user to design a block diagram of the target system, simulate the behavior of the system, analyze the performance of the system, and improve the design of the system. Simulink® allows the user to design the target system using a user interface that allows the drawing of a block diagram model of the target system. All the blocks in the block library 110 can be used by the user when the user creates a block diagram of the target system. Each user customizes this model block, (a) reconfigures the block into some custom format, (b) removes unused blocks, and (c) adds custom blocks designed by him / her. May be possible. Blocks may be dragged from the block library 110 to a window (ie, a model drawing surface) using some human-machine interface (such as a mouse or keyboard). Simulink includes a block diagram editor that allows the user to perform tasks such as drawing, editing, annotating, saving, and printing block diagram representations of the target system. The block diagram editor is a component of a graphical user interface (GUI) that allows a user to draft a block diagram model. Simulink (R) also includes a character interface with an instruction set that allows interaction with a graphical editor. The user can use this character interface to write a specific script that automatically performs block diagram editing operations. Simulink® also allows the user to determine the behavior of the system by simulating the designed target system. Simulink includes a block that performs the task of compiling and linking a block diagram to create an “in-memory executable” version of the model used for code generation and / or simulation of the block diagram model A diagram execution engine is included.

  The code generator 140 generates a customizable C code directory from the model block diagram designed using the editor 120. Code generator 140 automatically generates source code to enable rapid prototyping, hardware-in-the-loop simulation, and rapid desktop simulation of models designed in editor 120. The code generation tool 140 may generate valid source code for embedded system applications. Those skilled in the art will appreciate that the source code is an example of code that is generated within the code generator 140 and that the code generator 140 may generate other code, such as Ada, for the model. Real-Time Workshop from The Mathworks of Natick, Massachusetts is an example of a code generation tool 140.

  Those skilled in the art will appreciate that the graphical programming environment 100 is not limited to a block diagram programming environment, but includes any other graphical programming environment, such as a state programming graphical programming environment. Stateflow® from The Mathworks of Natick, Massachusetts provides an example of a state flowchart modeling environment. Stateflow® provides a graphical environment for modeling and designing event-driven models. Stateflow® allows the user to create a state flowchart that graphically represents the hierarchical and parallel states of multiple models and event-driven transitions between the multiple states. Simulink® that interfaces seamlessly with Stateflow® may execute a model based on a state flow chart created by Stateflow® and analyze the behavior of the model.

  FIG. 2 is an example of an electronic device 200 suitable for implementing embodiments of the present invention. The electronic device 200 includes a network interface 230, a modem 240, an auxiliary storage device 250, a main storage device 260, a microprocessor 270, a monitor 280, and a keyboard / mouse 290. The microprocessor 270 controls each component of the electronic device 200 so that software tools within the graphical programming environment 100 are properly executed. The electronic device 200 receives data necessary for controlling the design and simulation of the target system, such as control data for setting the operation mode of the block processing block 300, via the keyboard / mouse 290 (see FIG. 3). ) The electronic device 200 displays the result generated in the graphical programming environment 100 on the monitor 280. Main memory 260 retrieves code from auxiliary memory 250 that needs to be accessed quickly by microprocessor 270 for operation of electronic device 200 and execution of graphical programming environment 100 and sends it to microprocessor 270. . The auxiliary storage device 250 normally stores software tools for applications. Specifically, the auxiliary storage device 250 includes a code 251 for the block library 110, a code 252 for the editor 120, and a code 253 for the simulator 130. The network interface 230 and the modem 240 are connected to other electronic devices via a communication network such as the Internet, an intranet, a LAN (Local Area Network), a WAN (Wide Area Network), and a MAN (Metropolitan Area Network). Enables communication. With such a communication function, the distributed implementation of the present invention may be possible.

  FIG. 3 is an example of a block processing block 300 provided by the block library 110 in the graphical programming environment 100 of the embodiment of the invention illustrated in FIG. Block processing block 300 implements an iterative system capable of performing block processing operations within a graphical programming environment. Block processing block 300 receives input data and generates output data. The input data may have any number of dimensions. For example, in an image or video processing system, the input data has a matrix dimension and contains a large amount of data to be processed. Block processing block 300 includes sub-blocks representing a data processing device 310 that performs a data processing function on input data. The data processing function of the data processing device 310 may be specified by a user. For example, the block processing block 300 processes each 8 × 8 block of 512 × 512 input data using a single DCT (Discrete Cosine Transform) data processor 310.

  The block processing block 300 divides the input data into a plurality of blocks, sends each block of the input data to the data processing device 310, and places each block of the processed data at an appropriate position in the output data. As a result, output data is created. The operation mode of the block processing block 300 is determined by a user who specifies parameters of the block processing block 300 such as, for example, the size of the block and the range in which block processing is executed in the input data. The parameters of block processing block 300 are described in more detail with reference to FIG. Based on a predetermined operation mode of the block processing block 300, the entire input data or a part of the input data is divided into a plurality of blocks. A data processing function is executed by the data processing device 310 for each block of the input data. As the blocks of the input data are processed, output data is reconstructed by reassembling the blocks of processed data in the same order.

  Block processing block 300 may be utilized for numerous applications, including image compression and audio coding. In the JPEG (Joint Photographic Expert Group) image compression method, the data processor 310 selects to execute a JPEG image compression algorithm in which a large amount of input image data can be compressed by block processing. May be. In the compression stage, the input image is divided into a plurality of blocks, and each block is processed by a data processor 310 that performs a DCT (Discrete Cosine Transform) transformation. In the restoration stage, inverse DCT is performed on each block, and finally output data is reconstructed. One skilled in the art will appreciate that the block processing block 300 may be used with MPEG (Moving Picture Expert Group) video compression. In the case of voice coding, the voice signal is processed within a frame of 10 to 30 milliseconds. Normally, an input frame is subdivided into 2 to 4 subframes, and the data processor 310 can perform the same series of operations on samples of these subframes. These speech coding subframe samples may overlap across subframe boundaries. This overlap is described in more detail below with reference to FIG. 5A.

  FIG. 4 is an example of a graphical user interface (GUI) 400 for entering parameters into the block processing block 300 to set the operating mode of the block processing block 300 in the embodiment of the present invention illustrated in FIG. is there. Those skilled in the art will appreciate that the GUI 400 is exemplary and the parameters of the block processing block 300 may be entered via a text user interface, such as a command line interface, for example. The GUI 400 provides several spaces for the user to enter parameters for the block processing block 300. The parameters may include the number of rows per block 410, the number of columns per block 420, duplicate rows 430, duplicate columns 440, input data size 450 and boundary values 460. The parameters in the GUI 400 are exemplary, and the GUI 400 provides a space for entering additional parameters, such as the data processing function of the data processing device 310 and the order of multiple blocks that process the input data. Those skilled in the art will appreciate that this is possible. The order of a plurality of blocks for processing input data will be described in more detail below with reference to FIGS. 5C to 5E.

  The number of rows 410 per block and the number of columns 420 per block determine the size of the block in the input data. The GUI 400 may include another parameter group that determines the size of the block, such as the number of blocks in the row direction of the input data to be processed and the number of blocks in the column direction of the input data to be processed. Those skilled in the art will appreciate.

  Duplicate rows 430 and duplicate columns 440 determine the overlap between each block and adjacent blocks. These duplicates are extra rows and columns outside the data block whose values are taken into account during block processing. FIG. 5A is an example of input data that illustrates duplicate rows and columns of each block in the input data. In FIG. 5A, the input data of the embodiment of the present invention is divided into a plurality of data blocks, and these data blocks have an 8 × 8 matrix size. Each block of input data overlaps adjacent blocks by two columns and one row. Each 8 × 8 block overlaps one row at the top and bottom and two columns at the left and right. A shaded portion 520 represents an overlap. The GUI 400 may include a blank for inputting a boundary value 460 for padding. FIG. 5B is an example of input data illustrating a padding process of input data in the embodiment of the present invention. The input data is divided into a plurality of blocks, and each block has an 8 × 8 matrix size. If these blocks do not completely match the input data, padding values are added to the shaded range 530 on the lower and right sides of the input data so that the blocks match the input data to be processed. Further, the overlap illustrated in FIG. 5A extends beyond the input data boundary 510. In this padding process, a padding value is also added to the overlap 520 outside the boundary 510 of the input data.

  The order of a plurality of blocks for processing input data to be processed may be selected by the user selecting an index generator that is a code word generation function. These data blocks may be processed in any arbitrary order specified by the user. For example, these blocks may be processed in the horizontal (row) direction, vertical (column) direction, or zigzag direction, as illustrated in FIGS. 5C-5E, respectively. One skilled in the art will appreciate that the order illustrated in FIGS. 5C-5E is exemplary, and that these blocks may be processed in other orders, such as, for example, main diagonal and sub-diagonal directions. These blocks may be processed in the order specified by the user. For example, when the user inputs a specific order such as “1, 3, 5, 7, 9...” For processing the blocks, the blocks of input data are block 1, block 3, block 5, block 7 and so on. , Block 9...

  FIG. 6 is an example of a block processing block 600 that executes block processing of input data in the embodiment of the present invention. The block processing block 600 includes an iterator 610 and a data processing device 620. The iterator 610 receives input data and outputs output data. Based on the operation mode of the block processing block 600 selected by the user, the iterator 610 selects one block of input data to be processed and sends the selected block of input data to the data processing device 620. When the data processor 620 processes the selected block of input data and returns the processed block of data to the iterator 610, the iterator 610 places the processed block of data in the output data. The block currently being processed may be displayed so as to be visible in the environment 100. This display may be useful in debugging processing. Those skilled in the art will appreciate that the size of the block of processed data may differ from the size of the block of input data depending on the data processing function of the data processing device 620 defined by the user. The position of the processed data block in the output data is determined based on the position of the selected block in the input data. The block processing block 600 repeats these steps for all blocks of input data to be processed.

  FIG. 7 shows another example 700 of a block processing block for executing block processing of input data in the embodiment of the present invention. The block processing block 700 includes an index generator 710, a selector 720, a data processing device 730, and an allocation device 740. The selector 720 and the allocation device 740 receive input data, and the allocation device 740 generates output data. An index generator 710 generates a codeword or index that typically includes one or more integers for a block of input data. Based on the operational mode of the block processing block, the index generator 710 generates a series of codewords or indexes that accurately identify which elements of the input data are selected to form the block during the block processing iteration. Generate repeatedly. The block index is determined so as to specify both the block of input data to be processed and the position of the block of processed data in the output data. The block index generated by the index generator may be a scalar or a vector. The block index individually identifies all samples included in the block. The size of the scalar or vector index must be smaller than the size of the data block. The index generator can implement a generalized addressing scheme that individually identifies the subunits of the input signal. In this generalized addressing scheme, the samples that make up the subunits of the input signal do not necessarily have to be adjacent to each other in the memory. If i = 1, 2, 3,..., n is a repetition index, the address of the subunit element may be any function f (i) applied to the repetition index. For example, the code word for the block index may be defined as f (i) = a + bi, which is a simple linear function of i, where a may be the starting index and b may be the index increment. Another example of the block index may include [start row, end row] and [start column, end column] of the block. Those skilled in the art will appreciate that the index may be in another form, for example using an offset of the end row / column from the start row / column of each block. The selector 720 and the allocation device 740 receive the block index of the input data. The selector 720 selects one block based on the block index, and sends the selected block to the data processing device 730. The data processing device 730 processes the transmitted input data block and outputs a processed data block. An allocation device 740 receives the processed data block and allocates the processed data block in the output data based on the index of the input data block. Those skilled in the art will appreciate that other index generators may be used for the selector 720 and the allocation device 740. Block processing block 700 repeats these steps for all input data blocks to be processed. The block processing block 700 may execute in-place processing of input data. In this case, the output data needs to share a memory area with the input data. In the in-place process, the output data is overwritten with the input data. In-place block processing is described in more detail below with reference to FIG.

  FIG. 8 shows still another example 800 of a block processing block capable of executing in-place block processing of input data in the embodiment of the present invention. The block processing block 800 includes a pointer generator 810 and a data processing device 820. The pointer generator 810 and the data processing device 820 receive input data. The pointer generator 810 generates a pointer to each input data block based on the operation mode of the block processing block 800 selected by the user. A pointer to an input data block represents the position of the block in the memory area. The pointer of the block may include a pointer to the first element of the block. The pointer to the block may include a pointer to another element of the block, such as a pointer to the last element of the block, which can identify the block in the memory area. Will be understood by those skilled in the art. The pointer to the input data block is sent to the data processing device 820. The data processing device 820 processes the input data block specified by the pointer. When the processing of the input data block is completed, the data processing device 820 overwrites the processed data block at a position in the memory area specified by the pointer to the block received from the pointer generator 810. Block processing block 800 repeats these steps for all input data blocks to be processed. In this way, output data is completely formed at the end of the iterative process. It will be understood by those skilled in the art that in the in-place processing of the input data, generally, the size of the input data is larger than or equal to the size of the output data.

  In summary, embodiments of the present invention provide block processing of input data in a graphical programming environment. The embodiment of the present invention provides a block processing block for executing block processing of input data. It will be understood by those skilled in the art that the block processing of the input data may be executed in units of a plurality of blocks that are constituent elements of the block processing block. A portion to be processed in the input data is divided into a plurality of blocks, and the plurality of blocks of the input data are processed in an order designated by the user. The processed data blocks are combined in the same order as the input data blocks are processed. The embodiment of the present invention also provides in-place processing of input data, in which a processed data block is overwritten in a memory area corresponding to the input data block. By the in-place processing of the input data, the output data can share the memory area with the input data, and the memory area for the output data can be saved.

  As described above, it will be understood that the present invention achieves the above-mentioned objects. Since several modifications may be made without departing from the scope of the invention, all matter contained in the above description or shown in the accompanying drawings is illustrative only and not restrictive. It is intended to be interpreted as not intended. For example, embodiments of the present invention may be implemented in any graphical programming environment that performs data processing of input data. The order and configuration of the steps shown in the figures can be changed without departing from the scope of the invention, and the description contained herein is only one example of many suitable descriptions that illustrate the invention. Will be understood by those skilled in the art.

The foregoing features, advantages, and other features and aspects of the present invention will be more fully understood by reference to the detailed description taken in conjunction with the accompanying drawings.
FIG. 1 is an example of a graphical programming environment in which multiple blocks are utilized to represent a model of an embodiment of the present invention. FIG. 2 is an electronic device suitable for implementing an embodiment of the present invention. FIG. 3 is an example of blocks used in the block processing model provided in the graphical programming environment of the embodiment of the present invention shown in FIG. FIG. 4 is an example of a graphical user interface (GUI) for inputting the parameters of the block processing block of the embodiment of the present invention shown in FIG. 3 and setting the operation mode of the block processing block. FIG. 5A is an example of input data for explaining duplicate columns and rows of each block input via the GUI shown in FIG. 4 in the embodiment of the present invention. FIG. 5B is an example of input data illustrating a padding process of input data in the embodiment of the present invention. FIG. 5C is an example of input data for explaining the order of a plurality of blocks for processing input data horizontally (in the row direction) in the embodiment of the present invention. FIG. 5D is an example of input data illustrating the order of a plurality of blocks for processing input data vertically (column direction) in the embodiment of the present invention. FIG. 5E is an example of input data illustrating the order of a plurality of blocks for processing the input data in the zigzag direction in the embodiment of the present invention. FIG. 6 is an example of a block processing block according to the embodiment of the present invention. FIG. 7 shows another example of the block processing block according to the embodiment of the present invention. FIG. 8 shows still another example of the block processing block according to the embodiment of the present invention.

Claims (33)

A system for performing block processing of input data in a graphical programming environment, wherein the graphical programming environment provides a model that mathematically represents an actual system, wherein the input data is divided into a plurality of data blocks A system with:
An index generator for generating an address for individually specifying each data block of the input data to be processed;
A selector for selecting one data block from the input data based on the address generated by the index generator;
A block processing device that processes each data block to produce an output associated with the data block;
An iterator that allows iterative processing of the plurality of data blocks of the input data;
An output generator for reassembling a plurality of processed data blocks based on the block index to generate the output of the system.   The data block address generated by the index generator is either a scalar or a vector, and the data block address is a code word that can individually identify all samples included in the data block. The system according to 1.   The system of claim 2, wherein the size of the scalar or vector address must be smaller than the size of the data block.   The index generator can perform a generalized addressing scheme that individually identifies data blocks of a large input data structure, and the plurality of samples making up the data block of input data are not necessarily in memory The system of claim 1, wherein the elements may not be adjacent to each other.   The system according to claim 2, wherein the addresses of the plurality of blocks are functions f (i) applied to the index, where i = 1, 2, 3,..., n is an iterator index. .   6. The system of claim 5, wherein the code word of the data block address is defined as f (i) = a + bi, which is a simple linear function of i, where a is a starting index and b is an index increment.   The system of claim 1, wherein the index generator includes a plurality of outputs.   The system of claim 1, wherein different index generators are used for the selector and the output generator.   The system of claim 1, wherein the same index generator is used for the selector and the output generator.   The system of claim 1, wherein the control parameter includes a size of the input data.   The system of claim 1, wherein the size of each block is included in the control parameter.   2. The control parameter of claim 1, wherein the control parameter includes an index generator codeword generation function defined for a series of positive integers, and the plurality of data blocks are processed in any order specified by the user. system.   The system of claim 1, wherein the control parameter includes a number of samples that overlap between a plurality of adjacent data blocks.   The system of claim 1, wherein the control parameter includes a boundary value of a sample having an address that exceeds the range of the original input signal.   The system of claim 1, wherein the system includes a block processing model implemented within a block diagram modeling environment, and automatic source code representing the operation of the block processing model is generated.   The system of claim 15, wherein the block processing model is used in a data flow and time oriented simulation environment.   The system enables in-place processing in which the input data can share a memory area with the output data when the size of the input data is greater than or equal to the size of the output data. The system of claim 1. A system for performing block processing of input data in a graphical programming environment that provides a model that mathematically represents an actual system:
A block processing subsystem for repeatedly generating an address for individually specifying each data block of the input data to be processed, and selecting one data block from the input data based on the address generated by an index generator; ;
A block processing device that processes each data block to produce an output associated with the data block;
With
The block processing subsystem enables iterative processing of a plurality of data blocks of the input data based on control parameters input by a user, reassembles the processed data blocks based on the block index, and Generating the output of the system, and the control parameters include a specification of the processing device for processing the data block;
system.   The system of claim 18, wherein the control parameter includes a size of the input data.   The system of claim 18, wherein the control parameter includes a size of each block.   The system of claim 18, wherein the control parameters include any order specified by a user in specifying a function defined for a series of positive integers.   The system of claim 18, wherein a data block currently being processed is displayed visibly within the graphical programming environment.   The system of claim 18 further comprising a dedicated block processing structure for each block processing subsystem.   19. The system of claim 18, further comprising a general block processing structure for all block processing subsystems, wherein settings and control parameters for each block processing subsystem are individually stored in the form of control variables.   The system of claim 18, wherein the control parameter includes a number of samples that overlap between a plurality of adjacent data blocks.   The system of claim 18, wherein the control parameter includes a boundary value of a sample having an address that exceeds the range of the original input signal.   The system of claim 18, wherein the system includes a block processing model implemented in a graphical programming environment, and automatic source code representing the operation of the block processing model is generated.   The system of claim 18, wherein the block processing subsystem is used in a data flow and time oriented simulation environment.   The in-place processing is possible when the input data can share a memory area with the output data when the size of the input data is larger than or equal to the size of the output data. 18. The system according to 18. A system for performing block processing of input data, wherein the system is implemented in an electronic device that provides a graphical programming environment, the graphical programming environment providing a model that mathematically represents the actual system A system that is used to design the target system:
A pointer generator for repeatedly generating a pointer of each block of the input data based on a control parameter input by a user;
A processing device for processing input data of each block designated by the pointer;
With
The processing unit directly processes the block of input data specified by the pointer so that the input data and output data share a memory area;
system.   31. The system of claim 30, wherein the control parameter includes a number of samples that overlap between a plurality of adjacent data blocks.   31. The system of claim 30, wherein the control parameters include boundary values for samples having addresses that exceed the range of the original input signal. 32. The system of claim 30, wherein automatic source code representing the operation of the block processing model is generated.

Images