A method and system for rapid order reporting using FPGA

Abstract

This application relates to the technical field of FPGA applications, and in particular to an FPGA-based rapid order reporting method and system, comprising: establishing a session connection; dividing TCP data packets into two paths for parsing, the first path being used to parse the TCP packet header and output bypass data for storage, and the second path being used to perform integrity checks on the TCP data packets to generate receive buffer data for caching; selecting session information for arbitration under arbitration conditions, obtaining session information with different sequence numbers and comparing them, and reading TCP stream data from the first or second path based on the comparison result; parsing the service packet header and disassembling the TCP stream data to obtain several service packets, performing timing adaptation on the packet tails of the service packets, performing risk control checks on the service packets, and initiating an order report after passing the checks. This application effectively achieves the requirement of rapid TCP order reporting.

Description

Technical Field

[0001] This application relates to the technical field of FPGA applications, and in particular to an FPGA-based rapid order reporting method and system. Background Technology

[0002] Modern financial markets, especially in the areas of securities, options, and foreign exchange trading, are characterized by speed, high frequency, and low latency. The transmission speed and processing rate of trading orders directly determine the competitiveness, profitability, and risk management capabilities of market participants. Even millisecond or microsecond-level latency differences can cause slippage, miss optimal prices, or put participants at a disadvantage in the fierce competition of algorithmic trading.

[0003] While traditional financial transaction communication protocols are widely used and stable, their overhead and processing flow are gradually becoming bottlenecks restricting speed improvements in scenarios where performance is paramount. This is especially true during large-scale concurrent order placements and periods of high market volatility, when systems need to handle massive numbers of order requests requiring timely responses.

[0004] To meet the stringent requirements of the financial industry for ultra-low latency, high throughput, and deterministic response, TCP fast order reporting is particularly important.

[0005] In existing FPGA-based order reporting methods, the TCP protocol is hardened based on the FPGA. After the TCP is fully verified, the correct data is sent to the packet unpacking module for risk control, and finally the order is reported.

[0006] This method, which involves disassembling and controlling the TCP stream only after the entire TCP stream has been inspected, increases the processing delay of business packets, resulting in a larger overall order reporting delay. Summary of the Invention

[0007] To meet the requirements of TCP fast packet reporting, this application provides an FPGA-based ultra-fast packet reporting method and system.

[0008] Firstly, this application provides an FPGA-based rapid order reporting method, employing the following technical solution:

[0009] An FPGA rapid order reporting method includes the following steps:

[0010] Establish a session connection;

[0011] The TCP data packet is divided into two paths for parsing. The first path is used to parse the TCP header and output bypass data for storage. The second path is used to perform integrity checks on the TCP data packet to generate receive buffer data and cache it.

[0012] Under the condition of arbitration, session information is selected for arbitration, session information is obtained and compared at different sequence numbers, and TCP stream data is read from the first or second channel according to the comparison result.

[0013] The service packet header is parsed and the TCP stream data is disassembled to obtain several service packets. The packet tail of the service packets is time-series adapted, and the service packets are subjected to risk control detection. If the detection is successful, an order is initiated.

[0014] In some embodiments, parsing the TCP header and outputting bypass data for storage includes the following steps:

[0015] Configure a bypass storage space that includes both the first and second spaces;

[0016] After parsing the TCP header, a pre-read sequence number, session ID, TCP packet length, and pre-read pulse signal are generated.

[0017] After detecting the predetermined pre-read pulse signal, the bypass data is stored in the first space or the second space based on the storage rules, and an identity ID corresponding to the first space or the second space is generated based on the pre-read sequence number, session ID, and TCP packet length.

[0018] The storage rules are as follows:

[0019] If the first space and / or the second space is not busy, the bypass data is stored in the non-busy space; if both the first space and the second space are busy, the bypass data is stored in the space corresponding to the oldest data.

[0020] In some embodiments, the second path is used to perform integrity checks on the TCP packets to generate receive buffer data and cache it, including the following steps:

[0021] After the integrity check is completed, the end sequence number, the detection result, and the end pulse signal are output.

[0022] In some embodiments, the following steps are also included:

[0023] When establishing a session connection, obtain the starting sequence number, session ID, and starting pulse;

[0024] Based on the start pulse signal, the session ID is stored in the session cache, and the session ID is used as an address to generate an independent sequence number cache for each session ID;

[0025] Based on the start pulse signal, the pre-read pulse signal, and the end pulse signal, the start sequence number, the pre-read sequence number, and the end sequence number are stored in the corresponding sequence number cache.

[0026] In some embodiments, under arbitration conditions, session information is selected for arbitration, the sequence numbers corresponding to the session information in different paths are obtained and compared, and TCP stream data is read in the first or second path based on the comparison result, including the following steps:

[0027] When the session cache is not empty and the current arbitrator is not busy, the arbitration conditions are considered to be met.

[0028] Read the session ID corresponding to one data session from the session cache, and obtain the corresponding stored start sequence number, pre-read sequence number and end sequence number based on the session ID;

[0029] When the value of the end sequence number is greater than the value of the start sequence number, the receive buffer data is read, and the difference between the value of the end sequence number and the value of the start sequence number is used as the arbitration length.

[0030] When the value of the pre-read sequence number is greater than the value of the end sequence number and the value of the end sequence number is equal to the value of the start sequence number, the bypass data is selected to be read, and the difference between the values ​​of the pre-read sequence number and the start sequence number is used as the arbitration length.

[0031] When the values ​​of the start sequence number, the pre-read sequence number, and the end sequence number are all equal, the current arbitration ends and the next arbitration is read.

[0032] In some embodiments, when reading TCP stream data in the first or second channel based on the comparison result, the method further includes determining the validity of the arbitration. Specifically,

[0033] If the arbitration length is non-zero and less than the preset condition header length, the current session ID is written back to the session cache to end the current arbitration, and the session ID is reselected in the session cache for the next arbitration.

[0034] If the arbitration length is greater than the condition header length, an arbitration valid signal is generated to read data in the first or second channel according to the arbitration result.

[0035] In some embodiments, parsing the service packet header and disassembling the TCP stream data to obtain several service packets includes the following steps:

[0036] Parse the business packet header to obtain the packet length field, and generate the business packet length based on the packet length field;

[0037] Based on the comparison between the read length and the length of the service packet, check whether the read length is not less than the length of the service packet;

[0038] If so, the corresponding service packet body is read and combined with the service packet header to form a service packet, and then the next unpacking is performed;

[0039] If not, update the length of the received buffer data and end the arbitration;

[0040] Wherein, when the service packet is the first packet, the reading length is the arbitration length, and when the service packet is not the first packet, the reading length is the remaining length.

[0041] In some embodiments, timing adaptation is performed on the end of the service packet, including the following steps:

[0042] When the service packet corresponds to the bypass data and is the first packet, an additional frame is added at the end of the service packet and the integrity detection result is stored, and the last frame and the penultimate frame are different frames;

[0043] When the service package corresponds to a non-first package, an extra beat is added at the end of the service package, and the last beat and the second-to-last beat are the same beat.

[0044] In some embodiments, when the service packet corresponds to the bypass data and is not the first packet, the following steps are included before comparing the read length with the service packet length:

[0045] Obtain the integrity check result corresponding to the last frame of the first packet. If the check fails, stop parsing the non-first packet and end the arbitration. If the check succeeds, continue parsing the non-first packet.

[0046] Secondly, this application provides an FPGA-based rapid reporting system, which adopts the following technical solution:

[0047] An FPGA-based rapid reporting system is provided to implement the above method.

[0048] The technical solutions provided by the embodiments of this application have the following technical effects:

[0049] By fully utilizing the parallel processing capabilities of FPGAs, and building upon existing high-frequency trading systems, TCP stream integrity checks, TCP stream packet unpacking, and risk control checks are processed in parallel, reducing the latency of business packets traversing the FPGA and thus achieving rapid TCP order reporting. Attached Figure Description

[0050] Figure 1 This is a schematic diagram illustrating the steps of an FPGA-based rapid order reporting method provided in this embodiment.

[0051] Figure 2 This is a logical schematic diagram of the FPGA rapid reporting method provided in the embodiments of this application.

[0052] Figure 3 This is a schematic diagram of the framework of the FPGA rapid reporting system provided in the embodiments of this application. Detailed Implementation

[0053] To better understand the purpose, technical solutions, and advantages of this application, it has been described and illustrated below with reference to the accompanying drawings and embodiments. However, those skilled in the art should understand that this application can be implemented without these details. In some cases, to avoid obscuring various aspects of this application due to unnecessary description, well-known methods, processes, systems, components, and / or circuits already described at a higher level will not be elaborated upon. It will be apparent to those skilled in the art that various modifications can be made to the embodiments disclosed in this application, and the general principles defined in this application can be applied to other embodiments and application scenarios without departing from the principles and scope of this application. Therefore, this application is not limited to the illustrated embodiments, but conforms to the broadest scope consistent with the scope of protection claimed in this application.

[0054] It should be noted that the descriptions of these embodiments are for the purpose of aiding understanding the present invention, but do not constitute a limitation thereof. Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0055] In the description of this application, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0056] In the description of this application, the terms "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples.

[0057] like Figure 1 and Figure 2 As shown in the figure, this application discloses an FPGA rapid order reporting method, which specifically includes the following steps:

[0058] S100, establish a session connection.

[0059] When a session connection is established, the following information will be output first: the start sequence number of the connection establishment start_seq, the session ID at the time of connection establishment sessionid, and the start pulse corresponding to the session establishment sid_set_p.

[0060] Among them, session is a one-hot code, sessionid is a decimal code used to represent the unique identity of the current packet, and the start pulse sid_set_p is the valid pulse corresponding to the establishment of the session, used to inform subsequent modules that "a new session has been established".

[0061] Meanwhile, after establishing a connection, the system further determines whether the data packet is a TCP packet. If an Ethernet packet is received, non-TCP packets are discarded according to the protocol, and only TCP packets are kept for parsing.

[0062] S200 divides TCP packets into two paths for parsing. The first path is used to parse the TCP header and output bypass data for storage. The second path is used to perform integrity checks on TCP packets to generate receive buffer data and cache it.

[0063] The parsed data is divided into two paths: one is bypass data, and the other is rxbuf data (receive buffer data).

[0064] In this process, after parsing the identification field of the TCP header, the bypass data sends the detection result corresponding to the raw TCP data to the subsequent module for storage, while the receive buffer data performs integrity checks on the entire data and stores the correct data in the cache after the check is completed.

[0065] S300 selects session information for arbitration under the arbitration conditions, obtains session information in different sequence numbers and compares them, and reads TCP stream data in the first or second channel according to the comparison result.

[0066] First, determine whether the read data meets the arbitration conditions. If so, select appropriate data from several stored session information based on the arbitration for subsequent unpacking and risk control detection.

[0067] During arbitration, the system further determines, based on session information and different sequence number information, whether to read and split the bypass data in the first channel or to read and split the receive buffer data in the second channel.

[0068] The sequence number information is updated at each stage of the process. For example, the starting sequence number start_seq triggered by the starting pulse sid_set_p is included, as well as the sequence number corresponding to the completion of the first channel and the sequence number corresponding to the completion of the second channel.

[0069] In this application, based on the split design, one data path is only pre-read, that is, the TCP flag field is parsed and then output, while the other path is output only after integrity testing. Therefore, the output timing of the two paths is different, so the specific data location to be selected can be determined based on the relationship between different sequence numbers at different time points.

[0070] S400 parses the business packet header and disassembles the TCP stream data to obtain several business packets. It performs timing adaptation on the packet tails of the business packets, performs risk control detection on the business packets, and initiates a report after passing the detection.

[0071] Based on the arbitration result, the TCP stream data is read from the corresponding path, and the TCP stream data is split into several business packets according to the required packet length. After subsequent risk control detection, the order is reported.

[0072] Based on the above method, by making full use of the parallel processing characteristics in FPGA, the integrity detection of TCP stream, the packet unpacking of TCP stream, and the risk control detection are processed in parallel on the basis of the existing high-frequency trading system, reducing the latency of business packets crossing in FPGA, thereby achieving the goal of fast TCP order reporting.

[0073] In other embodiments, parsing the TCP header and outputting bypass data for storage includes the following steps:

[0074] S210 is configured with bypass storage space including a first space and a second space.

[0075] This application divides the cache RAM into two spaces, each space supporting the caching of a maximum frame packet. In the following description, A refers to the first space and B refers to the second space.

[0076] S211, after parsing the TCP header, generates the pre-read sequence number, session ID, TCP packet length, and pre-read pulse signal.

[0077] After the first TCP header is parsed and the session allocation is completed, the pre-read sequence number pre_seq, session ID, TCP packet length tcp_len, and pre-read pulse signal pre_vld_p representing the completion of pre-reading will be output.

[0078] The pre-read sequence number is the initial sequence number corresponding to the current packet plus the data frame length of the TCP packet during parsing, and its session ID is transmitted based on the same session.

[0079] S212, after detecting the predetermined pre-read pulse signal, the bypass data is stored in the first space or the second space based on the storage rules, and an identity ID corresponding to the first space or the second space is generated based on the pre-read sequence number, session ID, and TCP packet length.

[0080] Upon detecting the pre-read pulse signal, bypass data packets are received and written to the corresponding buffers according to storage rules. Each buffer's stored data is marked to ensure that the correct data can be selected during subsequent data retrieval. The marking is based on data packets to configure a unique identity ID for each space. This ID is composed of the pre-read sequence number, session ID, and TCP packet length corresponding to the bypass data.

[0081] The storage rules are as follows:

[0082] If the first space and / or the second space are not busy, the bypass data will be stored in the non-busy space; if both the first space and the second space are busy, the bypass data will be stored in the space corresponding to the oldest data.

[0083] Specifically,

[0084] When the pulse signal pre_vld_p=1, if both buffers A and B are empty, then either buffer A or B is selected to store the current data, and the identity ID is stored in the register corresponding to either buffer A or B.

[0085] When the pulse signal pre_vld_p=1, if buffer A is not empty and buffer B is empty, then buffer B is selected to store the current data, and the identity ID is stored in the corresponding register of buffer B.

[0086] When the pulse signal pre_vld_p=1, if buffer A is empty and buffer B is not empty, then buffer A is selected to store the current data, and the identity ID is stored in the register corresponding to buffer A.

[0087] When the pulse signal pre_vld_p=1, if both buffer A and buffer B are not empty and no data is being read, then the old data frame is refreshed and the new data is written into the space where the older data exists.

[0088] When the pulse signal pre_vld_p=1, if both cache A and cache B are not empty and there is already cached data being read, then the data in the non-read cache needs to be refreshed.

[0089] The bypass data is temporarily stored because the first path, as the data for preprocessing, is characterized by "outputting before integrity checks are performed". It needs to be temporarily stored to wait for subsequent arbitration calls. The core function of the cache is to temporarily store bypass data, avoid data loss or waiting, and ensure the continuity of parallel processing.

[0090] Meanwhile, in this embodiment, the identity ID is also used to compare with the subsequent arbitration results. When a subsequent arbitration is received and data needs to be read from the bypass, the arbitration result needs to be compared with the identity ID in the cached data. If the comparison is OK, the cached data is used as the arbitration data for this arbitration and read by the subsequent module for unpacking and risk control detection. If the comparison fails, the current arbitration is terminated directly, and the current arbitration is written back for a new arbitration.

[0091] like Figure 2 As shown, in some other embodiments, the second path is used to perform integrity checks on TCP packets to generate receive buffer data and cache it, including the following steps:

[0092] S220, after the integrity check is completed, outputs the end sequence number, the test result and the end pulse signal.

[0093] After the integrity check of the entire data packet is completed, the end sequence number end_seq of the parsed data packet, the integrity check result, and the end pulse signal end_vld_p will be output.

[0094] The end pulse signal is used to inform subsequent modules that the integrity result of the current packet has been obtained, triggering the storage of the corresponding end sequence number and detection result. Simultaneously, this pulse also determines whether the receive buffer signal can be read by subsequent modules.

[0095] The end sequence number is the initial sequence number corresponding to the current packet plus the length of the TCP packet data frame after the integrity check is completed.

[0096] This enables the parallel processing of TCP data in multiple paths:

[0097] For bypass data, there is no need to wait for integrity check. It is immediately output and temporarily stored in the dual-zone buffer when the TCP identifier field (such as SYN, ACK) is parsed. It is given priority for subsequent packet disassembly, realizing "parallel integrity check and packet disassembly" and compressing the delay. At the same time, the bypass data is a complete TCP data packet, but it has not been checked for integrity. It needs to be matched with the identifier to ensure correctness later.

[0098] As for received cached data, it needs to wait for the integrity check of the entire data packet to be completed and the result to be qualified before it will be entered into the cache. As a backup data source, it is a qualified TCP data packet with integrity verification and can be directly used for packet unpacking and reporting.

[0099] like Figure 2 As shown, in some other embodiments, the following steps are also included:

[0100] S230, when establishing a session connection, obtain the starting sequence number, session ID and starting pulse.

[0101] S231, based on the start pulse signal, stores the session ID in the session cache, and uses the session ID as an address to generate an independent sequence number cache for each session ID.

[0102] S231, based on the start pulse signal, the pre-read pulse signal, and the end pulse signal, the start sequence number, the pre-read sequence number, and the end sequence number are stored in the corresponding sequence number caches respectively.

[0103] In scenarios involving multiple sessions, it is necessary to implement arbitration and sequence number management for these sessions.

[0104] Arbitration, in the context of multi-session concurrency, involves filtering out the currently processable session from multiple sessions stored in the cache according to conditions and rules, and determining whether the data for that session should be read from bypass data or from the aggregated receive buffer data. The core purpose of arbitration is to avoid data conflicts within a session, ensure the correctness of the data source being read, and provide a usable data address for subsequent packet unpacking.

[0105] To facilitate the selection of arbitration objects in multi-session scenarios, this application, when the start pulse signal start_vld_p=1, first stores each session separately, storing each session ID in a session cache, and then generates a sequence number cache based on the session ID as the address, storing the starting sequence number in the corresponding sequence number cache. Simultaneously, one-hot encoding is used as a storage flag; if the one-hot code corresponding to the current session ID is valid, it indicates that the current session ID has already been stored, and therefore it is not stored again, thus ensuring that each session ID is stored at most once.

[0106] When the pre-read pulse signal pre_vld_p=1, the corresponding pre-read sequence number is stored in the sequence number cache with the corresponding session ID as the address; when the end pulse signal end_vld_p=1, the corresponding end sequence number is stored in the sequence number cache with the session ID as the address.

[0107] During subsequent arbitration, the session ID is selected from the session cache to determine whether arbitration can be performed, and the corresponding sequence number for each stage can be directly obtained based on the session ID during arbitration.

[0108] In other embodiments, under arbitration conditions, session information is selected for arbitration, the sequence number corresponding to the session information in different paths is obtained and compared, and TCP stream data is read from the first or second path based on the comparison result, including the following steps:

[0109] S310: When the session cache is not empty and the current arbitrator is not busy, the arbitration conditions are considered met.

[0110] Before arbitration, it is necessary to determine whether the basic conditions for arbitration are met. The first condition is that the session cache is not empty, that is, the session to be processed is stored in the current session ID. The second condition is that no other arbitration requests are being processed at present, that is, there is no concurrent conflict.

[0111] S320 reads the session ID corresponding to one data session from the session cache, and obtains the corresponding stored start sequence number, pre-read sequence number, and end sequence number based on the session ID.

[0112] When the arbitration conditions are met, first read the cached data and obtain the session ID of the current arbitration. Then, based on the session ID, read the start sequence number, pre-read sequence number, and end sequence number from the corresponding sequence number cache. At the same time, select the cache location for reading data based on the numerical relationship of the above three sequence numbers.

[0113] S330: When the value of the end sequence number is greater than the value of the start sequence number, select to read the receive buffer data and use the difference between the value of the end sequence number and the value of the start sequence number as the arbitration length.

[0114] When end_seq > start_seq, read the receive buffer data, and the length read is end_seq - start_seq.

[0115] S340, when the value of the pre-read sequence number is greater than the value of the end sequence number and the value of the end sequence number is equal to the value of the start sequence number, select to read bypass data and use the difference between the values ​​of the pre-read sequence number and the start sequence number as the arbitration length.

[0116] When pre_seq > end_seq = start_seq, bypass data is read, and the length read is pre_seq - start_seq.

[0117] S350: When the values ​​of the start sequence number, the pre-read sequence number, and the end sequence number are all equal, the current arbitration ends and the next arbitration is read.

[0118] When end seq=pre_seq=start seq, it indicates that there is no data in the current cache, the current arbitration ends, and the next arbitration begins.

[0119] The above scheme is based on the fact that the sequence number changes with the business, and the sequence number is a 32-bit unsigned integer (as defined by the TCP standard). The comparison logic is to directly compare the decimal values.

[0120] The values ​​of the pre-read sequence number and the end sequence number should be the same; the only difference between them is the timing of their generation.

[0121] Since the end sequence number is generated after the integrity check, if it is greater than the start sequence number, it means that the data has completed the integrity check and passed the check. Therefore, this data, as a subsequent data packet after the session is established, needs to be received with verified buffered data to ensure its correctness.

[0122] If the end sequence number and the start sequence number are the same, it means that the integrity check has not been completed, resulting in the end sequence number not being updated. However, if the pre-read sequence number is at its maximum value, it means that the packet header has been parsed. In this case, bypass data is used to pre-disassemble the packet, realizing a technical solution of parallel integrity check and packet disassembly, thus reducing latency.

[0123] When all three values ​​are the same, it indicates that the packet is the first packet after the session was established. The integrity check was not completed, the packet header parsing was not updated, and the data is unavailable. Therefore, the current sanctions are terminated and another session ID is selected from the session cache for a new arbitration.

[0124] like Figure 2 As shown, in some other embodiments, when reading TCP stream data in the first or second channel based on the comparison result, the method further includes determining the validity of the arbitration. Specifically,

[0125] S360: If the arbitration length is non-zero and less than the preset condition header length, the current session ID is written back to the session cache to end the current arbitration, and a new session ID is selected in the session cache for the next arbitration.

[0126] S370, if the arbitration length is greater than the condition header length, an arbitration valid signal is generated to read data in the first or second channel according to the arbitration result.

[0127] Furthermore, after determining which route to read the data from, it is necessary to verify an arbitration condition again: length compliance. That is, the data packet length of the session data selected by arbitration must meet the "minimum length for splitting" under the business requirements (i.e., the data length is sufficient to split into at least one business packet to avoid splitting failure).

[0128] The header length of the condition packet is a fixed value statically defined by the exchange protocol (e.g., 8 bytes, with the header byte count being uniform across all business packets). To disassemble a complete business packet, the minimum requirement is...

[0129] According to the arbitration result, if the arbitration length is not equal to 0 and is less than the business packet header length, it means that the data corresponding to the current arbitration length is insufficient to complete the parsing process of a single packet disassembly. In this case, the arbitration result is invalid, and the current session ID needs to be written back to the session cache to end the current arbitration. Then, another session ID is selected from the session cache for the next arbitration. If the arbitration length is greater than the condition packet header length, it means that the arbitration is valid and subsequent packet disassembly operations are allowed.

[0130] In other embodiments, parsing the service packet header and unpacking the TCP stream data to obtain several service packets includes the following steps:

[0131] S410, parse the business packet header to obtain the packet length field, and generate the business packet length based on the packet length field.

[0132] First, based on the arbitration result, read the TCP stream data from the first or second channel and store its data length in real time (this data length will change with the subsequent unpacking process, and is the remaining length after each use).

[0133] The packet header is parsed, and the packet length is generated based on the "total length of this service packet" recorded in a reserved field (such as bytes 3-4) at a specific location in the header. The packet length represents the amount of data required to perform the packet unpacking operation.

[0134] S420 compares the read length with the business packet length to determine if the read length is not less than the business packet length.

[0135] S430, if so, then read the corresponding service packet body and combine it with the service packet header to form a service packet and perform the next unpacking.

[0136] S440, if not, update the length of the receive buffer data and end arbitration.

[0137] The length of the target data to be read is compared with the length of the business packet. If the length of the read data is not less than the length of the business packet, it means that the length of the data being read fully meets the length requirement of a business packet. Then, based on the known packet header and packet length, the size of the packet body is calculated by subtracting the packet header from the packet length, and the data of the corresponding length is read and integrated into a business packet in one unpacking operation.

[0138] If the read length is less than the length of the business packet, it means that the current read data size cannot meet the data length requirement of a business packet. In this case, the length of the receive buffer data is updated and the current arbitration ends.

[0139] Meanwhile, during the unpacking process, the read length varies depending on whether a business packet is the first packet or not.

[0140] Specifically, when the service packet is the first packet, the read length is the arbitration length; when the service packet is not the first packet, the read length is the remaining length. This is because when the service packet is the first packet, it means that the TCP stream data corresponding to the session ID is being processed for the first time, and its corresponding remaining length is the initial arbitration length. When the service packet is not the first packet, it means that the remaining length read is the arbitration length minus the length of multiple service packets, resulting in the remaining data length.

[0141] When the remaining length read is insufficient for further depacketization, updating the length of the receive buffer data serves the purpose of updating the length of the receive buffer data. Since the effective bytes of the bypass data and the receive buffer data are exactly the same, the only difference lies in the processing timing. When data cannot be depacketized because the remaining bytes do not meet the service packet length requirements, the data consumption progress of the bypass needs to be synchronized to the receive buffer data. This is because the receive buffer data is a "reliable" data source. If subsequent depacketization from rxbuf is required, it must be ensured that its length is the "actual remaining amount after deducting the consumed bypass portion" to avoid data duplication or omission.

[0142] It should be clarified that updating the length of the receive buffer data here does not mean updating the total storage length of the receive buffer data, but rather updating the used length of the receive buffer data (i.e., the length consumed by bypass processing).

[0143] When bypass processing is interrupted, updating the length of the receive buffer is to "make the state of the fallback data source consistent with the bypass", ensuring that subsequent data unpacking can be based on the "accurate remaining length", so as not to repeat processing or miss data - ultimately supporting the dual goals of "low latency" and "high reliability".

[0144] like Figure 2 As shown, in some other embodiments, timing adaptation is performed on the end of the service packet, including the following steps:

[0145] S450: When a service packet corresponds to bypass data and is the first packet, an additional clock signal is added at the end of the service packet to store the integrity check result, and the last clock signal and the penultimate clock signal are different clock signals.

[0146] S460, when the service packet corresponds to a non-first packet, add a beat at the end of the service packet and make the last beat the same as the second to last beat.

[0147] Furthermore, since the bypass data is data that has not undergone TCP flow integrity detection, an extra beat needs to be added at the end of the first packet when the service packet corresponds to the first packet, and the integrity detection result of the current packet needs to be stored. That is, the original last beat eop of the first packet is transformed into the second to last beat pre_eop, and the added beat is used as the new last beat eop.

[0148] When the service packet is not the first packet, a second-to-last pre_eop is added directly to the eop position of the last packet, and eop and pre_eop are in the same packet.

[0149] In this application, a marker is added to the end of each service packet. The last marker, eop, is the end-of-packet marker, while the penultimate marker, pre_eop, is the preamble marker. The penultimate marker is used to prompt subsequent modules to unpack the packet, while the last marker carries the verification result.

[0150] Asynchronous timing is characterized by the penultimate and final timings of a data packet being output in two adjacent time periods, meaning the penultimate timing is one time period earlier than the final timing; synchronous timing is characterized by the penultimate and final timings of a data packet being output in the same clock period, meaning their rising edges are aligned.

[0151] The key to parallel processing without sacrificing reliability in the staggered timing design is to output the first data packet in advance for unpacking. However, the integrity verification of the other path often requires waiting for 1-2 timings. The staggered timing design allows the penultimate timing pre_eop to be output 1 timing before the last timing eop, informing the subsequent modules to prepare to receive the detection result. After the detection result is obtained, the last timing eop outputs the result, ensuring that a reliable conclusion is obtained at the end of the unpacking.

[0152] For non-first packets, there is no need to unpack them in advance; data can be output only after integrity verification is completed. The synchronous design synchronizes pre_EOP with EOP, linking unpacking and verification results in real time, with a processing latency of 0 beats, making it suitable for low-latency sensitive services (such as real-time market data subscriptions).

[0153] In other embodiments, when the service packet corresponds to bypass data and is not the first packet, the following steps are included before comparing the read length with the service packet length:

[0154] S470: Obtain the integrity check result corresponding to the last frame of the first packet. If the check fails, stop parsing non-first packets and end arbitration. If the check succeeds, continue parsing non-first packets.

[0155] When a business packet is read from bypass data and is not the first packet, since the first packet is the object to be output and unpacked in advance, the subsequent processing logic of the first packet can be determined based on the integrity check result of the last row of the first packet.

[0156] If the last byte of the first packet corresponds to an unqualified packet, the data in the first packet is deemed invalid. In this case, the unpacking process is immediately terminated, and no more data is transmitted to subsequent reporting modules. At the same time, the usage length is updated and the current session ID is written back to the session cache. If the last byte of the first packet corresponds to a qualified packet, the data in the first packet is determined to be reliable. The subsequent unpacking, risk control detection, and reporting are then completed. The remaining byte length is updated, and preparation is made to process subsequent data.

[0157] By adapting the timing and analyzing the detection results of the last packet, the timing contradiction between "premature unpacking of bypass data" and "lagging integrity verification" is resolved. This provides a decision-making basis for "whether to continue processing" for non-first packets, preventing invalid data from entering the reporting process.

[0158] like Figure 3As shown, this application also discloses an FPGA-based rapid reporting system for implementing the above method, specifically including:

[0159] The modules include TOE, sid_arb, bypass_ctrl, unpack_ctrl, ic_chk, and the order reporting module.

[0160] The TOE module primarily uses hardware logic to perform the core functions of the TCP protocol, including connection-oriented session management, end-to-end reliable transmission, and data integrity assurance.

[0161] The sid_arb module mainly implements multi-session arbitration and TCP sequence number management.

[0162] The bypass_ctrl module is mainly responsible for storing and managing the bypass data transmitted from the TOE module.

[0163] The unpack_ctrl module is mainly responsible for splitting the TCP stream into business packets and passing them as single packets to the subsequent reporting module for reporting.

[0164] The order reporting module mainly performs risk control checks on the split order data and then reports the data packets to the exchange via the TCP protocol.

[0165] The implementation principle is as follows:

[0166] By fully utilizing the parallel processing capabilities of FPGAs, and building upon existing high-frequency trading systems, TCP stream integrity checks, TCP stream packet unpacking, and risk control checks are processed in parallel, reducing the latency of business packets traversing the FPGA and thus achieving rapid TCP order reporting.

[0167] It should be understood that although the steps in the flowcharts in the accompanying drawings are shown sequentially as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise expressly stated herein, there is no strict order in which these steps are performed, and they may be performed in other orders.

[0168] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A rapid order reporting method for FPGA, characterized in that, Includes the following steps: Establish a session connection; The TCP data packet is divided into two paths for parsing. The first path is used to parse the TCP header and output bypass data for storage. The second path is used to perform integrity checks on the TCP data packet to generate receive buffer data and cache it. Under the condition of arbitration, session information is selected for arbitration, session information is obtained and compared at different sequence numbers, and TCP stream data is read from the first or second channel according to the comparison result. The service packet header is parsed and the TCP stream data is disassembled to obtain several service packets. The packet tail of the service packets is time-series adapted, and the service packets are subjected to risk control detection. If the detection is successful, an order is initiated.

2. The FPGA rapid order reporting method according to claim 1, characterized in that, Parsing the TCP header and outputting bypass data for storage includes the following steps: Configure a bypass storage space that includes both the first and second spaces; After parsing the TCP header, a pre-read sequence number, session ID, TCP packet length, and pre-read pulse signal are generated. After detecting the predetermined pre-read pulse signal, the bypass data is stored in the first space or the second space based on the storage rules, and an identity ID corresponding to the first space or the second space is generated based on the pre-read sequence number, session ID, and TCP packet length. The storage rules are as follows: If the first space and / or the second space is not busy, the bypass data is stored in the non-busy space; if both the first space and the second space are busy, the bypass data is stored in the space corresponding to the oldest data.

3. The FPGA rapid order reporting method according to claim 2, characterized in that, The second path is used to perform integrity checks on the TCP packets to generate receive buffer data and cache it, including the following steps: After the integrity check is completed, the end sequence number, the detection result, and the end pulse signal are output.

4. The FPGA rapid reporting method according to claim 3, characterized in that, It also includes the following steps: When establishing a session connection, obtain the starting sequence number, session ID, and starting pulse; Based on the start pulse signal, the session ID is stored in the session cache, and the session ID is used as an address to generate an independent sequence number cache for each session ID; Based on the start pulse signal, the pre-read pulse signal, and the end pulse signal, the start sequence number, the pre-read sequence number, and the end sequence number are stored in the corresponding sequence number cache.

5. The FPGA rapid order reporting method according to claim 4, characterized in that, Arbitration is performed on session information when the arbitration conditions are met. The sequence number of the session information in different paths is obtained and compared. Based on the comparison result, TCP stream data is read from the first or second path. The process includes the following steps: When the session cache is not empty and the current arbitrator is not busy, the arbitration conditions are considered to be met. Read the session ID corresponding to one data session from the session cache, and obtain the corresponding stored start sequence number, pre-read sequence number and end sequence number based on the session ID; When the value of the end sequence number is greater than the value of the start sequence number, the receive buffer data is read, and the difference between the value of the end sequence number and the value of the start sequence number is used as the arbitration length. When the value of the pre-read sequence number is greater than the value of the end sequence number and the value of the end sequence number is equal to the value of the start sequence number, the bypass data is selected to be read, and the difference between the values ​​of the pre-read sequence number and the start sequence number is used as the arbitration length. When the values ​​of the start sequence number, the pre-read sequence number, and the end sequence number are all equal, the current arbitration ends and the next arbitration is read.

6. The FPGA rapid order reporting method according to claim 5, characterized in that, When reading TCP stream data from the first or second path based on the comparison results, the process also includes determining the validity of the arbitration. Specifically, If the arbitration length is non-zero and less than the preset condition header length, the current session ID is written back to the session cache to end the current arbitration, and the session ID is reselected in the session cache for the next arbitration. If the arbitration length is greater than the condition header length, an arbitration valid signal is generated to read data in the first or second channel according to the arbitration result.

7. The FPGA rapid order reporting method according to claim 5, characterized in that, Parsing the service packet header and disassembling the TCP stream data to obtain several service packets includes the following steps: Parse the business packet header to obtain the packet length field, and generate the business packet length based on the packet length field; Based on the comparison between the read length and the length of the service packet, check whether the read length is not less than the length of the service packet; If so, the corresponding service packet body is read and combined with the service packet header to form a service packet, and then the next unpacking is performed; If not, update the length of the received buffer data and end the arbitration; Wherein, when the service packet is the first packet, the reading length is the arbitration length, and when the service packet is not the first packet, the reading length is the remaining length.

8. The FPGA rapid order reporting method according to claim 5, characterized in that, Timing adaptation is performed on the end of the service packet, including the following steps: When the service packet corresponds to the bypass data and is the first packet, an additional frame is added at the end of the service packet and the integrity detection result is stored, and the last frame and the penultimate frame are different frames; When the service package corresponds to a non-first package, an extra beat is added at the end of the service package, and the last beat and the second-to-last beat are the same beat.

9. The FPGA rapid reporting method according to claim 8, characterized in that, When the service packet corresponds to the bypass data and is not the first packet, the following steps are included before comparing the read length with the service packet length: Obtain the integrity check result corresponding to the last frame of the first packet. If the check fails, stop parsing the non-first packet and end the arbitration. If the check succeeds, continue parsing the non-first packet.

10. An FPGA-based rapid reporting system, characterized in that, Used to implement the method as described in any one of claims 1-9.

Images