CN116820602B - Database partial loading system - Google Patents

Database partial loading system Download PDF

Info

Publication number
CN116820602B
CN116820602B CN202310597923.9A CN202310597923A CN116820602B CN 116820602 B CN116820602 B CN 116820602B CN 202310597923 A CN202310597923 A CN 202310597923A CN 116820602 B CN116820602 B CN 116820602B
Authority
CN
China
Prior art keywords
coverage
index
file
design module
identity
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.)
Active
Application number
CN202310597923.9A
Other languages
Chinese (zh)
Other versions
CN116820602A (en
Inventor
汤杰
高波
金俏慧
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.)
Chengdu Rongjian Software Technology Co ltd
Shanghai Hejian Industrial Software Group Co Ltd
Original Assignee
Chengdu Rongjian Software Technology Co ltd
Shanghai Hejian Industrial Software Group Co Ltd
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 Chengdu Rongjian Software Technology Co ltd, Shanghai Hejian Industrial Software Group Co Ltd filed Critical Chengdu Rongjian Software Technology Co ltd
Priority to CN202310597923.9A priority Critical patent/CN116820602B/en
Publication of CN116820602A publication Critical patent/CN116820602A/en
Application granted granted Critical
Publication of CN116820602B publication Critical patent/CN116820602B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44521Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3676Test management for coverage analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/13File access structures, e.g. distributed indices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/172Caching, prefetching or hoarding of files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2246Trees, e.g. B+trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/252Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention relates to the technical field of electronic design automation, in particular to a database partial loading system, wherein a database of the system comprises N index files classified according to coverage indexes, each index file comprises a plurality of design module index data blocks, and each design module index data block comprises a design module identity mark and position information thereof in the coverage index files; when loading, corresponding design module identity and coverage index type are obtained according to the object appointed by the user, the position information of the design module in the coverage index file is searched through the index file, and the data block in the coverage index file is loaded according to the searched position information; the index file and the coverage index file are matched, so that the aim of partial loading is fulfilled, the data volume of loading is greatly reduced, and the technical problem of slow data loading when the database is accessed according to the object appointed by the user is solved.

Description

Database partial loading system
Technical Field
The invention relates to the technical field of electronic design automation, in particular to a database partial loading system.
Background
The purpose of front-end verification is to ensure the correctness and completeness of the logic functions of the design. Coverage rate driven verification technology is an index for measuring design completeness by analyzing the functional coverage rate and the code coverage rate of RTL codes. Wherein coverage includes various types of coverage indicators, such as state machine coverage, row coverage, condition coverage, assertion coverage, and the like. The data corresponding to the coverage rate of the test module can be output no matter software or hardware simulation including formal verification, the crossing data must be unified into a final coverage rate database and an access interface, and the crossing data are shared among tools to make a high-efficiency test plan so as to avoid repeated tests. The current coverage data exchange standard UCIS (Unified Coverage Interoperability Standard) provides a standard node name naming format, a type identifier of each node in different types of coverage indexes, a standardized interface, and the like. In the UCIS standard, all data in the database is stored as one xml format database file. When a user checks one type of coverage index, the system reads the whole database file in an xml format into the memory, and then analyzes and establishes a hierarchical relationship to obtain the corresponding coverage index. Because the coverage rate data and the structured data of the coverage index are stored in the same database file at the same time, the user accesses the whole database file every time, which may also cause a data security risk that the structured data of the coverage index is tampered.
Disclosure of Invention
In order to solve the technical problem of slow data loading when accessing a database according to a user specified object, the invention adopts the following technical scheme: a database partial loading system, the system comprising a database, a processor and a memory storing a computer program, the database comprising a map file sdb, an index file metrindex and a target file, wherein: the sdb comprises a design module, a design module identity, an instance and a mapping relation among instance identities; metrindex includes N index files {metrindex1,metrindex2,…,metrindexg,…,metrindexN},metrindexg classified according to the coverage index as index files of g coverage index metric g, and the value range of g is 1 to N; metrindex g includes M1 design module index data blocks pos, pos= { pos 1,pos2,…,posr,…,posR},posr is the R-th design module index data block, and the value range of R is 1 to R; pos r includes the design module identification information rid r of the r design module and the position information loc r of the r design module in the target file; the value range of the identity information rid f≠ridr of the design module of the f-th index data block pos f is 1 to R, and f is not equal to R; when the computer program is executed by a processor, the following steps are implemented:
c100, when the user selects partial loading, loading the mapping file sdb and the index file metrindex;
c200, acquiring a coverage index type meta g specified by a user and a design module identity rid r according to a first target object specified by the user;
C300, searching all index files in metrindex according to the meta g to obtain an index file metrindex g of the meta g;
C400, searching the design module index data block in metrindex g according to the design module identity mark rid r of the target design module to obtain target position information loc r of the target design module in the target file;
And C500, loading the data blocks in the target file within the range of the target position information loc r into the memory.
The invention provides a database partial loading system, which is characterized in that the position of each design module in a target file is configured in index files indxf corresponding to different coverage indexes, so that a user can quickly acquire the position range of the corresponding design module in the target file through the index file corresponding to the corresponding coverage index when designating the corresponding design module or instance, further load a data block in the position range, achieve the aim of partial loading through the cooperation between the index file and the coverage index file, greatly reduce the loaded data volume, and solve the technical problem of slow data loading when accessing a database according to the designated object of the user.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1is a schematic diagram of a structured data discrete storage system for coverage indicators according to a first embodiment;
FIG. 2 is a flowchart of a data positioning method according to a second embodiment of the present invention;
FIG. 3 is a flowchart of a data visualization positioning method according to a third embodiment of the present invention;
FIG. 4 is a flowchart of a method for loading a database portion according to a fourth embodiment of the present invention;
FIG. 5 is a flowchart of a method for loading a target file portion according to a fifth embodiment of the present invention;
FIG. 6 is a flowchart of a method for partially loading a target file according to a sixth embodiment of the present invention;
FIG. 7 is a flowchart of a coverage rate storing method according to a seventh embodiment of the present invention;
Fig. 8 is a flowchart of a coverage rate obtaining method according to an eighth embodiment of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to fall within the scope of the invention.
As the database UCIS comprises basic information of a source file, basic information of a design module, basic information of an instance, structured data of coverage indexes, coverage rate data obtained by different test cases and the like, wherein the structured data comprises hierarchical structure relations of different types of coverage indexes. In the UCIS standard, all data in the database is stored as one xml format database file. When a user checks one type of coverage index, the system reads the whole database file in an xml format into the memory, and then analyzes and establishes a hierarchical relationship to obtain the corresponding coverage index. Because the coverage rate data and the structured data of the coverage index are stored in the same database file at the same time, the user accesses the whole database file every time, which may also cause a data security risk that the structured data of the coverage index is tampered. In order to solve the technical problem, the present invention proposes a first embodiment.
Example 1
Referring to fig. 1, a first embodiment provides a structured data discrete storage system for coverage indicators, the system includes a database, a processor, and a memory storing a computer program, the database includes N coverage indicator files item= { item 1,item2,…,itemi,…itemN }, where item i is a structured data storage file for an i-th type coverage indicator of a design module, and a value of i ranges from 1 to N. It should be noted that, because the data required by different coverage indexes are different, the corresponding structured data is stored by using different coverage index files; structured data for a plurality of different design modules may be included in the same coverage index file item i. Types of coverage indicators (metrics) include a conditional coverage indicator, a row coverage indicator, an assertion coverage indicator, a finite state machine coverage indicator, a flip coverage indicator, a functional coverage indicator, or the like.
Optionally, item i is a line coverage index file, a condition coverage index file, a finite state machine coverage index file, an assertion coverage index file, a flip coverage index file, or a function coverage index file, and other types of coverage indexes in the prior art fall within the scope of the present invention. The j-th class coverage index file item j is different from item i in type, the value range of j is 1 to N, and i is not equal to j.
The structured data of the design module is a tree structure with a hierarchical structure, and the tree structure meets UCIS standards and comprises: a design module coverage field, an index coverage field (scope) and a coverage item (coveritem objects), wherein in the tree hierarchy structure, the design module coverage field is a root node of the tree structure, the coverage item is a leaf node of the tree structure, and the index coverage field is an intermediate node of the tree structure; wherein the index overlay domain as an intermediate node may further comprise a plurality of layers of index overlay domains having a parent-child nested structure. It should be noted that, since one coverage index file includes at least one design module, each design module corresponds to a tree structure. Alternatively, the design module in the coverage index file may be a module (module), a package (package), a program (program), an interface (interface), or the like. The coverage items are basic units for measuring coverage rate, the coverage states of all coverage items form the coverage rate of the coverage domain of the corresponding parent node, and the coverage rate of all coverage domains forms the coverage rate of one root node.
As an example, when the type of the coverage index is a Finite State Machine (FSM), the coverage index file of the Finite state machine includes a plurality of design modules, each design module includes a plurality of Finite state machines, and at this time, the coverage index file includes a plurality of tree structures with the design modules as root nodes, the tree structures with the design modules as root nodes further include an index coverage domain with the root nodes as parent nodes, each index coverage domain is an index coverage domain of a corresponding plurality of Finite state machines, and the structures of the index coverage domains of the Finite state machines are similar, except for the state configuration and the state conversion configuration of different Finite state machines. For example, the design module test1 includes a finite state machine curr_state1, where the finite state machine includes a state coverage field state and a state transition coverage field transtation, where the state coverage field includes all state coverage items, such as an error state, an idle state, an occupied state, and so on; the state transition coverage includes all state transition coverage items, such as transition from an error state to an idle state, transition from an idle state to an error state, transition from an idle state to an occupied state, transition from an occupied state to an error state, transition from an occupied state to an idle state, and the like. In the tree structure of the design module test1, using test1 as a root node, using curr_state1 as a parent index coverage domain, using states and transtation as child index coverage domains, using all state coverage items and all state transition coverage items as leaf nodes, wherein the parent node of the parent index coverage domain is the root node, the parent node of the child index coverage domain is the parent index coverage domain, and the parent index coverage domain and the child index coverage domain are intermediate nodes with nested structures.
As another example, when the type of the index coverage is a condition and an expression, the structured data of its corresponding coverage index includes two tree structures: a conditional structure and an expression structure, wherein the conditional structure includes a conditional override field and all conditional override items included in the conditional override field; the expression structure includes an expression overlay field and all expression overlays included by the expression overlay field. Wherein each type may include a nested structure of multiple index coverage fields.
Preferably, the overlay index file is named by the type of overlay index.
Further, item i includes: m1 design modules cover a domain data block root= { root 1,root2,…,rootm1,…,rootM1 }; the root m1 is an M1-th design module coverage domain data block, and includes a design module identity id m1, and the value range of M1 is 1 to M1. The identity identifier rid f of the f-th design module coverage domain data block root f is different from rid m1, the value range of f is 1 to M1, and f is not equal to M1.
Preferably, each design module coverage field data block further comprises a design module type identifier, wherein the design module type identifier meets UCIS standards.
The item i is a json format file, each data block is a piece of data formed by a plurality of basic information for describing an object in the json format file, and specifically, each data block comprises B key value pairs: { Key1: value1, key2: value2, …, keyi: valuei, …, keyB: valueB }, wherein each Key value represents a basic information of an object, the Key value pairs in the data block are an unordered set of Key value pairs, and the positions of the Key value pairs can be exchanged.
For example: the design module coverage domain data block is { "rid":1, "type": 24, "" name ": fsm" }, the design module coverage domain data block comprises 3 key value pairs in total, wherein the design module identity identifier "rid" is taken as a key and a value of "1" to form a key value pair, the design module type identifier type is taken as a key and a value of "24" to form a key value pair, the design module name is taken as a key and a value of "fsm" to form a key value pair, and the object described by the data block is a design module object with the design module identity identifier of 1, the type of 24 and the name of fsm.
Further, item i also includes: m2 index coverage field data blocks scope = { scope 1,scope2,…,scopem2,…,scopeM2 }, where scope m2 is the M2 index coverage field data block, scope m2 includes index coverage field identity id m2, and the range of M2 is 1 to M2.
It should be noted that, the index coverage field data block is one type of data block, each index coverage field data block includes multiple basic information of the index coverage field, and the index coverage field data block is an intermediate node in the tree structure.
The index coverage domain data block comprises a father index coverage domain and a child index coverage domain, and the child index coverage domain binds the father index coverage domain. All index coverage domain data blocks of the same parent node in the scope are parallel nodes. In item i, when corresponding data blocks are loaded into the memory, the computer loads the corresponding data blocks according to the distribution sequence of the data blocks, so that all index coverage domain data blocks distributed in item i and located under a root m1 form a hierarchical structure with a root m1 as a parent node and all index coverage domain data blocks under a root m1 as child nodes after being loaded into the memory, and the range of a root m1 is that the data blocks are distributed backwards from the first data block after the root m1 until no other data blocks exist or are executed until the next design module coverage domain data block.
Alternatively, in a path from the root node to the leaf node, the intermediate nodes traversed may include a plurality of intermediate nodes acting as index coverage domains, the plurality of index coverage domains constituting a hierarchy. When the parent node bound by scope m2 is the M2 'index coverage domain data block scope m2′, spid m2=sidm2′, where sil m2′ is the index coverage domain identity of scope m2′, and the value range of M2' is 1 to M2. The overlay domain binding identifies the structured relationships used to establish the data blocks.
Further, item i also includes: the overlay data blocks cvitem = { cvitem 1,cvitem2,…,cvitemm3,…,cvitemM3 } of the index overlay domain data blocks in M3 binding scope respectively, wherein cvitem m3 is the M3-th overlay data block, and comprises an overlay identity iid m3 and an overlay binding identity ipid m3, and the value range of M3 is 1 to M3; when cvitem m3 binds scope m2, ipid m3 is equal to the sil m2 of bound scope m2. Each overlay item data block is bound with an index overlay domain data block, the index overlay domain data block and the overlay item data block cannot be bound with the same father node, and child nodes under the same father node are of the same data block type. For example, child nodes are all child index coverage data blocks or all coverage data blocks, but cannot include both index coverage data blocks and coverage data blocks.
It should be noted that the overlay item data block is one type of data block, and contains various basic information of the overlay item. The overlay item is a leaf node in the tree structure.
Preferably, each design module overlay domain data block further comprises a design module type identifier, each index overlay domain data block further comprises an index overlay domain type identifier, and each overlay item data block further comprises an overlay item type identifier, wherein the design module type identifier, the index overlay domain type identifier and the overlay item type identifier meet UCIS standards. It should be noted that, tree hierarchies corresponding to different coverage indexes and type identifiers of each node in each tree hierarchy are defined in UCIS standards. For example, in the UCIS standard, the code coverage of the finite state machine, the type identifier of the design module overlay field is 24, the type identifier of the parent index overlay field FSM is 22, the child index overlay field includes the type identifier of the state overlay field is 29, the type identifier of the state transition overlay field is 30, and the type identifiers of the state overlay item and the state transition overlay item are 11. The storage system provided by the embodiment of the invention can be used as a sharing system by adopting the type identifier conforming to UCIS standard, on one hand, corresponding coverage rate data can be directly extracted from a third party database through a standard UCIS interface, and on the other hand, the coverage rate data corresponding to the discrete storage system can be shared for other databases.
The design module type identifiers in the plurality of different design modules corresponding to the tree structure of the same coverage index type in the item i are the same. The tree structure corresponding to each type of coverage index and the type identifier of each node in the tree structure are defined in UCIS standard. For example, a conditional coverage index, a line coverage index, an assertion coverage index, a finite state machine coverage index, or the like is defined in the UCIS standard, where each coverage index corresponds to a standard tree structure and a type identifier of each node in the corresponding tree structure.
Each design module coverage domain data block is used as a root node of a tree structure, and all data blocks under the design module coverage domain data block belong to the design module coverage domain data block; when there are multiple design module coverage domain data blocks, then all data blocks after the current design module coverage domain data block root m1 and before the next design module coverage domain data block root m1+1 belong to the design module coverage domain data block root m1. The child index coverage domain data blocks establish structural relations among index coverage domains by binding identity marks of parent index coverage domain data blocks, hierarchical relations of different types of index coverage domains accord with structural definitions in UCIS standards, and similarly, the coverage item data blocks establish structural relations between coverage items and index coverage domains by binding identity marks of index coverage domains, so that a tree structure with one design module as a root node, index coverage domains as intermediate nodes and coverage items as leaf nodes is formed.
Preferably, each design module overlay field data block further comprises a design module name, each index overlay field data block further comprises an index overlay field name, and each overlay item data block further comprises an overlay item name.
Preferably, the discretized storage system further includes a basic information file of a source file, where the basic information file of the source file includes basic information data blocks { sorf 1,sorf2,…,sorfx1,…,sorfX1},sorfx1 of X1 source files are basic information data blocks of X1 source files, and a value range of X1 is 1 to X1; sorf x1 includes the mapping of the source file identity sorfid x1 to the absolute path RL x1 of the source file. Optionally, the absolute path RL x1 of the source file is the storage path of the source file.
Preferably, root m1 also includes source file identity sorf x1. And acquiring an absolute path of the source file according to the source file identity through a mapping relation in a basic information file of the source file during compiling, and accessing the source file according to the absolute path of the source file. The storage space occupied by the absolute path of the source file can be further reduced by replacing the absolute path of the source file with the source file identification.
In summary, the structured data discrete storage system for the overlay index provided by the embodiment of the invention includes N overlay index files, each overlay index file is a structured data storage file of a design module corresponding to an overlay index, the overlay index storage file includes M1 overlay domain data blocks of the design module, M2 overlay domain data blocks of the index and M3 overlay item data blocks, wherein a hierarchical structure relationship is established between the overlay domain data blocks of the index and the overlay item data blocks through binding identification, and as the data blocks in the discrete storage system are subjected to discrete storage in json format, and meanwhile, a hierarchical structure between the data blocks is established through binding identification, the aim of guaranteeing the hierarchical structure between the data blocks and simultaneously performing discrete storage is achieved, and meanwhile, the technical problem that the hierarchical relationship can be established only by reading the whole database into a memory in a standard UCIS database is solved, and meanwhile, as the structured data is not stored in the same file any more, the technical problem that the structured data is easy to be tampered with the coverage rate is solved.
As a preferred embodiment, on the basis of the first embodiment, the identities included in all the data blocks in the item i are globally unique. Specifically, the design module identity, the index coverage area identity and the coverage item identity are globally unique. It should be noted that, the design module identity identification globally and uniquely means that the identity identification of the same design module in the database is the same, the identity identifications of different design modules are different, and the design module identity identification, the index coverage area identity identification and the coverage item identity identification are different; i.e. the design module using the same identity is considered to be the same design module, and other types of identities are the same. As an example, the same design module a as root m1 is included in item j, and the identity of design module a is also rid m1. When a user designates a unique design module identity, the system can directly locate a unique data block without layered searching, thereby achieving the purpose of quick location.
Optionally, the data types of the identity are long-form or universal unique identification codes (Universally Unique Identifier, UUID). When the number of the identity marks is huge, the long-shaped identity marks occupy larger storage space, and the UUID is adopted at the moment, so that the storage space can be saved.
In the preferred embodiment, the identity tag globally unique among all the data blocks in item i has the following defects: when long-integer storage is adopted, when the quantity of structured data to be stored is very large, the identity identification data is also very large, so that a large amount of storage space is occupied; when UUIDs are adopted, the occupation of space storage resources can be relatively reduced for a large amount of data, but when the amount of the identity identification data is small, the UUIDs occupy more space due to the fixed length of the UUIDs. In order to solve the technical problem that the identity mark occupies a large amount of storage space, the invention provides the following preferred embodiments.
As a preferred embodiment, all design module identities in item i are globally unique, the index overlay domain identity is unique under the same parent node, and the overlay item identity is unique under the same parent node. It should be noted that, because all the index overlay domain identifiers using the same design module as the father node are uniformly and independently numbered and are different from each other. The overlay item identification numbers are the same, and the overlay items are described below by taking the overlay item as an example, and all the overlay items under the same father node are uniformly and independently numbered and are different from each other. As one example, two index coverage domains are included in the finite state machine: the state coverage domain node and the state transition coverage domain node, the child nodes included as the father node in the state coverage domain include: error state nodes, idle state nodes, occupied state nodes; the state transition coverage domain includes, as a parent node, child nodes including: a node which is converted into an idle state from an error state, a node which is converted into an error state from an idle state, a node which is converted into an occupied state from an idle state, a node which is converted into an error state from an occupied state, and a node which is converted into an idle state from an occupied state; one combination of identity tags may be: two state coverage areas under the design module are independently numbered: the state coverage area node with the identity of 01 and the state transition coverage area node with the identity of 02 comprise two groups of child nodes belonging to the same father node, wherein the two groups of child nodes are independently coded, and one group of child nodes is the state coverage area node with the identity of 01: an error state node with an identity of 01, an idle state node with an identity of 02, an occupied state node with an identity of 03, and a child node of a state transition coverage domain node with an identity of 02: the node of the identity mark 01 converted from the error state to the idle state, the node of the identity mark 02 converted from the idle state to the error state, the node of the identity mark 03 converted from the idle state to the occupied state, the node of the identity mark 04 converted from the occupied state to the error state, and the node of the identity mark 05 converted from the occupied state to the idle state.
The unique method of the identity under the same father node can enable the identity under each father node to count independently, so that the problem that the identity occupies a storage space is greatly reduced, and the technical problem that the data volume of the identity occupies a huge data storage space is solved.
As a preferred embodiment, all design module identities in item i are globally unique, the identities corresponding to the index overlay domain are globally unique, and the overlay identity is unique under the same father node. The global unique identification corresponding to the index coverage field refers to the uniform independent numbering of the index coverage field identification in all design modules in item i and is different from each other. As an example, item i includes an index coverage field data block in the first design module and an index coverage field data block in the second design module, where the identity of the index coverage field data block in the first design module is 001, and the identity of the index coverage field data block in the second design module is 002, where the identities 001-002 in the first design module and the second design module are uniformly numbered and different from each other.
The overlay item identity is independently numbered under each father node again by the way that the index overlay domain identity is globally unique and the overlay item identity is unique under the same father node, and the technical problem that the data volume of the identity occupies huge data storage space can be solved as well. And the overall uniqueness in the index coverage domain identity can enable a user to reduce the number of layers searched when searching the tree structure, and the searching efficiency is improved.
As a preferred embodiment, all design module identities in item i are globally unique, the identities corresponding to the index overlay domain are globally unique, and all overlay item identities are globally unique. It should be noted that, the identity identifiers of all the coverage items globally and uniquely refer to the identity identifiers of all the coverage items included in all the modules in item i are uniformly and independently numbered and are different from each other. Compared with the scheme that all the data blocks comprise the global unique identification, the method and the device can reduce the maximum number length of the identification, and enable a user to directly locate the corresponding coverage item because the identification of the coverage item is globally unique when the user searches the corresponding coverage item, and the tree structure is not required to be searched, so that the locating efficiency is improved.
The first embodiment is to store the structured data of the coverage index separately, so that the problem of data security risk that the structured data of the coverage index is tampered due to that a user accesses the whole database file every time can be solved. Based on the xml format database in UCIS standard, the whole database file needs to be read into the memory again even if the user designates the database, which results in slow system performance. In order to solve this problem, the present invention proposes implementation two and embodiment three.
Example two
A second embodiment provides a data positioning system comprising a database, a processor and a memory storing a computer program, the database comprising a mapping file sdb, an index file indxf and an overlay index file item.
Further, the sdb includes a design module, a design module identity, an instance, and a mapping relationship between instance identities. It should be noted that, all the design module identifiers and instance identifiers in the coverage index file are defined in the sdb file, and the design module identifiers and instance identifiers are globally unique in all the files of the database, that is, in other files, for example, item files, index files indxf and other files, the design module identifiers of the same design module are the same, the design module identifiers of different design modules are different, and the instance identifiers are globally unique.
As a preferred embodiment, the mapping relationship in the sdb includes Q1 first mapping relationships map1 and Q2 second mapping relationships map2, where map 1= { map1 1,map12…,map1q1,…,map1Q1},map1q1 is the Q1 st first mapping relationship, map1 q1 includes the mapping relationship between the Q1 st design module mod q1 and the design module identity id q1, and the value range of Q1 is 1 to Q1; map 2= { map2 1,map22…,map2q2,…,map2Q2},map2q2 is the second mapping relation of the Q2 nd, map2 q2 includes the mapping relation among the Q2 nd instance inst q2, instance identity instid q2 and design module identity rid q1, and the value range of Q2 is 1 to Q2.
When coverage rate test is performed, one design module may instantiate multiple instances, that is, a mapping relationship is established between one design module identity rid q1 and the multiple instances.
As a preferred embodiment, map2 q2 also includes the parent node identity of inst q2.
Further, indxf includes D index data blocks ind, ind= { ind 1,ind2…,indd,…,indD},indd is the D index data block, ind d includes a design module identity id m1, an overlay index metric i, and location information mline d of the design module in the overlay index file, where D ranges from 1 to D.
Alternatively, index file indxf is made up of several index data blocks, each of which may be in xml format or json format.
Wherein rid m1 belongs to a pre-defined identity of a design module in sdb. The coverage index meta i is one type of coverage index corresponding to the item file. The type of the coverage index (metric) is described in detail in the first embodiment, and will not be described again.
As a preferred embodiment, when item i is in text format, mline d includes a line number for the start line and a line number for the end line.
As a preferred embodiment, mline d includes a start position offset and a data length when item i is in binary format. The initial position offset is the offset of the initial position of the data block relative to the initial position of the file, and the initial position offset plus the data length is the end position of the data block.
The indxf is used for directly searching the row range of the corresponding design module in the coverage index file according to the target design module specified by the user, so that the system directly loads the data blocks in the corresponding row range instead of the whole coverage index file, the loaded data quantity is reduced, and the loading speed is improved.
Further, item= { item 1,item2,…,itemi,…itemN},itemi is a structured data storage file of a design unit corresponding to the i-th type coverage index metric i, and the value range of i is 1 to N; the item i includes M coverage index data blocks, and the structure of the mth coverage index data block including the design module id m and the location information sline m.itemi file of the design module in the source file is described in detail in the first embodiment, which is not described in detail. It should be noted that, the coverage index data block includes a coverage domain data block root, an index coverage domain data block scope, and a coverage item data block cvitem as in the first embodiment, where m=m1+m2+m3, which are described in detail in the first embodiment, and are not described again. Sline m in item i is used to locate directly to a location in the associated source file according to the user-selected target object after the system loads the data blocks in the corresponding row range into memory. The item i includes structured data for storing the design module, that is, includes the design module identity when the coverage indicator data block is a design module coverage field data block; when the coverage index data block is an index coverage domain data block, the coverage index data block comprises an index coverage domain identity; when the coverage index data block is a coverage item data block, the coverage item data block comprises a coverage item identity and a coverage item binding identity; after the item i file is read into the memory and parsed, a structured data relationship can be established between corresponding coverage indicator data blocks through binding identification.
As a preferred embodiment, sline m includes left rank position information and right rank position information of the design module in the source file.
Further, referring to fig. 2, when the computer program is executed by the processor, the following steps are implemented:
A100, reading the mapping file sdb and the index file indxf into the memory. Wherein the map file sdb and the index file indxf are global shared files in the database.
And A200, acquiring a first target object designated by a user, wherein the first target object is a module or an instance. It should be noted that, the user selects the first target object in the visualization window.
And A300, searching the sdb in the memory according to the first target object to obtain a design module identity mark rid m1 corresponding to the first target object. It should be noted that, when the first target object is an instance, map2 is searched to obtain the identity of the design module. When the first target object is a design module, searching map1 to obtain the identity of the design module.
A400, searching indxf in the memory according to the rid m1 and the coverage index metric i specified by the user, and obtaining mline d. Note that mline d acquired at this time is a line range in item i. For example: when item i is in text format, mline d includes a line number of 10 for the beginning line and a line number of 50 for the ending line, which indicates that the data blocks in the range from line 10 to line 50 in item i file all belong to rid m1, and the data blocks in the range from line 10 to line 50 need to be read into memory.
A500, all data blocks ablock included in mline d in item i are read into the memory. It should be noted that, in this step, the design in item i can be read into the memory, and the coverage index file is converted into the memory data with the hierarchical structure relationship.
A600, searching ablock in the memory according to the identity of the second target object specified by the user to obtain the position information sline of the second target object in the source file. It should be noted that, the user selects the second target object in the visualization window, where the second target object may be a certain coverage item, for example, when the user wants to view an idle state in the FSM, the idle state object is designated as the second target object.
A700, locating the position of the second target object in the source file according to ablock and sline.
As a preferred embodiment, a basic information file of the source file is also included in the database, where the basic information file includes a mapping relationship between the source file identity and the absolute path of the source file. The basic information file of the source file is described in detail in the first embodiment, and will not be described in detail.
As a preferred embodiment, ablock includes a source file id, and the a700 further includes: searching a basic information file of a source file according to the source file identity to obtain an absolute path of the source file, opening a corresponding source file according to the absolute path of the source file, and positioning the position of a design module in the source file according to sline.
In summary, the database of the second embodiment includes the mapping file sdb, the index file indxf and the coverage index file item, and the mapping file sdb and the index file indxf are read into the memory first; then, a first target object designated by a user firstly acquires the identity of the design module through the sdb, then acquires the line range information of the design module in item through indxf, then reads the data block in the coverage index file according to the line range information, achieves the aim of partially loading the data block, and finally acquires the source file position information carried in the read data block according to the target design module designated by the user to achieve the aim of positioning the corresponding line of the target design module in the source file. The problem of resource consumption caused by the fact that the whole database file needs to be loaded every time data are read in the prior art is solved.
Example III
An embodiment three provides a data visualization positioning system, which comprises a database, a processor and a memory storing a computer program, wherein the database comprises a mapping file sdb, an index file indxf, an overlay index file item and an extension information file ext.
Further, the sdb includes a design module, a design module identity, an instance, and a mapping relationship between instance identities. It should be noted that, the mapping file sdb is the same as that in the second embodiment, and will not be described again.
Further, indxf includes a plurality of index data blocks, each index data block including a module identity, an overlay index, location information iline of the design module in the overlay index file, and location information eline of the design module in the extension information file.
Wherein iline is used to index the location of the coverage index data block associated with the design module in the coverage index file, eline is used to index the location of the extension data block associated with the design module in the extension information file. iline1 includes a start position and an end position of the associated coverage index data block corresponding to each design module in the coverage index file, and the corresponding eline includes a start position and an end position of the extension data block corresponding to the design module in the extension information file.
It should be noted that, in the coverage index file, the data blocks related to each design module are sequentially distributed, and when the data block corresponding to one design module is written, the related data block of another design module is written. For example, the relevant data blocks of the first design module are located in rows 1-12 and the relevant data blocks of the second design module are located in rows 13-23. Wherein, each design module related coverage index data block comprises a design module coverage domain data block, an index coverage domain data block, a coverage item data block and the like. The corresponding one of the extended data blocks in the extended information file corresponds to the overlay index data block in the overlay index file, i.e., each of the extended data blocks in the extended information file corresponds to the overlay index data block in the overlay index file. For example, the relevant data blocks of the first module are located in lines 1-12, and the corresponding 12 lines of extended data blocks are included in the extended information file. The design module in the coverage index file covers the domain data blocks and the index coverage domain data blocks, and corresponding expansion data blocks exist in the expansion information file; the coverage item data blocks in the coverage index file may or may not include corresponding extension data blocks in the extension information file.
Further, the item includes N overlay index files, wherein the ith overlay index file item i includes M overlay index data blocks, wherein the mth overlay index data block includes an identity describing the object. It should be noted that, the object is an object described by each data block, the description object may be a design module, an index coverage area or a coverage item, and the identity of the description object may be a design module identity, an index coverage area identity or a coverage item identity, etc. The coverage index file item is the same as that in the first embodiment, and will not be described again.
Further, ext comprises N extension information files, wherein an ith extension information file ext i comprises M (i) extension data blocks, wherein an mth extension data block comprises associated identity and location information sline m of an object in a source file, wherein M (i) is less than or equal to M. The associated identity is used for being associated with a corresponding coverage index data block in the coverage index file. It should be noted that each coverage index file corresponds to one extension information file. Compared with the second embodiment, the identity and position information of the description object in the coverage index data block in the item file in the second embodiment are disassembled and stored separately, that is, the structural information in the coverage index data block is stored in item i, and the position information in the coverage index data block is stored in the ext i file. The method can enable the system to load the useful information of the object according to actual conditions, and not load all the information of the object.
As a preferred embodiment, when ext i is a file corresponding to the conditional coverage indicator, the extended data block further includes a key value pair of a condition and a parameter, where a key in the key value pair of the condition is a conditional name and the key value is a condition; the keys in the parameter key value pair are named parameters, and the key value is an array of a plurality of parameters. As an example, the conditional expression "b; the parameter key value pair is "subexpr" [ "b", "c", "d", "e", "f" ]. The additional information is put into the expansion file, so that the data volume loaded during calculating the coverage rate or merging the databases can be reduced, the information of the object is divided into two files, namely the coverage index file and the expansion information file from the two angles of calculating the coverage rate and displaying, and the relevant expansion information file is not required to be loaded during calculating the coverage rate, so that the data volume loaded is reduced, and the loading efficiency is improved.
As a preferred embodiment, ext i does not include the extended data block corresponding to the coverage item data block in item i. Whether the coverage item data block has a corresponding extension data block depends on the type of the coverage index, and when the type of the coverage index is a conditional coverage index, the coverage item corresponding to the conditional coverage index has no corresponding position information in ext i; when the coverage index is FSM, the coverage item corresponding to FSM has location information in ext i. When the coverage items have position information, each extension data block in the extension information file corresponds to one-to-one with the coverage index data block in the coverage index file; when the coverage item does not have position information, other data blocks in the extension information file are in one-to-one correspondence with the extension data blocks corresponding to the data blocks of the coverage item.
As a preferred embodiment, when all coverage index data blocks in item i describe the identity of the object to be globally unique, the associated identity of the extended data block in ext is the same as the corresponding object identity in item i. After the system loads item i, a memory object is built for each coverage index data block, and when the ext file is loaded, the position information in the extended data block can be bound to the corresponding memory object according to the associated identity, and the bound memory object is unique. When it needs to be described, the identity of the object described by all the coverage index data blocks in item i is globally unique, and in the preferred embodiment of the first embodiment, the description is already detailed, and will not be repeated.
As a preferred embodiment, when all the design module identifiers in item i are globally unique, the index coverage area identifiers are unique under the same father node, and the coverage item identifiers are unique under the same father node, the associated identifiers corresponding to the design modules in the extension data block of ext are the same as the design module identifiers in item i, and the associated identifiers corresponding to the index coverage area and the coverage item are all path names of the corresponding object identifiers in item i respectively. The step of obtaining the full path name comprises the following steps: searching the data blocks of the target object under the design module in item i, and sequentially splicing object identities on the paths of the nodes where the data blocks of the target object are located, which are searched by the index coverage domain nodes, so as to obtain the full path names. As one example, one path to find "Id:1, name: STATE_ERROR" in item i by describing the identity and binding identity of an object is: "Id 1, name: curr_state1", "Id 2, name: UCIS: STATE", "Id 1, name: STATE_ERROR", wherein curr_state1 node and UCIS are both index overlay domain nodes, and STATE_ERROR is an overlay item node; then splicing the identity of each object in the path in turn to obtain the full path name in ext as follows: 1.2.1, i.e. the associated identity of the overlay item is 1.2.1. If the searched target object is 'Id: 2, name: UCIS: STATE', the association identity of the index coverage is 1.2. And so on. Alternatively, the object identity splice character may also employ other characters. Alternatively, the object id splice format may also take other formats. The setting of the associated identity enables the corresponding index coverage domain and the coverage item to have unique identity in the extension information file, and the purpose of binding the position information in the corresponding extension data block to the unique memory object can be achieved through the associated identity. When partial loading is carried out, corresponding design modules are loaded according to different design module identification marks, and the associated identification marks are unique in the same design module. It should be noted that, in item i, all the design module identifiers are globally unique, the index coverage area identifiers are unique under the same parent node, and the coverage item identifiers are unique under the same parent node, which are already described in detail in the preferred embodiment of embodiment one, and are not described in detail.
As a preferred embodiment, when all the design module identifiers in item i are globally unique, the identifiers corresponding to the index coverage domains are globally unique, and the identifiers of the coverage items are unique under the same father node, the associated identifiers corresponding to the design modules in the extension data block of ext are the same as the identifiers of the design modules in item i, the associated identifiers corresponding to the index coverage domains are the same as the identifiers of the index coverage domains in item i, and the associated identifiers corresponding to the coverage items comprise the identifiers of the coverage items in item i and the binding identifiers of the coverage items. Because the identity of the design module and the identity of the index coverage area are respectively globally unique, and the associated identity of the corresponding expansion data block is respectively the same as the identity of the design module and the identity of the coverage area, the position information in the expansion data block can be uniquely bound to the corresponding memory object. And the father-son relationship between the overlay item and the index overlay domain is reassigned in the extension information file through the overlay item identity and the overlay item binding identification, so that the purpose of uniquely binding the position information in the extension data block to the memory object through the overlay item identity and the overlay item binding identification is achieved. It should be noted that, in the item i, all the design module identifiers are globally unique, the identifiers corresponding to the index overlay domain are globally unique, and the overlay item identifiers are unique under the same father node, which are already described in detail in the preferred embodiment of the first embodiment and are not described again.
As a preferred embodiment, when the identity of all design modules is globally unique, the identity corresponding to the index coverage field is globally unique, and the identity of all coverage items is globally unique, and the extension data block of the coverage item is not included in the ext file, the associated identity of the extension data block in the ext is the same as the corresponding object identity in item i. It should be noted that, in the item i, the identity of all the design modules is globally unique, the identity corresponding to the index coverage domain is globally unique, and the identity of all the coverage items is globally unique, which are already described in detail in the preferred embodiment of the first embodiment and are not described in detail.
Optionally, when the module identity identifier in item i is globally unique, the index coverage area is globally unique, and the coverage item is globally unique, and the ext file includes the extension data block of the coverage item, the associated identity identifier corresponding to the design module is the same as the design module identity identifier in item i; the associated identity corresponding to the index coverage is the same as the index coverage identity in item i; the associated identity corresponding to the overlay item comprises an overlay item identity in item i and an overlay item type identity, wherein the type identity is used for distinguishing an overlay domain and an extended data block corresponding to the overlay item, and in this way, the position information in each extended data block can be uniquely bound with the memory object established by item i.
As a preferred embodiment, when the module identity identifier in item i is globally unique, the index coverage field is globally unique, and the coverage item is globally unique, and the ext file includes the extended data block of the coverage item, the associated identity identifier corresponding to the index coverage field includes the index coverage field identity identifier and the index coverage field type identifier in item i; the associated identity corresponding to the design module is the same as the identity of the design module in item i; the associated identity corresponding to the overlay item is the same as the overlay item identity in item i. In general, the number of the extended data blocks corresponding to the coverage item is relatively large, the number of the extended data blocks corresponding to the index coverage field is relatively small, and by adding the type identifier in the associated identity identifier corresponding to the index coverage field, a large amount of storage space can be saved relative to the coverage item, and the binding efficiency can be greatly improved.
Optionally, the location information of the object in the source file is rank location information of the object in the source file. As one example, when the object is a state of the FSM, then the location information is the start line number and end line number of the state in the source file.
Further, referring to fig. 3, when the computer program is executed by the processor, the following steps are implemented:
b100, reading the mapping file sdb and the index file indxf into the memory.
B200, acquiring a first target object designated by a user, wherein the first target object is a design module or an instance; and searching the sdb in the memory according to the first target object to obtain a design module identity mark rid m1 corresponding to the first target object. It should be noted that, the search process of the identity of the design module and the first target object are the same as those of the embodiment, and will not be described again.
B300, obtaining the index data block comprising rid m1 according to indxf, and obtaining the position information iline1 of the design module in item i and the position information eline2 of the design module in the extension information file in the index data block. Preferably, before acquiring the index data block including rid m1 according to indxf, the method further includes: and obtaining a coverage index file item i according to the coverage index metric i selected by the user.
And B400, loading the data blocks within iline range in item i to a memory, establishing a memory object and binding the identity of the object, and further loading the module specified by the user in item i to achieve the aim of partial loading.
And B500, loading the expansion data block in the eline range in the ext to a memory, binding the position information sline m of the object in the source file with the memory object according to the association identity in the expansion data block, and further loading the position information related to the module appointed by the user, thereby achieving the purpose of partial loading. When the coverage rate or the database is combined, the extension information file ext does not need to be loaded, so that the data volume to be loaded can be reduced, the occupied memory space is further reduced, and the loading efficiency can be improved.
And B600, searching the identity of the object bound by the memory object and the position information of the object in the source file according to the identity of the second target object designated by the user to obtain the position information of the second target object in the source file. The second target object is a memory object of the coverage item specified by the user. For example, it may be a state or state transition in the FSM.
And B700, positioning and visually displaying the second target object in the source file according to the position information of the second target object in the source file.
Specifically, a corresponding source file is opened according to the source file identity mark bound by the memory object, positioning is carried out in the source file according to the position information of the second target object in the source file, and the position of the second target object in the source file is visually displayed. Wherein, since the source file may be opened in the visual interface, the position of the second target object specified by the user in the source file is displayed, for example, the user specifies an overlay item that is an idle state in the FSM, and then a line of source code that is an idle state defined in the ext file is displayed in the visual interface. It should be noted that, in the item i file, the overlay domain data block of the design module includes the source file identity, and when the item i file is loaded, a memory object is established for each data block, and a hierarchical relationship is established through the object identity and the binding identity, so that the memory object corresponding to the overlay domain data block can obtain the binding source file identity by searching the father node. The location information of the source file identity is stored in a basic information file of the source file, where the basic information file of the source file is described in detail in the first embodiment, and will not be described again.
In summary, the third embodiment of the present invention provides a data visualization positioning system, which is configured to store structured data and location information in a coverage index file and an extension information file respectively, and cooperate with location information of a module stored in an index file in the coverage index file and location information of the module stored in the extension information file, so that not only can the purpose of accurately positioning a location in a source file according to user specification be achieved, but also only a corresponding design module needs to be loaded in a loading process, so that the amount of loaded data is reduced, and occupation of memory resources is reduced. Meanwhile, the structured data and the position information are respectively stored in the coverage index file and the extension information file, so that irrelevant extension information does not need to be loaded in the coverage index integration (merge) process, the loaded data volume is reduced, the waste of memory resources is reduced, and the loading efficiency is improved.
When the database is accessed according to the object specified by the user, the whole database file needs to be loaded when the database is in UCIS standard, and a large amount of redundant information irrelevant to the object specified by the user is included, so that the data loading is slow, and aiming at the technical problem, the invention provides the fourth embodiment, the fifth embodiment and the sixth embodiment.
Example IV
A fourth embodiment provides a database partial loading system comprising a database, a processor and a memory storing a computer program, the database comprising a mapping file sdb, an index file metrindex and a target file.
Further, the sdb includes a design module, a design module identity, an instance, and a mapping relationship between instance identities. The mapping file sdb is the same as that in the second embodiment, and will not be described again.
Further, metrindex includes that the N index files {metrindex1,metrindex2,…,metrindexg,…,metrindexN},metrindexg classified according to the coverage index are index files of g-th coverage index metric g, and the value range of g is 1 to N; metrindex g includes M1 design module index data blocks pos, pos= { pos 1,pos2,…,posr,…,posR},posr is the R-th design module index data block, and the value range of R is 1 to R; pos r includes the design module identification information rid r of the r design module and the position information loc r of the r design module in the target file; the value range of the identity information rid f≠ridr of the design module of the f-th index data block pos f is 1 to R, and f is not equal to R.
The type of the coverage index (metric) includes a conditional coverage index, a line coverage index, an assertion coverage index, or a finite state machine coverage index, a flip coverage index, or a function coverage index, etc.
Further, referring to fig. 4, the following steps are implemented when the computer program is executed by the processor:
C100, when the user selects partial loading, the map file sdb and index file metrindex are loaded.
And C200, acquiring the coverage index type meta g and the design module identity rid r specified by the user according to the first target object specified by the user.
Optionally, searching the sdb according to the first target object to obtain the identity of the design module of the target design module. Optionally, the first target object is a design module or an instance. It should be noted that, when the object specified by the user is a design module or an instance, the method for obtaining the identity of the design module is already described in detail in step a300 of the second embodiment, which is not described in detail.
C300, searching all index files in metrindex according to the meta g to obtain an index file metrindex g of the meta g.
And C400, searching the design module index data block in metrindex g according to the design module identity mark rid r of the target design module to obtain target position information loc r of the target design module in the target file.
Optionally, a standard interface function is invoked, and the entry parameters of the standard interface function include the identity of the design module and the first target object, and the target location information acquired by the query is returned. Wherein the standard interface function meets UCIS standard.
Optionally, the target file is an overlay index file, or an overlay index file and an extension information file.
Optionally, when the target file is a coverage index file, each coverage index data block in the coverage index file includes a design module identity and position information of the design module in the source file; loc r is the position information of the r design module in the coverage index file. As one example, when the design module is in the coverage index file with a line range of 3 to 13 lines, the location information in the design module index data block includes two key-value pairs, one key is the start line and the key-value is 3, and the other key is the end line and the key-value is 13. It should be noted that, when the target file is the coverage index file, the coverage index file is the same as that in the second embodiment, and the coverage index file is already described in detail in the second embodiment and is not described again.
It should be noted that, the location information of the design module in the source file is not equal to the location information of the design module in the coverage index file. The source file is a code source file, the coverage index file is in a text format or a binary format, and data blocks of a plurality of objects are defined in the coverage index file, wherein each data block comprises structural information and position information of the corresponding object in the source file. The position information of the design module in the coverage index refers to the row range of the data blocks corresponding to all nodes taking the design module as a father node in the tree structure in the coverage index file.
Optionally, when the target file is a coverage index file and an extension information file, each coverage index data block in the coverage index file includes a design module identity, and each extension information data block in the extension information file includes an associated identity and position information of the object in the source file; loc r is the position information of the r design module in the coverage index file and the extension information file, respectively. As an example, when the line range of the design module in the coverage index file is 3 to 13 lines and the line range in the extension information file is also 3 to 13 lines, the location information in the design module index data block includes four key value pairs, respectively: the start line and key value in the overlay index file is 3, the end line and key value in the overlay index file is 13, the start line and key value in the extension information file is 3, and the end line and key value in the extension information file is 13. It should be noted that, when the target file is the coverage index file and the extension information file, the coverage index file and the extension information file are the same as those in the third embodiment, and will not be described again. Compared with the mode that all the position information and the structured information are placed in the same data block, the position information and the structured information are placed in two different files, so that the position information and the structured information can be loaded according to the needs, the position information does not need to be loaded when the coverage rate needs to be calculated, the loading data quantity is reduced, the loading efficiency is improved, and meanwhile, the memory load is reduced.
And C500, loading the data blocks in the target file within the range of the target position information loc r into the memory.
Optionally, the target file is an overlay index file or an extension file.
As a preferred embodiment, loc r includes a line number of a start line and a line number of a stop line when the target file is in text format. It should be noted that the line number of the start line and the line number of the end line are both in the form of key value pairs in loc r.
As a preferred embodiment, loc r includes a start position offset and a data length when the target file is in binary format. It should be noted that the start position offset and the data length are both in the form of key value pairs in loc r.
In summary, the fourth embodiment provides a system for loading a database portion, which configures the position of each design module in the target file in the index file indxf corresponding to different coverage indexes, so that when a user designates a corresponding design module or instance, the user can quickly obtain the position range of the corresponding design module in the target file through the index file corresponding to the corresponding coverage index, and further load the data block in the position range, and the purpose of partial loading is achieved through the cooperation between the index file and the coverage index file, so that the data volume loaded is greatly reduced, and the technical problem of slow data loading when the user accesses the database according to the designated object is solved. Meanwhile, the corresponding position information is stored according to the coverage index classification, so that the whole data size of the index file is reduced, and the technical problem of large data size and slow loading of the index file is solved.
Example five
A fifth embodiment provides a target file partial loading system comprising a database, a processor and a memory storing a computer program, the database comprising a map file sdb, an index file modidx and a target file.
Further, the sdb includes a design module, a design module identity, an instance, and a mapping relationship between instance identities. The mapping file sdb is the same as that in the second embodiment, and will not be described again.
Further, modidx includes M1 index modules { modidx 1,modidx2,…,modidxm1,…,modidxM1},modidxm1 is the M1 st index module, and the value range of M1 is 1 to M1; modidx m1 includes a design module identity id m1 and N1 coverage index groups metridx,metridx={metridx1,metridx2,…,metridxn1,…,metridxN1},metridxn1 are the N1 th coverage index group, and the value range of N1 is 1 to N1; metridx n1 includes the coverage index type and the location information lloc n1 of the module in the target file, where the f1 st index module modidx f1 has a module id rid f1≠ridm1, where the value of f ranges from 1 to M1 and f is not equal to M.
It should be noted that, in the first embodiment, the coverage index type is already described in detail and will not be described again.
Optionally, when the target file is an overlay index file, the location information lloc n1 is line range information of the design module in the overlay index file. It should be noted that, the coverage index file is the same as that in the second embodiment, and will not be described again.
Optionally, when the target file is the coverage index file and the extension information file, the location information in the index data block of the design module is row range information of the corresponding design module in the coverage index file and the extension information file respectively. It should be noted that, the coverage index file and the extension information file are the same as those in the third embodiment, and will not be described again.
As an example, taking the target file as an overlay index file, the target file is divided into different index modules according to the module identification in the same index file. modidx m1 includes { rid:5, "FSM": { Start:1, end:12}, COND: { Start:13, end:25} … }, where "rid:5" is the module identity of 5, FSM and COND are the overlay index types, respectively, "Start:1, end:12" is the line range of the design module with module identity of 5 in the overlay index file. Wherein COND is a conditional coverage index.
Further, referring to fig. 5, when the computer program is executed by the processor, the following steps are implemented:
d100, when the user selects the partial load, the map file sdb and the index file modidx are loaded.
The map1 comprises the map1 of Q1 first map1 and the map2 of Q2 second map1, and the map1 comprises the map between Q1 design modules and the identity of the design modules; map2 includes the mapping between Q2 instances, instance identities, and design module identities. Note that, in the fifth embodiment, the sdb is the same as the sdb in the second embodiment, and will not be described again.
And D200, acquiring a first target object designated by a user, and searching for the sdb to obtain a module identity mark rid m1. Wherein the first target object is a module or instance. Optionally, when the first target object is an instance, acquiring the module identity according to map 2; and when the first target object is a module, acquiring the module identity according to the map 1.
And D300, searching modidx according to the module identity mark rid m1 and the first target object to obtain the position information lloc n1 of the first target object in the target file, which is designated by the user.
Optionally, D300 further includes:
And D310, searching modidx according to the module identity mark rid m1 to obtain a target index module modidx m1.
And D320, searching metridx in modidx m1 to obtain metridx n1 according to the coverage index type of the first target object. It should be noted that, in the first embodiment, the coverage index type is already described in detail, and will not be described again. The first target object specified by the user is a memory object, and related attributes of the object are already bound in the memory of the system, wherein the related attributes comprise the coverage index type.
Optionally, the step of searching modidx in D300 further includes: and calling UCIS a standard query interface function, wherein the entry parameters of the query interface function comprise a module identity rid m1 and a first target object, and returning target position information lloc n1 acquired by query.
And D330, obtaining the position information lloc n1 of the first target object in the target file according to metridx n1.
As a preferred embodiment, lloc n1 includes a line number of the start line and a line number of the end line when the target file is in text format. It should be noted that, the line number of the start line and the line number of the end line are both in the form of key value pairs in lloc n1.
As a preferred embodiment, lloc n1 includes a start position offset and a data length when the target file is in binary format. It should be noted that the initial position offset and the data length are shown in lloc n1 as key-value pairs.
And D400, loading the data blocks in the target file within the range of the position information lloc n1 into the memory.
In summary, the fifth embodiment provides a database partial loading system, by loading an index file modidx, configuring the position of the corresponding coverage index in the target file for each design module by using the design module identity basic unit in the index file, only occupying one IO interface during loading, enabling a user to quickly acquire the position range of the corresponding design module in the target file when designating the corresponding design module or instance, further loading the data block in the position range, achieving the purpose of partial loading by matching the index file and the coverage index file, greatly reducing the data volume loaded, and solving the technical problem of slow data loading when accessing the database according to the designated object of the user. Only one file is needed to be searched during searching, and the searching efficiency is high. And according to the classification of the identity of the design module, the coverage index groups with the identity of the same design module can share the identity of the same design module, so that a large amount of the same information stored in the index file is reduced, and the technical problem of large data volume and slow loading in the index file is solved.
Example six
Referring to fig. 6, a sixth embodiment provides a method for partially loading a target file, the method including the following steps:
E100, loading the mapping file sdb and the index file mmetrindex when the user selects partial loading; the sdb comprises a design module, a design module identity, an instance and a mapping relation among instance identities.
It should be noted that, the mapping file sdb is the same as that in the second embodiment, and will not be described again.
Wherein mmetrindex includes N coverage index units {mmetrindex1,mmetrindex2,…,mmetrindexn1,…,mmetrindexN},mmetrindexn1, N1 st coverage index unit, N1 has a value range of 1 to N; mmetrindex n1 includes a coverage index type and N1 module information groups { modx 1,modx2,…,modxn1,…,modxN1},modxn1 is the N1 st module information group, and the value range of N1 is 1 to N1; modx n1 includes a module id m1 and position information mloc n1 of the design module in the target file, where the f1 st module id f1≠ridm1 of the module information group modx f1 has a value range of f1 from 1 to N1 and f1 noteq m1. The coverage indicator type is described in detail in the first embodiment, and will not be described again.
It should be noted that, in the sixth embodiment of the present invention, the index file mmetrindex is a file, and only one IO interface is occupied when the index file is loaded. The index file is divided into a plurality of different index units by the type of the coverage index.
Optionally, when the target file is an overlay index file, the location information lloc n1 is line range information of the design module in the overlay index file. It should be noted that, the coverage index file is the same as that in the second embodiment, and will not be described again.
Optionally, when the target file is the coverage index file and the extension information file, the location information in the index data block of the design module includes row range information of the design module in the coverage index file and the extension information file, respectively. As a preferred embodiment, when ext i is a file corresponding to the conditional coverage index, expanding key value pairs of conditions and parameters in the data block, where a key in the key value pair of conditions is a conditional name and a key value is a condition; the keys in the parameter key value pair are named parameters, and the key value is an array of a plurality of parameters. It should be noted that, the coverage index file and the extension information file are the same as those in the third embodiment, and will not be described again.
As an example, taking the target file as the coverage index file, four coverage index units are included in the same index file, which are a first coverage index unit corresponding to the conditional coverage index, a second coverage index unit corresponding to the line coverage index, a third coverage index unit corresponding to the asserted coverage index, and a fourth coverage index unit corresponding to the finite state machine coverage index. The fourth coverage index unit comprises { "FSM" [ { rid:5, start:1, end:12}, { rid:6, start:13, end:25} … }, where FSM is the coverage index type, "rid:5" is the module identity of 5, where "start:1, end:12" is the row range of the design module with the module identity of 5 in the coverage index file.
And E200, obtaining a module identity mark rid m1 and a coverage index type according to the first target object specified by the user. It should be noted that the first target object is a design module or an instance. The first target object designated by the user is a memory object, and the identity, the type identifier, the name, the father node information and the like of the object are bound on the first target object.
And E300, searching the index file mmetrindex according to the module identity mark rid m1 and the coverage index type to obtain target position information mloc n1 of the design module specified by the user in the target file. It should be noted that, the object file includes a plurality of data blocks of the design modules, the data blocks in the starting line and the ending line of each design module belong to the same data block, and the data blocks are continuously adjacent to each other.
And E400, loading the data blocks in the target file within the range of the target position information mloc n1. Namely, only the module corresponding to the first target object designated by the user is loaded, other modules are not loaded, the purpose of partial loading is achieved, the data volume of loading is reduced, the loading efficiency is improved, and meanwhile, the space occupied by the memory is reduced.
As a preferred embodiment, mloc n1 includes a line number of the start line and a line number of the end line when the target file is in text format. It should be noted that, the line number of the start line and the line number of the end line are both in the form of key value pairs in mloc n1.
As a preferred embodiment, mloc n1 includes a start position offset and a data length when the target file is in binary format. It should be noted that the initial position offset and the data length are shown in mloc n1 as key-value pairs.
In summary, the embodiment of the present invention provides a method for partially loading a target file, by loading an index file mmetrindex, where each type of coverage index in the index file is an index unit, each index unit includes N1 module information groups based on the identity of a design module as a grouping basis, when loading the index file, only one index file needs to be loaded, and when a user designates a design module or an instance, a position range of the design module in the target file can be quickly obtained, so that a data block in the position range is loaded when loading, and by matching between the index file and the coverage index file, the purpose of partial loading is achieved, the loaded data volume is greatly reduced, and the technical problem of slow data loading when accessing a database according to the user-designated object is solved. Only one index file needs to be loaded during loading, the occupation of an IO interface is small, and the searching efficiency is high; meanwhile, a large amount of identical information stored in the index file is reduced, and the technical problem of large data volume and slow loading in the index file is solved.
Because the standard UCIS database is adopted, the coverage status data obtained by the user when executing the test case once is required to be updated into the UCIS standard database, namely, the database file is required to be read into the memory and updated once when executing one test case, a large amount of memory resources are occupied, and the structured data of the coverage index is easy to tamper, so that the invention provides an embodiment seven and an embodiment eight for solving the problems.
Example seven
An embodiment seven provides a coverage rate storage system, where the system includes a database, a processor, and a memory storing a computer program, where the database includes N types of coverage indicators, where an h coverage rate data file fdat h in N coverage data files fdat and fdat corresponding to the N types of coverage indicators respectively includes: coverage data block inst h={insth,1,insth,2,…,insth,t,…,insth,T of T instances, where inst h,t is the coverage data block of the T th instance, and the value range of T is 1 to T; wherein inst h,t includes instance identity instid h,t, full path name instNa h,t of instance, and overlay data h,t,datah,t, the binary number including overlay item type identifier itype h,t, sum h,t of number of all overlay items, and overlay value field Val h,t,Valh,t is equal to Sum h,t, and each binary corresponds to an overlay state identifier of an overlay item. After compiling the source file to obtain a coverage index file, when a user tests coverage rates of different coverage indexes by using a test case, corresponding coverage data are generated; the coverage data is classified according to the types of the coverage indexes, the coverage data corresponding to one type of coverage indexes is stored in each coverage data file, the aim of separating and storing the compiled coverage index structured data from the tested coverage data is fulfilled, the compiled coverage index structured data is prevented from being damaged, and meanwhile, the problem that the compiled data is frequently overloaded due to the fact that the compiled data and the test data are put into the same file in the UCIS standard is solved.
Each instance has a unique identity, that is, the identity of the same instance is the same in the same coverage data file or different coverage data files, and the identities of different instances are different. The identity of the instance is used to associate the coverage indicator in the data block to which it belongs with the module data block in the coverage indicator file, so as to calculate the coverage rate of the corresponding module.
Wherein the full path name instNa h,t of the instance conforms to the file naming format in the UCIS standard. Wherein inst h,t also includes global identification Sig h,t of the block of module data. Wherein the global identities of the data blocks belonging to the same module are identical. The overlay item type identifier is used for indicating the type of the current overlay data in the tree structure of the overlay index, and in UCIS standards, the overlay item type can indicate the overlay index and the overlay item to which the current overlay data belongs because the overlay item type identifiers in the tree structures of different overlay indexes are different. In the binary data of the coverage value, 0 indicates that the corresponding coverage item is not covered by the test case, and 1 indicates that the corresponding coverage item is covered by the test case. The number of coverage items is used to represent the number of all coverage items covered by the current coverage data, including all coverage items to be tested, including all coverage items that are uncovered and covered. The coverage data can be represented by three fields, so that the coverage state of the memory object established in each data block in the item file can be accurately represented.
Further, referring to fig. 7, the database further includes a mapping file sdb, an index file, and an coverage index file, and when the computer program is executed by the processor, the following steps are implemented:
And F100, loading a mapping file sdb and an index file, wherein the sdb comprises a design module, a design module identity, an instance and a mapping relation between instance identities.
Optionally, when the coverage data block in the coverage index file includes the identity of the design module and the location information of the module in the source file, the index data in the index file includes the identity of the design module, the coverage index, and the location information of the design module in the coverage index file. It should be noted that, the coverage index file and the index file in this embodiment are already described in detail in the second embodiment, and will not be described again.
Optionally, when the coverage rate data block in the coverage index file includes the identity of the design module, and does not include the location information; the index data block in the index file comprises a module identity, a coverage index, position information of the design module in the coverage index file and position information of the design module in the extension information file. It should be noted that, the coverage index file and the index file in this embodiment are already described in detail in the third embodiment, and will not be described again. Because the coverage index file does not comprise the position information of the object in the source file, and the position of the object in the source file does not need to be positioned when the association between the coverage index file and the coverage data is established, the loading of the extension information file is not needed, the loaded data volume can be reduced, the consumption of memory resources is reduced, and the loading efficiency is improved.
And F200, loading a coverage data file fdat h, and establishing a one-to-one association relation between the coverage value data in all coverage data blocks in fdat h and the coverage item data blocks in the coverage index file. And after the association relation between the coverage value data and the coverage item is established, the whole coverage rate is convenient to calculate.
The establishing step of the association relation of inst h,t comprises the following steps:
F210, obtaining the instance identity instid h,t of inst h,t.
And F220, searching a design module identity mark rid m1 forming a mapping relation with instid h,t in the sdb.
And F230, searching a target position range of the design module corresponding to the rid m1 in the coverage index file in the index file. Wherein prior to searching the index file, further comprises: and acquiring the coverage index type according to the coverage item type identifier itype h,t, and searching the index file according to the coverage index type and rid m1 to obtain the position range. It should be noted that, in the UCIS standard, the overlay item type identifier is globally unique, and the corresponding overlay index type can be obtained after the overlay item type identifier is obtained.
And F240, acquiring a target coverage item data block with the coverage item type identifier itype h,t in the target position range in the coverage index file.
F250, associating Val h,t in inst h,t with the target overlay item data block. Specifically, val h,t needs to be converted into binary data, and each binary bit is sequentially associated with the target coverage item data block.
Optionally, when Val h,t is binary data, each binary bit corresponds to an overlay state identifier of an overlay item.
As a preferred embodiment, when Val h,t is hexadecimal data, val h,t is converted into binary data, and each binary bit corresponds to an overlay state identification of an overlay item.
In summary, the seventh embodiment of the present invention provides a coverage rate storage system, where when coverage rate data is stored, the coverage rate storage system stores a coverage value in the coverage rate data, establishes a mapping relationship among a coverage item type identifier, the number of coverage items, and a coverage value field, and determines, through the coverage rate and the coverage number, which bits of valid data are in the coverage rate and the coverage status of each bit, where the coverage type identifier explicitly indicates a coverage index to which the current coverage rate belongs; and the coverage rate data block also comprises an instance identity, and the corresponding design module identity can be uniquely determined through the instance identity, so that the coverage rate can be calculated by establishing the association relationship between the coverage index file and the coverage data file, and the technical problem that the whole standard UCIS database needs to be reloaded and updated every time the test case is executed is solved.
Example eight
Referring to fig. 8, an eighth embodiment provides a coverage rate obtaining method, which includes the steps of:
G200, obtaining an h coverage data file fdat h, wherein fdat h includes: the coverage data block inst h,t of the T-th instance of the coverage data blocks inst h,insth of the T instances includes an instance identity instid h,t and the coverage data h,t,datah,t includes a coverage item type identity itype h,t, a field Sum h,t of the number of all coverage items, and a binary number of coverage value field Val h,t,Valh,t equal to Sum h,t, and each binary corresponds to a coverage status identity of one coverage item.
And G400, searching a mapping file sdb according to instid h,t, wherein the sdb comprises a mapping relation between the module identity and the instance identity, and acquiring instid h,t a module identity rid m1 corresponding to the module identity.
G600, according to itype h,t, get the coverage index type of data h,t.
G800, acquiring an i-th type coverage index file item i according to the coverage index type of data h,t, wherein a coverage item type identifier and an index identifier are further included in a coverage item data block in item i, and the index identifier in the coverage item data block belonging to the same father node is unique. Wherein the index identification is unique under the same father node, which means that the index identifications are independently numbered and are different from each other under the father node. The item i file is already described in detail in the first embodiment and will not be described in detail.
And G1000, searching item i according to itype h,t to obtain all target coverage item data blocks.
And G1200, sequentially taking out the coverage state identification corresponding to each data block from the data h,t according to the index identification in the target coverage item data block. The function of the index identifier is equivalent to the offset in the coverage value data, so that the corresponding coverage state identifier can be quickly bound into the corresponding target data block, and the parent node can be quickly searched during searching. Compared with a method for arranging and searching according to the identity of the coverage item data block, the searching efficiency is improved. It should be noted that, because the index identifier of the overlay item data block under each parent node is unique, the number of parent nodes determines that the data h,t is divided into several segments, and each segment corresponds to the index overlay domain of one parent node.
And G1400, calculating coverage rate according to the coverage state identification of each data block. After binding the coverage status data into the coverage item data blocks in the coverage index file item i, the overall coverage rate is calculated according to the coverage status of each coverage item data block.
As a preferred embodiment, the item i does not include extension information for display on a graphical user interface. Optionally, the extension information is location information of the object in the source file. Optionally, when item i is a condition to cover the index file, the extension information is a key value pair of a condition and a parameter, and location information of an object in the source file. By the method, the data volume loaded can be further reduced, related data irrelevant to the calculation coverage rate is not loaded, wherein the expansion information can be stored in an expansion information file, and the third embodiment has detailed description of related embodiments and is not repeated.
As a preferred embodiment, the inst h,t also includes the full path name instNa h,t of the instance.
The invention can also load the coverage index file in a partial loading mode so as to reduce the loaded data quantity and reduce the occupation of memory resources. Methods of partial loading include, but are not limited to, the following three ways:
the first way, before G1000, further includes:
The G900, a target design module corresponding to the design module identity rid m1 in the partially loaded item i, includes:
g910, searching index files of all the coverage index files according to the coverage index type of the data h,t to obtain target index files, wherein the index files are classified according to the coverage index, and each index file comprises design module identity information and position information of the design module identity information in the coverage index file.
And G920, searching a design module index data block in the target index file according to the design module identity mark rid m1 to obtain target position information of the target design module in item i.
And G930, loading the data blocks in the item i within the target position information range into a memory.
It should be noted that, in the fourth embodiment, related embodiments have been described in detail, and will not be described in detail.
In a second manner, the G1000 further includes:
The G900, a target design module corresponding to the design module identity rid m1 in the partially loaded item i, includes:
G901, searching an index file according to the module identity mark rid m1 to obtain a target index module; the index file comprises M1 index modules, each index module comprises a design module identity and N1 coverage index groups grouped according to the coverage index, and each coverage index group comprises the type of the coverage index and the position information of the design module in the coverage index file.
And G902, searching the coverage index group in the target index module according to the coverage index type of the data h,t to obtain a target coverage index group.
And G903, obtaining target position information of the target design module in item i according to the target coverage index set.
And G904, loading the data blocks in the item i within the target position information range into a memory.
It should be noted that, in the fifth embodiment, related embodiments have been described in detail, and will not be described in detail.
In a third manner, the G1000 further includes:
The G900, a target design module corresponding to the design module identity rid m1 in the partially loaded item i, includes:
G9001, searching an index file according to the coverage index types of the module identity marks rid m1 and data h,t to obtain target position information of a target design module in item i; the index file comprises N coverage index units divided according to the types of the coverage indexes, the coverage index units comprise the types of the coverage indexes and N1 module information groups divided according to the identities of the design modules, and the module information groups comprise the identities of the design modules and the position information of the design modules in the coverage index file.
G9002 loads data blocks in item i that are within the range of target location information mloc n1.
It should be noted that, in the sixth embodiment, related embodiments have been described in detail, and will not be described in detail.
As a preferred embodiment, before G1200, further includes:
G1101, obtaining a plurality of father nodes to which all target coverage item data blocks in item i belong.
G1102, dividing the target coverage item data blocks belonging to the same parent node into the same data group.
G1103 orders the data groups in the order in which the parent nodes appear in item i.
As a preferred embodiment, when Val h,t is hexadecimal data, val h,t is converted into binary data, and each binary bit corresponds to an overlay state identification of an overlay item.
In summary, according to the embodiment of the invention, the coverage status identifier is accurately obtained from the coverage data block of the coverage data file through the index identifier configured by the coverage index file, and the coverage is calculated according to the coverage status identifier, so that not only the structured data and the coverage data of the coverage index can be stored separately, but also the separately stored structured data and the coverage data can be accurately associated to calculate the coverage, and only the coverage data file is required to be updated instead of all files in the whole database when each test case is executed, thereby solving the technical problem that the whole standard UCIS database is required to be reloaded and updated when each test case is executed.

Claims (10)

1. A database partial loading system, the system comprising a database, a processor and a memory storing a computer program, the database comprising a mapping file sdb, an index file metrindex and a target file, wherein:
the sdb comprises a design module, a design module identity, an instance and a mapping relation among instance identities;
metrindex includes N index files {metrindex1,metrindex2,…,metrindexg,…,metrindexN},metrindexg classified according to the coverage index as index files of the g-th coverage index type metric g, where the value of g ranges from 1 to N; metrindex g includes R design module index data blocks pos, pos= { pos 1,pos2,…,posr,…,posR},posr is the R design module index data block, and the value range of R is 1 to R; pos r includes the design module identity rid r of the r design module and the target position information loc r of the r design module in the target file; the f-th design module index data block pos f is provided with a design module identity mark rid f≠ridr, the value range of f is 1 to R, and f is not equal to R;
When the computer program is executed by a processor, the following steps are implemented:
c100, when the user selects partial loading, loading the mapping file sdb and the index file metrindex;
c200, acquiring a coverage index type meta g specified by a user and a design module identity rid r according to a first target object specified by the user;
C300, searching all index files in metrindex according to the meta g to obtain an index file metrindex g of the meta g;
C400, searching the design module index data block in metrindex g according to the design module identity mark rid r of the target design module to obtain target position information loc r of the target design module in the target file;
And C500, loading the data blocks within the range of the target position information loc r in the target file to the memory.
2. The system of claim 1, wherein the target file is an overlay index file, each overlay index data block in the overlay index file comprising a design module identity and design module location information in the source file.
3. The system of claim 2, wherein loc r is the location information of the r-th design module in the coverage index file.
4. The system of claim 1, wherein the target file is an overlay index file and an extension information file, each overlay index data block in the overlay index file includes a design module identity, and each extension information data block in the extension information file includes an associated identity and location information of the object in the source file.
5. The system of claim 4, wherein loc r is the location information of the r-th design module in the coverage index file and the extension information file, respectively.
6. The system of claim 1, wherein loc r includes a line number of a start line and a line number of a stop line of the r-th design module in the object file when the object file is in a text format.
7. The system of claim 1, wherein loc r includes a start position offset and a data length of the r-th design module in the target file when the target file is in a binary format.
8. The system of claim 1, wherein the design module identity and the instance identity in the sdb are globally unique.
9. The system of claim 1, wherein the type of coverage indicator comprises a conditional coverage indicator, a row coverage indicator, an assertion coverage indicator, a finite state machine coverage indicator, a flip coverage indicator, or a function coverage indicator.
10. The system of claim 1, wherein the first user-specified target object is a design module or instance.
CN202310597923.9A 2023-05-25 2023-05-25 Database partial loading system Active CN116820602B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310597923.9A CN116820602B (en) 2023-05-25 2023-05-25 Database partial loading system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310597923.9A CN116820602B (en) 2023-05-25 2023-05-25 Database partial loading system

Publications (2)

Publication Number Publication Date
CN116820602A CN116820602A (en) 2023-09-29
CN116820602B true CN116820602B (en) 2024-04-26

Family

ID=88140224

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310597923.9A Active CN116820602B (en) 2023-05-25 2023-05-25 Database partial loading system

Country Status (1)

Country Link
CN (1) CN116820602B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118035519B (en) * 2024-04-12 2024-06-21 成都融见软件科技有限公司 Classification searching method, electronic equipment and storage medium

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292795B1 (en) * 1998-05-30 2001-09-18 International Business Machines Corporation Indexed file system and a method and a mechanism for accessing data records from such a system
CN112306957A (en) * 2019-07-30 2021-02-02 华为技术有限公司 Method and device for acquiring index node number, computing equipment and storage medium
CN113051181A (en) * 2021-04-30 2021-06-29 腾讯科技(深圳)有限公司 Method, device, equipment and storage medium for determining incremental test coverage information
CN115203004A (en) * 2021-04-08 2022-10-18 北京字节跳动网络技术有限公司 Code coverage rate testing method and device, storage medium and electronic equipment
CN115237853A (en) * 2021-04-22 2022-10-25 腾讯科技(深圳)有限公司 Data query method and device, electronic equipment and storage medium

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292795B1 (en) * 1998-05-30 2001-09-18 International Business Machines Corporation Indexed file system and a method and a mechanism for accessing data records from such a system
CN112306957A (en) * 2019-07-30 2021-02-02 华为技术有限公司 Method and device for acquiring index node number, computing equipment and storage medium
CN115203004A (en) * 2021-04-08 2022-10-18 北京字节跳动网络技术有限公司 Code coverage rate testing method and device, storage medium and electronic equipment
CN115237853A (en) * 2021-04-22 2022-10-25 腾讯科技(深圳)有限公司 Data query method and device, electronic equipment and storage medium
CN113051181A (en) * 2021-04-30 2021-06-29 腾讯科技(深圳)有限公司 Method, device, equipment and storage medium for determining incremental test coverage information

Also Published As

Publication number Publication date
CN116820602A (en) 2023-09-29

Similar Documents

Publication Publication Date Title
CN116627972B (en) Structured data discrete storage system for covering index
CN116627568B (en) Visual positioning system of data
CN116820602B (en) Database partial loading system
CN116610383B (en) Method for partially loading target file
CN116627973B (en) Data positioning system
CN116627974B (en) Coverage rate storage system
JP6530829B2 (en) Data multidimensional model generation system and data multidimensional model generation method
US20050010606A1 (en) Data organization for database optimization
CN108388640B (en) Data conversion method and device and data processing system
CN110716539B (en) Fault diagnosis and analysis method and device
US20220076151A1 (en) Computer-implemented system and method having a digital twin and a graph-based structure
Czerepicki Application of graph databases for transport purposes
CN115857469A (en) Industrial equipment fault knowledge base construction method and device and fault diagnosis method and system
CN114168705B (en) Chinese address matching method based on address element index
CN114238085A (en) Interface testing method and device, computer equipment and storage medium
CN116954745B (en) Target file partial loading system
CN116610577B (en) Coverage rate acquisition method
CN109522311A (en) Date storage method, device, server and storage medium
CN116775431A (en) Automatic driving application calculation performance measurement method, device, equipment and storage medium
CN113704491B (en) Road office configuration file error proofing system based on domain knowledge graph
US20190354459A1 (en) Method and apparatus for tracing common cause failure in integrated drawing
Gür et al. Multidimensional Enrichment of Spatial RDF Data for SOLAP--Full Version
Zeng et al. Efficient xml keyword search: from graph model to tree model
CA2118358C (en) Method for mapping between object-oriented models and relational models, or between two object models
Nordin et al. Modular lazy search for constraint satisfaction problems

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant