WO2003075188A1 - Procede d'extraction de la topologie d'un systeme a partir de sa description textuelle - Google Patents

Procede d'extraction de la topologie d'un systeme a partir de sa description textuelle Download PDF

Info

Publication number
WO2003075188A1
WO2003075188A1 PCT/FR2003/000550 FR0300550W WO03075188A1 WO 2003075188 A1 WO2003075188 A1 WO 2003075188A1 FR 0300550 W FR0300550 W FR 0300550W WO 03075188 A1 WO03075188 A1 WO 03075188A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
port
topology
signal
address
Prior art date
Application number
PCT/FR2003/000550
Other languages
English (en)
Inventor
Emmanuel Vaumorin
Vasyl Baranetskyy
Marcel Saussay
Original Assignee
Prosilog S.A.
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 Prosilog S.A. filed Critical Prosilog S.A.
Priority to AU2003248860A priority Critical patent/AU2003248860A1/en
Publication of WO2003075188A1 publication Critical patent/WO2003075188A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design

Definitions

  • the present invention relates to a method for producing data representing the topology of a system, from the textual description of the system in an object-oriented language, in particular the SystemC language.
  • CAD computer-aided system design
  • Formal languages such as VHDL, Verilog or SystemC make it possible to describe verbatim, with an object-oriented approach, a system comprising one or more hardware (hardware) and / or software (software) modules.
  • Each module of the system is represented by an object having a determined number of input ports and a determined number of output ports, or even input / output ports in certain applications.
  • the modules are connected to each other by signals which connect at least one output port of one module to at least one input port of another module, or even of the same module (in the case of looping an output with a module input).
  • a connection In the language of a person skilled in the art and hereinafter, the association between a port and a signal which is connected to it is called a connection.
  • the textual description of the system takes the form of a code (or program) following the syntax specific to formal language.
  • the code is recorded on any storage medium, possibly after a compilation operation, and can be loaded into the memory of a computer. It can then be executed by the computer, in particular to simulate the functioning of the system.
  • SystemC is also a library of pre-coded objects (also called “classes”), and a simulation kernel, which can be used to model and simulate the functioning of a system.
  • modules of the system are represented by a C ++ object which characterizes its input and / or output ports, as well as the principle of its operation via functions (also called “methods” or “processes”) which control the variation of the signals connected to the module outputs according to the variation of the signals connected to the module inputs.
  • the simulation kernel executes the system code.
  • An object of the invention is to propose a method making it possible, as transparently as possible for the designer, to dynamically obtain the topology of a system from the netlist of this system written in formal language, in particular but not exclusively SystemC.
  • adverb “dynamically”, we mean “as and when” the execution of the system code.
  • the system topology is thus automatically and immediately available for later use.
  • system topology knowledge of the modules which compose it and of their connections via the aforementioned signals.
  • This topology is entirely defined by the list of system connections.
  • Data representing this topology can be produced from the netlist itself (since this netlist describes the structure of the system as a whole). It can be stored in memory in various forms, in particular in one or more files forming a structure appropriate memory.
  • This data provides all the information on the topology of the system: information on all its components and their connections to each other. This can be very useful for many applications, for example the generation of a graphical representation of the system (on a screen or on paper), the implementation of a software for placing / routing the modules of the system in view of its implementation towards the target material, etc., indirectly from the sole textual description of the system.
  • the invention thus provides a method for producing data representing the topology of a system which comprises one or more modules each having a determined number of input ports and a determined number of output ports and linked together by determined signals , from the textual description of the system in an object oriented language
  • a module initialization function comprising, as a parameter, an identifier of a topology extraction object and receiving, when called, the address of said topology extraction object;
  • connection function for each port of each module, as many times as there are respective signals connected to this port, with each time an identifier of the signal concerned as a parameter.
  • connection function of each port of each module makes the connection to this port of the signal whose identifier is specified as a parameter. On the other hand, it sends the address of this signal to the topology extraction object if the module initialization function has already been called or stores this address in the storage structure associated with said port if the module initialization function has not yet been called.
  • the initialization function of each module records the address of the topology extraction object whose identifier is specified as a parameter in said first internal variable of the module, sends the address and the functional type of the module to the topology extraction object, and, if necessary, sends for each port of the module the respective addresses of each signal connected to this port which have been previously stored in the storage structure associated with said port.
  • the topology extraction object receives the address of each module, and the address of each signal connected to each port of each module, and stores them in a determined topology storage structure.
  • the data representing the topology of the system is extracted as the netlist is executed.
  • a memory structure for example an array and / or a list in which the information on the typology of the system is stored.
  • the system designer does not have to worry about the relative order of the calls to the initialization functions of each of the modules on the one hand and to the connection functions of one of the ports of this module on the other hand .
  • FIG. 1 is an example system diagram which is used to illustrate the principle of the invention
  • FIG. 2 is a flow diagram of the steps of a method according to the invention.
  • FIG. 3 is a flow diagram of the steps for processing the instructions contained in the textual description (netlist) of the system;
  • Figure 4 is a flow diagram of the steps executed when calling a connection function of a determined port of the system;
  • FIG. 5 is a flowchart of the steps executed when calling the initialization function of a specific module
  • FIG. 6 is a flow diagram of the steps executed for sending information to the topology extraction object on the connections which have been stored in the storage structure associated with a determined port;
  • FIG. 7 is a diagram illustrating a table included in a first topology storage structure
  • FIG. 8 is a diagram illustrating a list included in the first topology storage structure
  • - Figure 9 is a diagram illustrating a second topology storage structure
  • - Figure 10 is a diagram illustrating a third topology storage structure
  • FIG. 11 is a flowchart illustrating the steps of a method of recording topology information in the second or third topology storage structure from information stored in the first topology storage structure.
  • the designer adopts the strategy which consists in describing each module by two files.
  • a file whose name has the extension ".h” (file called “Header” in the jargon of those skilled in the art), which contains the declaration of the modules.
  • a file having the same name with the extension ".cpp” which contains the definition of the various functions of the modules.
  • main.cpp main file
  • main.cpp main file
  • the system ports can be either input ports, output ports, or input / output ports. It is considered that the type "Port” has been declared, the values of which are as follows: “INPUT”, “OUTPUT” and “INPUT / OUTPUT” respectively.
  • the names of the input ports of a module are prefixed with “in”. Likewise the names of the output ports have “out” as a prefix, and the input / output ports have “inout” as a prefix.
  • This system includes eleven modules M1 to M11. Each module includes at least one input port and / or at least one output port. For the sake of simplification of this presentation, an input / output port is not described. The invention however applies to systems comprising modules also having such ports.
  • the input and output ports of a given module are represented by a black rectangle respectively on the left or on the right of the module.
  • modules do not have input ports. This is the case for example of modules M1, M2, M7, M8 and M9. Such modules have a data generator function.
  • certain modules include several input ports (such as the M3 and M6 modules which have two and three respectively) and / or several output ports (such as the M6 module which includes two).
  • each module comprises a determined number n of input ports and a determined number m of output ports, where n and m are integers which may be zero.
  • the input ports of a given module are noted in i below and in Figure 1, where i can vary between 1 and n.
  • the output ports of a module determined are denoted outj in the following and in Figure 1, where j is an index between 1 and m.
  • this port is noted in, and when a determined module has only one output port, this port is noted out.
  • the modules M1 to M11 are interconnected by means of ten signals f1 to f10, these signals link more particularly:
  • Annex 1 gives the textual description, in SystemC language, of the declaration of a specific type of module called "module_x", according to the prior art.
  • the declaration of the module notably includes: - the declaration of the input ports in i of the module, for i between
  • SC_CTOR which is also a predefined function of the SystemC language; this definition of the constructor includes the initialization of the variables of the module on the one hand, and the declaration of the sensitivities of the methods of the module on the other hand.
  • ⁇ type> given in Annex 1 is mentioned as an indication to respect the syntax of the SystemC language, and does not prejudge the very type of each port concerned which can be chosen from the available types of the C ++ language.
  • a variable of the "structurejiste" type is intended to contain the address of a data storage structure associated with one of the ports of a given module.
  • the function of this associated storage structure is to store the addresses of the signals connected to this port.
  • this storage structure is a linked list.
  • Other examples of storage structure are of course conceivable, such as a tree or a table, or the combination of such elements.
  • a variable of type "recovery_class” is intended to contain the address of a topology extraction object associated with the system.
  • This object is specific to the implementation of the invention. It is a particular object having the function of extracting, from the textual description of the system (that is to say from the netlist written in SystemC language in the example), the data relating to the topology of this system and to store them in an appropriate form in an ad-hoc memory of the computer, for later use and / or_ their recording on an external data medium.
  • the declaration of the module includes first of all the declaration 21 of a function for initializing the module, called function "do_init" in an example.
  • This function is not in itself specific to the implementation of the invention. However, according to the invention, it includes as a parameter an identifier of the topology extraction object. Naturally, it can also receive other parameters which do not appear here as soon as they are unrelated to the invention. When called, it receives the address of the topology extraction object whose an identifier is provided as a parameter. Its description is included in the extension file ".cpp" and will be explained below with reference to the step diagram in Figure 5.
  • This declaration 21 takes the form of the following instruction, visible in Annex 2:
  • the presence of the symbol "&" after the type "ecup class” in parentheses allows the "dojnit” function to directly receive the address of the variable whose only name (and not address) is specified as a parameter .
  • This declaration 21 of the function is included in the part reserved for the declaration of the public functions of the module, that is to say after the expression "public:”. It follows that the "dojnit" function of the module concerned can be called from anywhere in the netlist (after however the occurrence of the instruction declaring this module (called instantiation or declaration instruction of this module).
  • the module declaration also includes the declaration 22 of respective connection functions for each of the input ports inj (with i between 1 and n) and output ports outj (with j between 1 and m) of the module.
  • connection functions are preferably called respectively "Inj” (with i between 1 and n) and “Outj” (with j between 1 and m).
  • These functions include in parameter an identifier of a signal connected to the corresponding port. When called, they receive the address of this signal.
  • the "&" symbol allows the function to receive the address of the signal whose identifier is passed as a parameter when calling the function, even when this identifier is the name of the signal (for example "f1" for the signal f1) and not the address of this signal (that is to say "& f1").
  • this identifier is the name of the signal (for example "f1" for the signal f1) and not the address of this signal (that is to say "& f1").
  • the identifier of the signal specified in parameter when calling the connection function of each port of each module can then be the name of this signal.
  • connection function (Inj or Outj) of each port (input or output, respectively) of each module has for name the name of said port (inj or outj, respectively) with the first letter in uppercase and the following letters in lowercase.
  • the above measures namely the presence of the symbol "&" in parentheses in the declaration of connection functions on the one hand, and the use of the port name with a capital letter in the first letter as the name of the connection function, on the other hand
  • this reduces the changes in the writing of the netlist describing the system compared to the current habits of system designers in SystemC language.
  • the declaration of the module also includes the declaration 23 of a variable of type "class_recup", called “Circuit” in the example. As mentioned above, such a variable is suitable for storing the address of the topology extraction object associated with the system.
  • This declaration takes the form of the following instruction, visible in Appendix 2: “classe_recup * Circuit”
  • each module also includes the declaration 24 of variables of type "structurejiste" respectively associated with each of the ports of the module.
  • the variables are adapted to contain the address of a storage structure associated with this port.
  • the variables "hdlnj” (with i between 1 and n) and “hdOutj” (with j between 1 and m) are declared for each of the input ports and output ports respectively.
  • This declaration takes the form of the following instruction, visible in Appendix 2: "structurejiste * hdlnj” and, "Structurejiste * hdOutJ", for i between 1 and n, and j between 1 and m.
  • the declaration of the module also includes the initialization of the variables "hdlnj” (with i between 1 and n), “hdOutj” (with j between 1 and m) and "Circuit", at a respective determined initial value.
  • this initial value is the null value for each of these variables.
  • the declaration of the module also includes the declaration of a function for sending topology information to the topology extraction object.
  • This function is called "do_sendJnfo" in the example, the choice of this name being purely arbitrary and therefore in no way limiting.
  • This function is a private function of the module. It is declared in the function part
  • Annex 3 provides the partial declaration of the M6 module of the system shown in Figure 1, which appears to be the most complex from the point of view of topology, that is to say from the point of view of the number of its ports.
  • this is a type module called "Dec" in the example.
  • Annex 4 and Annex 5 contain a portion of the netlist corresponding to the textual description of the system of FIG. 1, respectively according to the prior art and according to the invention.
  • This portion of the netlist which is written in SystemC language, is included in the file with the extension ".cpp".
  • the instructions relating to the description of the topology of the system have been mentioned. It is understood that other instructions are necessary for the description of the operation of the system, but do not appear here because they are not useful for understanding the invention.
  • the instructions necessary for the description of the system include the instructions for declaring the modules M1 to M11 (we generally speak of instructions for instantiating the modules in the jargon of those skilled in the art, to designate these instructions), the instructions for connecting the input and output ports of the modules, and the instructions for initializing the modules by calling the "dojnit" function of each of the modules.
  • the instructions for connecting the input ports and the output ports of the modules are made, according to the invention, by calling the corresponding "Inj" or "Outj" function.
  • FIG. 3 schematically illustrates the steps of a method for executing the netlist of Annex 5, which consists in executing the instructions it contains sequentially. These operations are executed by the simulation kernel (processor controlled by an ad hoc program) of SystemC.
  • a step 31 one wonders whether the netlist still contains an instruction to be executed. If the answer is no, then, in a step 32, the simulation of the system and / or the processing of the topology is launched. This step 32 corresponds to the very essence of the applications for the design and system simulation in SystemC. Otherwise, and for each instruction contained in the netlist, one wonders in a step 33 what is the type of the instruction concerned.
  • step 34 we construct the module concerned. This consists in executing the "SCjMODULE” function for this module. In particular, this execution initializes the variables "Circuit”, “hdlnj” (for i between 1 and n) and “hdOutj” (opur j between 1 and n) of the module.
  • Step 35 If it is an instruction to connect an input or output port of a module, for example the instruction "M6.ln_1 (f4)" to connect the input in_1 of the M6 module to signal f4, then, in a step 35, the function Inj or the corresponding function Outj is called. Step 35 will be detailed below with reference to the flow diagram of FIG. 4. If it is an instruction for initializing a module, for example the instruction “M ⁇ .dojnit (Circuit) For the initialization of the module M6, then, in a step 36, the initialization of this module is executed. This is done by calling the "dojnit" function of this module. Step 36 will be detailed below with reference to the flow diagram of FIG. 5. If it is another instruction (unrelated to the topology of the system, therefore not visible in the netlist of the Appendix 5), then, in a step 37, the instruction concerned is executed.
  • the instruction concerned is executed.
  • the flow diagram of FIG. 4 illustrates the detail of step 35, which consists in executing a connection instruction Inj or Outj of a port respectively of input or output of a determined module.
  • making a connection consists in associating a signal with a port to which this signal is connected.
  • the code for implementing the Inj and Outj functions of the M6 module is provided in Appendix 6
  • connection function ln_1 has been called to connect any signal p to the input in_1 of the module M6.
  • This call can take the following form, visible in Annex 5:
  • M6.ln_1 (f1) for the connection of the signal f1 to the input in_1 of the M6 module.
  • the "SetLien” method is defined for objects of type "ecup class". It allows the recording of a connection by the topology extraction object.
  • This connection is defined by the address of the module concerned (given by the term “this” which is a predefined term in the SystemC language), the address of the connected signal (ie "&p” in the example), the type “Portjype "(for example the value” INPUT “or the value” OUTPUT “depending on whether it is an input port or an output port, respectively), and the serial number of this port in its type, noted q (which corresponds to the order of appearance port in the module port declaration list, the input ports and the output ports being distinguished and counted separately).
  • the "SetLien” function creates a new cell to be added to the list of existing cells, for example according to an approach known in add to the top of the list.
  • the cell created is defined using the information passed in parameters for the following fields: address of the module concerned, address of the connected signal, type of port concerned, number of this port in the type.
  • the implementation of the "SetLien” function is within the reach of those skilled in the art.
  • An example of implementation of this function in SystemC language is given in Annex 7.
  • the topology storage structure chosen for the representation in memory of the topology is a linked list.
  • the "SetLink" function when called for a specific topology retrieval object, creates a new cell to add to the existing cells of the list. This new cell is populated with the information passed in parameters, for the following fields: address of the module concerned, address of the connected signal, type of the port concerned, number of this port in its type.
  • the list storing the information on the connections of the circuit already made is thus enriched with a new cell, consequently, with a new connection.
  • ListStorageTopology the list which allows the topology extraction object to store in memory the list of connections already made. This list, which initialized at the null address "NIL”, is enriched each time the "SetLien” function is called, with a new cell corresponding to a new connection.
  • step 41 If, in step 41, the answer is no, this means that the "dojnit" function of the module has not yet been called.
  • step 43 the address of the signal concerned is recorded in the associated storage structure at the port concerned. This is for example achieved by calling a "AddLink" function, which is declared as follows:
  • the "AddLien” function is a function accessible to all modules. In an example, it is called as follows to connect a signal to the input port in_1 of the M6 module: "AddLink (& hdln_1, &p)"
  • step 44 the actual connection of the signal to the port concerned is then carried out. This is achieved, in the usual way in SystemC language, by the following instruction:
  • FIG. 5 a flowchart is shown which gives the details of the steps implemented during step 36 (FIG. 3) to which the initialization function "dojnit" of a given module is called. Still by way of example, in the following we will consider the case of calling the initialization function of the M6 module, with the following instruction:
  • This method receives as argument the identifier of the system topology extraction object, ie the module's "Circuit" variable.
  • the method starts by performing a test 51 to find out if the "dojnit" function has already been called before, which would be an error.
  • Such a test is carried out for example by the following instruction:
  • the error is managed. For example, we generate an interrupt.
  • the address is stored the topology extraction object in the module's internal "Circuit" variable. This is done for example by an instruction such as
  • a step 54 we send to the topology extraction object all the information on the connections already made for this module, and which have been stored in the storage structures associated with each of the input ports and / or module output.
  • a "do sendjnfo" method is used to send to the topology extraction object all the information on the connections which may have been made before by previous calls to the connection functions Inj and / or Outj for this module.
  • the detail of the execution of the "do_sendjnfo" function will now be explained with reference to the flow diagram of FIG. 6.
  • a step 61 it is checked that the module does indeed belong to a system and that it is therefore possible to send information to the topology extraction object associated with this system. This is achieved by testing the value of the "Circuit" variable, by an instruction already presented above, of the type
  • the error is managed for example by introducing an interrupt.
  • step 63 the address of the module is sent (given by the term “this” which is a predefined term in the C ++ language) as well as its functional type ("Dec" for the module
  • step 64 one wonders if one has traversed all the ports of the module. As long as one remains not yet processed, it is asked in a step 65 if the storage structure associated with this port is empty. If the answer is yes, it means that no signal has yet been connected to this port, and we return to step 64. If on the contrary the answer is no, it means that at least one signal has been connected to this port to make a connection. For each signal address thus stored (step 66), the address of this signal is sent in a step 67 to the topology extraction object using the "SetLien" function already presented above.
  • the lists are then destroyed, in a step 68, thanks to a "DeleteList" function whose implementation is within the reach of those skilled in the art and which is part of a library accessible by the modules. This is achieved, for example for the storage list of connections associated with the input port in_1 of the M6 module, by an instruction of the following type:
  • the topology extraction object receives the address of each module which is passed to it when the "MakeModule" function is called. It also receives the address of each signal connected to each port of each module, during calls to the respective Inj and Outj connection functions for each of these ports. It stores these different addresses in a storage structure with a determined topology.
  • this topology storage structure includes an array and a list dynamically generated by the topology retrieval object. When all the topology information relating to the system has been extracted, the table includes as many filled cells as there are modules present in the system. It is called an array of modules in the following. In addition, the list contains as many cells as there are port / signal connections in the system. It is called list of connections in the following.
  • the module table in its final state (that is to say after the complete execution of the netlist describing the system), is illustrated in Figure 7.
  • Each cell of the table is represented by one of its lines.
  • the cells are filled in dynamically, each time the "MakeModule" function is called.
  • the first cell C0, of index 0 in the table was created first, and the eleventh cell C10, of index 10 in the table, was created last.
  • Each cell includes (from left to right):
  • FC3 a third field FC3 containing a list of parameters; these parameters are made up of any information which could characterize the module, and which would be transmitted as a parameter by the "dojnit" function.
  • the list of parameters has a length which depends on the type of module. So, in an example:
  • FIG. 8 The list of connections, in its final state, is illustrated in FIG. 8. It includes here twenty chained cells, one per connection of the system of FIG. 1.
  • the cells are graphically represented by tables with one column and five lines. They contain all the data necessary to define a connection.
  • the cells are created dynamically, each time the "SetLien" function is called, so as not to unnecessarily reserve memory space. As for clarity reasons, it is indicated opposite cell L4 only, each cell comprises (from top to bottom):
  • the order of cells L0 to L19 in the list as represented in FIG. 8, corresponds to the respective order of the calls to the functions Inj and Outj as it appears in the netlist of Appendix 5.
  • the address T of the first cell L0, called the list head hereinafter, is contained in a particular memory cell denoted HL in the figure.
  • the fifth field of each of the cells L0 to L18 symbolically contains the term "next" to designate the address of the next cell in the list.
  • the fifth field of the last cell L19 contains a pointer to a particular memory cell which contains the value "NIL" to indicate that there is no next cell in the list.
  • the topology information can then be read in the storage structure consisting of this table and this list by any hardware and / or software device for specific processing.
  • this information can be used by a placement / routing module to design the implantation of the system on silicon, when the system is a microelectronic system. They can also be supplied as input to a display module making it possible to provide a graphic representation of the system on a screen, and / or to a printing module making it possible to print a document such as a diagram of the system.
  • topology storage structure comprising the table and the list represented in FIGS. 7 and 8, it is also possible to create a second list storage structure which comprises a single table containing the information on the connections between the modules of the system.
  • Such a table is represented by the diagram in FIG. 9.
  • it comprises ten cells denoted T0 to T9, one per signal from the system.
  • One cell corresponds to a column in the table. It includes four fields.
  • the table is therefore a table with ten columns and four rows.
  • incoming module and “outgoing module” designates the module of which an input port or an output port respectively is connected to the signal.
  • the input port number and output port number denote the number in its type, respectively "INPUT” or “OUTPUT” of the input port and the output port to which this signal is connected.
  • the four fields of a cell are:
  • the second topology storage structure represented in FIG. 9 is a table comprising one cell per signal, each cell containing information characterizing the connection between two modules via this signal.
  • This topology storage structure makes it possible to list all the connections of the circuit.
  • a third topology storage structure can be generated from the first topology storage structure. For example, one can add to the cells of the table of modules represented in FIG. 7, additional fields which provide information on the immediate neighboring modules of the module, or, more specifically still, on the position of the module in the topology of the circuit.
  • a fourth field FC4 has been added to each cell C0 to C11 of the module table which contains a pointer to the list. This pointer designates the address of the head of a list of connections associated with the module, noted VO to V11 respectively. This list is made up of as many cells as the module has connections, one cell per connection.
  • each cell in the associated list respectively VO to V11 contains the following six fields (from left to right): - a first field FV1 which contains the type of port of the module concerned which is connected;
  • the third topology storage structure represented in FIG. 10 comprises a table comprising one cell per module of the system, and each cell of which comprises a field FC4 containing a pointer to the list, which designates a list (V0 to V10) of the links of this module with other modules of the system.
  • topology storage structure can be imagined, of varying complexity, depending on the application for which it is intended to be used (placement / routing, signal tracing, study of signal propagation, etc.).
  • placement / routing, signal tracing, study of signal propagation, etc. we will now describe how, from the information which is stored dynamically in the first topology storage structure (that is to say in the table of modules in FIG. 7 and in the list in FIG. 8), we can , at the end of the description of the system, reconstitute the topology of this one, i.e. have the list of the modules of the circuit, as well as for each of them, the detail of their connection with the other modules ( port to port).
  • the reconstruction mechanism is as follows.
  • the list head cell is accessed, the address T of which is contained in the memory cell HL.
  • This list head cell contains the information characterizing a connection between a port and a signal. We will then browse the rest of the list in search of cells that characterize connections on the same signal.
  • a test 120 one wonders if the list is empty (that is to say, in practice, if the address T is equal to NIL). If the answer is yes, then the process is complete.
  • step 130 the address of the module concerned is stored as well as the type of the port and its number in the type. Then, in a step 140, in the field FL2 of the list head cell, the address of the signal concerned by the connection is read. In a step 150, it is then asked whether the next cell in the list is the NIL cell. If the answer is yes, it means that the port of the module concerned by the connection is not connected to any other module, which constitutes an error. This error is then treated in a step 151, for example by generating an interrupt 152.
  • step 160 the next cell in the list is accessed. Then, in a step 170, the address in the field FL2 of this next cell in the list is read, the address of the signal concerned by the corresponding connection. If the addresses of the signals concerned by the connections of the head list cell and the next cell, which were read in steps 140 and 170 respectively, are equal, then, in a step 180, the address of the module concerned is stored as well as the type of the port and its number in the type.
  • a step 190 it is then asked whether the next cell in the list is the null cell. If the answer is no, then we jump to step 160 where we access this next non-zero cell.
  • the information relating to the links between the different modules linked together by the signal concerned by the identified connections is stored in the desired form.
  • this information can be stored in the second or third topology storage structure presented above with reference to FIGS. 9 and 10 respectively.
  • step 210 the cells of the list which have been processed are deleted, and one jumps to step 110 to access the new cell at the head of the list and repeat the process.
  • connection function surin_1 // declaration of the connection function surin_1: void Inj (sc_signal ⁇ double> &);
  • connection function surout_1 // declaration of the connection function surout_1: void Out (sc_signal ⁇ double> &);
  • Source modules M1 ("M1”); Source M2 ("N ⁇ -); Source M7 (“ M7 “); Source M8 (“ M8 “); Source M9 (“ M9 “); Display M5 ( n M5 n ); Display MIO CMIO”); Display M11 (“MU”); Add M3 (“M3”); Mult M4 CM4 M ); Dec M6 (“M6”);
  • DeleteListe // release the variables for storing topology information.
  • DeleteListe &hdlnj
  • DeleteListe &hdln_2
  • DeleteListe &hdln_3
  • DeleteListe &hdOutJ
  • DeleteListe &hdOut_2
  • new_cell -> AddModule module_address
  • new_cell -> AddSignal address_signal
  • new_cell -> PortType type_du_port
  • new_cell -> PortNum port_num
  • new_cell -> next HeadList;

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Pour permettre la production de données représentant la topologie d’un système qui comprend un ou plusieurs modules à partir de la description textuelle du système dans un langage orienté objet, une fonction de connexion de chaque port de chaque module, d’une part, réalise (44) la connexion à ce port du signal dont l’identifiant est spécifié en paramètre, et d’autre part envoie (42) l’adresse de ce signal à un objet d’extraction de topologie si une fonction d’initialisation du module a déjà été appelée ou enregistre (43) cette adresse dans la structure de stockage associée audit port si la fonction d’initialisation du module n’a pas encore été appelée.

