WO2002050676A1 - Procede de placement d'applications multiprocesseurs - Google Patents

Procede de placement d'applications multiprocesseurs Download PDF

Info

Publication number
WO2002050676A1
WO2002050676A1 PCT/FR2001/003826 FR0103826W WO0250676A1 WO 2002050676 A1 WO2002050676 A1 WO 2002050676A1 FR 0103826 W FR0103826 W FR 0103826W WO 0250676 A1 WO0250676 A1 WO 0250676A1
Authority
WO
WIPO (PCT)
Prior art keywords
tasks
elements
data
task
pattern
Prior art date
Application number
PCT/FR2001/003826
Other languages
English (en)
Inventor
Eric Lenormand
Original Assignee
Thales
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales filed Critical Thales
Priority to DE60132629T priority Critical patent/DE60132629T2/de
Priority to EP01271582A priority patent/EP1356382B1/fr
Publication of WO2002050676A1 publication Critical patent/WO2002050676A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs

Definitions

  • the present invention relates to a method for placing multiprocessor applications. It applies in particular to the placement of deterministic applications requiring high computing power, such as systematic signal processing (TSS) from radars, image processing, or real-time data compression.
  • TSS systematic signal processing
  • An application intended to be executed on a multiprocessor architecture is called a multiprocessor application.
  • An architecture includes hardware elements (called “hardware” in Anglo-Saxon literature) and software elements (said “software” in Anglo-Saxon literature).
  • the material elements include, for example. processors, memories, specialized circuits, and data buses.
  • the software elements include for example a set of basic instructions, called API (from the English expression “Application Programming
  • the material elements of an architecture are also called resources.
  • the software elements of an architecture are also called services.
  • Placement is an operation occurring during the development of multiprocessor applications. It consists in transforming an application described functionally into a set of sub-applications each intended for one of the processors of a target architecture. During the placement step, it is sought to have calculations performed in parallel by several processors of the target architecture.
  • a first way to execute calculations in parallel called task parallelism, consists in distributing different tasks on several processors or groups of processors. The different tasks are then executed at the same time on different processors or groups of processors.
  • a second way of performing calculations in parallel, called data parallelism consists in distributing the same task over several processors. According to this second operating mode, called SIMD or SPMD (“Single Instruction Multiple Data” or “Single Program Multiple Data”), several processors then execute at the same time and in a synchronized manner calculations corresponding to the same task, but on different data.
  • Placement generally includes a step called partitioning, a step called assignment, and a step called scheduling.
  • Partitioning consists, from an application described in a functional manner, of determining elementary calculation steps called tasks on the one hand, and / or of sharing homogeneous data blocks into elementary data blocks on the other hand.
  • Assignment known as “mapping” in Anglo-Saxon literature, consists in allocating elementary tasks and elementary data blocks to elements of the architecture such as processors for tasks, and memories for data blocks.
  • the scheduling consists in determining the chronology of execution of the tasks.
  • the multiprocessor architecture chosen is often called the target architecture.
  • the application can be described functionally by high-level software or by a graphic or DFG representation (from the English expression “Data Flow Graph”).
  • the tasks can be described in a form that can be manipulated by code generation tools (compilers for example), or in the form of codes usable by elementary processors.
  • a good placement ensures a good performance of the architecture, that is to say an almost optimal exploitation of its resources. Consequently, such a placement saves hardware components in the architecture.
  • a target architecture can go for example from 20 electronic cards to 10 electronic cards, thanks to a better placement of the same application.
  • An object of the invention is to overcome the aforementioned drawbacks and in particular to facilitate the placement of applications, by making it faster, and by making it possible to verify the integrity of the placement.
  • the invention relates to a method for placing multiprocessor applications on a target architecture, and to a device making it possible to implement the method.
  • the method includes at least the following steps:
  • the entry of a communication task during step (c) is carried out by specifying on the one hand:
  • the method further comprises a step of entering call tasks, said call tasks calling on other communication and / or calculation and / or call tasks.
  • the method further comprises a simulation step making it possible to test the application placed during the preceding steps.
  • the main advantages of the invention are that it makes it possible to determine the execution time on the target architecture of the application placed, even when said target architecture does not yet exist.
  • Figure 1 a block diagram of an example of workshop for placement of applications to implement the method according to the invention
  • Figures 2a and 2b an example of target architecture having a symmetrical structure
  • Figure 4 an example of the information displayed by the input interface of the workshop illustrated in Figure 1; • Figures 5, 6, 7, 9, 11, 12, 14, 16a, 16b, examples of views displayed by the input interface of the workshop during placement steps;
  • Figures 17a and 17b examples of the results of a simulation of the execution time of an application placed on a target architecture with the workshop illustrated in Figure 1.
  • the TSS application under consideration includes well structured and parallel task sequences, called loop nests.
  • Each loop nest contains a call to a procedure or macro-instruction generally corresponding to an array transformation, ie to a function of a signal processing library such as an FFT.
  • the treatments are regular and are carried out on multidimensional signals, the data are organized in tables whose dimensions (for example source, frequency, recurrence time, pointing time) carry the vectors on which the individual treatments will be carried out.
  • the application is generally represented by an acyclic data flow graph in which each array element is only updated once by the application.
  • the course of the application does not follow from external events or calculation results appearing during execution, which means that this course is predictable. In other words, the progress of the application is deterministic.
  • the invention applies to any type of TSS application, in particular to deterministic applications by parties.
  • deterministic applications by parts include deterministic processing sequences of limited duration, which follow one another in time in an order that is not predictable a priori. This is the case of multi-mode radar processing for example.
  • FIG. 1 illustrates an example of an application placement assistance workshop.
  • This workshop 100 includes an input interface 102 which makes it possible to enter an application that is not placed 101.
  • This input interface 102 which makes it possible to enter an application that is not placed 101.
  • the 102 is functionally linked to a model 105 of the target architecture forming an integral part of the workshop 100.
  • the user sometimes called “mapper”
  • partitions the application 101 Then the user 106 makes an assignment to the different resources of the modeled architecture 105.
  • the user 106 triggers a behavioral simulation driven by a simulation engine 103 included in the workshop 100.
  • the workshop 100 makes it possible to simulate the behavior of the modeled architecture 105.
  • a presentation interface 104 included in Workshop 100 makes it possible to present the results in terms of timing and occupation of memories as a function of time.
  • the user 106 repeats the placement iteratively until a satisfactory placement has been found.
  • the application 101 is then transformed into a set of single-processor applications, the executable code of which remains to be generated with usual means.
  • the placement of the application is manual, in the sense that the key decisions are left to the user 106.
  • the workshop 100 makes it possible to present the most appropriate information to assist the user 106.
  • the user first partitions the application according to the tasks into several primary partitions. Each primary partition is assigned to a subset of the target architecture. Then each primary partition is partitioned according to the data.
  • segment architecture each of the subsets of the target architecture on which calculations are carried out using data parallelism.
  • a level often corresponds to a resource in the architecture, such as an electronic card, on which other resources are placed, such as memories for example.
  • Each level includes elements, such as homogeneous sets on the one hand, and / or specific resources on the other. Homogeneous sets of a level can in turn include elements of a lower level.
  • FIGS 2a and 2b illustrate an example of repetitive segment architecture. This architecture has four levels. The first level
  • level 1 includes homogeneous sets, namely four electronic cards 201, 202, 203, 204, 205, and a specific resource, namely an inter-card communication network 200.
  • the inter-card communication network 200 connects the electronic cards to one another.
  • the electronic cards in turn comprise elements of lower level (level 2) 211, 212, 213, 210.
  • the electronic card 201 for example comprises homogeneous assemblies, namely three nodes 211, 212, 213, and a specific resource, namely a communication network internodes 210.
  • Each inter-node communication network 210 connects the nodes of the same card between them.
  • the internode communication network 210 comprises for example a bus.
  • the nodes 211, 212, 213 in turn comprise elements of lower level (level 3) 224, 225 222, 223.
  • the node 211 comprises two specific resources, namely an external RAM 222 and a internal RAM 223 on the other hand, and homogeneous sets, namely two computing units (UC) 224,225.
  • the calculation units 224, 225 in turn comprise lower level elements (level 4). This last level (not shown) includes specific resources only, these resources being elements of the calculation units.
  • the repetitive segment architecture illustrated in FIG. 2 includes the following specific resources and homogeneous sets:
  • the inter-node communication networks 210 can be grouped together in a one-dimensional INTER array comprising 5 elements.
  • Each element of the INTER array corresponds to the communication network 210 of an electronic card.
  • the external RAM memories 222 can be grouped in a two-dimensional RAM_EXT table, the first dimension comprising 5 elements, the second dimension comprising 3 elements.
  • the element RAM_EXT [i] [j] corresponds to the external RAM memory 222 of the i th electronic card, and of the j th nodes.
  • the internal RAM memories 223 can be grouped in a two-dimensional RAMJNT table.
  • the calculation units can be grouped in a three-dimensional UC table, the first dimension comprising 5 elements, the second dimension comprising 3 elements, and the third dimension comprising 2 elements.
  • the CPU element [i]] [] is the k th calculation unit of the ith electronic card, j ee nodes.
  • Array-OL from the Anglo-Saxon expression "array oriented language”
  • This array formalism is suitable for multi-dimensional signal processing.
  • Alain Demeure, Anne Lafage, Emmanuel Boutillon, Didier Rozzonelli, Jean-Claude Dufourd, and Jean-Louis Marro “Array-OL: Proposal of a table formalism for multi-dimensional signal processing. » In Grestsi, Juan-Les-Pins, France, September 1995.
  • the Array-OL formalism makes it possible to describe the location of data in an array accessed by a calculation task in reading (input array, or operand) or in writing (output array, or result). This description, made with the Array-OL formalism, is called the access specification of a task.
  • a task can be described from a specification of the calculations on the one hand, and from a specification of the accesses on the other. The specification of the accesses is distinct from the specification of the calculations performed by the task.
  • a calculation task can be broken down into a repetition of an elementary calculation performed on data having the same structure. This elementary calculation carried out during an iteration is called elementary transformation. At each iteration, the elementary transformation accesses part of the data from the operand tables and the result tables. These groups of data extracted from tables are called patterns. An operand pattern is associated with each operand table, and a result pattern is associated with each result array.
  • the patterns can be represented by one-dimensional arrays, with a determined number of elements.
  • a pattern can of course also be represented by a table with several dimensions. In order to facilitate understanding of this presentation, only one-dimensional array patterns will be used. The explanations provided are easily generalized to any type of pattern.
  • This calculation task makes it possible to carry out beam formation by calculation. It produces a 3-dimensional BF table (cd, channel, rec) from a three-dimensional ECH sample table (cd, ant, rec), and a table of two-dimensional COEF coefficients (channel, ant).
  • the dimensions cd, ant and rec of the ECH table correspond to a distance, a sensor, and a time. They are indexed respectively by the distance cell number num_cd, the antenna number num_ant, and the recurrence number num_rec.
  • the track and ant dimensions of the COEF table correspond to a track and a sensor.
  • the dimensions cd, channel and rec of the table BF are indexed respectively by the distance cell number num_cd, the channel number num_voie, and the recurrence number num-rec.
  • This elementary TE transformation uses two patterns operands M01 and MO2 of 8 elements each, and produces a result pattern MR of 1 element.
  • the specification of the calculations performed by a task is the set of calculations performed in an elementary transformation.
  • the specification of the calculations performed by the beam forming task by calculation is given by the relation
  • the elementary transformation TE is repeated by the task in one or more nested loops. These loops have clues associated with them.
  • the set of indices ni, n2, n3, ... can be associated with dimensions of a multidimensional space. This space has as many dimensions as there are nested loops, i.e. loop indices. Each dimension of this space is associated with a size: the number of iterations N1, N2, N3, ....
  • This tuple represents a finite dimension space, where each dimension corresponds to a loop index, and each size corresponds to a number of iterations.
  • the k th element of the tuple represents the number of iterations performed by the task according to the k th loop index. This space of finite dimension is called the iteration space of the task.
  • the operand patterns MOI, MO2 and the result pattern MR are associated with the input tables ECH, COEF and the output table BF respectively.
  • the link between the elements of a pattern and the elements of an array is the access specification of the task. In other words, the access specification makes it possible to determine the correspondence between the elements of a pattern and the elements of the associated array. This correspondence between the elements of a pattern and the elements of an array depends on the task's loop indices on the one hand, and on the indices used in the elementary transformation TE on the other.
  • the access specification can be broken down into three parts:
  • the first part is independent of the task loop indices or the indices used in the elementary transformation. It is the element taken as origin in the array. This first part of the access specification is called the origin. The origin gives the relationship between the first element of a pattern and an element of the array for the first iteration of the task.
  • the second part is linked to the indices used in the elementary transformation TE. In the example considered, there is only one index of TE, the index i. This second part is called adjustment. The adjustment gives the relationship between the other elements of a pattern and the elements of an array for the first iteration of the task.
  • the third part is linked to the task's loop indices. This third part is called paving.
  • the tiling gives relation between the indices of the pattern and of the table according to the loop indices of the task. The tiling can be seen as the displacement of the pattern in the table for the following iterations of the task.
  • the origin, fit and tiling of a pattern can be represented with vectors. These vectors have as many elements as the table associated with the pattern has indices, that is to say of dimensions:
  • the task has three loops nested on the indices ni, n2 and n3.
  • the loop index ni corresponds to the dimension cd for the ECH and BF tables.
  • the loop index n2 corresponds to the rec dimension for the ECH and CHANNEL tables.
  • the loop index n3 corresponds to the channel dimension for the COEF and BF tables.
  • the elements of the pattern M01 can be associated with the elements of the array ECH by the following relation:
  • MOl [i] ECH [0RG + i x AJ1 + ni x PAV1 + n2 x PAV2 + n3 x PAV3] (2)
  • the vectors of indices can be written from a linear combination of basic vectors of the natural vector space associated with an array.
  • the same names are used to represent the basic vectors and the associated dimensions.
  • AJ1 ant
  • PAV1 cd
  • PAV2 rec.
  • abbreviated notations can be used for the other COEF and BF tables.
  • the access specifications of the task, using abbreviated notations are given in the following table:
  • index indices used in the example because they do not provide any information (silent indices).
  • a column in the table corresponds to the same index (except for the origin). The number of iterations carried out by index is shown in bold type.
  • the vectors of indices equal to the basic vectors, and identical in the same column of the table. this is not a obligation. There may be different index names in the same column.
  • the index vectors can be a multiple or a linear combination of the unit vectors.
  • This description can be done with a text file for example. This description includes:
  • ⁇ elementary type> is a character string representing an elementary type.
  • This character string can be for example short, int, float, complex to represent respectively a short integer, a long integer, a real number and a complex number.
  • ⁇ array name> is a character string which will be used later in the file to refer to this array.
  • the syntax for declaring elementary transformations can be as follows:
  • ⁇ name of the elementary transformation> is a character string which will be used in the rest of the file to refer to this elementary transformation.
  • the job description syntax can be as follows
  • task ⁇ task name> do ⁇ number of iterations first dimension> ⁇ number of iteration 2 nd dimension> ... ⁇ number of iterations nth dimension> using ⁇ name of elementary transformation> array__in ⁇ name of 1 st input table> org ⁇ vector of origin index> aj ⁇ vector of adjustment indices> pav ⁇ vector of tiling indices corresponding to the 1st dimension-- ⁇ vector of tiling indices corresponding to the 2 nd dimension> ...
  • ⁇ number of iterations 1 st dimension> is an integer representing the number of iterations according to the first dimension of the iteration space of the task ⁇ name of the task>.
  • the whole numbers between the do and using keywords represent the task iteration space.
  • the character string following the keyword using is the name of an elementary transformation declared above in the file using the keyword transfom.
  • the string following the keyword array_ 90 or array_out is the name of an array defined earlier in the file using the keyword array.
  • index vectors which follow the keywords org, aj and pav represent respectively the origin, the adjustment and the tiling.
  • the number of index vectors following the pav keyword is equal to the number of dimensions of the task iteration space.
  • such an application description file can be using this syntax. It first includes a description of the tables giving the names, the dimensions of the tables and the number of elements per dimension.
  • the arrays are arrays of complex numbers called ECH, COEF, BF, REP, COMP, TWID and DOP:
  • the file then includes a declaration of the elementary transformations giving the name of the elementary transformations and the number of elements of the operand patterns and results.
  • the elementary transformations are called Mulac and FFT:
  • the file finally includes a description of the tasks giving the name of the tasks, the space for iteration of the tasks, the name of the elementary transformation used, the name of the input and output tables used, and the access specifications. associated with the tables (origin, adjustment, paving).
  • the tasks are called Beam Formation, Pulse Compression and Doppler Filter:
  • FIGS. 1 and 4. At the start of the placement, the user 106 opens a description of the application 101 not placed, such as that described in the file of the previous example. Workshop 100 can present a graph such as that illustrated in FIG. 4.
  • This graph can be generated by the input interface 102.
  • the graph can include windows A1, A2, A3, A4, A5 representing the tables ECH, COEF, REP, TWID and DOP. In these windows appear the information relating to the tables, for example the names of the dimensions and the number of elements per dimension. When a dimension does not have a name in the description file of the application 101, an arbitrary name such as "x1" can be assigned to it by the workshop 100.
  • the graph can also include windows T1, T2, T3 representing the Beam Formation, Pulse Compression and Doppler Filter tasks.
  • window In these windows appear the information relating to the tasks, such as for example the name of the elementary transformation used, a table grouping together the information concerning the iteration space and the access specifications (origin, adjustment, tiling).
  • Arrows F1, F2, F3, F4, F5, F6, F7 can be used to represent data inputs and outputs.
  • the arrows F1 and F2 come from windows A1 and A2 and arrive at window T1.
  • These arrows F1 and F2 signify that the tables ECH and COEF are inputs to the Beam Formation task.
  • the user then partitions the tasks according to the data.
  • the user modifies the iteration space of the tasks. It can add or remove dimensions to the iteration space, while keeping the total number of iterations constant.
  • the total number iteration is the product of the number of iterations of the dimensions of the iteration space.
  • the user can partition the TrainingBeam task according to the data by dividing one of the dimensions of the task iteration space by example.
  • the user can select column C1 of the window T1 and open a dialog box D1.
  • This dialog box D1 allows you to divide one dimension of the iteration space of the Beam Formation task (window T1) into several dimensions.
  • the starting dimension is then divided into several arrival dimensions. This starting dimension corresponds to column C1.
  • the user 106 enters the numbers of arrival iterations corresponding to the new dimensions. These iteration numbers can be separated by a comma.
  • the selected dimension includes 32 iterations.
  • the user enters "8, 4" in the D1 dialog box.
  • the starting dimension comprising 32 iterations is divided into two arrival dimensions comprising 8 and 4 iterations respectively.
  • the user 101 divides a dimension of the iteration space, he must verify that the total number of iterations remains constant. In other words, the product of the numbers of arrival iterations must be equal to the number of departure iterations. According to an advantageous embodiment, the workshop 100 can carry out this verification.
  • the arrival iteration space of the FormationBeam task includes 4 dimensions. These dimensions respectively include 1536, 8, 4 and 6 iterations.
  • the tiling is modified for the ECH and BF tables. These tables had the rec index vector associated with the second dimension of the starting iteration space (column C1). This second dimension has been replaced by two dimensions (columns C2 and C3).
  • the index vectors associated with the seconds and third dimensions of the arrival iteration space become rec and 8rec respectively.
  • the loop of 32 iterations on the index num_rec of step 1 is replaced by two nested loops of respectively 8 and 4 iterations on the index num_rec.
  • the first loop of 8 iterations has a step of 1. This loop is repeated 4 times by the second loop. Each time the first loop is repeated, the index num_rec a is incremented by 8.
  • the second loop on the index num_rec has a step of 8
  • the nesting order of the loops is determined implicitly by the workshop. This nesting order corresponds in our example to the order of entering the arrival dimensions.
  • the user has entered "8, 4" in the D1 dialog box. This means that the first nested loop has 8 iterations, and the second nested loop has 4.
  • An advantageous alternative embodiment of the workshop allows the user to explicitly specify the nesting order of the loops. For this purpose, the user enters for example the ratio between the pitch of the arrival loops and the pitch of the departure loop. These relationships can be represented by numbers in parentheses. Thus, instead of entering "8, 4" in the D1 dialog box, the user can enter "8 (1), 4 (8)” or “4 (8), 8 (1)” .
  • the access specification of the Beam Formation task before being partitioned can be represented in the following table:
  • the user assigns the tasks to the calculation units.
  • the space for iteration of the tasks to be assigned has been provisioned beforehand.
  • This partition of the iteration space is such that at least one dimension can correspond to a number of units of calculation of a segment of the target architecture.
  • the target architecture considered is a repetitive segment architecture. Consequently, the calculation units are arranged in a regular manner, so that they can be grouped in tables of identical elements.
  • the assignment of a calculation task is carried out by selecting certain dimensions of its iteration space on the one hand, and by making them correspond to the dimensions of an array of calculation units on the other hand go.
  • the dimensions of the iteration space selected during the allocation, which represented a repetition of an elementary calculation then represent a distribution of said calculation between the different calculation units.
  • the elementary calculation of this task is carried out in parallel by all the calculation units to which the task has been assigned.
  • Each calculation unit repeats the elementary calculation according to the other dimensions (not selected during allocation) of the iteration space.
  • FIG. 7 is illustrated a step for assigning a calculation task.
  • the user selects one or more dimensions of the iteration space of the task he wishes to assign to calculation units. To this end, the user selects for example column C2 of the window T1. This selection corresponds to the second dimension of the iteration space of the TrainingBeam task. Then the user opens a D2 dialog box allowing him to carry out the assignment. The number of iterations corresponding to the selected dimension can be recalled in a field D21 of this dialog box D2. Thanks to the target architecture model 105, the workshop can display all of the available segments, for example in a drop-down list D22 in the dialog box D2.
  • the user chooses for example a segment comprising the same number of elements as there are iterations per dimension, ie 8 elements in this example.
  • This segment can be represented by a table of calculation units.
  • the user chooses to assign the TrainingBeam task to a segment of 8 calculation units represented by the table P155MHz [8].
  • the calculation units to which the task has been assigned have read or write access to the elements of the input and output tables. During the execution of the application placed on the target architecture, these elements will be stored in memories of said architecture. Following a placement error, it may happen that this data is stored in memories inaccessible to the computing units.
  • the workshop provides the user with a means of verifying the accessibility of the data, and therefore of avoiding such placement errors. These errors are therefore detected at an early stage of development, even before the realization of a first prototype.
  • the user specifies the way in which the data is distributed in the different memories of the target architecture.
  • This specification of the data distribution can be done for each table of input or output of the tasks.
  • This specification of the distribution of the data contained in the table is called assignment of an array to memories.
  • the target architecture is a repetitive segment architecture
  • the memories can be grouped into identical memory tables.
  • the assignment of a data table to memories consists in distributing part of the data in the table in a memory table.
  • the first part is a reference to an element of array A taken as origin. This first part is called the origin table.
  • the second part is a reference to the memory of table M in which the element of table A corresponding to the table origin is stored. This second part is called the memory origin.
  • the third part makes it possible to determine for each memory of the array M in which at least one element of the array A is stored, a reference to a first element of the array A stored in said memory.
  • This third part is called the projector.
  • the reference to the first element of array A stored in the memory corresponding to the memory origin is the array origin. From the table origin, the memory origin, and the projector, it is possible to determine the reference to the first element of the table A stored in each of said memories.
  • the fourth part gives for each memory of the table M, from the reference to the first element of the table A stored in said memory, all of the other stored items. This fourth part is called the local motif.
  • the table origin, the memory origin, the spotlight and the local pattern can be represented with integers and index vectors. It is assumed in the following representation example that the distribution is homogeneous. In other words, it is assumed that the number of elements stored in array A is the same in each memory in array M. It is of course possible to use another representation for inhomogeneous distributions.
  • the array indices modulo the number of elements per dimension. For example, for a dimension of an array comprising 8 elements, the indices 0, 8, 16, 24 represent the same element of the array. Similarly, the indices 1, 9, 17, 25, ... represent the same element of the array. The indices 2, 10, 18, 26, ... represent the same element of the array ...
  • the representation can be as follows:
  • the table origin can be represented by a vector of ORGA indices comprising as many elements as the data table A has dimensions;
  • the memory origin can be represented by a vector of indices ORGM comprising as many elements as the array of memories M has dimensions;
  • the projector can be represented by vectors of indices VPR1, VPR2, VPR3, ... comprising as many elements as the data table A has dimensions on the one hand, and integers NPR1, NPR2,
  • the local pattern can be represented by vectors of indices VML1, VML2, VML3, ... comprising as many elements as the data table A has dimensions on the one hand, and integers NML1, NML2,
  • the memory M [i1, i2, i3, ...] contains NML1 NML2 ⁇ NML3 ⁇ ... elements of the array
  • ni, n2, n3, ... are whole numbers satisfying the following relationships:
  • FIG. 8 is shown an example of assignment of a data table A in a memory table M.
  • the data table A can have 3 dimensions, of size 100, 200, and 300 by example.
  • the memory table M can have 2 dimensions, of size 3 and 2.
  • the memory table M therefore includes 6 memories M1, M2, M3, M4, M5, M6. These 6 memories are ordered in table M as follows:
  • VPR2 (10,0,0) (18)
  • VML1 (20, 0, 0) (20)
  • the memory M2 corresponds to the origin memory ORGM defined in relation (14), that is to say the element M [1, 0] of the array M.
  • This memory M2 comprises the element of the array A corresponding to the ORGA array origin defined in relation (13), ie the element A [7,1, 5].
  • the local pattern NML1, VML1 makes it possible to determine the other elements of the array A contained in this memory M2.
  • the jump of indices between these elements is given by the vector of indices VML1.
  • the following NML1-1 elements contained in this memory M2 are determined using the vector VML1. These elements are A [27, 1, 5], A [47,1,5] and A [67,1, 5].
  • the first element of array A contained in the memory M3 can be determined using the projector. This first element can be referenced by the vector of indices ORGA + VPR1, ie A [7,3,5].
  • the following NML1-1 elements contained in this memory M3 are determined using the vector VML1. These elements are A [27,3,5], A [47,3,5], A [67,3,5].
  • the first element of the array A contained in the memory M5 can be determined using the projector.
  • This first element can be referenced by the vector of indices ORGA + VPR2, that is to say A [17,1, 5].
  • the following NML1-1 elements contained in this memory M5 are determined using the vector VML1. These elements are A [37, 1, 5], A [57.1, 5], A [77.1, 5J.
  • the first element of the array A contained in the memory M6 can be determined using the projector.
  • This first element can be referenced by the vector of indices ORGA + VPR1 + VPR2, ie A [17,3,5].
  • the following NML1-1 elements contained in this memory M5 are determined using the vector VML1. These elements are A [37,3,5], A [57,3,5], A [77,3,5].
  • the memories M1 and M4 of the memory table M do not contain elements of table A.
  • FIGS. 1, 9 and 10 a step of assigning the data table ECH to a table of memories DPRAM is illustrated.
  • the user selects the table he wishes to assign, ie the ECH table.
  • the user opens, for example, a dialog box D3 allowing him to carry out the assignment.
  • This dialog box can contain a field D31 recalling information on the table to be assigned, such as the name of the table, the names of its dimensions, the sizes of these dimensions.
  • field D31 contains the character string "ECH [cd: 1536] [ant: 8] [rec: 32]", recalling the name "ECH” in the table, the names “cd”, “ant”, “Rec” dimensions, and their sizes "1536", "8", "32”.
  • the workshop can display all of the available memory tables, for example in a drop-down list D32.
  • it chooses an array of 8 memories DR1, DR2, DR3, DR4, DR5, DR6, DR7, DR8, ordered in a one-dimensional array DPRam as follows:
  • the user can enter the information concerning the assignment of the ECH data table to the DPRam memory table in the D3 dialog box.
  • This information can be represented by the table origin, the memory origin, the projector, and the local pattern, in fields D33, D34, D35, and D36 of the dialog box D3.
  • the array origin and the memory origin in this example are null vectors.
  • the user enters "0" or equivalent "(0,0,0)" in field D33 of the D3 dialog box. He enters "0" in field D34.
  • the DPRam memory table having a dimension, the projector is represented by an integer and a clues vector. The integer chosen is 8, which corresponds to the number of memories in the table.
  • the vector of indices is (0,0,1) which can also be noted “rec”.
  • the projector is represented by a character string. This character string comprises an integer and a vector of indices separated by the symbol "*", possibly separated by a comma from the other integers and vectors of indices. The integers and the index vectors are placed in the order of the dimensions of the memory table. In this example, the projector may be marked "8 * rec”.
  • the local pattern is represented by a character string comprising an integer and a vector of indices separated by the symbol "*", possibly separated by a comma from the other integers and vectors of following indices.
  • the local pattern is represented by the character string "1536 * cd, 8 * ant, 4 * 8rec" in the field D36.
  • Each of the 8 memories therefore includes 1536 x 8x4, or 49152 elements of the ECH data table.
  • the distribution of this data in the memories DR1, DR2, DR3, DR4, DR5, DR6, DR7, DR8 of the memory table is illustrated in FIG. 10.
  • the memory DR1 includes the elements
  • the memory DR2 comprises the elements whose indices verify the relations (21), (22), (24) and the following relation:
  • the memory DR3 includes the elements whose indices verify the relations (21), (22), (24) and the following relation:
  • the memory DRi where i varies between 1 and 8, includes the elements whose indices verify the relations (21), (22), (24) and the following relation:
  • the output tables of the calculation tasks are automatically assigned to specific memories. These memories are those associated with the calculation units to which said calculation tasks have been assigned. Consequently, the user need only assign the tables which serve only as input, ie those which are not produced by any calculation task. In other words, the calculated data are automatically distributed in the memories by the workshop.
  • these data movements are represented by communication tasks.
  • a communication task allows you to change the memory location of the data in a table. In other words, a communication task allows you to change the assignment of a data table.
  • a communication task makes it possible to move all of the data in a table, or only part of its data.
  • a communication task corresponds to a succession of movements elementary. The elementary movements in the communication tasks are the equivalent of the elementary transformations in the calculation tasks.
  • a communication task has read access to an input table and write to an output table. The output table is a partial or total copy of the input table. The data are not changed during a communication. They are copied from the input table to the output table. However, the distributions of the input and output tables are different. Therefore, when copying data from the input table to the output table, there is movement of said data from an input memory to an output memory.
  • the communication task should be described from an access specification on the one hand, and from a movement specification on the other.
  • the access specification can be represented with index vectors corresponding to an origin, an adjustment and a tiling such as those used for calculation tasks.
  • the origin, the adjustment and the tiling make it possible to determine which elements of the input array and the output array are associated with an operand pattern and a result pattern.
  • the operand patterns and results are associated with an elementary movement.
  • Elementary movement is a transfer of a packet of data.
  • the elements of the operand pattern contain the data to be transferred during an elementary movement.
  • the operand motif can be represented by a data table, generally having several dimensions.
  • the result pattern is a copy of the operand pattern.
  • the number of elements of the operand pattern is equal to the number of data moved at each iteration of the communication task, that is to say by the elementary movement.
  • the motion specification is used to determine how this data moves. In other words, the motion specification makes it possible to determine for each element of the operand pattern, the arrival memory in which the corresponding element of the result pattern will be copied.
  • the motion specification is expressed independently of the iteration of the communication task. The workshop user can therefore create communication tasks, which allows him to specify the data movements himself. This makes it possible to obtain investments that are much more efficient than with known investment techniques.
  • the user wishes to move all the data from the ECH table, initially assigned to the DPRam table of 8 memories (illustrated in FIGS. 9 and 10), to a DataBO table of 8 memories.
  • the user selects the starting table and the finishing table, a copy of the starting table.
  • it opens a D4 dialog box to create a communication task.
  • This dialog box D4 comprises for example a field D41 recalling the name and the dimensions of the starting table. In this example, this field contains the character string "ECH [cd: 1536] [ant: 8] [rec: 32]".
  • This dialog box can also include a zone D42 in which are recalled the information relating to the assignments of departure and arrival, that is to say the assignment of the starting table to the table of memories DPRam memories, and the assignment of the Arrival table to the DataBO memory table.
  • the user can enter the motion specification and the access specification in two areas D43 and D44 of the D4 dialog box.
  • the user can choose an elementary movement from a drop-down list D45 in the area D43.
  • This drop-down list D45 contains a set of predefined elementary movements.
  • the user chooses an elementary movement “DPRam_DataB0” which makes it possible to move data from the table of memories DPRam to the table of memories DataBO.
  • This elementary movement uses an operand pattern whose dimensions can be given in two fields D46 and D47 in the area D43.
  • the first field D46 comprises one or more whole numbers separated by commas, each number representing the size of a dimension of the operand pattern. All the dimensions of field D46 correspond to dimensions of the starting memory table.
  • field D46 contains the character string "8". Consequently, the operand pattern has a dimension of size 8 corresponding to the unique dimension of the array of memories DPRam.
  • the second field D47 comprises one or more whole numbers separated by commas, each number representing the size of a dimension of the operand pattern. These dimensions correspond to dimensions internal to any of the memories of the starting memory table.
  • the product of the numbers contained in the field D47 is equal to the number of elements of the data table contained in a memory of the starting memory table.
  • field D47 contains the character string "1". Consequently, the operand motif has only one element per memory.
  • the operand pattern is therefore an array of 8 one-dimensional elements, each element of the operand pattern being in a memory different from the DPRam array [8].
  • the user can enter the memory offset and the number of the starting memory in two fields D48 and D49 in the area D43.
  • the origin is a vector of indices which can be the null vector as in this example, or a linear combination of the vectors cd, ant and rec in this example.
  • the adjustment includes as many index vectors as the operand pattern has dimensions.
  • the order of the index vectors can be that of the dimensions of the operand pattern.
  • the user can also enter the number of associated elements per index vector. This number of elements is equal to the size of the associated dimension of the operand pattern, which corresponds to number of elements to be moved according to this dimension.
  • field D51 contains the character string "8 * rec".
  • the index vector associated with the single dimension of the operand pattern is rec.
  • the number of elements to be moved according to this dimension is 8.
  • the tiling includes several integers corresponding to a number of iterations, and vectors of indices associated with these integers.
  • Field D52 contains the character string "1536 * cd, 8 * ant, 4 * 8rec". There are three nested loops of respectively 1536, 8 and 4 iterations. The index vectors associated with these loops are respectively cd, ant and 8rec.
  • the access specification of the communication task entered by the user can be represented by the following table:
  • FIGS. 12, 13a and 13b in which another example of the creation of a communication task is illustrated.
  • the user wishes to change the arrangement of the data in the COMP table in the DPRam table of 8 memories DR1, DR2, DR3, DR4, DR5, DR6, DR7, DR8.
  • the user selects the starting table and the finishing table, a copy of the starting table. Then it opens the D4 dialog box to create a communication task.
  • the fields of this dialog box have been described in figure 11.
  • the data table involved in the communication task is the COMP table. This table has three dimensions track, rec and cd of size 6, 32, 1536.
  • the starting assignment i.e. the assignment of the table whose data must be moved by the communication task, can be given by the following relationships:
  • each DPRam memory [i] comprises the elements COMP [channel _ num, num _ rec, num _cd] whose indices verify the following relationships:
  • VPR1 cd (45)
  • each DPRam memory [i] includes the elements COMP [channel_num, rec_num, num _cd] whose indices verify the following relationships:
  • the communication task allowing to pass from the departure assignment to the arrival assignment must swap the rec and cd dimensions of the projector.
  • the user chooses an elementary movement from the drop-down list D45 in the area D43.
  • the user chooses an elementary movement "CT_DPRam" which allows to swap the dimensions of a two-dimensional data table assigned to a one-dimensional memory table.
  • FIG. 13a and 13b illustrate this elementary movement.
  • the operand motif corresponding to this elementary movement is a two-dimensional array, each dimension having a size of 8.
  • the operand motif elements are distributed in groups of 8 in each of 8 memories DR1, DR2, DR3, DR4, DR5, DR6 , DR7, DR8.
  • the indices i and j are used to refer to the first and second dimensions of the operand pattern.
  • the elements of the operand pattern are numbered in FIG. 13a from 1 to 64.
  • the number n of the element of the operand pattern is linked to the indices i and j by the following relation:
  • the distribution of the elements of the operand motif is illustrated in FIG. 13a.
  • the memory DR1 contains the elements 1 to 8 of the operand pattern, that is to say those for which the index i is equal to 0.
  • the memory DR2 contains the elements 9 to 16 of the operand pattern, that is to say those for which the 'index i is worth 1.
  • the memory DR3 contains the elements 17 to 24 of the operand pattern, that is to say those for which the index i is worth 2.
  • the memory DR4 contains the elements 25 to 32 of the operand pattern, it is ie those for which the index i is worth 3. ...
  • the memory DR8 contains the elements 57 to 64 of the operand pattern, that is to say those for which the index i is worth 7.
  • the result pattern is a copy of the operand pattern.
  • the same numbering and the same indices are used to refer to the elements of the result pattern.
  • the distribution of the elements of the result pattern is illustrated in FIG. 13b.
  • Memory DR1 contains elements 1, 9, 17, 25, 33, 41, 49, 57 of the result pattern, that is to say those for which the index j is equal to 0.
  • the memory DR2 contains the elements 2, 10, 18, 26, 34, 42, 50, 58 of the result pattern, that is to say those for which the index j is worth 1.
  • the memory DR3 contains the elements 3, 11, 19, 27, 35, 43, 51, 59 of the result pattern, that is to say those for which the index j is 2.
  • the memory DR4 contains the elements 4, 12, 20, 28, 36, 44, 52, 60 of the result pattern, that is to say those for which the index j is equal to 3.
  • the memory DR8 contains the elements 8, 16, 24, 32, 40, 48, 56 of the result pattern, i.e. those for which the index j is 7.
  • the elements memorized in each memory are distributed in all of the memories.
  • the elements 1, 2, 3, 4, 5, 6, 7, 8 of the operand pattern stored in the memory DR1 are distributed in the memories DR1, DR2, DR3, DR4, DR5, DR6, DR7, DR8.
  • the user enters the origin, the adjustment and the tiling of this communication task.
  • the origin, fit, and tiling are as follows:
  • This communication task is called a transposition or a permutation because two dimensions of an array have been permuted in memories. These dimensions are in this example rec and cd.
  • FIGS. 14, 15a and 15b in which another example of the creation of a communication task is illustrated.
  • the user wishes to group the data from the COMP table, initially distributed on a DataC table of 8 memories DC1, DC2, DC3, DC4, DC5, DC6, DC7, DC8 in 4 of these memories DC1, DC2, DC3, DC4 belonging to the same dimension.
  • the DataC array is a 2-dimensional array.
  • the first dimension has a size of 4.
  • the second dimension has a size of 2.
  • the 8 memories are ordered in the DataC table as follows:
  • the user selects the starting table COMP and the finishing table, a copy of the starting table. Then it opens a dialog box to create a communication task.
  • each DataC memory [i, j] includes the COMP elements [channel_num, rec_num, num_cd] whose indices verify the following relationships:
  • each DataC memory [i, ⁇ ] includes the COMP elements [channel_num, rec_num, num_cd] whose indices verify the following relationships:
  • num _ rec 4 xk + i (62) 0 ⁇ k ⁇ 8 (63)
  • the communication task making it possible to pass from the departure assignment to the arrival assignment must group together in the same memory certain elements of the table COMP initially stored in different memories.
  • the user chooses an elementary movement from the drop-down list D45 in the area D43.
  • the user chooses an elementary movement “GT_DataC” illustrated in FIGS. 15a and 15b.
  • the operand motif corresponding to this elementary movement is a two-dimensional table.
  • the first dimension has a size of 4.
  • the second dimension has a size of 2.
  • the elements of the operand pattern illustrated in FIG. 15a are distributed in the memories DC1, DC2, DC3, DC4, DC5, DC6, DC7, DC8.
  • the indices i and j are used to refer to the first and second dimensions of the operand pattern.
  • the elements of the operand motif are numbered in FIG. 15a from 1 to 8.
  • the number n of the operand motif element is linked to the indices i and j by the following relation:
  • n i + 4 x j + 1 (65)
  • the memory DC1 contains the element 1 of the operand pattern, ie the one for which i is worth 0 and j is worth 0.
  • the memory DC2 contains the element 2 of the operand pattern, ie the one for which i is worth 1 and j is worth 0.
  • the memory DC3 contains the element 3 of the operand pattern, that is to say the one for which i is worth 2 and j is 0.
  • the memory DC4 contains the element 4 of the operand pattern, it is at say the one for which i is worth 3 and j is worth 0.
  • the memory DC5 contains the element 5 of the operand pattern, that is to say the one for which i is worth 0 and j is 1.
  • the memory DC6 contains the element 6 of the pattern operand, that is to say the one for which i is worth 1 and j is worth 1.
  • the memory DC7 contains the element 7 of the operand pattern, that is to say the one for which i is worth 2 and j is 1.
  • the memory DC8 contains element 8 of the operand pattern, that is, one for which i is 3 and j is 1.
  • the result pattern is a copy of the operand pattern.
  • the same numbering and the same indices are used to refer to the elements of the result pattern.
  • the distribution of the elements of the result pattern is illustrated in FIG. 15b.
  • the memory DC1 contains the elements 1 and 5 of the result pattern, ie those for which the index i is equal to 0.
  • the memory DC2 contains the elements 2 and 6 of the result pattern, ie those for which l index i is equal to 1.
  • the memory DC3 contains the elements 3 and 7 of the result pattern, that is to say those for which the index i is equal to 2.
  • the memory DC4 contains the elements 4 and 8 of the result pattern, that is ie those for which the index i is worth 3.
  • the user enters the origin, the adjustment and the tiling of this communication task.
  • the origin, fit, and tiling are as follows:
  • the workshop can carry out verifications when entering a communication task, and indicate the possible errors by an error message for example.
  • errors can for example concern the access specification.
  • the adjustment entered by the user may be incompatible with the operand pattern, for example if the number of elements involved in the adjustment is different from the number of elements in the operand pattern. These errors may concern the motion specification.
  • the elementary movement chosen by the user may be incompatible with the initial assignment, for example if the memories involved in the assignment and the elementary movement are different at the start.
  • the user can enter elementary movements not initially present in the drop-down list D45 in the area D43 of the dialog box D4. These new elementary movements can then be added to the drop-down list.
  • the user can enter tasks calling on other communication and / or calculation tasks. These tasks are called call tasks.
  • a call task allows you to repeat a call to other calculation or movement tasks for example.
  • a call task can also repeat a call to other tasks call.
  • the call task iteration space contains one or more dimensions. All the dimensions of the call task iteration space are contained in the call task iteration spaces.
  • the input tables of the called tasks are the input tables of the call task.
  • the output tables of the called tasks not used only as the input table of one of the called tasks are the output tables of the call task.
  • FIGS. 16a and 16b in which the creation of a calling task is illustrated.
  • the user wants to create a task calling the TrainingBeam task represented by the window.
  • T1 on the one hand, and calling the Compressionlmpulsion task represented by the T2 window on the other.
  • it selects the two windows T1 and T2 with a selection rectangle S1 made with the mouse for example.
  • This selection rectangle encompasses the two windows T1 and T2. This rectangle makes it possible to materialize the inputs and outputs of the call task. So the arrows
  • F1, F2, and F4 correspond to the entries of the call task which will be created.
  • the arrow F5 corresponds to the output of the call task which will be created.
  • the input tables of the call task will therefore be ECH, COEF, and REP.
  • the COMP table will be the output table for this call task.
  • the iteration space of the TrainingBeam task includes 4 dimensions represented by columns C11, C12, C13, C14.
  • the iteration space of the Compressionlmpulsion task includes 4 dimensions represented by columns C21, C22, C23, C24.
  • the dimensions corresponding to columns C11 and C21 have already been assigned to calculation units during previous assignment steps.
  • Columns C11 and C21 can be represented differently using a dark background instead of a light background, so as to remind the user that the dimensions corresponding to these columns have already been assigned to calculation units.
  • These dimensions cannot be dimensions of the iteration space of the call task. Indeed, it no longer corresponds to a repetition of an operation, but to a distribution of this operation over several calculation units.
  • the user opens a dialog box, not shown, in order to enter the iteration space of the new call task, indicating the correspondence between the dimensions of this iteration space and the dimensions of the iteration spaces. called tasks.
  • the user can place the columns C11, C12, C13, C14 and C21, C22, C23, C24 of the windows T1 and T2 in a determined order, so that the rightmost columns of the correspond in the the columns in the iteration space of the new call task.
  • the user then only has to enter the number of dimensions of the iteration space of the call task.
  • the iteration space of the call task includes a dimension. This dimension of the iteration space of the call task corresponds to columns C14 and C25 of windows T1 and T2.
  • the created call task is then represented by a new window T4 illustrated in FIG. 16b.
  • This new window T4 replaces the windows T1 and T2 in FIG. 16a.
  • the iteration space of this call task has only one dimension represented by a column C41.
  • the other dimensions of the iteration spaces of the called tasks become dimensions of the adjustment of this new task.
  • the user can repeat the different operations of partitioning, assignment and creation of tasks until obtaining a correct placement.
  • the user adds communication tasks and call tasks. All these tasks have a common general structure which allows the user to handle them in the same way. In particular, this allows the user to group communication tasks and calculation tasks in the same call task. By making such groupings, the user can avoid having to resort to “swap” procedures. Indeed, the user can take advantage of a symmetry of the calculations to make calculations in cascades on blocks of data. To this end, it combines the different calculations represented by several calculation tasks, in a single call task. In the example illustrated in FIGS.
  • the user has grouped two calculations, which makes it possible to avoid having to use a “swap” method to memorize the elements of the table BF. These elements will be calculated, temporarily stored in small memories accessible to the calculation units, then used. In a conventional placement, these data would have been stored in another larger memory, but not accessible to the calculation units.
  • the invention makes investments more efficient by reducing the number of communications required.
  • the communications saved are those making it possible to transfer the data from the LF table calculated by the Beam Formation task into a memory having a large capacity on the one hand, and the communication making it possible to transfer the data from the LF table stored in this memory for their use by the Compressionlmpulsion task on the other hand.
  • the workshop therefore allows the user to optimize data movements.
  • a call task can call another call task, which in turn can call another call task.
  • a hierarchy of tasks can be defined, the hierarchical level of a task depending on the level of nesting of the task. Calculation or communication tasks are the lowest level tasks. This level can be numbered zero (0).
  • a call task calling a task of level n belongs to the higher level n + 1. Thus, a call task calling calculation tasks is of level 1. When a task calls tasks of different levels, it is the task with the highest level which is used to determine the level of the task. call.
  • the set of higher level tasks is first presented to the user by the input interface.
  • the user wishes to modify a task of lower level, he can for example double click on the window representing the calling task (the one of higher level). This window is then replaced by the windows representing the called tasks. The user repeats this operation until arriving at the task called who interests him.
  • the user can then modify the parameters of the called task. All the tasks called by a call task have at least one dimension of the iteration space corresponding to one dimension of the iteration space of the call task. If the user modifies (by partitioning for example) this dimension for one of the tasks, he must make the same modification for all the other tasks. In order to avoid errors, these modifications can be prohibited by the workshop in the called tasks once the call task has been created. If the user wishes to modify this dimension, he can then do so from the window representing the call task.
  • the user can test it with a behavioral simulation.
  • the simulation engine integrated into the workshop makes it possible to check the execution time of the application on the target architecture, the use of resources and in particular the memory filling rate. The more detailed the architecture model, the finer the results.
  • FIGS. 17a and 17b are shown results of simulation of the execution time. These results can be displayed by the presentation interface 104 of the workshop.
  • the results of this simulation can be presented in the form of a GR graph.
  • This GR graph is a chronogram representing the execution time of calculation or communication tasks for example. Time is represented there along a horizontal axis. The execution of the various tasks is represented on lines GL1, GL2, GL3, GL4, GL5 of the graph.
  • FIG. 17a the timing diagram corresponds to an application placed but very little optimized. By using the workshop, the user optimizes the placement of his application. The result of the simulation of this better placed application is illustrated in Figure 17b.
  • the placement information can be reused if part of the architecture is modified without its structure being modified. It then suffices to modify the architecture model. This makes it possible to test the performance of an application already placed, having already been implemented on a particular target architecture, when one component of said architecture is replaced by another.
  • the placement information may be presented in another form.
  • the architecture model can be stored in a file used by the workshop, and not be part of the workshop.
  • the simulation engine can be an external simulation program.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Complex Calculations (AREA)
  • Underground Structures, Protecting, Testing And Restoring Foundations (AREA)
  • Catching Or Destruction (AREA)
  • Separation Using Semi-Permeable Membranes (AREA)
  • Devices For Executing Special Programs (AREA)
  • Radar Systems Or Details Thereof (AREA)

Abstract

La présente invention concerne un procédé de placement d'applications multiprocesseurs. Le procédé comprend au moins les étapes suivantes: a) une étape de partitionnement suivant les données d'une application préalablement partitionnée en tâches de calcul; b) une étape d'affectation desdites tâches de calcul, partitionnées suivant les données, à des unités de calcul de l'architecture cible; c) une étape de saisie de tâches de communication, lesdites tâches de communication permettant de copier totalement ou partiellement les données d'un tableau départ vers un tableau d'arrivée, ledit tableau de départ affecté à des mémoires de départ de l'architecture cible, ledit tableau d'arrivée étant affecé à des mémoires d'arrivée de l'architecture cible. L'invention s'applique notamment au placement d'applications déterministes nécessitant une forte puissance de calcul, telles que les traitements de signaux systématiques (TSS) des radars, les traitements d'images, ou les compressions de données temps réel.

Description

PROCEDE DE PLACEMENT D'APPLICATIONS MULTIPROCESSEURS.
La présente invention concerne un procédé de placement d'applications multiprocesseurs. Elle s'applique notamment au placement d'applications déterministes nécessitant une forte puissance de calcul, telles que les traitements de signaux systématiques (TSS) des radars, les traitements d'images, ou les compressions de données temps réel.
On appelle application multiprocesseur une application destinée à être exécutée sur une architecture multiprocesseur. Une architecture comprend des éléments matériels (dits « hardware » dans la littérature anglo-saxonne) et des éléments logiciels (dits « software » dans la littérature anglo-saxonne). Les éléments matériels comprennent par exemple des . processeurs, des mémoires, des circuits spécialisés, et des bus de données. Les éléments logiciels comprennent par exemple un jeu d'instructions de base, dit API (de l'expression anglo-saxonne « Application Programming
Interface »), des programmes de communication bas niveau, et un ordonnanceur. Les éléments matériels d'une architecture s'appellent aussi des ressources. Les éléments logiciels d'une architecture s'appellent aussi des services.
Le placement est une opération intervenant lors du développement d'applications multiprocesseurs. Il consiste à transformer une application décrite de manière fonctionnelle en un ensemble de sous- applications destinées chacune à l'un des processeurs d'une architecture cible. Lors de l'étape de placement, on cherche à faire exécuter des calculs en parallèle par plusieurs processeurs de l'architecture cible. Une première manière d'exécuter des calculs en parallèle, appelée parallélisme de tâche, consiste à répartir des tâches différentes sur plusieurs processeurs ou groupes de processeurs, Les différentes tâches s'exécutent alors en même temps sur des processeurs ou groupes de processeurs différents. Une seconde manière d'exécuter des calculs en parallèle, appelée parallélisme de données, consiste à répartir une même tâche sur plusieurs processeurs. Selon ce second mode de fonctionnement, dit SIMD ou SPMD (« Single Instruction Multiple Data » ou « Single Program Multiple Data »), plusieurs processeurs exécutent alors en même temps et de façon synchronisée des calculs correspondant à une même tâche, mais sur des données différentes.
Le placement comprend généralement une étape appelée partitionnement, une étape appelée affectation et une étape appelée ordonnancement. Le partitionnement consiste, à partir d'une application décrite de manière fonctionnelle, à déterminer des étapes de calculs élémentaires appelées tâches d'une part, et / ou à partager des blocs de données homogènes en blocs de données élémentaires d'autre part. L'affectation, connue sous le nom de « mapping » dans la littérature anglo- saxonne, consiste à allouer les tâches élémentaires et les blocs de données élémentaires aux éléments de l'architecture tels que des processeurs pour des tâches, et des mémoires pour des blocs de données. L'ordonnancement consiste à déterminer la chronologie d'exécution des tâches. L'architecture multiprocesseur choisie est souvent appelée architecture cible. L'application peut être décrite de manière fonctionnelle par un logiciel de haut niveau ou par une représentation graphique ou DFG (de l'expression anglo-saxonne « Data Flow Graph »). Les tâches peuvent être décrites sous une forme manipulable par des outils de génération de code (compilateurs par exemple), ou sous forme de codes utilisables par des processeurs élémentaires.
Un bon placement permet d'assurer un bon rendement de l'architecture, c'est à dire une exploitation presque optimale de ses ressources. Par conséquent, un tel placement permet d'économiser des composants matériels dans l'architecture. Une architecture cible peut passer par exemple de 20 cartes électroniques à 10 cartes électroniques, grâce à un meilleur placement d'une même application.
II apparaît donc que pour de tels systèmes, le placement d'une application sur une architecture cible est crucial. Pour des systèmes nécessitant une forte puissance de calcul, le placement est complexe, par conséquent long et coûteux. Outre ces problèmes de temps et coût, il faut ajouter des problèmes de fiabilité. En effet, on peut introduire des erreurs liées à la gestion de la mémoire par exemple : en appliquant un calcul à de mauvaises données, ou en saturant une mémoire. Ces erreurs apparaissent souvent très tard, généralement lors de la réalisation des prototypes. Elles sont dures à identifier car les causes peuvent être multiples.
Un but de l'invention est de pallier aux inconvénients précités et notamment de permettre de faciliter le placement d'applications, en le rendant plus rapide, et en permettant d'effectuer une vérification de l'intégrité du placement.
A cet effet l'invention concerne un procédé de placement d'applications multiprocesseurs sur une architecture cible, et un dispositif permettant de mettre en œuvre le procédé. Le procédé comprend au moins les étapes suivantes :
(a) une étape de partitionnement suivant les données d'une application préalablement partitionnée en tâches de calcul ;
(b) une étape d'affectation desdites tâches de calcul, partitionnées suivant les données, à des unités de calcul de l'architecture cible ;
(c) une étape de saisie de tâches de communication, lesdites tâches de communication permettant de copier totalement ou partiellement les données d'un tableau départ vers un tableau d'arrivée, ledit tableau de départ affecté à des mémoires de départ de l'architecture cible, ledit tableau d'arrivée étant affecté à des mémoires d'arrivée de l'architecture cible.
Selon un mode de réalisation avantageux, la saisie d'une tâche de communication lors de l'étape (c) est réalisée en spécifiant d'une part :
(a) une étape de spécification d'un mouvement élémentaire, ledit mouvement élémentaire consistant à copier les éléments d'un motif opérande dans un motif résultat, ledit mouvement élémentaire étant répété plusieurs fois par la tâche de communication ; et d'autre part,
(b) une étape de spécification d'accès, ledit accès comprenant d'une part la relation entre les éléments du motif opérande avec les données du tableau de départ, et d'autre part la relation entre les éléments du motif résultat avec les données du tableau d'arrivée. Selon un autre mode de réalisation avantageux, le procédé comprend en outre une étape de saisie de tâches d'appel, lesdites tâches d'appel faisant appel à d'autres tâches de communication et/ou de calcul et/ou d'appel.
Selon un autre mode de réalisation avantageux, le procédé comprend en outre une étape de simulation permettant de tester l'application placée lors des étapes précédentes.
L'invention a pour principaux avantages qu'elle permet de déterminer le temps d'exécution sur l'architecture cible de l'application placée, alors même que ladite architecture cible n'existe pas encore.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard de dessins annexés qui représentent :
• la figure 1, un schéma synoptique d'un exemple d'atelier d'aide au placement d'applications permettant de mettre en œuvre le procédé selon l'invention ; • les figures 2a et 2b, un exemple d'architecture cible ayant une structure symétrique ;
• la figure 3, un exemple de tâche de calcul d'une application radar ;
• la figure 4, un exemple des informations affichées par l'interface de saisie de l'atelier illustré figure 1 ; • les figures 5, 6, 7, 9, 11, 12, 14, 16a, 16b, des exemples de vues affichées par l'interface de saisie de l'atelier lors d'étapes du placement ;
• les figures 8, 10, 13a, 13b, 15a, 15b, des exemples de tableaux de mémoires d'une architecture cible ;
• les figures 17a et 17b, des exemples de résultats d'une simulation du temps d'exécution d'une application placée sur une architecture cible avec l'atelier illustré figure 1.
On décrit maintenant un exemple non limitatif de placement selon l'invention d'une application radar de TSS. L'application de TSS considérée comprend des séquences de tâches, appelées nids de boucles, bien structurées et parallèles. Chaque nid de boucles contient un appel à une procédure ou macro-instruction correspondant en général à une transformation de tableau c'est à dire à une fonction d'une librairie de traitement du signal telle qu'une FFT. Les traitements sont réguliers et s'effectuent sur des signaux multidimensionnels, les données sont organisées en tableaux dont les dimensions (par exemple source, fréquence, temps récurrence, temps pointage) portent les vecteurs sur lesquels vont s'effectuer les traitements individuels. L'application est globalement représentée par un graphe de flot de données acyclique dans lequel chaque élément de tableau n'est mis qu'une seule fois à jour par l'application. Enfin, le déroulement de l'application ne découle pas d'événements extérieurs ni de résultats de calcul apparaissant lors de l'exécution, ce qui fait que ce déroulement est prévisible. En d'autres termes, le déroulement de l'application est déterministe.
Bien entendu, l'invention s'applique à tout type d'application de TSS, notamment aux applications déterministes par parties. Ces applications déterministes par parties comprennent des séquences de traitements déterministes de durée limitée, qui se succèdent dans le temps dans un ordre non prévisible a priori. C'est le cas des traitements radar multi-mode par exemple.
La figure 1 illustre un exemple d'atelier d'aide au placement d'applications. Cet atelier 100 comprend une interface de saisie 102 qui permet de saisir une application non placée 101. Cette interface de saisie
102 est reliée fonctionnellement à un modèle 105 de l'architecture cible faisant partie intégrante de l'atelier 100. Grâce aux commandes de l'interface de saisie 102 et sous contrôle d'opérations de vérifications incluses dans l'atelier 100, l'utilisateur (appelé parfois « mappeur ») 106 partitionne l'application 101. Puis l'utilisateur 106 réalise une affectation aux différentes ressources de l'architecture modélisée 105. Enfin, l'utilisateur 106 déclenche une simulation comportementale conduite par un moteur de simulation 103 inclus dans l'atelier 100. L'atelier 100 permet de simuler le comportement de l'architecture modélisée 105. Une interface de présentation 104 incluse dans l'atelier 100 permet de présenter les résultats en termes de timing et d'occupation des mémoires en fonction du temps. L'utilisateur 106 répète le placement de façon itérative jusqu'à ce qu'un placement satisfaisant ait été trouvé. L'application 101 est alors transformée en un ensemble d'applications mono-processeurs dont il reste à générer le code exécutable avec des moyens usuels.
Le placement de l'application est manuel, dans le sens où les décisions clés sont laissées à l'utilisateur 106. L'atelier 100 permet de présenter les informations les plus appropriées pour aider l'utilisateur 106.
Parmi ces informations, certaines proviennent d'une simulation comportementale de l'architecture.
En utilisant l'atelier, l'utilisateur partitionne d'abord l'application suivant les tâches en plusieurs partitions primaires. Chaque partition primaire est affectée à un sous-ensemble de l'architecture cible. Puis chaque partition primaire est partitionnée suivant les données. On appelle architecture segment chacun des sous-ensembles de l'architecture cible sur lequel s'effectuent des calculs mettant en œuvre du parallélisme de données.
On appelle architecture segment répétitive, une architecture segment dont les ressources sont agencées d'une manière régulière, de manière à pouvoir être regroupées dans des tableaux d'éléments identiques. Lorsque ces tableaux ont plusieurs dimensions, ces dimensions peuvent se représenter par des niveaux. Un niveau correspond souvent à une ressource de l'architecture, telle qu'une carte électronique, sur laquelle sont disposées d'autres ressources, telles que des mémoires par exemple. Chaque niveau comprend des éléments, tels que des ensembles homogènes d'une part, et / ou des ressources spécifiques d'autre part. Les ensembles homogènes d'un niveau peuvent comprendre à leur tour des éléments de niveau inférieur.
Les figures 2a et 2b illustrent un exemple d'architecture segment répétitive. Cette architecture comprend quatre niveaux. Le premier niveau
(niveau 1) comprend des ensembles homogènes, à savoir quatre cartes électroniques 201 , 202, 203, 204, 205, et une ressource spécifique, à savoir un réseau de communication inter-cartes 200. Le réseau de communication inter-cartes 200 relie les cartes électroniques entre elles.. Les cartes électroniques comprennent à leur tour des éléments de niveau inférieur (niveau 2) 211, 212, 213, 210. La carte électronique 201 par exemple comprend des ensembles homogènes, à savoir trois nœuds 211, 212, 213, et une ressource spécifique, à savoir un réseau de communication internœuds 210. Chaque réseau de communication inter-nœuds 210 relie les nœuds d'une même carte entre eux. Le réseau de communication internœuds 210 comprend par exemple un bus. Les nœuds 211, 212, 213 comprennent à leur tour des éléments de niveau inférieur (niveau 3) 224, 225 222, 223. Par exemple le nœud 211 comprend deux ressources spécifiques, à savoir une mémoire RAM externe 222 d'une part et une mémoire RAM interne 223 d'autre part, et des ensembles homogènes, à savoir deux unités de calcul (UC) 224,225. Les unités de calcul 224, 225 comprennent à leur tour des éléments de niveau inférieur (niveau 4). Ce dernier niveau (non représenté) comprend des ressources spécifiques uniquement, ces ressources étant des éléments des unités de calculs.
En d'autres termes, l'architecture segment répétitive illustrée figure 2 comprend lesressources spécifiques et les ensembles homogènes suivants :
Figure imgf000009_0001
Les réseaux de communication inter-nœuds 210 peuvent être regroupés dans un tableau INTER à une dimension comprenant 5 éléments.
Chaque élément du tableau INTER correspond au réseau de communication 210 d'une carte électronique. Les mémoires RAM externes 222 peuvent être regroupées dans un tableau RAM_EXT à deux dimensions, la première dimension comprenant 5 éléments, la seconde dimension comprenant 3 éléments. L'élément RAM_EXT[i][j] correspond à la mémoire RAM externe 222 de la ieme carte électronique, et du jeme nœuds. De la même façon, les mémoires RAM internes 223 peuvent être regroupées dans un tableau RAMJNT à deux dimensions. Les unités de calculs peuvent être regroupées dans un tableau UC à trois dimensions, la première dimension comprenant 5 éléments, la seconde dimension comprenant 3 éléments, et la troisième dimension comprenant 2 éléments. L'élément UC[i] '][ ] correspond à la keme unité de calcul de la ième carte électronique, du je e nœuds.
Afin de faciliter la compréhension de cet exposé, nous utilisons un formalisme tableau, dit Array-OL (de l'expression anglo-saxonne « array oriented language »). Ce formalisme tableau est adapté aux traitements de signaux multi-dimensionnels. On pourra se référer au document de Alain Demeure, Anne Lafage, Emmanuel Boutillon, Didier Rozzonelli, Jean-Claude Dufourd, et Jean-Louis Marro, « Array-OL : Proposition d'un formalisme tableau pour le traitement de signal multi-dimensionnel. », à Grestsi, Juan- Les-Pins, France, Septembre 1995.
Le formalisme Array-OL permet de décrire l'emplacement des données dans un tableau auxquelles accède une tâche de calcul en lecture (tableau d'entrée, ou opérande) ou en écriture (tableau de sortie, ou résultat). Cette description, faite avec le formalisme Array-OL, s'appelle la spécification des accès d'une tâche. Une tâche peut être décrite à partir d'une spécification des calculs d'une part, et d'une spécification des accès d'autre part. La spécification des accès est distincte de la spécification des calculs effectués par la tâche.
Une tâche de calcul peut se décomposer en une répétition d'un calcul élémentaire effectué sur des données ayant une même structure. On appelle transformation élémentaire ce calcul élémentaire réalisé lors d'une itération. A chaque itération, la transformation élémentaire accède à une partie des données des tableaux opérande et des tableaux résultat. Ces groupes de données extraites des tableaux s'appellent des motifs. A chaque tableau opérande est associé un motif opérande, et à chaque tableau résultat est associé un motif résultat. Les motifs peuvent être représentés par des tableaux à une dimension, ayant un nombre d'éléments déterminés. Un motif peut bien entendu être aussi représenté par un tableau à plusieurs dimensions. Dans le but de faciliter la compréhension de cet exposé, on n'utilisera que des motifs tableau à une dimension. Les explications fournies se généralisent facilement à tout type de motif.
On se réfère maintenant à la figure 3 sur laquelle est représenté un exemple de tâche de calcul d'une application radar. Cette tâche de calcul permet de réaliser une formation de faisceau par calcul. Elle produit un tableau BF à 3 dimensions (cd, voie, rec) à partir d'un tableau d'échantillons ECH à trois dimensions (cd, ant, rec), et d'un tableau de coefficients COEF à deux dimensions (voie, ant). Les dimensions cd, ant et rec du tableau ECH correspondent à une distance, un capteur, et un temps. Elles sont indexées respectivement par le numéro de case distance num_cd, le numéro d'antenne num_ant, et le numéro de récurrence num_rec. Les dimensions voie et ant du tableau COEF correspondent à une voie et un capteur. Elles sont indexées respectivement par le numéro de voie num_voie et le numéro d'antenne num_ant. Les dimensions cd, voie et rec du tableau BF sont indexées respectivement par le numéro de case distance num_cd, le numéro de voie num_voie, et le numéro de récurrence num-rec.
La tâche de calcul :
• pondère les échantillons du tableau ECH par les coefficients du tableau COEF ;
• et, somme 8 échantillons pondérés, sur l'indice num_ant, et ce pour chaque indice num_rec, num_cd, et num_voie. Les échantillons pondérés intervenant dans cette somme correspondent à 8 capteurs du radar
(indice num_ant).
En utilisant le formalisme Array-OL appliqué à cet exemple, on peut décomposer cette tâche en une répétition d'une transformation élémentaire TE. Cette transformation élémentaire TE utilise deux motifs opérandes M01 et MO2 de 8 éléments chacun, et produit un motif résultat MR de 1 élément. On peut écrire les calculs effectués par la transformation élémentaire TE avec la relation suivante :
Figure imgf000012_0001
D'une manière générale, la spécification des calculs effectués par une tâche est l'ensemble des calculs réalisés dans une transformation élémentaire. Dans l'exemple considéré, la spécification des calculs effectués par la tâche de formation de faisceau par calcul est donnée par la relation
(1).
La transformation élémentaire TE est répétée par la tâche dans une ou plusieurs boucles imbriquées. Ces boucles ont des indices qui leur sont associés. On note ni, n2, n3, ... ces indices de boucles et N1, N2, N3,... le nombre d'itérations effectuées par chacune de ces boucles. En utilisant une représentation vectorielle, l'ensemble des indices ni, n2, n3,... peuvent être associés à des dimensions d'un espace multidimensionnel. Cet espace a autant de dimensions qu'il y a de boucles imbriquées, c'est à dire d'indices de boucles. A chaque dimension de cet espace, on associe une taille : le nombre d'itérations N1, N2, N3, .... On peut représenter cet espace et les tailles associées au dimensions par un n-uplet d'entiers (N1, N2, N3,...). Ce n-uplet représente un espace de dimension finie, où chaque dimension correspond à un indice de boucle, et chaque taille correspond à un nombre d'itérations. Le klème élément du n-uplet représente le nombre d'itérations effectuées par la tâche suivant le kιeme indice de boucle. On appelle cet espace de dimension finie, l'espace d'itération de la tâche.
Les motifs opérandes MOI, MO2 et le motif résultat MR sont associés respectivement aux tableaux d'entrée ECH, COEF et au tableau de sortie BF. La liaison entre les éléments d'un motif et les éléments d'un tableau est la spécification d'accès de la tâche. En d'autres termes, la spécification d'accès permet de déterminer la correspondance entre les éléments d'un motif et les éléments du tableau associé. Cette correspondance entre les éléments d'un motif et les éléments d'un tableau dépend des indices de boucle de la tâche d'une part, et des indices utilisés dans la transformation élémentaire TE d'autre part.
La spécification d'accès peut se décomposer en trois parties :
• La première partie est indépendante des indices de boucles de la tâche ou des indices utilisés dans la transformation élémentaire. C'est l'élément pris comme origine dans le tableau. Cette première partie de spécification d'accès est appelée l'origine. L'origine donne la relation entre le premier élément d'un motif et un élément du tableau pour la première itération de la tâche.
• La seconde partie est liée aux indices utilisés dans la transformation élémentaire TE. Dans l'exemple considéré, il n'y a qu'un indice de TE, l'indice i. Cette seconde partie est appelée l'ajustage. L'ajustage donne la relation entre les autres éléments d'un motif et les éléments d'un tableau pour la première itération de la tâche.
• La troisième partie est liée aux indices de boucle de la tâche. Cette troisième partie est appelée le pavage. Le pavage donne relation entre les indices du motif et du tableau en fonction des indices de boucle de la tâche. Le pavage peut être vu comme la le déplacement du motif dans le tableau pour les itérations suivantes de la tâche.
L'origine, l'ajustage et le pavage d'un motif peuvent se représenter avec des vecteurs. Ces vecteurs ont autant d'éléments que le tableau associé au motif a d'indices, c'est à dire de dimensions :
• On représente l'origine par un vecteur ORG.
• On représente l'ajustage par autant de vecteurs AJ1, AJ2, AJ3, ... qu'il y a d'indices utilisés dans la transformation élémentaire TE. Dans l'exemple considéré, il n'y a qu'un seul indice i, donc un seul vecteur AJ1. • On représente le pavage par autant de vecteurs PAV1 , PAV2, PAV3, ... que l'espace d'itération a de dimensions, c'est à dire d'indices de boucle de la tâche.
Dans l'exemple considéré, la tâche a trois boucles imbriquées sur les indices ni , n2 et n3. L'indice de boucle ni correspond à la dimension cd pour les tableaux ECH et BF. L'indice de boucle n2 correspond à la dimension rec pour les tableaux ECH et VOIE. L'indice de boucle n3 correspond à la dimension voie pour les tableaux COEF et BF.
On utilise plusieurs notations équivalentes pour représenter un élément d'un tableau. Par exemple, l'élément du tableau ECH correspondant aux indices num_cd = 1 , num_ant = 2 et num_rec = 3 se note :
• ECH[ 1 , 2, 3 ], ou bien
• ECH[ 1 ][ 2 ][ 3 ], ou bien • ECH[ V ] où V est un vecteur d'indices valant ( 1, 2, 3).
On peut représenter les calculs effectués par la tâche de calcul par les instructions suivantes en C : «
For ( ni = 0 ; ni < NI ; nl++ )
For ( n2 = 0 ; n2 < N2 ; n2++ )
For ( n.3 = 0 ; n.3 < N3 ; n3++ ) { MR = 0 ; For ( i = 0 ; i < 8 ; i++ )
MOl f i] = ECH [ni] [i] [n2] ; M02 [i] = COEF [n3 ] [i] ; MR = MR + M01 [i] + M02 [i] ; BF [nl] [n3 ] [n2 ] = MR; }
Ainsi, les éléments du motif M01 peuvent être associés aux éléments du tableau ECH par la relation suivante :
MOl[i] = ECH[0RG + i x AJ1 + ni x PAV1 + n2 x PAV2 + n3 x PAV3] (2)
où on utilise une combinaison linéaire de vecteurs d'indices, ces vecteurs étant : ORG = (0 0 0) (3) AJ1 = (0 1 0) (4)
PAV1 = (1 0 0) (5)
PAV2 = (0 0 1) (6)
PAV3 = (0 0 0) (7)
La relation (2) est équivalente à
MOl[i] = ECH[n1 i n2] (8)
Les vecteurs d'indices peuvent s'écrire à partir d'une combinaison linéaire de vecteurs de base de l'espace vectoriel naturel associé à un tableau. On utilise les mêmes noms pour représenter les vecteurs de base et les dimensions associées. Ainsi, on peut écrire AJ1=ant, PAV1=cd, et PAV2=rec. De la même façon, on peut utiliser des notations abrégées pour les autres tableaux COEF et BF. Les spécifications d'accès de la tâche, utilisant des notations abrégées sont données dans le tableau suivant :
Figure imgf000015_0001
Dans ce tableau, on ne rappelle pas les noms d'indices utilisés dans l'exemple car ils n'apportent aucune d'information (indices muets). Une colonne du tableau correspond à un même indice (sauf pour l'origine). On a représenté en caractères gras le nombre d'itérations réalisées par indice.
Dans ce tableau, les vecteurs d'indices égaux aux vecteurs de base, et identiques dans une même colonne du tableau. Ceci n'est pas une obligation. Il peut y avoir des noms d'indices différents dans une même colonne. Les vecteurs d'indices peuvent être un multiple ou une combinaison linéaire des vecteurs unitaires.
Avant le début du placement, l'utilisateur saisit une description de l'application partitionnée en tâches. Cette description peut se faire avec un fichier texte par exemple. Cette description comprend :
• une description des tableaux utilisés et produits par les tâches de calcul,
• une déclaration des transformations élémentaires utilisées dans les tâches de calcul,
• une description des tâches.
On décrit un exemple de syntaxe d'un tel fichier texte. Dans la description de cette syntaxe, on représente en caractères gras les mots clefs de la syntaxe, entre crochets < > chaque champ que l'utilisateur doit paramétrer, entre crochets [ ] les groupes optionnels de mots clefs et / ou de champs.
La syntaxe de description des tableaux peut être la suivante : «
array of <type élémentaire> <no du tableau> <no bre d'éléments pour la ιιere dimension> <nombre d'éléments pour la 2lême dimension> ... <nombre d'éléments pour la nιeme dimension> [ dimensions <nom de la lιere dimension> <nom de la 2ièrae dimension> ... <nom de la n ιeme dimension> ]
<type éiémentaire> est une chaîne de caractère représentant un type élémentaire. Cette chaîne de caractères peut être par exemple short, int, float, complex pour représenter respectivement un entier court, un entier long, un nombre réel et un nombre complexe.
<nom du tableau> est une chaîne de caractères qui sera utilisée dans la suite du fichier pour faire référence à ce tableau. La syntaxe de déclaration des transformations élémentaires peut être la suivante : «
transform <nom de la transformation élémentaire> in <nombre d' éléments du 1er motif opérande> in ---nombre d' éléments du 2nd motif opérande>
in <nombre d' éléments du nlême motïf opérande> out <nombre d'éléments du. 1er motif résultat> out <nottibre d'éléments du 2nd motif résultat>
out <nombre d'éléments du nαe e motif résultat> end »
<nom de la transformation élémentaire> est une chaîne de caractères qui sera utilisé dans la suite du fichier pour faire référence à cette transformation élémentaire.
La syntaxe de description des tâches peut être la suivante
task <nom de la tâche> do <nombre d'itérations llêre dimension> <nombre d'itération 2nde dimension> ... <nombre d'itérations nιeme dimension> using <nom de la transformation élémentaire> array__in <nom du 1er tableau d'entrée> org <vecteur d'indice origine> aj <vecteur d'indices d'ajustage> pav <vecteur d' indices de pavage correspondant à la lιere dimension-- <vecteur d' indices de pavage correspondant à la 2nde dimension> ...
<vecteur d'indices de pavage correspondant à la niêrae dimension> array_in <nom du 2nd tableau d' entrée> org ... array_out <nom du 1er tableau de sortie> org array_out <nom du 2nd tableau de sortie> org
end
<nombre d'itérations 1ιere dimension> est un entier représentant le nombre d'itération selon la première dimension de l'espace d'itération de la tâche <nom de la tâche>. Les nombres entiers compris entre les mots clefs do et using représentent l'espace d'itération de la tâche.
La chaîne de caractères qui suit le mot clef using est le nom d'une transformation élémentaire déclarée plus haut dans le fichier en utilisant le mot clef transfom.
La chaîne de caractères qui suit le mot clef array_în ou array_out est le nom d'un tableau défini plus haut dans le fichier en utilisant le mot clef array.
Les vecteurs d'indices qui suivent les mots clefs org, aj et pav représentent respectivement l'origine, l'ajustage et le pavage. Le nombre de vecteurs d'indices qui suit le mot clef pav est égal au nombre de dimensions de l'espace d'itération de la tâche.
Par exemple, un tel fichier de description d'application peut être en utilisant cette syntaxe. Il comprend d'abord une description des tableaux donnant les noms, les dimensions des tableaux et le nombre d'éléments par dimension. Dans cet exemple, les tableaux sont des tableaux de nombres complexes appelés ECH, COEF, BF, REP, COMP, TWID et DOP :
« array of complex ECH 1536 8 32 dimensions cd ant rec
array of complex COEF 6 8 dimensions voie ant
array of complex BF 1536 6 32 dimensions cd voie rec
array of complex REP 20 dimensions cd
array of complex COMP 6 32 1536 dimension voie rec cd
array of complex T ID 512
array of complex DOP 6 32 1536 dimensions voie dop cd
Puis le fichier comprend ensuite une déclaration des transformations élémentaire donnant le nom des transformations élémentaires et le nombre d'éléments des motifs opérandes et résultats. Dans cet exemple, les transformations élémentaires sont appelées Mulac et FFT :
«
TE Mulac in 8 in 8 out 8 end
TE FFT in 32 in 32 out 32 end »
Puis le fichier comprend enfin une description des tâches donnant le nom des tâches, l'espace d'itération des tâches, le nom de la transformation élémentaire utilisée, le nom de tableaux d'entrée et de sortie utilisés, et les spécifications d'accès associées aux tableaux (origine, ajustage, pavage). Dans cet exemple, les tâches sont appelées FormationFaisceau, Compressionlmpulsion et FiltreDoppler :
task FormationFaisceau do 1536 32 6 using Mulac array_in ECH org (0,0,0) aj (0,1,0) pav (1,0,0) (0,0,1)
(0,0,0) array_in COEF org (0,0,0) aj (0,1) pav (0,0) (0,0) (1,0) array_out BF org (0,0,0) aj (0,0,0) pav (1,0,0) (0,0,1)
(0,1,0) end
task Compressionlmpulsion do 6 32 1536 using Mulac array_in BF org (0,0,0) aj (1,0,0) pav (0,1,0) (0,0,1) (1,0,0) array_in REP org (0) aj (1) pav (0) (0) (0) array_out COMP org (0,0,0) aj (0,0,0) pav (1,0,0) (0,1,0) (0,0,1) end
task FiltreDoppler do 6 1536 using FFT array_in COMP org (0,0,0) aj (0,1,0) pav (1,0,0) (0,0,1) array_in TWID org (0) aj (1) pav (0) (0) array_out DOP org (0,0,0) aj (0,1,0) pav (1,0,0) (0,0,1) end
On se réfère aux figures 1 et 4. Au début du placement, l'utilisateur 106 ouvre une description de l'application 101 non placée telle que celle décrite dans le fichier de l'exemple précédent. L'atelier 100 peut présenter un graphique tel que celui illustré figure 4.
Ce graphique peut être généré par l'interface de saisie 102. Le graphique peut comprendre des fenêtres A1 , A2, A3, A4, A5 représentant les tableaux ECH, COEF, REP, TWID et DOP. Dans ces fenêtres apparaissent les informations relatives aux tableaux, par exemple les noms des dimensions et le nombre d'éléments par dimension. Lorsqu'une dimension ne porte pas de nom dans le fichier de description de l'application 101 , un nom arbitraire tel que « x1 » peut lui être attribué par l'atelier 100. Le graphique peut comprendre aussi des fenêtres T1, T2, T3 représentant les tâches FormationFaisceau, Compressionlmpulsion et FiltreDoppler. Dans ces fenêtres apparaissent les informations relatives aux tâches, comme par exemple le nom de la transformation élémentaire utilisée, un tableau regroupant les informations concernant l'espace d'itération et les spécifications d'accès (origine, ajustage, pavage). Des flèches F1, F2, F3, F4, F5, F6, F7 peuvent être utilisées pour représenter les entrées et les sorties des données. Par exemple, les flèches F1 et F2 proviennent des fenêtres A1 et A2 et arrivent à la fenêtre T1. Ces flèches F1 et F2 signifient que les tableaux ECH et COEF sont des entrées de la tâche FormationFaisceau.
L'utilisateur partitionne alors les tâches suivant les données. En d'autres termes, l'utilisateur modifie l'espace d'itération des tâches. Il peut ajouter ou supprimer des dimensions à l'espace d'itération, tout en gardant le nombre total d'itérations constant. On rappelle que le nombre total d'itérations est le produit des nombres d'itérations des dimensions de l'espace d'itération.
On se réfère maintenant aux figures 1 et 5 et 6. En utilisant l'interface de saisie 102, l'utilisateur peut partitionner la tâche FormationFaisceau suivant les données en divisant l'une des dimensions de l'espace d'itération de la tâche par exemple. A cet effet, l'utilisateur peut sélectionner la colonne C1 de la fenêtre T1 et ouvrir une boîte de dialogue D1. Cette boîte de dialogue D1 permet de diviser l'une dimension de l'espace d'itération de la tâche FormationFaisceau (fenêtre T1) en plusieurs dimensions. La dimension de départ est alors divisée en plusieurs dimensions d'arrivée. Cette dimension de départ correspond à la colonne C1. A cet effet, l'utilisateur 106 saisit les nombres d'itérations d'arrivée correspondant aux nouvelles dimensions. Ces nombres d'itérations peuvent être séparés par une virgule. Dans cet exemple, la dimension sélectionnée comprend 32 itérations. L'utilisateur saisit « 8, 4 » dans la boîte de dialogue D1. La dimension de départ comprenant 32 itérations est divisée en deux dimensions d'arrivée comprenant respectivement 8 et 4 itérations. Lorsque l'utilisateur 101 divise une dimension de l'espace d'itération, il doit vérifier que le nombre total d'itérations reste constant. En d'autres termes, le produit des nombres d'itérations d'arrivée doit être égal au nombre d'itérations de départ. Selon un mode de réalisation avantageux, l'atelier 100 peut effectuer cette vérification.
Le résultat de cette division est représenté sur la figure 6. L'espace d'itération d'arrivée de la tâche FormationFaisceau comprend 4 dimensions. Ces dimensions comprennent respectivement 1536, 8, 4 et 6 itérations. On peut représenter le nouvel espace d'itération par le n-uplet (1536, 8, 4, 6). Dans la fenêtre T1 , ceci se traduit par l'apparition de deux nouvelles colonnes, C2 et C3, remplaçant la colonne C1. Le pavage est modifié pour les tableaux ECH et BF. Ces tableaux avaient le vecteur d'indices rec associé à la seconde dimension de l'espace d'itération de départ (colonne C1). Cette seconde dimension a été remplacée par deux dimensions (colonnes C2 et C3). Pour les tableaux ECH et BF, les vecteurs d'indices associés aux secondes et troisièmes dimensions de l'espace d'itération d'arrivée deviennent respectivement rec et 8rec.
Ainsi, pour le tableau ECH par exemple, la boucle de 32 itérations sur l'indice num_rec de pas 1 , est remplacée par deux boucles imbriquées de respectivement 8 et 4 itérations sur l'indice num_rec. La première boucle de 8 itérations a un pas de 1. Cette boucle est répétée 4 fois par la seconde boucle. A chaque fois que la première boucle est répétée, l'indice num_rec a est incrémenté de 8. Le résultat des calculs réalisés par la tâche FormationFaisceau devant rester le même après le partitionnement, la seconde boucle sur l'indice num_rec a un pas de 8. Lors de la saisie avec la boîte de dialogue D1, l'ordre d'imbrication des boucles est déterminé de façon implicite par l'atelier. Cet ordre d'imbrication correspond dans notre exemple à l'ordre de saisie des dimensions d'arrivée. Ainsi, l'utilisateur a saisit « 8, 4 » dans la boîte de dialogue D1. Ceci signifie que la première boucle imbriquée comprend 8 itérations, et la seconde boucle imbriquée en comprend 4.
Une variante de réalisation avantageuse de l'atelier permet à l'utilisateur de spécifier explicitement l'ordre d'imbrication des boucles. A cet effet, l'utilisateur saisit par exemple le rapport entre le pas des boucles d'arrivées et le pas de la boucle de départ. Ces rapports peuvent être représentés par des nombres entre parenthèses. Ainsi, au lieu de saisir « 8, 4 » dans la boîte de dialogue D1, l'utilisateur pourra saisir de manière équivalente « 8(1), 4(8) » ou encore « 4(8), 8(1) ».
La spécification d'accès de la tâche FormationFaisceau avant d'être partitionnée peut être représentée dans le tableau suivant :
Figure imgf000023_0001
Après l'étape de partitionnement illustrée figures 5 et 6, la spécification d'accès devient :
Figure imgf000024_0001
L'utilisateur affecte les tâches aux unités de calculs. L'espace d'itération des tâches à affecter a préalablement été patitionné. Cette partition de l'espace d'itération est telle qu'au moins une dimension puisse correspondre à un nombre d'unités de calcul d'un segment de l'architecture cible. L'architecture cible considérée est une architecture segment répétitive. Par conséquent, les unités de calculs sont agencées d'une manière régulière, de manière à pouvoir être regroupées dans des tableaux d'éléments identiques. Selon l'invention, l'affectation d'une tâche de calcul est réalisée en sélectionnant certaines dimensions de son espace d'itération d'une part, et en les faisant correspondre aux dimensions d'un tableau d'unités de calcul d'autre part. Les dimensions de l'espace d'itération sélectionnées lors de l'affectation, qui représentaient une répétition d'un calcul élémentaire, représentent alors une répartition dudit calcul entre les différentes unités de calcul. En d'autres termes, le calcul élémentaire de cette tâche est réalisée en parallèle par toutes les unités de calcul à laquelle la tâche a été affectée. Chaque unité de calcul répète le calcul élémentaire suivant les autres dimensions (non sélectionnées lors de l'affectation) de l'espace d'itération. Ainsi, on peut déterminer les données traitées en parallèles lors de chaque itération à partir des spécifications d'accès de la tâche (origine, ajustage, et pavage).
On se réfère maintenant à la figure 7 sur laquelle est illustrée une étape d'affectation d'une tâche de calcul. L'utilisateur sélectionne une ou plusieurs dimensions de l'espace d'itération de la tâche qu'il souhaite affecter à des unités de calcul. A cet effet, l'utilisateur sélectionne par exemple la colonne C2 de la fenêtre T1. Cette sélection correspond à la seconde dimension de l'espace d'itération de la tâche FormationFaisceau. Puis l'utilisateur ouvre une boîte de dialogue D2 lui permettant de réaliser l'affectation. Le nombre d'itérations correspondant à la dimension sélectionnées peut être rappelé dans un champ D21 de cette boîte de dialogue D2. Grâce au modèle de l'architecture cible 105 l'atelier peut afficher l'ensemble des segments disponibles, par exemple dans une liste déroulante D22 de la boîte de dialogue D2. L'utilisateur choisit par exemple un segment comprenant le même nombre d'éléments qu'il y a d'itérations par dimension, c'est à dire 8 éléments dans cet exemple. Ce segment peut être représenté par un tableau d'unités de calcul. Dans cet exemple, l'utilisateur choisit d'affecter la tâche FormationFaisceau à un segment de 8 unités de calcul représenté par le tableau P155MHz[8].
Les unités de calculs auxquelles a été affectée la tâche accèdent en lecture ou en écriture aux éléments des tableaux d'entrée et de sortie. Lors de l'exécution de l'application placée sur l'architecture cible, ces éléments seront stockés dans des mémoires de ladite architecture. Suite à une erreur de placement, il peut arriver que ces données soient stockées dans des mémoires inaccessibles aux unités de calcul. L'atelier fournit à l'utilisateur un moyen de vérifier l'accessibilité des données, et par conséquent d'éviter de telles erreurs de placement. Ces erreurs sont donc détectées à un stade précoce du développement, avant même la réalisation d'un premier prototype.
A cet effet, l'utilisateur spécifie la manière dont sont réparties les données dans les différentes mémoires de l'architecture cible. Cette spécification de la répartition des données peut se faire pour chaque tableau d'entrée ou de sortie des tâches. On appelle affectation d'un tableau à des mémoires cette spécification de la répartition des données contenues dans le tableau. L'architecture cible étant une architecture segment répétitive, les mémoires peuvent être regroupées dans des tableaux de mémoires identiques. Selon l'invention, l'affectation d'un tableau de données à des mémoires consiste à répartir une partie des données du tableau dans un tableau de mémoires.
La spécification de la répartition d'un tableau de données A dans un tableau de mémoires M peut se décomposer par exemple en quatre parties :
• La première partie est une référence à un élément du tableau A pris comme origine. Cette première partie est appelée l'origine tableau.
• La seconde partie est une référence à la mémoire du tableau M dans laquelle l'élément du tableau A correspondant à l'origine tableau est mémorisé. Cette seconde partie est appelée l'origine mémoire.
• La troisième partie permet de déterminer pour chaque mémoire du tableau M dans laquelle au moins un élément du tableau A est mémorisé, une référence à un premier élément du tableau A mémorisé dans ladite mémoire. Cette troisième partie est appelée le projecteur. La référence au premier élément du tableau A mémorisé dans la mémoire correspondant à l'origine mémoire est l'origine tableau. A partir de l'origine tableau, de l'origine mémoire, et du projecteur, il est possible de déterminer la référence au premier élément du tableau A mémorisé dans chacune desdites mémoires.
• La quatrième partie donne pour chaque mémoire du tableau M, à partir de la référence au premier élément du tableau A mémorisé dans ladite mémoire, l'ensemble des autres éléments mémorisés. Cette quatrième partie est appelée le motif local.
L'origine tableau, l'origine mémoire, le projecteur et le motif local peuvent être représentés avec des entiers et des vecteurs d'indices. On suppose dans l'exemple de représentation qui suit que la répartition est homogène. En d'autres termes, on suppose que le nombre d'éléments mémorisés du tableau A est le même dans chaque mémoire du tableau M. Il est possible bien entendu d'utiliser une autre représentation pour des répartitions inhomogènes.
On note les indices de tableau modulo le nombre d'éléments par dimension. Par exemple, pour une dimension d'un tableau comprenant 8 éléments, les indices 0, 8, 16, 24 représentent le même élément du tableau. De même, les indices 1 , 9, 17, 25, ... représentent le même élément du tableau. Les indices 2, 10, 18, 26, ... représentent le même élément du tableau ...
La représentation peut être la suivante :
• l'origine tableau peut être représentée par un vecteur d'indices ORGA comprenant autant d'éléments que le tableau de données A a de dimensions ; • l'origine mémoire peut être représentée par un vecteur d'indices ORGM comprenant autant d'éléments que le tableau de mémoires M a de dimensions ;
• le projecteur peut être représenté par des vecteurs d'indices VPR1 , VPR2, VPR3, ... comprenant autant d'éléments que le tableau de données A a de dimensions d'une part, et des entiers NPR1 , NPR2,
NPR3, ... d'autre part, de manière à ce que le vecteur d'indices VPRi et l'entier NPRi soient associés à la ieme dimension du tableau M ;
• le motif local peut être représenté par des vecteurs d'indices VML1 , VML2, VML3, ... comprenant autant d'éléments que le tableau de données A a de dimensions d'une part, et des entiers NML1 , NML2,
NML3, ... d'autre part.
A partir de cette représentation, on peut déterminer la répartition des éléments du tableau A mémorisés dans le tableau de mémoires M. La mémoire M[i1, i2,i3,...] contient NML1 NML2χ NML3χ... éléments du tableau
A. Ces éléments vérifient la relation suivante :
ORGA + (M - ORGM[θJχ VPR1 + (i2 - ORGM[l])χ VPR2 + .
(9) + n1χ VML1 + n2χ VML2 + n3χ VML3...
où ni , n2, n3, ... sont des nombres entiers vérifiant les relations suivantes :
0 < n1 < NML1 (10) 0<n2<NML2 (11)
0<n3<NML3 (12)
On se réfère maintenant à la figure 8 sur laquelle est représenté un exemple d'affectation d'un tableau de données A dans un tableau de mémoires M. Le tableau de données A peut avoir 3 dimensions, de taille 100, 200, et 300 par exemple. Le tableau de mémoires M peut avoir 2 dimensions, de taille 3 et 2. Le tableau de mémoires M comprend donc 6 mémoires M1, M2, M3, M4, M5, M6. Ces 6 mémoires sont ordonnées dans le tableau M de la manière suivante :
Figure imgf000028_0001
L'affectation est représentée par :
ORGA = (7, 1,5) (13)
ORGM = (1,0) (14)
NPR1 = 2 (15)
VPR1 = (0,2,0) (16)
NPR2 = 2 (17)
VPR2 = (10,0,0) (18)
NML1 = 4 (19)
VML1 = (20, 0, 0) (20) La mémoire M2 correspond à l'origine mémoire ORGM définie dans la relation (14), c'est à dire l'élément M[1 ,0] du tableau M. Cette mémoire M2 comprend l'élément du tableau A correspondant à l'origine tableau ORGA définie dans la relation (13), c'est à dire l'élément A[7,1 ,5]. Le motif local NML1 , VML1 permet de déterminer les autres éléments du tableau A contenus dans cette mémoire M2. Le saut d'indices entre ces éléments est donné par le vecteur d'indices VML1. On détermine les NML1-1 éléments suivants contenus dans cette mémoire M2 en utilisant le vecteur VML1. Ces éléments sont A[27, 1 ,5], A[47,1,5] et A[67,1 ,5].
On peut déterminer le premier élément du tableau A contenu dans la mémoire M3 en utilisant le projecteur. Ce premier élément peut être référencé par le vecteur d'indices ORGA + VPR1 , c'est à dire A[7,3,5]. On détermine les NML1-1 éléments suivants contenus dans cette mémoire M3 en utilisant le vecteur VML1. Ces éléments sont A[27,3,5], A[47,3,5], A[67,3,5].
De la même façon on peut déterminer le premier élément du tableau A contenu dans la mémoire M5 en utilisant le projecteur. Ce premier élément peut être référencé par le vecteur d'indices ORGA + VPR2 , c'est à dire A[17,1 ,5]. On détermine les NML1-1 éléments suivants contenus dans cette mémoire M5 en utilisant le vecteur VML1. Ces éléments sont A[37, 1 ,5], A[57,1 ,5], A[77,1 ,5J.
De la même façon on peut déterminer le premier élément du tableau A contenu dans la mémoire M6 en utilisant le projecteur. Ce premier élément peut être référencé par le vecteur d'indices ORGA + VPR1 + VPR2 , c'est à dire A[17,3,5]. On détermine les NML1-1 éléments suivants contenus dans cette mémoire M5 en utilisant le vecteur VML1. Ces éléments sont A[37,3,5], A[57,3,5], A[77,3,5].
Dans cet exemple d'affectation, les mémoires M1 et M4 du tableau de mémoire M ne contiennent pas d'éléments du tableau A. On se réfère maintenant aux figures 1 , 9 et 10 sur lesquelles est illustrée une étape d'affectation du tableau de données ECH à un tableau de mémoires DPRAM. A cet effet, l'utilisateur sélectionne le tableau qu'il souhaite affecter, c'est à dire le tableau ECH. Puis l'utilisateur ouvre par exemple une boîte de dialogue D3 lui permettant de réaliser l'affectation. Cette boîte de dialogue peut contenir un champ D31 rappelant des informations sur le tableau à affecter, telles que le nom du tableau, les noms de ses dimensions, les tailles de ces dimensions. Dans cet exemple, le champ D31 contient la chaîne de caractères « ECH[cd :1536][ant :8][rec :32] », rappelant le nom « ECH » du tableau, les noms « cd », « ant », « rec » des dimensions, et leurs tailles « 1536 », « 8 », « 32 ». Grâce au modèle de l'architecture cible 105 l'atelier peut afficher l'ensemble des tableaux de mémoires disponibles, par exemple dans une liste déroulante D32. Il choisit dans cet exemple un tableau de 8 mémoires DR1 , DR2, DR3, DR4, DR5, DR6, DR7, DR8, ordonnées dans un tableau à une dimension DPRam de la manière suivante :
DPRam[0] = DR1
DPRam[1] = DR2
DPRam[2] = DR3
DPRam[3] = DR4
DPRam[41 = DR5
DPRam[5] = DR6
DPRam[6] = DR7
DPRam[7] = DR8
L'utilisateur peut saisir les informations concernant l'affectation du tableau de données ECH au tableau de mémoires DPRam dans la boîte de dialogue D3. Ces informations peuvent être représentées par l'origine tableau, l'origine mémoire, le projecteur, et le motif local, dans des champs D33, D34, D35, et D36 de la boîte de dialogue D3. L'origine tableau et l'origine mémoire dans cet exemple sont des vecteurs nuls. L'utilisateur saisit « 0 » ou de manière équivalente « (0,0,0) » dans le champ D33 de la boîte de dialogue D3. Il saisit « 0 » dans le champ D34. Le tableau de mémoires DPRam ayant une dimension, le projecteur est représenté par un entier et un vecteur d'indices. L'entier choisit est 8, ce qui correspond au nombre de mémoires du tableau. Par conséquent toutes les mémoires DR1 , DR2, DR3, DR4, DR5, DR6, DR7, DR8 du tableau DPRam sont utilisées dans cet exemple. Le vecteur d'indices est (0,0,1) qui peut se noter aussi « rec ». Le projecteur est représenté par une chaîne de caractères. Cette chaîne de caractères comprend un entier et un vecteur d'indices séparés par le symbole « * », éventuellement séparés par une virgule des autres entiers et vecteurs d'indices. Les entiers et les vecteurs d'indices sont placés dans l'ordre des dimensions du tableau de mémoires. Dans cet exemple, le projecteur peut se noter « 8*rec ». Le motif local est représenté par une chaîne de caractères comprenant un entier et un vecteur d'indices séparés par le symbole « * », éventuellement séparés par une virgule des autres entiers et vecteurs d'indices suivants. Dans cet exemple, le motif local est représenté par la chaîne de caractères « 1536*cd, 8*ant, 4*8rec » dans le champ D36. Chacune des 8 mémoires comprend donc 1536 x 8x4 , soit 49152 éléments du tableau de données ECH.
La répartition de ces données dans les mémoires DR1, DR2, DR3, DR4, DR5, DR6, DR7, DR8 du tableau de mémoires est illustrée figure 10. La mémoire DR1 comprend les éléments
ECH[num _ cd, num _ ant, num _ rec] dont les indices vérifient :
0 < num _cd < 1536 (21)
0 < num _ant < 8 (22)
Figure imgf000031_0001
0 < k < 4 (24)
La mémoire DR2 comprend les éléments dont les indices vérifient les relations (21), (22), (24) et la relation suivante :
Figure imgf000031_0002
La mémoire DR3 comprend les éléments dont les indices vérifient les relations (21), (22), (24) et la relation suivante :
num _ rec = 8 x k + 2 (26)
D'une manière générale, la mémoire DRi où i varie entre 1 et 8, comprend les éléments dont les indices vérifient les relations (21), (22), (24) et la relation suivante :
Figure imgf000032_0001
Selon un mode de réalisation avantageux de l'atelier, les tableaux de sortie des tâches de calcul sont automatiquement affectés à des mémoires déterminées. Ces mémoires sont celles associées aux unités de calculs auxquelles ont été affectés lesdites tâches de calcul. Par conséquent, l'utilisateur n'a besoin d'affecter que les tableaux servant uniquement d'entrée, c'est à dire ceux qui ne sont produits par aucune tâche de calcul. En d'autres termes, les données calculées sont automatiquement réparties dans les mémoires par l'atelier.
Entre plusieurs tâches de calcul accédant à des données communes, il peut y avoir des répartitions différentes desdites données dans des mémoires différentes. Par ailleurs, les mémoires auxquelles accèdent certaines unités de calculs n'ont pas toujours une capacité suffisante pour stocker les données nécessaires pour toutes les itérations d'une tâche de calcul. Il est par conséquent nécessaire d'effectuer des mouvements de données.
Selon l'invention, ces mouvements de données sont représentés par des tâches de communication. Une tâche de communication permet de changer l'emplacement mémoire des données d'un tableau. En d'autres termes, une tâche de communication permet de changer l'affectation d'un tableau de données. Une tâche de communication permet de déplacer la totalité des données d'un tableau, ou seulement une partie de ses données. Une tâche de communication correspond à une succession de mouvements élémentaires. Les mouvements élémentaires dans les tâches de communication sont l'équivalent des transformations élémentaires dans les tâches de calcul. Une tâche de communication accède en lecture à un tableau d'entrée, et en écriture à un tableau de sortie. Le tableau de sortie est une copie partielle ou totale du tableau d'entrée. Lors d'une communication, les données ne sont pas modifiées. Elles sont recopiées du tableau d'entrée vers le tableau de sortie. Cependant les répartitions des tableaux d'entrée et de sortie sont différentes. Par conséquent, lors de la copie des données du tableau d'entrée vers le tableau de sortie, il y a un mouvement desdites données d'une mémoire d'entrée vers une mémoire de sortie.
La tâche de communication être décrite à partir d'une spécification d'accès d'une part, et d'une spécification de mouvement d'autre part. La spécification d'accès peut être représentée avec des vecteurs d'indices correspondant à une origine, un ajustage et un pavage tels que ceux utilisés pour les tâches de calcul. L'origine, l'ajustage et le pavage permettent de déterminer quels éléments du tableau d'entrée et du tableau de sortie sont associés à un motif opérande et à un motif résultat. Les motifs opérandes et résultats sont associés à un mouvement élémentaire. Le mouvement élémentaire est un transfert d'un paquet de données. Les éléments du motif opérande contiennent les données à transférer lors d'un mouvement élémentaire. Le motif opérande peut être représenté par un tableau de données, généralement ayant plusieurs dimensions. Le motif résultat est la copie du motif opérande.
Le nombre d'éléments du motif opérande est égal aux nombre de données déplacées à chaque itération de la tâche de communication, c'est à dire par le mouvement élémentaire. La spécification de mouvement permet de déterminer la manière dont ces données se déplacent. En d'autres termes, la spécification de mouvement permet de déterminer pour chaque élément du motif opérande, la mémoire d'arrivée dans lequel l'élément correspondant du motif résultat sera copié. De même que la spécification de calcul d'une tâche de calcul, la spécification de mouvement s'exprime indépendamment de l'itération de la tâche de communication. L'utilisateur de l'atelier peut donc créer des tâches de communication, ce qui lui permet de spécifier lui-même les mouvements de données. Ceci permet d'obtenir des placements beaucoup plus performant qu'avec les techniques de placement connues.
On se réfère maintenant à la figure 11 sur laquelle est illustré un exemple de création d'une tâche de communication avec l'atelier.
Dans cet exemple, l'utilisateur souhaite déplacer toutes les données du tableau ECH, affecté au départ au tableau DPRam de 8 mémoires (illustré figures 9 et 10), vers un tableau DataBO de 8 mémoires. A cet effet, l'utilisateur sélectionne le tableau de départ et le tableau d'arrivée, copie du tableau de départ. Puis il ouvre une boîte de dialogue D4 pour créer une tâche de communication. Cette boîte de dialogue D4 comprend par exemple un champ D41 rappelant le nom et les dimensions du tableau de départ. Dans cet exemple, ce champ contient la chaîne de caractères « ECH[cd :1536][ant :8][rec :32] ». Cette boîte de dialogue peut aussi comprendre une zone D42 dans laquelle sont rappelées les informations relatives aux affectations de départ et d'arrivée, c'est à dire l'affectation du tableau de départ au tableau de mémoires mémoires DPRam, et l'affectation du tableau d'arrivée au tableau de mémoires DataBO. L'utilisateur peut saisir la spécification de mouvement et la spécification d'accès dans deux zones D43 et D44 de la boîte de dialogue D4.
Afin de saisir la spécification de mouvement, l'utilisateur peut choisir un mouvement élémentaire dans une liste déroulante D45 de la zone D43. Cette liste déroulante D45 contient un ensemble de mouvements élémentaires prédéfinis. Dans cet exemple, l'utilisateur choisit un mouvement élémentaire « DPRam_DataB0 » qui permet de déplacer des données à partir du tableau de mémoires DPRam vers le tableau de mémoires DataBO. Ce mouvement élémentaire utilise un motif opérande dont les dimensions peuvent être données dans deux champs D46 et D47 de la zone D43. Le premier champ D46 comprend un ou plusieurs nombres entiers séparés par des virgules, chaque nombre représentant la taille d'une dimension du motif opérande. Toutes les dimensions du champ D46 correspondent à des dimensions du tableau de mémoires de départ. Dans cet exemple, le champ D46 contient la chaîne de caractères « 8 ». Par conséquent le motif opérande a une dimension de taille 8 correspondant à l'unique dimension du tableau de mémoires DPRam.
Le second champ D47 comprend un ou plusieurs nombres entiers séparés par des virgules, chaque nombre représentant la taille d'une dimension du motif opérande. Ces dimensions correspondent à des dimensions internes à l'une quelconque des mémoires du tableau de mémoires de départ. Le produit des nombres contenus dans le champ D47 est égal au nombre d'éléments du tableau de données contenus dans une mémoire du tableau de mémoires de départ. Dans cet exemple, le champ D47 contient la chaîne de caractères « 1 ». Par conséquent le motif opérande a un unique élément par mémoire. Le motif opérande est donc un tableau de 8 éléments à une dimension, chaque élément du motif opérande étant dans une mémoire différente du tableau DPRam[8].
Afin de préciser davantage la spécification de mouvement, l'utilisateur peut saisir le décalage mémoire et le numéro de la mémoire de départ dans deux champs D48 et D49 de la zone D43.
Afin de saisir la spécification d'accès de la tâche de communication, l'utilisateur saisit l'origine, l'ajustage et le pavage dans les champs D50, D51 et D52 de la zone D44. L'origine est un vecteur d'indices qui peut être le vecteur nul comme dans cet exemple, ou une combinaison linéaire des vecteurs cd, ant et rec dans cet exemple.
L'ajustage comprend autant de vecteurs d'indices que le motif opérande a de dimensions. L'ordre des vecteurs d'indices peut être celui des dimensions du motif opérande. L'utilisateur peut aussi saisir le nombre d'éléments associés par vecteur d'indices. Ce nombre d'éléments est égal à la taille de la dimension associée du motif opérande, qui correspond au nombre d'éléments à déplacer selon cette dimension. Dans cet exemple, le champ D51 contient la chaîne de caractères « 8*rec ». Le vecteur d'indice associé à l'unique dimension du motif opérande est rec. Le nombre d'éléments à déplacer selon cette dimension est 8.
Le pavage comprend plusieurs entiers correspondant à un nombre d'itérations, et des vecteurs d'indices associés à ces entiers. Le champ D52 contient la chaîne de caractères « 1536*cd, 8*ant, 4*8rec ». Il y a trois boucles imbriquées de respectivement 1536, 8 et 4 itérations. Les vecteurs d'indices associés à ces boucles sont respectivement cd, ant et 8rec.
La spécification d'accès de la tâche de communication saisie par l'utilisateur peut être représentée par le tableau suivant :
Figure imgf000036_0001
L'utilisateur peut saisir des tâches de communications plus complexes. On se réfère maintenant aux figures 12, 13a et 13b sur laquelle est illustré un autre exemple de création d'une tâche de communication.
Dans cet exemple, l'utilisateur souhaite changer l'arrangement des données du tableau COMP dans le tableau DPRam de 8 mémoires DR1 , DR2, DR3, DR4, DR5, DR6, DR7, DR8. A cet effet, l'utilisateur sélectionne le tableau de départ et le tableau d'arrivée, copie du tableau de départ. Puis il ouvre la boîte de dialogue D4 pour créer une tâche de communication. Les champs de cette boîte de dialogue ont étés décrits figure 11. Dans cet exemple, le tableau de données intervenant dans la tâche de communication est le tableau COMP. Ce tableau a trois dimensions voie, rec et cd de taille 6, 32, 1536. L'affectation de départ, c'est à dire l'affectation du tableau dont les données doivent être déplacées par la tâche de communication, peut être donnée par les relations suivantes :
ORGA = 0 (28)
ORGM = 0 (29)
NPR1 = 8 (30)
VPR1 = rec (31)
NML1 = 6 (32)
VM I ≈ voie (33)
NML2 = 4 (34)
VML2 = 8rec (35)
NML3 = 1536 (36)
VML3 = cd (37)
Par conséquent au départ, chaque mémoire DPRam[i] comprend les éléments COMP[num _ voie, num _ rec, num _cd] dont les indices vérifient les relations suivantes :
Figure imgf000037_0001
0 < k < 4 (39)
0 < num _voie < 6 (40)
0 < num _cd < 1536 (41) L'affectation d'arrivée peut être donnée par les relations suivantes :
ORGA = 0 (42)
ORGM = 0 (43)
NPR1 = 8 (44)
VPR1 = cd (45)
NML1 = 6 (46)
VML voie (47)
NML2 = 32 (48)
VML2 = rec (49)
NML3 = 192 (50)
VML3 = 8cd (51)
Par conséquent à l'arrivée, chaque mémoire DPRam[i] comprend les éléments COMP[num_ voie, num _ rec, num _cd] dont les indices vérifient les relations suivantes :
Figure imgf000038_0001
0<k<192 (53)
0<num_voie<6 (54)
0 < num _Jec < 32 (55) La tâche de communication permettant de passer de l'affectation de départ à l'affectation d'arrivée doit permuter les dimensions rec et cd du projecteur. Afin de saisir la spécification de mouvement, l'utilisateur choisit un mouvement élémentaire dans la liste déroulante D45 de la zone D43. Dans cet exemple, l'utilisateur choisit un mouvement élémentaire « CT_DPRam » qui permet permuter les dimensions d'un tableau de données à deux dimensions affecté à un tableau de mémoires à une dimension.
Les figures 13a et 13b illustrent ce mouvement élémentaire. Le motif opérande correspondant à ce mouvement élémentaire est un tableau à deux dimensions, chaque dimension ayant une taille de 8. Les éléments du motifs opérande sont répartis par groupe de 8 dans chacune de 8 mémoires DR1 , DR2, DR3, DR4, DR5, DR6, DR7, DR8. On utilise dans cet exemple les indices i et j pour faire référence à la première et la seconde dimension du motif opérande. On a numéroté dans la figure 13a les éléments du motif opérande de 1 à 64. Le numéro n de l'élément du motif opérande est lié aux indices i et j par la relation suivante :
Figure imgf000039_0001
La répartition des éléments du motif opérande est illustrée figure 13a. La mémoire DR1 contient les éléments 1 à 8 du motif opérande, c'est à dire ceux pour lesquels l'indice i vaut 0. La mémoire DR2 contient les éléments 9 à 16 du motif opérande, c'est à dire ceux pour lesquels l'indice i vaut 1. La mémoire DR3 contient les éléments 17 à 24 du motif opérande, c'est à dire ceux pour lesquels l'indice i vaut 2. La mémoire DR4 contient les éléments 25 à 32 du motif opérande, c'est à dire ceux pour lesquels l'indice i vaut 3. ... La mémoire DR8 contient les éléments 57 à 64 du motif opérande, c'est à dire ceux pour lesquels l'indice i vaut 7.
Le motif résultat est une copie du motif opérande. On utilise la même numérotation et les même indices pour faire référence aux éléments du motif résultat. La répartition des éléments du motif résultat est illustrée figure 13b. La mémoire DR1 contient les éléments 1, 9, 17, 25, 33, 41 , 49, 57 du motif résultat, c'est à dire ceux pour lesquels l'indice j vaut 0. La mémoire DR2 contient les éléments 2, 10, 18, 26, 34, 42, 50, 58 du motif résultat, c'est à dire ceux pour lesquels l'indice j vaut 1. La mémoire DR3 contient les éléments 3, 11, 19, 27, 35, 43, 51, 59 du motif résultat, c'est à dire ceux pour lesquels l'indice j vaut 2. La mémoire DR4 contient les éléments 4, 12, 20, 28, 36, 44, 52, 60 du motif résultat, c'est à dire ceux pour lesquels l'indice j vaut 3. ... La mémoire DR8 contient les éléments 8, 16, 24, 32, 40, 48, 56 du motif résultat, c'est à dire ceux pour lesquels l'indice j vaut 7.
Lors du mouvement élémentaire permettant de copier les éléments du motif opérande dans le motif résultat, les éléments mémorisés dans chaque mémoire sont répartis dans l'ensemble des mémoires. Par exemple, les éléments 1, 2, 3, 4, 5, 6, 7, 8 du motif opérande mémorisés dans la mémoire DR1 sont répartis dans les mémoires DR1, DR2, DR3, DR4, DR5, DR6, DR7, DR8.
L'utilisateur saisit l'origine, l'ajustage et le pavage de cette tâche de communication. Dans cet exemple, l'origine, l'ajustage et le pavage sont les suivants :
Figure imgf000040_0001
On appelle cette tâche de communication une transposition ou encore une permutation car deux dimensions d'un tableau ont été permutées dans les mémoires. Ces dimensions sont dans cet exemple rec et cd.
On se réfère maintenant aux figures 14, 15a et 15b sur lesquelles est illustré un autre exemple de création d'une tâche de communication.
Dans cet exemple, l'utilisateur souhaite regrouper les données du tableau COMP, réparties initialement sur un tableau DataC de 8 mémoires DC1, DC2, DC3, DC4, DC5, DC6, DC7, DC8 dans 4 de ces mémoires DC1, DC2, DC3, DC4 appartenant à la même dimension. Le tableau DataC est un tableau à 2 dimensions. La première dimension a une taille de 4. La seconde dimension a une taille de 2. Les 8 mémoires sont ordonnées dans le tableau DataC de la manière suivante :
Figure imgf000041_0002
A cet effet, l'utilisateur sélectionne le tableau de départ COMP et le tableau d'arrivée, copie du tableau de départ. Puis il ouvre une boîte de dialogue pour créer une tâche de communication.
Au départ, chaque mémoire DataC[i,j] comprend les éléments COMP[num_ voie, num _ rec, num _cd]dont les indices vérifient les relations suivantes :
0 num __ voie < 6 (57)
Figure imgf000041_0001
0 ≤ k < 4 (59)
0 < num _cd < 1536 (60)
A l'arrivée, chaque mémoire DataC[i,θ] comprend les éléments COMP[num _ voie, num _ rec, num _ cd]dont les indices vérifient les relations suivantes :
0 < num_voie < 6 (61)
num _ rec = 4 x k + i (62) 0 < k < 8 (63)
0 < num _ cd < 1536 (64)
La tâche de communication permettant de passer de l'affectation de départ à l'affectation d'arrivée doit regrouper dans une même mémoire certains éléments du tableau COMP initialement mémorisés dans des mémoires différentes. Afin de saisir la spécification de mouvement correspondant à cette tâche, l'utilisateur choisit un mouvement élémentaire dans la liste déroulante D45 de la zone D43. Dans cet exemple, l'utilisateur choisit un mouvement élémentaire « GT_DataC » illustré figures 15a et 15b.
Le motif opérande correspondant à ce mouvement élémentaire est un tableau à deux dimensions. La première dimension a une taille de 4. La seconde dimension a une taille de 2. Les éléments du motif opérande illustrés figure 15a sont répartis dans les mémoires DC1, DC2, DC3, DC4, DC5, DC6, DC7, DC8. On utilise dans cet exemple les indices i etj pour faire référence à la première et la seconde dimension du motif opérande. On a numéroté dans la figure 15a les éléments du motif opérande de 1 à 8. Le numéro n de l'élément du motif opérande est lié aux indices i et j par la relation suivante :
n = i + 4 x j + 1 (65)
La répartition des éléments du motif opérande est illustrée figure
15a. La mémoire DC1 contient l'élément 1 du motif opérande, c'est à dire celui pour lequel i vaut 0 et j vaut 0. La mémoire DC2 contient l'élément 2 du motif opérande, c'est à dire celui pour lequel i vaut 1 et j vaut 0. La mémoire DC3 contient l'élément 3 du motif opérande, c'est à dire celui pour lequel i vaut 2 et j vaut 0. La mémoire DC4 contient l'élément 4 du motif opérande, c'est à dire celui pour lequel i vaut 3 et j vaut 0. La mémoire DC5 contient l'élément 5 du motif opérande, c'est à dire celui pour lequel i vaut 0 et j vaut 1. La mémoire DC6 contient l'élément 6 du motif opérande, c'est à dire celui pour lequel i vaut 1 et j vaut 1. La mémoire DC7 contient l'élément 7 du motif opérande, c'est à dire celui pour lequel i vaut 2 et j vaut 1. La mémoire DC8 contient l'élément 8 du motif opérande, c'est à dire celui pour lequel i vaut 3 et j vaut 1.
Le motif résultat est une copie du motif opérande. On utilise la même numérotation et les mêmes indices pour faire référence aux éléments du motif résultat. La répartition des éléments du motif résultat est illustrée figure 15b. La mémoire DC1 contient les éléments 1 et 5 du motif résultat, c'est à dire ceux pour lesquels l'indice i vaut 0. La mémoire DC2 contient les éléments 2 et 6 du motif résultat, c'est à dire ceux pour lesquels l'indice i vaut 1. La mémoire DC3 contient les éléments 3 et 7 du motif résultat, c'est à dire ceux pour lesquels l'indice i vaut 2. La mémoire DC4 contient les éléments 4 et 8 du motif résultat, c'est à dire ceux pour lesquels l'indice i vaut 3.
Lors du mouvement élémentaire permettant de copier les éléments du motif opérande dans le motif résultat, les éléments mémorisés dans les mémoires DC5, DC6, DC7, DC8 sont déplacés dans les mémoires DC1 , DC2, DC3, DC4.
L'utilisateur saisit l'origine, l'ajustage et le pavage de cette tâche de communication. Dans cet exemple, l'origine, l'ajustage et la pavage sont les suivants :
Figure imgf000043_0001
Selon un mode de réalisation avantageux, l'atelier peut effectuer des vérifications lors de la saisie d'une tâche de communication, et indiquer les éventuelles erreurs par un message d'erreur par exemple. Ces erreurs peuvent par exemple concerner la spécification d'accès. L'ajustage saisit par l'utilisateur peut être incompatible avec le motif opérande par exemple si le nombre d'éléments intervenant dans l'ajustage est différent du nombre d'éléments du motif opérande. Ces erreurs peuvent concerner la spécification de mouvement. Le mouvement élémentaire choisit par l'utilisateur peut être incompatible avec l'affectation de départ par exemple si les mémoires impliquées dans l'affectation et le mouvement élémentaire sont différentes au départ.
Selon une autre variante avantageuse, l'utilisateur peut saisir des mouvements élémentaires non présents initialement dans la liste déroulante D45 de la zone D43 de la boîte de dialogue D4. Ces nouveaux mouvements élémentaires peuvent alors être ajoutés à la liste déroulante.
Les mémoires auxquelles les unités de calcul peuvent accéder rapidement ont souvent des capacités limitées. Ces mémoires sont par exemple les mémoires internes des microprocesseurs. Les tableaux d'entrée ou de sortie ont par conséquent souvent trop d'éléments pour pouvoir être mémorisés intégralement dans ces mémoires. Il possible de diviser une tâche de calcul accédant à des tableaux trop volumineux, de manière à transférer les tableaux dans les mémoires en plusieurs fois sans dépasser la capacité desdites mémoires. On utilise par exemple une première mémoire ou tableau de mémoires de grande capacité pour mémoriser l'intégralité des tableaux, et une seconde mémoire ou tableau de mémoires accessible aux unités de calcul. La capacité de la seconde mémoire ou tableau de mémoires est inférieure à celle de la première mémoire ou tableau de mémoires. On transfère une partie des tableaux d'entrée de cette première mémoire vers la seconde mémoire pour effectuer les calculs. Une fois les calculs effectués, on transfère le résultat des calculs de la seconde mémoire vers la première mémoire dans les tableaux de sortie. On répète ces transferts et ces calculs sur l'ensemble des tableaux d'entrée et de sortie. Ce procédé de transfert par partie pour effectuer des calculs est connu sous le nom de « swap » dans la littérature anglo-saxonne.
Selon une variante avantageuse de l'invention, l'utilisateur peut saisir des tâches faisant appel à d'autres tâches de communication et/ou de calcul. On nomme ces tâches des tâches d'appel. Une tâche d'appel permet de répéter un appel à d'autres tâches de calcul ou de mouvement par exemple. Une tâche d'appel peut aussi répéter un appel à d'autres tâches d'appel. L'espace d'itération de la tâche d'appel contient une ou plusieurs dimensions. Toutes les dimensions de l'espace d'itération de la tâche d'appel sont contenues dans les espaces d'itération des tâches appelées. Les tableaux d'entrée des tâches appelées sont les tableaux d'entrée de la tâche d'appel. Les tableaux de sortie des tâches appelées non utilisés uniquement comme tableau d'entrée de l'une des tâches appelées sont les tableaux de sortie de la tâche d'appel.
On se réfère aux figures 16a et 16b sur lesquelles est illustrée la création d'une tâche d'appel. Dans cet exemple, l'utilisateur souhaite créer une tâche appelant la tâche FormationFaisceau représentée par la fenêtre
T1 d'une part, et appelant la tâche Compressionlmpulsion représentée par la fenêtre T2 d'autre part. A cet effet, il sélectionne les deux fenêtres T1 et T2 avec un rectangle de sélection S1 fait à la souris par exemple. Ce rectangle de sélection englobe les deux fenêtres T1 et T2. Ce rectangle permet de matérialiser les entrées et les sorties de la tâche d'appel. Ainsi, les flèches
F1 , F2, et F4 correspondent aux entrées de la tâche d'appel qui va être créé.
La flèche F5 correspond à la sortie de la tâche d'appel qui va être créée. Les tableaux d'entrée de la tâche d'appel seront donc ECH, COEF, et REP. Le tableau COMP sera le tableau de sortie de cette tâche d'appel.
L'espace d'itération de la tâche FormationFaisceau comprend dans cet exemple 4 dimensions représentées par les colonnes C11, C12, C13, C14. L'espace d'itération de la tâche Compressionlmpulsion comprend dans cet exemple 4 dimensions représentées par les colonnes C21 , C22, C23, C24. Les dimensions correspondant aux colonnes C11 et C21 ont été déjà affectées à des unités de calcul lors d'étapes précédentes d'affectation. Les colonnes C11 et C21 peuvent être représentées de manière différente en utilisant un fond sombre au lieu d'un fond clair, de manière à rappeler à l'utilisateur que les dimensions correspondant à ces colonnes ont déjà été affectées à des unités de calcul. Ces dimensions ne pourront pas être des dimensions de l'espace d'itération de la tâche d'appel. En effet, elle ne correspondent plus à une répétition d'une opération, mais à une répartition de cette opération sur plusieurs unités de calcul. L'utilisateur ouvre une boîte de dialogue, non représentée, afin de saisir l'espace d'itération de la nouvelle tâche d'appel, en indiquant la correspondance entre les dimensions de cet espace d'itération et les dimensions des espaces d'itération des tâches appelées. A cet effet, l'utilisateur peut placer les colonnes C11, C12, C13, C14 et C21, C22, C23, C24 des fenêtres T1 et T2 dans un ordre déterminé, de telle sorte que les colonnes les plus à droite des correspondent dans l'ordre aux colonnes de l'espace d'itération de la nouvelle tâche d'appel. L'utilisateur n'a alors plus qu'à saisir le nombre de dimensions de l'espace d'itération de la tâche d'appel. Dans cet exemple, l'espace d'itération de la tâche d'appel comprend une dimension. Cette dimension de l'espace d'itération de la tâche d'appel correspond aux colonnes C14 et C25 des fenêtres T1 et T2.
La tâche d'appel créée est alors représentée par une nouvelle fenêtre T4 illustrée figure 16b. Cette nouvelle fenêtre T4 remplace les fenêtres T1 et T2 de la figure 16a. L'espace d'itération de cette tâche d'appel a une seule dimension représentée par une colonne C41. Les autres dimensions des espaces d'itération des tâches appelées deviennent des dimensions de l'ajustage de cette nouvelle tâche.
L'utilisateur peut répéter les différentes opérations de partitionnement, d'affectation et de création de tâches jusqu'à obtenir un placement correct. Au début du placement, il n'y a que des tâches de calcul. Puis l'utilisateur ajoute des tâches de communication et des tâches d'appel. Toutes ces tâches ont une structure générale commune qui permet à l'utilisateur de les manipuler de la même façon. En particulier, ceci permet à l'utilisateur de regrouper des tâches de communication et des tâches de calcul dans une même tâche d'appel. En faisant de tels regroupements, l'utilisateur peut éviter d'avoir recours à des procédés de « swap ». En effet, l'utilisateur peut tirer parti d'une symétrie des calculs pour faire effectuer des calculs en cascades sur des blocs de données. A cet effet, il regroupe les différents calculs représentés par plusieurs tâches de calculs, dans une seule tâche d'appel. Dans l'exemple illustré figures 16a et 16b, l'utilisateur a regroupé deux calculs, ce qui permet d'éviter d'avoir recours à un procédé de « swap » pour mémoriser les éléments du tableau BF. Ces éléments seront calculés, mémorisés de façon temporaire dans des petites mémoires accessibles aux unités de calcul, puis utilisées. Dans un placement classique, ces données auraient été mémorisées dans une autre mémoire plus importante, mais non accessible aux unités de calcul. L'invention permet de rendre les placements plus performants en réduisant le nombre de communications nécessaires. Dans cet exemple, les communications économisées sont celles permettant de transférer les données du tableau BF calculées par la tâche FormationFaisceau dans une mémoire ayant une grande capacité d'une part, et la communication permettant de transférer les données du tableau BF stockées dans cette mémoire pour leur utilisation par la tâche Compressionlmpulsion d'autre part. L'atelier permet donc à l'utilisateur d'optimiser les mouvements de données.
L'utilisateur peut partitionner l'espace d'itération des tâches d'appel en plusieurs dimensions de manière à en regrouper dans une autre tâche d'appel. Une tâche d'appel peut appeler une autre tâche d'appel, laquelle à son tour peut appeler une autre tâche d'appel. On peut définir une hiérarchie de tâches, le niveau hiérarchique d'une tâche dépendant du niveau d'imbrication de la tâche. Les tâches de calcul ou de communication sont les tâches de plus bas niveau. Ce niveau peut être numéroté zéro (0). Une tâche d'appel appelant une tâche de niveau n appartient au niveau supérieur n+1. Ainsi, une tâche d'appel appelant des tâches de calcul est de niveau 1. Lorsqu'une tâche appelle des tâches de niveaux différents, c'est la tâche dont le niveau est le plus élevé qui est utilisé pour déterminer le niveau de la tâche d'appel.
L'ensemble des tâches de niveau plus élevé est d'abord présenté à l'utilisateur par l'interface de saisie. Lorsque l'utilisateur souhaite modifier une tâche de niveau inférieur, il peut par exemple double cliquer sur la fenêtre représentant la tâche d'appel (celle de niveau plus élevé). Cette fenêtre est alors remplacée par les fenêtres représentant les tâches appelées. L'utilisateur répète cette opération jusqu'à arriver à la tâche appelée qui l'intéresse. L'utilisateur peut alors modifier les paramètres de tâche appelée. Toutes les tâches appelées par une tâche d'appel ont au moins une dimension de l'espace d'itération correspondant une dimension de l'espace d'itération de la tâche d'appel. Si l'utilisateur modifie (en partitionnant par exemple) cette dimension pour l'une des tâches, il doit effectuer la même modification pour toutes les autres tâches. De manière à éviter des erreurs, ces modifications peuvent être interdites par l'atelier dans les tâches appelées une fois la tâche d'appel créée. Si l'utilisateur souhaite modifier cette dimension, il pourra alors le faire à partir de la fenêtre représentant la tâche d'appel.
Une fois l'application placée sur l'architecture cible, l'utilisateur peut la tester avec une simulation comportementale. Le moteur de simulation intégré à l'atelier permet de vérifier le temps d'exécution de l'application sur l'architecture cible, l'utilisation des ressources et notamment le taux de remplissage des mémoires. Plus le modèle de l'architecture est détaillé, plus les résultats sont fins.
On se réfère aux figures 17a et 17b sur lesquelles sont représentés des résultats de simulation du temps d'exécution. Ces résultats peuvent être affichés par l'interface de présentation 104 de l'atelier.
Les résultats de cette simulation peuvent être présentés sous la forme d'un graphique GR. Ce graphique GR est un chronogramme représentant le temps d'exécution de tâches de calcul ou de communication par exemple. Le temps y est représenté selon un axe horizontal. L'exécution des différentes tâches est représentée sur des lignes GL1, GL2, GL3, GL4, GL5 du graphique. Sur la figure 17a, le chronogramme correspond à une application placée mais très peu optimisée. En utilisant l'atelier, l'utilisateur optimise le placement de son application. Le résultat de la simulation de cette application mieux placée est illustré figure 17b.
Grâce à l'invention, ces simulations sont rapides une fois l'application placée avec l'atelier. En effet, les informations de placement sont directement utilisées avec le modèle de l'architecture par le moteur de simulation. Ainsi, il n'est pas nécessaire de développer un atelier de simulation pour tester le placement.
L'utilisateur voit directement l'impact de ses choix sur les performances de l'application placée. Par conséquent il peut réaliser un placement optimisé très rapidement.
Par ailleurs, les informations de placement peuvent être réutilisées si une partie de l'architecture est modifiée sans que sa structure soit modifiée. Il suffit alors de modifier le modèle de l'architecture. Ceci permet de tester les performances d'une application déjà placée, ayant déjà été implantée sur une architecture cible particulière, lorsque un composant de ladite architecture est remplacé par un autre.
Bien entendu, l'invention ne se limite pas à cet exemple de mise en œuvre. Les informations de placement peuvent être présentées sous une autre forme. Le modèle de l'architecture peut être stocké dans un fichier utilisé par l'atelier, et non faire partie de l'atelier. Le moteur de simulation peut être un programme de simulation externe.

Claims

REVENDICATIONS
1. Procédé de placement d'applications multiprocesseurs sur une architecture cible, caractérisé en ce qu'il comprend au moins les étapes suivantes :
(a) une étape de partitionnement suivant les données d'une application préalablement partitionnée en tâches de calcul ;
(b) une étape d'affectation desdites tâches de calcul, partitionnées suivant les données, à des unités de calcul de l'architecture cible ; (c) une étape de saisie de tâches de communication, lesdites tâches de communication permettant de copier totalement ou partiellement les données d'un tableau départ vers un tableau d'arrivée, ledit tableau de départ affecté à des mémoires de départ de l'architecture cible, ledit tableau d'arrivée étant affecté à des mémoires d'arrivée de l'architecture cible.
2. Procédé selon la revendication 1 caractérisé en ce que la saisie d'une tâche de communication lors de l'étape (c) comprend d'une part :
(a) une étape de spécification d'un mouvement élémentaire, ledit mouvement élémentaire consistant à copier les éléments d'un motif opérande dans un motif résultat, ledit mouvement élémentaire étant répété plusieurs fois par la tâche de communication ; et d'autre part,
(b) une étape de spécification d'accès, ledit accès comprenant d'une part la relation entre les éléments du motif opérande avec les données du tableau de départ, et d'autre part la relation entre les éléments du motif résultat avec les données du tableau d'arrivée.
3. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape de saisie de tâches d'appel, lesdites tâches d'appel faisant appel à d'autres tâches de communication et/ou de calcul et/ou d'appel.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape de simulation permettant de tester l'application placée lors des étapes précédentes.
5. Dispositif de placement d'applications multiprocesseurs sur une architecture cible, caractérisé en ce qu'il comprend au moins :
(a) des moyens de partitionnement suivant les données d'une application préalablement partitionnée en tâches de calcul ;
(b) des moyens d'affectation desdites tâches de calcul partitionnées suivant les données à des unités de calcul de l'architecture cible ;
(c) des moyens de saisie de tâches de communication, lesdites tâches de communication permettant de copier totalement ou partiellement les données d'un tableau départ vers un tableau d'arrivée, ledit tableau de départ affecté à des mémoires de départ de l'architecture cible, ledit tableau d'arrivée étant affecté à des mémoires d'arrivée de l'architecture cible.
6. Dispositif selon la revendication 5 caractérisé en ce que les moyens de saisie d'une tâche de communication comprennent d'une part :
(a) des moyens de saisie d'un mouvement élémentaire, ledit mouvement élémentaire consistant à copier les éléments d'un motif opérande dans un motif résultat, ledit mouvement élémentaire étant répété plusieurs fois par la tâche de communication ; et d'autre part,
(b) des moyens de saisie d'une spécification d'accès, ledit accès comprenant d'une part la relation entre les éléments du motif opérande avec les données du tableau de départ, et d'autre part la relation entre les éléments du motif résultat avec les données du tableau d'arrivée.
7. Dispositif selon l'une des revendications 5 à 6, caractérisé en ce qu'il comprend en outre des moyens de saisie de tâches d'appel, lesdites tâches d'appel faisant appel à d'autres tâches de communication et/ou de calcul et/ou d'appel.
8. Dispositif selon l'une des revendications 5 à 7, caractérisé en ce qu'il comprend en outre des moyens de simulation permettant de tester l'application placée avec les moyens précédents.
PCT/FR2001/003826 2000-12-19 2001-12-04 Procede de placement d'applications multiprocesseurs WO2002050676A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE60132629T DE60132629T2 (de) 2000-12-19 2001-12-04 Verfahren zum plazieren von mehrprozessoranwendungen
EP01271582A EP1356382B1 (fr) 2000-12-19 2001-12-04 Procede de placement d'applications multiprocesseurs

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0016589A FR2818406B1 (fr) 2000-12-19 2000-12-19 Procede de placement d'applications multiprocesseurs
FR00/16589 2000-12-19

Publications (1)

Publication Number Publication Date
WO2002050676A1 true WO2002050676A1 (fr) 2002-06-27

Family

ID=8857872

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/003826 WO2002050676A1 (fr) 2000-12-19 2001-12-04 Procede de placement d'applications multiprocesseurs

Country Status (5)

Country Link
EP (1) EP1356382B1 (fr)
AT (1) ATE384995T1 (fr)
DE (1) DE60132629T2 (fr)
FR (1) FR2818406B1 (fr)
WO (1) WO2002050676A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10387454B2 (en) 2016-08-02 2019-08-20 International Business Machines Corporation Method for creating efficient application on heterogeneous big data processing platform
CN112338919B (zh) * 2020-10-30 2022-03-04 珠海一微半导体股份有限公司 一种机器人的运行控制方法、机器人及芯片

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2791789A1 (fr) * 1999-04-02 2000-10-06 Thomson Csf Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2791789A1 (fr) * 1999-04-02 2000-10-06 Thomson Csf Procede generique d'aide au placement d'applications de traitement de signal sur calculateurs paralleles

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GUETTIER C: "Optimisation globale du placement d' applications de traitement du signal sur architectures parallèles utilisant la programmation logique avec contraintes;chapitre 2", THESE ECOLE DES MINES DE PARIS, XX, XX, 12 December 1997 (1997-12-12), pages 41 - 68, XP002140827 *
P BOULET ET AL: "Communication Pre-evaluation in HPF", PUBLICATION AS-182 LABORATOIRE D' INFORMATIQUE FONDAMENTALE DE LILLE, 17 March 1998 (1998-03-17), Lille, France, pages 1 - 31, XP002180510 *

Also Published As

Publication number Publication date
DE60132629D1 (de) 2008-03-13
ATE384995T1 (de) 2008-02-15
EP1356382B1 (fr) 2008-01-23
EP1356382A1 (fr) 2003-10-29
DE60132629T2 (de) 2009-09-24
FR2818406B1 (fr) 2003-03-07
FR2818406A1 (fr) 2002-06-21

Similar Documents

Publication Publication Date Title
Gounaris et al. A methodology for spark parameter tuning
EP1805611B1 (fr) Procede d&#39;ordonnancement de traitement de tâches et dispositif pour mettre en oeuvre le procede
FR3091375A1 (fr) Instruction de chargement-stockage
FR2865047A1 (fr) Systeme de generation automatique de codes optimises
EP3019957B1 (fr) Procede d&#39;optimisation de traitement parallele de donnees sur une plateforme materielle
US11194826B2 (en) Single-pass distributed sampling from block-partitioned matrices
US11126503B2 (en) Pre-filtering of join execution over multi-column range summaries and other synopses
FR2573888A1 (fr) Systeme pour la transmission simultanee de blocs de donnees ou de vecteurs entre une memoire et une ou plusieurs unites de traitement de donnees
Dongarra et al. Parallel processing and applied mathematics
US10181000B1 (en) Scheduling parallel processing of multiple partitions for signal electromigration analysis
EP2956874B1 (fr) Dispositif et procédé pour accélérer la phase de mise à jour d&#39;un noyau de simulation
EP2856323B1 (fr) Procédé, dispositif et programme d&#39;ordinateur de contrôle dynamique de distances d&#39;accès mémoire dans un système de type numa
EP1356382B1 (fr) Procede de placement d&#39;applications multiprocesseurs
FR2820526A1 (fr) Procede de simulation de performances, et procede de realisation d&#39;applications multiprocesseurs, et dispositifs permettant de mettre en oeuvre lesdits procedes
EP0780775B1 (fr) Architecture d&#39;un système de tableaux de processeurs à structures parallèles multiples
Perwej et al. An extensive investigate the mapreduce technology
Langr et al. CPP11sort: A parallel quicksort based on C++ threading
US12008469B1 (en) Acceleration of neural networks with stacks of convolutional layers
Dong et al. User-defined tensor data analysis
Dias et al. Janus: Diagnostics and reconfiguration of data parallel programs
Honan et al. A quantum computer operating system
Soumagne et al. A Software Defined Storage Approach to Exascale Storage Services (Final Technical Report)
Gonthier Scheduling Under Memory Constraint in Task-based Runtime Systems
Chen et al. A Survey on Graph Neural Network Acceleration: A Hardware Perspective
FR3045857A1 (fr) Procede et dispositif de classement d&#39;un ensemble d&#39;elements informatiques

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2001271582

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2001271582

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 2001271582

Country of ref document: EP