An AHB bus cross-clock domain data synchronization method based on a custom handshake protocol

Abstract

The application discloses an AHB bus cross-clock domain data synchronization method based on a self-defined handshake protocol and particularly relates to the AHB technical field, which comprises the following steps: designing a self-defined handshake protocol, setting an AHB bus conversion bridge, setting an asynchronous FIFO synchronization circuit, setting a handshake protocol conversion bridge, and completing the cross-clock domain synchronization of a request path and a response path. Through the request and response full-handshake mechanism, the application can realize data synchronization between any clock domains in any frequency combination of a source clock domain and a target clock domain, avoid the timing conflict caused by the superposition of multiple requests, fix the READY signal of the response channel as a high level, and completely solve the deadlock problem of the existing pulse synchronization scheme. In addition, the application optimizes the depth required by the asynchronous FIFO circuit and the information between different clock domains by utilizing the characteristic that the in-transit request of the handshake protocol is less than or equal to 1, optimizes the timing of the AHB bus conversion bridge through scene conversion logic, realizes the request of any burst transmission type, and improves the synchronization and transmission efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of AHB, more particularly, the present application relates to a kind of AHB bus cross clock domain data synchronization method based on self-defined handshake protocol. BACKGROUND

[0002] In the field of integrated circuit design, AHB bus is widely used in data interaction between different functional modules due to its high performance and support for burst transmission, and cross clock domain data synchronization is one of the core requirements in AHB bus application. When AHB master and slave devices are in different clock domains, data reliable transmission needs to be realized through a specific synchronization scheme.

[0003] According to the search, the patent with the publication number CN104850524A discloses a cross clock domain AHB bus bridging method and device, which converts pulse to level and then to pulse signal. However, there is no corresponding feedback mechanism for the loop, which is easy to produce unexpected requests. At the same time, the synchronization circuit is sensitive to the frequency ratio between different clock domains, which causes deadlock between request and response.

[0004] The patent with the publication number CN100483377C discloses an asynchronous bridge and data transmission method, which realizes support for cross clock domain AHB bus burst transmission by using bidirectional memory to temporarily store read and write data during AHB bus burst transmission in the asynchronous bridge. However, in order to be compatible with burst transmission, the FIFO depth needs to meet the maximum number of burst transmission. For single transmission scenario, the depth of read and write FIFO cannot be effectively utilized, resulting in resource waste. At the same time, the number of states increases sharply due to synchronization problems, increasing the complexity of additional design and verification. SUMMARY

[0005] In order to overcome the above-mentioned defects of the prior art, the present application provides an AHB bus cross clock domain data synchronization method based on self-defined handshake protocol to solve the problems raised in the background art.

[0006] To achieve the above-mentioned purpose, the present application provides the following technical solution: an AHB bus cross clock domain data synchronization method based on self-defined handshake protocol, comprising the following steps:

[0007] S1: design a self-defined handshake protocol, which contains a request channel and a response channel, both channels are based on VALID and READY handshake mechanism transmission, the request channel contains TRANS, ADDR, SIZE, WRITE, WDATA signals, the response channel contains RESP, RDATA signals, the response channel handshake timing is later than the request channel handshake, and the number of requests in transit is ≤1;

[0008] S2: setting an AHB bus conversion bridge, converting an AHB bus request of a source clock domain into a request signal of the self-defined handshake protocol, the AHB bus request being divided into an ADDRESS PHASE and a DATA PHASE, and converting an AHB bus response of a target clock domain into a response signal of the self-defined handshake protocol;

[0009] The conversion logic of the AHB bus conversion bridge for a write request is that the request information is registered in the ADDRESS PHASE, and a handshake request is output in the first clock cycle of the DATA PHASE;

[0010] The conversion logic of the AHB bus conversion bridge for a read request is that when there is no write request registration, a handshake request is output in the first clock cycle of the ADDRESS PHASE, and when there is write request registration, a handshake request is output in the next clock cycle;

[0011] S3: setting an asynchronous FIFO synchronization circuit, the asynchronous FIFO having a depth of 1, receiving the handshake request output by the AHB bus conversion bridge in the source clock domain and writing the handshake request into the FIFO, reading the handshake request in the FIFO in the target clock domain, receiving the handshake response output by the AHB bus conversion bridge in the target clock domain and writing the handshake response into the FIFO, reading the handshake response in the FIFO in the source clock domain, and synchronizing the empty state signal or the full state signal of the asynchronous FIFO through a two-stage synchronizer;

[0012] S4: setting a handshake protocol conversion bridge, restoring the handshake request output by the asynchronous FIFO in the target clock domain into an AHB bus request and sending the AHB bus request to an AHB slave device, and restoring the handshake response output by the asynchronous FIFO in the source clock domain into an AHB bus response and sending the AHB bus response to an AHB master device;

[0013] S5: completing the cross-clock-domain synchronization of the request path and the response path, wherein the request path is from the source clock domain to the target clock domain, and the response path is from the target clock domain to the source clock domain.

[0014] Preferably, the WRITE signal and the request channel VALID signal of the self-defined handshake protocol in S1 are generated at the same time, and the WDATA signal is valid when the WRITE signal is at a high level.

[0015] The READY signal of the response channel is fixed at a high level.

[0016] Preferably, the self-defined handshake protocol in S1 supports all burst transmission types of the AHB bus, including the INCR and WRAP types.

[0017] Preferably, the AHB bus conversion bridge in S2 emulates the HREADY signal of the AHB bus DATAPHASE through the VALID signal of the handshake protocol, and emulates the HREADY signal of the AHB bus ADDRESS PHASE through the request register state of the handshake protocol.

[0018] Preferably, the restoration logic of the write request of the handshake protocol conversion bridge in S4 is: mapping the AHB request signal in the ADDRESS PHASE, and tapping the WDATA in the ADDRESS PHASE, and outputting the HWDATA in the DATA PHASE.

[0019] The restoration logic of the read request is: mapping the AHB request signal in the ADDRESS PHASE, and mapping the HRDATA signal in the DATA PHASE.

[0020] Preferably, the request channel and the response channel of the self-defined handshake protocol in S1 are separated, the VALID signal of the self-defined handshake protocol does not depend on the READY signal, and the READY signal can depend on the VALID signal.

[0021] Preferably, the read-write control logic of the asynchronous FIFO synchronization circuit in S3 is linked with the VALID signal and the READY signal of the self-defined handshake protocol, and the read-write operation is only performed when the READY signal is high.

[0022] Preferably, the READY signal of the response channel of the AHB bus conversion bridge in S2 is fixed as high, because the AHB bus can receive the response at any time in the DATAPHASE.

[0023] Preferably, the handshake protocol conversion bridge in S4 converts the VALID signal of the handshake request into the HTRANS signal of the AHB bus, and maps the ADDR, SIZE, and WRITE signals of the handshake request into the HADDR, HSIZE, and HWRITE signals of the AHB bus, respectively.

[0024] Preferably, the two-stage synchronizer in S3 is a two-stage D flip-flop, which is used to suppress metastability when the empty state signal or the full state signal is transmitted.

[0025] Technical effects and advantages of the present application:

[0026] 1. Through the request and response full handshake system, the response channel handshake is strictly later than the request channel, data synchronization is performed between any clock domains, no special synchronization circuit is needed for different frequency ratio designs, any frequency combination of the source clock domain and the target clock domain can be adapted, cross-clock domain compatibility is significantly improved, any clock frequency ratio is supported, the in-transit request of the self-defined handshake protocol is ≤1, which meets the AHB bus protocol limit, avoids timing conflicts caused by the superposition of multiple requests, the READY signal of the response channel is fixed to high level, there is no response blocking scene, and the deadlock problem of the existing pulse synchronization scheme is completely solved;

[0027] 2. By using the in-transit request of the handshake protocol ≤1, the FIFO depth is fixed to 1, only 1 data storage unit and 6 bit control signal storage unit are needed, the depth required by the asynchronous FIFO circuit and the information between different clock domains are optimized, the storage resource occupation is reduced compared with the traditional scheme, the problem that the traditional asynchronous FIFO needs to synchronize the read and write pointers through the Gray code is solved, the circuit logic is complex, the FIFO empty state signal and full state signal are processed through a two-stage synchronizer, which not only suppresses the metastability, but also simplifies the synchronization logic, reduces the consumption of hardware resources such as flip-flops, and the unified handshake protocol processes all transmission scenarios, without the need to design independent verification cases for different transmission types, the metastability suppression mechanism of the two-stage synchronizer and the fixed design of the FIFO depth of 1 reduce the workload of timing analysis and abnormal scene verification, and the verification period is shortened;

[0028] 3. The AHB bus conversion bridge optimizes the timing through scene conversion logic, the write request is converted in the first cycle of the DATA PHASE, the read request is directly converted in the ADDRESS PHASE without writing, which perfectly simulates the transmission characteristics of the AHB bus ADDRESS PHASE and DATA PHASE flow overlap, the transmission rate approaches the AHB bus flow limit, realizes the efficient conversion between the AHB bus protocol and the self-defined handshake protocol, realizes the transmission of any burst transmission type in the scene without losing transmission efficiency, improves the synchronization and transmission efficiency, and solves the problem that the existing scheme often decomposes the burst transmission into single transmission, which greatly reduces the efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 The application is an AHB bus cross-clock synchronization circuit application diagram structure diagram.

[0030] Figure 2 The application is an AHB bus cross-clock synchronization circuit structure diagram.

[0031] Figure 3 The application is an AHB bus read and write request conversion to handshake protocol read and write request waveform diagram.

[0032] Figure 4Waveform diagram for handshake protocol read-write request conversion to AHB bus read-write request of the application.

[0033] Figure 5 Waveform diagram for data synchronization under AHB bus request fast-to-slow clock domain of the application.

[0034] Figure 6 Waveform diagram for data synchronization under AHB bus request slow-to-fast clock domain of the application. DETAILED DESCRIPTION

[0035] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the application.

[0036] Embodiment:

[0037] As shown in the figure, the embodiment is applicable to the AHB bus cross-clock domain data transmission scenario in an integrated circuit: Figures 1-6

[0038] Source clock domain: deploy an AHB master device, the clock frequency can be set as mst_clk=100MHz, which can be flexibly adjusted to any frequency, and is responsible for initiating AHB read-write requests;

[0039] Target clock domain: deploy an AHB slave device, the clock frequency can be set as slv_clk=200MHz or 50MHz, supporting any frequency ratio, and is responsible for receiving and processing AHB requests and returning responses;

[0040] Core synchronization circuit: deploy an AHB bus conversion bridge, an asynchronous FIFO synchronization circuit, and a handshake protocol conversion bridge, to realize bidirectional data synchronization between the source clock domain and the target clock domain, and support all burst transmission types of the AHB bus such as single transmission, INCR increment, and WRAP wrap.

[0041] S1: design and implementation of a custom handshake protocol, in the embodiment, the custom handshake protocol is implemented through hardware logic Verilog or VHDL code, and the core includes a request channel module and a response channel module, both of which are independently designed and are based on the VALID and READY handshake mechanism, and the specific implementation details are as follows:

[0042] 1. Mapping of channel signals and AHB bus signals:

[0043]

[0044] ​

[0045] 2. Handshake timing rule implementation

[0046] Response later than request: The state of "request sent but no response received" is recorded by 1-bit status register req_pending, which is set to 1 when req_VALID and req_READY are both 1, i.e. the request handshake is successful; and set to 0 when rsp_VALID and rsp_READY are both 1, i.e. the response handshake is successful. This ensures that the response channel handshake is only triggered when req_pending = 1, and the response is later than the request.

[0047] In-flight request ≤ 1: The request channel enable is controlled by the state of req_pending register. Only when req_pending = 0, i.e. no in-flight request, req_VALID can be pulled high. This strictly limits the number of in-flight requests to be ≤ 1, which is consistent with the AHB bus protocol limitation.

[0048] VALID and READY dependency: The pull-up of req_VALID is only controlled by req_pending = 0 and AHB master request valid, and does not depend on req_READY. The pull-up of req_READY is controlled by the empty state of the asynchronous FIFO. FIFO empty indicates the receiving capability, but its validity is subject to req_VALID = 1. Only when req_VALID = 1, req_READY = 1 indicates that the request can be received. If req_VALID = 0, the state of req_READY does not affect the handshake, i.e. does not trigger the request reception. The response channel is the same.

[0049] 3. Full burst transmission support

[0050] For the INCR increment burst, WRAP wrap burst and other types of AHB bus, the continuous switching of req_TRANS signal is used to implement them. For example, in INCR4 burst transmission, the first request req_TRANS = NONSEQ (non-continuous), req_ADDR = 0x100, the second to fourth requests req_TRANS = SEQ (continuous), req_ADDR are 0x104, 0x108, 0x10C respectively. The protocol module identifies the burst type through the sequence of req_TRANS, ensures that the burst transmission is not interrupted, and supports all AHB burst transmission types.

[0051] S2: Implementation of AHB bus conversion bridge, the AHB bus conversion bridge is implemented through a timing logic circuit, the core function is to convert the ADDRESS PHASE and DATA PHASE signals of the AHB bus into request signals or response signals of a self-defined handshake protocol, and there are two types of scene designs, namely write request conversion and read request conversion, the specific implementation is as follows:

[0052] 1. Write request conversion logic, combined with a clock cycle example

[0053] The source clock domain mst_clk cycle is 10 ns, 100 MHz, and the AHB write request timing is as follows:

[0054] T1 cycle ADDRESS PHASE: AHB master outputs HTRANS = NONSEQ (request valid), HADDR = 0x200, HSIZE = 32bit (HSIZE = 010), HWRITE = 1 (write identifier), and the conversion bridge registers the above address, size and read-write identifier information through a D flip-flop, at this time HWDATA is not valid, and AHB write request WDATA is valid in DATA PHASE.

[0055] T2 cycle DATA PHASE: AHB master outputs HWDATA = 0xABCD1234, HREADY = 1 (indicating that DATA PHASE is valid), the conversion bridge combines req_ADDR = 0x200, req_SIZE = 010, req_WRITE = 1 with the current req_WDATA = 0xABCD1234, and pulls up req_VALID = 1 at the same time, the handshake request is valid, and the conversion of the write request to the handshake protocol is completed.

[0056] 2. Read request conversion logic

[0057] Scene 1: No write request registration: T1 cycle ADDRESS PHASE, AHB master outputs HTRANS = NONSEQ, HADDR = 0x300, HWRITE = 0 (read identifier), the conversion bridge has no unprocessed write request registration, directly combines req_ADDR = 0x300, req_SIZE = 010, req_WRITE = 0, and pulls up req_VALID = 1, without waiting for DATA PHASE, to realize fast conversion.

[0058] Scenario 2: There is a write request register: if the conversion bridge has registered the write request HADDR = 0x200 of the T0 period before the T1 period, the ADDRESS PHASE of the T1 period only registers the read request HADDR = 0x300, HWRITE = 0, and the original write request DATA PHASE is completed before the req VALID = 1 is pulled high, so as to avoid the conflict of read and write request signals.

[0059] 3. HREADY signal simulation

[0060] HREADY simulation of ADDRESS PHASE: The conversion bridge indicates whether the AHB master can send a new request through the request register state. When the conversion bridge has registered a write request and the DATA PHASE conversion is not completed, HREADY = 0 is output, which prohibits the AHB master from sending a new request. When there is no registered request, HREADY = 1 is output, which allows a new request to enter. This register state corresponds to the request register state of the handshake protocol, which realizes the request register state simulation of the HREADY of ADDRESS PHASE.

[0061] HREADY simulation of DATA PHASE: Because the rsp READY of the response channel has been fixed to 1, the completion of the response handshake is only determined by rsp VALID. Therefore, the conversion bridge directly maps the rsp VALID signal of the response channel to the HREADY signal of the AHB bus DATA PHASE. When rsp VALID = 1, the response is valid, HREADY = 1, indicating that the AHB master can receive the response. When rsp VALID = 0, HREADY = 0, waiting for the response, which realizes the VALID simulation of the HREADY of DATA PHASE.

[0062] 4. The READY of the response channel is fixed to high level

[0063] Because the AHB bus can receive responses at any time in the DATA PHASE without waiting for additional preparation, the rsp READY signal of the response channel is fixed to 1 through power-on or logic high level, which ensures that the response channel can receive response signals from the asynchronous FIFO at any time without the risk of response blocking.

[0064] S3: Implementation of asynchronous FIFO synchronization circuit, the asynchronous FIFO synchronization circuit is designed with a 1-depth storage unit and a two-stage synchronizer, which solves the problems of cross-clock domain data buffering and metastability suppression:

[0065] 1. Hardware structure of 1-depth FIFO

[0066] FIFO only contains 1 32-bit data storage unit (storing req_WDATA, rsp_RDATA) and 6-bit control signal storage unit (including 2-bit req_TRANS, 3-bit req_SIZE, 1-bit req_WRITE), as well as empty fifo_empty and full fifo_full state signals:

[0067] Source clock domain write operation: when the source clock domain req_VALID = 1 and fifo_empty = 1, i.e. FIFO is empty, it can be written, write enable wr_en = 1, write handshake request signal to the storage unit, and at the same time fifo_full = 1 from the clock domain perspective, fifo_empty = 0 from the source clock domain perspective.

[0068] Target clock domain read operation: when the target clock domain req_READY = 1 and fifo_full = 1, i.e. FIFO is full, it can be read out, read enable rd_en = 1, read handshake request signal from the storage unit, and at the same time fifo_empty = 1 from the source clock domain perspective, fifo_full = 0 from the target clock domain perspective.

[0069] 2. Implementation of two-stage synchronizer

[0070] Two-stage D flip-flop cascade is adopted to cross-clock domain synchronization of fifo_empty and fifo_full signals, taking the target clock domain to source clock domain fifo_empty as an example:

[0071] First stage flip-flop: clock terminal connects target clock slv_clk, data terminal connects target clock domain native signal fifo_empty, output empty_sync1, sample fifo_empty under target clock, and preliminarily stabilize the signal.

[0072] Second stage flip-flop: clock terminal connects source clock mst_clk, data terminal connects empty_sync1, output source clock domain available synchronized empty signal empty_sync2, sample empty_sync1 under source clock, completely suppress metastability, and ensure that fifo_empty used in source clock domain has no glitch.

[0073] Similarly, fifo_full signal is synchronized from source clock domain to target clock domain, and full_sync2 is obtained through two-stage D flip-flop, which is used for target clock domain read operation, realizing synchronization of empty and full state signals.

[0074] 3. Read-write control and handshake linkage

[0075] The write enable wr_en of the FIFO is controlled by the handshake request valid req VALID and the post-synchronization empty signal empty sync2, and wr_en = 1 only when req VALID = 1 and empty sync2 = 1; the read enable rd_en is controlled by the post-synchronization full signal full sync2 and the target clock domain receiving preparation req READY, and rd_en = 1 only when full sync2 = 1 and req READY = 1, realizing the linkage of the read-write control logic and the VALID and READY signals of the handshake protocol.

[0076] S4: Implementation of the handshake protocol conversion bridge, the function of the handshake protocol conversion bridge is to restore the handshake protocol signals read out by the asynchronous FIFO to AHB bus signals, which is divided into two scenarios of write request restoration and read request restoration, taking the target clock domain slv clk = 200MHz and the period 5ns as an example:

[0077] 1. Write request restoration logic

[0078] T3 period ADDRESS PHASE: FIFO reads out the handshake request signals req_ADDR = 0x200, req_SIZE = 010 (32bit), req_WRITE = 1, req_TRANS = 10 (NONSEQ), and the conversion bridge converts:

[0079] The req VALID signal read out by the FIFO (synchronized to the target clock domain and matched with the FIFO read enable timing) is combined with the value of req TRANS to convert HTRANS = NONSEQ of AHB;

[0080] The req_ADDR signal of the handshake protocol request channel is correspondingly set as the HADDR signal of the AHB bus, and the specific value of the HADDR signal is 0x200; the req_SIZE signal of the handshake protocol request channel is correspondingly set as the HSIZE signal of the AHB bus, and the specific value of the HSIZE signal is 010, wherein 010 corresponds to the data width of 32bit; the req_WRITE signal of the handshake protocol request channel is correspondingly set as the HWRITE signal of the AHB bus, and the specific value of the HWRITE signal is 1;

[0081] At the same time, the req WDATA = 0xABCD1234 is clocked by a D flip-flop, delayed by 1 clock period, and prepared for the DATA PHASE.

[0082] T4 cycle DATA PHASE: the conversion bridge outputs the req_WDATA after the clocking as HWDATA=0xABCD1234 of AHB, and monitors the HREADY signal of AHB slave, when HREADY=1, it indicates that the write data has been received by the slave, and the conversion bridge is ready to receive the response signal HRESP=OKAY of the slave.

[0083] 2, read request restoration logic

[0084] T3 cycle ADDRESS PHASE: the FIFO reads the handshake request signal req_ADDR=0x300, req_SIZE=010, req_WRITE=0, req_TRANS=NONSEQ, and the conversion bridge maps it as HADDR=0x300, HSIZE=010, HWRITE=0, HTRANS=NONSEQ, and no WDATA clocking, because the core of the read request is to obtain data from the slave, and there is no need to send write data to the slave, so there is no need to clock WDATA, that is, there is no write data for the read request.

[0085] T4 cycle DATA PHASE: the AHB slave reads data HRDATA=0x5678EFGH from the HADDR=0x300 address and outputs HRESP=OKAY, HREADY=1, the conversion bridge sets the HRDATA signal of the AHB bus to the rsp_RDATA signal of the handshake protocol response channel, the specific value of the rsp_RDATA signal is 0x5678EFGH; the HRESP signal of the AHB bus is set to the rsp_RESP signal of the handshake protocol response channel, the specific value of the rsp_RESP signal is 00, wherein 00 indicates the response state of OKAY; at the same time, the rsp_VALID signal of the handshake protocol response channel is pulled high to 1, so as to complete the conversion from the AHB bus protocol to the self-defined handshake protocol.

[0086] S5: complete synchronization process of request and response path, for example, the source clock domain 100MHz write request to the target clock domain 200MHz slave, and then to the source clock domain response, the complete synchronization process is as follows:

[0087] 1, request path:

[0088] T1 source clock, 10ns: the AHB master sends a write request HADDR=0x200, HWRITE=1, and the conversion bridge registers the address information;

[0089] T2 source clock: AHB master outputs HWDATA=0xABCD1234, conversion bridge outputs handshake request req_VALID=1, FIFO write enable wr_en=1, fifo_empty=1, request to write FIFO;

[0090] T3 (target clock, 5ns, corresponding to the middle time of source clock T2): fifo_full=1 of FIFO, conversion bridge read enable rd_en=1, read handshake request, restore to AHB write request HADDR=0x200, HWDATA=0xABCD1234;

[0091] T4 target clock: AHB slave receives write data, outputs HRESP=OKAY, HREADY=1.

[0092] 2, response path:

[0093] T4 target clock: target side conversion bridge converts HRESP=OKAY into handshake response rsp_VALID=1, rsp_RESP=00, writes into response side FIFO, depth 1, consistent with request side FIFO structure;

[0094] T5 (source clock, 15ns): fifo_full=1 of response side FIFO, source side conversion bridge reads handshake response, restores to AHB response HRESP=OKAY;

[0095] T5 source clock: AHB master receives HRESP=OKAY, req_pending is set to 0, and once cross-clock-domain write synchronization is completed.

[0096] Summary: The embodiment solves the deadlock problem of the existing pulse synchronization scheme by using the request and response closed-loop handshake, i.e., req_pending state control, to perform data synchronization between any clock domains, and the asynchronous FIFO depth is 1, only 1 storage unit and 2 groups of secondary synchronizers are required. By using the characteristic that the in-transit request of the handshake protocol is less than or equal to 1, the depth required by the asynchronous FIFO circuit and the information between different clock domains are optimized. Compared with the prior art, the FIFO depth of the embodiment is only 1, the logical resource occupation is reduced according to the number of storage units, the transmission rate is close to the pipeline limit of the AHB bus, reaches 98% of the clock frequency, the transmission rate is high, all burst transmission types of the AHB bus are supported, and the compatibility covers mainstream AHB application scenarios.

[0097] Finally, it should be noted that the drawings of the disclosed embodiments only involve the structures involved in the disclosed embodiments, and other structures can be referred to the general design, and the same embodiment and different embodiments of the present application can be combined with each other under the condition of no conflict;

[0098] Finally: the above only for the preferred embodiments of the present application, and not for limiting the present application, any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application, should be included in the scope of protection of the present application.

Claims

1. A method for cross-clock domain data synchronization on an AHB bus based on a custom handshake protocol, characterized in that: Includes the following steps: S1: Design a custom handshake protocol. The custom handshake protocol includes a request channel and a response channel. Both channels are based on the VALID and READY handshake mechanism for transmission. The request channel includes TRANS, ADDR, SIZE, WRITE, and WDATA signals. The response channel includes RESP and RDATA signals. The handshake sequence of the response channel is later than that of the request channel, and the number of requests in transit is ≤1. S2: Set up an AHB bus conversion bridge to convert the AHB bus request from the source clock domain into a request signal of the custom handshake protocol. The AHB bus request is divided into ADDRESS PHASE and DATA PHASE. Convert the AHB bus response from the target clock domain into a response signal of the custom handshake protocol. The AHB bus conversion bridge's conversion logic for write requests is as follows: register the request information in the ADDRESS PHASE and output a handshake request in the first clock cycle of the DATAPHASE. The AHB bus conversion bridge's conversion logic for read requests is as follows: when there is no write request register, a handshake request is output in the first clock cycle of ADDRESS PHASE; when there is a write request register, a handshake request is output in the next clock cycle. S3: Set up an asynchronous FIFO synchronization circuit. The asynchronous FIFO has a depth of 1. It receives the handshake request output by the AHB bus conversion bridge in the source clock domain and writes it into the FIFO. It reads the handshake request in the FIFO in the target clock domain. At the same time, it receives the handshake response output by the AHB bus conversion bridge in the target clock domain and writes it into the FIFO. It reads the handshake response in the FIFO in the source clock domain. The asynchronous FIFO synchronizes the empty state signal or the full state signal through a secondary synchronizer. S4: Set up a handshake protocol conversion bridge to restore the handshake request output by the asynchronous FIFO of the target clock domain to an AHB bus request and send it to the AHB slave device; restore the handshake response output by the asynchronous FIFO of the source clock domain to an AHB bus response and send it to the AHB master device. S5: Complete cross-clock domain synchronization of the request path and response path, where the request path is from the source clock domain to the target clock domain, and the response path is from the target clock domain to the source clock domain.

2. The AHB bus cross-clock domain data synchronization method based on a custom handshake protocol according to claim 1, characterized in that: In S1, the WRITE signal of the custom handshake protocol is generated simultaneously with the VALID signal of the request channel. When WRITE is high, the WDATA signal is valid. The READY signal of the response channel is fixed at a high level.

3. The AHB bus cross-clock domain data synchronization method based on a custom handshake protocol according to claim 1, characterized in that: The custom handshake protocol in S1 supports all burst transmission types of the AHB bus, including INCR and WRAP types.

4. The AHB bus cross-clock domain data synchronization method based on a custom handshake protocol according to claim 1, characterized in that: In S2, the AHB bus conversion bridge simulates the HREADY signal of the AHB bus DATA PHASE through the VALID signal of the handshake protocol response channel, and simulates the HREADY signal of the AHB bus ADDRESS PHASE through the request register status of the handshake protocol.

5. The AHB bus cross-clock domain data synchronization method based on a custom handshake protocol according to claim 1, characterized in that: The handshake protocol conversion bridge in S4 restores the write request logic as follows: map the AHB request signal in ADDRESS PHASE, press WDATA in ADDRESS PHASE, and output HWDATA in DATA PHASE. The logic for restoring read requests is as follows: map the AHB request signal in the ADDRESS PHASE and the HRDATA signal in the DATA PHASE.

6. The AHB bus cross-clock domain data synchronization method based on a custom handshake protocol according to claim 1, characterized in that: In the custom handshake protocol of S1, the request channel and the response channel are separated. The VALID signal of the custom handshake protocol does not depend on the READY signal, but the READY signal can depend on the VALID signal.

7. The AHB bus cross-clock domain data synchronization method based on a custom handshake protocol according to claim 1, characterized in that: The read / write control logic of the asynchronous FIFO synchronization circuit in S3 is linked with the VALID and READY signals of the custom handshake protocol, and read / write operations are performed only when the READY signal is high.

8. The AHB bus cross-clock domain data synchronization method based on a custom handshake protocol according to claim 1, characterized in that: The READY signal of the response channel of the AHB bus conversion bridge in S2 is fixed at a high level.

9. The AHB bus cross-clock domain data synchronization method based on a custom handshake protocol according to claim 1, characterized in that: The handshake protocol conversion bridge in S4 converts the VALID signal of the handshake request into the HTRANS signal of the AHB bus, and maps the ADDR, SIZE, and WRITE signals of the handshake request into the HADDR, HSIZE, and HWRITE signals of the AHB bus, respectively.

10. A method for cross-clock domain data synchronization on an AHB bus based on a custom handshake protocol according to claim 1, characterized in that: The secondary synchronizer in S3 is a two-stage D flip-flop used to suppress metastability during the transmission of empty and full state signals.

Images