Description

PROCEDE D'EXTRACTION DE LA TOPOLOGIE D'UN SYSTEME A PARTIR DE SA DESCRIPTION TEXTUELLE
La présente invention concerne un procédé de production de données représentant la topologie d'un système, à partir de la description textuelle du système dans un langage orienté objet, notamment le langage SystemC.
Elle se rapporte au domaine des techniques de description de systèmes dans un langage formel, de simulation des systèmes et plus généralement de la conception de systèmes assistée par ordinateur (CAO).
Des langages formels tels que VHDL, Verilog ou SystemC permettent de décrire textuellement, avec une approche orientée objet, un système comprenant un ou plusieurs modules matériels (hardware) et/ou logiciels (software). Chaque module du système est représenté par un objet ayant un nombre déterminé de ports d'entrée et un nombre déterminé de ports de sortie, voire des ports d'entrée/sortie dans certaines applications. Les modules sont raccordés entre eux par des signaux qui relient au moins un port de sortie d'un module à au moins un port d'entrée d'un autre module, voire du même module (en cas de bouclage d'une sortie avec une entrée du module). Dans le langage de l'homme du métier et dans la suite, l'association entre un port et un signal qui lui est relié est appelée une connexion.
La description textuelle du système prend la forme d'un code (ou programme) suivant la syntaxe propre au langage formel. Le code est enregistré sur un support de mémorisation quelconque, éventuellement après une opération de compilation, et peut être chargé dans la mémoire d'un ordinateur. Il peut alors être exécuté par l'ordinateur, notamment pour simuler le fonctionnement du système.
Dans le jargon de l'homme du métier, la description textuelle du système, c'est-à-dire le code dans le langage formel, est appelée "netlist". Le concepteur d'un système fabrique la description textuelle du système en programmant dans un langage formel. Dans la suite, on considère seulement l'exemple de SystemeC, bien que l'invention ne se limite pas à ce langage formel particulier. SystemC a été récemment introduit pour la description des systèmes.
C'est un langage unique capable de décrire les systèmes à tous les niveaux d'abstraction, qui offre de nombreuses opportunités pour utiliser les concepts de la programmation orientée objet. SystemC est inspiré du langage C++ et en utilise avantageusement l'expressivité pour la modélisation des systèmes.
Mais SystemC est aussi une bibliothèque d'objets pré-codés (aussi appelés « classes »), et un noyau de simulation, utilisables pour modéliser et simuler le fonctionnement d'un système. Chaque module du système est représenté par un objet C++ qui caractérise ses ports d'entrée et/ou de sortie, ainsi que le principe de son fonctionnement via des fonctions (aussi appelées « méthodes » ou « processus ») qui pilotent la variation des signaux reliés aux sorties du module en fonction de la variation des signaux reliés aux entrées du module. Dit autrement, le noyau de simulation exécute le code du système.
Un objet de l'invention est de proposer une méthode permettant, de façon la plus transparente possible pour le concepteur, d'obtenir dynamiquement la topologie d'un système à partir de la netlist de ce système écrite en langage formel, notamment mais pas exclusivement SystemC. Par l'adverbe "dynamiquement", on entend "au fur et à mesure" de l'exécution du code du système. On dispose ainsi automatiquement et immédiatement de la topologie du système, pour une utilisation ultérieure.
Par topologie du système, on entend la connaissance des modules qui le composent et de leurs raccordements via les signaux précités. Cette topologie est entièrement définie par la liste des connexions du système. Des données représentant cette topologie peuvent être produites à partir de la netlist elle-même (puisque cette netlist décrit la structure du système dans sa globalité).EIIes peuvent être stockées en mémoire sous des formes diverses, notamment dans un ou plusieurs fichiers formant une structure mémoire appropriée.
Ces données permettent de disposer de l'ensemble des informations sur la topologie du système : informations sur tous ses composants et leurs raccordements entre eux. Cela peut s'avérer très utile pour de nombreuses applications, par exemple la génération d'une représentation graphique du système (sur un écran ou sur du papier), la mise en oeuvre d'un logiciel de placement/routage des modules du système en vue de son implantation vers le matériel cible, etc., indirectement à partir de la seule description textuelle du système. L'invention propose ainsi un procédé de production de données représentant la topologie d'un système qui comprend un ou plusieurs modules ayant chacun un nombre déterminé de ports d'entrées et un nombre déterminé de ports de sortie et reliés entre eux par des signaux déterminés, à partir de la description textuelle du système dans un langage orienté objet
Suivant l'invention, on introduit dans la déclaration de chaque module du système :
- la déclaration d'une fonction d'initialisation du module comprenant en paramètre un identifiant d'un objet d'extraction de topologie et recevant, lorsqu'elle est appelée, l'adresse dudit objet d'extraction de topologie ;
- la déclaration de fonctions de connexion respectives pour chacun des ports d'entrée et des ports de sortie du module comprenant en paramètre un identifiant d'un signal relié audit port, et recevant, lorsqu'elle est appelée, l'adresse dudit signal ; - la déclaration d'une première variable interne adaptée pour stocker l'adresse de l'objet d'extraction de topologie ;
- la déclaration d'autres variables internes respectivement associées à chacun des ports d'entrée et des ports de sortie du module, et adaptées pour contenir l'adresse d'une structure de stockage associée ; et, - l'initialisation desdites première et autres variables internes à une valeur initiale déterminée respective.
De plus, on introduit, dans la description textuelle du système et dans un ordre quelconque :
- l'appel de la fonction d'initialisation de chaque module, avec un identifiant de l'objet d'extraction de topologie en paramètre ;
- l'appel de la fonction de connexion de chaque port de chaque module, autant de fois qu'il y a de signaux respectifs reliés à ce port, avec à chaque fois un identifiant du signal concerné en paramètre.
La fonction de connexion de chaque port de chaque module, d'une part réalise la connexion à ce port du signal dont l'identifiant est spécifié en paramètre. D'autre part, elle envoie l'adresse de ce signal à l'objet d'extraction de topologie si la fonction d'initialisation du module a déjà été appelée ou enregistre cette adresse dans la structure de stockage associée audit port si la fonction d'initialisation du module n'a pas encore été appelée.
La fonction d'initialisation de chaque module enregistre l'adresse de l'objet d'extraction de topologie dont l'identifiant est spécifié en paramètre dans ladite première variable interne du module, envoie l'adresse et le type fonctionnel du module à l'objet d'extraction de topologie, et, le cas échéant, envoie pour chaque port du module les adresses respectives de chaque signal relié à ce port qui ont été préalablement stockées dans la structure de stockage associée audit port. L'objet d'extraction de topologie reçoit l'adresse de chaque module, et l'adresse de chaque signal relié à chaque port de chaque module, et les stocke dans une structure de stockage de topologie déterminée.
Ainsi, les données représentant la topologie du système sont extraites au fur et à mesure de l'exécution de la netlist. On obtient ainsi, directement, une structure mémoire (par exemple un tableau et/ou une liste) dans laquelle les informations sur la typologie du système sont stockées.
Avantageusement, le concepteur du système n'a pas à se soucier de l'ordre relatif des appels des fonctions d'initialisation de chacun des modules d'une part et des fonctions de connexion d'un des ports de ce module d'autre part.
D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels :
- la figure 1 est un schéma d'exemple de système qui est utilisé pour illustrer le principe de l'invention ;
- la figure 2 est organigramme des étapes d'un procédé selon l'invention ;
- la figure 3 est un organigramme des étapes de traitement des instructions contenues dans la description textuelle (netlist) du système ; - la figure 4 est un organigramme des étapes exécutées lors de l'appel d'une fonction de connexion d'un port déterminé du système;
- la figure 5 est un organigramme des étapes exécutées lors de l'appel de la fonction d'initialisation d'un module déterminé ; - la figure 6 est un organigramme des étapes exécutées pour l'envoi vers l'objet d'extraction de topologie des informations sur les connexions qui ont été stockées dans la structure de stockage associée à un port déterminé ;
- la figure 7 est un schéma illustrant un tableau compris dans une première structure de stockage de topologie ;
- la figure 8 est un schéma illustrant une liste comprise dans la première structure de stockage de topologie ;
- la figure 9 est un schéma illustrant une deuxième structure de stockage de topologie ; - la figure 10 est un schéma illustrant une troisième structure de stockage de topologie ; et,
- la figure 11 est un organigramme illustrant les étapes d'un procédé d'enregistrement des informations de topologie dans la deuxième ou la troisième structure de stockage de topologie à partir des informations stockées dans la première structure de stockage de topologie.
La description qui suit est donnée en référence à un exemple dans lequel on utilise, pour la description textuelle du système, le langage de programmation de SystemC, qui est inspiré du langage C++.
En général, le concepteur adopte la stratégie qui consiste à décrire chaque module par deux fichiers. D'une part un fichier dont le nom possède l'extension ".h" (fichier appelé "Header" dans le jargon de l'homme du métier), qui contient la déclaration des modules. Et d'autre part un fichier ayant le même nom avec l'extension ".cpp", qui contient la définition des différentes fonctions des modules. En général, le système est alors décrit dans un fichier principal (classiquement appelé "main.cpp") qui incorpore les instructions qui sont exécutées par l'ordinateur pour la simulation sous SystemC du fonctionnement du système, et qui accède aux fichiers d'extension ".h" et ".cpp" de chaque module lorsque c'est nécessaire. Seul ce fichier "main.cpp" est compilé pour l'exécution de la netlist du système. Les ports du système peuvent être soit des ports d'entrée, soit des ports de sortie, soit des ports d'entrée/sortie. On considère qu'il a été déclaré le type "Port" dont les valeurs énumérées sont les suivantes : « ENTREE », « SORTIE » et « ENTREE/SORTIE » respectivement. Les noms des ports d'entrée d'un module sont préfixés par "in". De même les noms des ports de sortie ont "out" comme préfixe, et les ports d'entrées/sortie ont "inout" comme préfixe.
Dans les Annexes 1 à 6, on a donné des portions de code en langage SystemC correspondant à des parties de la déclaration des modules (dans le fichier d'extension ".h") et/ou de la description textuelle du système (dans le fichier d'extension ".cpp") qui sont utiles à la compréhension de l'invention. Par souci de clarté, des commentaires sont introduits dans ces portions de code, après les caractères "//" et en caractères italiques. A la figure 1 , on a représenté le schéma d'un exemple de système utilisé dans la description ci-après pour illustrer l'invention.
Ce système comprend onze modules M1 à M11. Chaque module comprend au moins un port d'entrée et/ou au moins un port de sortie. Par soucis de simplification du présent exposé, il n'est pas décrit de port d'entrée/sortie. L'invention s'applique toutefois aux systèmes comprenant des modules ayant également de tels ports. Les ports d'entrée et de sortie d'un module déterminé, sont représentés par un rectangle noir respectivement sur la gauche ou sur la droite du module.
On constate que certains modules n'ont pas de ports d'entrée. C'est le cas par exemple des modules M1 , M2, M7, M8 et M9. De tels modules ont une fonction de générateur de données. On constate également que d'autres modules n'ont pas de ports de sortie. Il s'agit dans l'exemple des modules M5, M10 et M11. De tels modules ont pour fonction de traiter des données reçues sans produire eux-mêmes de nouvelles données. Un tel traitement comprend par exemple l'affichage de la donnée. On constate en outre que certains modules comprennent plusieurs ports d'entrée (comme les modules M3 et M6 qui en comportent respectivement deux et trois) et/ou plusieurs ports de sortie (comme le module M6 qui en comporte deux).
Dans le cas général, on considérera dans la suite que chaque module comprend un nombre déterminé n de ports d'entrée et un nombre déterminé m de ports de sortie, où n et m sont des nombres entiers éventuellement nuls.
Les ports d'entrée d'un module déterminé sont notés in i dans la suite et à la figure 1 , où i peut varier entre 1 et n. De même, les ports de sortie d'un module déterminé sont notés outj dans la suite et à la figure 1 , où j est un indice compris entre 1 et m. Toutefois, par souci de simplicité, lorsqu'un module déterminé n'a qu'un port d'entrée ce port est notée in, et lorsqu'un module déterminé n'a qu'un port de sortie ce port est noté out.
Pour les onze modules M1 à M11 du système représenté à la figure 1 , le nombre n de ports d'entrée et le nombre m de ports de sortie de chaque module est donné par le Tableau I ci-dessous :
Figure imgf000009_0001
Tableau I Les modules M1 à M11 sont reliés entre eux par l'intermédiaire de dix signaux f1 à f10, ces signaux relient plus particulièrement :
- pour le signal f1 : la sortie out de M1 à l'entrée in_1 de M3 ;
- pour le signal f2 : la sortie out de M2 à l'entrée in_2 de M3 ;
- pour le signal f3 : la sortie out de M3 à l'entrée in de M4 ;
- pour le signal f4 : la sortie out de M3 à l'entrée in_1 de M6 ; - pour le signal f5 : la sortie out de M4 à l'entrée in de M5 ;
- pour le signal f6 : la sortie out de M7 à l'entrée in_1 de M6 ;
- pour le signal f7 : la sortie out de M8 à l'entrée in_2 de M6 ;
- pour le signal f8 : la sortie out de M9 à l'entrée in_3 de M6 ;
- pour le signal f9 : la sortie out_1 de M6 à l'entrée in de M10 ; et, - pour le signal f10 : la sortie out_2 de M6 à l'entrée in de M11.
Dans le jargon de l'homme du métier et dans la suite, l'association entre un signal d'une part et un port d'un module déterminé auquel ce signal est relié d'autre part, est appelé une connexion du système.
Pour décrire le système représenté à la figure 1 , il faut tout d'abord définir un certain nombre de types de modules. On définit ainsi :
- un type « Source » pour les modules M1 , M2, M7, M8 et M9 ;
- un type « Display » pour les modules M5, M10 et M11 ;
- un type « Add »pour le module M3 ;
- un type « Mult » pour le module M4 ; et, - un type « Dec »pour le module M6.
La définition d'un type de module particulier se fait dans le langage
SystemC, grâce à la fonction SC_MODULE qui est une fonction prédéfinie de ce langage. Bien entendu, les noms donnés aux types de modules précités sont tout à fait arbitraires et ne sauraient être interprétés comme une caractéristique limitative de l'invention.
L'Annexe 1 donne la description textuelle, en langage SystemC, de la déclaration d'un type de module déterminé appelé « module_x », selon l'art antérieur. La déclaration du module comprend notamment : - la déclaration des ports d'entrée in i du module, pour i compris entre
1 et n, grâce à la fonction sc_in qui est une fonction prédéfinie du langage SystemC ;
- la déclaration des ports de sortie outj du module, pour j compris entre 1 et m, grâce à la fonction sc_out qui est également une fonction prédéfinie du langage SystemC ;
- la déclaration des variables privées du module et des méthodes ou fonctions privées du module, qui suit l'expression « private : » ;
- la déclaration des variables publiques du module et des méthodes ou fonctions publiques du module qui suit l'expression « public : » ; - la définition du constructeur du module grâce a la fonction
"SC_CTOR" qui est également une fonction prédéfinie du langage SystemC ; cette définition du constructeur comprend l'initialisation des variables du module d'une part, et la déclaration des sensitivités des méthodes du module d'autre part. Le vocable "<type>" donné à l'Annexe 1 est mentionné à titre indicatif pour respecter la syntaxe du langage SystemC, et ne préjuge pas du type même de chaque port concerné qui peut être choisi parmi les types disponibles du langage C++.
A l'Annexe 2, on a donné la description de la déclaration d'un module selon l'invention. Par souci de clarté, les éléments ajoutés par rapport à la déclaration classique d'un module telle que rappelée à l'Annexe 1 , sont présentés en caractères gras. On suppose que le fichier d'extension ".h" comprend par ailleurs la définition de types de variables déterminés, appelés "structurejiste" d'une part, et "classe_recup" d'autre part.
Une variable du type "structurejiste" est destinée à contenir l'adresse d'une structure de stockage de données associée à l'un des ports d'un module déterminé. Cette structure de stockage associée a pour fonction de stocker les adresses des signaux reliés à ce port. Dans un exemple préféré pour sa simplicité, cette structure de stockage est une liste chaînée. D'autres exemples de structure de stockage sont bien entendu envisageables, tel qu'un arbre ou un tableau, ou la combinaison de tels éléments.
Une variable de type "classe_recup" est destinée à contenir l'adresse d'un objet d'extraction de topologie associé au système. Cet objet est spécifique de la mise en œuvre de l'invention. Il s'agit d'un objet particulier ayant pour fonction d'extraire, de la description textuelle du système (c'est-à- dire de la netlist écrite en langage SystemC dans l'exemple), les données relatives à la topologie de ce système et de les stocker sous une forme appropriée dans une mémoire ad-hoc de l'ordinateur, en vue d'une utilisation ultérieure et/ou_de leur enregistrement sur un support de données externe.
Bien entendu, les noms donnés aux deux types de variables précités sont tout à fait arbitraires et ne sauraient être interprétés comme une caractéristique limitative de l'invention.
Les étapes de la déclaration de chaque module qui sont spécifiques de l'invention (c'est-à-dire qui sont nécessaires à la mise en œuvre du procédé d'extraction de données relatives à la topologie du système) sont illustrées par l'organigramme de la figure 2.
La déclaration du module (par la fonction SC_MODULE de SystemC) comprend tout d'abord la déclaration 21 d'une fonction d'initialisation du module, appelée fonction "do_init" dans un exemple. Cette fonction n'est pas en soi spécifique à la mise en œuvre de l'invention. Néanmoins, selon l'invention, elle comprend en paramètre un identifiant de l'objet d'extraction de topologie. Naturellement, elle peut aussi recevoir d'autres paramètres qui n'apparaissent pas ici dès lorsqu'ils sont sans rapport avec l'invention. Elle reçoit, lorsqu'elle est appelée, l'adresse de l'objet d'extraction de topologie dont un identifiant lui est fourni en paramètre. Sa description est incluse dans le fichier d'extension ".cpp" et sera explicitée plus loin en regard du diagramme d'étapes de la figure 5.
Cette déclaration 21 prend la forme de l'instruction suivante, visible à l'annexe 2 :
« void dojnit (classe_recup &, et types des autres paramètres) » où le vocable "void" signifie que la fonction "dojnit" ne retourne aucune information lorsqu'elle est appelée, et où le type "classe_recup" entre parenthèses spécifie que la fonction reçoit, lorsqu'elle est appelée, une donnée de type "classe_recup", qui est une adresse. On trouve ensuite les types des autres paramètres de la fonction dojnit, qui ne concernent pas la topologie du système mais se réfèrent à la description fonctionnelle du module et ne sont donc pas explicités ici.
De plus, la présence du symbole "&" après le type "classe ecup" entre parenthèses permet à la fonction « dojnit » de recevoir directement l'adresse de la variable dont seul le nom (et non l'adresse) est spécifié en paramètre. Dit autrement, on peut appeler la fonction « dojnit » avec en paramètre un identifiant qui est le nom de la variable et, pour autant, l'objet qui appelle cette fonction recevra l'adresse de cette variable. Sans la présence du symbole "&" après le type du paramètre de la fonction « dojnit » spécifié entre parenthèses dans la déclaration de cette fonction, il faudrait, pour parvenir au même résultat, ajouter le symbole "&" devant le nom de la variable passée en paramètre lors de l'appel de la fonction « dojnit » afin de transmettre l'adresse de cette variable. Dit autrement, l'identifiant de la variable passée en paramètre ne serait pas son nom, mais un pointeur donnant l'adresse de la variable. Cette disposition de l'invention permet donc d'utiliser le nom de l'objet d'extraction de topologie comme identifiant dudit objet spécifié en paramètre lors de l'appel de la fonction d'initialisation de chaque module. L'avantage est de simplifier l'écriture de la netlist par le concepteur du système. Cette déclaration 21 de la fonction est comprise dans la partie réservée à la déclaration des fonctions publiques du module, c'est-à-dire après l'expression "public :". Il s'ensuit que la fonction « dojnit » du module concerné peut être appelée de n'importe quel endroit de la netlist (après toutefois l'occurrence de l'instruction déclarant ce module (dite instruction d'instanciation ou de déclaration de ce module).
Bien entendu, le nom donné à la fonction d'initialisation précitée est tout à fait arbitraire et ne saurait être interprété comme une caractéristique limitative de l'invention.
La déclaration du module comprend aussi la déclaration 22 de fonctions de connexion respectives pour chacun des ports d'entrée inj (avec i compris entre 1 et n) et des ports de sortie outj (avec j compris entre 1 et m) du module. Ces fonctions de connexion sont de préférence appelées respectivement « Inj » (avec i compris entre 1 et n) et « Outj » (avec j compris entre 1 et m). Ces fonctions comprennent en paramètre un identifiant d'un signal relié au port correspondant. Elles reçoivent, lorsqu'elles sont appelées, l'adresse de ce signal. Ces déclarations prennent ainsi la forme suivante, visible à l'Annexe 2 ; « void ln_i (sc_signal <type>&) » et
« void Outj (sc_signal <type>&) », pour i compris entre 1 et n, et j compris entre 1 et m, où "void" signifie que la fonction concernée ne retourne aucune information lorsqu'elle est appelée, et où l'expression "sc_signal <type>" entre parenthèses permet, de façon classique dans le langage SystemC, de spécifier que la fonction reçoit, lorsqu'elle est appelée, un signal de type "type".
Le symbole "&", quant à lui, permet là-aussi à la fonction de recevoir l'adresse du signal dont l'identifiant est passé en paramètre lors de l'appel de la fonction, même lorsque cet identifiant est le nom du signal (par exemple "f1" pour le signal f1 ) et non pas l'adresse de ce signal (c'est-à-dire "&f1"). Dit autrement, l'identifiant du signal spécifié en paramètre lors de l'appel de la fonction de connexion de chaque port de chaque module peut alors être le nom de ce signal.
On notera que, avantageusement, la fonction de connexion (Inj ou Outj) de chaque port (d'entrée ou de sortie, respectivement) de chaque module a pour nom le nom dudit port (inj ou outj, respectivement) avec la première lettre en majuscule et les lettres suivantes en minuscules. Les mesures qui précèdent (à savoir la présence du symbole "&" entre parenthèses dans la déclaration des fonctions de connexion d'une part, et l'utilisation du nom du port avec une majuscule en première lettre comme nom de la fonction de connexion, d'autre part) ne sont pas de simples fantaisies de rédaction de la netlist, mais sont des choix préférés en raison des avantages pratiques suivants, qu'ils procurent. D'une part, cela permet de réduire les changements dans la rédaction de la netlist décrivant le système par rapport aux habitudes actuelles des concepteurs de systèmes en langage SystemC. En effet, au lieu de réaliser une connexion entre le port inj (par exemple) et un signal f déterminé en insérant une instruction du type « inj (f) » dans la description du système comme dans l'art antérieur, il réalisera cette connexion par l'appel à la fonction Inj en insérant une instruction du type « Inj (f) », qui est identique à la majuscule près. D'autre part, cela permet aussi d'envisager une modification automatisée de la description textuelle des modules pré- codés actuellement disponibles dans les bibliothèques SystemC, avec de ce fait un risque d'erreurs minimal et des recompilations éventuelles limitées à ce qui est juste nécessaire. Une telle modification automatisée peut en effet être réalisée à l'aide d'un interpréteur syntaxique. On obtiendrai ainsi une mise à niveau des bibliothèques disponibles. La déclaration du module comprend aussi la déclaration 23 d'une variable de type "classe_recup", appelée "Circuit" dans l'exemple. Ainsi qu'il a été dit plus haut, une telle variable est adaptée pour stocker l'adresse de l'objet d'extraction de topologie associé au système. Cette déclaration prend la forme de l'instruction suivante, visible à l'Annexe 2 : « classe_recup *Circuit »
La déclaration de chaque module comprend encore la déclaration 24 de variables de type "structurejiste" respectivement associées à chacun des ports du module. Les variables sont adaptées pour contenir l'adresse d'une structure de stockage associée à ce port. Ainsi, les variables "hdlnj" (avec i compris entre 1 et n) et "hdOutj" (avec j compris entre 1 et m) sont déclarées pour chacun des ports d'entrée et des ports de sortie respectivement. Cette déclaration prend la forme de l'instruction suivante, visible à l'Annexe 2 : « structurejiste *hdlnj » et, « structurejiste *hdOutJ », pour i compris entre 1 et n, et j compris entre 1 et m. Le symbole étoile présent devant le nom des variables "Circuit", "hdjnj" et hd OutJ" indique que ces variables sont des pointeurs sur une cellule, au sens informatique du terme. Cela signifie que la variable correspondante contient l'adresse de l'emplacement dans la mémoire de l'ordinateur où la cellule est mémorisée, et non directement la cellule elle- , même.
Bien entendu, les noms donnés aux variables précitées sont tout à fait arbitraires et ne sauraient être interprétés comme une caractéristique limitative de l'invention.
La déclaration du module comprend encore l'initialisation 25 des variables "hdlnj" (avec i compris entre 1 et n), "hdOutj" (avec j compris entre 1 et m) et "Circuit", à une valeur initiale déterminée respective. Dans un exemple, cette valeur initiale est la valeur nulle pour chacune de ces variables. Cette initialisation est réalisée dans la partie de la déclaration du module appelée déclaration du constructeur du module, c'est-à-dire grâce à la fonction « SC CTOR » précitée. Cette initialisation prend la forme suivante, visible à l'Annexe 2 : « Circuit » = 0,
« hdlnj=0 » et, « hdOutJ=0 », pour i compris entre 1 et n, et j compris entre 1 et m.
La déclaration du module comprend aussi la déclaration d'une fonction d'envoi des informations de topologie vers l'objet d'extraction de topologie.
Cette fonction est appelée « do_sendJnfo» dans l'exemple, le choix de ce nom étant purement arbitraire et donc nullement limitatif. Cette fonction est une fonction privée du module. Elle est déclarée dans la partie de la fonction
« SCJvlODULE » qui suit l'expression « private : ». Cette déclaration prend la forme suivante :
« void do_sendJnfo (void) ». A titre d'exemple plus concret, l'Annexe 3 fournit la déclaration partielle du module M6 du système représenté à la figure 1 , qui apparaît comme étant le plus complexe du point de vue de la topologie, c'est-à-dire du point de vue du nombre de ses ports. On rappelle qu'il s'agit d'un module de type appelé "Dec" dans l'exemple.
L'Annexe 4 et l'Annexe 5 contiennent une portion de la netlist correspondant à la description textuelle du système de la figure 1 , respectivement selon l'art antérieur et selon l'invention. Cette portion de la netlist, qui est écrite en langage SystemC, est incluse dans le fichier d'extension ".cpp". Dans ces annexes, seules les instructions se rapportant à la description de la topologie du système ont été mentionnées. Il est bien entendu que d'autres instructions sont nécessaires à la description du fonctionnement du système, mais n'apparaissent pas ici car elles ne sont pas utiles à la compréhension de l'invention.
En bref, les instructions nécessaires à la description du système comprennent les instructions de déclaration des modules M1 à M11 (on parle en général d'instructions d'instanciation des modules dans le jargon de l'homme du métier, pour désigner ces instructions), les instructions de connexion des ports d'entrée et des ports de sortie des modules, et les instructions d'initialisation des modules par appel de la fonction "dojnit" de chacun des modules. Ainsi qu'il apparaît en comparant les Annexes 4 et 5, seules les instructions de connexion diffèrent entre le cas selon l'art antérieur et le cas selon l'invention. En effet les instructions de connexion des ports d'entrée et des ports de sortie des modules se font, selon l'invention, par appel de la fonction "Inj" ou "Outj" correspondante. L'organigramme de la figure 3 illustre de façon schématique les étapes d'un procédé d'exécution de la netlist de l'Annexe 5, qui consiste à exécuter séquentiellement les instructions qu'elle contient. Ces opérations sont exécutées par le noyau de simulation (processeur piloté par un programme ad- hoc) de SystemC. Dans une étape 31 , on se demande si la netlist contient encore une instruction à exécuter. Si la réponse est non, alors, dans une étape 32, on lance la simulation du système et/ou le traitement de la topologie. Cette étape 32 correspond à l'essence même des applications pour la conception et la simulation de système en SystemC. Sinon, et pour chaque instruction contenue dans la netlist, on se demande dans une étape 33 quel est le type de l'instruction concernée.
S'il s'agit d'une instruction d'instanciation d'un nouveau module, par exemple l'instruction « Dec M6 ("M6") » pour l'instanciation du module M6, alors, dans une étape 34, on construit le module concerné. Ceci consiste à exécuter la fonction "SCjMODULE" pour ce module. En particulier, cette exécution initialise les variables "Circuit", "hdlnj" (pour i compris entre 1 et n) et "hdOutj" (opur j compris entre 1 et n) du module. S'il s'agit d'une instruction de connexion d'un port d'entrée ou de sortie d'un module, par exemple l'instruction « M6.ln_1 (f4)» pour relier l'entrée in_1 du module M6 au signal f4, alors, dans une étape 35, on appelle la fonction Inj ou la fonction Outj correspondante. L'étape 35 sera détaillée ci-dessous en regard de l'organigramme de la figure 4. S'il s'agit d'une instruction d'initialisation d'un module, par exemple l'instruction « Mδ.dojnit (Circuit) » pour l'initialisation du module M6, alors, dans une étape 36, on exécute l'initialisation de ce module. Ceci est effectué par appel de la fonction "dojnit" de ce module. L'étape 36 sera détaillée ci- dessous en regard de l'organigramme de la figure 5. S'il s'agit d'une autre instruction (sans rapport avec la topologie du système, donc non visible dans la netlist de l'Annexe 5), alors, dans une étape 37, on exécute l'instruction concernée.
On notera que l'ordre d'apparition des différentes instructions précitées dans la netlist décrivant le système en langage SystemC peut être quelconque. En particulier, il est possible qu'une instruction de connexion d'un port d'entrée ou de sortie d'un module déterminé soit appelée avant que la fonction d'initialisation de ce module n'ait été appelée. Il s'ensuit que l'adresse de l'objet d'extraction de topologie associé au système auquel appartient ce module peut encore être indéterminée lors de l'appel de l'instruction de connexion. Ainsi qu'il va maintenant être explicité, l'invention permet de s'affranchir des inconvénients d'une telle situation, grâce à la mise en œuvre des structures de stockage des informations de topologie associées à chaque port de chaque module. L'organigramme de la figure 4 illustre le détail de l'étape 35, qui consiste à exécuter une instruction de connexion Inj ou Outj d'un port respectivement d'entrée ou de sortie d'un module déterminé. On rappelle que réaliser une connexion consiste à associer un signal à un port auquel ce signal est relié. Le code de l'implémentation des fonctions Inj et Outj du module M6 est fourni à l'Annexe 6
Dans ce qui suit, on illustre le déroulement des étapes de cette implémentation en considérant par exemple le cas où on a appelé la fonction de connexion ln_1 pour connecter un signal p quelconque à l'entrée in_1 du module M6. Cet appel peut prendre la forme suivante, visible à l'Annexe 5 :
« M6.ln_1 (f1) » pour la connexion du signal f1 à l'entrée in_1 du module M6.
Dans une étape 41 , on se demande si la fonction d'initialisation "dojnit" de ce module a déjà été appelée. Un tel test est par exemple réalisé par une instruction telle que « if (Circuit != 0) » ou, ce qui revient au même, « if (Circuit) ». Dit autrement, on se demande si la variable "Circuit" du module est non nulle (c'est-à-dire si elle a perdu la valeur nulle qui lui a été attribuée lors de son initialisation).
Si la réponse est oui, cela signifie que la fonction "dojnit" du module a déjà été appelée. En effet, l'adresse non nulle de l'objet d'extraction de topologie associé au système auquel appartient le module est alors contenue dans la variable "Circuit". Alors, dans une étape 42, on envoie l'adresse du signal p à l'objet d'extraction de topologie, par exemple au moyen d'une fonction appelée "SetLien" utilisée par exemple de la façon ci-dessous : « Circuit -> SetLien ( this, &p, Portjype, q ) »
La méthode "SetLien" est définie pour les objets de type "classe ecup". Elle permet l'enregistrement d'une connexion par l'objet d'extraction de topologie. Cette connexion est définie par l'adresse du module concerné (donnée par le vocable "this" qui est un vocable prédéfini du langage SystemC), l'adresse du signal connecté (soit "&p" dans l'exemple), le type "Portjype" (par exemple la valeur "ENTREE" ou la valeur "SORTIE" selon qu'il s'agit d'un port d'entrée ou d'un port de sortie, respectivement), et le numéro d'ordre de ce port dans son type, noté q (qui correspond à l'ordre d'apparition du port dans la liste de déclaration des ports du module, les ports d'entrée et les ports de sortie étant distingués et comptés séparément). C'est pourquoi les informations ci-dessus sont passées en paramètres lors de l'appel de la fonction "SetLien". L'implémentation de la méthode "SetLien" varie en fonction de la nature de la structure de stockage de topologie choisie pour la représentation en mémoire de la topologie. Si l'on considère l'exemple d'une liste chaînée (voir plus loin, description de la figure 8), la fonction "SetLien" crée une nouvelle cellule à ajouter à la liste des cellules existantes par exemple selon une approche, connue en soi, d'ajout en tête de liste. La cellule créée est définie grâce aux informations passées en paramètres pour les champs suivants : adresse du module concerné, adresse du signal connecté, type du port concerné, numéro de ce port dans le type.
L'implémentation de la fonction « SetLien » est à la portée de l'homme du métier. Un exemple d'implémentation de cette fonction en langage SystemC est donné à l'Annexe 7. Dans cet exemple, la structure de stockage de topologie choisie pour la représentation en mémoire de la topologie est une liste chaînée. La fonction "SetLien", lorsqu'elle est appelée pour un objet de récupération de topologie déterminé, crée une nouvelle cellule à ajouter aux cellules existantes de la liste. Cette nouvelle cellule est renseignée grâce aux informations passée en paramètres, pour les champs suivants : adresse du module concerné, adresse du signal connecté, type du port concerné, numéro de ce port dans son type. La liste stockant les informations sur les connexions du circuit déjà réalisées est ainsi enrichie d'une nouvelle cellule, par conséquent, d'une nouvelle connexion. Dans l'exemple d'implémentation donnée à l'Annexe 7, on note "ListeStockageTopologie" la liste qui permet à l'objet d'extraction de topologie de stocker en mémoire la liste des connexions déjà réalisées. Cette liste, qui initialisée à l'adresse nulle "NIL", est enrichie à chaque appel de la fonction "SetLien", d'une nouvelle cellule correspondant à une nouvelle connexion.
Si, à l'étape 41, la réponse est non, cela signifie que la fonction "dojnit" du module n'a pas encore été appelée. Alors, dans une étape 43, on enregistre l'adresse du signal concerné dans la structure de stockage associée au port concerné. Ceci est par exemple réalisé en appelant une fonction "AddLien", qui est déclarée de la façon suivante :
« void AddLien (structurejiste **, sc_signal<type> *) » La fonction "AddLien" est une fonction accessible à tous les modules. Dans un exemple, elle est appelée de la façon ci-dessous pour connecter un signal au port d'entrée in_1 du module M6 : « AddLien (&hdln_1,&p) »
Elle permet d'ajouter l'adresse d'un signal (&p dans cet exemple) en tête d'une liste de type "structurejiste" (celle repérée par l'adresse &hdln_1 dans l'exemple), soit la liste chaînée qui contient toutes les adresses des signaux déjà connectés au port d'entrée in_1 du module. Dit autrement, la fonction "AddLien" permet de stocker l'adresse &p du signal dans la liste chaînée qui contient toutes les adresses des signaux déjà connectés au port concerné du module. Cette liste chaînée sera ensuite utilisée, lors de l'appel de la fonction "do sendjnfo" pour l'enregistrement des connexions stockées par le module.
Après l'étape 42 comme après l'étape 43, on effectue alors, dans une étape 44, la connexion proprement dite du signal au port concerné. Ceci est réalisé, selon la manière habituelle en langage SystemC, par l'instruction suivante :
« in_1 ( p ) »
A la figure 5, on a représenté un organigramme qui donne le détail des étapes mise en oeuvre lors de l'étape 36 (figure 3) à laquelle on appelle la fonction d'initialisation "dojnit" d'un module déterminé. Toujours à titre d'exemple, on considérera dans ce qui suit le cas de l'appel de la fonction d'initialisation du module M6, par l'instruction suivante :
« Mβ.dojnit ( Circuit ) »
Cette méthode reçoit en argument l'identifiant de l'objet d'extraction de topologie du système, c'est-à-dire la variable "Circuit" du module. La méthode commence par effectuer un test 51 pour savoir si la fonction "dojnit" a déjà été appelée auparavant, ce qui serait une erreur. A cet effet on teste la valeur de la variable interne "Circuit" qui doit avoir la valeur nulle (c'est-à-dire la valeur qui lui a été attribuée lors de son initialisation par le constructeur du module). Un tel test est réalisé par exemple par l'instruction suivante :
« if ( Circuit != 0) »
Si la fonction "dojnit" a déjà été appelée, alors, dans une étape 52, on gère l'erreur. Par exemple, on génère une interruption.
Si au contraire la fonction "dojnit" n'a pas été appelée auparavant, c'est-à-dire si c'est le premier appel de cette fonction pour le module concerné, alors, dans une étape 53, on stocke l'adresse de l'objet d'extraction de topologie dans la variable interne "Circuit" du module. Ceci se fait par exemple par une instruction telle que
« Circuit = &c »
Ensuite, dans une étape 54, on envoie à l'objet d'extraction de topologie toutes les infirmations sur les connexions déjà réalisées pour ce module, et qui ont été stockées dans les structures de stockage associées à chacun des ports d'entrée et/ou de sortie du module.
A cet effet, on appelle une méthode "do sendjnfo" permet d'envoyer vers l'objet d'extraction de topologie toutes les informations sur les connexions qui ont pu être réalisées auparavant par des appels antérieurs aux fonctions de connexion Inj et/ou Outj pour ce module. Le détail de l'exécution de la fonction "do_sendjnfo" va maintenant être explicité en regard de l'organigramme de la figure 6.
Dans une étape 61 , on vérifie que le module appartient bien à un système et que l'on peut donc envoyer des informations vers l'objet d'extraction de topologie associé à ce système. Ceci est réalisé en testant la valeur de la variable "Circuit", par une instruction déjà présentée plus haut, du type
« if ( Circuit != 0 ) ».
Si la réponse est non, alors, dans une étape 62, on gère l'erreur par exemple en introduisant une interruption.
Si au contraire la réponse est oui, alors, dans une étape 63, on envoie l'adresse du module (donnée par le vocable « this » qui est un vocable prédéfini du langage C++) ainsi que son type fonctionnel ("Dec" pour le module
M6) à l'objet d'extraction de topologie. Ceci est par exemple réalisé grâce à une méthode "MakeModule", par une instruction du type ci-dessous : « Circuit -> MakeModule ( this, "Dec" ) ».
On verra plus loin comment est gérée la mémoire pour enregistrer la liste des modules qui constituent le système.
Il s'agit ensuite d'enregistrer toutes les connexions qui ont été stockées pour chaque port du module. Pour cela, on parcourt la liste de pointeurs correspondant à la structure de stockage associée à chaque port du module, et on envoie vers l'objet d'extraction de topologie les adresses contenues dans cette structure de stockage, c'est-à-dire l'adresse de chacun des signaux connectés au port concerné déjà répertoriés. Plus spécifiquement, dans une étape 64 on se demande si on a parcouru tous les ports du module. Tant qu'il en reste un non encore traité, on se demande dans une étape 65 si la structure de stockage associée à ce port est vide. Si la réponse est oui, c'est qu'aucun signal n'a encore été relié à ce port, et on retourne à l'étape 64. Si au contraire la réponse est non, c'est que au moins un signal a été relié à ce port pour réaliser une connexion. Pour chaque adresse de signal ainsi stockée (étape 66), on envoie dans une étape 67, l'adresse de ce signal à l'objet d'extraction de topologie grâce à la fonction "SetLien" déjà présentée plus haut.
A titre d'exemple, on peut considérer l'implémentation de la fonction "dojsendjnfo" qui est donnée à l'Annexe 6 en se limitant à la partie concernant le port d'entrée in_1 du module M6. Pour le port in_1, on va parcourir la liste repérée par la variable "hdln_1" grâce à la variable temporaire "ptr" qui est un pointeur sur liste de type "structurejiste". Chaque adresse de signal contenue dans cette liste sera enregistrée vers et enregistrée par l'objet d'extraction de topologie dont l'adresse est contenue dans la variable "Circuit" grâce à l'utilisation de la méthode "SetLien" qui a été décrite précédemment. L'on parcourt ainsi toutes les listes correspondant aux ports d'entrée et de sortie du module (pour l'exemple du module M6 de type "Dec", il y a cinq listes : celles repérées par les pointeurs &hdln_1 , &hdln 2, &hdln_3, &hdOut_1 et &hdOut_2)
Une fois que toutes les informations relatives aux connexions réalisées antérieurement à l'appel de la fonction d'initialisation ont été envoyées vers l'objet d'extraction de topologie (c'est-à-dire lorsque le test de l'étape 64 donne .
21
une réponse négative), les listes sont ensuite détruites, dans une étape 68, grâce à une fonction "DeleteListe" dont Pimplérnentation est à la portée de l'homme du métier et qui fait partie d'une bibliothèque accessible par les modules. Ceci est réalisé, par exemple pour la liste de stockage des connexions associés au port d'entrée in_1 du module M6, par une instruction du type suivant :
« DeleteListe ( &hdln_1 ) » Cette fonction "DeleteListe" permet de libérer l'espace mémoire réservé pour l'ensemble des éléments d'une structure de stockage associée à un port. Son implémentation est à la portée de l'homme du métier. t •
Il reste à exposer le traitement mis en œuvre au niveau de l'objet d'extraction de topologie.
L'objet d'extraction de topologie reçoit l'adresse de chaque module qui lui est passée lors de l'appel de la fonction "MakeModule". Il reçoit aussi l'adresse de chaque signal relié à chaque port de chaque module, lors des appels aux fonctions de connexion Inj et Outj respectives pour chacun de ces ports. Il stocke ces différentes adresses dans une structure de stockage de topologie déterminée. Dans un exemple, cette structure de stockage de topologie comprend un tableau et une liste générés dynamiquement par l'objet d'extraction de topologie. Lorsque l'ensemble des informations de topologie se rapportant au système ont été extraites, le tableau comporte autant de cellules renseignées qu'il y a de modules présents dans le système. Il est appelé tableau des modules dans la suite. De plus, la liste contient autant de cellules qu'il y a de connexions port/signal dans le système. Elle est appelée liste des connexions dans la suite.
Le tableau des modules, dans son état final (c'est-à-dire après l'exécution complète de la netlist décrivant le système), est illustré à la figure 7. Chaque cellule du tableau est représentée par une de ses lignes. On distingue ainsi onze cellules C0 à C10, une par module du système de la figure 1. Les cellules sont renseignées dynamiquement, à chaque appel de la fonction "MakeModule". Sur la figure, la première cellule C0, d'indice 0 dans le tableau, a été créée en premier, et la onzième cellule C10, d'indice 10 dans le tableau, a été créée en dernier. Chaque cellule comprend (de gauche à droite) :
- un premier champ FC1 contenant l'adresse du module concerné ;
- un deuxième champ FC2 contenant le type du module concerné ; et,
- un troisième champ FC3 contenant une liste de paramètres ; ces paramètres sont constitués par toutes informations qui pourraient caractériser le module, et qui seraient transmises en paramètre par la fonction "dojnit".
Dans un exemple, la liste de paramètres a une longueur qui dépend du type du module. Ainsi, dans un exemple :
- pour le type "Source", on a k paramètres notés Param_1 à Param_k ; - pour le type "Display", on a d paramètres notés ParanrM à Param d ;
- pour le type "Add", on a p paramètres notés Param_1 à Paramjp ;
- pour le type "Mult", on a q paramètres notés Param_1 à Param ; et,
- pour le type "Dec", on a r paramètres notés ParanrM à Param_r. L'ordre des cellules C0 à C10 est repéré en mémoire par un indice compris entre 0 et 10. Sur la figure 7, cet ordre correspond à l'ordre d'apparition des fonctions d'instanciation des modules M1 à M11 tel qu'il apparaît dans la netlist de l'Annexe 5.
La liste des connexions, dans son état final, est illustrée à la figure 8. Elle comprend ici vingt cellules chaînées, une par connexion du système de la figure 1. Les cellules sont graphiquement représentées par des tableaux à une colonne et cinq lignes. Elles contiennent toutes les données nécessaires à la définition d'une connexion. Les cellules sont créées dynamiquement, à chaque appel de la fonction "SetLien", afin de ne pas réserver inutilement d'espace mémoire. Ainsi que pour des raisons de clarté il est indiqué en regard de la cellule L4 seulement, chaque cellule comprend (de haut en bas) :
- un premier champ FL1 contenant l'adresse du module concerné ;
- un deuxième FL2 champ contenant l'adresse du signal concerné ;
- un troisième champ FL3 contenant le type du port concerné (ENTREE ou SORTIE) ; et,
- un quatrième champ FL4 contenant le numéro d'ordre du port dans le type pour le module concerné, et un cinquième champ contenant l'adresse de la cellule suivante de la liste. L'ordre des cellules L0 à L19 de la liste telle que représentée sur la figure 8, correspond à l'ordre respectif des appels des fonctions Inj et Outj tel qu'il apparaît dans la netlist de l'Annexe 5. L'adresse T de la première cellule L0, appelée tête de liste dans la suite, est contenue dans une cellule mémoire particulière notée HL à la figure. A la figure 8, le cinquième champ de chacune des cellules L0 à L18 contient symboliquement le vocable "next" pour désigner l'adresse de la cellule suivante dans la liste. Le cinquième champ de la dernière cellule L19 contient un pointeur vers une cellule mémoire particulière qui contient la valeur "NIL" pour indiquer qu'il n'y a pas de cellule suivante dans la liste.
Le tableau des modules représenté à la figure 7 et la liste des connexions représentées à la figure 8 contiennent à eux deux l'ensemble des informations nécessaires et suffisantes pour décrire la topologie du système, le tableau comprend une cellule par module, cette cellule contenant des informations caractérisant un module déterminé du système, et la liste contient une cellule par connexion, cette cellule contenant des informations caractérisant une connexion déterminée.
Les informations de topologie peuvent ensuite être lues dans la structure de stockage constitué de ce tableau et de cette liste par tout dispositif matériel et/ou logiciel en vue d'un traitement spécifique. En particulier ces informations peuvent être utilisées par un module de placement/routage pour concevoir l'implantation du système sur silicium, lorsque le système est un système microélectronique. Elles peuvent aussi être fournies en entrée d'un module d'affichage permettant de fournir une représentation graphique du système sur un écran, et/ou d'un module d'impression permettant d'imprimer un document tel qu'un schéma du système.
A partir de la structure de stockage de topologie comprenant le tableau et la liste représentés aux figures 7 et 8, on peut aussi créer une deuxième structure de stockage liste qui comprend un unique tableau contenant les informations sur les connexions entre les modules du système.
Un tel tableau est représenté par le schéma de la figure 9. Dans l'exemple, il comprend dix cellules notées T0 à T9, une par signal du système. Une cellule correspond à une colonne du tableau. Elle comprend quatre champs. Le tableau est donc un tableau à dix colonnes et quatre lignes.
Dans ce qui suit, on désigne par module entrant et module sortant, le module dont respectivement un port d'entrée ou un port de sortie est relié au signal. De plus, on désigne par numéro de port d'entrée et numéro de port de sortie le numéro dans son type, respectivement "ENTREE" ou "SORTIE" du port d'entrée et du port de sortie auquel ce signal est relié. Les quatre champs d'une cellule sont les suivants :
- un premier champ FT1 contenant l'indice du module sortant tel que défini par l'ordre d'apparition de la fonction d'instanciation du module dans la netlist ; cet indice est l'indice est l'indice de la cellule correspondant à ce module dans le tableau des modules de la figure 7 ;
- un deuxième FT2 champ contenant le numéro du port d'entrée ;
- un troisième FT3 champ contenant l'indice du module entrant ; et, - un quatrième FT4 champ contenant le numéro du port d'entrée.
En résumé, la deuxième structure de stockage de topologie représentée à la figure 9 est un tableau comprenant une cellule par signal, chaque cellule contenant des informations caractérisant la liaison entre deux modules via ce signal. Cette structure de stockage de topologie permet de répertorier toutes les connexions du circuit. En liaison avec le tableau des modules, on dispose alors de toutes les information sur la topologie du système (modules, paramètres et connexions).
Elle ne permet cependant pas, par exemple, de connaître rapidement les modules voisins de chaque module, ou de reconstituer le parcours d'une donnée déterminée dans le système. Pour ce faire on a besoin d'une représentation de la topologie qui soit une représentation orientée module.
A cet effet, on peut générer une troisième structure de stockage de topologie à partir de la première structure de stockage de topologie. Par exemple, on peut ajouter aux cellules du tableau des modules représenté à la figure 7, des champs supplémentaires qui renseignent sur les modules voisins immédiats du module, ou, de façon plus spécifique encore, sur la position du module dans la topologie du circuit. Dans l'exemple représenté à la figure 10, on a ajouté à chaque cellule C0 à C11 du tableau des modules un quatrième champ FC4 qui contient un pointeur sur liste. Ce pointeur désigne l'adresse de la tête d'une liste de connexions associée au module, notée VO à V11 respectivement. Cette liste est composée d'autant de cellules que le module présente de connexions, à raison d'une cellule par connexion.
Pour chaque cellule C0 à C11 du tableau des modules, chaque cellule de la liste associée respectivement VO à V11 , contient les six champs suivants (de gauche à droite) : - un premier champ FV1 qui contient le type du port du module concerné qui est connecté ;
- un deuxième champ FV2 qui contient le numéro (dans son type) du port du module concerné qui est connecté ;
- un troisième champ FV3 qui contient l'indice du module voisin auquel le port du module concerné est connecté ;
- un quatrième champ FV4 qui contient le type du port du module voisin auquel le port du module concerné est connecté ;
- un cinquième champ FV5 qui contient le numéro (dans son type) du port du module voisin auquel le port du module concerné est connecté ; et, - un sixième champ FV6 qui contient l'adresse de la cellule suivante dans la liste associée ; pour la dernière cellule de la liste associée, ce sixième champ FV6 contient un pointeur vers une cellule mémoire particulière qui contient la valeur "NIL" pour indiquer qu'il n'y a pas de cellule suivante dans la liste. En résumé la troisième structure de stockage de topologie représentée à la figure 10 comprend un tableau comprenant une cellule par module du système, et dont chaque cellule comprend un champ FC4 contenant un pointeur sur liste, qui désigne une liste (V0 à V10) des liaisons de ce module avec d'autres modules du système. D'autres types de structure de stockage de topologie peuvent être imaginées, de complexités variables, selon l'application à laquelle on destine son utilisation (placement/routage, tracé de signaux, étude de la propagation des signaux, etc.). On va maintenant décrire comment à partir des informations qui sont stockées dynamiquement dans la première structure de stockage de topologie (c'est-à-dire dans le tableau des modules de la figure 7 et dans la liste de la figure 8), on peut, au terme de la description du système, reconstituer la topologie de celui-ci, c'est à dire disposer de la liste des modules du circuit, ainsi que pour chacun d'entre eux, le détail de leurs liaison avec les autres modules (port à port). Nous nous bornerons ici à détailler le processus de reconstitution de la topologie, sachant que celle-ci peut être stockée de multiples façons, notamment dans la deuxième ou dans troisième structure de stockage de topologie décrites plus haut.
Le mécanisme de reconstitution est le suivant. Dans une étape 110, on accède à la cellule de tête de liste, dont l'adresse T est contenue dans la cellule mémoire HL. Cette cellule de tête de liste contient les informations caractérisant une connexion entre un port et un signal. On va alors parcourir le reste de la liste à la recherche des cellules qui caractérisent des connexions sur le même signal. Dans un test 120, on se demande si la liste est vide (c'est-à-dire, en pratique, si l'adresse T est égale à NIL). Si la réponse est oui, alors le processus est terminé.
Si la réponse est non, alors, dans une étape 130, on stocke l'adresse du module concerné ainsi que le type du port et son numéro dans le type. Puis, dans une étape 140, on lit dans le champ FL2 de la cellule de tête de liste, l'adresse du signal concerné par la connexion. Dans une étape 150, on se demande ensuite si la cellule suivante dans la liste est la cellule NIL. Si la réponse est oui, cela signifie que le port du module concerné par la connexion n'est relié à aucun autre module, ce qui constitue une erreur. On traite alors cette erreur dans une étape 151 , par exemple en générant une interruption 152.
Si la réponse est non, alors, dans une étape 160, on accède à la cellule suivante dans la liste. Ensuite, dans une étape 170, on lit l'adresse dans le champ FL2 de cette cellule suivante dans la liste, l'adresse du signal concerné par la connexion correspondante. Si les adresses des signaux concernés par les connexions de la cellule de tête de liste et de la cellule suivante, qui ont été lues aux étapes 140 et 170 respectivement, sont égales, alors, dans une étape 180, on stocke l'adresse du module concerné ainsi que le type du port et son numéro dans le type.
Dans une étape 190, on se demande ensuite si la cellule suivante dans la liste est la cellule nulle. Si la réponse est non, alors on saute à l'étape 160 où l'on accède à cette cellule suivante non nulle.
Si au contraire la réponse est oui, alors, dans une étape 200, on stocke sous la forme désirée les informations relatives aux liaisons entre les différents modules reliés entre eux par le signal concerné par les connexions identifiées. Par exemple, on peut stocker ces informations dans la deuxième ou la troisième structure de stockage de topologie présentées plus haut en regard des figures 9 et 10 respectivement.
Enfin, dans une étape 210, on supprime les cellules de la liste qui ont été traitées, et on saute à l'étape 110 pour accéder à la nouvelle cellule de tête de liste et répéter le processus.
ANNEXE 1
// déclaration du module_x
SCJVIODULE ( module_x ) {
//déclaration des ports d'entrée scjn < type > in ; scjn < type > inJ2; scjn < type > in_n;
//déclaration des ports de sorties sc_out < type > out J ; sc_out < type > out ; sc_out < type > out_m; private :
//ici la déclarations des variables privées du module
//ici la déclaration des méthodes et fonctions privées du module
//exemple : void dojnit (types des paramètres)
public :
//ici la déclaration des variables publiques du module //ici la déclarations des fonctions publiques du module //exemple : dojnit (paramètres par défaut)
//. constructeur
SC_CTOR ( module_x ) {
//ici l'initialisation des variables du module
//ici la déclaration des sensitivrt' és des méthodes du module
)
};
// fm de déclaration du module x ANNEXE 2 // déclaration du module_x
SC_MODULE ( module c ) {
//déclaration des ports d'entrée scjn < type > in ; scjn < type > in .; scjn < type > in_n;
//déclaration des ports de sorties sc_out < type > out ; sc_out < type > out ; sc_out < type > out_m;
//déclaration liste de stockage des connexions des ports du module: structurejiste *hdln _1 ; structurejiste *hdln _2; structurejiste *hdln_n; structurejiste *hdOut ; structurejiste *hdOutJ2; structurejiste *hdOut_m;
//déclaration de l'objet d'extraction de topologie : classe ecup *Circuit ; private :
//déclaration fonction d'envoi des infos de topologie : void do_sendJnfo ( void );
//ici la déclaration des variables privées du module
//ici la déclaration des méthodes et fonctions privées du module
public :
//déclaration de la fonction d'initialisation du module : void dojnit ( classe_recup&, types des autres paramètres );
//déclaration fonctions de connexion des ports du module : void In ( sc_signal < type >& ); void ln_2 ( sc_signal < type >& ); void ln_π ( sc_signal < type >& ); void Out ( sc_signal < type >& ); void Out_2 ( sc_signal < type >& ); void Out_m ( sc_signal < type >& ); //ici la déclaration des variables publiques du module //ici la déclaration des fonctions publiques du module
// constructeur
SC_CTOR ( module_x ) {
//initialisation des variables internes de stockage de topologie : hdln _1 = 0; hdln_2 = 0; hdln i = 0; hdOutj = 0; hdOut_2 = 0; hdOut_m = 0;
//initialisation de la variable interne de stockage de l'objet //d'extraction de topologie : Circuit = 0;
//ici l'initialisations des autres variables du module
//ici la déclaration des sensitivités des méthodes du module
}
};
//_ fjn de déclaration du module x
ANNEXE 3
SCJVIODULE ( Dec ) {
//déclaration des ports d'entrée du module: scjn < type > inj //Entrée in_1 du module scjn < type > inJ2 //Entrée in_2 du module scjn < type > in_3 //Entrée in 3 du module
//déclaration des ports de sortie du module: sc_out < type > outj ; //Sortie out_1 du module sc_out < type > out 2; //Sortie out_2 du module
//déclaration des variables de stockage de topologie : structurejiste *hdln J ; structurejiste *hdlnJ2; structurejiste *hdln_3; structurejiste *hdOut J ; structurejiste *hdOutJ2;
//déclaration de l'objet d'extraction de topologie : classe ecup "Circuit ; private :
//déclaration de la fonction d'envoi des informations de topologie : void do_sendJnfo ( void );
//ici la déclarations des variables privées du module
//ici la déclaration des méthodes et fonctions privées du module public :
//déclaration de la fonction d'initialisation du module : void dojnit (classe ecup&, types des autres paramètres );
//déclaration de la fonction de connexion surin_1 : void Inj (sc_signal <double> &);
//déclaration de la fonction de connexion sur in_2 void ln_2 (sc_signal <double> &);
//déclaration de la fonction de connexion sur in_3 void ln_3 (sc_signal <double> &);
//déclaration de la fonction de connexion surout_1 : void Out (sc_signal <double> &);
//déclaration de la fonction de connexion sur out_2 : void Out_2(sc_signal <double> &);
//ici la déclaration des variables publiques du module //ici la déclaration des fonctions publiques du module
// constructeur •
SC .CTOR ( Dec ) { //initialisation des variables internes de stockage de topologie . hdln = 0; hdln_2 = 0; hdln_3 = 0; hdOutj = 0; hdOut_2 = 0;
//initialisation de la variable interne de stockage de l'objet //d'extraction de topologie : Circuit = 0;
//ici l'initialisation des autres variables du module
//ici la déclaration des sensitivités des méthodes du module
};
ANNEXE 4
//déclaration des signaux : sc_signal <type> f 1 , f2, f3, f4, f5, f6, f7, fδ, f9, f10
//déclaration de l'objet d'extraction de topologie : classe ecup Circuit (paramètres);
//déclaration des modules Source M1 ("M1") ; Source M2 ("N^-) ; Source M7 ("M7") ; Source M8 ("M8") ; Source M9 ("M9") ; Display M5 (nM5n) ; Display MIO CMIO") ; Display M11 ("MU") ; Add M3 ("M3") ; Mult M4 CM4M) ; Dec M6 ("M6") ;
//initialisation des modules : M1.doJnit(paramètres) M2.doJnit(paramëtres) M7.do nit( ara/T7éfres) ; M8.dojnit(paramêfres) M9.dojnit( ara/T7éfres) M5.dojnit(para/77èfres) M10.dojnit(paramë/rβs) ; M11.doJnit(paraméfres) ; M3.doJnit(paramëtres) ; M4.doJnit(paramëfres) ; M6.doJnit(paramèfres) ;
//connexion des modules aux signaux .
M1.out (f1) ;
M2.out (f2)
M7.out (f6)
Mβ.out (f7)
M9.out (f8)
Mδ.in (f5) ;
M10.in (f9) ;
M11.in (f10) ;
M3.inJ (f1) ; M3.in_2 (f2) ; M3.out (f3) ; M3.out (f4) ;
M4.in (f3) ; M4.out (f5) ;
M6.inJ (f4) ; M6.inJ (f6) ; M6.in_2 (f7) ; M6.inJ3 (f8) ; Mδ.outJ (f9) ; M6.out_2 (f10) ; ANNEXE 5
//déclaration des signaux : sc_signal <type> f1 , f2, f3, f4, f5. f6, f7, f8, f9, f 10
//déclaration de l'objet d'extraction de topologie : classe ecup Circuit (paramètres);
//déclaration des modules Source M1 ("M1") ; Source M2 ("M2") ; Source M7 ("M7") ; Source M8 ("M8") ; Source M9 ("M9") ; Display M5 ("M5") ; Display M 10 ("M 10") ; Display M11 ("M 11") ; Add M3 ("M3") Mult M4 ("M4") Dec M6 ("M6")
//initialisation des modules : M1.doJnit(Circuit,autres paramètres) M2.doJnit(Circuit,aufres paramètres) M7.doJnit(Circuit,au/res paramètres) M8.dojnit(Circuit,aufres paramètres) M9.dojnit(Circuit,aufrθs paramètres) M5.dojnit(Circuit,aufres paramètres) M10.doJnit(Circuit,at tres paramètres) ; M11.dojnit(Circuit,aιτfres paramètres) ; M3.dojnit(Circuit,aufres paramètres) ; M4.dojnit(Circuit,aufres paramètres) ; M6.do nit(Circuit,aιrfres paramètres) ;
//connexion des modules aux signaux :
M1.0ut (f1) ;
M2.0ut (f2) ;
M7.0ut (f6) ;
Mβ.Out (f7) ;
M9.0ut (f8) ;
Mδ.ln (f5) ;
M10.ln (f9) ;
M11.ln (f10) ;
M3.lnJ (f1) ; M3.ln_2 (f2) ; M3.0ut (f3) ; M3.0ut (f4) ;
M4.ln (f3) ; M4.0ut (f5) ;
Mδ.lnJ (f4) ; M6.lnJ (f6) ; M6.ln_2 (f7) ; M6.ln_3 (f8) ;
Mβ.Out (f9) ; M6.OutJ2 (f10) ; ANNEXE 6 // fonction In 1 void Dec :: In ( sc_signal < type > &p ) {
//si le module appartient à un système if ( Circuit )
//alors on envoie l'info de connexion à l'objet Circuit Circuit -> SetLien ( this, &p, ENTREE, 0 ); else
//sinon on stocke l'adresse du signal connecté AddLien (&hdlnj ,&p); inj ( p ); //réalisation de la connexion du signal p au port in_1
}
// fin fonction In 1
// fonction In 2 - void Dec :: lnJ2 ( sc_signal < type > &p ) {
//si le module appartient à un système if ( Circuit )
//alors on envoie l'info de connexion à l'objet Circuit Circuit -> SetLien ( this, &p, ENTREE, 1 ); else
//sinon on stocke l'adresse du signal connecté AddLien (&hdln_2,&p); in_2 ( p ); //réalisation de la connexion du signal p au port in_2
}
// fjn fonction In 2
// fonction In 3 • void Dec :: ln_3 ( sc_signal < fype > &p ) {
//si le module appartient à un système if ( Circuit )
//alors on envoie l'info de connexion à l'objet Circuit Circuit -> SetLien ( this, &p, ENTREE, 2 ); else
//sinon on stocke l'adresse du signal connecté AddLien (&hdln_3,&p); in _3 ( p ); //réalisation de la connexion du signal p au port in_3
}
// — fin fonction In 3 // fonction Out 1 void Dec :: Out ( sc_signal < fype > &p ) {
//si le module appartient à un système if ( Circuit )
//alors on envoie l'info de connexion à l'objet Circuit Circuit -> SetLien ( this, &p, SORTIE, 0 ); else
//sinon on stocke l'adresse du signal connecté AddLien (&hdOut J ,&p); outj ( p ); //réalisation de la connexion du signal p au port out_1
}
//. fin fonction Out 1
// fonction Out_2 • void Dec :: Out 2 ( sc_signal < type > &p ) {
//si le module appartient à un système if ( Circuit )
//alors on envoie l'info de connexion à l'objet Circuit Circuit -> SetLien ( this, &p, SORTIE, 1 ); else
//sinon on stocke l'adresse du signal connecté AddLien (&hdOut_2,&p);
//réalisation de la connexion du signal p au port out_2 out_2 ( p );
}
//. fin fonction Out 2
// fonction do sendjnfo void Dec :: do_sendJnfo ( void ) { if( Circuit != 0 ) { //si le module appartient à un système
//envoi de l'adresse du module Circuit -> MakeModule ( this, "Dec" );
//envoi des infos de connexion stockées pour ce module
//pour le port d'entrée in_1 : if( hdln ) { structurejiste *ptr; for( ptr = hdln J ; ptr != 0; ptr = ptr -> next ) Circuit -> SetLien ( this, ptr -> adresse, ENTREE, 0 );
};
//pour le port d'entrée in_2 : if( hdln_2 ) { structurejiste *ptr; for( ptr = hdln_2; ptr != 0; ptr = ptr -> next ) Circuit -> SetLien ( this, ptr -> adresse, ENTREE, 1 );
};
//pour le port d'entrée in_3 : if( hdln _3 ) { structurejiste *ptr; for( ptr = hdln_3; ptr != 0; ptr = ptr -> next ) Circuit -> SetLien ( this, ptr -> adresse, ENTREE, 2 );
};
//pour le port de sortie out_1 : if( hdOutj ) { structurejiste *ptr; for( ptr = hdOutj ; ptr != 0; ptr = ptr -> next ) Circuit -> SetLien ( this, ptr -> adresse, SORTIE, 0);
};
//pour le port de sortie out_2 : if( hdOut_2 ) { structurejiste *ptr; for( ptr = hdOut_2; ptr != 0; ptr = ptr -> next ) Circuit -> SetLien ( this, ptr -> adresse, SORTIE, 1 );
};
else {
//gestion erreur
};
//libération des variables de stockage des informations de topologie . DeleteListe ( &hdlnj); DeleteListe ( &hdln_2); DeleteListe ( &hdln_3); DeleteListe ( &hdOutJ); DeleteListe ( &hdOut_2);
} //- fin fonction do send info
// fonction do init - void Dec :: dojnit (classe_recup &c ) {
//on teste si la fonction dojnit a déjà été appelée if( Circuit != 0)
//ici gestion de l'erreur : dojnit appelée plusieurs fois
else //mise en mémoire de l'adresse de l'objet circuit Circuit = &c;
//envoi de infos de topologie vers l'objet circuit do_sendJnfo( );
}
//. fin fonction do init •
ANNEXE 7 clasεe_recup : : SetLien ( void* adresse_module, sc_signal<type>* adresse_signal, Port_type type_du_port, int port_num ) {
//défini tion d ' un pointeur sur une nouvelle cellule : stock_cellule *nouvelle_cellule ;
//réservation de l ' espace mémoire pour la nouvelle cellule: nouvelle_cellule = new {stock_cellule) ;
//renseignement de la nouvelle cellule: nouvelle_cellule -> AddModule = adresse_module; nouvelle_cellule -> AddSignal = adresse_signal; nouvelle_cellule -> PortType = type_du_port; nouvelle_cellule -> PortNum = port_num; nouvelle_cellule - > next = HeadList ;
//ajout en tête de la liste LiεteStockageTopologie, qui est une
//variable de l 'objet classe_recup, de la nouvelle cellule
//consti tuée et renseignée:
AddCellule (ListeStockageTopologie, nouvelle_celIule) ;
//ou plus simplement "addCellule" .
)

Claims

REVENDICATIONS
1. Procédé de production de données représentant la topologie d'un système qui comprend un ou plusieurs modules (M1-M11) ayant chacun un nombre déterminé de ports d'entrées et un nombre déterminé de ports de sortie et reliés entre eux par des signaux déterminés (f1-f10), à partir de la description textuelle du système dans un langage orienté objet, suivant lequel : a) on introduit dans la déclaration de chaque module du système :
- la déclaration (21 ) d'une fonction d'initialisation du module comprenant en paramètre un identifiant d'un objet d'extraction de topologie et recevant, lorsqu'elle est appelée, l'adresse dudit objet d'extraction de topologie ;
- la déclaration (22) de fonctions de connexion respectives (InJ.OutJ) pour chacun des ports d'entrée (inj) et des ports de sortie (outj) du module comprenant en paramètre un identifiant d'un signal relié audit port, et recevant, lorsqu'elle est appelée, l'adresse dudit signal ; - la déclaration (23) d'une première variable interne adaptée pour stocker l'adresse de l'objet d'extraction de topologie ;
- la déclaration (24) d'autres variables internes respectivement associées à chacun des ports d'entrée et des ports de sortie du module, et adaptées pour contenir l'adresse d'une structure de stockage associée ; - l'initialisation (25) desdites première et autres variables internes à une valeur initiale déterminée respective ; b) on introduit, dans la description textuelle du système et dans un ordre quelconque :
- l'appel de la fonction d'initialisation (36) de chaque module, avec un identifiant de l'objet d'extraction de topologie en paramètre ;
- l'appel de la fonction de connexion (35) de chaque port de chaque module, autant de fois qu'il y a de signaux respectifs reliés à ce port, avec à chaque fois un identifiant du signal concerné en paramètre ; c) la fonction de connexion de chaque port de chaque module, d'une part, réalise (44) la connexion à ce port du signal dont l'identifiant est spécifié en paramètre, et d'autre part envoie (42) l'adresse de ce signal à l'objet d'extraction de topologie si la fonction d'initialisation du module a déjà été appelée ou enregistre (43) cette adresse dans la structure de stockage associée audit port si la fonction d'initialisation du module n'a pas encore été appelée ; d) la fonction d'initialisation de chaque module enregistre (53) l'adresse de l'objet d'extraction de topologie dont l'identifiant est spécifié en paramètre dans ladite première variable interne du module, envoie (54) l'adresse et le type fonctionnel du module à l'objet d'extraction de topologie, et, le cas échéant, envoie (67) pour chaque port du module les adresses respectives de chaque signal relié à ce port qui ont été préalablement stockées dans la structure de stockage associée audit port ; e) l'objet d'extraction de topologie reçoit l'adresse de chaque module, et l'adresse de chaque signal relié à chaque port de chaque module, et les stocke dans une structure de stockage de topologie déterminée.
2. Procédé selon la revendication 1 , suivant lequel la fonction de connexion de chaque port de chaque module a pour nom le nom dudit port avec la première lettre en majuscule et les lettres suivantes en minuscules.
3. Procédé selon la revendication 1 ou la revendication 2, suivant lequel l'identifiant du signal spécifié en paramètre lors de l'appel de la fonction de connexion de chaque port de chaque module est le nom dudit signal.
4. Procédé selon l'une quelconque des revendications précédentes, suivant lequel l'identifiant de l'objet d'extraction de topologie spécifié en paramètre de l'appel de la fonction d'initialisation de chaque module est le nom dudit objet.
5. Procédé selon l'une quelconque des revendications précédentes, suivant lequel la structure de stockage associée à chacun des ports de chaque module est une liste.
6. Procédé selon l'une quelconque des revendications précédentes, suivant lequel la structure de stockage de topologie comprend un, tableau (Figure 7) et une liste (Figure 8), le tableau comprenant une cellule par module chacune contenant des informations caractérisant un module déterminé du système, et la liste contenant une cellule par connexion chacune contenant des informations caractérisant une connexion déterminée.
7. Procédé selon l'une quelconque des revendications 1 à 5, suivant lequel la structure de stockage de topologie est un tableau (Figure 9) comprenant une cellule par signal, chaque cellule (T0-T9) contenant des informations caractérisant la liaison entre deux modules via ce signal.
8. Procédé selon l'une quelconque des revendications 1 à 5, suivant lequel la structure de stockage de topologie (Figure 10) comprend un tableau comprenant une cellule par module du système, et dont chaque cellule comprend un champ (FC4) contenant un pointeur sur liste, qui désigne une liste (V0-V10) des liaisons de ce module avec d'autres modules du système.
PCT/FR2003/000550 2002-03-01 2003-02-19 Procede d'extraction de la topologie d'un systeme a partir de sa description textuelle WO2003075188A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003248860A AU2003248860A1 (en) 2002-03-01 2003-02-19 Method for extracting the topology of a system based on its textual description

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR02/02641 2002-03-01
FR0202641A FR2836734B1 (fr) 2002-03-01 2002-03-01 Procede d'extraction de la topologie d'un systeme a partir de sa description textuelle

