CPLD-based protocol-compatible access method, device and equipment

Abstract

This application provides a protocol-compatible access method, apparatus, and device based on CPLD, applied in the field of digital circuit interface technology. The method includes: responding to a target interface receiving a protocol access request, identifying the protocol type of the access request; if the protocol type is SMBUS, decoding the SMBUS command code in the access request using CPLD to obtain the corresponding register access parameters; generating an access timing signal adapted to the APB protocol based on the register access parameters; and accessing the target register on the APB based on the access timing signal; wherein the SMBUS and I2C protocols reuse the same register architecture. This method achieves unified adaptation of the SMBUS and I2C protocols at the register access layer through CPLD, enabling the two protocols to reuse the same register architecture, improving system compatibility and reducing development and maintenance costs.

Description

Technical Field

[0001] This application relates to the field of digital circuit interface technology, and in particular to a protocol-compatible access method, apparatus and device based on CPLD. Background Technology

[0002] In modern embedded systems, industrial control equipment, and consumer electronics, System Management Bus (SMBUS) and Inter-Integrated Circuit (I2C) are two widely adopted serial communication protocols, commonly used to connect peripheral devices such as sensors, power management modules, and memory. The SMBUS protocol extends the system management functions (such as hardware monitoring and power status detection) of the I2C protocol, while I2C is widely used for general-purpose device communication due to its simplicity and low power consumption. However, in practical engineering, there are many scenarios that require simultaneous support for both SMBUS and I2C protocols.

[0003] In related technologies, separate physical interface modules are configured for the SMBUS and I2C protocols, and the protocol mode is switched via hardware switches or design changes to enable devices to support the two protocols separately in different scenarios. For example, when the device needs to operate on the I2C protocol, the I2C interface module is enabled; when the device needs to operate on the SMBUS protocol, the SMBUS interface module is enabled.

[0004] However, this hardware discrete design cannot achieve protocol-compatible access on a single interface, resulting in low system compatibility and high development and maintenance costs. Summary of the Invention

[0005] This application provides a protocol-compatible access method, apparatus, and device based on CPLD to solve the problem in related technologies where hardware discrete design cannot achieve protocol-compatible access on a single interface, resulting in low system compatibility and high development and maintenance costs.

[0006] In a first aspect, this application provides a protocol-compatible access method based on CPLD, comprising: in response to a target interface receiving a protocol access request, identifying the protocol type of the protocol access request, wherein the protocol type includes SMBUS protocol and I2C protocol;

[0007] If the protocol type is SMBUS, the SMBUS command code in the protocol access request is decoded based on the Complex Programmable Logic Device (CPLD) to obtain the corresponding register access parameters, which include read / write type, continuous access length, and register start address.

[0008] Based on the Advanced Peripheral Bus (APB) protocol, access timing signals adapted to the APB protocol are generated according to the register access parameters.

[0009] Access the target register on APB based on the access timing signals;

[0010] The SMBUS and I2C protocols reuse the same register architecture.

[0011] In one possible implementation, the CPLD has a pre-configured programmable lookup table that decodes the SMBUS command code in the protocol access request to obtain the corresponding register access parameters, including:

[0012] Using the SMBUS command code as the lookup table address, the corresponding register access parameters are found and parsed through the programmable lookup table, which stores the mapping relationship between the SMBUS command code and the register access parameters.

[0013] In one possible implementation, the CPLD-based protocol-compatible access method further includes:

[0014] If the protocol type is I2C, then the register address in the protocol access request will be used as the register start address;

[0015] The read / write type is determined based on the read / write flags in the protocol access request.

[0016] In one possible implementation, based on the APB protocol, access timing signals adapted to the APB protocol are generated according to register access parameters, including:

[0017] Based on the register start address and the consecutive access length, a continuously increasing APB address sequence is generated, where each address in the APB address sequence corresponds one-to-one with a register on the APB;

[0018] Based on the APB protocol, access timing signals adapted to the APB protocol are generated according to the read / write type and APB address sequence.

[0019] In one possible implementation, accessing the target register on the APB based on access timing signals includes:

[0020] When the read / write type is a write operation, in response to the write data valid flag of the SMBUS protocol, the write data in the protocol access request is latched, and the write data is written to the target register through the write data port of APB.

[0021] When the read / write type is a read operation, data is read from the target register, a read data valid flag is generated, and the read data is sent to the initiator of the protocol access request through the read data port of the APB.

[0022] Record the number of bytes that have been accessed. When the number of bytes that have been accessed is equal to the length of the continuous access, end the current protocol access request.

[0023] In one possible implementation, the programmable lookup table is configured with a hierarchical address mapping mechanism for expanding the register address space.

[0024] Hierarchical address mapping mechanisms include:

[0025] Using the SMBUS command code as the lookup address, the page address and the page offset base address are mapped from the programmable lookup table;

[0026] The page address and the base address of the offset within the page are combined to generate the complete register start address;

[0027] The addressing range of the complete register starting address is greater than the depth of the programmable lookup table.

[0028] In one possible implementation, the mapping is configured through an initialization file imported at compile time, or updated via online programming.

[0029] Secondly, this application provides a protocol-compatible access device based on CPLD, comprising:

[0030] The identification module is used to identify the protocol type of the protocol access request when the target interface receives a protocol access request. The protocol types include SMBUS protocol and I2C protocol.

[0031] The decoding module is used to decode the SMBUS command code in the protocol access request based on CPLD when the protocol type is SMBUS protocol, and obtain the corresponding register access parameters. The register access parameters include read / write type, continuous access length and register start address.

[0032] The address generation and APB adaptation module is used to generate access timing signals adapted to the APB protocol based on register access parameters.

[0033] The access module is used to access the target register on the APB based on the access timing signals;

[0034] The SMBUS and I2C protocols reuse the same register architecture.

[0035] In one possible implementation, the CPLD has a pre-configured programmable lookup table. The decoding module is specifically used to: use the SMBUS command code as the lookup table address, and use the programmable lookup table to find and parse the corresponding register access parameters. The programmable lookup table stores the mapping relationship between the SMBUS command code and the register access parameters.

[0036] In one possible implementation, the CPLD-based protocol-compatible access device further includes a processing module for: using the register address in the protocol access request as the register start address when the protocol type is I2C; and determining the read / write type based on the read / write flag bit in the protocol access request.

[0037] In one possible implementation, the address generation and APB adaptation module is specifically used to: generate a continuously increasing APB address sequence based on the register start address and the continuous access length, wherein each address in the APB address sequence corresponds one-to-one with a register on the APB; and generate an access timing signal adapted to the APB protocol based on the APB protocol, according to the read / write type and the APB address sequence.

[0038] In one possible implementation, the access module is specifically used to: when the read / write type is a write operation, in response to the write data validity flag of the SMBUS protocol, latch the write data in the protocol access request, and write the write data to the target register through the write data port of the APB; when the read / write type is a read operation, read data from the target register, generate a read data validity flag, and send the read data to the initiator of the protocol access request through the read data port of the APB; record the number of bytes that have been accessed, and when the number of bytes that have been accessed is equal to the continuous access length, end the current protocol access request.

[0039] In one possible implementation, the programmable lookup table is configured with a hierarchical address mapping mechanism to expand the register address space. The hierarchical address mapping mechanism includes: using the SMBUS command code as the lookup address, mapping the page address and the page offset base address from the programmable lookup table; combining the page address and the page offset base address to generate the complete register start address; wherein the addressing range of the complete register start address is greater than the depth of the programmable lookup table.

[0040] In one possible implementation, the mapping is configured through an initialization file imported at compile time, or updated via online programming.

[0041] Thirdly, this application provides a protocol-compatible access system, comprising: a CPLD-based protocol-compatible access device according to the second aspect, and a register module connected to the CPLD-based protocol-compatible access device via an APB, the register module including a target register.

[0042] Fourthly, this application provides an electronic device including the protocol-compatible access system of the third aspect.

[0043] This application provides a CPLD-based protocol-compatible access method, apparatus, and device. In response to a target interface receiving a protocol access request, the method identifies the protocol type of the access request, which may include SMBUS or I2C protocols. If the protocol type is SMBUS, the method decodes the SMBUS command code in the access request using CPLD to obtain the corresponding register access parameters, including read / write type, continuous access length, and register start address. Based on the APB protocol, the method generates access timing signals adapted to the APB protocol according to the register access parameters. Based on the access timing signals, the method accesses the target register on the APB. The SMBUS and I2C protocols reuse the same register architecture. This application effectively improves the compatibility issue between the SMBUS and I2C protocols at the register access layer. Specifically, by automatically identifying protocol types and distinguishing between SMBUS and I2C protocols without requiring hardware switches or design changes, it achieves compatible access to both protocols on a single physical interface. By decoding SMBUS command codes, it converts implicit address access in SMBUS into explicit address access recognizable by the APB bus, achieving precise conversion from SMBUS command codes to register addresses and solving the technical challenge of SMBUS not being able to directly access the I2C register architecture. Based on a unified APB protocol, it generates standardized access timing, eliminating the need to design separate interface modules for the two protocols. This ensures hardware architecture compatibility with the register access requirements of both protocols, enabling register access function reuse and significantly reducing hardware redundancy. Furthermore, SMBUS and I2C protocols reuse the same register architecture, eliminating the need to design separate register access logic for each protocol, significantly reducing design complexity. Only one register architecture needs to be maintained, lowering development and maintenance costs. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0045] Figure 1 A flowchart illustrating the protocol-compatible access method based on CPLD provided in this application embodiment;

[0046] Figure 2 This application provides a timing diagram for SMBUS write command access in an embodiment.

[0047] Figure 3 The timing diagram for SMBUS read command access provided in the embodiments of this application;

[0048] Figure 4 A block diagram illustrating the implementation of the protocol-compatible access method based on CPLD provided in this application embodiment;

[0049] Figure 5 A schematic diagram of the CPLD-based protocol-compatible access device provided in this application embodiment. Figure 1 ;

[0050] Figure 6 A schematic diagram of the CPLD-based protocol-compatible access device provided in this application embodiment. Figure 2 ;

[0051] Figure 7 This is a schematic diagram of the structure of a protocol-compatible access system provided in an embodiment of this application.

[0052] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0053] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0054] The terms “first,” “second,” etc., used in the specification and claims of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, products, or apparatus.

[0055] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0056] As device functionality becomes more complex, a single system may need to simultaneously support register access requirements via both SMBUS and I2C protocols. For example, a smart home appliance control system might need to access the power management unit's registers via SMBUS while simultaneously accessing the environmental sensor's registers via I2C.

[0057] In related technologies, although the SMBUS and I2C interfaces have been unified in physical hardware design, there are significant differences in their protocol layers: the I2C protocol uses direct access via register addresses, while the SMBUS protocol uses indirect access via command codes. These differences in protocol layers mean that the two interfaces cannot be used interchangeably to access internal registers, requiring design changes or hardware switches for adaptation. This means that the internal registers of the same device cannot simultaneously support both protocol access methods.

[0058] Therefore, it is usually necessary to design separate register access interface modules for the SMBUS and I2C protocols. That is, the two sets of interfaces need to use two different architectures and their corresponding functional modules. This approach has the following drawbacks: it is impossible to achieve protocol-compatible access on a single interface, resulting in hardware architecture redundancy, extended development cycle, and low system compatibility; as products iterate and upgrade, two independent protocol adaptation schemes need to be maintained simultaneously, which significantly increases the R&D cycle and maintenance costs, especially when multiple projects are developed in parallel, the problem of resource waste is particularly prominent.

[0059] Therefore, there is an urgent need for a solution that can achieve SMBUS and I2C protocol compatible access without hardware reconstruction, so as to improve system compatibility and reduce development and maintenance costs.

[0060] To address the aforementioned technical issues, the inventors, starting from the protocol layer differences between the SMBUS and I2C protocols, provide a protocol-compatible access scheme based on a CPLD. This scheme constructs a unified protocol conversion layer using a CPLD, enabling multiplexed access to the same register architecture for both protocols. Specifically, the CPLD automatically identifies the protocol access request received by the target interface, distinguishing between SMBUS and I2C protocols. When identified as SMBUS, the SMBUS command code is decoded and converted into unified register access parameters, achieving precise conversion from SMBUS command code to register address. Based on the APB protocol, standardized APB access timing signals are generated according to the register access parameters, uniformly converting the implicit address access of the SMBUS protocol and the explicit register address access of the I2C protocol into standardized APB bus timing. Through this method, register access is unified under the APB bus architecture, thus achieving hardware architecture-level compatibility for the register access requirements of both protocols, avoiding hardware redundancy, and achieving unified register access adaptation for SMBUS and I2C protocols, significantly reducing development and maintenance costs.

[0061] Next, we will first introduce the application scenarios of this application.

[0062] This application is not limited to embedded systems that need to simultaneously support both SMBUS and I2C protocols, such as multi-protocol sensor networks in IoT devices, power management modules in industrial automation control systems, and multi-interface peripheral communication scenarios in consumer electronics. In these scenarios, the system needs to be compatible with register access for both protocols through a unified hardware architecture, while also meeting the requirements for dynamic protocol switching and low-power design.

[0063] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0064] Figure 1 This is a flowchart illustrating the protocol-compatible access method based on CPLD provided in this application embodiment. The execution entity of this application embodiment is CPLD, which implements functions such as protocol identification, command decoding, address generation, and APB timing conversion through hardware logic.

[0065] like Figure 1 As shown, the protocol-compatible access method based on CPLD provided in this embodiment includes:

[0066] S101. In response to the target interface receiving a protocol access request, identify the protocol type of the protocol access request. The protocol type includes SMBUS protocol and I2C protocol.

[0067] The I2C protocol's transmission format includes slave address, register address, and data; the SMBUS protocol's transmission format includes slave address, SMBUS command code, data, and checksum. Protocol type refers to the category of the communication protocol, used to distinguish the data format and access rules of different communication protocols. For example, the SMBUS protocol implicitly specifies the register address through the command code, while the I2C protocol achieves access by explicitly sending the register address.

[0068] For example, the target interface of the CPLD (such as the SCL and SDA pins) continuously listens for communication start conditions on the bus to detect whether a protocol access request has been received.

[0069] Once the communication initiation condition is detected, in one possible implementation, the CPLD determines the protocol type by parsing the slave address in the protocol access request.

[0070] Specifically, the CPLD has multiple pre-configured slave address registers, corresponding to the SMBUS and I2C protocols respectively. For example, a first slave address (e.g., 0x60) is assigned to the SMBUS protocol, and a second slave address (e.g., 0x62) is assigned to the I2C protocol. Upon receiving a slave address, the CPLD compares it with the pre-configured slave addresses: if the received slave address matches the first slave address (0x60), the protocol type of the current access request is determined to be SMBUS; if the received slave address matches the second slave address (0x62), the protocol type of the current access request is determined to be I2C; if neither matches, the CPLD ignores the current access and continues to wait for the next communication start condition. It should be understood that the above slave addresses are only illustrative examples; in actual applications, they can be flexibly configured according to system design requirements, with different slave addresses (or slave address ranges) configured for SMBUS and I2C protocols respectively.

[0071] In one implementation, the CPLD may have an internal protocol type discriminator that determines the protocol type of the protocol access request based on the protocol header information format of the protocol access request.

[0072] S102. If the protocol type is SMBUS, the SMBUS command code in the protocol access request is decoded based on the CPLD to obtain the corresponding register access parameters. The register access parameters include read / write type, continuous access length, and register start address.

[0073] It should be understood that the fundamental difference between the SMBUS and I2C protocols at the register access layer lies in the different address representation methods. In the I2C protocol, the master device directly sends the address of the target register, and the slave device directly accesses the corresponding register based on this address. In the SMBUS protocol, the master device sends an SMBUS command code, which is an 8-bit encoded value. This SMBUS command code is not directly equal to the register address, but needs to be decoded and converted into the corresponding register access parameters.

[0074] For example, the CPLD internally establishes a mapping between SMBUS command codes and register access parameters. When the CPLD receives an SMBUS command code, it converts the command code into three explicit register access parameters based on this mapping: read / write type, consecutive access length, and register start address. This mapping ensures that the implicit address access of the SMBUS protocol is compatible with the explicit address access of the APB bus.

[0075] The read / write type indicates whether the current access is a read or write operation. The consecutive access length indicates the number of register bytes to be accessed consecutively, with a value ranging from 1 to 32 bytes. The register start address indicates the starting location of the target register for this access, with a value ranging from 0x00 to 0xFF.

[0076] For example, when the SMBUS master device sends SMBUS command code 0x10, the CPLD, according to a preset mapping, parses the SMBUS command code as: read operation type, continuous access length of 4 bytes, register start address of 0x30. When the SMBUS master device sends SMBUS command code 0x20, the CPLD parses it as: write operation type, continuous access length of 2 bytes, register start address of 0x60.

[0077] It should be noted that if the SMBUS command code received by the CPLD is not defined in the preset mapping, the CPLD will determine that the SMBUS command code is invalid, for example, by returning a non-acknowledgment signal to the SMBUS master device, indicating that it cannot process the command.

[0078] Through the above decoding process, the CPLD converts the implicit command code of the SMBUS protocol into explicit register access parameters, preparing for the subsequent APB timing generation.

[0079] Furthermore, after parsing the SMBUS command code to obtain the continuous access length, the CPLD performs subsequent read and write accesses based on this continuous access length. Optionally, in embodiments supporting block transfer extensions, if the SMBUS master device sends a "byte count" field after the command code, the CPLD can perform a consistency check between the byte count value and the parsed continuous access length. If the check matches (i.e., the "continuous access length" equals the "byte count"), subsequent read and write accesses continue; if the check does not match (i.e., the "continuous access length" does not equal the "byte count"), it is determined to be a protocol violation or an access out-of-bounds event, and the CPLD ignores this access.

[0080] S103. Based on the APB protocol, generate access timing signals adapted to the APB protocol according to the register access parameters.

[0081] APB is a low-bandwidth, low-power bus protocol. In this embodiment, it serves as the interface bus between the CPLD and the target register, providing a unified register access interface. That is, regardless of whether the upper-layer protocol is SMBUS or I2C, the target register is ultimately accessed through the same APB timing sequence.

[0082] For example, the CPLD starts the APB access timing generation logic based on the register access parameters parsed in step S102. Specifically, the CPLD converts the register start address, continuous access length, and read / write type in the register access parameters into access timing signals that conform to the APB bus protocol specification, based on the APB protocol.

[0083] For example, if the read / write type is a write operation, the CPLD generates APB write timing signals, including: activating the APB select signal, activating the APB enable signal, driving the register start address and subsequent incrementing address to the APB address bus, driving the write data to the APB write data bus, and activating the APB write control signal. If the read / write type is a read operation, the CPLD generates APB read timing signals, including: activating the APB select signal, activating the APB enable signal, driving the register start address and subsequent incrementing address to the APB address bus, and deactivating the APB write control signal.

[0084] During the generation of APB access timing signals, the CPLD automatically handles the APB bus handshake protocol, including the establishment and holding of the select signal, the timing control of the enable signal, and the waiting and response to the ready signal. The CPLD continuously monitors the APB ready signal to ensure that the timing generation is completed only after the ready signal is valid for each APB transmission.

[0085] In this way, the CPLD converts the register access parameters of the SMBUS protocol into standard APB bus timing signals, preparing for access to the target register on the APB.

[0086] S104. Access the target register on APB based on the access timing signal.

[0087] In this design, the SMBUS and I2C protocols reuse the same register architecture. Specifically, the target register's register architecture is based on the APB protocol interface, which serves both SMBUS and I2C protocols. When the protocol access request is for SMBUS, it is converted to APB access timing through steps S102 and S103. Both protocols can ultimately access the same set of target registers through the same APB timing, eliminating the need to design separate register access interface modules for each protocol. This achieves reused access to the same register architecture for both SMBUS and I2C protocols. When internal register function modules need to be upgraded, only one register architecture needs to be maintained, eliminating the need to maintain two independent interface versions simultaneously, significantly reducing development and maintenance costs.

[0088] For example, the CPLD accesses the target register via the APB bus based on the APB access timing signal generated in step S103. If it is a write operation, the CPLD sends the write data to the target register via the APB bus to complete the data writing. If it is a read operation, the CPLD reads data from the target register via the APB bus and returns the read data to the SMBUS master device via the SMBUS interface.

[0089] This application's embodiments automatically identify the protocol type, automatically distinguishing between SMBUS and I2C protocols without requiring hardware switches or design changes, achieving compatible access to both protocols on a single physical interface. By decoding the SMBUS command code, the implicit address access of the SMBUS protocol is converted into an explicit address access recognizable by the APB bus, achieving accurate conversion from SMBUS command code to register address, solving the technical challenge of SMBUS protocol not being able to directly access the I2C register architecture. Based on a unified APB protocol, standardized access timing is generated, eliminating the need to design independent interface modules for the two protocols, ensuring compatibility with the register access requirements of both protocols at the hardware architecture level, achieving register access function reuse, and significantly reducing hardware redundancy design. In addition, the SMBUS and I2C protocols reuse the same register architecture, eliminating the need to design separate register access logic for each protocol, significantly reducing design complexity, requiring only one register architecture to be maintained, and reducing development and maintenance costs.

[0090] In some embodiments, the CPLD has a pre-configured programmable lookup table to decode the SMBUS command code in the protocol access request and obtain the corresponding register access parameters. This includes: using the SMBUS command code as the lookup table address, searching and parsing the corresponding register access parameters through the programmable lookup table, and storing the mapping relationship between the SMBUS command code and the register access parameters in the programmable lookup table.

[0091] In this context, the lookup address can be viewed as an address signal used to locate stored content in a programmable lookup table.

[0092] For example, the programmable lookup table is implemented using random access memory (RAM) with a depth of 256 and a bit width of 16 bits. Specifically, the address space of the programmable lookup table is 0x00 to 0xFF, corresponding one-to-one with the value space of the SMBUS command code (8-bit binary numbers, corresponding to 0 to 255). Each memory cell of the programmable lookup table is 16 bits wide and is used to store the register access parameters of the corresponding SMBUS command code. The 16 bits of data in each memory cell are divided as follows: the high 2 bits are used to store the read / write type, the middle 6 bits are used to store the continuous access length, and the low 8 bits are used to store the register start address. Among them, the read / write type reg_rdw[1:0] uses binary encoding: 10 represents a read operation, 01 represents a write operation, and 00 or 11 represents an invalid command; the continuous access length reg_len[5:0] ranges from 1 to 32 bytes, corresponding to binary 000001 to 100000; the register start address reg_adr[7:0] ranges from 0x00 to 0xFF.

[0093] For example, the CPLD acquires the received SMBUS command code, uses this command code as a lookup address, accesses the programmable lookup table using this address, and reads 16 bits of data from the corresponding memory cell. Then, the CPLD performs field splitting on the read 16 bits: extracting the high 2 bits as the read / write type, the middle 6 bits as the continuous access length, and the low 8 bits as the register start address. Finally, the CPLD uses the split read / write type, continuous access length, and register start address as register access parameters and outputs them to the subsequent APB timing generation logic.

[0094] Taking the SMBUS master device sending SMBUS command code 0x10 as an example, assume the data pre-stored at address 0x10 in the programmable lookup table is 0x8A30. The CPLD accesses the programmable lookup table using address 0x10 and reads the data 0x8A30. Then, 0x8A30 is converted to binary: 1000101000110000. The field splitting result is: the high 2 bits are binary 10, indicating a read operation; the middle 6 bits are binary 001000, indicating a continuous access length of 4 bytes; the low 8 bits are binary 00110000, indicating the register starting address is 0x30. The CPLD outputs the above parsing result as register access parameters. Subsequent steps will generate the APB read timing based on these parameters, continuously reading 4 bytes of data from addresses 0x30, 0x31, 0x32, and 0x33.

[0095] This application's embodiments achieve precise mapping between SMBUS command codes and register access parameters through a programmable lookup table. Specifically, the SMBUS command code serves as the lookup table address, converting the implicit command code of the SMBUS protocol into an explicit register address. This mapping relationship is flexibly configurable, supporting dynamic association between different SMBUS command codes and register addresses, thus solving the technical challenge of the SMBUS protocol's inability to directly access the I2C register architecture. Simultaneously, the differences between the SMBUS and I2C protocols at the protocol layer are abstracted into a programmable mapping relationship. This hardware logic flexibility replaces the discrete hardware design schemes in related technologies, eliminating the need to design separate register access interface modules for each protocol, significantly reducing hardware redundancy.

[0096] In some embodiments, the mapping is configured through an initialization file imported at compile time, or updated via online programming.

[0097] In one implementation, the storage content of the programmable lookup table (i.e., the mapping relationship between SMBUS command codes and register access parameters) can be configured through an initialization file. During the CPLD compilation stage, the pre-configured initialization file is imported into the CPLD design. The initialization file records the register access parameters corresponding to each SMBUS command code. For example, a configuration record in the initialization file can be represented as: data 0x8A30 is stored at address 0x10, SMBUS indicates that command code 0x10 corresponds to a read operation, the continuous access length is 4 bytes, and the register starting address is 0x30. By modifying the initialization file, the mapping relationship between SMBUS command codes and register access parameters can be flexibly adjusted without changing the CPLD hardware design. For example, when different products require different command code mapping rules, only the initialization file needs to be replaced and the programmable lookup table recompiled and burned; there is no need to modify the CPLD's register transfer level code. This implementation greatly improves flexibility and reusability.

[0098] In another implementation, the mapping relationships in the programmable lookup table are updated via online programming. For example, during the debugging phase, new mapping rules can be written into RAM through external interfaces such as JTAG to support functional testing or protocol adaptation. In this process, no changes need to be made to the CPLD hardware design, allowing for flexible adjustment of the correspondence between SMBUS command codes and register addresses, significantly reducing maintenance costs and shortening the development cycle.

[0099] In practical applications, the number of target registers may exceed 256, which places higher demands on the addressing capabilities of programmable lookup tables (PLAs). If a PLA can only output an 8-bit register start address, with an addressing range of 0x00 to 0xFF (256 addresses), it cannot meet the access requirements of larger-scale register arrays, resulting in insufficient hardware scalability. For example, some complex system-on-a-chip (SoCs) may contain 1024 or more register units. In this case, direct addressing cannot cover the entire register address space, requiring an expanded addressing range.

[0100] In some embodiments, the programmable lookup table is configured with a hierarchical address mapping mechanism to expand the register address space. The hierarchical address mapping mechanism includes: using the SMBUS command code as the lookup address, mapping the page address and the page offset base address from the programmable lookup table; combining the page address and the page offset base address to generate the complete register start address; wherein the addressing range of the complete register start address is greater than the depth of the programmable lookup table.

[0101] Specifically, each entry in the programmable lookup table directly stores the page address and the page offset base address corresponding to the SMBUS command code. The page address serves as the first-level address, and the page offset base address serves as the second-level address. For example, the CPLD uses the SMBUS command code as the lookup address to directly read the corresponding page address and page offset base address from the programmable lookup table in one go. The page address is used to select the page containing the registers; each page contains a set of consecutive register cells. The page offset base address indicates the starting offset position of the command code within the page. The bit width of the page address can be configured according to the actual number of pages required; for example, if 16 pages are needed, the page address is configured to be 4 bits. Then, the page address is used as the high-order bits of the complete address, and the page offset base address is used as the low-order bits of the complete address to generate the complete register starting address. By combining the page address and the offset, the addressing range is expanded.

[0102] Taking a system requiring support for 4096 registers (address space 0x000 to 0xFFF) as an example, the programmable lookup table (PLA) remains at a depth of 256. Each entry outputs a 4-bit page address and an 8-bit offset base address, totaling 12 bits. The page address is the high 4 bits of the complete address, and the offset base address is the low 8 bits. When the SMBUS master device sends command code 0x10, the CPLD accesses the PLA at address 0x10 and reads the mapping result: page address 0x3 (binary 0011), offset base address 0x00. The CPLD combines the page address and offset base address to generate the complete 12-bit register start address: 0x300. Through this hierarchical address mapping mechanism, the original 256-bit deep PLA, outputting 8-bit addresses, can support 4096 register addresses (…). The addressing range is expanded by 16 times, and no increase in lookup table depth is required, only an increase in output bit width is needed.

[0103] The page address and offset combination rules in the hierarchical address mapping mechanism can be configured through the initialization file of the programmable lookup table. The page address and offset base address corresponding to each SMBUS command code can be set independently to adapt to different register address space layouts. For example, for SMBUS command code 0x10, the lookup table can be configured with a page address of 0x3 and an offset base address of 0x00, combining to generate the complete address 0x300; for SMBUS command code 0x11, the page address can be configured with 0x3 and an offset base address of 0x01, combining to generate the complete address 0x301. The page address and offset base address of each command code can be configured independently without affecting each other.

[0104] Optionally, the hierarchical address mapping mechanism includes a three-level mapping: the first level is the page address; the second level is the block address; and the third level is the offset base address within the block. These three levels of addresses are then combined to generate the complete register start address. This approach is suitable for systems where the register address space is hierarchically organized (such as a multi-core processor where each core has its own independent register block).

[0105] The hierarchical address mapping mechanism effectively expands the register addressing range, meeting the register access requirements of complex systems; it also reduces the storage resource requirements of the programmable lookup table. For example, a programmable lookup table with a depth of 256 and a width of 16 bits can support a register address space much larger than 256 bytes without increasing the depth of the programmable lookup table. Only the output bit width of each table entry needs to be appropriately increased, thus saving internal storage resources of the CPLD.

[0106] In some embodiments, the protocol-compatible access method based on CPLD further includes: if the protocol type is I2C, then using the register address in the protocol access request as the register start address; and determining the read / write type according to the read / write flag in the protocol access request.

[0107] For example, the CPLD extracts the register address field from the I2C protocol access request. In the I2C protocol, the master device sends an 8-bit register address byte immediately after sending the device address (including the read / write flags) to specify the target register to be accessed. The CPLD directly uses this register address byte as the register start address without any decoding or conversion. For example, when the I2C master device sends register address 0x30, the CPLD sets the register start address to 0x30.

[0108] In the I2C protocol, the read / write type is not determined by the "register address" itself, but by the 8th bit (R / W bit) after the device address. A value of 0 indicates a write operation, and a value of 1 indicates a read operation. The CPLD obtains this read / write flag bit when receiving the device address and uses it as the read / write type in the register access parameters.

[0109] Unlike the SMBUS protocol, the CPLD in the I2C protocol does not need to know the continuous access length in advance. The I2C master device implicitly specifies the transmission length through the transmission process: the CPLD processes the same number of bytes sent by the master device until a stop condition (such as the STOP field) is detected.

[0110] For example, the CPLD may have an internal byte counter to record the number of data bytes actually transmitted during this access. When a stop condition is detected, the CPLD uses the value of the byte counter as the actual continuous access length for this access.

[0111] Specifically, when the master device sends only one data byte before sending the stop condition, the actual continuous access length is equal to 1, corresponding to single-byte access; when the master device sends multiple data bytes consecutively before sending the stop condition, the actual continuous access length is greater than 1, corresponding to multi-byte access.

[0112] It should be understood that, regardless of whether it is a single-byte or multi-byte access, the CPLD uses the same processing mechanism: for each received data byte (write operation) or each sent data byte (read operation), the CPLD increments the current register address by 1, thus continuously incrementing the address. This mechanism corresponds to the way the SMBUS protocol generates an address sequence based on a preset length (i.e., the parsed continuous access length), and both are unified into the same address increment logic at the APB access level.

[0113] In other words, the incrementing of register addresses under the I2C protocol is dynamically driven by the actual number of data bytes transmitted.

[0114] After the above processing, the I2C protocol access request is converted into a register start address and read / write type. Unlike the SMBUS protocol, the CPLD in the I2C protocol does not preset the continuous access length, but determines it dynamically through the transmission process. Subsequently, the CPLD executes steps S103 and S104, generating APB access timing signals based on these register access parameters, and accessing the target register on the APB. Specifically: for an I2C write operation, the CPLD responds to each write data valid flag, sequentially receives each data byte sent by the master device, generates an APB write timing sequence, writes the current data byte to the current register address through the APB bus, and automatically increments the register address by 1 until a stop condition is detected; for an I2C read operation, the CPLD sequentially generates an APB read timing sequence, reads data from the current register address, and returns it to the I2C master device through the I2C interface. After each byte is read, the register address is automatically incremented by 1 until a stop condition or non-acknowledgment signal is detected.

[0115] In this manner, the SMBUS command code is decoded and converted by the CPLD, and the I2C protocol register addresses are passed through by the CPLD. Both ultimately access the same register architecture using APB bus timing. Since both paths share the same APB timing generation and register access logic, the register access parameter format output by the I2C path is completely consistent with that of the SMBUS path, avoiding redundant design of functional modules. Simultaneously, the I2C protocol retains its native method of direct register address access, requiring no conversion. Therefore, the SMBUS and I2C protocols share the same register architecture, eliminating the need to design separate register access logic for each protocol, significantly reducing hardware redundancy and maintenance costs.

[0116] In some embodiments, based on the APB protocol, access timing signals adapted to the APB protocol are generated according to register access parameters, specifically including:

[0117] Step 1031: Generate a continuously increasing APB address sequence based on the register start address and the continuous access length, wherein each address in the APB address sequence corresponds one-to-one with a register on the APB.

[0118] For example, the CPLD internally sets up an address counter and a length counter. The address counter is initialized to the register start address, and the length counter is initialized to 0. The CPLD uses the register start address as the first address in the sequence, and then increments it sequentially to generate subsequent addresses until the number of generated addresses equals the consecutive access length. That is, the APB address sequence is: Addr0 = register start address, Addr1 = register start address + 1, Addr2 = register start address + 2, ..., Addr(N-1) = register start address + (N-1), where N is the consecutive access length.

[0119] For example, if the register starting address is 0x30 and the continuous access length is 4 bytes, then the APB address sequence generated by the CPLD is: 0x30, 0x31, 0x32, 0x33.

[0120] Each address in the APB address sequence corresponds one-to-one with a register on the APB. Each register unit on the APB bus has a unique address, which the CPLD uses to select the target register to access.

[0121] For I2C protocol paths (with a fixed continuous access length of 1), the APB address sequence generated by the CPLD contains only one address, namely the register start address itself, and no address increment operation is required.

[0122] Step 1032: Based on the APB protocol, generate access timing signals adapted to the APB protocol according to the read / write type and APB address sequence.

[0123] It should be understood that the CPLD generates the corresponding APB access timing for each address in the APB address sequence according to the read / write type.

[0124] For example, when the read / write type is a write operation, the CPLD performs the following operations sequentially for each address in the APB address sequence:

[0125] First, the CPLD waits for the SMBUS master to send write data. When it receives a write data valid flag, the CPLD latches the current write data.

[0126] Secondly, the CPLD drives the current APB address to the APB address bus, drives the latched write data to the APB write data bus, sets the APB select signal to active, sets the APB enable signal to active, and sets the APB write control signal to high level (indicating a write operation).

[0127] Then, the CPLD continuously monitors the APB ready signal. When the APB ready signal is detected to be high, the APB write timing is generated for this operation.

[0128] Finally, the CPLD restores the APB select signal and enable signal to an invalid state, preparing to generate the write timing for the next address.

[0129] The CPLD repeats the above process until all addresses in the APB address sequence have completed the generation of write timings.

[0130] When the read / write type is a read operation, the CPLD performs the following operations sequentially for each address in the APB address sequence:

[0131] First, the CPLD drives the current APB address to the APB address bus, enables the APB select signal, enables the APB enable signal, and sets the APB write control signal to low.

[0132] Secondly, the CPLD continuously monitors the APB ready signal. When the APB ready signal is detected to be high, the timing sequence for this APB read is completed.

[0133] Finally, the CPLD restores the APB select signal and enable signal to an invalid state, preparing to generate the read timing for the next address.

[0134] The CPLD repeats the above process until all addresses in the APB address sequence have completed the generation of read timings.

[0135] In this embodiment, by generating a continuously increasing APB address sequence, the multi-byte block transmission of the SMBUS protocol is automatically split into multiple single APB transmissions. This requires no software intervention and achieves seamless adaptation between the SMBUS protocol and the APB bus directly through hardware logic. For single-byte access (such as the I2C protocol), the address sequence degenerates into a single address, which also applies. Based on the APB protocol, a standardized access timing sequence is generated, and handshake signals such as select, enable, and ready are automatically processed, ensuring compatibility with APB slave devices of different speeds. This achieves seamless adaptation between the SMBUS protocol (or I2C protocol) and the APB bus.

[0136] In some embodiments, accessing the target register on the APB based on access timing signals includes:

[0137] Step 1041: When the read / write type is a write operation, in response to the write data valid flag of the SMBUS protocol, latch the write data in the protocol access request, and write the write data to the target register through the write data port of APB.

[0138] To facilitate understanding of the SMBUS write command access timing, combined with Figure 2 Please provide an explanation. Figure 2 The SMBUS write command access timing diagram provided for the embodiments of this application is as follows: Figure 2As shown, this timing diagram illustrates the waveform changes of key signals when the CPLD processes SMBUS write commands. Figure 2 The signals include:

[0139] smb_cmd: SMBUS command code signal, carrying the command code sent by the master device (marked as WR in the figure, indicating a write command);

[0140] smb_cmd_vld: SMBUS command code validity flag signal. When this signal is high, it indicates that the command code on smb_cmd is valid.

[0141] smb_wdt: SMBUS write data signal, carrying the data to be written sent by the master device;

[0142] smb_wdt_vld: SMBUS write data valid flag signal. When this signal is high, it indicates that write data on smb_wdt is valid.

[0143] apb_sel: APB selection signal, driven by CPLD, used to select the APB slave device;

[0144] apb_ena: APB enable signal, driven by CPLD, and works with apb_sel to generate APB transmission timing;

[0145] apb_adr: APB address signal, driven by CPLD, indicates the address of the target register currently being accessed;

[0146] apb_write: APB write control signal, driven by CPLD. High level indicates write operation, low level indicates read operation;

[0147] apb_rdy: APB ready signal, driven by the APB slave device. A high level indicates that the slave device is ready to complete the current transmission.

[0148] apb_wdt: APB write data signal, driven by CPLD, carries the data to be written to the target register.

[0149] The SMBUS write command access sequence is divided into the following stages:

[0150] Phase 1: Command Reception Phase.

[0151] The SMBUS master device sends a write command code. The CPLD detects that the smb_cmd_vld signal is high and latches the SMBUS command code on smb_cmd. The CPLD decodes the SMBUS command code to obtain the register start address, continuous access length, and read / write type (write operation). Figure 2The area marked "WR" corresponds to the SMBUS command code transmission stage.

[0152] Phase 2: Data reception and APB write timing generation phase.

[0153] The SMBUS master device sequentially sends multiple bytes of write data, with each byte corresponding to a write data validity flag. For example... Figure 2 As shown, five data bytes, D0, D1, D2, D3, and D4, appear sequentially on the smb_wdt signal, each accompanied by an smb_wdt_vld pulse.

[0154] For each received write data byte, the CPLD performs the following operations: First, in response to the smb_wdt_vld signal, the CPLD latches the write data currently on the smb_wdt. Second, the CPLD drives the current APB address onto the apb_adr bus. (The rest of the text appears to be unrelated and likely refers to a different CPLD.) Figure 2 As shown, the APB addresses are A+0, A+1, A+2, A+3, and A+4, where A is the starting address of the decoded register, and subsequent addresses increment sequentially. Simultaneously, the CPLD drives the latched write data to the apb_wdt bus, sets the apb_write signal high (indicating a write operation), and sets the apb_sel and apb_ena signals to active levels, initiating a write transfer to the APB bus. The CPLD continuously monitors the apb_rdy signal. (The text abruptly ends here.) Figure 2 As shown, when the apb_rdy signal is high, it indicates that the APB slave device has completed writing data to the current address, and this APB write transfer is complete. After completing the writing to the current address, the CPLD restores apb_sel and apb_ena to their invalid states, preparing for the write transfer to the next address.

[0155] Phase 3: Address Increment and Continuous Writing.

[0156] The APB address signal apb_adr increments sequentially in each write transfer cycle: A+0, A+1, A+2, A+3, A+4. The CPLD internally maintains an address counter, which automatically increments by 1 after each APB write transfer, pointing to the next destination register address. The CPLD repeats the above data reception and APB write timing generation process until all write data bytes have been written to the corresponding destination register.

[0157] It should be noted that "latching the write data in the latch protocol access request" in step 1041 specifically refers to the CPLD storing the current data value on the smb_wdt bus into an internal register or buffer unit when it detects that smb_wdt_vld is valid. The latch operation ensures that the write data can stably drive the appb_wdt bus during subsequent APB write timing generation, avoiding write errors caused by data changes on the SMBUS bus. The latch is triggered by the valid edge of smb_wdt_vld (usually the rising edge). Each write data byte corresponds to an independent latch operation; the latched data remains stable until the next latch operation updates it.

[0158] Step 1042: When the read / write type is a read operation, read data from the target register, generate a read data valid flag, and send the read data to the initiator of the protocol access request through the read data port of the APB.

[0159] To facilitate understanding of the SMBUS read command access timing, combined with Figure 3 Please provide an explanation. Figure 3 The SMBUS read command access timing diagram provided for the embodiments of this application is as follows: Figure 3 As shown, this timing diagram illustrates the waveform changes of key signals when the CPLD processes SMBUS read commands. Figure 3 The signals include:

[0160] smb_cmd: SMBUS command code signal, carrying the command code sent by the master device (marked as RD in the figure, indicating a read command);

[0161] smb_cmd_vld: SMBUS command code validity flag signal. When this signal is high, it indicates that the command code on smb_cmd is valid.

[0162] smb_rdt: SMBUS read data signal, driven by CPLD, carrying data read from the target register and returned to the master device;

[0163] smb_rdt_vld: SMBUS read data valid flag signal, driven by CPLD. When this signal is high, it indicates that the read data on smb_rdt is valid.

[0164] apb_sel: APB selection signal, driven by CPLD, used to select the APB slave device;

[0165] apb_ena: APB enable signal, driven by CPLD, and works with apb_sel to generate APB transmission timing;

[0166] apb_adr: APB address signal, driven by CPLD, indicates the address of the target register currently being accessed;

[0167] apb_write: APB write control signal, driven by CPLD, and kept low during read operations;

[0168] apb_rdy: APB ready signal, driven by the APB slave device. A high level indicates that the slave device is ready to complete the current transmission.

[0169] apb_rdt: APB read data signal, driven by the APB slave device, carrying data read from the target register.

[0170] Similarly, the SMBUS read command access timing is divided into the following stages:

[0171] Phase 1: Command Reception Phase.

[0172] The SMBUS master device sends a read command code. The CPLD detects that the smb_cmd_vld signal is high and latches the SMBUS command code on smb_cmd. The CPLD decodes the SMBUS command code to obtain the register start address, continuous access length, and read / write type (read operation). Figure 3 The area marked "RD(2B)" corresponds to the SMBUS command code transmission stage, where 2B indicates that the continuous access length is 2 bytes.

[0173] Phase 2: APB read timing generation and data reading phase.

[0174] The CPLD generates a continuously increasing APB address sequence based on the decoded register start address and the consecutive access length. For example... Figure 3 As shown, the APB addresses are A+0 and A+1, where A is the starting address of the decoded register, and the subsequent addresses increase sequentially.

[0175] For each address in the APB address sequence, the CPLD performs the following operations: First, the CPLD drives the current APB address onto the apb_adr bus, sets the apb_write signal low (indicating a read operation), and sets the apb_sel and apb_ena signals to active levels, initiating a read transfer to the APB bus. Second, the CPLD continuously monitors the apb_rdy signal. When the apb_rdy signal is detected to be high, it indicates that the APB slave device has driven the data in the target register onto the apb_rdt bus, and the current APB read transfer is complete. Then, the CPLD latches the data read from the apb_rdt bus and drives this data onto the smb_rdt bus, while simultaneously setting the smb_rdt_vld signal high, returning the read data to the SMBUS master device. Figure 3 As shown, two data bytes, D0 and D1, appear sequentially on apb_rdt, and D0 and D1 also appear sequentially on the corresponding smb_rdt, with each data byte accompanied by an smb_rdt_vld pulse. After completing the reading of the current address, the CPLD restores apb_sel and apb_ena to an invalid state, preparing for the read transfer of the next address.

[0176] Phase 3: Address Increment and Continuous Reading.

[0177] like Figure 3 As shown, the APB address signal apb_adr increments sequentially in each read transfer cycle: A+0, A+1. The CPLD internally maintains an address counter and a byte counter. Each time an APB read transfer is completed, the address counter automatically increments by 1, and the byte counter increments by 1.

[0178] It should be noted that in step 1042, "generating a valid read data flag" specifically refers to the CPLD setting the smb_rdt_vld signal high after latching valid data from the apb_rdt bus, indicating that the data on smb_rdt is valid. The SMBUS master device can sample and read data during this period. Figure 3 As shown, the smb_rdt_vld pulse is aligned with the valid data on smb_rdt to ensure that the master device samples the correct data at the correct time. Each read data byte corresponds to an independent smb_rdt_vld pulse.

[0179] Step 1043: Record the number of bytes that have been accessed. When the number of bytes that have been accessed is equal to the length of the continuous access, end the current protocol access request.

[0180] For example, the CPLD internally sets up a byte counter, initially set to 0. The byte counter automatically increments by 1 after each successful APB read transfer (i.e., successfully latching a data byte from app_rdt); or, after each successful APB write transfer (i.e., successfully latching a data byte from app_wdt). After each update, the CPLD compares the current count value with the length of consecutive accesses.

[0181] If the current count value is less than the consecutive access length, then continue to initiate a read transfer (or write transfer) to the next address in the APB address sequence.

[0182] If the current count value equals the continuous access length, it means that all target registers have been read (or written). The CPLD ends the current read operation (or write operation), does not initiate a new APB read transfer (or write transfer), and can send a stop condition to the SMBUS master device.

[0183] It's important to note that the SMBUS and I2C protocols share the same read / write access logic. When the protocol type is I2C and it's a write operation, data is written to the target register via the APB write data port. When the protocol type is I2C and it's a read operation, the continuous access length is 1, and the above process degenerates into a single APB read transfer. Data is retrieved from the target register via the APB read data port and returned to the master device, sharing the same APB read timing generation and data reading process as the SMBUS read operation. Therefore, the SMBUS and I2C protocols achieve a unified read / write access path, eliminating the need to design separate read / write access logic for each protocol.

[0184] In this embodiment, by latching write data and driving it to the APB write data port in response to a data validity flag, and by latching data from the APB read data port and generating a read data validity flag, reliable conversion between SMBUS read / write data and APB bus data transmission is achieved. By recording the number of bytes accessed and comparing it with the continuous access length, the start and end of multi-byte block reads and writes are precisely controlled, ensuring transmission integrity. The SMBUS protocol and the I2C protocol share the same set of read / write access logic, eliminating the need for redesign.

[0185] exist Figure 2 and Figure 3 Based on this, next, combined with Figure 4 The protocol-compatible access method based on CPLD provided in the embodiments of this application is illustrated.

[0186] Figure 4 A block diagram illustrating the implementation of the CPLD-based protocol-compatible access method provided in this application embodiment is shown below. Figure 4 As shown, the core architecture of this solution includes the following functional modules: a decoding module, an address generation module, a control module, and an APB interface adapter module. Among them:

[0187] The decoding module receives the smb_cmd command code and the smb_cmd_vld validity flag from the target interface. This module has a pre-built programmable lookup table. Using smb_cmd as the lookup address, it searches for and parses the corresponding register access parameters, including the register start address, continuous access length, and read / write type, and outputs them to the control module.

[0188] The address generation module is used to generate a continuously increasing APB address sequence based on the register start address and continuous access length parsed by the decoding module, so as to provide address support for subsequent APB accesses.

[0189] The control module is the core scheduling unit of this solution, internally comprising two sub-modules: Write Control and Read Control. The Write Control module latches the write data on the smb_wdt in response to the valid smb_wdt_vld flag, and, in conjunction with the address generation module, writes the write data to the target register via the APB interface adapter module. The Read Control module reads data from the target register based on the address sequence provided by the address generation module, generates smb_rdt and smb_rdt_vld, and returns them to the master device via the SMBUS interface.

[0190] The APB interface adapter module is used to convert internal read and write requests initiated by the control module into standard APB bus timing signals, including output signals such as apb_sel, apb_ena, apb_addr, apb_write, and apb_wdt, and to monitor the apb_rdy and apb_rdt input signals to complete the handshake interaction with the APB bus.

[0191] Figure 5 A schematic diagram of the CPLD-based protocol-compatible access device provided in this application embodiment. Figure 1 .like Figure 5 As shown, the CPLD-based protocol-compatible access device 50 includes: an identification module 51, a decoding module 52, an address generation and APB adaptation module 53, and an access module 54. Wherein:

[0192] The identification module 51 is used to identify the protocol type of the protocol access request in response to the target interface receiving a protocol access request. The protocol type includes SMBUS protocol and I2C protocol.

[0193] Decoding module 52 is used to decode the SMBUS command code in the protocol access request based on CPLD when the protocol type is SMBUS protocol, and obtain the corresponding register access parameters. The register access parameters include read / write type, continuous access length and register start address.

[0194] Address generation and APB adaptation module 53 is used to generate access timing signals adapted to the APB protocol based on register access parameters according to the APB protocol.

[0195] Access module 54 is used to access the target register on APB based on access timing signals;

[0196] The SMBUS and I2C protocols reuse the same register architecture.

[0197] In one possible implementation, the CPLD has a pre-configured programmable lookup table. The decoding module 52 is specifically used to: use the SMBUS command code as the lookup table address, and use the programmable lookup table to find and parse the corresponding register access parameters. The programmable lookup table stores the mapping relationship between the SMBUS command code and the register access parameters.

[0198] like Figure 6 As shown, in one possible implementation, the CPLD-based protocol-compatible access device 50 further includes a processing module 55, configured to: when the protocol type is I2C, use the register address in the protocol access request as the register start address; and determine the read / write type according to the read / write flag bit in the protocol access request.

[0199] In one possible implementation, the address generation and APB adaptation module 53 is specifically used to: generate a continuously increasing APB address sequence based on the register start address and the continuous access length, wherein each address in the APB address sequence corresponds one-to-one with a register on the APB; and generate an access timing signal adapted to the APB protocol based on the APB protocol, according to the read / write type and the APB address sequence.

[0200] In one possible implementation, the access module 54 is specifically configured to: when the read / write type is a write operation, latch the write data in the protocol access request in response to the write data valid flag of the SMBUS protocol, and write the write data to the target register through the write data port of the APB; when the read / write type is a read operation, read data from the target register, generate a read data valid flag, and send the read data to the initiator of the protocol access request through the read data port of the APB; record the number of bytes that have been accessed, and terminate the current protocol access request when the number of bytes that have been accessed is equal to the continuous access length.

[0201] In one possible implementation, the programmable lookup table is configured with a hierarchical address mapping mechanism for expanding the register address space. The hierarchical address mapping mechanism includes: using the SMBUS command code as the lookup address, mapping the page address and the page offset base address from the programmable lookup table; combining the page address and the page offset base address to generate the complete register start address; wherein the addressing range of the complete register start address is greater than the depth of the programmable lookup table.

[0202] In one possible implementation, the mapping is configured through an initialization file imported at compile time, or updated via online programming.

[0203] The protocol-compatible access device based on CPLD provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0204] This application also provides a protocol-compatible access system, such as... Figure 7 As shown in the schematic diagram of the protocol-compatible access system provided in the embodiments of this application, the protocol-compatible access system 70 includes: a CPLD-based protocol-compatible access device 50, and a register module 71 connected to the CPLD-based protocol-compatible access device 50 via an APB. The register module 71 includes the target register in the aforementioned embodiments.

[0205] The CPLD-based protocol-compatible access device 50 is used to execute the CPLD-based protocol-compatible access method described in the foregoing embodiments, specifically including: identifying the protocol type of the protocol access request (SMBUS protocol or I2C protocol); decoding the SMBUS command code to obtain register access parameters; generating access timing signals based on the APB protocol; and accessing the target register in the register module 71 via the APB bus. The register module 71 is designed based on the APB protocol interface, compatible with the existing I2C register architecture, and accommodates the access requirements of both the SMBUS and I2C protocols. The SMBUS and I2C protocols reuse the same register module 71 through the CPLD-based protocol-compatible access device 50, eliminating the need to design separate register access interfaces for each protocol.

[0206] By using the above-mentioned protocol-compatible access system, the SMBUS and I2C protocols can reuse access to the same register architecture. When the register module needs to be upgraded, only one register architecture needs to be maintained, which significantly reduces development and maintenance costs.

[0207] This application also provides an electronic device, including the above-described protocol-compatible access system.

[0208] Specifically, the electronic device can be any of a server, computer, smart home appliance, industrial control equipment, or consumer electronics product. The protocol-compatible access system is located inside the electronic device, using a CPLD to enable compatible access to the same register architecture via both SMBUS and I2C protocols. When the main controller (such as a BMC, CPU, or MCU) in the electronic device accesses internal registers via SMBUS or I2C protocols, the protocol-compatible access system automatically identifies the protocol type, completes protocol conversion and register access, without requiring hardware switches or design changes. Thus, the electronic device can simultaneously support both SMBUS and I2C protocols on a single interface, reducing hardware redundancy and development and maintenance costs.

[0209] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A protocol-compatible access method based on CPLD, characterized in that, include: In response to the target interface receiving a protocol access request, the protocol type of the protocol access request is identified, and the protocol type includes the System Management Bus (SMBUS) protocol and the Inter-Integrated Circuit Bus (I2C) protocol; If the protocol type is SMBUS, then based on the complex programmable logic device CPLD, the SMBUS command code in the protocol access request is decoded to obtain the corresponding register access parameters, which include read / write type, continuous access length and register start address. Based on the Advanced Peripheral Bus (APB) protocol, access timing signals adapted to the APB protocol are generated according to the register access parameters. Based on the access timing signals, access the target register on APB; The SMBUS protocol and the I2C protocol reuse the same register architecture.

2. The protocol-compatible access method based on CPLD according to claim 1, characterized in that, The CPLD has a pre-set programmable lookup table. Decoding the SMBUS command code in the protocol access request to obtain the corresponding register access parameters includes: Using the SMBUS command code as the lookup table address, the corresponding register access parameters are found and parsed through the programmable lookup table, which stores the mapping relationship between the SMBUS command code and the register access parameters.

3. The protocol-compatible access method based on CPLD according to claim 1, characterized in that, Also includes: If the protocol type is I2C, then the register address in the protocol access request is used as the starting address of the register; The read / write type is determined based on the read / write flag in the access request of the protocol.

4. The protocol-compatible access method based on CPLD according to any one of claims 1 to 3, characterized in that, Based on the APB protocol, and according to the register access parameters, an access timing signal adapted to the APB protocol is generated, including: Based on the register start address and the consecutive access length, a continuously increasing APB address sequence is generated, wherein each address in the APB address sequence corresponds one-to-one with a register on the APB; Based on the APB protocol, an access timing signal adapted to the APB protocol is generated according to the read / write type and the APB address sequence.

5. The protocol-compatible access method based on CPLD according to any one of claims 1 to 3, characterized in that, The access to the target register on the APB based on the access timing signal includes: When the read / write type is a write operation, in response to the write data valid flag of the SMBUS protocol, the write data in the protocol access request is latched, and the write data is written to the target register through the write data port of the APB. When the read / write type is a read operation, data is read from the target register, a read data valid flag is generated, and the read data is sent to the initiator of the protocol access request through the read data port of the APB. Record the number of bytes that have been accessed. When the number of bytes that have been accessed is equal to the length of the continuous access, end the current protocol access request.

6. The protocol-compatible access method based on CPLD according to claim 2, characterized in that, The programmable lookup table is configured with a hierarchical address mapping mechanism, which is used to expand the register address space. The hierarchical address mapping mechanism includes: Using the SMBUS command code as the lookup address, the page address and the page offset base address are mapped from the programmable lookup table; The page address and the page offset base address are combined to generate the complete register start address; The addressing range of the complete register starting address is greater than the depth of the programmable lookup table.

7. The protocol-compatible access method based on CPLD according to claim 2, characterized in that, The mapping relationship is configured through an initialization file imported at compile time, or updated through online programming.

8. A protocol-compatible access device based on CPLD, characterized in that, include: The identification module is used to identify the protocol type of the protocol access request in response to the target interface receiving the protocol access request. The protocol type includes the System Management Bus (SMBUS) protocol and the Inter-Integrated Circuit Bus (I2C) protocol. The decoding module is used to decode the SMBUS command code in the protocol access request based on the complex programmable logic device CPLD when the protocol type is SMBUS protocol, and obtain the corresponding register access parameters. The register access parameters include read / write type, continuous access length and register start address. The address generation and APB adaptation module is used to generate access timing signals adapted to the APB protocol based on the Advanced Peripheral Bus (APB) protocol and the register access parameters. The access module is used to access the target register on the APB based on the access timing signal; The SMBUS protocol and the I2C protocol reuse the same register architecture.

9. A protocol-compatible access system, characterized in that, include: The protocol-compatible access device based on CPLD as described in claim 8; Additionally, a register module connected to the CPLD-based protocol-compatible access device via the Advanced Peripheral Bus (APB), the register module containing a target register.

10. An electronic device, characterized in that, include: The protocol-compatible access system as described in claim 9.

Images