Address allocation method and electronic device

Abstract

The application discloses an address allocation method and an electronic device, relates to the technical field of address allocation, and comprises the following steps: determining a plurality of link entities in a target link by analyzing an electrical connection netlist, constructing a link topology tree, and generating an address allocation rule set; determining logical addresses of the plurality of link entities; determining real allocation addresses of the plurality of link entities; performing address conflict checking on the plurality of link entities based on the real allocation addresses and the logical addresses, and determining an address conflict entity in response to the fact that a link entity does not pass the address conflict checking; determining a modifiable variable set based on address information of the address conflict entity and determining a minimum cost modification solution set. The application can automatically plan and allocate addresses based on the electrical connection netlist, and can realize conflict repair after address conflict checking, so as to solve the problems of insufficient address space utilization, difficult path conflict discovery, low conflict positioning and repair efficiency and the like in the related art.

Description

Technical Field

[0001] This application relates to the field of address allocation technology, and in particular to an address allocation method and electronic device. Background Technology

[0002] In complex electronic systems, multiple link entities communicate via buses or links, and their address planning must simultaneously satisfy multiple constraints, including topology, access paths, protocol constraints, and electrical conditions. However, due to the lack of a unified rule derivation mechanism in the logical address planning process, related technologies often fail to fully identify access constraints, leading to insufficient address space utilization and problems such as path conflicts, misjudgment of reuse conditions, or unreasonable address allocation. Simultaneously, the actual addresses on the hardware side are affected by production factors such as configuration pin mounting, resistor loading / unloading, and component replacement, resulting in inconsistencies with the design logic and causing address conflicts or addressing anomalies during system operation. Faced with these situations, related technologies neither effectively verify the logical addresses against the actual addresses nor promptly locate the root causes of conflicts and provide feasible modification solutions, resulting in low processing efficiency, a large scope of modifications, complex maintenance processes, and further increasing the possibility of introducing new conflicts or potential risks. Summary of the Invention

[0003] This application provides an address allocation method that can automatically plan and allocate addresses based on electrical connection netlists, and determine the minimum cost modification and resolution after address conflict verification, thereby completing the conflict repair. This method aims to at least solve the problems of insufficient address space utilization, difficulty in timely detection of path conflicts, and low efficiency of conflict location and repair in related technologies.

[0004] This application provides an address allocation method, including:

[0005] Parse the electrical connection netlist of the target link to determine multiple link entities in the target link and their corresponding connection relationships, construct a link topology tree based on the connection relationships, and generate an address allocation rule set based on the link topology tree;

[0006] Based on the address allocation rule set, determine the logical addresses of multiple link entities, and configure the loading attributes of multiple link entities based on the logical addresses;

[0007] Obtain the loading attributes of multiple link entities, and determine the actual address of multiple link entities based on the loading attributes;

[0008] Based on the actual address and logical address, address consistency is checked for multiple link entities. If a link entity fails the address consistency check, an address conflict check is performed on the link entity.

[0009] If a link entity fails the address conflict check, the link entity is determined to be an address conflict entity and its actual address is modified.

[0010] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing any of the above-described address allocation methods when executing the computer program.

[0011] This application, by parsing the electrical connection netlist and constructing the link topology tree, can accurately obtain the connection relationships and access levels between link entities, thereby achieving automatic identification of communication access paths. The address allocation rule set generated accordingly can make logical address allocation more in line with actual access constraints, reducing path conflicts and unreasonable allocation. At the same time, by combining the material loading attributes of link entities to determine the actual address, it can identify actual allocation deviations caused by production factors. When checking the consistency and conflict between logical addresses and actual addresses, it can promptly detect and correct addressing anomalies. Thus, this application can improve the accuracy of address planning and the efficiency of conflict handling, reduce modification costs, and solve the problems of insufficient access constraint identification, addressing anomalies caused by inconsistencies between logical and actual addresses, and low conflict repair efficiency in the prior art. Attached Figure Description

[0012] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of an application environment according to an embodiment of this application;

[0014] Figure 2 A flowchart of an address allocation method provided in an embodiment of this application;

[0015] Figure 3 A schematic diagram illustrating the process of constructing a link topology tree and generating logical addresses, provided for an embodiment of this application;

[0016] Figure 4 An example of the application of an address allocation rule set in a real link topology provided in this application embodiment;

[0017] Figure 5 A schematic diagram of a link topology tree with the master control bus as the root node is provided in this application embodiment;

[0018] Figure 6 A schematic diagram illustrating the actual address derivation process based on material loading attributes, provided for an embodiment of this application;

[0019] Figure 7A schematic diagram of an address allocation device and its working process is provided for embodiments of this application;

[0020] Figure 8 This is a schematic diagram of the address allocation process under user interaction provided in the embodiments of this application;

[0021] Figure 9 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0023] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0024] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0025] This application provides an address allocation method that can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network, enabling terminal 102 to upload the electrical connection netlist and production-related data of the target link to server 104. Server 104 performs address planning, address verification, and conflict resolution based on the data and returns the processing results to terminal 102.

[0026] In this application environment, terminal 102 may include, but is not limited to, personal computers, laptops, smartphones, tablets, or portable wearable devices, for displaying the address planning interface, inputting design data, or viewing address repair results;

[0027] Server 104 can be a standalone server or a server cluster composed of multiple servers. By running the method module of this application, it achieves the following functions: parsing the electrical connection netlist to construct a link topology tree, identifying the communication access paths between link entities, generating an address allocation rule set based on the access paths, and determining the logical addresses of multiple link entities; the logical address is sent to the attribute configuration unit, which generates loading attributes based on the logical address to guide actual production mounting; server 104 further determines the actual addresses of multiple link entities based on the loading attributes, performs consistency and conflict checks on the logical address and the actual address, and further constructs a set of modifiable variables based on the conflicting entities and solves the minimum cost modification solution set to complete the address conflict repair of the target link;

[0028] Under the above architecture, the terminal 102 mainly undertakes the functions of data display and interaction, while the server 104 executes the core calculation, reasoning and optimization process, thereby ensuring that the method of this application can run stably and efficiently in large-scale link design and production scenarios; the attribute configuration unit is an independent physical device or production line device in the production process, which is used to configure the loading attributes of multiple link entities according to the logical address issued by the server, and may include: the loading station of the SMT placement machine, the automated programmer, the address configuration fixture, the online workstation (linked with the MES system) or the programmable electronic silo.

[0029] It is worth noting that the electrical connection netlist is a structured data file automatically generated by the link design tool, which contains information such as all device instances, pins, network node names, and wiring relationships in the link; preferably, the electrical connection netlist can be a SPICE netlist, EDIF netlist, Verilog netlist, XML format netlist, or an intermediate format exported by EDA tools (such as Cadence, Altium, Mentor);

[0030] The production netlist is a manufacturing data file used for actual surface mount production. It contains the part number, package, reference number, assembly orientation, mounting status (POP / NP), and BOM information of the device. Preferably, the production netlist is exported from the SMT production line MES system or obtained by expanding the engineering BOM to ensure accurate and reliable mounting status.

[0031] A link entity refers to an independently addressable device or module, such as a sensor, PMIC, memory, I / O expansion, switching device, voltage regulator, etc. Preferably, a link entity can be equivalent to a device instance in the netlist (such as U11, U32) and contains at least one address configuration pin or communication interface.

[0032] In one embodiment, such as Figure 2 As shown, this application provides an address allocation method, including:

[0033] Step 201: Parse the electrical connection netlist of the target link, determine the multiple link entities in the target link and their corresponding connection relationships, construct a link topology tree based on the connection relationships, and generate an address allocation rule set based on the link topology tree;

[0034] Step 202: Determine the logical addresses of multiple link entities according to the address allocation rule set, and configure the loading attributes of multiple link entities based on the logical addresses;

[0035] Step 203: Obtain the loading attributes of multiple link entities, and determine the actual address of multiple link entities based on the loading attributes;

[0036] Step 204: Based on the actual address and logical address, perform address consistency verification on multiple link entities. If a link entity fails the address consistency verification, perform address conflict verification on the link entity.

[0037] Step 205: In response to the link entity failing the address conflict check, the link entity is determined to be an address conflict entity and the actual address of the link entity is modified.

[0038] This embodiment provides an address allocation method. By parsing the electrical connection netlist and constructing a link topology tree, it can accurately obtain the connection relationships and access levels between link entities, thereby achieving automatic identification of communication access paths. The address allocation rule set generated accordingly can make logical address allocation more in line with actual access constraints, reducing path conflicts and unreasonable allocation. At the same time, by combining the material loading attributes of link entities to determine the actual address, it can identify actual allocation deviations caused by production factors. When performing consistency and conflict checks on logical addresses and actual addresses, it can promptly detect and correct addressing anomalies, thereby solving the problems of insufficient access constraint identification, addressing anomalies caused by inconsistencies between logical and actual addresses, and low conflict repair efficiency in the prior art.

[0039] In one embodiment, the electrical connection netlist of the target link is parsed to determine multiple link entities in the target link and their corresponding connection relationships, and a link topology tree is constructed based on the connection relationships, including:

[0040] Analyze the electrical connection netlist to obtain network node information and device instance information;

[0041] Based on network node information and device instance information, extract the identifiers of multiple link entities and their corresponding entity pin connection information;

[0042] Based on the pin connection information of multiple entities, determine the connection relationship between multiple link entities;

[0043] Based on the connection relationship, multiple interconnected link entities are grouped and aggregated to generate multiple link connection subgraphs;

[0044] Based on the preset root node selection rules, the topology root node is determined from multiple link connection subgraphs;

[0045] Starting with the root node of the topology, multiple link entities are expanded level by level according to the electrical connection direction to generate a hierarchical link topology tree.

[0046] Preferably, the parsing of the electrical connection netlist can be performed using a graph database (Graph DB), depth-first search (DFS), or disjoint-set data structure to identify connected components; preferably, the root node selection rules can include: priority for the address master device, priority for the node with the largest access fan-out, and fixed as the system main bus node.

[0047] Specifically, in this embodiment, network node information and device instance information are obtained by parsing the electrical connection netlist, and the link entity identifier and pin connection information are further extracted, which can accurately restore the actual connection structure of the link. At the same time, the interconnected link entities are aggregated to form a connection subgraph, and a topology tree is generated based on the root node selection rule. This enables the link hierarchy relationship to be established automatically and in a structured manner, thereby improving the accuracy of topology construction and providing a reliable structural foundation for subsequent access path identification and rule derivation, avoiding the topology identification errors caused by the traditional reliance on manual understanding of connection relationships.

[0048] In one embodiment, generating an address allocation rule set based on the link topology tree includes:

[0049] Based on the hierarchical structure of the link topology tree, determine the node hierarchy position of the target road entity relative to the root node of the topology;

[0050] Based on the node hierarchical position and the connection relationship between the target link entity and adjacent link entities, the access link from the topology root node to the target link entity is determined, where the access link represents a unique node sequence from the topology root node to a certain link entity;

[0051] Based on the access link of at least two link entities, the communication access path is determined according to the preset path determination rule to characterize the communication relationship between at least two link entities;

[0052] A set of address allocation rules is generated based on the structural characteristics of multiple communication access paths.

[0053] Preferably, the access path is generated using a parent pointer backtracking method of the topology tree, and each node can store the parent node pointer for quick link recovery; in multi-switch scenarios, it is preferable to generate multiple candidate paths based on the switch status table and select the reachable path set from the operation mode table.

[0054] Specifically, in this embodiment, the hierarchical position of the target entity is determined by the hierarchical structure based on the link topology tree, and the access link is derived by combining the connection relationship of its adjacent entities. The real access path from the root node to any link entity can be obtained automatically. Furthermore, the communication access path is determined according to the preset path determination rules, so that the system can accurately represent the communication relationship between link entities, thereby avoiding access misjudgment caused by insufficient path inference, and providing a reliable basis for the subsequent generation of path constraint class address allocation rules.

[0055] In one embodiment, an address allocation rule set is generated based on the structural feature information of multiple communication access paths, including:

[0056] The structural feature information of multiple communication access paths is analyzed to obtain the structural features of multiple paths;

[0057] Based on multiple path structure features, multiple link entities are classified according to path features to obtain multiple path entity groups;

[0058] The link entities connected to the root node in the link topology tree are identified as global child nodes. Based on the global reachability characteristics of the global child nodes, the first address allocation rule is determined to characterize that the logical address of the global child node is unique in the global scope.

[0059] Based on the access reachability, path overlap, and communication conflict risk among multiple link entities in the same group of the path entity group, a second address allocation rule is determined to characterize that the logical addresses of multiple link entities in the same group are different.

[0060] Based on the mutual exclusion of access, the isolation of operating modes, and the non-overlapping of corresponding communication access paths among multiple path entity groups, a third address allocation rule is determined to characterize the address reuse conditions that allow multiple heterogeneous link entities to reuse the same logical address.

[0061] The first address allocation rule, the second address allocation rule, and the third address allocation rule are combined to generate an address allocation rule set.

[0062] It is worth noting that access reachability is used to characterize whether a link entity can be directly or indirectly accessed by the root node of the topology in the current topology structure and switch state. If there is a continuous and reachable access link from the root node of the topology to the entity, the entity is considered to have access reachability. This can be determined by performing a depth traversal of the link topology tree and combining the switch state table or mode configuration table.

[0063] Path overlap describes the degree of overlap between the communication access paths of two entities in the topology. It is an important basis for determining path uniqueness and is calculated by comparing the access link sequences from the root node to the two entities and calculating their longest common prefix (LCP) length. For example, when the LCP length is greater than zero, the two access paths are considered to have overlapping segments. Furthermore, the larger the LCP length, the higher the path overlap, and the greater the likelihood of communication conflicts. Path overlap can be determined through link sequence alignment, path node encoding, or path hash vector generation.

[0064] Communication conflict risk is used to characterize the possible address conflicts, bus contention, or protocol conflicts that may occur between multiple link entities in the same communication domain. When two or more entities are located in a shared access link and there are duplicate addresses, path overlaps, or bus risk items identified in historical fault records, they are considered to have communication conflict risk. This risk can be identified based on path overlap, bus load model, and protocol constraints.

[0065] Access mutual exclusion describes the possibility that multiple link entities cannot be accessed simultaneously due to their physical structure or switch configuration. For example, when two entities are on different switch channels, and only one of the switch channels is allowed to be on at any given time, their access is considered mutually exclusive. Another example is that some link structures only allow access to local devices under a specific modulation mode, while other devices cannot access them under that mode, which also constitutes access mutual exclusion. It can be determined through switch channel configuration tables, device mutual exclusion matrices, or mode switching strategies.

[0066] Operating mode isolation is used to describe the situation where two or more link entities are accessed separately in different operating modes, and there is no situation where they are accessed simultaneously in the same operating mode. For example, if the operating modes of the target system are divided into multiple mutually exclusive functional modes (such as charging mode, communication mode, debugging mode, etc.), and certain entities are only enabled in their own exclusive operating modes, then these entities are considered to have operating mode isolation; it can be identified through a mode-entity mapping table.

[0067] The non-overlapping nature of communication access paths describes that the communication access paths of two link entities on the topology tree do not share any parent node, switch node, or link segment, that is, the communication links are completely independent; for example, if the length of the longest common prefix (LCP) of the access path sequences of two entities is zero, then their access paths are considered to be non-overlapping; it can be determined based on access link sequence comparison, path tree structure analysis, or path hash encoding.

[0068] Specifically, in this embodiment, by analyzing and classifying the structural features of multiple communication access paths, link entities can be automatically grouped according to access levels, overlap characteristics, and communication risks. At the same time, based on the access characteristics of different groups, global uniqueness rules, path uniqueness rules, and address reuse rules are generated respectively, so that logical address allocation can fully reflect actual constraints such as access topology, path conflicts, and mode isolation. In general, the generation of this rule set avoids rule omissions or constraint conflicts caused by traditional empirical planning, and significantly improves the rationality and controllability of address planning.

[0069] In one specific embodiment, to enable the address allocation rule set to be executed automatically in the target link topology, this application further refines the process of generating the address allocation rule set based on the structural feature information of multiple communication access paths, specifically including:

[0070] First, the structural features of multiple communication access paths are analyzed to obtain several path features that characterize the path structure.

[0071] Then, multiple path entities are grouped based on path characteristics to form multiple path entity groups; on this basis, three types of address allocation rules are constructed respectively: global uniqueness rules, path uniqueness rules, and address reuse rules, and finally the three types of rules are combined to form a complete set of address allocation rules;

[0072] The first address allocation rule is used to constrain the address uniqueness of global child nodes. Global child nodes are link entities in the link topology tree that are directly connected to the root node of the topology and can be accessed in any operating mode. They typically include first-layer devices located on the main bus and other fixed devices that can be accessed without relying on switch states. To this end, a global access dataset is established to record the device identifier, address configuration pin information, and candidate logical addresses of each global child node. A global uniqueness constraint is applied to this dataset so that the logical addresses of any two link entities in the global access dataset are not allowed to be duplicated, thus ensuring that the master controller can uniquely address each entity globally.

[0073] The second address allocation rule is used to constrain the addresses of multiple link entities within a path entity group to be different. This rule is set based on the access path structure of the target link and is applicable to multiple link entities whose access paths overlap, including multiple slave devices located on the same bus, downstream devices passing through the same switch channel, and multiple entities whose access paths have a common prefix. To this end, a path feature dataset is constructed for each access path, including the access link node sequence, the bus to which it belongs, the switch channel number it passes through, and the path overlap. The path overlap relationship is determined based on the longest common prefix, and link entities with path overlap are assigned to the same path entity group. A path uniqueness constraint is applied in each path entity group so that the logical addresses of entities in the same group cannot be repeated within the path range, in order to avoid addressing ambiguity when the master controller accesses shared links.

[0074] The third address allocation rule is used to determine the address reuse conditions to improve the overall utilization of the logical address space. For link entities located between different path entity groups that have mutual access exclusion or operational mode isolation, or whose communication access paths do not overlap, they can reuse the same logical address. To this end, reuse candidate pairs are generated based on the mutual access exclusion attributes between path entity groups, the independence of operational modes, and the non-overlapping access paths. Without violating the aforementioned global uniqueness rules and path uniqueness rules, the reuse candidate pairs are assigned the same logical address, so that address resources can be shared between different access domains.

[0075] In a preferred embodiment, the specific settings for various rules may further include: for global uniqueness, establishing a global access form for all link entities directly connected to the main bus, and ensuring that the logical addresses of each entity in the form are different from each other; for path uniqueness, constructing an independent path dataset for each access path, and for slave devices directly connected to the main bus, the path dataset includes the master device, the slave device, and other slave devices belonging to the same main line; for those located in I... 2 After the C switch is applied, the slave device's path dataset includes the master device, I... 2 The C switch, the target slave device, and other slave devices under the same switch channel are required to have different logical addresses for all devices in the same path dataset. For address reuse, when any two different devices are included in the above globally unique dataset or any path dataset, they are allowed to reuse the same logical address.

[0076] By setting the above-mentioned subordinate rules, the address allocation rule set generated by this application can not only accurately reflect the actual constraints of the link topology and access path, but also maximize the use of available address resources while ensuring the correctness of addressing, providing a clearly defined and verifiable constraint basis for the subsequent logical address solution process.

[0077] In one embodiment, determining the logical addresses of multiple link entities based on an address allocation rule set includes:

[0078] Based on the address allocation rule set, determine one or more address allocation rules that match multiple link entities;

[0079] Based on one or more address allocation rules matched by the link entity, determine the address constraints corresponding to the link entity. The address constraints shall include at least one or more of the following: global uniqueness constraint, path uniqueness constraint, and address reusability constraint.

[0080] Based on multiple address constraints and the set of available logical addresses in the address space, the logical addresses of multiple link entities are solved to obtain a set of logical addresses that satisfy multiple address constraints, including:

[0081] Select multiple link entities corresponding to the global uniqueness constraint as the first link entity;

[0082] Unoccupied logical addresses are selected sequentially from the available logical address set as first candidate logical addresses, and global conflict detection is performed on multiple first candidate logical addresses. The global conflict detection is used to determine whether the candidate logical address is duplicated with any allocated global child node address.

[0083] If a conflict is detected, an unoccupied logical address is selected from the set of available logical addresses to replace the conflicting first candidate logical address, until multiple first link entities each have a unique first candidate logical address, and multiple first candidate logical addresses are deleted from the set of available logical addresses to avoid reuse in subsequent steps;

[0084] Select multiple link entities corresponding to the path uniqueness constraint as the second link entity;

[0085] Based on the topological order of the path entity group to which the second link entity belongs (e.g., according to the access link depth, the position of the device in the link, or the path node number), logical addresses are sequentially selected from the set of available logical addresses as the second candidate logical addresses of the second link entity. Intra-group conflict detection is performed on multiple second candidate logical addresses within the path entity group. Intra-group conflict detection is used to determine whether there are duplicate addresses or violations of path uniqueness rules within the same path entity group.

[0086] If a conflict is detected, a new logical address is selected from the set of available logical addresses to replace the conflicting second candidate logical address, until multiple second link entities have corresponding second candidate logical addresses, and multiple second candidate logical addresses are deleted from the set of available logical addresses.

[0087] Based on address reuse constraints, a reuse entity group that satisfies the address reuse conditions is determined from multiple first link entities and multiple second link entities. The address reuse conditions include, but are not limited to: any two entities in the reuse entity group do not exist simultaneously within the global uniqueness range; any two entities in the reuse entity group do not belong to the same path entity group; any two entities in the reuse entity group satisfy at least one of access mutual exclusion, operation mode isolation, or access path non-overlap.

[0088] Select at least one link entity from the multiplexing entity group as the third link entity, and use the logical address of the third link entity as the multiplexing address;

[0089] The reused address is assigned to the remaining link entities in the reused entity group, excluding the third link entity, and the original logical address of the remaining link entities is added to the set of available logical addresses for possible re-solution in the future.

[0090] Preferably, global conflict detection or intra-group conflict detection can be performed using a hash structure, a path conflict matrix, or a reachability matrix.

[0091] Specifically, in this embodiment, by determining the constraints of link entity matching according to the rule set, and solving the global uniqueness, path uniqueness and address reuse conditions in stages within the available logical address space, the allocation of logical addresses can strictly follow the real constraints of the access structure; by gradually detecting conflicts and avoiding them by replacing candidate addresses, the allocation process has self-correction capabilities. At the same time, by improving the address space utilization through address reuse logic, the probability of logical address conflicts can be reduced, and the accuracy of allocation and resource utilization efficiency can be improved.

[0092] like Figure 3 As shown, in one embodiment, the process of constructing the link topology tree and generating logical addresses includes: parsing the electrical connection netlist of the target link to obtain network node information, device instance information, and pin connection relationships of each link entity; based on the parsing results, aggregating and grouping interconnected link entities, and constructing a hierarchical link topology tree of the target link according to a preset root node selection rule, thereby forming an access hierarchy that can truly reflect the electrical connection structure; after constructing the link topology tree, generating an address allocation rule set for logical address planning according to the communication access paths between link entities, the rule set may include global uniqueness rules, path uniqueness rules, and address reuse rules, etc.; and solving the logical addresses of multiple link entities according to the rule set to obtain initial logical address allocation results that satisfy access constraints.

[0093] After generating the logical address, a conflict detection is performed to determine whether there is a conflict between the logical address and the path sharing scope. If the detection result shows no conflict, the current logical address allocation is considered valid, thus completing the logical address allocation of multiple link entities. If a conflict is detected, the address allocation rule set is reapplied to adjust the logical address of the relevant link entities until the conflict is eliminated.

[0094] Therefore, this embodiment can automatically complete the logical address planning of link topology tree construction, rule deduction and conflict self-correction while ensuring that access topology constraints are met, which significantly improves the accuracy and automation of address allocation.

[0095] In one embodiment, an example of the application of the address allocation rule set in a real link topology is as follows: Figure 4 As shown, where, Figure 4 The left side shows an example of an error that may occur when the address allocation rule set is not applied correctly, and the right side shows an example of correct logical address planning based on the address allocation rule set proposed in this application.

[0096] In the erroneous example, link entity 1 and link entity 3 are both assigned logical address 0x50. Both link entity 1 and link entity 3 are within the reach of the same access link, and the access path of link entity 3 passes through link entity 2 and link entity 0. Therefore, according to the path uniqueness rule of this application, since link entity 1 and link entity 3 have overlapping paths in the same communication access path, their logical addresses should be kept separate to avoid access conflicts, which would prevent the system from distinguishing the access targets of link entity 1 and link entity 3.

[0097] In the correct example, the access characteristics of the link entities were analyzed according to the address allocation rule set of this application: Although both link entity 1 and link entity 3 can be accessed by the root node link entity 0, their communication access paths have a shared segment, so they fall within the scope of path uniqueness constraints. Based on this, when allocating a logical address for link entity 3, the system avoids the address 0x50 already occupied by link entity 1 and selects a new logical address 0x51 from the available address space, thereby ensuring that all link entities within the path have mutually non-conflicting logical addresses.

[0098] Therefore, as can be seen from the comparison in this embodiment, the address allocation rule set of this application can effectively identify possible access conflicts in the same path, avoid addressing ambiguity caused by repeated logical addresses, ensure that the address allocation process meets communication topology constraints, and improve the reliability and consistency of system access.

[0099] like Figure 5As shown, in one embodiment, the address allocation method of this application is applied to an exemplary link topology, wherein the structure uses a main control bus as the root node of the topology, and multiple link entities of different types are connected to it, including switching devices, sensors, memory, power management chips, and voltage regulators, etc. On the left side of the main control bus, switch 1 (logic address 0x70) is connected, and power management chip 1 (fixed logical address 0x48) and switch 2 (logic address 0x72) are further connected below switch 1. Sensor 2 (logic address 0x30) and voltage regulator (logic address 0x31) are connected to the branch below switch 2, and the two are respectively attached as leaf nodes at the end of the same path. On the right side of the main control bus, sensor 1 (logic address 0x51) and memory (logic address 0x50) are connected in sequence. At the same time, power management chip 2 (logic address 0x22) is connected in the middle of the main control bus and arranged in parallel with the switch path bypass.

[0100] The above structure clearly constructs a hierarchical topology tree of the link: the main control bus is located at the root node of the topology, and various functional devices form a multi-branch structure according to their electrical connection relationships; switching devices form intermediate layer nodes, while functional devices such as sensors, voltage regulators and memory form leaf nodes.

[0101] In one embodiment, obtaining the loading attributes of multiple link entities and determining the actual addresses of the multiple link entities based on the loading attributes includes:

[0102] Obtain the address configuration pins of multiple link entities, and determine the configuration elements connected to the address configuration pins based on the electrical connection netlist. Here, address configuration pins refer to hardware pins used to adjust device addresses, such as I... 2 The A0, A1, and A2 pins of device C;

[0103] Obtain and parse the production netlist of the target link to determine the loading attributes that characterize the mounting status of the configuration components;

[0104] Based on the loading attributes of the configuration components, determine the actual level state of multiple address configuration pins, and map the actual level state to the variable address bits in the address field of the corresponding link entity;

[0105] The variable address bits are combined with the preset fixed address bits of the link entity to obtain the hardware address field of the link entity, and the hardware address field is determined as the actual address of the link entity, so as to serve as the physical addressing identifier of the link entity on the target link.

[0106] Specifically, in this embodiment, the mounting status of the configuration element is obtained by parsing the production netlist of the link, and the actual level and variable address bits of the address configuration pin are determined accordingly. Under actual production conditions, the actual hardware address of the link entity can be accurately recovered. The hardware address field is obtained by combining the variable address bits and the fixed address bits, which can ensure that the actual address truly reflects the hardware status, thereby improving the accuracy of subsequent consistency verification and avoiding the problems of inaccurate or missing address recovery in the traditional manual verification method.

[0107] like Figure 6 As shown, in one embodiment, the actual address derivation process based on loading attributes provided by this application can automatically deduce the actual logical address of the link entity according to the component mounting information. Taking the link entity U11 as an example, its address pins A0 and A1 are connected to the positive power supply or ground through a resistor network, respectively. The mounting or unmounting state of the resistor element determines the level of the corresponding pin, thereby affecting the final address derivation result.

[0108] like Figure 6 As shown on the left, address pin A0 is connected to the positive power supply through resistor R1 and to ground through resistor R2; address pin A1 is connected to the positive power supply through resistor R3 and to ground through resistor R4. According to the material loading attribute information of this embodiment, resistor R1 is mounted and resistor R2 is not mounted. Therefore, the A0 terminal is pulled up to the positive power supply, and its logic level is 1; resistor R3 is not mounted and resistor R4 is mounted. Therefore, the A1 terminal is pulled down to ground, and its logic level is 0.

[0109] like Figure 6 As shown on the right, the system determines A0=1 and A1=0 based on the above mounting information, and further combines the high-order fixed address field of link entity U11 to concatenate the logical address field of U11. In this embodiment, the high-order address field of U11 is "10011". After combining the variable address bits A1A0, the complete binary address "1001101" is obtained. The system converts the binary address into hexadecimal format to obtain the actual device address of U11 as 0x4D.

[0110] In one embodiment, address consistency verification is performed on multiple link entities based on the actual address and the logical address, including:

[0111] Compare the logical addresses of multiple link entities with their corresponding actual addresses to determine whether the entities pointed to by the logical addresses and actual addresses are consistent.

[0112] In response to consistency, the link entity is determined to have passed the address consistency check and is thus identified as an address-consistent entity.

[0113] In response to inconsistency, the link entity is determined to have failed the address consistency check and is identified as an address misalignment entity.

[0114] In response to a link entity failing the address consistency check, an address conflict check is performed on the link entity, including:

[0115] Based on multiple rule set address verification items obtained by parsing the address allocation rule set, rule set conflict verification is performed on the actual addresses corresponding to multiple address misaligned entities in turn. If the address misaligned entity fails the rule set conflict verification, the address misaligned entity is determined to be the first address conflict entity.

[0116] Based on the historical fault records of the target link and the bus protocol attribute parsing, multiple hardware risk address verification items are obtained. Hardware risk conflict verification is performed on the actual addresses corresponding to multiple link entities in turn to determine whether multiple link entities meet the physical communication environment restrictions of the target link. If a link entity fails the hardware risk conflict verification, the link entity is determined to be the second address conflict entity.

[0117] The first address conflict entity and the second address conflict entity are combined to obtain the address conflict entity.

[0118] Specifically, in this embodiment, by setting a consistency check between the logical address and the actual address, address misalignment entities can be identified promptly and accurately when address configuration errors, address drift, or addressing anomalies occur, improving the accuracy of address anomaly detection and reducing the error of traditional methods that rely on indirect judgment based on fault manifestations. Simultaneously, based on rule set address verification items generated from the address allocation rule set and hardware risk address verification items obtained from historical fault records and bus protocol attribute parsing, conflict checks are performed on link entities from both rule constraints and hardware communication environment levels, achieving comprehensive coverage of address conflicts. This not only detects explicit conflicts that violate rules but also identifies implicit conflicts caused by potential protocol-sensitive addresses or high-risk address combinations. By combining the first address conflict entity obtained from rule set conflict verification with the second address conflict entity obtained from hardware risk conflict verification, the link entities with genuine conflict risks can be accurately located, effectively reducing the scope of subsequent address modifications, avoiding unnecessary address reconfiguration, and reducing engineering modifications. Furthermore, by introducing historical fault experience and protocol risk information, risk factors can be identified in advance before address configuration causes communication failures, improving the system's foresight and stability, thereby reducing debugging cycles and lowering the probability of rework during mass production.

[0119] In a preferred embodiment, based on multiple hardware risk address verification items obtained from historical fault records of the target link and bus protocol attribute parsing, hardware risk conflict verification is performed sequentially on the actual addresses corresponding to multiple address-consistent entities, including:

[0120] Obtain the historical fault record library corresponding to the target link. The fault record library includes address conflict fault information, abnormal access logs and bus reset records collected during production verification, joint debugging and mass production testing.

[0121] Extract historical fault risk items related to address risk from the fault record database, including but not limited to: address ranges that are prone to conflict with broadcast addresses, address combinations that have caused communication congestion, and address bit patterns related to device response instability.

[0122] The risky address entries at the protocol layer are obtained by parsing bus protocol attributes. These bus protocol attributes include: reserved address ranges, special addressing intervals prohibited by the protocol, protocol broadcast addresses, device default addresses, and sensitive address segments related to specific addressing timings. For example, for I... 2 The C / SMBus bus can parse broadcast or reserved addresses such as 0x00, 0x01, 0x02, and 0x7F from the protocol specification and add them to the risk address set. For PMBus, it can further include address fields that conflict with the page selection mechanism.

[0123] Historical fault risk items are merged with protocol risk items to construct a set of hardware risk address verification items, which are then indexed by device type, bus domain, and access path to enable independent risk comparisons to be performed on entities with the same address.

[0124] For each link entity, based on its access path, device type, and actual measured address, a subset of its corresponding risk rules is selected from the risk item set.

[0125] Perform risk comparison on the actual address of each link entity, including but not limited to: determining whether the actual address falls within the protocol reserved range; determining whether the actual address matches the conflict address marked in the historical fault record; determining whether there is known bus interference or load risk in the combination of the actual address and the address of other devices in the same access domain; and determining whether the actual address has a potential conflict relationship with the broadcast command or addressing command in the current operating mode.

[0126] If the actual address of a link entity meets any of the judgment conditions of a risk item, the entity is determined to have failed the hardware risk conflict verification and is marked as a second address conflict entity; otherwise, the entity is determined to be a safe entity that has passed the verification.

[0127] By summarizing all entities with second address conflicts, a basis is provided for subsequently determining the set of modifiable variables and constructing the minimum cost modification solution set.

[0128] Through the above steps, this preferred embodiment can introduce hardware risk identification based on actual testing experience and protocol constraints, in addition to logical consistency verification and verification under the address allocation rule set. This enables the system to detect potential physical layer conflicts or protocol layer anomalies in advance, thereby improving the reliability and engineering applicability of address planning.

[0129] In one embodiment, modifying the actual address of the address conflicting entity includes:

[0130] Based on the address information of one or more conflicting entities, a set of modifiable variables is determined, and based on the set of modifiable variables and the set of address allocation rules, a minimum cost modification solution set is determined, so as to modify the actual address of the conflicting entity based on the minimum cost modification solution set.

[0131] The set of modifiable variables is determined based on the following steps:

[0132] Extract the address information of multiple entities with address conflicts, obtain the corresponding logical address field and actual address field, and generate an address conflict dataset;

[0133] Based on the type of the address conflicting entities, the address conflict dataset is divided into a first address conflict dataset and a second address conflict dataset.

[0134] The first address conflict dataset is parsed, and the positions of the fields that violate the rules are identified according to the constraint types of the address allocation rule set. These fields are designated as rule conflict fields. Rule conflict fields include, but are not limited to: fields where the logical address field and the actual address field do not point to the same value, fields that violate global uniqueness constraints, fields that violate path uniqueness constraints, and fields that violate address reuse constraints.

[0135] The second address conflict dataset is parsed, and based on multiple hardware risk address verification items, the actual configured address field of the corresponding hardware risk is determined as the hardware risk address field.

[0136] Based on the topological association and resource coupling relationship of multiple address conflicting entities, identify the associated entities that have addressing dependencies with multiple address conflicting entities, and determine the actual address field of the associated entities as the associated address field;

[0137] The rule conflict field, hardware risk address field, and associated address field are summarized, and the non-adjustable fields are removed based on the structural characteristics and changeable range of the target link to obtain the set of modifiable variables. Preferably, the non-adjustable fields include, but are not limited to: chips with fixed hardware addresses (such as EEPROM), non-rewritable OTP addresses, and device reference numbers locked by BOM.

[0138] Specifically, in this embodiment, by extracting logical fields and actual fields from conflicting entities and generating a conflict dataset, and then classifying them into rule conflict fields and hardware risk fields according to conflict type, the specific field locations causing the conflict can be accurately identified. Based on structural characteristics and changeable range, non-adjustable fields are eliminated, resulting in a truly operable set of modifiable variables. This ensures that subsequent modification schemes are only applied to necessary fields, avoiding the problems of excessive scope and misjudgment of modification objects in traditional manual analysis, thereby improving the targeting and efficiency of conflict remediation.

[0139] In one embodiment, based on the topological association and resource coupling relationships of multiple address conflicting entities, associated entities that have addressing dependencies with the multiple address conflicting entities are identified, and the actual address field of the associated entity is determined as the associated address field, including:

[0140] Based on the material loading attributes of multiple link entities in the target link, determine the structural information of the target link. The structural information includes at least: addressing topology, bus segmentation information, device hierarchy relationship, and resource coupling relationship.

[0141] Based on structural information, determine the parent-child relationship, sibling sharing relationship, or cross-node association relationship of multiple entities with address conflicts on the topological path;

[0142] Identify entities that have addressing dependencies with multiple entities that conflict with each other in the same addressing path, the same bus domain, or the same functional resource domain, and designate them as associated entities;

[0143] Extract the actual address fields of multiple related entities to characterize the candidate address locations that may affect address conflict resolution, and use the actual address fields as related address fields.

[0144] Specifically, by introducing associated entities identified based on topological relationships and resource coupling relationships during the determination of the set of modifiable variables, this embodiment can provide additional sources of modifiable fields when the address conflict entity itself is not adjustable, the adjustment cost is high, or it is limited by hardware. This significantly improves the flexibility and optimization capability of address conflict resolution. By identifying associated entities that have addressing dependencies with the conflict entity and adding their actual address fields as associated address fields to the candidate range, the system can find the optimal correction scheme for the conflict in a larger but still controlled search space, resulting in smaller final modification amount, lower risk, and more feasible adjustment process. Furthermore, since associated entities are usually in the same bus domain, the same addressing path, or the same functional resource group as the conflict entity, adjusting their address fields can often rebalance the local address distribution at a lower cost, avoiding modifications to critical devices or fixed address devices. This reduces the scope of impact on hardware and reduces the pressure of changes to production, BOM, or firmware. This not only improves the success rate of address conflict resolution but also enhances the system's adaptability and robustness in the face of complex topologies, multi-slave shared bus, or cross-node addressing environments.

[0145] In one embodiment, determining the minimum-cost modification solution set based on the set of modifiable variables and the set of address allocation rules includes:

[0146] Based on a set of modifiable variables, multiple initial address modification operations are constructed. Each initial address modification operation includes at least one adjustment operation of the actual address field of one or more link entities. The set of modifiable variables is used to identify the actual address fields that are allowed to be adjusted in the target link, including but not limited to: slave device address bits in writable registers, address pins that can be selected by jumpers / pads, and downstream device address fields that can be configured and adjusted by multi-channel switches / MUX.

[0147] Based on the hardware modification scope of the target link, the address allocation rule set, and multiple hardware risk address verification items, multiple initial address modification operations are constrained and filtered to eliminate invalid modification operations. The hardware modification scope is used to limit the types of physical modifications that can be performed, such as whether it is allowed to change the device pad configuration, whether it is allowed to add or replace devices, and whether it is allowed to swap switch channels. Furthermore, when filtering initial address modification operations, the address allocation rule set (including global uniqueness constraints, path uniqueness constraints, and address reuse constraints) is used to check whether the modification operation will cause a new address conflict. The hardware risk address verification items are used to check whether the modified address falls into a risk address range and whether it matches a high-risk combination in the existing fault record. If an initial modification operation does not meet the hardware modification scope or violates any rule, it is determined to be an invalid operation and is eliminated.

[0148] Based on the multiple initial address modification operations retained after filtering, multiple candidate address modification solution sets are constructed. Each candidate address modification solution set consists of a set of modification operations that can take effect simultaneously and do not conflict with each other, and can make the target link satisfy the address allocation rule set after execution.

[0149] The construction of the candidate address modification solution set can be based on depth-first search, breadth-first search, backtracking search, or heuristic search strategies.

[0150] Based on the configuration adjustment cost, hardware modification cost, and link downtime cost of the candidate address modification solution set, generate the address modification cost of multiple candidate address modification solution sets.

[0151] Select the candidate address modification solution set corresponding to the minimum address modification cost, and determine it as the target address modification scheme.

[0152] Specifically, in this embodiment, an initial modification operation is constructed based on a set of modifiable variables, and validity filtering is performed by combining hardware modification scope, rule set, and risk verification. This ensures that all candidate modification schemes meet the actual engineering constraints. Furthermore, the candidate schemes are quantitatively evaluated based on the configuration adjustment cost, hardware modification cost, and link downtime cost, enabling the system to automatically select the modification solution set with the lowest overall cost. This minimizes the modification scope while ensuring security, significantly improves conflict resolution efficiency, and avoids the large-scale changes and high-cost risks caused by traditional manual or global backtracking modifications.

[0153] In a preferred embodiment, the construction of the candidate address modification solution set includes:

[0154] Based on the multiple initial actual address modification operations retained after filtering, the current address configuration state of the target link is modeled, each actual address modification operation is regarded as an optional decision variable, and the original address configuration state without any modification operation is used as the initial state for the search.

[0155] The initial actual address modification operations are sorted according to heuristic rules. Heuristic rules may include: prioritizing modification operations that act on the address conflicting entity itself or its strongly related entities, prioritizing operations with lower single hardware modification costs, and prioritizing local adjustment operations that are less likely to introduce new conflicts, so as to improve the efficiency of subsequent search to construct candidate modification solution sets.

[0156] During the search process, a strategy combining depth-first search with a backtracking mechanism is adopted. Starting from the initial state, untried actual address modification operations are selected sequentially, the operation is added to the current set of modified solutions to be built, and the operation is applied to the current state to obtain a new address configuration state.

[0157] After each new actual address modification operation is added, a constraint check is performed on the current partial modification solution set. Specifically, this includes: checking whether the current address configuration meets the global uniqueness constraint, path uniqueness constraint, and allowed address reuse constraint based on the address allocation rule set; checking whether the current cumulative hardware operations exceed the allowed physical modification type or modification quantity limit based on the hardware modification range; detecting whether the actual address in the current state has entered a risk address segment or formed a high-risk combination pattern based on the hardware risk address check item; if any constraint is not met, the current search branch is determined to be an invalid branch, backtracking is performed, the most recently added actual address modification operation is undone, and other optional operations at the same level are tried.

[0158] If the actual address modification operations contained in the current partial modification solution set can eliminate the conflict state of all address conflicting entities, and the target link meets the requirements of address allocation rule set, hardware modification range and risk verification in this state, then the set of non-conflicting and simultaneously executable actual address modification operations is marked as a legal candidate address modification solution set and stored in the candidate modification solution set set.

[0159] Furthermore, during the search process, pruning strategies can be used to reduce ineffective search overhead. For example, if the estimated total cost of the current partial modified solution set (based on the sum of the cost of the currently selected operation and the estimated minimum possible cost of the remaining conflicting entities) is no less than the upper bound of the cost of the minimum cost solution in the currently discovered candidate modified solution set, then the search branch is terminated early; or when a partial modified solution set is completely dominated by another partial solution set with a lower cost on the covered set of conflicting entities, the search branch corresponding to that partial solution set is directly discarded.

[0160] Furthermore, an upper limit can be set on the number of candidate address modification solutions or stopping conditions such as search depth and search time. When the number of found candidate modification solutions reaches the threshold, or the search meets the preset stopping conditions, the search process is terminated to obtain a set of candidate address modification solutions that meet the engineering constraints, providing input for subsequent selection of the minimum cost modification solution set based on cost evaluation.

[0161] Specifically, this embodiment introduces depth-first search combined with backtracking, heuristic sorting, and pruning strategies when constructing the candidate address modification solution set. This allows the search process for modification schemes to proceed efficiently within a controlled range. Thus, while ensuring that all modification operations meet the requirements of address allocation rules, hardware modifiability, and risk address verification, a set of legal and engineering-feasible candidate modification solutions is quickly generated. Heuristic sorting prioritizes the exploration of low-cost modification paths with minimal local impact, and pruning strategies terminate invalid branches early, significantly reducing the search space and computational overhead, and improving the efficiency of solution set generation. Therefore, this embodiment can effectively converge to a high-quality candidate solution set in complex link environments, laying the foundation for subsequent selection of the minimum-cost modification scheme and greatly improving the automation and reliability of address conflict repair.

[0162] In one specific embodiment, address modification costs for multiple candidate address modification sets are generated based on the configuration adjustment cost, hardware modification cost, and link downtime cost of the candidate address modification solution set, including:

[0163] Obtain preset parameters for cost calculation, including: unit cost parameters for configuration adjustment cost, unit cost parameters for hardware modification cost, unit time cost parameters for link downtime cost, and weight coefficients used to characterize the relative importance of various costs in the engineering scenario;

[0164] Among them, configuration adjustment cost is used to measure the scale of content that needs to be updated synchronously in firmware, scripts or configuration files due to actual address modification; hardware modification cost is used to assess the actual cost of implementing physical layer modifications; link downtime cost is used to assess the time loss caused by downtime, maintenance or restart caused by address modification process;

[0165] For each candidate address modification solution set, based on the specific actual address modification operations contained in the solution set, the number of firmware configuration items, address mapping table entries, initialization script parameters or system configuration file entries that need to be adjusted synchronously is counted, and the corresponding configuration adjustment cost is calculated. Preferably, the configuration adjustment cost can be obtained by multiplying the number of the above-mentioned change items by the corresponding unit cost parameter and then summing them up.

[0166] Next, for each candidate address modification solution set, based on the hardware modification operations it contains, the number of operations required to perform the physical modification is counted, such as the number of jumper / pad configuration changes, the number of switch channels or MUX paths reconfigured, the number of device address pin adjustments, and the number of devices to be added or replaced, etc., and the hardware modification cost is calculated accordingly; preferably, the number of different hardware operation types can be multiplied by the corresponding unit cost parameter and summed to obtain the complete hardware modification cost;

[0167] For each candidate address modification solution set, the link shutdown cost is calculated based on information such as the expected downtime, number of restarts, test verification time, or production line downtime required to implement the solution set. Preferably, the link shutdown cost can be obtained by multiplying the expected downtime by the unit time cost parameter. If necessary, the additional time cost caused by multiple power-on, reloading configuration, or repeated testing processes can be further added to more accurately reflect the actual shutdown cost.

[0168] In some implementations, in order to unify the dimensions of different cost items, the configuration adjustment cost, hardware modification cost, and link downtime cost can be normalized and scaled to a uniform numerical range before subsequent weighted summation.

[0169] For each candidate address modification solution set, the configuration adjustment cost, hardware modification cost, and link downtime cost are linearly combined according to the preset weighting rules to obtain the address modification cost of the candidate address modification solution set, thereby providing a quantifiable comparison basis for selecting the address modification scheme with the minimum cost.

[0170] In a preferred embodiment, after determining the minimum cost modification solution set, the minimum cost modification solution set is sent to the attribute configuration unit so that the attribute configuration unit adjusts the actual address fields of multiple link entities based on the minimum cost modification solution set.

[0171] After the adjustment is completed, the actual addresses of multiple link entities are reacquired and address conflict verification is performed again until the actual addresses of all link entities in the target link pass the address conflict verification.

[0172] Based on the actual address of the link entity after conflict checking, update the corresponding logical address and update the electrical connection netlist to enable subsequent address configuration of link entities of the same type of link.

[0173] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0174] like Figure 7 As shown, embodiments of this application also provide an address allocation device, which is used to automatically generate a device address file that can be used for programming or configuration based on the electrical connection netlist and the production netlist. The address allocation device includes: a netlist parsing module, a topology management module, an address allocation module, a conflict detection module, and an output module. The modules work together through data interaction to complete the address planning process.

[0175] In this embodiment, the electrical connection netlist and the production netlist are used as input data and are first fed into the netlist parsing module. The netlist parsing module is used to obtain information such as link entities, connection relationships, hierarchical structure, device attributes, and material loading attributes from the input netlists, and provides the parsed structured data to the topology management module;

[0176] The topology management module analyzes and models the connection relationships between entities in a link, constructing a hierarchical topology tree or set of access paths for the link, providing path-level basic information for subsequent address allocation. Based on the topology relationships, the topology management module sends the access paths, parent-child structures, and reachability relationships of each link entity to the address allocation module;

[0177] The address allocation module performs logical address generation, reusability analysis, and address mapping processing on the link structure provided by the topology management module according to a preset address allocation rule set. During address generation, the address allocation module interacts with the conflict detection module. The conflict detection module verifies the address results generated by the address allocation module to determine whether address conflicts exist within the same path or conflict domain. If a conflict is detected, the conflict information is returned to the address allocation module for adjustment or reallocation.

[0178] Once all link entities have completed address planning and there are no conflicts, the address allocation module submits the final address results to the output module. The output module is used to export the allocated device addresses as configuration files and can optionally generate a minimal address modification set compatible with the programming tool, so as to facilitate device programming or address hardening in the actual production environment.

[0179] Through the above steps, the address allocation device provided in this embodiment can realize automated address planning for complex link systems, reduce manual configuration costs, and improve the accuracy and consistency of the address allocation process.

[0180] like Figure 8 As shown, in one embodiment, the address allocation process under user interaction includes:

[0181] Users upload link netlist files through the system interface. After receiving the netlist, the system interface submits the netlist file to the conflict verification module to start the verification process. The conflict verification module parses the link structure and entity relationships based on the netlist content, identifies potential address conflict risks in the netlist, and returns a set of address conflict entities to the system interface.

[0182] The system interface displays the received address conflict entities, and after user confirmation, modifiable constraints (such as adjustable pins, reusable address fields, priority strategies, etc.) are input to the address allocation module. The address allocation module performs address generation and optimization based on the set of modifiable constraints provided by the user, and returns the generated minimum modified dataset to the system interface.

[0183] After receiving the minimized modified dataset, the system interface calls the results output module to generate a final report. The report includes the address conflict resolution results, the actual allocated device address information, the netlist fields that need to be modified, and the final configuration file for use by the system or production line. The results output module sends the report to the system interface, which then displays it to the user and allows for subsequent export.

[0184] Through the above process, this embodiment realizes a complete automated processing flow from netlist input, conflict detection, constraint input, address allocation to result output. This not only reduces the workload of manual inspection and adjustment, but also improves the stability and accuracy of address allocation by minimizing modification strategies, making it suitable for large-scale link address planning in complex electronic systems.

[0185] like Figure 9 As shown, embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described address allocation method embodiments.

[0186] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0187] The above provides a detailed description of an address allocation method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. An address allocation method characterized by, The method comprises the following steps: parsing an electrical connection netlist of a target link to determine a plurality of link entities in the target link and corresponding connection relationships, and constructing a link topology tree based on the connection relationships, and generating an address allocation rule set according to the link topology tree; determining logical addresses of the plurality of link entities according to the address allocation rule set, and configuring loading attributes of the plurality of link entities based on the logical addresses; obtaining the loading attributes of the plurality of link entities and determining real allocation addresses of the plurality of link entities according to the loading attributes, comprising: obtaining address configuration pins of the plurality of link entities, and determining configuration elements connected to the address configuration pins based on the electrical connection netlist; obtaining and parsing a production netlist of the target link to determine loading attributes representing mounting states of the configuration elements; determining actual level states of the plurality of address configuration pins according to the loading attributes of the configuration elements, and mapping the actual level states into variable address bits in address fields of the corresponding link entities; combining the variable address bits with preset fixed address bits of the link entities to obtain a hardware address field of the link entity, and determining the hardware address field as the real allocation address of the link entity as a physical addressing identifier of the link entity on the target link; performing address consistency verification on the plurality of link entities based on the real allocation addresses and the logical addresses, and performing address conflict verification on the link entities in response to the link entities failing to pass the address consistency verification; determining the link entities as address conflict entities and modifying the real allocation addresses of the link entities in response to the link entities failing to pass the address conflict verification.

2. The address allocation method according to claim 1, wherein, The method of parsing an electrical connection netlist of a target link to determine a plurality of link entities in the target link and corresponding connection relationships, and constructing a link topology tree based on the connection relationships comprises: parsing the electrical connection netlist to obtain network node information and device instance information; extracting identifications of the plurality of link entities and corresponding entity pin connection information according to the network node information and the device instance information; determining the connection relationships between the plurality of link entities according to the plurality of entity pin connection information; grouping and aggregating a plurality of link entities in communication with each other based on the connection relationships to generate a plurality of link connection subgraphs; determining a topology root node from the plurality of link connection subgraphs based on preset root node selection rules; expanding the plurality of link entities step by step according to electrical connection directions with the topology root node as a starting node to generate a hierarchical link topology tree.

3. The address allocation method according to claim 2, wherein The method of generating an address allocation rule set according to the link topology tree comprises: determining a node hierarchical position of a target link entity relative to the topology root node based on a hierarchical structure of the link topology tree; determining an access link from the topology root node to the target link entity based on the node hierarchical position and a connection relationship between the target link entity and an adjacent link entity. determining a communication access path according to a preset path determination rule based on the access links of the at least two link entities, to represent a communication relationship between the at least two link entities; generating the address allocation rule set according to structural feature information of the multiple communication access paths.

4. The address allocation method according to claim 3, wherein The generating the address allocation rule set according to structural feature information of the multiple communication access paths comprises: parsing the structural feature information of the multiple communication access paths to obtain multiple path structural features; classifying the multiple link entities according to the multiple path structural features to obtain multiple path entity groups; determining a first address allocation rule according to global reachability features of the global child nodes connected to the topology root node in the link topology tree, to represent that the logical addresses of the global child nodes are unique in a global range; determining a second address allocation rule according to access reachability, path overlap degree and communication conflict risk between multiple same-group link entities in the multiple path entity groups, to represent that the logical addresses of the multiple same-group link entities are different from each other; determining a third address allocation rule according to access exclusivity, running mode isolation and non-overlapping of corresponding communication access paths between multiple different-group link entities, to represent address multiplexing conditions under which the multiple different-group link entities are allowed to multiplex a same logical address; combining the first address allocation rule, the second address allocation rule and the third address allocation rule to generate the address allocation rule set.

5. The address allocation method according to claim 4, wherein, The determining the logical addresses of the multiple link entities according to the address allocation rule set comprises: determining one or more address allocation rules matched by the multiple link entities based on the address allocation rule set; determining address constraints corresponding to the link entities according to the one or more address allocation rules matched by the link entities, the address constraints comprising one or more of the following: global uniqueness constraint, path uniqueness constraint and address multiplexing constraint; solving the logical addresses of the multiple link entities according to the multiple address constraints and a set of available logical addresses in an address space, to obtain a set of logical addresses satisfying the multiple address constraints, comprising: selecting the multiple link entities corresponding to the global uniqueness constraint as first link entities; selecting, from the set of available logical addresses, unoccupied logical addresses as first candidate logical addresses in sequence, and performing global conflict detection on the multiple first candidate logical addresses; if a conflict is detected, reselecting unoccupied logical addresses from the set of available logical addresses to replace the conflicting first candidate logical addresses, until the multiple first link entities each correspond to a first candidate logical address, and deleting the multiple first candidate logical addresses from the set of available logical addresses; selecting the multiple link entities corresponding to the path uniqueness constraint as second link entities; selecting, in sequence, logical addresses from the set of available logical addresses as second candidate logical addresses of the second link entities based on a topological order of the path entity group to which the second link entities belong, and performing intra-group conflict detection on the second candidate logical addresses within the path entity group; if a conflict is detected, reselecting logical addresses from the set of available logical addresses to replace the second candidate logical addresses in conflict, until each of the second link entities corresponds to a second candidate logical address, and deleting the second candidate logical addresses from the set of available logical addresses; determining, based on the address multiplexing constraint, a multiplex entity group from the first link entities and the second link entities that satisfies the address multiplexing condition; selecting at least one link entity from the multiplex entity group as a third link entity, and setting a logical address of the third link entity as a multiplex address; assigning the multiplex address to the remaining link entities in the multiplex entity group except the third link entity, and adding original logical addresses of the remaining link entities to the set of available logical addresses.

6. The address allocation method according to claim 1, wherein, The address consistency verification on the link entities based on the real address and the logical address comprises: comparing the logical address of the link entity with the corresponding real address to determine whether the logical address and the real address point to the same entity; in response to consistency, determining that the link entity passes the address consistency verification, and determining the link entity as an address consistent entity; in response to inconsistency, determining that the link entity fails the address consistency verification, and determining the link entity as an address misplacement entity; In response to the link entity failing the address consistency verification, the address conflict verification on the link entity comprises: based on a plurality of rule set address verification items obtained by parsing the address allocation rule set, sequentially performing rule set conflict verification on the real address corresponding to the address misplacement entity, and if the address misplacement entity fails the rule set conflict verification, determining the address misplacement entity as a first address conflict entity; based on a plurality of hardware risk address verification items obtained by parsing the historical fault record of the target link and the bus protocol attribute, sequentially performing hardware risk conflict verification on the real address corresponding to the link entity to determine whether the link entity meets the physical communication environment limit of the target link, and if the link entity fails the hardware risk conflict verification, determining the link entity as a second address conflict entity; combining the first address conflict entity and the second address conflict entity to obtain the address conflict entity.

7. The address allocation method according to claim 6, wherein, The modification of the real address of the address conflict entity comprises: determining a modifiable variable set based on address information of one or more address conflict entities, and determining a minimum cost modification solution set based on the modifiable variable set and the address allocation rule set, to modify the real address of the address conflict entity based on the minimum cost modification solution set; wherein the modifiable variable set is determined based on the following steps: extracting address information of the plurality of address conflict entities to obtain corresponding logical address fields and real address fields, and generating an address conflict dataset; dividing the address conflict dataset based on types of the address conflict entities to obtain a first address conflict dataset and a second address conflict dataset; parsing the first address conflict dataset, identifying field positions of fields that violate rules in the corresponding fields as rule conflict fields according to the rule set address checking items; parsing the second address conflict dataset and determining real address fields corresponding to hardware risks as hardware risk address fields according to a plurality of the hardware risk address checking items; identifying associated entities that exist addressing dependency with the plurality of address conflict entities based on topological association relationships and resource coupling relationships of the plurality of address conflict entities, and determining real address fields of the associated entities as associated address fields; summarizing the rule conflict fields, the hardware risk address fields and the associated address fields, and eliminating unadjustable fields based on structural characteristics and alterable ranges of the target link to obtain a modifiable variable set.

8. The address allocation method according to claim 7, wherein, The determining of the minimum cost modification solution set according to the modifiable variable set and the address allocation rule set comprises: constructing a plurality of initial address modification operations based on the modifiable variable set, the initial address modification operations at least including adjustment operations on real address fields of one or more link entities; performing constraint filtering on the plurality of initial address modification operations based on hardware modification ranges of the target link, the address allocation rule set and a plurality of the hardware risk address checking items to eliminate invalid modification operations; constructing a plurality of candidate address modification solution sets based on the plurality of initial address modification operations retained after filtering; generating address modification costs of the plurality of candidate address modification solution sets according to configuration adjustment costs, hardware modification costs and link downtime costs of the candidate address modification solution sets; selecting a candidate address modification solution set corresponding to a minimum address modification cost and determining the candidate address modification solution set as a target address modification scheme.

9. An electronic device, comprising: comprise: a memory for storing a computer program; a processor for implementing the steps of the address allocation method of any one of claims 1 to 8 when executing the computer program.

Images