Publications (1)

Publication Number Publication Date
WO2003075188A1 true WO2003075188A1 (fr) 2003-09-12

Family

ID=27741375

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/000550 WO2003075188A1 (fr) 2002-03-01 2003-02-19 Procede d'extraction de la topologie d'un systeme a partir de sa description textuelle

Country Status (3)

Country Link
AU (1) AU2003248860A1 (fr)
FR (1) FR2836734B1 (fr)
WO (1) WO2003075188A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000065492A1 (fr) * 1999-04-27 2000-11-02 Magma Design Automation, Inc. Procede de stockage de plusieurs niveaux de donnees de conception dans une base de donnees commune
WO2001090961A2 (fr) * 2000-05-24 2001-11-29 Koninklijke Philips Electronics Nv Ameliorations apportees a un environnement de modelisation et de simulation de conceptions d'un circuit electronique oriente objet

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000065492A1 (fr) * 1999-04-27 2000-11-02 Magma Design Automation, Inc. Procede de stockage de plusieurs niveaux de donnees de conception dans une base de donnees commune
WO2001090961A2 (fr) * 2000-05-24 2001-11-29 Koninklijke Philips Electronics Nv Ameliorations apportees a un environnement de modelisation et de simulation de conceptions d'un circuit electronique oriente objet

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JUNG Y ET AL: "simCore: an event-driven simulation framework for performance evaluation of computer systems", MODELING, ANALYSIS AND SIMULATION OF COMPUTER AND TELECOMMUNICATION SYSTEMS, 2000. PROCEEDINGS. 8TH INTERNATIONAL SYMPOSIUM ON SAN FRANCISCO, CA, USA 29 AUG.-1 SEPT. 2000, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 29 August 2000 (2000-08-29), pages 274 - 280, XP010515424, ISBN: 0-7695-0728-X *
LIAO S Y: "TOWARDS A NEW STANDARD FOR SYSTEM-LEVEL DESIGN", PROCEEDINGS OF THE 8TH. INTERNATIONAL WORKSHOP ON HARDWARE/SOFTWARE CODESIGN. CODES 2000. SAN DIEGO, CA, MAY 3 - 5, 2000, PROCEEDINGS OF THE INTERNATIONAL WORKSHOP ON HARDWARE/SOFTWARE CODESIGN, NEW YORK, NY: ACM, US, 3 May 2000 (2000-05-03), pages 2 - 6, XP000966190, ISBN: 1-58113-214-X *

Also Published As

Publication number Publication date
FR2836734B1 (fr) 2004-07-02
AU2003248860A1 (en) 2003-09-16
FR2836734A1 (fr) 2003-09-05

Similar Documents

Publication Publication Date Title
EP1376417B1 (fr) Procédé et système d&#39;émulation d&#39;un circuit sous test associé à un environnement de test
EP1805611B1 (fr) Procede d&#39;ordonnancement de traitement de tâches et dispositif pour mettre en oeuvre le procede
EP1290554B1 (fr) Systeme informatique modulaire et procede associe
EP1387305B1 (fr) Procédé et systeme d&#39;établissement automatique d&#39;un modèle global de simulation d&#39;une architecture
FR2668271A1 (fr) Interface de modelisation dynamique des performances des systemes informatiques.
FR2820919A1 (fr) Procede et dispositif pour suivre une connectivite de reseau au moyen d&#39;une hierarchie de conception
FR2535087A1 (fr) Appareil de simulation logique
FR2824160A1 (fr) Conteneur generique configurable de facon dynamique
FR2713368A1 (fr) Procédure et procédé de communication entre machines et procédé généralisé de préparation de programmes afférents.
EP2342636A1 (fr) Procédé de réalisation d&#39;un appel d&#39;une instance d&#39;une fonction, dispositif, et programme d&#39;ordinateur correspondant
FR2965948A1 (fr) Systeme d&#39;ordonnancement de l&#39;execution de taches cadence par un temps logique vectoriel
EP2956874B1 (fr) Dispositif et procédé pour accélérer la phase de mise à jour d&#39;un noyau de simulation
WO2003075188A1 (fr) Procede d&#39;extraction de la topologie d&#39;un systeme a partir de sa description textuelle
EP0780775B1 (fr) Architecture d&#39;un système de tableaux de processeurs à structures parallèles multiples
FR2806498A1 (fr) Systeme informatique de calcul et procede de calcul mis en oeuvre au moyen d&#39;un tel systeme
FR3107608A1 (fr) Dispositif electronique et procede de generation d&#39;au moins un code informatique, programme d&#39;ordinateur associe
FR3084179A1 (fr) Acces direct en memoire
EP3598315B1 (fr) Accès direct en mémoire
EP4394642A1 (fr) Système informatique de validation formelle d&#39;un système physique en ingénierie des systèmes, procédé et programme d&#39;ordinateur correspondants
EP2369486A1 (fr) Système de test d&#39;une architecture de calcul multitâches à partir de données de communication entre processeurs et procédé de test correspondant
FR3087916A1 (fr) Procede de traitement d&#39;un code source, dispositif, systeme et programme correspondant
FR2917522A1 (fr) Procede de reduction parametree de modeles d&#39;automates communicants
FR3131022A1 (fr) Procede de determination d une grandeur physique et systeme de determination associe.
WO2020193351A1 (fr) Traitement informatisé d&#39;un enchaînement d&#39;agents de calcul mis en œuvre par un ensemble de technologies distinctes
FR2861481A1 (fr) Atelier et procede de conception d&#39;un reseau prediffuse programmable et support d&#39;enregistrement pour leur mise en oeuvre

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP