Processing method and system supporting user customized data

Abstract

The invention relates to the technical field of customized data processing, and provides a processing method for supporting user customized data, which comprises the following steps: S1, defining a special flag bit system and user configuration, defining a universal special flag bit system specification, and providing a user configuration interface at the same time; s2, generating user customized data, and embedding a standard special flag bit in the data by a user according to a customized data format to indicate an organization structure, a field meaning and a data type of the data; s3, carrying out customized data analysis and processing, loading a user format definition file, analyzing and generating a format description model, loading customized data, identifying a special flag bit in the customized data, analyzing data contents in combination with the format description model, and mapping the data contents to an internal data structure of the tool; and S4, feedback and verification are carried out, and the EDA tool verifies the analysis process and result. Through combination of the special flag bit and the user format definition file, data format individuation requirements of different clients and projects can be flexibly met.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of customized data processing, and in particular to a processing method and system supporting user customized data. BACKGROUND

[0002] In the field of development and application of electronic design automation (EDA) tools, data is a key element supporting the realization of core functions of the tool, and its role runs through the core process of tool operation. Not only does it need to accurately define key information such as instances, biases, data values, etc. in the model, but it is also the basic prerequisite for a series of core operations such as model verification, logic simulation, performance analysis, etc. of EDA tools. Without compliant and effective data support, EDA tools will not be able to accurately process and analyze electronic design models, thereby affecting the efficiency and quality of the entire electronic design process.

[0003] Under the existing technical system, traditional EDA tools generally adopt a "fixed data format" processing mode, i.e. the tool can only recognize and parse a single or limited number of preset data formats. This mode has certain applicability in the early stage of EDA tool development and in the relatively single industry demand scenario. However, with the rapid development of the electronic design industry, the data processing needs of EDA tools by enterprises in different fields and of different sizes show significant differentiation characteristics: from the perspective of customer groups, customers in different industries (such as consumer electronics, automotive electronics, aerospace electronics) have different requirements for the content composition (such as whether to include design parameters specific to a particular field) and organization method (such as data level division logic) of data due to differences in functional requirements and performance indicators of design objects. Even within the same industry, different customers will have individualized needs for the focus of data (such as compatibility of data for some customers, and simplicity of data for some customers) and the interaction method (such as data interface protocol, transmission format) of data with subsequent self-developed tools or third-party tools due to differences in internal design specifications and technical accumulation. Even the same customer will have differentiated demands for data formats in different projects due to differences in chip architecture and design complexity involved in the projects. For example, some customers need to add specific "noise coefficient tags" and "temperature coefficient attribute definitions" to the data when designing high-precision analog circuits, but the fixed data format of traditional EDA tools cannot support the bearing and analysis of such customized information, resulting in a compatibility fault between data and tools.

[0004] To solve the above adaptation problem, the prior art often uses a "customized development" scheme, that is, a special data analysis module and processing module are developed for each customer's special needs. However, this scheme has many drawbacks: first, the development cost is high, and designing modules for each requirement requires a large amount of research and development manpower and time, and the compatibility design between modules further increases the development difficulty; second, the maintenance complexity increases dramatically, as the number of customized modules increases, subsequent version updates and bug fixes need to be carried out for different modules, which can easily cause a chain reaction; third, the tool versatility and flexibility are severely limited, and the customized module is only suitable for a specific customer or scenario, which prevents the EDA tool from being quickly expanded to a wider user group; fourth, the market response capability is insufficient, when customers propose new data format requirements or market demand changes, the development process needs to be restarted, which cannot achieve rapid iteration and thus misses market opportunities.

[0005] In summary, how to break through the limitations of traditional fixed data formats and provide a technical mechanism with flexibility, efficiency and versatility, which can allow users to customize data formats according to their actual business needs and ensure that the EDA tool can accurately identify these customized format data and complete efficient parsing and subsequent processing, has become a core technical problem in the current EDA tool technical field that needs to be solved.

[0006] From the perspective of application scenario adaptation, the above technical problem is not limited to a specific link of the EDA tool, but exists in all processes that need to process data, including but not limited to model import, parameter configuration, result output, etc. Especially in scenarios where the customer group is complex (such as serving multiple industry customers), the project demand is significantly different (such as handling different types of design projects in the same time period), and the data format needs to be frequently adjusted to adapt to different tool chains (such as integration with upstream and downstream simulation tools and layout design tools), the technical problem is more prominent, and the practical necessity and urgency of solving the above technical needs are further improved. SUMMARY

[0007] To solve the above problem, the purpose of the present application is to provide a processing method and system supporting user customized data, which can flexibly meet the individualized needs of different customers and projects by combining special flag bits with user format definition files, improve the versatility and adaptability of EDA tools, reduce development and maintenance costs, optimize user experience and efficiency, ensure data parsing accuracy and reliability, and have good scalability and promote integration with third-party tools.

[0008] The above invention purpose of the present application is realized by the following technical scheme: A processing method supporting user customized data, comprising the following steps: S1: Special flag system definition and user configuration, define a general special flag system specification, which includes naming rules, types, syntax structures and parsing priority rules of flags, and has extensibility, while providing a user configuration interface to allow users to define customized data formats based on the special flag system specification and form a user format definition file; S2: User customized data generation, users embed the special flags in the data according to the customized data format to indicate the organization structure, field meaning and data type of the data; S3: Customized data parsing and processing, EDA tools load the user format definition file and generate a format description model, then load the customized data, identify the special flags in it, parse the data content combined with the format description model and map to the internal data structure of the tool, and finally use the mapped internal data to perform subsequent EDA processing; S4: Feedback and verification, EDA tools verify the parsing process and results, show the parsing results, warnings and error information to the user for adjusting the data flags or the user format definition file.

[0009] Further, in step S1, the naming rules of the special flag system specification include using a specific prefix or a specific symbol combination at the beginning followed by the flag name; The types of flags include format declaration flags, section definition flags, field definition flags, data type flags, conditional control flags, end flags, etc. The syntax structure of the flag includes the structure of the flag name, parameter list, scope delimiter, etc. The user configuration interface provided is the configuration file of the original specific format, and the user defines the content of the customized data format through this interface according to the special flag system specification, including: Declarative flag configuration: define the start flag for declaring that the data adopts the customized format and its optional parameters; Data section structure definition: use different sections to define the start and end of different logical blocks in the data, and specify the attributes including the name of the section; Field definition and mapping: for each section, define the name, data type, whether required, default value, value range, unit of each data field, and the mapping relationship between the field and the corresponding attribute of the internal data model of the EDA tool; Conditional logic and constraint configuration: Use conditional control flags to define conditions for fields or sections, including occurrence conditions, dependencies between fields, or value constraints. After the user completes the configuration, the system saves the configuration information as the user-defined format file.

[0010] Furthermore, in step S2, when the user writes or generates customized data, according to the customized data format defined by themselves, a special flag bit is embedded in the corresponding position of the data; the special flag bit clearly indicates the information of the data, including the organizational structure, the meaning of each field, and the data type.

[0011] Furthermore, step S3 specifically includes: S31: Load and parse the user format definition file. When the EDA tool starts the data processing task, it first loads the user format definition file and parses it according to the defined general flag bit system specification using the built-in flag bit system parser. It understands the meta-information defined by the user, including the meaning of flag bits, data structure, and field mapping relationships, and organizes this meta-information into a structured format description model. If the user format definition file is found to be inconsistent with the flag bit system specification or to have logical errors during the parsing process, the system uses the default value to override it. S32: Load user data and identify special flag bits. The EDA tool loads the generated customized data containing special flag bits, and scans the loaded customized data through the flag bit recognizer module in the system. Based on the flag bit features including specific prefixes and names obtained by parsing the user format definition file, all special flag bits in the data and their positions are identified. S33: Based on the format description model and the identified special flags, parse the data content and map it to the internal data structure. The data content parser module, combining the format description model and the identified special flags, performs section-by-section and field-by-field parsing of the data, specifically including: The scope and type of a section are defined by the section start / end markers; Each field is identified based on its field flag, and the field values ​​are validated and converted based on the metadata carried in the flag, including data type and unit. Based on the mapping relationship defined in the format description model, the parsed field values ​​are accurately filled into the common data structure or object model inside the EDA tool; If the conditional logic and constraint checks defined in the user format definition file exist, then this configuration is executed to ensure data consistency and validity; S34: Perform subsequent processing. After the data is successfully parsed and mapped to the tool's internal data structure, the EDA tool uses this internal data for subsequent core processing.

[0012] Furthermore, in step S4, after the EDA tool verifies the parsing process and results, it displays the parsing results through the interface. The parsing results include successfully parsed sections and settings, warnings found during the parsing process, and errors found during the parsing process. Based on the information displayed on the interface, the user adjusts the flag bits in their data or the user format definition file.

[0013] Furthermore, in step S1, when parsing the user format definition file, a user format definition file parsing algorithm is used. This algorithm is based on configuration file parsing technology, including a JSON parser, to convert the JSON text format user format definition file into a format description model that can be understood and efficiently queried within the EDA tool. The algorithm also includes: Dedicated verification for flag bit systems: Based on general parsing, additional verification steps are added for special flag bit systems to ensure that user-defined formats are valid; Construct a structured format description model: Organize the parsed information into a structured data model that includes a section definition table, a field definition table, and a flag dictionary. The data model adopts a structure including a hash table or a tree structure so that the data can be quickly queried and matched during subsequent data parsing. Semantic checking and conflict detection: Perform preliminary semantic checks on conditional logic and constraint configurations.

[0014] Furthermore, in step S3, the identification of special flag bits and the parsing of mapping data content also involve three core algorithms: Special flag identification algorithm in data: Based on string matching and pattern recognition technology, it dynamically generates or adjusts regular expression patterns or finite state machines according to the flag features recorded in the format description model, performs multi-pattern parallel matching according to predefined priority rules to avoid ambiguity, and checks whether the flag appears in a reasonable context after it is identified by combining the format description model. Data content parsing and mapping algorithm based on flag bits: Based on syntax analysis technology and attribute grammar, the parsing process is driven by the identified special flag bits as state transition points. The original string field values ​​are automatically converted and verified according to the data type meta-information specified in the field flag bits. The verified field values ​​are dynamically assigned to the internal objects of the EDA tool through reflection mechanism or pre-generated mapping function table. Conditional logic and constraint evaluation algorithm: It calls a small expression evaluation engine to parse user-defined conditional expressions and decides whether to parse specific fields, apply default values, or trigger warnings / errors based on the evaluation results. This algorithm draws on the idea of ​​rule engines and simplifies and optimizes it for data parsing scenarios.

[0015] A system for processing user-customized data, used to perform the processing method for user-customized data as described above, includes: The flag configuration module is used for defining and configuring special flag systems. It defines a general special flag system specification, which includes the naming rules, types, syntax structure, and parsing priority rules of flags and is extensible. It also provides a user configuration interface, allowing users to define customized data formats based on the special flag system specification and form user format definition files. The customized data generation module is used to generate user-customized data. Users embed standardized special flags into the data according to the customized data format to indicate the data's organizational structure, field meanings, and data types. The data parsing and processing module is used for customized data parsing and processing. The EDA tool loads the user format definition file and parses it to generate a format description model. Then, it loads the customized data, identifies the special flag bits, parses the data content in combination with the format description model, and maps it to the internal data structure of the tool. Finally, it uses the mapped internal data to perform subsequent EDA processing. The verification and feedback module is used for feedback and verification. The EDA tool verifies the parsing process and results, and displays the parsing results, warnings and error messages to the user, allowing the user to adjust the data flags or the user format definition file.

[0016] A computer device includes a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method described above.

[0017] A computer-readable storage medium storing computer code that, when executed, performs the method described above.

[0018] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) High flexibility and customization capability: Through the collaboration of special flag bits and user format definition files, this invention grants users the authority to define the data organization structure and field meanings independently, which can flexibly adapt to the personalized data format needs of different customers and projects, and completely get rid of the limitations of traditional fixed formats on diverse needs.

[0019] (2) Significantly improve the versatility and adaptability of EDA tools: There is no need to repeatedly develop dedicated parsing modules for different customers' special data formats, which greatly reduces the development cost and post-maintenance complexity of EDA tools, enabling a single EDA tool to cover a wider range of users and effectively expand the application scenarios and service scope of the tool.

[0020] (3) Effectively enhance user experience and work efficiency: Users do not need to spend time learning and adapting to the fixed format of EDA tools. They can directly adopt data formats that conform to their own usage habits or internal enterprise standards, which greatly reduces the workload of data conversion and format adaptation and significantly improves overall work efficiency.

[0021] (4) It has good technical scalability: The special flag system specification incorporates scalability from the beginning of the design, which makes it easy to add flag types and functions according to needs in the future. It can continuously support more complex customized scenarios in the future and ensure the long-term applicability of the technical solution.

[0022] Ensuring the accuracy and reliability of data parsing: Through the pre-parsing and verification of user-defined format files, combined with special flag identification, data type verification, and constraint checking mechanisms during the data parsing process, the accuracy and reliability of customized data parsing are ensured from multiple dimensions, effectively reducing parsing errors caused by format mismatch.

[0023] (6) Effectively promote integration with third-party tools: Support users to adjust the data format to be compatible with third-party tools or self-developed tools, break down the data flow barriers between different tools, promote the smooth transfer of data between various tool chains, and improve the collaborative efficiency of the entire electronic design process. Attached Figure Description

[0024] Figure 1 This is an overall flowchart of the method for processing user-customized data according to the present invention; Figure 2 This is an overall structural diagram of the system for processing user-customized data according to the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0027] First Embodiment like Figure 1 As shown, this embodiment provides a method for processing user-customized data, including the following steps: S1: Define and configure a special flag bit system for users. Define a general special flag bit system specification. The special flag bit system specification includes the naming rules, types, syntax structure and parsing priority rules of the flag bits and has extensibility. At the same time, it provides a user configuration interface, allowing users to define customized data formats based on the special flag bit system specification and form user format definition files.

[0028] In step S1, the naming rules of the special flag bit system specification include starting with a specific prefix (such as @CUST_) or a specific combination of symbols (such as starting with "###") followed by the flag bit name; the types of flag bits include format declaration flag bits, section definition flag bits, field definition flag bits, data type flag bits, condition control flag bits, and end flag bits; the syntax structure of the flag bits includes the flag bit name, parameter list, and scope delimiter. The provided user configuration interface is a user-friendly configuration file in a specific format provided by the EDA tool. Through this interface, users can define customized data formats based on the special flag bit system specification, including but not limited to: Declarative flag configuration: Defines the starting flags and their optional parameters (such as the format version number) used to declare that the data adopts a customized format. Data section structure definition: Use different sections to delineate the beginning and end of different logical blocks in the data (such as ".START_DISPLAY", ".START_SHOW_ALL_CFG", ".START_SETTINGS"), and specify attributes including the name of the section; Field definition and mapping: For each section, define the name, data type (such as integer, floating point, string, enumeration, array, etc., which can be specified through data type flags), required status, default value, value range, unit, and mapping relationship between the field and the corresponding attribute in the data model inside the EDA tool; Conditional logic and constraint configuration: Use conditional control flags to define conditions for fields or sections, including occurrence conditions, dependencies between fields, or value constraints. After the user completes the configuration, the system saves the configuration information as the user-defined format file.

[0029] Step S1 serves as the foundational configuration step for supporting user-customized data processing methods. Its core objective is to build a reusable and scalable "rule system" and provide users with a convenient configuration entry point, ensuring that the generation and parsing of subsequent customized data have a unified standard to follow.

[0030] From the definition of the special flag bit system specification, this specification is not a simple symbol convention, but a set of structured rules covering the entire process of "identification-classification-parsing": In terms of naming rules, the design of "specific prefixes (such as @CUST_)" or "specific symbol combinations (such as starting with "###")" allows EDA tools to quickly distinguish customized flag bits from ordinary data content, avoiding identification ambiguity; in terms of flag bit type classification, it covers six major categories: format declaration, section definition, field definition, data type, condition control, and end flag bits, which correspond to core requirements such as data format declaration, data logic block division, field attribute definition, data type annotation, condition constraint setting, and parsing boundary definition, achieving full-scenario coverage of customized formats; in terms of syntax structure, it clearly defines three key elements: flag bit name, parameter list, and scope delimiter, ensuring that users can clearly describe the function and parameters of the flag bit (such as the format version number), and also clarifying the effective scope of the flag bit (such as within a certain section) through the scope delimiter, laying the foundation for accurate parsing later. Meanwhile, the specification emphasizes "scalability" and reserves space for adding new flag types and functions to cope with more complex customization needs in the future.

[0031] In terms of user configuration interface and configuration content design, the solution fully considers both "ease of use" and "functionality": the interface adopts the configuration file format of the EDA tool's original specific format, avoiding the cost of users learning new tools and reducing the configuration threshold; the configuration content revolves around "complete description of customized format", forming a closed loop from "format declaration" to "data mapping"—declarative flag configuration is used to clarify the customized attributes of the data, allowing the tool to identify the data type at first glance; the data section structure definition uses example sections such as ".START_DISPLAY", "START_SHOW_ALL_CFG", and "START_SETTINGS" to divide the data into different logical blocks, meeting the user's needs for data classification and management; field definition and mapping go deep into the section, not only defining the basic attributes of the field (name, data type, whether required, default value, value range, unit), but also establishing the association with the internal data model of the EDA tool, solving the core problem of "how customized data is understood by the tool"; condition logic and constraint configuration, through condition control flags, realize the dynamic adaptation of fields or sections (such as a field only appearing under specific conditions), further improving the flexibility of format customization. Ultimately, this configuration information is integrated by the system into a "user format definition file," which becomes a key bridge connecting user customization needs with tool parsing logic.

[0032] S2: Generate user-customized data. Based on the customized data format, the user embeds standardized special flags in the data to indicate the data's organizational structure, field meanings, and data types.

[0033] In step S2, when a user writes or generates customized data, they embed standardized special flags in the corresponding positions of the data according to their own defined customized data format. These special flags clearly indicate information about the data, including its organizational structure, the meaning of each field, and its data type. For example, a customized settings section might begin with ".START_SETTINGS" and end with ".END_SETTINGS," and each setting description field within the section might have corresponding field flags such as "Headers Order,Units;Sim Value;Target," "Output Format,1," etc.

[0034] Step S2 is a crucial execution step that transforms the "customized format rules" defined in step S1 into actual customized data that can be recognized by EDA tools. The core logic is to allow users to concretize the abstract format requirements into the data by "embedding special flag bits", providing clear "data guidance" for subsequent tool parsing.

[0035] From an operational logic perspective, this step fully embodies the core of "user-led" customization: users do not need to follow the fixed format preset by the EDA tool, but rather, based on their own customized data format defined in step S1 (which has been saved as a user format definition file), they embed standardized special flags into the corresponding positions of the data during the process of writing or generating data. These special flags are not meaningless symbols, but play a core role in "information annotation"—they clearly inform the subsequent parsing tool of the data's organizational structure (such as which contents belong to the same logical block), the specific meaning of each field (such as whether a field represents "simulation value" or "output format"), and the data type of the field (such as integer, string, or enumeration type), which is equivalent to adding a "parsing instruction manual" to the data, ensuring that the tool can accurately understand the user's customization intent.

[0036] The example provided in the solution further clarifies this process: For a customized settings section (typically used to store tool configuration data), the user specifies the starting boundary of the section using the ".START_SETTINGS" flag and the ending boundary using the ".END_SETTINGS" flag. This "start and end flags" design allows the tool to quickly locate the scope of the logical block, avoiding confusion with data from other sections. Inside the section, dedicated flags before each setting description field (such as "Headers Order,Units;Sim Value;Target" and "Output Format,1") further refine the information—the former can indicate whether the field involves attributes such as "header order, units, simulation value, and target parameters," while the latter can specify the specific value of the "output format" field (such as "1" representing a preset format type). Through this hierarchical embedding method of "block-level flags + field-level flags," both the clarity of the data organization structure and the accuracy of each field's information are ensured, making the customized data both meet user needs and have the basic conditions for accurate parsing by the tool.

[0037] S3: Perform customized data parsing and processing. The EDA tool loads the user format definition file and parses it to generate a format description model. Then, it loads the customized data, identifies the special flag bits, parses the data content in combination with the format description model, and maps it to the tool's internal data structure. Finally, it uses the mapped internal data to perform subsequent EDA processing.

[0038] In this embodiment, step S3 specifically includes: S31: Load and parse the user format definition file. When the EDA tool starts the data processing task, it first loads the user format definition file and parses it according to the defined general flag bit system specification using the built-in flag bit system parser. It understands the meta-information defined by the user, including the meaning of flag bits, data structure, and field mapping relationships, and organizes this meta-information into a structured format description model (which can be understood as a data structure template). If the user format definition file is found to be inconsistent with the flag bit system specification or to have logical errors during the parsing process, the system uses the default value to override it. S32: Load user data and identify special flag bits. The EDA tool loads the generated customized data containing special flag bits, and scans the loaded customized data through the flag bit recognizer module in the system. Based on the flag bit features including specific prefixes and names obtained by parsing the user format definition file, all special flag bits in the data and their positions are identified. S33: Based on the format description model and the identified special flags, parse the data content and map it to the internal data structure. The data content parser module, combining the format description model and the identified special flags, performs section-by-section and field-by-field parsing of the data, specifically including: The scope and type of a section are defined by the section start / end markers; Each field is identified based on its field flag, and the field values ​​are validated and converted based on the metadata carried in the flag, including data type and unit (for example, converting a string of numbers to a floating-point number and checking whether the value is within the specified range). Based on the mapping relationship defined in the format description model, the parsed field values ​​are accurately filled into the common data structure or object model inside the EDA tool; If the conditional logic and constraint checks defined in the user format definition file exist, then this configuration is executed to ensure data consistency and validity; S34: Perform subsequent processing. After the data is successfully parsed and mapped to the tool's internal data structure, the EDA tool can use this internal data for subsequent core processing, just like it would with traditional fixed-format data.

[0039] Step S3 is the core execution link for EDA tools to connect with users' customized needs. Through a four-step closed loop of "loading rules - identifying flags - parsing mappings - subsequent processing", the customized data generated by users is transformed into internal data that the tool can directly use. This not only achieves accurate adaptation to the customized format, but also ensures the normal operation of subsequent core functions. It is a key bridge connecting users' customized needs with the actual application of the tool.

[0040] From the perspective of specific execution logic, S31, as the "rule initialization" step in the parsing process, is essentially about transforming the user-pre-configured "user format definition file" into a structured model that the tool can understand. After the EDA tool starts, it first loads this file and uses the built-in "flag system parser" to parse it according to the general special flag system specifications defined in step S1. This process not only reads the configuration content but also extracts metadata such as flag meanings, data structures, and field mapping relationships, organizing it into a "format description model" (similar to a "template" for data parsing), allowing the tool to clearly define "which rules to use to parse the data." Simultaneously, the solution also considers fault tolerance: if the file contains non-compliant specifications (such as incorrect flag naming) or logical contradictions (such as conflicting field dependencies), the system will automatically overwrite with default values, preventing the entire parsing process from being interrupted due to configuration errors and ensuring the stability of the tool's operation.

[0041] S32 is the "marker localization" step in the parsing process, aiming to quickly locate key special markers from massive amounts of data. After loading user-generated customized data, the tool performs a comprehensive scan of the data through the "marker recognizer" module. The scanning is not based on fixed rules, but on the marker features parsed in S31 (such as specific prefixes "@CUST_" and specific names ".START_SETTINGS"). This "user-configured dynamic recognition" method ensures accurate matching of user-defined markers and avoids misidentifying ordinary data content. Through this step, the tool can clearly identify the location of all special markers, defining "navigation coordinates" for subsequent segment-by-segment and field-by-field parsing.

[0042] S33 is the "core data transformation" step in the parsing process, which uses a "data content parser" to achieve a deep mapping of customized data to the data inside the tool. This step employs a "layered parsing + multi-dimensional verification" logic: First, the scope and type of each logical block are defined based on the start / end flags of the section (such as ".START_SETTINGS" and ".END_SETTINGS"), ensuring the structured nature of the data parsing; then, within each section, specific fields are identified through field flags, and the field values ​​are processed in conjunction with the metadata carried by the flags (such as data type being floating-point numbers and unit being "V")—including format conversion (such as converting the string "3.5" to the floating-point number 3.5) and validity verification (such as checking whether the value is within the specified range of "0-10"); subsequently, according to the preset mapping relationship in the "format description model," the verified field values ​​are accurately filled into the tool's internal common data structure or object model, solving the core problem of "how customized data is understood by the tool"; if the user defines conditional logic and constraints during configuration (such as a field only taking effect when "temperature > 25℃"), the configuration is executed synchronously, further ensuring data consistency and validity, and preventing abnormal data from entering subsequent processes.

[0043] S34, as the "finishing and transition" step in the parsing process, achieves seamless integration between customized data and the tool's original functions. Once the data is successfully parsed and mapped to the internal data structure, its form within the tool is completely consistent with traditional fixed-format data. This means that the tool can directly use this customized data to perform subsequent core operations such as model verification and logic simulation without modifying its original core processing logic. This preserves the integrity of the tool's original functions while supporting customized formats through the adaptation of previous steps, truly achieving the design goal of "customization requirements not affecting the tool's original workflow."

[0044] S4: Provide feedback and verification. The EDA tool verifies the parsing process and results, and displays the parsing results, warnings (such as missing non-essential fields with default values), and error messages (such as missing required fields, data type mismatch, and values ​​out of range) to the user, allowing the user to adjust the data flags or the user format definition file.

[0045] In step S4, after verifying the parsing process and results, the EDA tool displays the parsing results through the interface. The parsing results include successfully parsed sections and settings, warnings found during the parsing process, and errors found during the parsing process. Based on the information displayed on the interface, the user adjusts the flag bits in their data or the user format definition file.

[0046] Step S4 is the "closed-loop assurance link" in the entire customized data processing process. Its core function is to help users discover problems in customized data or format configuration in a timely manner through the verification and feedback of EDA tools, so as to ensure the accuracy and reliability of subsequent data processing. At the same time, it provides clear guidance for users to optimize and adjust, forming a complete closed loop of "configuration-generation-parsing-adjustment".

[0047] From a verification logic perspective, EDA tools don't just verify the parsing results; they cover the entire chain from "parsing process to final result." The tool tracks every step of the S3 process in real time, from loading user-defined format files and identifying special flags to parsing data content and mapping internal data structures. It checks both the completeness and compliance of the final parsed sections and settings, and also identifies potential hidden problems (such as missing unnecessary fields or abnormal data type conversions). This end-to-end verification provides more comprehensive control over data quality, preventing errors in subsequent processing due to oversights in a single step.

[0048] In terms of feedback presentation, the solution emphasizes "information clarity and user readability": the tool displays verification results in a categorized manner through the interface, clearly distinguishing between "successfully parsed content" and "problem information"—the former explicitly lists the successfully parsed sections (such as the configuration module corresponding to ".START_SETTINGS") and settings (such as specific field parameter settings), allowing users to intuitively understand which parts meet expectations; the latter further subdivides information into "warnings" and "errors": warnings address non-fatal issues (such as missing non-essential fields but the system has automatically filled in default values), only reminding users that no forced modifications are needed; errors point to critical issues affecting the effectiveness of parsing (such as missing required fields leading to incomplete data, data type mismatch preventing conversion, values ​​exceeding preset ranges, etc.), requiring user intervention. This categorized display helps users quickly focus on core issues, avoiding wasting energy on non-critical information.

[0049] From a user operation perspective, the feedback information directly provides "precise navigation" for subsequent adjustments: users can pinpoint the root cause based on the specific issues displayed on the interface—if a warning or error stems from improper embedding of flags in the data (such as a missing section end flag or incorrect field flag parameters), then the flags in the data can be adjusted accordingly; if the problem originates from oversights in the initial configuration (such as incorrect field value range settings in the user format definition file or contradictory condition constraint logic), then the user format definition file can be optimized by returning to step S1. This direct correspondence between "problem-adjustment direction" significantly reduces the difficulty of user troubleshooting and modification, ensuring efficient optimization and allowing customized data or format configurations to quickly meet the tool's parsing requirements, thus guaranteeing the smooth progress of the entire processing flow.

[0050] Furthermore, in step S1, when parsing the user format definition file, a user format definition file parsing algorithm is used. This algorithm is based on configuration file parsing technology, including a JSON parser, to convert the JSON text format user format definition file into a format description model that can be understood and efficiently queried within the EDA tool. The algorithm also includes: Dedicated validation for flag bit systems: Based on general parsing, additional validation steps are added for special flag bit systems to ensure that user-defined formats are valid; for example, checking whether flag bit names conform to naming rules, whether flag bit types are valid, whether parameters are complete and of the correct type, and whether there are nested logic errors in section definitions and field definitions, etc.

[0051] Constructing a structured format description model: This involves more than simply reading configuration values. Instead, the parsed information is organized into a structured data model that includes a section definition table, a field definition table (each field is associated with its section, data type, mapping target, etc.), and a flag dictionary (a mapping of flags to their types and parameters). The data model adopts a structure including hash tables or tree structures to enable fast querying and matching during subsequent data parsing. Semantic checks and conflict detection: Perform preliminary semantic checks on conditional logic and constraint configurations, such as detecting circular dependencies or contradictory constraints.

[0052] The algorithm used to parse the user format definition file in step S1 is the "translation core" that connects user configuration requirements with the parsing capabilities of EDA tools. It is not a simple text reading tool, but a mature configuration file parsing technology based on JSON parsers. Through the design of "general parsing + dedicated optimization", it transforms the JSON text format user format definition file into a structured format description model that the tool can efficiently understand and query. At the same time, it ensures the legality and logic of the configuration through multi-layer verification, laying a solid foundation for subsequent customized data parsing.

[0053] From the perspective of breaking down the core functions of the algorithm, "dedicated verification for the flag bit system" is a crucial line of defense for ensuring the legality of configurations. This step, in addition to general JSON text parsing (such as syntax correctness checks), focuses on the compatibility checks of specific flag bit system specifications: for example, it determines whether flag bit names are compliant by matching preset naming rules (such as whether they begin with the prefix "@CUST_" or the symbol combination "###"), avoiding naming confusion that prevents the tool from being unable to recognize them; it checks for illegal type definitions by comparing the list of allowed flag bit types (six categories including format declarations and section definitions); it verifies the completeness of parameters (such as whether format declaration flag bits include version number parameters) and the correctness of their types (such as whether parameters are preset integer or string types), ensuring that configuration information is not missing or incorrect; and it checks the nesting relationship between sections and fields (such as whether fields are only defined within sections, and whether there are abnormal section nesting levels), avoiding logical contradictions. These targeted verifications essentially transform the flag bit system specifications defined in step S1 into executable verification rules, ensuring that the user's configuration format "conforms to the tool's parsing logic," reducing subsequent parsing errors from the source.

[0054] The core design for improving tool parsing efficiency is "building a structured format description model." Instead of directly reading and storing scattered values ​​from configuration files, the algorithm reorganizes the parsed information into three core structures based on functional modules: a section definition table records the names, start and end flags, and other attributes of all sections, facilitating quick data logic block location; a field definition table associates each field with its respective section, data type, and mapping target (an internal data model attribute of the EDA tool), achieving precise "field-data model" correspondence; and a flag dictionary establishes a mapping relationship between flags and types / parameters, allowing the tool to quickly query their functions and parameter requirements using flags. Simultaneously, the model employs efficient data structures such as hash tables (supporting fast key-value lookups) or tree structures (adapting to section nesting levels), enabling the tool to quickly match corresponding configuration rules using flags during subsequent data parsing (e.g., quickly querying the field definitions of a section using ".START_SETTINGS"), significantly shortening query and matching time and improving overall parsing efficiency.

[0055] "Semantic checking and conflict detection" is a supplementary step to ensure the logical consistency of configurations. It mainly targets the conditional logic and constraint rules configured by the user (such as a field only taking effect when it exists in a specific section, or a field value needing to be less than another field value). The algorithm uses a small semantic analysis engine to check for logical contradictions: for example, it checks for circular dependencies such as "field A depends on field B, and field B depends on field A," preventing the tool from getting stuck in an infinite loop during parsing; it checks for contradictory constraints such as "field values ​​must be greater than 10 and less than 5," preventing the tool from being unable to determine data validity due to rule conflicts. Although these checks do not involve syntax errors, they directly affect the accuracy of subsequent data parsing. By checking in advance, it can reduce parsing interruptions or data misjudgments caused by logical contradictions, further ensuring the availability of the configuration.

[0056] In addition, in step S3, when identifying special flag bits and parsing the mapping data content, three core algorithms are involved: (1) Special flag identification algorithm in data: Based on string matching and pattern recognition technology, the regular expression pattern or finite state machine is dynamically generated or adjusted according to the flag features recorded in the format description model. Multi-mode parallel matching is performed according to predefined priority rules to avoid ambiguity. After the flag is identified, the format description model is combined to check whether it appears in a reasonable context.

[0057] This data-specific flag identification algorithm quickly and accurately locates and extracts all special flags that match the descriptions in the "user format definition file" from user-provided data text (or data stream). It is based on string matching and pattern recognition techniques, such as regular expression matching. Applications and improvements in this invention include: Dynamic pattern generation: Instead of using a fixed pattern, the regular expression pattern or finite state machine is dynamically generated or adjusted based on the flag features recorded in the "format description model" (such as prefixes and a known set of flag names). This allows the recognition process to accurately match user-defined flags.

[0058] Multi-pattern parallel matching and priority handling: If flag names may be contained in or similar contexts, the algorithm will match according to predefined priority rules (such as the order of appearance in the "user format definition file", the flag length, or the priority explicitly specified by the user) to avoid ambiguity. For example, longer, more specific flags take precedence over shorter, more general flags.

[0059] Context-aware flag verification: After a flag is identified, its definition in the "format description model" is considered to check whether it appears in a reasonable context (e.g., the field flag defined in the section can only appear after the section start flag), thus initially filtering out some obvious erroneous flags.

[0060] The special flag identification algorithm in data is the core technology module of EDA tools for accurately extracting "parsing guidance" from customized data. Its core objective is to quickly and unambiguously locate all special flags that conform to user-configured rules in massive amounts of text data (or data streams), providing accurate "data anchors" for subsequent section-by-section and field-by-field parsing. This algorithm is based on string matching and pattern recognition technologies (such as regular expression matching), and has made three key improvements for user-customized scenarios, which not only solves the limitations of fixed pattern recognition, but also ensures the accuracy and reliability of the recognition.

[0061] "Dynamic pattern generation" is the core design of the algorithm, adapting to user-defined needs and breaking free from the constraints of traditional fixed pattern recognition. Instead of relying on preset fixed regular expressions or recognition rules, the algorithm first reads the flag features recorded in the "format description model" (generated by parsing the user's format definition file) before recognition. This includes user-defined flag prefixes (such as "@CUST_"), specific flag name sets (such as ".START_SETTINGS" and "Output Format"), and then dynamically generates or adjusts the regular expression pattern (e.g., generating a specific matching expression for ".START_SETTINGS") or the recognition logic of the finite state machine based on these features. This "user-configuration-based dynamic adaptation" approach ensures that the recognition rules are completely aligned with the user-defined flags, avoiding missed or incorrect recognition problems caused by fixed patterns failing to cover personalized flags.

[0062] The "Multi-pattern Parallel Matching and Priority Processing" approach focuses on resolving potential ambiguities in flag names, ensuring the uniqueness of the recognition results. In practical applications, different user-defined flags may have names that are inclusive (e.g., ".START_SETTINGS" and ".START_SETTINGS_DETAIL") or similar (e.g., ".START_CFG" and ".START_CONFIG"). Matching them in the normal order can easily lead to misjudgments. The algorithm uses predefined priority rules (e.g., the order in which flags appear in the "user format definition file," flag length, and user-specified priority) to perform parallel matching on multiple possible flag patterns, prioritizing patterns with higher priority as the recognition result—for example, the longer and more specific ".START_SETTINGS_DETAIL" will be recognized before the shorter ".START_SETTINGS," ensuring that each flag is accurately matched and completely avoiding ambiguity.

[0063] Context-aware flag verification is a crucial supplement to the algorithm's improved recognition reliability, essentially adding a "logical verification" step to the recognition results. After identifying a flag, the algorithm doesn't directly confirm its validity. Instead, it checks whether the flag appears in a reasonable context, considering the logical relationships between flags defined in the "format description model" (such as the hierarchical relationship between section flags and field flags). For example, according to the model definition, a field flag (e.g., "Output Format, 1") can only appear after the corresponding section start flag (e.g., ".START_SETTINGS") and before the end flag (e.g., ".END_SETTINGS"). If the field flag appears in other sections or outside of sections, it is considered invalid and filtered out. This context verification can initially filter out invalid data caused by user errors (e.g., incorrect flag embedding positions), reducing errors in subsequent parsing stages and further improving the stability of the entire processing flow.

[0064] (2) Data content parsing and mapping algorithm based on flag bits: Based on syntax analysis technology and attribute grammar, the identified special flag bits are used as state transition points to drive the parsing process. The original string field values ​​are automatically converted and verified according to the data type metadata specified in the field flag bits. The verified field values ​​are dynamically assigned to the internal objects of the EDA tool through reflection mechanism or pre-generated mapping function table.

[0065] The data content parsing and mapping algorithm based on flag bits identifies special flag bits, parses the data content between the flag bits, and maps it to the tool's internal data structure according to the definition of the "format description model." It also utilizes syntax analysis techniques, such as recursive descent parsing, combined with attribute grammars for semantic analysis and attribute calculation. Applications and improvements in this invention include: Flag-driven state machine parsing: This method uses identified special flags as key state transition points to drive the parsing process. For example, when the ".START_SETTINGS" flag is detected, the parser enters the "settings parsing state," where it only searches for field flags defined in settings and the end flag of settings. This state machine model can effectively handle the parsing of nested sections and sections of different types.

[0066] Data type conversion and validation of field values: Based on the data type metadata specified in the field flags (obtained from the "Format Description Model"), the original string-formatted field values ​​are automatically converted (e.g., string to integer, floating-point, Boolean, enumeration value), and range checks and format checks (e.g., date format) are performed. For enumeration types, it checks whether the value is in the predefined enumeration list.

[0067] Dynamic data binding and mapping: Parsed and validated field values ​​are dynamically assigned to internal objects based on the mapping relationship between the "format description model" and the tool's internal data structure. This can be achieved through reflection or a pre-generated mapping function table, ensuring flexibility and efficiency.

[0068] The flag-based data content parsing and mapping algorithm is a core bridge connecting "special flag identification" and "internal data application of EDA tools." Its core objective is to achieve structured parsing of customized data content and dynamic mapping of the tool's internal data structure based on accurate identification of special flags. This ensures both the orderliness and accuracy of the parsing process while achieving seamless compatibility between customized data and the tool's existing data system. The algorithm is based on recursive descent parsing and other syntax analysis techniques, combined with attribute grammar for semantic analysis and attribute calculation. It also incorporates three key improvements for customized scenarios, constructing a complete processing logic of "ordered parsing - accurate verification - flexible mapping."

[0069] "Flag-driven state machine parsing" is the core design of the algorithm to ensure the orderly parsing process, especially suitable for parsing complex nested sections and multi-type sections. The algorithm uses identified special flags as "switching signals" for parsing states, constructing a dynamic state machine model: when the parser scans the start flag of a section (e.g., ".START_SETTINGS"), it immediately switches to the section's dedicated parsing state (e.g., "settings parsing state"). At this time, the parser focuses only on the target content in this state—that is, it only recognizes the field flags defined within this section (e.g., "Output Format, 1") and their corresponding end flags (e.g., ".END_SETTINGS"), and no longer responds to flag signals from other sections. This state machine mechanism effectively avoids data confusion between different sections. Even with nested sections (e.g., a section containing sub-sections), the parsing scope of each logical block can be precisely defined through layer-by-layer state switching, ensuring that the parsing process proceeds in an orderly manner according to the user-defined data structure.

[0070] "Data type conversion and validation of field values" is a crucial step in ensuring data accuracy, resolving the incompatibility issue between the original string data and the tool's internal data types. The algorithm doesn't directly use the original string field values ​​from the data; instead, it first extracts metadata corresponding to the field flags from the "format description model"—including the field's data type (e.g., integer, floating-point, enumeration), value range (e.g., "0-100"), and format requirements (e.g., date format "YYYY-MM-DD"). Based on this metadata, it automatically processes the original string: on one hand, it performs data type conversion (e.g., converting the string "3.14" to the floating-point number 3.14, and "TRUE" to the boolean value true); on the other hand, it performs multi-dimensional validation (e.g., checking if the value is within the specified range, if the enumeration value is in the predefined list, and if the date format is compliant). This "validate before use" logic filters invalid or erroneous data at the source, preventing errors in subsequent processing due to data type mismatches or numerical anomalies.

[0071] "Dynamic data binding and mapping" is the core innovation of the algorithm, enabling compatibility between customized data and the tool's internal data structure, balancing flexibility and efficiency. After parsing and validating field values, the algorithm needs to populate the valid data into the EDA tool's internal data structure or object model. This process is achieved through two efficient methods: First, a reflection mechanism, which eliminates the need to pre-write fixed field assignment code. Instead, it dynamically locates and assigns values ​​to the attributes of internal objects based on the mapping relationship between fields and internal object attributes defined in the "format description model," making it suitable for scenarios where field mapping relationships change frequently. Second, a pre-generated mapping function table, which generates dedicated assignment functions for commonly used fixed mapping relationships. During parsing, these functions are directly called to populate the data, ensuring both execution efficiency and flexibility. The combination of these two methods avoids the rigidity of traditional fixed code mapping and solves the efficiency problems that may exist with pure reflection mechanisms. This ensures that customized data can be quickly and accurately integrated into the tool's internal data system, providing reliable data support for subsequent core processes such as model verification and logic simulation.

[0072] (3) Conditional logic and constraint evaluation algorithm: Call a small expression evaluation engine to parse user-defined conditional expressions. Based on the evaluation results, decide whether to parse specific fields, apply default values, or trigger warnings / errors. This algorithm draws on the idea of ​​rule engines and simplifies and optimizes it for data parsing scenarios.

[0073] The conditional logic and constraint evaluation algorithm involves the parser invoking a small expression evaluation engine for user-defined conditional control flags and constraints. This engine parses and evaluates the user-defined conditional expressions and determines whether to parse specific fields, apply default values, or trigger warnings / errors based on the evaluation results. This borrows ideas from rule engines but is simplified and optimized for specific data parsing scenarios.

[0074] Conditional logic and constraint evaluation algorithms are key supplementary modules that ensure the "flexibility" and "data validity" of customized data parsing. Their core objective is to enable EDA tools to understand and execute user-defined conditional logic and data constraint rules. This supports both "on-demand parsing" (e.g., parsing a field only under specific conditions) and proactively filtering data that does not meet constraints, preventing invalid information from entering subsequent processes. This algorithm does not build complex rule processing capabilities from scratch; instead, it borrows core ideas from mature rule engines, simplifying and optimizing them for lightweight data parsing scenarios. It ensures that functionality meets requirements while maintaining parsing efficiency and avoiding excessive consumption of system resources.

[0075] From the core execution logic of the algorithm, it relies on a "small expression evaluation engine" as its core carrier. When the EDA tool encounters user-defined condition control flags (such as "parse the humidity field only when the temperature field is >25℃") or data constraints (such as "the voltage field value must be within the range of 0-5V") during the parsing process, the parser calls this engine and inputs the user-configured condition expressions (such as "temperature > 25" and "voltage ∈ [0,5]"). The engine first performs syntactic parsing on the expression, converting the natural language-style constraint rules into logical instructions that the tool can understand (such as converting "voltage ∈ [0,5]" into the logical judgment expression "voltage ≥ 0 and voltage ≤ 5"). Then, it performs evaluation calculations based on the currently parsed field values ​​to obtain a clear result of "conditions met" or "conditions not met".

[0076] Based on the evaluation results, the algorithm triggers corresponding processing logic to achieve the dual functions of "dynamic parsing" and "data verification": At the parsing control level, if the result is "condition met", the corresponding field or section is parsed according to the user configuration; if the result is "condition not met", the parsing of that field / section is skipped, or a preset default value is automatically applied to non-essential fields (such as "when the humidity field is not parsed, the default value is set to 50%)", to avoid parsing interruption due to the absence of non-critical fields; At the data verification level, if the result is "condition not met" (such as the voltage field value being 6V, exceeding the 0-5V constraint), the engine will trigger a warning or error signal, feeding back the problem information (such as "voltage field value is out of range") to the user, while preventing invalid data from entering the tool's internal data structure, ensuring data quality from the source.

[0077] The algorithm's "simplification and optimization" design is key to its adaptability to data parsing scenarios: Compared to the complex business logic supported by general rule engines (such as multi-system linkage and complex time-series judgments), this algorithm only retains core functions strongly related to data parsing (such as simple numerical comparison, field dependency judgment, and enumeration value verification), eliminating redundant modules and significantly reducing the engine's size and operating overhead. Simultaneously, considering the "segmented field value acquisition" characteristic during parsing, the engine supports "incremental evaluation"—it can evaluate conditions in real time based on the parsed field values ​​without waiting for all fields to be parsed, avoiding parsing delays caused by waiting for full data and ensuring the smoothness and efficiency of the overall parsing process. This "simplification on demand" design satisfies users' customization needs for conditional logic and constraints without imposing additional performance burdens on EDA tools, achieving a balance between functionality and efficiency.

[0078] Second Embodiment like Figure 2 As shown, this embodiment provides a user-customized data processing system for executing the user-customized data processing method as described in the first embodiment, including: The flag configuration module is used for defining and configuring special flag systems. It defines a general special flag system specification, which includes the naming rules, types, syntax structure, and parsing priority rules of flags and is extensible. It also provides a user configuration interface, allowing users to define customized data formats based on the special flag system specification and form user format definition files. The customized data generation module is used to generate user-customized data. Users embed standardized special flags into the data according to the customized data format to indicate the data's organizational structure, field meanings, and data types. The data parsing and processing module is used for customized data parsing and processing. The EDA tool loads the user format definition file and parses it to generate a format description model. Then, it loads the customized data, identifies the special flag bits, parses the data content in combination with the format description model, and maps it to the internal data structure of the tool. Finally, it uses the mapped internal data to perform subsequent EDA processing. The verification and feedback module is used for feedback and verification. The EDA tool verifies the parsing process and results, and displays the parsing results, warnings and error messages to the user, allowing the user to adjust the data flags or the user format definition file.

[0079] A computer-readable storage medium stores computer code that, when executed, performs the methods described above. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0080] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0081] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0082] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for processing user-customized data, characterized in that, Includes the following steps: S1: Define and configure a special flag bit system for users. Define a general special flag bit system specification. The special flag bit system specification includes the naming rules, types, syntax structure and parsing priority rules of the flag bits and has extensibility. At the same time, it provides a user configuration interface, allowing users to define customized data formats based on the special flag bit system specification and form user format definition files. S2: Generate user-customized data. The user embeds standardized special flags in the data according to the customized data format to indicate the data's organizational structure, field meanings, and data types. S3: Perform customized data parsing and processing. The EDA tool loads the user format definition file and parses it to generate a format description model. Then, it loads the customized data, identifies the special flag bits, parses the data content in combination with the format description model, and maps it to the internal data structure of the tool. Finally, it uses the mapped internal data to perform subsequent EDA processing. S4: Provide feedback and verification. The EDA tool verifies the parsing process and results, and displays the parsing results, warnings, and error messages to the user, allowing the user to adjust the data flags or the user format definition file.

2. The method for processing user-customized data according to claim 1, characterized in that, In step S1, the naming rules of the special flag bit system specification include starting with a specific prefix or a specific combination of symbols followed by the flag bit name; The types of flags include format declaration flags, section definition flags, field definition flags, data type flags, condition control flags, and end flags; The syntax structure of a flag includes the flag name, parameter list, and scope delimiter. The provided user configuration interface is a configuration file in a specific format. Through this interface, users can define customized data formats based on the special flag bit system specification, including: Declarative flag configuration: Defines the starting flags and their optional parameters used to declare that data uses a customized format; Data section structure definition: Use different sections to delineate the beginning and end of different logical blocks in the data, and specify attributes including the name of the section; Field definition and mapping: For each section, define the name, data type, required status, default value, value range, unit, and mapping relationship between the field and the corresponding attribute in the data model inside the EDA tool; Conditional logic and constraint configuration: Use conditional control flags to define conditions for fields or sections, including occurrence conditions, dependencies between fields, or value constraints. After the user completes the configuration, the system saves the configuration information as the user-defined format file.

3. The method for processing user-customized data according to claim 1, characterized in that, In step S2, when a user writes or generates customized data, a special flag is embedded in the corresponding position of the data according to the customized data format defined by the user. The special flag clearly indicates information about the data, including the organizational structure, the meaning of each field, and the data type.

4. The method for processing user-customized data according to claim 1, characterized in that, Step S3 is as follows: S31: Load and parse the user format definition file. When the EDA tool starts the data processing task, it first loads the user format definition file and parses it according to the defined general flag bit system specification using the built-in flag bit system parser. It understands the meta-information defined by the user, including the meaning of flag bits, data structure, and field mapping relationships, and organizes this meta-information into a structured format description model. If the user format definition file is found to be inconsistent with the flag bit system specification or to have logical errors during the parsing process, the system uses the default value to override it. S32: Load user data and identify special flag bits. The EDA tool loads the generated customized data containing special flag bits, and scans the loaded customized data through the flag bit recognizer module in the system. Based on the flag bit features including specific prefixes and names obtained by parsing the user format definition file, all special flag bits in the data and their positions are identified. S33: Based on the format description model and the identified special flags, parse the data content and map it to the internal data structure. The data content parser module, combining the format description model and the identified special flags, performs section-by-section and field-by-field parsing of the data, specifically including: The scope and type of a section are defined by the section start / end markers; Each field is identified based on its field flag, and the field values ​​are validated and converted based on the metadata carried in the flag, including data type and unit. Based on the mapping relationship defined in the format description model, the parsed field values ​​are accurately filled into the common data structure or object model inside the EDA tool; If the conditional logic and constraint checks defined in the user format definition file exist, then this configuration is executed to ensure data consistency and validity; S34: Perform subsequent processing. After the data is successfully parsed and mapped to the tool's internal data structure, the EDA tool uses this internal data for subsequent core processing.

5. The method for processing user-customized data according to claim 1, characterized in that, In step S4, after verifying the parsing process and results, the EDA tool displays the parsing results through the interface. The parsing results include successfully parsed sections and settings, warnings found during the parsing process, and errors found during the parsing process. Based on the information displayed on the interface, the user adjusts the flag bits in their data or the user format definition file.

6. The method for processing user-customized data according to claim 1, characterized in that, In step S1, when parsing the user format definition file, a user format definition file parsing algorithm is used. This algorithm is based on configuration file parsing technology, including a JSON parser, to convert the JSON text format user format definition file into a format description model that can be understood and efficiently queried within the EDA tool. The algorithm also includes: Dedicated verification for flag bit systems: Based on general parsing, additional verification steps are added for special flag bit systems to ensure that user-defined formats are valid; Construct a structured format description model: Organize the parsed information into a structured data model that includes a section definition table, a field definition table, and a flag dictionary. The data model adopts a structure including a hash table or a tree structure so that the data can be quickly queried and matched during subsequent data parsing. Semantic checking and conflict detection: Perform preliminary semantic checks on conditional logic and constraint configurations.

7. The method for processing user-customized data according to claim 1, characterized in that, In step S3, the identification of special flag bits and the parsing of mapping data content also involve three core algorithms: Special flag identification algorithm in data: Based on string matching and pattern recognition technology, it dynamically generates or adjusts regular expression patterns or finite state machines according to the flag features recorded in the format description model, performs multi-pattern parallel matching according to predefined priority rules to avoid ambiguity, and checks whether the flag appears in a reasonable context after identification in conjunction with the format description model. Data content parsing and mapping algorithm based on flag bits: Based on syntax analysis technology and attribute grammar, the parsing process is driven by the identified special flag bits as state transition points. The original string field values ​​are automatically converted and verified according to the data type meta-information specified in the field flag bits. The verified field values ​​are dynamically assigned to the internal objects of the EDA tool through reflection mechanism or pre-generated mapping function table. Conditional logic and constraint evaluation algorithm: It calls a small expression evaluation engine to parse user-defined conditional expressions and decides whether to parse specific fields, apply default values, or trigger warnings / errors based on the evaluation results. This algorithm draws on the idea of ​​rule engines and simplifies and optimizes it for data parsing scenarios.

8. A system for processing user-customized data for executing the processing method for user-customized data as described in any one of claims 1-7, characterized in that, include: The flag configuration module is used for defining and configuring special flag systems. It defines a general special flag system specification, which includes the naming rules, types, syntax structure, and parsing priority rules of flags and is extensible. It also provides a user configuration interface, allowing users to define customized data formats based on the special flag system specification and form user format definition files. The customized data generation module is used to generate user-customized data. Users embed standardized special flags into the data according to the customized data format to indicate the data's organizational structure, field meanings, and data types. The data parsing and processing module is used for customized data parsing and processing. The EDA tool loads the user format definition file and parses it to generate a format description model. Then, it loads the customized data, identifies the special flag bits, parses the data content in combination with the format description model, and maps it to the internal data structure of the tool. Finally, it uses the mapped internal data to perform subsequent EDA processing. The verification and feedback module is used for feedback and verification. The EDA tool verifies the parsing process and results, and displays the parsing results, warnings and error messages to the user, allowing the user to adjust the data flags or the user format definition file.

9. A computer device comprising a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing computer code, wherein when the computer code is executed, the method of any one of claims 1 to 7 is performed.

Images