EP2097844A2 - Procede et dispositif d'aide a la conception de circuits integres - Google Patents

Procede et dispositif d'aide a la conception de circuits integres

Info

Publication number
EP2097844A2
EP2097844A2 EP07870389A EP07870389A EP2097844A2 EP 2097844 A2 EP2097844 A2 EP 2097844A2 EP 07870389 A EP07870389 A EP 07870389A EP 07870389 A EP07870389 A EP 07870389A EP 2097844 A2 EP2097844 A2 EP 2097844A2
Authority
EP
European Patent Office
Prior art keywords
objects
information
category
abstraction layer
fields
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP07870389A
Other languages
German (de)
English (en)
Inventor
Stéphane BONNIOL
Michel Tabusse
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Satin IP Technologies
Original Assignee
Satin IP Technologies
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 Satin IP Technologies filed Critical Satin IP Technologies
Publication of EP2097844A2 publication Critical patent/EP2097844A2/fr
Withdrawn legal-status Critical Current

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 and a device for assisting the design of integrated circuits, independently of a design flow. It applies, particularly to the electronics industry.
  • IP block The design and integration flow of an IP block is inherently highly heterogeneous and unstable. It consists of a large number of tools and methods for each phase of implementation and verification, and is complemented by specific and proprietary practices built on the experience of the different actors.
  • the implementation of these tools and methods generates a set of data useful for measuring and controlling quality. But the nature of these data, their format, their location are directly related to the tool and the method used. Their interpretation to deduce a quality parameter therefore requires specific knowledge of the tool and the method.
  • the quality parameters used to measure and control the design and integration of an IP block are universal (in the context of integrated circuit design) and are independent of the tools and methods used.
  • an IP block designed as part of a stream A must be able to be used as part of a stream B.
  • the intrinsic quality of an IP block must not depend on the means implemented to design it. It is these means that will give indications on its quality.
  • the quality parameters there are de facto standards, promoted by some organizations such as VSIA, but it is important to leave the door open for the definition of other parameters if necessary.
  • the present invention is directed to a method of assisting the design of integrated circuits independently of a design flow, characterized in that it comprises: a step of setting up an information abstraction layer implementing a set of classes for creating objects by defining their structure, the abstraction layer being independent of said design flow of all or part of the circuits integrated, a data capture step specific and representative of said design flow, for assigning values to fields of at least a portion of said objects, and a step of interpreting the values of said objects by measurement applications and / or quality control of the design.
  • the present invention thus provides an object structure and a method for collecting, in a homogeneous and stable form, all the information necessary for measuring and controlling the quality of all or part of an integrated circuit during the phases of design and integration.
  • This method thus allows the establishment of a single quality dashboard for all phases of the life cycle of all or part of an integrated circuit, in a highly heterogeneous and unstable environment. Note that since the abstraction layer is independent of the integrated circuit design flow, it provides a stable and consistent basis for measurement and quality control.
  • the latter has a dynamic structure for storing information necessary for the measurement and quality control of reusable integrated circuit blocks.
  • the implementation of the present invention thus provides at least one dashboard for measuring and controlling the design quality and integration of integrated circuit blocks.
  • reusable also called “IP” (acronym for "Intellectual Property” for intellectual property).
  • the method as briefly described above includes a step of storing field names and their values in dynamic lists, categories of objects implemented in the abstraction layer.
  • these categories are themselves dynamically created objects, and have dynamic lists for their characteristics.
  • the structures making it possible to store the quality information can thus be defined according to the needs.
  • they can be programmed, created, modified via the user interface, without having to modify the source code of the application.
  • the latter is based on two classes of objects with dynamic lists of fields, the first class making it possible to create "category” objects defining the formats and characteristics of the "information" objects, instances of the second class.
  • the abstraction layer can be dynamically reconfigured as needed.
  • the method as succinctly preceding comprises a step of dynamically modifying menus of a graphical interface with the user for entering and viewing the "information" objects. These menus are dynamically modified according to the new structure of objects and adapt to it.
  • the existing objects are updated dynamically according to the new structure: the obsolete fields are deleted and the new fields are eventually filled in the next modification of the objects.
  • the method according to the invention comprises a step of referencing "information" objects with each other by link type fields, the "information" objects having at least one field whose value is obtained at during a step of data capture.
  • this method includes a step of storing "category" objects and "information" objects in at least one relational database.
  • each said database comprises, at least, a "CATEGORY” table for storing the “category” objects and a “CUSTOM” table for storing the "information" objects.
  • this method comprises a step of creating a database for each project and / or for each integrated circuit block.
  • the categories of "information" objects can thus be customized project by project and the "information” objects are thus stored project by project.
  • the method comprises a step of specifying at least one "sensor" object implemented during the data capture step, to create a bridge between the abstraction layer and the design flow. integrated circuit.
  • the capture step is automatic, in particular by assigning the values to said object fields by a link with at least one "sensor" object.
  • measurement and quality control of an IP block are performed without disrupting the design process, by automating the capture of necessary information, while preserving the integrity of the captured data.
  • the automatic aspect of data capture provides an objective measure at any time of the evolution of the design flow without interfering with it.
  • the present invention is therefore intended to be a non-intrusive solution with respect to said stream.
  • this method comprises a step of constructing a library of measurement and / or quality control applications. It is observed that the implementation of the present invention allows this library to be stable and standardized within an organization.
  • the step of class interpretation by measurement and / or design quality control applications is performed in random access memory in lists.
  • this step does not implement SQL queries on each database.
  • SQL queries more resource-intensive, is therefore limited to the creation of lists for processing in the business layer.
  • Applications based on the abstraction layer can thus handle a large number of objects (several tens of thousands) and the speed of execution is optimized.
  • the present invention relates to a device for implementing said method, characterized in that it comprises:
  • FIG. 1 schematically represents classes implemented by particular embodiments of the method that is the subject of the present invention
  • FIG. 2 schematically represents databases implemented by particular embodiments of the object process; of the present invention
  • FIG. 3 represents interactions between a stream and software components implemented by particular embodiments of the method that is the subject of the present invention
  • FIG. 4 represents, in the form of a logic diagram of the steps implemented. works in modes of Particular embodiments of the method which is the subject of the present invention
  • FIG. 5 schematically represent a particular embodiment of the device which is the subject of the present invention.
  • FIG. 1 illustrates a class diagram in which are:
  • class 105 "Field”
  • class 110 "Element”
  • class 115 "ElementList”
  • class 120 “Category”
  • - class 125 “Custom”.
  • Class 110 "Element” has the following fields: - "name”, “Summary”,
  • Class 115 "ElementList” has the following object:
  • Class 120 "Category” has the following fields:
  • class 125 "Custom” has the following fields: - "categoryName”,
  • Objects belong to a category (or type) of objects whose structure is described below.
  • a number of object categories are predefined but their structure can be modified (list of attributes or fields) and new categories can be created, preserving the integrity of already created objects.
  • class 120 "Category” which defines the categories by a list of fields with their characteristics
  • class 125 "Custom” which allows to create objects "information” and store the values of the fields according to their category.
  • the categories are, themselves, instance instances of the class 120 "Category” and the quality information is stored in instance instances of the class 125 "Custom”.
  • Classes 120 "Category” and 125 “Custom” inherit from the parent class 110 "Element”. All "category” objects and all “information” objects therefore have the fields of this class: "name”, “summary”, “description”, “author”, “creationDate” and "modificationDate”.
  • FIG. 2 The persistence of "category" objects and "information” objects is ensured by a layer of relational databases, represented in FIG. 2.
  • FIG. 2 two databases 215 and 220 are represented.
  • Each database, 215 and 220 consists of two tables: table 205 "CATEGORY” and table 210 "CUSTOM”.
  • table 205 "CATEGORY”
  • table 210 "CUSTOM”.
  • the structure of the records in the tables is described below.
  • a database is created by project and IP block.
  • the categories of "information” objects can thus be customized project by project and the "information" objects are stored project by project.
  • persistence of objects can also be provided by other means, for example XML files (acronym for "eXtended Markup Language” for extended markup language).
  • Class 120 "CATEGORY” is used to instantiate an object defining a category of information. This "category” object of information is then referenced when creating an "information" object by the "categoryName” field of the "CUSTOM” class.
  • the definition of a category consists in specifying the list of the fields which will be filled during the creation of the object "information” belonging to this category, with their characteristics, for example graphic, title, possible values, mapping, colors and order .
  • the class “CATEGORY” contains a set of fields of type "list” to specify each field in the category. At a position in a list corresponds a characteristic of a field.
  • the list type fields are as follows:
  • fieldName Name of the field; must be unique for a given category
  • FieldTitle Title of the field; text appearing in the GUI for entering or reading the field, - "fieldType”: Type of the field; which makes it possible to define both the function of the field and the graphic mode used for its input; examples of types include Title, Text, TextArea, Password, Path, FileUpload, Date, Select, Radio,
  • LinkSingle and “LinkMultiple”. Other types can be added, the interpretation of types being programmed in a graphical interface and corresponding applications, - "fieldSize”: Field size in memory, useful for text types,
  • FieldFormSize Size of the field in the input graphical interface (form)
  • feldFormValue Enumeration of the possible values for entering the field in the input graphic interface (form).
  • FieldCapture Name of the category of the object used for the automatic entry of the field value
  • fieldColor Color of the field area in the graphic interface
  • Fieldlmport Name of the corresponding mapping for importing "information" objects from an external source.
  • Class 120 "CATEGORY” also includes a "fieldObject” field of type list of "Field” class objects allowing direct access to the characteristics of a field of the "information" object, during processing on this object by the graphical interface or by the applications.
  • a "list” type field above is used for category transfers with the database and when entering categories via the GUI.
  • Class 125 "CUSTOM” is used to instantiate an "information" object.
  • the category of the object is specified by the field “categoryName”, the value of which corresponds to the name of a "category” object previously created, instance of the "CATEGORY” class described above.
  • Class 125 "CUSTOM” has two fields of type list, "fieldName” and “fieldValue” for storing, on the one hand, the names of the fields of the object "information" and, on the other hand, the corresponding values .
  • "fieldName” the name of the field
  • “fieldValue” the value corresponding to this field.
  • the characteristics of the fields are stored in the corresponding "category” object.
  • the values of the fields are all stored as a string.
  • the interpretation of the values of integer fields, real or other, is programmed in the corresponding applications.
  • the consistency of the values entered or captured automatically is verified by the type of the field specified in the corresponding "category” object.
  • the names of the fields and their values are stored in dynamic lists, the categories are themselves objects (thus dynamically created) having dynamic lists for their characteristics.
  • the structures for storing the quality information can therefore be programmed, created, modified as needed, via the user interface, without having to modify the source code of the application.
  • a structure of an object can be redefined without intervening on the initial program, freeing itself from a possible hard coding.
  • the graphic menus for entering and viewing the "information" objects are also dynamically modified according to the new structure.
  • the existing objects are dynamically updated according to the new structure: the obsolete fields are deleted and the new fields are eventually filled at the next modification of the objects (automatic synchronization of the "fieldName” and "fieldValue” lists).
  • the "CATEGORY” class can also evolve by adding new "list” fields to specify new characteristics for the fields of "information” objects.
  • the modification of the code of the class "CATEGORY” thus imposes an update of the "category” objects instances of this class, such a modification having to be carried out during the reinstallation of the application.
  • all the "information" objects already existing in the database are preserved by such a modification since the characteristics of their fields are not in the class 125 "CUSTOM". It is thus possible to enrich the application by adding new characteristics for the fields of the "information” objects, without impacting the "information” objects created by a previous version of the application.
  • each object is stored as a single record in a table, "CATEGORY” or “CUSTOM”.
  • the dynamic fields "list” are mapped, that is, stored in a structured way in 'TEXT' columns, list items separated by a programmable regular expression, for example the character 'the ⁇
  • the "list” type field is thus stored in the database in the form of a string of characters in a column, its different elements being separated by the chosen separator.
  • the chosen regular expression should not appear in the values of the items in the list.
  • mappings of the "list” type fields can be envisaged. This choice makes it possible to limit the use of the database to SQL (Structured Query Language) for the simplest way to save, modify or select the objects, the dynamic aspect of the structure objects being processed at the class level and their "list” type fields.
  • SQL Structured Query Language
  • the particular embodiment of the method that is the subject of the present invention is therefore not based on a complex organization of the objects in the database exploited by join SQL statements (see "MatrixOne" method, registered trademark), in order to separate the layer the persistence layer and thus to be able to easily choose other storage techniques, such as XML files.
  • the architecture of the system can be optimized and secured according to the needs and in case of failure, for example, by switching to a storage in the form of XML files, if the SQL server is not available.
  • applications based on the abstraction layer can handle a large number of objects (tens of thousands) and need to access the different fields optimally.
  • all these processes are preferably done in RAM in lists and not by SQL queries on the database.
  • the use of SQL queries is therefore limited preferably to the constitution of lists for processing in the business layer.
  • the abstraction layer provides an easy-to-use AFI (acronym for "Application Programming Interface”).
  • AFI Application Programming Interface
  • object-oriented language it is the set of public and documented methods of a class to create objects of this class and manipulate them. These are, for example, “set” and “get” methods making it possible to read or write the various fields of the object referenced in the code of an application.
  • this API is enriched over time, so as to constitute a library of methods, allowing the creation of new applications. An application that can itself become a new method of the library if it is useful, so that you can program new applications, for example:
  • Class 115 "ElementList” is used to store lists of selected objects for processing. With regard to the capture of information, all information and data necessary for measurement and quality control are captured:
  • GUI Graphical User Interface
  • the graphical interface offers a set of menus for viewing and editing "category" and "information” objects.
  • the menu format for "information” objects is automatically built from the characteristics described in the corresponding category. Through these menus, objects and their fields can be manually specified.
  • Fields in this object category are used to specify regular expressions to look for in files, database connection settings, program calls. These "sensor” objects are hooked to fields of "information” objects to automatically import their value. “Sensor” objects are used to import objects of a category using mapping information for field mapping. These "sensor” objects can therefore be created, modified and stored in order to build an automatic gateway between the specific and unstable elements of the design flows and the stable and homogeneous abstraction layer. The adaptation of a "sensor” object to a new situation is done by modifying one or more fields of the corresponding object.
  • the objects and the values of the fields of the automatically filled objects are interpreted by programs generating the quality views in different forms, for example tables, graphs, reports, metrics (set of measuring points whose value allows to measure a quality or a trend, for example the rate of bugs found per week) or standard supports.
  • FIG. 3 illustrates, on one side, the specific environment related to a stream 305 and, on the other hand, the independent domain 310.
  • the latter comprises sensors 315 connected to the stream 305, an abstraction layer 320, an API 325, applications 330 and the graphical interface 335.
  • the sensors form the interface between the stream 305 and the abstraction layer 320 making the latter independent of said stream 305.
  • FIG. 4 illustrates a particular embodiment of the method that is the subject of the present invention for the creation of objects of category "FUNCTSPEC", functional specification, containing a field making it possible to link this type of object
  • a layer, or level, of abstraction is created with the classes 105 to 125 illustrated in FIG. 1. It is noted that the abstraction layer proposes a simple API, so as to be able to program new applications, for example:
  • the information abstraction layer implements a set of object classes to create objects by defining their structure, and is independent of the design flow of all or part of integrated circuits.
  • Layer Abstraction has a dynamic structure for storing information needed for measurement and quality control of reusable IC chips.
  • the abstraction layer is based on two classes of objects with dynamic lists of fields, the first class making it possible to create "category" objects defining the formats and characteristics of the "information" objects instances of the second class.
  • category objects are created which define a category (or type) of objects whose structure is described above. It is recalled that a certain number of categories of objects are predefined and that their structure can be modified (list of attributes or fields) and new categories can be created, preserving the integrity of objects already created and data previously captured. and saved.
  • the structure of the objects is built from two classes: the class 120 "CATEGORY” which makes it possible to define the categories by a list of fields with their characteristics and a class 125 "CUSTOM” which makes it possible to create objects "informations" and store the values of the fields according to their category.
  • Class 120 "CATEGORY” is used to instantiate an object defining a category of information. This "category” object of information is then referenced when creating an "information" object by the "categoryName” field of the "CUSTOM” class.
  • the definition of a category consists in specifying the list of the fields which will be filled during the creation of the object "information” belonging to this category, with their characteristics, for example graphic, title, possible values, mapping, colors and order .
  • Class 120 "CATEGORY" includes, in particular, the field
  • FieldObject type list of "Field” class objects allowing direct access to the characteristics of a field of the "information" object, during processing on this object by the graphical interface or by the applications.
  • a “list” type field above is used for category transfers with the database and when entering categories via the GUI.
  • Class 125 "CUSTOM" is used to instantiate an "information" object
  • the structures for storing the quality information can therefore be programmed, created, modified as needed, via the graphical interface, without having to modify the source code of
  • Step 410 is in fact the creation of "category" objects in which one or more fields may be specified as being a link to other "information" objects of a certain category.
  • This link mechanism allows the specification of a link type field ("LinkSingle", “LinkMultiple”).
  • a "category" object with the following values is defined for the fields of the class "CATEGORY", that is to say that this object is created by a program or that the we create a new instance of the class
  • FieldType
  • mapping of names for the mapping in case of automatic import of objects of this category (mapping of names for the mapping in case of automatic import of objects of this category).
  • a user interface is updated whose graphic menus for entering and viewing the "information" objects are also dynamically modified according to the new structure.
  • the existing objects are dynamically updated according to the new structure: the obsolete fields are deleted and the new fields are eventually filled at the next modification of the objects (automatic synchronization of the "fieldName” and "fieldValue” lists).
  • This graphical interface offers a set of menus for viewing and editing "categories" and "information” objects.
  • the menu format for "information” objects is automatically built from the characteristics described in the corresponding category. Through these menus, objects and their fields can be manually specified.
  • the graphical interface has all the necessary features to automatically propose all the menus to edit the "information" objects of category "FUNCTSPEC", instances of the class "CUSTOM”.
  • a relational database is created to ensure the persistence of the "category" objects and "information” objects, consisting of two tables: the table 205 "CATEGORY” and the table 210 "CUSTOM".
  • the structure of the records in the tables is described above.
  • the category objects and the information objects are stored in a relational database.
  • a database is created for each project and / or for each block of integrated circuit.
  • Each database has, at least, a "CATEGORY” table for storing "category” objects and a "CUSTOM” table for storing "information" objects.
  • a step 430 we create "sensor" objects that perform the automatic capture of information, that is to say information and data necessary for measurement and quality control.
  • the specification of at least one "sensor” object creates a bridge between the abstraction layer and the integrated circuit design flow.
  • the cost of capturing the information is minimized so as not to consume dedicated resources. the realization of the IP block, which ultimately would negatively impact the quality of the IP block. Since a large amount of useful information for measurement and quality control is generated by design tools and formal methods, in various forms, their capture in the previously described abstraction layer is done automatically.
  • the information can be available in the design flow within text files, in databases or returned by program call.
  • a step 435 the creation of at least one application, developed using the API of the abstraction layer to access the "information" objects of the "FUNCTSPEC” category and to the values of the various fields, is carried out. of these objects: “name”, “summary”, “description”, “requirementName”, “manualReview”, “configuration”, “author”, “creationDate” and “modificationDate”.
  • the functions of the API also make it possible to access the object “category”"FUNCTSPEC” and the values of its various fields.
  • the characteristics of each field can be obtained directly by using the "field fieldObject” object list of the "category” object "FUNCTSPEC".
  • An application checks, for example, the requirements coverage ("REQUIREMENT” category) by the functional specifications and highlights any shortcomings.
  • a step 440 the construction of a library of measurement and / or quality control applications is carried out.
  • step 445 "information" objects are created, each referring to a “category” object, then the "sensor” objects automatically capture values stored in the "information” object fields. by a link with at least one "sensor” object.
  • step 445 Referencing the "information" objects, relative to each other, occurs during step 445, as these "information” objects are created during capture.
  • the data capture consists in creating the "information” objects and filling in their fields (manually or automatically), the link actually being made during the creation of the "information” objects during the step 445.
  • the objects are processed by measurement and / or design quality control applications.
  • the applications only depend on the format of the abstraction layer defined by the category objects. New applications can be developed using the abstraction layer API providing all the functions needed to manipulate objects.
  • a dynamic modification of at least one category of objects is performed without modifying or recompiling the application and preserving the integrity of all the existing information objects. For example, we store names of fields and their values in dynamic lists, the categories themselves being objects, therefore being created dynamically, having dynamic lists for their characteristics.
  • step 460 generated by the optional step 455, an automatic update of a graphical interface is performed, without modification or recompilation of the application.
  • the dynamic modification of menus of a graphical interface for the input and visualization of the "information" objects is performed, these menus being dynamically modified according to the new structure. Then we return to step 445.
  • FIG. 5 shows a computer 500 comprising a controller 505 equipped with a random access memory 510 and a non-volatile memory.
  • volatile 515 retaining a software 520 implementing the method object of the present invention, at least one relational database 525 and an application 530 for measuring and / or controlling the quality of the design.
  • the computer 500 constitutes a device for implementing the method according to the invention.
  • a device comprises: means (505, 405) for setting up an information abstraction layer (320) implementing a set of classes (105 to 125) for creating objects by defining their structure , the abstraction layer being independent of said flow (305) for designing all or part of the integrated circuits, means (505, 520, 445) for capturing specific data and representative of said design flow, for assigning values to fields of at least a portion of said objects and means (505, 530, 450) for interpreting the values of said objects by measurement and / or design quality control applications.
  • the implementation of the present invention also allows the dynamic modification of the categories of objects with automatic update of the graphical interface without modification or recompilation of the application.
  • the implementation of the present invention also makes it possible to reference the "information" objects with each other by link type fields. It allows specifying "sensor” objects to create a dynamic gateway between the abstraction layer and the information sources, to automatically capture the values of the fields by a link with "sensor” objects, to build a library of Measurement and quality control applications, stable and standardized within an organization.
  • the implementation of the present invention makes it possible to measure and control the quality of an IP block without disrupting the design process: automating the capture of the necessary information while preserving the integrity of the data.
  • the present invention can be extended to other domains than the design of IP blocks, in any application where it is a question of collecting and exploiting information through an abstraction layer making it possible to define correlate the measurement of the specificities of the environment.

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)
  • Stored Programmes (AREA)
  • Design And Manufacture Of Integrated Circuits (AREA)

Abstract

Procédé et dispositif d aide à la conception de circuits intégrés. Le procédé d aide à la conception de circuits intégrés, indépendamment d un flot de conception, comporte: uneétape (405) de mise en place d une couche d abstraction (320) de l information mettant en uvre un ensemble de classes (105 à 125) pour créer des objets en définissant leur structure, la couche d abstraction étant indépendante dudit flot de conception (305) de tout ou partie des circuits intégrés,une étape (445) de capture de données spécifiques et représentatives dudit flot de conception, pour attribuer des valeurs à des champs d au moins une partie desdits objets, et une étape (450) d interprétation desvaleurs desdits objets par des applications de mesure et/ou de contrôle de la qualité de la conception. Dans des modes de réalisation, au cours de l étape de mise en place de la couche d abstraction, cette dernièrepossède une structure dynamique pour stocker des informations nécessaires à la mesure et au contrôle qualité de blocs de circuits intégrés réutilisables. Selon d autres modes de réalisation, la couche d abstraction est 30 basée sur deux classes d objets avec listes dynamiques de champs, la première classe permettant de créer des objets «catégories» définissant les formats et caractéristiques des objets «informations» instances de la deuxième classe.

Description

Procédé et dispositif d'aide à la conception de circuits intégrés .
La présente invention concerne un procédé et un dispositif d'aide à la conception de circuits intégrés, indépendamment d'un flot de conception. Elle s'applique, en particulier à l'industrie électronique.
Le flot de conception et d'intégration d'un bloc IP est par nature fortement hétérogène et instable. Il est constitué d'un grand nombre d'outils et de méthodes pour chaque phase d' implémentation et de vérification, et est complété par des pratiques spécifiques et propriétaires bâties sur l'expérience des différents acteurs . La mise en œuvre de ces outils et méthodes génère un ensemble de données utiles à la mesure et au contrôle de la qualité . Mais la nature de ces données , leur format, leur emplacement sont directement liés à l'outil et à la méthode utilisés . Leur interprétation pour en déduire un paramètre qualité nécessite donc une connaissance spécifique de l'outil et de la méthode.
De manière générale, en raison du format propre à chaque flot de conception, l'utilisateur de ce dernier est alors obligé de manipuler quasiment manuellement les données issues dudit flot afin de les interpréter pour en déduire leur adéquation avec le niveau de qualité attendu.
Plusieurs méthodes et dispositifs tentent d' apporter un autre type d'aide à la conception de circuits intégrés, par exemple au travers du regroupement des données concernant les blocs IP sous forme du partage d'un catalogue ou d'une base de données, tel que décrit dans le document US 6 970 875. Cette solution permet d'utiliser et de combiner des blocs existants Une autre solution consiste par exemple à vérifier leur caractéristique, par exemple le temps de traitement lié audit bloc ou à la combinaison de blocs obtenue , comme décrit dans le document US 5 581 473. Toutefois, ces méthodes ne sont pas liées à une mise en place d' une gestion globale de la qualité de flots de conception hétérogènes .
D'autre part, les paramètres qualité utilisés pour mesurer et contrôler la conception et l'intégration d'un bloc IP sont universels (dans le cadre de la conception de circuits intégrés) et sont indépendants des outils et méthodes utilisés . Par exemple un bloc IP conçu dans le cadre d'un flot A doit pouvoir être utilisé dans le cadre d'un flot B. La qualité intrinsèque d'un bloc IP ne doit pas dépendre des moyens mis en œuvre pour le concevoir. C'est pourtant ces moyens qui vont donner les indications sur sa qualité. Concernant les paramètres qualité, il existe des standards de fait, promus par certains organismes comme le VSIA, mais il est important de laisser la porte ouverte à la définition d'autres paramètres si nécessaire.
Il existe donc le besoin d'obtenir une vue homogène de la qualité d'un bloc IP, au travers des différentes phases de son cycle de vie, mais aussi une même vue entre différents blocs IP, à partir de données fournies par une très grande variété d'outils et de méthodes, dans un même flot ou entre différents flots de conception.
Cette vue de la qualité doit être obtenue grâce à une méthode permettant de supporter le concepteur ou l'utilisateur du bloc IP dans la capture des informations nécessaires et l'exploitation de ces informations pour la mesure et le contrôle de la qualité. L'invention ici décrite permet de mettre en place une telle méthode de contrôle de la qualité et de remédier aux inconvénients de l'art antérieur.
A cet effet, selon un premier aspect, la présente invention vise un procédé d' aide à la conception de circuits intégrés indépendamment d'un flot de conception, caractérisé en ce qu'il comporte : une étape de mise en place d' une couche d'abstraction de l'information mettant en œuvre un ensemble de classes pour créer des objets en définissant leur structure, la couche d'abstraction étant indépendante dudit flot de conception de tout ou partie des circuits intégrés , une étape de capture de données spécifiques et représentatives dudit flot de conception, pour attribuer des valeurs à des champs d' au moins une partie desdits objets, et une étape d'interprétation des valeurs desdits objets par des applications de mesure et/ou de contrôle de la qualité de la conception .
La présente invention fournit donc une structure d'objets et un procédé qui permettent de recueillir, sous une forme homogène et stable, l'ensemble des informations nécessaires pour mesurer et contrôler la qualité de tout ou partie d' un circuit intégré pendant les phases de conception et d'intégration. Ce procédé permet ainsi la mise en place d'un tableau de bord qualité unique pour toutes les phases du cycle de vie de tout ou partie d'un circuit intégré, dans un environnement fortement hétérogène et instable. On note que la couche d'abstraction étant indépendante du flot de conception de circuit intégré, elle fournit une base stable et homogène pour la mesure et le contrôle de la qualité .
Selon des caractéristiques particulières, au cours de l'étape de mise en place de la couche d'abstraction, cette dernière possède une structure dynamique pour stocker des informations nécessaires à la mesure et au contrôle qualité de blocs de circuits intégrés réutilisables .
La mise en œuvre de la présente invention fournit ainsi au moins un tableau de bord pour la mesure et le contrôle de la qualité de conception et d' intégration de blocs de circuit intégré réutilisables, aussi appelés « IP » (acronyme de « Intellectual Property » pour propriété intellectuelle) .
Selon des caractéristiques particulières , le procédé tel que succinctement exposé ci-dessus comporte une étape de stockage de noms des champs et de leurs valeurs dans des listes dynamiques, des catégories d'objets mises en œuvre dans la couche d'abstraction. Par ailleurs, ces catégories sont elles-mêmes des objets créées dynamiquement, et ayant des listes dynamiques pour leurs caractéristiques.
Les structures permettant de stocker les informations qualité peuvent donc être définies selon les besoins. En particulier, elles peuvent être programmées, créées, modifiées par l'intermédiaire de l'interface utilisateur, sans avoir à modifier le code source de l'application.
Selon des caractéristiques particulières, au cours de l'étape de mise en place de la couche d'abstraction, cette dernière est basée sur deux classes d'objets avec listes dynamiques de champs, la première classe permettant de créer des objets « catégories » définissant les formats et caractéristiques des objets « informations », instances de la deuxième classe.
Grâce à sa structure dynamique, la couche d'abstraction peut être reconfigurée dynamiquement en fonction des besoins .
Selon des caractéristiques particulières , le procédé tel que succinctement précédent comporte une étape de modification dynamique de menus d'une interface graphique avec l'utilisateur pour la saisie et la visualisation des objets « informations ». Ces menus sont modifiés dynamiquement en fonction de la nouvelle structure des objets et s'adaptent à celle-ci.
Ainsi, les objets existants sont mis à jour dynamiquement en fonction de la nouvelle structure : les champs obsolètes sont supprimés et les champs nouveaux sont éventuellement remplis à la prochaine modification des objets .
Selon des caractéristiques particulières, le procédé selon l'invention comporte une étape de référencement d'objets « informations » les uns avec les autres par des champs de type lien, les objets « informations » possédant au moins un champ dont la valeur est obtenue au cours d'une étape de capture de données .
Selon des caractéristiques particulières, ce procédé comporte une étape de stockage des objets « catégories » et des objets « informations » dans au moins une base de données relationnelle .
Selon des caractéristiques particulières, chaque dite base de données comporte , au moins , une table « CATEGORY » pour stocker les objets « catégories » et une table « CUSTOM » pour stocker les objets « informations ».
Avantageusement, ce procédé comporte une étape de création d'une base de données pour chaque projet et/ou pour chaque bloc de circuit intégré. Les catégories d'objets « informations » peuvent donc être personnalisées projet par projet et les objets « informations » sont donc stockés projet par projet.
Selon des caractéristiques particulières, le procédé comporte une étape de spécification d'au moins un objet « capteur » mis en œuvre au cours de l'étape de capture de données, pour créer une passerelle entre la couche d'abstraction et le flot de conception de circuit intégré .
Selon des caractéristiques particulières, l'étape de capture est automatique, notamment au travers de l'attribution des valeurs auxdits champs des objets par un lien avec au moins un objet « capteur ». Ainsi, la mesure et le contrôle de qualité d'un bloc IP sont effectués sans perturber le processus de conception, grâce à l'automatisation de la capture des informations nécessaires, tout en préservant l'intégrité des données captées. L'aspect automatique de la capture des données offre une mesure objective à tout instant de l'évolution du flot de conception sans interférer avec celui-ci. La présente invention se veut donc être une solution non intrusive par rapport audit flot.
Selon des caractéristiques particulières, ce procédé comporte une étape de construction d' une bibliothèque d' applications de mesure et/ou de contrôle de la qualité. On observe que la mise en œuvre de la présente invention permet que cette bibliothèque soit stable et standardisée au sein d'une organisation.
Selon des caractéristiques particulières, l'étape d'interprétation des classes par des applications de mesure et/ou de contrôle de la qualité de la conception est effectuée en mémoire vive dans des listes .
Ainsi, cette étape ne met pas en œuvre de requêtes SQL sur chaque base de données. L'utilisation des requêtes SQL, plus gourmandes en ressources , se limite donc préférentiellement à la constitution des listes pour traitement dans la couche métier. Les applications reposant sur la couche d'abstraction peuvent ainsi manipuler un grand nombre d'objets (plusieurs dizaines de milliers) et la vitesse d'exécution est optimisée.
Selon un deuxième aspect, la présente invention vise un dispositif de mise en œuvre dudit procédé, caractérisé en ce qu'il comporte :
un moyen de mise en place d'une couche d'abstraction de l'information mettant en œuvre un ensemble de classes pour créer des objets en définissant leur structure, la couche d'abstraction étant indépendante dudit flot de conception de tout ou partie des circuits intégrés , un moyen de capture de données spécifiques et représentatives dudit flot de conception, pour attribuer des valeurs à des champs d' au moins une partie des dits objets et un moyen d' interprétation des valeurs desdits objets par des applications de mesure et/ou de contrôle de la qualité de la conception.
Les avantages, buts et caractéristiques de ce dispositif étant similaires à ceux du procédé tel que succinctement exposé ci- dessus , ils ne sont pas rappelés ici .
D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif en regard des dessins annexés , dans lesquels :
la figure 1 représente, schématiquement, des classes mises en œuvre par des modes de réalisation particuliers du procédé objet de la présente invention , - la figure 2 représente, schématiquement, des bases de données mises en œuvre par des modes de réalisation particuliers du procédé objet de la présente invention , la figure 3 représente des interactions entre un flot et des composants logiciels mis en œuvre par des modes de réalisation particuliers du procédé objet de la présente invention, la figure 4 représente, sous forme d'un logigramme des étapes mises en œuvre dans des modes de réalisation particuliers du procédé objet de la présente invention et la figure 5 représente, schématiquement, un mode de réalisation particulier du dispositif objet de la présente invention .
En ce qui concerne la couche (ou niveau) d'abstraction mise en œuvre pour l' implémentation de la présente invention, la figure 1 illustre un diagramme de classes dans lequel se trouvent :
une classe 105 « Field », une classe 110 « Elément », une classe 115 « ElementList », une classe 120 « Category » et - une classe 125 « Custom ».
On observe que toutes les informations et données nécessaires à la mesure et au contrôle qualité sont stockées, dans les classes 105 à 125, sous la forme d'objets ou d'attributs d'objets.
Ainsi, la classe 105 « Field » comporte les champs suivants, dont le détail est donné plus loin :
« name », - « title »,
« type »,
« size »,
« formSize »,
« formValue », - « capture »,
« color » et
« import ».
La classe 110 « Elément » comporte les champs suivants : - « name », « summary »,
« description »,
« author »,
« creationDate » et - « modificationDate » .
La classe 115 « ElementList » comporte l'objet suivant :
« Eléments » .
La classe 120 « Category » comporte les champs suivants :
« fieldName », - « fieldTitle »,
« fieldType »,
« fieldSize »,
« fieldFormSize »,
« fieldFormValue », - « fieldCapture »,
« fieldColor »,
« fieldlmport » et
« fieldObject ».
Et la classe 125 « Custom » comporte les champs suivants : - « categoryName »,
« fieldName » et
« fieldValue ».
Les objets appartiennent à une catégorie (ou type) d'objets dont la structure est décrite ci-dessous. Un certain nombre de catégories d'objets sont prédéfinies mais leur structure peut être modifiée (liste des attributs ou champs) et de nouvelles catégories peuvent être créées, en préservant l'intégrité des objets déjà crées.
La structure des objets est construite à partir de deux classes : la classe 120 « Category » qui permet de définir les catégories par une liste de champs avec leurs caractéristiques et une classe 125 « Custom » qui permet de créer des objets « informations » et de stocker les valeurs des champs selon leur catégorie. Les catégories sont donc, elles-même, des objets instances de la classe 120 « Category » et les informations de qualité sont stockées dans des objets instances de la classe 125 « Custom ». Les classes 120 « Category » et 125 « Custom » héritent de la classe mère 110 « Elément ». Tous les objets « catégories » et tous les objets « informations » possèdent donc les champs de cette classe : « name », « summary », « description », « author », « creationDate » et « modificationDate » .
La persistance des objets « catégories » et des objets « informations » est assurée par une couche de bases de données relationnelles, représentées en figure 2. En figure 2, deux bases de données 215 et 220 sont représentées. Chaque base de données, 215 et 220, est constituée de deux tables : la table 205 « CATEGORY » et la table 210 « CUSTOM ». La structure des enregistrements dans les tables est décrite ci-dessous. Une base de données est créée par projet et par bloc IP. Les catégories d'objets « informations » peuvent donc être personnalisées projet par projet et les objets « informations » sont stockés projet par projet.
On note que la persistance des objets peut être aussi assurée par d'autres moyens, par exemple des fichiers XML (acronyme de « eXtended Markup Language » pour langage de balisage étendu ») .
La classe 120 « CATEGORY » permet d'instancier un objet définissant une catégorie d'information. Cet objet « category » d' information est ensuite référencé lors de la création d' un objet « information » par le champ « categoryName » de la classe 125 « CUSTOM ». La définition d'une catégorie consiste à spécifier la liste des champs qui seront remplis lors de la création de l'objet « information » appartenant à cette catégorie, avec leurs caractéristiques, par exemple graphique, titre, valeurs possibles, mapping, couleurs et ordre. La classe « CATEGORY » comporte un ensemble de champs de type « liste » pour spécifier chaque champ de la catégorie. A une position dans une liste correspond une caractéristique d'un champ. Les champs de type liste sont les suivants :
- « fieldName » : Nom du champ ; doit être unique pour une catégorie donnée ,
« fieldTitle » : Titre du champ ; texte apparaissant dans l'interface graphique pour la saisie ou la lecture du champ, - « fieldType » : Type du champ ; qui permet de définir à la fois la fonction du champ et le mode graphique utilisé pour sa saisie ; parmi les exemples de types, on peut citer « Title », « Text », « TextArea », « Password », « Path », « FileUpload », « Date », « Select », « Radio »,
« LinkSingle » et « LinkMultiple ». D'autres types peuvent être rajoutés, l'interprétation des types étant programmée dans une interface graphique et des applications correspondantes , - « fieldSize » : Taille du champ en mémoire, utile pour les types textes ,
« fieldFormSize » : Taille de la zone du champ dans l'interface graphique de saisie (formulaire), « feldFormValue » : Enumération des valeurs possibles pour la saisie du champ dans l'interface graphique de saisie (formulaire) . Dans le cas du type « LinkSingle », lien avec un autre objet, ou du type « LinkMultiple », lien avec d'autres objets, enumération des catégories pouvant être liées avec ce champ de cette catégorie,
« fieldCapture » : Nom de la catégorie de l'objet utilisé pour la saisie automatique de la valeur du champ, « fieldColor » : Couleur de la zone du champ dans l'interface graphique et « fieldlmport » : Nom du mapping correspondant pour l' import d'objets « informations » d'une source externe .
La classe 120 « CATEGORY » comporte aussi un champ « fieldObject » de type liste d'objets de classe « Field » permettant d'accéder directement aux caractéristiques d'un champ de l'objet « information », lors des traitements sur cet objet par l'interface graphique ou par les applications. Un champ de type « liste » ci-dessus est utilisé pour les transferts des catégories avec la base de données et lors de la saisie des catégories par l' interface graphique .
La classe 125 « CUSTOM » permet d' instancier un objet « information ». La catégorie de l'objet est précisée par le champ « categoryName », dont la valeur correspond au nom d'un objet « category » précédemment créé , instance de la classe « CATEGORY » décrite ci-dessus .
La classe 125 « CUSTOM » comporte deux champs de type liste, « fieldName » et « fieldValue » permettant de stocker, d'une part, les noms des champs de l'objet « information » et, d'autre part, les valeurs correspondantes. Ainsi, à une position donnée, on obtient, dans la première liste, le nom du champ et, dans la deuxième liste, la valeur correspondant à ce champ. Les caractéristiques des champs sont stockées dans l'objet « category » correspondant. Les valeurs des champs sont toutes stockées sous la forme d'une chaîne de caractères. L'interprétation des valeurs des champs en type entier, réel ou autres, est programmée dans les applications correspondantes. La cohérence des valeurs saisies ou capturées automatiquement est vérifiée grâce au type du champ spécifié dans l'objet « category » correspondant.
Les noms des champs et leurs valeurs sont stockées dans des listes dynamiques, les catégories sont elles-mêmes des objets (donc crées dynamiquement) ayant des listes dynamiques pour leurs caractéristiques. Les structures permettant de stocker les informations qualité peuvent donc être programmées, créées, modifiées selon les besoins, par l'intermédiaire de l'interface utilisateur, sans avoir à modifier le code source de l'application. Ainsi, une structure d'un objet peut être redéfinie sans intervenir sur le programme initial, s'affranchissant d'un éventuel codage en dur.
Les menus graphiques pour la saisie et la visualisation des objets « informations » sont, eux aussi, modifiés dynamiquement en fonction de la nouvelle structure. Les objets existants sont mis à jour dynamiquement en fonction de la nouvelle structure : les champs obsolètes sont supprimés et les champs nouveaux sont éventuellement remplis à la prochaine modification des objets (synchronisation automatique des listes « fieldName » et « fieldValue ») .
D'autre part, la classe « CATEGORY » peut aussi évoluer en ajoutant de nouveaux champs « liste » pour spécifier des nouvelles caractéristiques pour les champs des objets « informations ». La modification du code de la classe « CATEGORY » impose donc une mise à jour des objets « category » instances de cette classe, une telle modification devant être effectuée lors de la réinstallation de l'application. En revanche, tous les objets « informations » déjà existants dans la base de données sont préservés par une telle modification puisque les caractéristiques de leurs champs ne sont pas dans la classe 125 « CUSTOM ». On peut ainsi enrichir l'application en rajoutant de nouvelles caractéristiques pour les champs des objets « informations », sans impacter lesdits objets « informations » créés par une version précédente de 1' application .
Comme expliqué ci-dessus, la persistance des objets « category » et « informations » est réalisée par le stockage des objets en base de données relationnelle. Chaque objet est mémorisé sous la forme d'un seul enregistrement dans une table, « CATEGORY » ou « CUSTOM ». Les champs dynamiques « liste » sont mappés, c'est- à-dire stockés de manière structurée dans des colonnes de type « TEXT », les éléments des listes étant séparés par une expression régulière programmable, par exemple le caractère 'l'¬ Un champ de type « liste » est ainsi stocké dans la base de données sous la forme d' une chaîne de caractères dans une colonne , ses différents éléments étant séparés par le séparateur choisi. L'expression régulière choisie ne doit pas apparaître dans les valeurs des éléments de la liste. Lors d'un transfert d'un objet mettant en œuvre une base de données, une conversion est effectuée entre les champs de type « liste » de l'objet et les colonnes de type « TEXT » de l'enregistrement dans la base de données.
D'autres mappings des champs de type « liste » peuvent être envisagés. Ce choix permet de limiter l'utilisation de la base de données à des instructions SQL (acronyme de « Structured Query Language » pour langage de recherche structuré) les plus simples pour enregistrer, modifier ou sélectionner les objets, l'aspect dynamique de la structure des objets étant traitée au niveau des classes et leurs champs de type « liste ». Le mode de réalisation particulier du procédé objet de la présente invention ne repose donc pas sur une organisation complexe des objets dans la base de données exploitée par des instructions SQL de jointure (voir méthode « MatrixOne », marque déposée) , afin de séparer la couche métier de la couche de persistance et ainsi de pouvoir choisir facilement d'autres techniques de mémorisation, comme des fichiers XML. L'architecture du système peut donc être optimisée et sécurisée en fonction des besoins et en cas de panne, par exemple, par un basculement vers une mémorisation sous forme de fichiers XML, si le serveur SQL n'est pas disponible. De plus, les applications reposant sur la couche d'abstraction peuvent manipuler un grand nombre d'objets (plusieurs dizaines de milliers) et ont besoin d'accéder aux différents champs de façon optimale. Pour optimiser la vitesse d'exécution, tous ces traitements se font préférentiellement en mémoire vive dans des listes et non par des requêtes SQL sur la base de données . L'utilisation des requêtes SQL se limite donc préférentiellement à la constitution des listes pour traitement dans la couche métier .
La couche d'abstraction propose une AFI (acronyme de « Application Programming Interface » pour interface de programmation d'application) simple. En langage orienté objet, il s'agit de l'ensemble des méthodes publiques et documentées d'une classe permettant de créer des objets de cette classe et de les manipuler. Il s'agit par exemple de méthodes de « set » et de « get » permettant de lire ou d'écrire les différents champs de l'objet référencé dans le code d'une application. Dans des modes de réalisation de la présente invention, cette API s'enrichit au fil du temps, de façon à constituer une bibliothèque de méthodes, permettant la création de nouvelles applications . Une application pouvant devenir elle-même une nouvelle méthode de la bibliothèque si elle s'avère utile, de façon à pouvoir programmer de nouvelles applications, par exemple :
recherche d'objets en fonction de leur catégorie et/ou de leur nom, récupération de la valeur d'un champ d'un objet et - création, modification, suppression d'objet(s).
La classe 115 « ElementList » est utilisée pour stocker les listes d'objets sélectionnés pour traitement. En ce qui concerne la capture de l'information, toutes les informations et données nécessaires à la mesure et au contrôle qualité sont capturées :
- manuellement au travers d'un interface graphique, ou GUI (acronyme de « Graphical User Interface » pour interface utilisateur graphique) , par exemple, pour les données et remarques issues d' une réflexion humaine ou - automatiquement, par exécution d'objets « capteurs » pour les valeur de paramètres mesurables .
L' interface graphique propose un ensemble de menus pour la visualisation et l'édition des objets « category » et « informations ». Le format des menus pour les objets « informations » est automatiquement construit à partir des caractéristiques décrites dans la catégorie correspondante . Par ces menus , les objets et leurs champs peuvent être manuellement spécifiés .
Dans le cadre de la mesure et du contrôle de la qualité d' un processus, il est primordial que la collecte des informations nécessaires se fasse de manière continue et sans perturber le processus lui-même. Dans le cas de la conception de circuit intégré, il est important de minimiser le coût requis pour la capture des informations afin de ne pas consommer des ressources dédiées à la réalisation du bloc IP, ce qui, au final, impacterait de façon négative la qualité du bloc IP. Un grand nombre d' informations utiles pour la mesure et le contrôle de la qualité étant générées par des outils de conception et des méthodes formelles, sous différentes formes, leur capture dans la couche d'abstraction précédemment décrite est effectuée automatiquement. L'information peut être disponible dans des fichiers texte, dans des bases de données ou retournée par appel de programmes . La méthode mise en oeuvre pour l' implémentation du procédé objet de la présente invention s'appuie sur des routines logicielles encapsulées dans des objets « capteurs » programmables comme précédemment décrit. Les champs de cette catégorie d'objet permettent de spécifier les expressions régulières à rechercher dans les fichiers , les paramètres de connexion à des bases de données, les appels de programmes. Ces objets « capteurs » sont accrochés à des champs d' objets « informations » pour importer automatiquement leur valeur. Les objets « capteurs » sont utilisés pour importer des objets d'une catégorie en utilisant les informations de mapping pour la correspondance des champs . Ces objets « capteurs » peuvent donc être créés, modifiés et mémorisés afin de bâtir une passerelle automatique entre les éléments spécifiques et instables des flots de conception et la couche d'abstraction stable et homogène. L'adaptation d'un objet « capteur » à une nouvelle situation se fait par la modification d'un ou plusieurs champs de l'objet correspondant.
En ce qui concerne les applications, les objets et les valeurs des champs des objets renseignés automatiquement sont interprétés par des programmes générant les vues qualité sous différentes formes, par exemple tableaux, graphes, rapports, metrics (ensemble de points de mesure dont la valeur permet de mesurer une qualité ou une tendance, par exemple le taux de bugs trouvés par semaine) ou supports standards .
L'indépendance de la couche d'abstraction avec les spécificités des flots de conception permet de bâtir un ensemble d'applications de mesure et de contrôle de la qualité stable et standardisé au sein d'une organisation.
Les applications dépendent uniquement du format de la couche d'abstraction défini par les objets « category ». De nouvelles applications peuvent être développées en utilisant l'API de la couche d'abstraction fournissant toutes les fonctions nécessaires à la manipulation des objets. La figure 3 illustre, d'un côté, l'environnement spécifique lié à un flot 305 et, d'un autre côté, le domaine indépendant 310. Ce dernier comporte des capteurs 315 reliés au flot 305, une couche d'abstraction 320, une API 325, des applications 330 et l'interface graphique 335. Les capteurs forment l'interface entre le flot 305 et la couche d'abstraction 320 rendant cette dernière indépendante dudit flot 305.
La figure 4 illustre un mode de réalisation particulier du procédé objet de la présente invention pour la création d'objets de catégorie « FUNCTSPEC », spécification fonctionnelle, contenant un champ permettant de lier ce type d'objets
« FUNCTSPEC » avec un ou plusieurs objets de catégorie
« REQUIREMENT », expression des besoins pour la conception d'un bloc IP, déjà définie, et de catégorie « DOCUMENT », méta- information sur les documents de référence ou de standards utilisés pour la conception, déjà définie, un champ permettant de stocker l'état de sa revue manuelle, et un champ permettant de lier ce type d'objets avec un objet de catégorie « RELEASE », version du bloc IP, déjà définie.
Au cours d'une étape 405, on crée une couche, ou niveau, d'abstraction avec les classes 105 à 125 illustrées en figure 1. On note que la couche d' abstraction propose une API simple , de façon à pouvoir programmer de nouvelles applications, par exemple :
recherche d'objets en fonction de leur catégorie, de leur nom, - récupération de la valeur d'un champ d'un objet et création, modification, suppression d'objet(s).
La couche d'abstraction de l'information met en oeuvre un ensemble de classes d'objets pour créer des objets en définissant leur structure, et est indépendante du flot de conception de tout ou partie de circuits intégrés . La couche d'abstraction possède une structure dynamique pour stocker des informations nécessaires à la mesure et au contrôle qualité de blocs de circuits intégrés réutilisables . La couche d'abstraction est basée sur deux classes d'objets avec listes dynamiques de champs , la première classe permettant de créer des objets « category » définissant les formats et caractéristiques des objets « informations » instances de la deuxième classe.
Au cours d'une étape 410, on crée des objets « category » qui définissent une catégorie (ou type) d'objets dont la structure est décrite ci-dessus. On rappelle qu'un certain nombre de catégories d'objets sont prédéfinies et que leur structure peut être modifiée (liste des attributs ou champs) et de nouvelles catégories peuvent être créées, en préservant l'intégrité des objets déjà crées et des données préalablement captées et enregistrées. La structure des objets est construite à partir de deux classes : la classe 120 « CATEGORY » qui permet de définir les catégories par une liste de champs avec leurs caractéristiques et une classe 125 « CUSTOM » qui permet de créer des objets « informations » et de stocker les valeurs des champs selon leur catégorie .
La classe 120 « CATEGORY » permet d'instancier un objet définissant une catégorie d'information. Cet objet « category » d' information est ensuite référencé lors de la création d' un objet « information » par le champ « categoryName » de la classe 125 « CUSTOM ». La définition d'une catégorie consiste à spécifier la liste des champs qui seront remplis lors de la création de l'objet « information » appartenant à cette catégorie, avec leurs caractéristiques, par exemple graphique, titre, valeurs possibles, mapping, couleurs et ordre.
La classe 120 « CATEGORY » comporte, en particulier, le champ
« fieldObject » de type liste d'objets de classe « Field » permettant d'accéder directement aux caractéristiques d'un champ de l'objet « informations », lors des traitements sur cet objet par l'interface graphique ou par les applications. Un champ de type « liste » ci-dessus est utilisé pour les transferts des catégories avec la base de données et lors de la saisie des catégories par l'interface graphique.
La classe 125 « CUSTOM » permet d' instancier un objet « information »
Les noms des champs et leurs valeurs sont stockées dans des listes dynamiques, les catégories sont elles-mêmes des objets
(donc crées dynamiquement) ayant des listes dynamiques pour leurs caractéristiques. Les structures permettant de stocker les informations qualité peuvent donc être programmées, créées, modifiées selon les besoins, par l'intermédiaire de l'interface graphique, sans avoir à modifier le code source de
1' application .
L'étape 410 est en fait la création des objets « category » dans lesquels un ou plusieurs champs peuvent être spécifiés comme étant un lien vers d'autres objets « informations » d'une certaine catégorie . Ce mécanisme de lien permet la spécification d'un champs de type lien (« LinkSingle », « LinkMultiple ») .
Dans l'exemple illustré par la figure 4, on définit un objet « catégorie » avec les valeurs suivantes pour les champs de la classe « CATEGORY », c'est-à-dire que cet objet est créé par un programme ou que l'on créé une nouvelle instance de la classe
« CATEGORY » en précisant les valeurs des champs , les champs de type « listes » qui permettent de préciser les caractéristiques de chaque champ de la catégorie ainsi créée étant saisis dans une table par l'intermédiaire de l'interface graphique 335 :
« name » : « FUNCTSPEC », nom permettant de référencer la catégorie pour les objets « informations », « summary » : catégorie pour les objets de spécifications fonctionnelles (texte libre pour présenter brièvement la nature de l'objet), « description » : cette objet « catégorie » comporte les champs « requirementName », « manualReview »,
« configuration » . Le champ « requirementName » est utilisé pour etc (texte libre permettant de décrire dans les détails le rôle de cet objet) , « fieldName » : I requirementName |manualReview | configuration | (noms des champs spécifiques des objets appartenant à cette catégorie, séparés par l'expression régulière choisie, en l'occurence le caractère Λ|')# « fieldTitle » : | Requirement Name | Manual Review I Configuration I (titres des champs spécifiques utilisés pour la visualisation des objets et dans les formulaires de saisie) ,
« fieldType » : | LinkMultiple | Radio | LinkSingle | (types des champs permettant de définir leur fonction et leurs caractéristiques graphiques : le premier est un lien multiple saisi par liste de sélection, le deuxième est un bouton radio, le troisième est un lien unique saisi par liste de sélection, - « fieldSize » : | none | none | none | (la taille mémoire n'est pas à préciser pour ces types de champs), « fieldFormSize » : | none | none | none | (la taille des zones graphiques n'est pas à préciser pour ces types de champs) , - « fieldFormValue » :
I REQUIREMENT,DOCUMENT I Yes,No I RELEASE I (pour le premier champ, tous les objets de catégorie REQUIREMENT et de catégorie DOCUMENT, déjà définis, seront proposés en sélection, pour le deuxième champ, les valeurs « Yes » et « No » seront proposées en bouton radio, pour le troisième champ, tous les objets de catégorie RELEASE, déjà définis, seront proposés en sélection) ,
« fieldCapture » : | none | none | none | (aucun de ces champs n'est capturé automatiquement) ,
« fieldColor » : | SILVER| BISQUE | SILVER| (couleurs différentes pour le deuxième champ dans l'interface graphique) et
« fieldlmport » : I requirementName |manualReview| configuration |
(correspondance de noms pour le mapping en cas d'importation automatique des objets de cette catégorie) .
Au cours d'une étape 420, on met à jour une interface utilisateur dont les menus graphiques pour la saisie et la visualisation des objets « informations » sont, eux aussi, modifiés dynamiquement en fonction de la nouvelle structure . Les objets existants sont mis à jour dynamiquement en fonction de la nouvelle structure : les champs obsolètes sont supprimés et les champs nouveaux sont éventuellement remplis à la prochaine modification des objets (synchronisation automatique des listes « fieldName » et « fieldValue ») .
Cette interface graphique propose un ensemble de menus pour la visualisation et l'édition des objets « catégories » et « informations ». Le format des menus pour les objets « informations » est automatiquement construit à partir des caractéristiques décrites dans la catégorie correspondante. Par ces menus, les objets et leurs champs peuvent être manuellement spécifiés .
Dans l'exemple illustré en figure 4, une fois chaque objet
« category » créé, l'interface graphique dispose de toutes les caractéristiques nécessaires pour proposer automatiquement tous les menus pour éditer les objets « informations » de catégorie « FUNCTSPEC », instances de la classe « CUSTOM ».
Au cours d'une étape 425, on crée une base de données relationnelle pour assurer la persistance des objets « category » et des objets « informations », constituée de deux tables : la table 205 « CATEGORY » et la table 210 « CUSTOM ». La structure des enregistrements dans les tables est décrite ci- dessus. On stocke ainsi les objets « category » et les objets « informations » dans une base de données relationnelle.
Préférentiellement, on crée une base de données pour chaque projet et/ou pour chaque bloc de circuit intégré. Chaque base de données comporte , au moins , une table « CATEGORY » pour stocker les objets « category » et une table « CUSTOM » pour stocker les objets « informations ».
Au cours d'une étape 430, on crée des objets « capteurs » qui effectuent la capture automatique de l'information, c'est-à-dire des informations et données nécessaires à la mesure et au contrôle qualité. La spécification d'au moins un objet « capteur » crée une passerelle entre la couche d' abstraction et le flot de conception de circuit intégré .
Pour que la collecte des informations nécessaires se fasse de manière continue et sans perturber le processus lui-même, dans le cas de la conception de circuit intégré, on minimise le coût requis pour la capture des informations afin de ne pas consommer des ressources dédiées à la réalisation du bloc IP, ce qui, au final, impacterait de façon négative sur la qualité du bloc IP. Un grand nombre d' informations utiles pour la mesure et le contrôle de la qualité étant générées par des outils de conception et des méthodes formelles, sous différentes formes, leur capture dans la couche d' abstraction précédemment décrite est effectuée automatiquement. L'information peut être disponible dans le flot de conception au sein de fichiers texte, dans des bases de données ou retournée par appel de programmes .
On s'appuie ici sur des routines logicielles encapsulées dans des objets « capteurs » programmables comme précédemment décrit. Les champs de cette catégorie d'objet permettent de spécifier les expressions régulières à rechercher dans les fichiers , les paramètres de connexion à des bases de données , les appels de programmes. Ces objets « capteurs » sont accrochés à des champs d'objets « informations » pour importer automatiquement leur valeur. Les objets « capteurs » sont utilisés pour importer des objets d'une catégorie en utilisant les informations de mapping pour la correspondance des champs . Ces objets « capteurs » peuvent donc être créés , modifiés et mémorisés afin de bâtir une passerelle automatique entre les éléments spécifiques et instables des flots de conception et la couche d'abstraction stable et homogène. L'adaptation d'un objet « capteur » à une nouvelle situation se fait par la modification d'un ou plusieurs champs de l'objet correspondant. L'utilisateur peut donc reconfigurer les paramètres de capture d'un tel objet « capteur ».
Au cours d'une étape 435, on effectue la création d'au moins une application, développée en utilisant l'API de la couche d'abstraction pour accéder aux objets « informations » de la catégorie « FUNCTSPEC » et aux valeurs des différents champs de ces objets : « name », « summary », « description », « requirementName », « manualReview », « configuration », « author », « creationDate » et « modificationDate ». Les fonctions de l'API permettent aussi d'accéder à l'objet « catégorie » « FUNCTSPEC » et aux valeurs de ses différents champs . Les caractéristiques de chaque champ peuvent être directement obtenues en utilisant la liste d' objet « Field fieldObject » de l'objet « catégorie » « FUNCTSPEC ». Une application vérifie, par exemple la couverture des besoins (catégorie « REQUIRΞMENT ») par les spécifications fonctionnelles et met en évidence les manquements éventuels .
Au cours d'une étape 440, on effectue la construction d'une bibliothèque d' applications de mesure et/ou de contrôle de la qualité .
Au cours d'une autre étape 445, on crée des objets « informations » faisant, chacun, référence à un objet « category » puis les objets « capteurs » effectuent une capture automatique de valeurs stockées dans les champs d'objets « informations », par un lien avec au moins un objet « capteur ».
Un référencement des objets « informations », les uns par rapport aux autres, s'effectue pendant l'étape 445, au fur et à mesure que ces objets « informations » sont créés pendant la capture. En effet, la capture de données consiste à créer les objets « informations » et à remplir leurs champs (manuellement ou automatiquement) , le lien se faisant effectivement pendant la création des objets « informations » au cours de l'étape 445. Au cours d'une autre étape 450, on effectue le traitement des objets par des applications de mesure et/ou de contrôle de la qualité de la conception.
On note que les applications reposant sur la couche d'abstraction peuvent manipuler un grand nombre d'objets (plusieurs dizaines de milliers) et ont besoin d'accéder aux différents champs de façon optimale. Pour optimiser la vitesse d'exécution, tous ces traitements se font préférentiellement en mémoire vive, par exemple de type RAM, dans des listes et non par des requêtes SQL sur la base de données. L'utilisation des requêtes SQL se limite donc préférentiellement à la constitution des listes pour traitement dans la couche métier. En ce qui concerne les applications, les objets et les champs des objets capturés sont interprétés par des programmes générant les vues qualité sous différentes formes, par exemple, tableaux, graphes, rapports, metrics ou supports standards.
L'indépendance de la couche d'abstraction par rapport aux spécificités des flots de conception permet de bâtir un ensemble d'applications de mesure et de contrôle de la qualité stable et standardisé au sein d'une organisation.
Les applications dépendent uniquement du format de la couche d'abstraction défini par les objets « category ». De nouvelles applications peuvent être développées en utilisant l'API de la couche d' abstraction fournissant toutes les fonctions nécessaires à la manipulation des objets.
Au cours d'une étape 455 optionnelle, on effectue une modification dynamique d'au moins une catégorie d'objets, sans modification ni recompilation de l'application et en préservant l'intégrité de tous les objets informations existants. Par exemple, on effectue le stockage de noms des champs et de leurs valeurs dans des listes dynamiques, les catégories étant elles- mêmes des objets, donc étant créées dynamiquement, ayant des listes dynamiques pour leurs caractéristiques.
Au cours d'une autre étape 460 engendrée par l'étape optionnelle 455, on effectue une mise à jour automatique d'une interface graphique, sans modification ni recompilation de l'application. Par exemple, on effectue la modification dynamique de menus d'une interface graphique pour la saisie et la visualisation des objets « informations », ces menus étant modifiés dynamiquement en fonction de la nouvelle structure. Puis on retourne à l'étape 445.
On observe, en figure 5, un ordinateur 500 comportant un contrôleur 505 doté d'une mémoire vive 510 et d'une mémoire non volatile 515 conservant un logiciel 520 implémentant le procédé objet de la présente invention, au moins une base de données relationnelle 525 et une application 530 de mesure et/ou de contrôle de la qualité de la conception .
L'ordinateur 500 constitue un dispositif de mise en œuvre du procédé selon l'invention. Un tel dispositif comporte : un moyen (505, 405) de mise en place d'une couche d'abstraction (320) de l'information mettant en oeuvre un ensemble de classes (105 à 125) pour créer des objets en définissant leur structure, la couche d'abstraction étant indépendante dudit flot (305) de conception de tout ou partie des circuits intégrés , un moyen (505, 520, 445) de capture de données spécifiques et représentatives dudit flot de conception, pour attribuer des valeurs à des champs d'au moins une partie des dits objets et un moyen (505, 530, 450) d'interprétation des valeurs desdits objets par des applications de mesure et/ou de contrôle de la qualité de la conception .
A la lecture de la description qui précède du procédé et du dispositif objets de la présente invention, on comprend qu'ils permettent la mise en place d'une couche d'abstraction à structure dynamique pour stocker les informations nécessaires à la mesure et au contrôle qualité de blocs de circuits intégrés réutilisables, basée sur deux classes d'objets avec listes dynamiques de champs. La première classe permet de créer des objets « category » définissant les formats et caractéristiques des objets « informations » instances de la deuxième classe. La couche d'abstraction est indépendante du flot de conception d'un bloc IP et fournit une base stable et homogène pour la mesure et le contrôle de la qualité. Grâce à sa structure dynamique, elle peut être reconfigurée dynamiquement en fonction des besoins . La mise en œuvre de la présente invention permet la modification dynamique des catégories d'objets, sans modification ni recompilation de l'application et en préservant l'intégrité de tous les objets informations existants.
La mise en œuvre de la présente invention permet aussi la modification dynamique des catégories d'objets avec mise à jour automatique de l'interface graphique sans modification ni recompilation de l'application.
La mise en œuvre de la présente invention permet encore de référencer les objets « informations » les uns avec les autres par des champs de type lien. Elle permet de spécifier des objets « capteurs » pour créer une passerelle dynamique entre la couche d'abstraction et les sources d'information, de capturer automatiquement les valeurs des champs par un lien avec des objets « capteurs », de bâtir une bibliothèque d'applications de mesure et contrôle de la qualité, stable et standardisée au sein d'une organisation.
La mise en place de la présente invention permet de mesurer et contrôler la qualité d'un bloc IP sans perturber le processus de conception : automatisation de la capture des informations nécessaires en préservant l'intégrité des données.
On note que la présente invention peut être étendue à d'autres domaines que la conception de blocs IP, à toutes applications où il s'agit de recueillir et d'exploiter des informations au travers d'une couche d'abstraction permettant de dé-corréler la mesure des spécificités de l'environnement.

Claims

REVENDICATIONS
1) Procédé d'aide à la conception de circuits intégrés indépendamment d'un flot de conception, caractérisé en ce qu'il comporte :
une étape (405) de mise en place d'une couche d'abstraction (320) de l'information mettant en oeuvre un ensemble de classes (105 à 125) pour créer des objets en définissant leur structure, la couche d'abstraction étant indépendante dudit flot de conception (305) de tout ou partie des circuits intégrés , une étape (445) de capture de données spécifiques et représentatives dudit flot de conception, pour attribuer des valeurs à des champs d' au moins une partie desdits objets, et une étape (450) d'interprétation des valeurs desdits objets par des applications de mesure et/ou de contrôle de la qualité de la conception .
2) Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape (405) de mise en place de la couche d'abstraction (320), la couche d'abstraction possède une structure dynamique pour stocker des informations nécessaires à la mesure et au contrôle qualité de blocs de circuits intégrés réutilisables .
3) Procédé selon l'une quelconque des revendications 1 ou 2 , caractérisé en ce qu'il comporte une étape (410) de stockage de noms des champs et de leurs valeurs dans des listes dynamiques, des catégories d'objets mises en œuvre dans la couche d'abstraction (320) étant, elles-mêmes, des objets ayant des listes dynamiques pour leurs caractéristiques. 4) Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, au cours de l'étape (405) de mise en place de la couche d'abstraction (320), cette dernière est basée sur deux classes d'objets avec listes dynamiques de champs, la première classe (120) permettant de créer des objets « catégories » définissant les formats et caractéristiques des objets « informations » instances de la deuxième classe (125) .
5) Procédé selon la revendication 4, caractérisé en ce qu'il comporte une étape (420, 460) de modification dynamique de menus d'une interface graphique pour la saisie et la visualisation des objets « informations », ces menus étant modifiés dynamiquement en fonction de la nouvelle structure des objets .
6) Procédé selon l'une quelconque des revendications 4 ou 5, caractérisé en ce qu'il comporte une étape (445) de référencement d'objets « informations » les uns avec les autres par des champs de type lien, les objets « informations » possédant au moins un champ dont la valeur est obtenue au cours de l'étape de capture de données.
7) Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce qu'il comporte une étape (425) de stockage des objets « catégories » et des objets « informations » dans au moins une base de données relationnelle (215) comportant au moins une table (205) pour stocker les objets « catégories » et une table (210) pour stocker les objets « informations ».
8) Procédé selon la revendication 7, caractérisé en ce qu'il comporte une étape (425) de création d'une base de données pour chaque projet et/ou pour chaque bloc de circuit intégré.
9) Procédé selon l'une quelconque des revendications l à 8, caractérisé en ce qu'il comporte une étape (430) de spécification d'au moins un objet « capteur » mis en œuvre au cours de l'étape (445) de capture de données, pour créer une passerelle entre la couche d'abstraction (320) et le flot (305) de conception de circuit intégré .
10) Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que l'étape (445) de capture est automatique, notamment au travers de l'attribution des valeurs auxdits champs des objets par un lien avec au moins un objet « capteur ».
11) Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comporte une étape (440) de construction d'une bibliothèque desdites applications de mesure et/ou de contrôle de la qualité .
12) Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que l'étape (450) d'interprétation des classes par des applications de mesure et/ou de contrôle de la qualité de la conception est effectuée en mémoire vive (510) dans des listes .
13) Dispositif (500) de mise en œuvre du procédé selon l'une quelconque des revendications 1 à 12 , caractérisé en ce qu'il comporte :
un moyen (505, 405) de mise en place d'une couche d'abstraction (320) de l'information mettant en oeuvre un ensemble de classes (105 à 125) pour créer des objets en définissant leur structure, la couche d'abstraction étant indépendante dudit flot (305) de conception de tout ou partie des circuits intégrés , - un moyen (505, 520, 445) de capture de données spécifiques et représentatives dudit flot de conception, pour attribuer des valeurs à des champs d'au moins une partie des dits objets et un moyen (505, 530, 450) d'interprétation des valeurs desdits objets par des applications de mesure et/ou de contrôle de la qualité de la conception .
EP07870389A 2006-12-14 2007-12-13 Procede et dispositif d'aide a la conception de circuits integres Withdrawn EP2097844A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0610893A FR2910146B1 (fr) 2006-12-14 2006-12-14 Procede et dispositif d'aide a la conception de circuits integres.
PCT/FR2007/052499 WO2008071895A2 (fr) 2006-12-14 2007-12-13 Procede et dispositif d'aide a la conception de circuits integres.

Publications (1)

Publication Number Publication Date
EP2097844A2 true EP2097844A2 (fr) 2009-09-09

Family

ID=37905879

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07870389A Withdrawn EP2097844A2 (fr) 2006-12-14 2007-12-13 Procede et dispositif d'aide a la conception de circuits integres

Country Status (4)

Country Link
US (1) US20100050147A1 (fr)
EP (1) EP2097844A2 (fr)
FR (1) FR2910146B1 (fr)
WO (1) WO2008071895A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103345387B (zh) * 2013-06-05 2016-12-28 中国电子科技集团公司第十五研究所 基于组件封装实现组件复用的方法
CN103514332A (zh) * 2013-10-10 2014-01-15 长沙理工大学 一种沥青面层结构整体动稳定度的层位分解方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5978811A (en) * 1992-07-29 1999-11-02 Texas Instruments Incorporated Information repository system and method for modeling data
US5581473A (en) * 1993-06-30 1996-12-03 Sun Microsystems, Inc. Method and apparatus for managing timing requirement specifications and confirmations and generating timing models and constraints for a VLSI circuit
US6654747B1 (en) * 1997-12-02 2003-11-25 International Business Machines Corporation Modular scalable system for managing data in a heterogeneous environment with generic structure for control repository access transactions
US5966707A (en) * 1997-12-02 1999-10-12 International Business Machines Corporation Method for managing a plurality of data processes residing in heterogeneous data repositories
US6993456B2 (en) * 1999-09-30 2006-01-31 Rockwell Automation Technologies, Inc. Mechanical-electrical template based method and apparatus
US6970875B1 (en) * 1999-12-03 2005-11-29 Synchronicity Software, Inc. IP library management system
US6594799B1 (en) * 2000-02-28 2003-07-15 Cadence Design Systems, Inc. Method and system for facilitating electronic circuit and chip design using remotely located resources
US20030121010A1 (en) * 2001-12-21 2003-06-26 Celoxica Ltd. System, method, and article of manufacture for estimating a potential performance of a codesign from an executable specification

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008071895A2 *

Also Published As

Publication number Publication date
WO2008071895A2 (fr) 2008-06-19
WO2008071895A3 (fr) 2008-10-09
US20100050147A1 (en) 2010-02-25
FR2910146A1 (fr) 2008-06-20
FR2910146B1 (fr) 2013-01-18

Similar Documents

Publication Publication Date Title
US10410673B2 (en) Embeddable video capturing, processing and conversion application
EP0784266B1 (fr) Procédé de manipulation de modèles de données utilisés en génie logiciel
AU2020203136A1 (en) System and method for the generation of an adaptive user interface in a website building system
JPH09508742A (ja) 従来の非オブジェクト指向業務アプリケーションをアクセスするためのオブジェクト構造を生成するための方法論
US11698944B2 (en) System and method for creation and handling of configurable applications for website building systems
CN104572062A (zh) 地理空间信息工作流服务功能流程模板的构建方法
US20120173965A1 (en) Dynamic web portal page
EP2297681A1 (fr) Procede de gestion de donnees pour atelier oriente service collaboratif
CA2419377C (fr) Systeme d'interface d'acces aux donnees d'une base de donnees
WO2008071895A2 (fr) Procede et dispositif d'aide a la conception de circuits integres.
EP1260911A1 (fr) Structure de données interne pour application destinée à s'interfacer avec une interface pour un document de type HTML ou XML
WO2009147311A1 (fr) Procede de gestion de processus dans un atelier oriente service collaboratif
CN110442782B (zh) 一种云资源检索方法与装置
EP2219113B1 (fr) Procédé d'affichage, dispositif et produit programme d'ordinateur correspondant
CN109522189A (zh) 一种数据监测方法、装置及系统
Čechák Using GraphQL for content delivery in Kentico Cloud
US20140215430A1 (en) Method and apparatus for enabling layered property definition in traditional and cloud computing environments
US20230359814A1 (en) System and method for creation and handling of configurable applications for website building systems
Vallejo Infinite Wicked Desert
FR3118815A1 (fr) Estimation de la progression de l'exécution d'une tâche logicielle
FR2931275A1 (fr) Procede pour la tracabilite de donnees dans un atelier oriente service collaboratif
JP5279767B2 (ja) 統括プログラム
WO2007012707A1 (fr) Systeme ouvert d'integration et de gestion de composants informatiques representant une fonctionnalite specifique d'une application determinee
EP2558932A1 (fr) Procédé d'enregistrement de données, dispositif, et produit programme d'ordinateur correspondant
Li et al. Persistent Storage I: MIDP Record Store

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090626

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20110915

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150701