Cache structures for high performance hardware-based processors.

Abstract

High performance computing systems and methods are provided that may be used to implement functions such as a matching book processor, a data feed service, and the like. The system and method of the present invention organizes data representing orders into highly efficient cache line structures called tiles. Each tile contains order data for a given product, side, and price. The order data within each tile is further organized as access nodes containing the minimum data necessary to process the order. The array of access nodes is further organized into one or more prioritized groups of active and / or free access nodes.

Description

Related Applications

[0001] This application claims priority to co-pending U.S. Provisional Patent Application No. 63 / 430,835, filed December 7, 2022, U.S. Provisional Patent Application No. 63 / 430,777, filed December 7, 2022, and U.S. Provisional Patent Application No. 63 / 430,778, filed December 7, 2022, the entire contents of each of which are incorporated herein by reference. [Technical Field]

[0002] This application relates to high performance computing systems such as may be used to implement matching book processors and data feed services in electronic trading systems. [Background technology]

[0003] An electronic order matching system, also known as a matching engine (ME), is an electronic system that matches (executes) orders for the purchase and sale of financial instruments or securities, such as stocks, futures, and commodities. When a buyer and seller match for a particular financial instrument, a "trade" or "execution" transaction occurs. The terms "trade" and "execution" are synonymous. For a given financial instrument, there is often a price gap on the book between the best (lowest) ask price among sellers and the best (highest) bid price among buyers, meaning that an order may not be executed immediately. Such unmatched orders remain on the book and are commonly referred to as "resting orders," or as liquidity additions or liquidity injections. The term "book," while now automated by electronic data stores, is an ancient term dating back to the days when people recorded orders by hand in paper "books." Resting orders are stored until they are canceled or executed. A matching order with its counterpart resting order is completed / concluded as a "trade" event. When a party matches the waiting liquidity, the liquidity is considered removed.

[0004] U.S. Patent Application Publication US20150081508A1 (Patent Document 1) describes numerous techniques for an electronic trading system, including a user portal for educational and informational purposes, which allows investors to configure market routing and trade settings for electronic trading orders.

[0005] US Patent Application Publication US20150073967A1 (Patent Document 2) describes a method and system for providing an electronic buy order management infrastructure on a server that accepts electronic trading orders from various trading entities and determines their market, whereby a transmission means introduces a certain amount of transmission latency before the trading order reaches an electronic exchange and can be executed. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] US Patent Application Publication No. 2015 / 081508 [Patent Document 2] US Patent Application Publication No. 2015 / 073967 Summary of the Invention [Problem to be solved by the invention]

[0007] Various embedded hardware technologies, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), digital signal processors (DSPs), reduced instruction set computing (RISC), and advanced RISC machines (ARMs), are well known for enabling the implementation of hardware logic gate arrays and / or programming them to execute predetermined logic at high speeds. Such embedded hardware can significantly increase execution speeds compared to general-purpose processor-based platforms. When building such hardware-accelerated designs, the size of the data set imposed by the application strongly influences the upper limit of achievable performance. Therefore, minimizing the use of external memory is crucial. In other words, a general rule of thumb for today's embedded hardware implementations is that it is difficult to build systems that operate at nanosecond resolution unless the data model is well-matched to the internal memory resources (also known as block random access memory, or RAM). For example, the data sets imposed by Matching Engine Book (MEB) applications and Matching Engine Data Feed services are, by their nature, heavy-tailed and random, and large in size, necessitating the use of external memory.

[0008] If external memory access becomes a design requirement, the next important consideration is to minimize the number of memory access operations per application process while maximizing the functional density of the data stored in external memory.

[0009] Another consideration is organizing or arranging the data in a way that effectively provides "implicit indexing" to the data when building embedded hardware-based processors. Intelligently prescribing how data collections are organized "spatially" can reduce the need for additional indexing of the data. Also, finding ways to minimize indexing and metadata can minimize the number of memory structures that need to be accessed sequentially. [Means for solving the problem]

[0010] Thus, in one preferred embodiment, an electronic data processing system provides one or more market functions. The system includes at least one data processing means operating using one or more memory devices. At least some of the memory devices provide cache memory local to the data processing means (e.g., located on the same semiconductor chip as the processing means). The cache stores order data in the form of tile structures. The tile structures have an arrangement of smaller structures called access nodes. The access nodes represent orders for a given financial instrument (e.g., stock symbol), side (buyer or seller), and price. Preferably, access nodes corresponding to a given instrument, side, and price are stored in the same tile. Furthermore, one or more head references and / or tail references organize the access nodes in each tile into one or more prioritized groups. Such prioritized groups may include active and / or free access nodes.

[0011] The access node may include a reference to a cell data structure having additional data describing the order.

[0012] The prioritized collection may be sorted based on one or more attributes of the access nodes (eg, by sequence number, time received, quantity, etc.).

[0013] The prioritized collection may be implemented as a linked list, where each access node contains a reference to the next access node or a reference to the previous access node.

[0014] The prioritized collection may be implemented as a docked list, the docked list including the head and tail references, each access node including a reference to a next access node and a reference to a previous access node.

[0015] Two or more tiles may be stored contiguously and accessed at one memory address.

[0016] In some embodiments, the storage means may include off-chip DRAM and on-chip block RAM. In that case, tile movements may involve any combination of off-chip DRAM addresses and on-chip block RAM addresses. In other words, source and destination addresses for accessing the storage means may include off-chip DRAM addresses, on-chip block RAM addresses, or both.

[0017] The tiles are generated at a predetermined size, but it may be possible to store and access groups of tiles as larger arrays.

[0018] If the number of access nodes corresponding to a given product, side, and price stored in a single tile exceeds a predetermined number, the tile may contain a reference to another tile, and such expansion of the tile may be performed dynamically as additional access nodes are stored.

[0019] The first access node contained within a tile may be accessed during an early part of the transfer process for that tile, before the tile has been fully loaded into the cache memory portion.

[0020] The free access nodes may be kept in order by their index into the array.

[0021] Access nodes can be moved from one prioritization group to another by rewriting the next and / or previous references.

[0022] The access node may include an index or reference to a cell data structure that stores additional data indicative of the order, preferably a data structure separate from the tile data structure.

[0023] The system can be used to implement various types of financial functions such as matching engine books, market data feed appliances, etc.

[0024] The processing means may be implemented as embedded hardware technology such as a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), or the like.

[0025] A preferred embodiment may include a computer program product stored on a computer-readable medium. The computer program product may comprise instructions for receiving an access node data structure, with each access node referencing a cell data structure representing order data for a given instrument, side, and price. Further instructions cause the access nodes to be inserted into one or more tiles, each containing an array of access nodes for a given instrument, side, and price, metadata fields for additional order data for the given instrument, side, and price, and at least head and tail reference information for organizing the access nodes in the array into one or more prioritized groups. Further instructions cause the array of access nodes to be processed to perform market functions.

[0026] A preferred embodiment of the system may also include an electronic data processing system that performs the method for implementing the predetermined configuration described above. For example, one or more data processing means may access one or more storage means to configure one or more tile data structures. The storage means may include on-chip block random access memory (block RAM) and off-chip dynamic random access memory (DRAM) located on a semiconductor chip that includes at least one of the data processing means.

[0027] Each of the one or more tiles may include an array of access nodes indicating orders for a particular product, side, and price (ISP), as well as one or more head and / or tail references that organize the access nodes into one or more prioritized groups of active access nodes and groups of free access nodes.

[0028] At least one of the one or more data processing means is further configured to accept a request for an access node of a given ISP, read a tile of the given ISP from the DRAM into the block RAM, identify in the block RAM the requested access node within the tile of the given ISP read into the block RAM, and return from the block RAM the requested access node from the tile of the given ISP read into the block RAM.

[0029] In such a system, the one or more data processing means may be further configured to move the requested access node from the one or more prioritized collections of active access nodes to the collection of free access nodes, the movement comprising modifying reference information of at least one of the one or more head reference information and / or tail reference information in the block RAM.

[0030] The system may also associate a request for access nodes of a given ISP with a new order, where the system may identify in the block RAM the requested access nodes within the tile of the given ISP by further identifying in the block RAM an access node within a first prioritized group of the one or more prioritized groups with the one or more head references and / or tail references.

[0031] The one or more data processing means may further be configured to perform additional processing, such as accepting a second request associated with the new order requesting a second access node of the given ISP; identifying in the block RAM the requested second access node within the tile of the given ISP; and returning from the block RAM the requested second access node from the tile of the given ISP that was loaded into the block RAM, wherein the identifying further includes identifying in the block RAM a second access node within the first prioritized group by the one or more head references and / or tail references.

[0032] The one or more data processing means may also be configured to accept a second request associated with the new order requesting a second access node of the given ISP, identify the requested second access node within a tile of the given ISP in the block RAM, and return from the block RAM the requested second access node from the tile of the given ISP loaded into the block RAM, wherein the identifying further includes identifying in the block RAM a second access node within a second prioritized group by the one or more head references and / or tail references.

[0033] In some embodiments, the given ISP may include a given commodity, a given side, and a first price, and the tile of the given ISP may include a first tile, and the one or more data processing means: accept a second request associated with the new order requesting a second access node of the given ISP; read the second tile for the given commodity, the given side, and a second price from the DRAM into the block RAM; and if the first tile does not include an active access node in the one or more prioritized groups within the first tile, The processor may be configured to perform the additional processing of: identifying in the block RAM the requested second access node within the second tile; and returning from the block RAM the requested second access node from the second tile that was loaded into the block RAM; wherein the identifying further includes identifying in the block RAM a second access node within a prioritized group of the one or more prioritized groups within the second tile using one or more head references and / or tail references within the second tile.

[0034] The one or more data processing means may start loading the second tile before accepting the second request for the second access node.

[0035] In some embodiments, each access node is uniquely identified by the given ISP and an index value in the array of access nodes, in which case accepting a request requesting an access node of a given ISP further includes accepting a request for an order cancellation request requesting an access node of a given ISP and a given index value, and accepting identifying in the block RAM the requested access node within the tile of the given ISP further includes identifying in the block RAM the access node having the given index value in the array of access nodes.

[0036] Additionally, the loading of the tiles of the given ISP from the DRAM into the block RAM may be performed prior to accepting a request for an access node of the given ISP.

[0037] The features and advantages of the approach described herein will be apparent from the following text and accompanying drawings. [Brief explanation of the drawings]

[0038] [Figure 1] FIG. 1 is a high-level block diagram of a trading system. [Figure 2] FIG. 1 is a detailed diagram of a Matching Engine Book (MEB) having an Open Order Database (OODB) containing cell objects, book processing logic, interconnection interfaces, and a cache containing access nodes associated with cell objects. [Figure 3] FIG. 17 illustrates an example of an OODB 170 in which each cell object contains a global sequence number (GSEQ) and a corresponding index (IDX) of the corresponding access node data element, which points to the cell by the associated GSEQ. [Figure 4] FIG. 2 is a detailed diagram showing an example of an access node array 290 stored in a tile data structure 250 stored in a storage means. [Figure 5] FIG. 10 shows the same example tile data structure as above, and one or more linked lists of access nodes. [Figure 6] 1 is a flow diagram illustrating a method according to some embodiments for processing a request for an access node. [Figure 7] FIG. 2 is a detailed flow diagram illustrating the method. [Figure 8] FIG. 1 is a schematic diagram illustrating an embodiment of an automated trading system with a ticker plant that maintains an independent order book. [Figure 9] FIG. 1 is a schematic diagram illustrating another embodiment of an automated trading system with a ticker plant that maintains an independent order book. DETAILED DESCRIPTION OF THE INVENTION

[0039] Electronic trading systems, specifically order matching (execution) engines that execute orders to buy and sell financial instruments such as stocks, are highly latency-sensitive environments. This specification discloses electronic trading systems that can be implemented using fixed logic, such as field programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs), to accelerate order execution. Fixed logic, such as FPGAs and ASICs, typically execute faster than central processing unit (CPU)-based platforms. However, electronic trading systems must process large data sets, sometimes referred to as "order books." Order book data sets often contain highly variable numbers of buy and sell orders at each price point for each financial instrument. Therefore, order book data sets generally cannot fit into the internal memory caches of fixed logic, such as FPGAs and ASICs.

[0040] To better accommodate large, open-book data sets, external memory caches such as dynamic random access memory (DRAM) are sometimes used. However, memory accesses in FPGA designs can be costly in terms of latency, especially when large data sets necessitate the use of external DRAM. DRAM is relatively slow the first time it is accessed, but becomes efficient for sequential accesses. In FPGAs, read / write memory access operations to internal memory caches such as block random access memory (BRAM) are generally faster than read / write memory access operations to external DRAM.

[0041] To address the above challenges, embodiments of the electronic trading system disclosed herein are configured to minimize memory access latency by reducing the number of external memory accesses. For example, order data for all outstanding orders for a particular product, side, and price ("ISP") may be organized into predetermined data structures (referred to herein as "tiles") that can be fetched from an external memory cache. By loading the tiles into an internal memory cache in fixed logic such as an FPGA, access latency for order data for multiple outstanding orders for the same product, side, and price can often be minimized. That is, a single access to external memory can be performed to obtain a tile containing order data for all outstanding orders for the same product, side, and price, rather than multiple accesses to an external memory cache to obtain data for each individual order separately.

[0042] In some embodiments, an external memory cache allocates a predetermined amount of space for each tile for a given product, side, and price, regardless of the number of active orders associated with that ISP. Because each tile has its own cache space, a symbol registry that bounds a contiguous memory segment may facilitate indexing tile locations according to price.

[0043] The electronic trading system and method described herein involves several design considerations, including the following:

[0044] The tile data structure combines data indexing (in the form of a prioritized list) and payload (implemented as an array of objects called access nodes, each storing data related to a particular open order). By combining indexing and payload into a single tile, a single-access design significantly reduces overall latency.

[0045] Furthermore, this design maximizes the space efficiency of tiles by including only the most relevant order data required for matching. Specifically, this design stores data representing standardized trade events (i.e., "order data instances") in data structures called cells. Each cell contains dynamic and static data fields. Dynamic data fields are fields within a cell that are required by the Matching Engine Book (MEB) processor to perform its processing. Dynamic data within a cell may include fields such as quantity, order type, and minimum trade increment. Static data are fields not used by the MEB to process trades but are required by other system components, such as free-form fields defined by clients. Extracting the dynamic / relevant data from cells and creating access nodes with only dynamic data fields maximizes the number of trade events per byte stored within a tile.

[0046] FIG. 1 illustrates an example system 100 that achieves these objectives. As shown, system 100 may include one or more client gateways 110-1, 110-2, ..., 110-M (collectively referred to as client gateways 110), a sequencer 130, one or more data feed provisioning systems (i.e., ticker plants) 140-1, 140-2, ..., 140-P (collectively ticker plants 14), and one or more matching engine book (MEB) processors 150-1, 150-2, ..., 150-N (collectively MEBs 150). Trading clients 120 (i.e., "market participants") exchange trade messages (i.e., "trade events") with system 100 via client gateways 110. Ticker plants 140 provide data feeds regarding financial securities trading to data feed subscribers 142. In a preferred embodiment, system 100 provides a novel multimodal cache structure 160 for high performance hardware-based processors such as hardware-based matching engine 150 and hardware-based ticker plant 140 that provide data feed services. Specifically, system 100 uses a highly efficient structure for cache 160 that allows for high throughput and low latency for processing orders stored in an open order database (OODB) 170.

[0047] 1 embodiment, one or more Matching Engine Book (MEB) processors 150 are central to the matching engine embodiment of system 100 and accept trade messages from market participants (clients 120) that indicate orders to buy and sell financial instruments. The one or more MEBs 150 send and receive such messages as standardized trade events to and from other ME components connected via one or more interconnections 165, such as a system area network.

[0048] A trade message may consist of an order requesting the purchase or sale of a financial instrument, a cancellation to remove it, or a replacement to modify it. Orders to buy or sell corresponding instruments that cannot be matched with a counterparty may be considered "pending orders" stored in the MEB 150's internal data store (also referred to as liquidity injections). Alternatively, if an order is matched with a counterparty that has already injected liquidity on the other side (e.g., a buyer and seller are matched), both orders are executed, resulting in a trade / contract.

[0049] Such trading events, such as queued additions and execution deletions, are reported through the interconnection means of the system via order confirmations (whether or not part of an order becomes queued) and trade reports (when matched or executed). When an order is executed, two types of outgoing messages may be generated: an acknowledgement and an execution. Order data, including transaction data for queued orders and / or executions, may also be reported to other systems by a data feed service, such as Ticker Plant 140.

[0050] In the following discussion, please also refer to Figures 2, 3, and 4. As shown in these figures, in a preferred embodiment, a trade message may be represented as an instance of a standardized data structure called cells 210-1, 210-2, ..., 210-D (collectively / inclusively referred to as cells 210). Cells 210 contain information required for a financial transaction (a single "order data instance") processed by system 100. Preferably, the data structure used in cells 210 is common to all components of system 100. The data within cells 210 may be categorized into two subsets: i) dynamic information 320 and ii) static information 310. Static information 310 is information required by other components (other than the MEB) but not required by MEB 150 to match transactions (e.g., a client-defined order token, etc.).

[0051] Dynamic data 320 refers to fields within a cell 210 that are required by book processing logic 220 to match a trade. Examples of dynamic fields 320 include items such as quantity, order type (order type, control), and other items used for self-match prevention, such as account ID. Preferably, a cell's dynamic data 320 is organized into a separate structure called an access node 260.

[0052] When the MEB 150 receives an order that is not fully matched with a counterparty (for example, because the order is only partially matched), the remaining order becomes queued. The data representing such queued orders is stored in a distributed manner: the cell's comprehensive (and larger) static data is stored in the MEB data store, also known as the Open Order Database (OODB 170). The dynamic data, the so-called Access Node 260, is replicated from the cell 210 and stored in a caching hierarchy called the Access Node Cache 160 (or simply "Cache" 160).

[0053] System 100 further organizes access nodes 260 into structures or containers called tiles 250. These tiles 250 are preferably arranged so that there is only one tile 250 per financial instrument (e.g., stock symbol) per side (i.e., buy or sell) per price (referred to herein as per instrument / side / price, or "ISP" for short). Thus, each tile 250 contains an array 290 of access nodes 260, each representing one of the outstanding orders for that ISP. The intent is that a single tile 250 will contain all dynamic order data needed by the book processing logic to execute trades for all access nodes 260, and therefore for all outstanding orders for a particular ISP.

[0054] The access nodes 260 within each tile 250 are arranged into one or more priority linked lists based on the priority of the underlying orders. In a preferred embodiment, the priority lists determine the order in which matching orders are paired with the opposing parties' order execution requests. Tiles 250 and their corresponding priority lists 350 are described in more detail below in connection with Figures 4 and 5.

[0055] FIG. 2 is a detailed diagram of example components of a Matching Engine Book (MEB) 150, including an Interconnect Interface 165, a Book Processing Logic (BPL) 220, a Cache Manager 225, an Open Order Database (OODB) 170, and an Access Node Cache 160.

[0056] Interconnect interface 165 receives cells 210 from other components of system 100, such as sequencer 130, and sends cells 210 to BPL 220 for further processing. The interconnect interface may also receive outgoing messages from MEB 150 (e.g., order confirmations, rejections, fills, etc.) from BPL 220. The outgoing messages may then be delivered in the form of cells via system interconnect 165 to other components in system 100.

[0057] The BPL 220 interfaces with the OODB 170 to access, such as input (write), delete, and retrieve (read) cells 210 that it receives and that correspond to pending orders. The OODB 170 may store cells 210 in an external data store (as described in connection with FIG. 3).

[0058] BPL 220 contains processing logic for performing order processing, including but not limited to, filling, canceling, etc. BPL 220 uses cache 160 to coordinate access to the pending order book.

[0059] The cache 160 stores dynamic trade data from cells 210 in smaller structures, namely, access nodes 260, which are then organized and cached within tiles 250 for the purposes of indexing and prioritizing open orders corresponding to cells 210 within the OODB 170.

[0060] Cache manager 225 provides an interface between BPL 220 and cache manager 225. Cache manager 225 allows BPL 220 to perform operations using data in access node 260 without needing to understand the structure of tile 250 or the contents of cache 160. For example, in some embodiments, cache manager 225 may include an interface ("get_next_an") that, when BPL 220 provides cache manager 225 with an instrument, symbol, and price (ISP), can return from cache 160 the "next access node" for that ISP that can be used to match a paired order for execution.

[0061] Additionally, in some embodiments, cache manager 225 may include an interface ("get_an") that can provide BPL 220 with the ISP tuple and identifier (i.e., "access node index," described below) for a particular access node 260. Cache manager 225 then retrieves the particular access node 260 from cache 160. This latter "get_an" interface may be useful in situations such as revocation requests where a specific, known access node 260 is to be fetched.

[0062] The "get_next_an" and "get_an" operations performed by the cache manager 225 are described in more detail below.

[0063] 2 is described in terms of MEB system 150, it will be appreciated that in some embodiments, many of the same components may also be present in a ticker plant system. For example, like the MEB system, a ticker plant may include interconnection interfaces for transmitting and / or receiving cells, a data store such as an OODB, and a caching system such as cache 160 and cache manager 225 for efficiently accessing trading data, including data regarding pending orders.

[0064] In some embodiments, one or more components of ticker plant 140 or MEB 150 (e.g., BPL 220, OODB 170, cache manager 225, etc.) may be implemented at least in part by fixed logic, such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other custom logic. Note that embodiments described herein as being implemented by an FPGA may also be implemented by other fixed digital logic, such as an ASIC or custom logic. In yet another embodiment, the custom logic may be executed at high speed using a programmable high performance processor, such as a digital signal processor (DSP), reduced instruction set computing (RISC), or advanced RISC machine (ARM).

[0065] In embodiments in which cache manager 225 is implemented in fixed logic such as an FPGA, a small but relatively fast cache memory implemented in block memory internal to the FPGA (herein designated “Block RAM L0 Cache” 230) may be included as cache 160, along with one or more larger but relatively slower external memories (depicted in FIG. 2 as a single external memory for simplicity). Such external memories may be implemented using synchronous dynamic random access memory (SDRAM) technology or some other type of dynamic RAM (labeled “DRAM” 240 in FIG. 2).

[0066] It should be noted that in some embodiments, memory cache 160 may be implemented as a single physical DRAM semiconductor chip or as two or more DRAM chips.

[0067] 2 further illustrates that this external memory stores multiple tiles 250-1, 250-2, ..., 250-T (collectively tiles 250), each associated with a particular ISP tuple. Cache manager 225 can efficiently fetch tiles from slower DRAM 240 into block RAM L0 cache 230 when BPL 220 wants to perform access node matching for that tile 250.

[0068] The FPGA's block RAM 230 may also store a symbol registry 270 for fast lookup that allows the cache manager 225 to quickly identify the memory locations of tiles 250 according to their corresponding ISPs, for example, in embodiments where the tiles are stored sequentially in order based on incremental price increments (e.g., one tile for each 0.01 USD increment in price), particularly in embodiments where the tiles 250 are all the same size (e.g., each tile may hold 256, 512, 1024, etc. access nodes 260).

[0069] In some embodiments, each tile 250 contains all the data BPL 220 needs to perform order matching, including dynamic data for all orders at a given symbol, side, and price (as described below), as well as metadata statistics, order indexing, and prioritization information for those orders. By pre-loading all such relevant data within a tile 250 into a cache in on-chip block RAM 230, BPL 220 is able to perform order matching extremely quickly.

[0070] It should be noted that the above description applies regardless of the various implementations of system 100, such as matching engine 150, market data feeds implemented by ticker plant 140, and other sophisticated financial system applications.

[0071] (MEB Data Model - Cells, Access Nodes and Tiles)

[0072] The MEB utilizes the data model shown in Figures 2, 3, 4 and 5, which includes the aforementioned cells 210, access nodes 260 and tiles 250. The data model may optimize the following design goals:

[0073] Latency budget - minimizing the total processing time of the MEB;

[0074] One or minimal memory access per MEB operation; and

[0075] Ability to resolve exceptional situations, such as excessive order quantities, while maintaining other objectives.

[0076] FIG. 4 illustrates an example tile 250, including a tile header 270 (described in more detail below) and a tile body 280. The tile body 280 includes an access node array 290, which is configured with a set of access nodes 260 and stored in a storage device such as block RAM 230 or DRAM 240. Each access node 260 has a predetermined size. The access nodes 260 are stored contiguously within the storage device. Thus, for example, a specific access node within the access node array 290 can be identified by an index number (e.g., by multiplying the index number by the size of each access node and adding the result to the address of the first access node 260). In this example, the access node array 290 includes a total of 256 access nodes. However, other sizes are possible for the access nodes 260 and the access node array 290. Examples of access nodes 260, particularly the fact that the access nodes 260 can be accessed via one or more linked lists, are described in more detail elsewhere herein.

[0077] 5 is a detailed diagram of an example of a tile 250. The tile 250 includes multiple active access nodes 260, each corresponding to a cell 210 stored in the OODB 170 (labeled "cell data store" in FIG. 3).

[0078] A cell 210 is a fixed-size data structure that represents a standardized trade event. The structure of a cell 210 is common to many components in the ME system, such as the MEB 150. Each cell 210 has a trading day-specific global identifier, or global sequence number (GSEQ). This GSEQ may be a unique identifier, such as an ingress time-based value, that may be inserted into the cell 210 by the sequencer 130 before the cell 210 arrives at the MEB 150. A cell 210 representing a pending order may be stored in a data store, such as the MEB's OODB 170, and may be identified by its GSEQ.

[0079] As mentioned briefly above, the data in cell 210 can be divided into two subsets: i) dynamic information 320 and ii) static information 310. Dynamic data 320 refers to the subset of fields in cell 210 that are necessary for the MEB's book processing logic to be able to perform trade matching processing on an order-by-order basis. Static data 310 can refer to any other data related to the transaction, such as client-provided data, such as a client order ID.

[0080] In the embodiment of FIG. 3, dynamic data in cells 210 may be replicated in access node (AN) structures stored in access node cache 160. Access nodes 260 are represented in FIGS. 3 and 5 as hexagons. The access node 260 structure allows for more efficient trade matching. In some embodiments, static data may be much larger than dynamic data. Thus, replicating dynamic data in cache 160 maximizes the speed at which data related to matching can be retrieved using access nodes 260. Additionally, storing access nodes corresponding to a given ISP within a single tile allows for more efficient access when processing multiple trading events. Once a trade / contract is executed, the dynamic data (in cache 160) may be recombined with the static data (i.e., data maintained in the corresponding cell 210) to complete the contract transaction.

[0081] Conceptually, the dynamic data stored in an access node 260 can be considered to be part of the data in its corresponding cell 210. In other words, an access node is a "stripe" of storage that contains the dynamic data 320 in the OODB. As shown in Figures 4 and 5, an access node 260 can include multiple fields, such as a mode field, a previous field, and a next field, as well as predefined data from the corresponding cell, such as an account field, a minimum quantity field, a quantity field, and a global sequence identifier (GSEQ).

[0082] That is, in some embodiments (such as the embodiment of FIG. 3), dynamic data 320 may not all be stored per access node 260, but rather some of the dynamic data 320 may be available from cache 160. For example, because the symbol, side, and price are common to all access nodes stored within a given tile, the symbol and / or side and / or price may be stored elsewhere in the tile 250, such as in the tile header 270, rather than being stored on each access node 260 itself. This approach may further optimize use of cache 160.

[0083] 3, each pending order in the MEB system is represented by a unique access node 260 in a corresponding tile 250 and is represented and stored in the OODB as a unique cell 210. These two representations of the same order are linked so that one can be identified from the other using a global sequence (GSEQ) identifier.

[0084] The table below lists some example fields in a cell 210. The table includes a description of the fields in a cell 210, whether they may be classified as static or dynamic data, and, if dynamic, where the data may be stored (e.g., in an access node 260 or in a tile header 270). Note that additional or different fields may be included. Also, in some embodiments, which fields are dynamic and which are static may differ from the example, and / or the dynamic data may be stored elsewhere in the cache 160.

[0085] [Table 1]

[0086] 3, each access node 260 further includes fields for previous and next pointers that define which members of its priority list are within its corresponding tile. Thus, an access node 260 can be of the following structure:

[0087] Struct access_node { UINT16 prev; UNIT16 next; UNIT16 account; UINT16 minqty; UNIT32 qty; UINT48 gseq; }

[0088] As previously mentioned, each cell 210 may be identified by a globally specific transaction identifier (GSEQ), which may also be included in the access node 260 (e.g., as the "gseq" field above) and serves as a reference to that particular cell 210.

[0089] Similarly, each access node 260 may be identified by an index number ("access node index" or "IDX")). The access node index 265 is an identifier for the access node. Each access node has a fixed size. Thus, the access node index 265 represents an index or offset within the tile structure, reflecting the location of the access node 260 within the memory allocated to that tile. In some embodiments, the access node index 265 may be independent of the physical memory location of the tile containing the corresponding access node 260. In such embodiments, every access node 260 may be uniquely identified throughout the MEB by the combination of its ISP and access node index 265.

[0090] The access node index 265 may be included in the cell 210 object stored in the OODB as additional reference information that is assigned to the cell when it is cached.

[0091] In other words, these two types of reference information (i.e., the cell's GSEQ stored in the corresponding access node 260 and the access node index 265 stored in the corresponding cell 210) can form a "double link" between the access node 260 and the corresponding cell 210 in the OODB.

[0092] (Summary of the relationship between cells 210 and access nodes 260)

[0093] An unfilled queued order may be distributed across both access nodes 260 and cells 210. An unfilled queued order may have only one cell 210 in the OODB and only one corresponding access node 260 stored in the cache 160. Access nodes 260 and cells 210 may be linked to each other. A cell 210 uniquely references an access node 260 by a tuple of its ISP and access node index 265. An access node references its constituent cells 210 by a globally unique GSEQ.

[0094] Access node 260 may be the single source of truth for the dynamic state of an order. Pending order fields (e.g., price, quantity) required to process an unfilled order are sourced from access node 260 rather than from cell 210, and changes are stored within access node 260. For example, as a pending order is filled by multiple paired orders, the changing execution quantity is stored in access node 260 rather than being updated within cell 210.

[0095] Cell 210 can be the only source of static state (order metadata). The static metadata is used only when constructing outgoing messages such as fills, confirmations, etc. The only dynamic data stored in cell 210 can be the access node 260 index (IDX value), which is used to serve as a reference to the access node 260. That is, cell 210 only needs to be written to the OODB when it is created, and can be deleted (released) later once the order is processed.

[0096] As mentioned above, access nodes may be stored in cache 160 in data structures called tiles. An example of a tile 250 is shown in Figures 4 and 5. A tile 250 is a multimodal cache data structure that includes all active access nodes 260 with the same product-side-price (ISP) tuple, metadata statistics for the access node, one or more prioritized lists 350 for the access node, and a free list 360 of unused access nodes. There is exactly one active tile for every ISP tuple with zero or more open orders. Tiles 250 are designed to optimize space-time utilization of cache 160 memory.

[0097] In one embodiment, a tile 250 may be represented by the following structure:

[0098] Struct packed tile / / Tile header: INT16 Type; / / MODE_IMMED or MODE_EXTEND INT16 open_shares; / / Total number of open shares across all tiles INT16 open_orders; / / Total number of open orders for this tile INT16 PriList0[2]; / / Top-bottom of priority list 0 (P0) INT16 PriList1[2]; / / Top-bottom of priority list 1 (P1) INT16 PriList2[2]; / / Priority List 2 (P2) start-end INT16 FreeList[2]; / / Free list start-end UINT16 Instrument; / / A globally unique symbol (e.g., stock symbol) per matching engine book processor for the instrument being traded UINT48 Price; / / Limit price of all orders in "this" tile INT16 Side; / / Side (Buy / Sell) of all orders in this tile ENUM TileCapacity; / / Tile body: Union { an_array

[0256] , / / Exists for MODE_IMMED type and changes depending on the tile size Uint32 indirect_address. / / Exists for MODE_EXTEND type and is a reference to a larger tile } }

[0099] In the exemplary embodiment of Figures 4 and 5, the tile header 270 includes metadata fields such as the total number of units in the tile and the number of open orders in the tile, as well as four bidirectional lists: one free list and three prioritized bidirectional lists 350 (P0, P1, and P2). The tile header 270 may further include items such as type, list head 370 and list tail 380 identifiers for the prioritized list and free list, and the corresponding symbol, price, and side of the tile. (Note that for simplicity, Figure 5 does not include detailed descriptions of the fields of the tile header 270 because such details are provided in Figure 4 and the preceding discussion. However, for the embodiment of Figures 4 and 5, it should be understood that the tile header 270 of Figure 5 may include the same fields as the tile header 270 shown in Figure 4.)

[0100] The tile header 270 is followed by a tile body 280 that contains an array 290 of access node 260 objects (i.e., "an_array" above). In the embodiment shown in Figures 4 and 5, the tile 250 may store up to a predetermined upper limit of the number of access nodes 260 in the array 290 (e.g., 256). However, it should be noted that the tile 250 may also store some other predetermined number of access nodes (e.g., 128, 512, 1024, etc.).

[0101] Read access times when fetching data from SDRAM tend to be relatively slow on the first access and more efficient for sequential accesses. Therefore, when the underlying memory technology is some kind of dynamic memory, such as SDRAM, storing all access nodes for a given product, side, and price within the same tile 250 allows the entire tile to be fetched in a single sequential access, providing optimal ability to quickly and efficiently fetch many related orders together.

[0102] In some embodiments, the capacity of a tile (i.e., "an_array," i.e., the upper limit number of access nodes in the tile's access node array 290) may be a fixed value, but different tiles 250 may have different fixed capacities (e.g., 256, 512, 1024, etc. access nodes 260). That is, if the number of active pending orders for a given ISP exceeds the capacity of the corresponding tile, the access nodes may be moved to a tile with a larger capacity. Optionally, when an ISP's access nodes exceed the capacity of a tile and need to be moved to a larger tile, the original tile may contain a memory address of the larger tile elsewhere in external memory (i.e., the tile's "indirect_address" field in this example), effectively acting as a pointer to the larger tile. This indirect addressing mode may be indicated by a Type field in the tile header 270. In some embodiments, the "indirect address" field may also be stored as a field within the tile body 280.

[0103] As mentioned above, each access node 260 in a tile 250 may be identified by its access node index 265. In the embodiment of FIG. 3, the access node index 265 may correspond to the index (subscript) of the access node 260 within the tile's access node array 290. Other indexing schemes may be employed. For example, in other embodiments, the access node index 265 may correspond to the byte offset of the access node 260 within the access node array 290 or the byte offset of the access node 260 within the tile 250. That is, in such embodiments, the access node index 265 is local to or relative to a particular tile.

[0104] References (also called "pointers") to access nodes 260 within a tile 250, such as the priority list 350 and free list 360, which are doubly linked lists within that tile, may also be made using access node indexes 265. As a result, the references may also be local to the tile or relative to the tile.

[0105] The access node 260 representing the corresponding cell 210 may be added to one of the priority lists in the tile 250. Preferably, access nodes 260 in higher priority lists, such as list 350-0, have their orders executed before pending orders of access nodes 260 in lower priority lists, such as list 350-1. Within each priority list, access nodes 260 at or near the top of the list 350 have their orders executed before orders of access nodes 260 at or near the bottom of the list. In the illustrated embodiment, the priority lists 350 are implemented as linked lists. That is, an access node 260 may have a pointer (i.e., reference information) that internally links the access node to one of the priority lists 350. For example, an access node 260 may have one pointer N (e.g., a next pointer) to the next access node in list 350-1 and another pointer P to the previous access node in list 350-1, as shown.

[0106] The priority list 350 of a tile 250 may be organized based on one or more attributes of the access node 260 to prioritize trade execution based on order type. For example, "visible" pending orders are typically filled before "non-visible" pending orders. In one embodiment, to support arbitrary prioritization functionality, there are one or more additional priority lists, such as a first priority list 350-1 for visible orders, another priority list 350-2 for non-visible orders, and priority list 350-3. When large orders are being filled, orders in higher priority lists (e.g., visible orders) may be executed before orders in the next higher priority list. Within a given priority list, orders may be arranged and filled in various ways. For example, orders may be ordered according to first-in-first-out (FIFO) order to prioritize time arrival. Alternatively, orders in the priority lists may be ordered according to a sequence, such as a GSEQ identifier, stored within each access node 260. In other embodiments, priorities may be determined by order size (e.g., number of trading units, total order amount, etc.), by the entity associated with the order, or by some other method.

[0107] In some embodiments, the priority of an order may be a field defined in cell 210, which may be assigned by one or more other components of system 100, such as gateway 110. Additionally or alternatively, the priority may be determined by MEB 150 depending on the nature of the order.

[0108] The free list 360 of a tile 250 may be a linked list of unused or "empty" access node 260 data structures in the access node array 290. Initially, the data in the access nodes 260 of this free list 360 is empty except for pointers. When a new access node 260 needs to be associated with a new pending order cell 210, the next free access node 260 is moved into one of the active priority lists 350. This "moving" may not require rewriting, copying, or moving data within the access node 260, but may simply require adjusting and / or rewriting the references (e.g., next and / or previous references) for that access node 260 in the tile's linked list.

[0109] Organizing the access nodes 260 into one or more prioritized lists 350 and / or free lists 360 contained in a tile 250, along with the access node array 290, allows all data relevant to the match to be quickly accessed for the next trade of an open order from the same ISP when its corresponding tile is loaded into the on-chip FPGA block RAM 230. As a result, no additional accesses to external memory are required when processing a set of open orders from the same ISP, because the relevant information needed to execute the open orders has essentially already been pre-fetched.

[0110] While the embodiments of Figures 3 and 5 above have been described as implementing priority list 350 and free list 360 as linked lists, other suitable prioritized collections of access nodes may alternatively or additionally be used to organize the access nodes within a tile, such as other types of list structures, tree structures, array structures, or graph data structures. For example, a singly linked list may be employed, with each access node containing a reference to the next access node in the list but not the previous access node in the list. In embodiments where a tile includes multiple prioritized collections, different prioritized collections within the tile may be implemented with different data structures, for example, depending on the expected access patterns of each prioritized collection.

[0111] Additionally, one or more head references and / or tail references associated with a prioritized collection (or, in the embodiments of FIGS. 3, 4, and 5, a linked list) may generally be treated as one or more insertion position references and / or removal position references. In some embodiments, it may be desirable to insert an access node into a particular position within the prioritized collection using an insertion position reference and / or to remove an access node from the prioritized collection 350 at another particular position using a removal position reference. In the embodiments of FIGS. 3, 4, and 5, an access node may be removed from the prioritized list and / or free list using the head reference and inserted into the priority list and / or free list using the tail reference. However, in alternative embodiments, the embodiment may be implemented with the opposite approach (i.e., inserting an access node using the head reference and removing an access node using the tail reference). In yet another alternative embodiment, at least in some scenarios, the removal and / or insertion of an access node may occur at another position within the prioritized collection, such as at the midpoint of a linked list or at some intermediate position within the prioritized collection.

[0112] (Cache manager interface 225 between book processing logic 220 and access node cache 160)

[0113] 2, a cache manager 225 provides an interface between the book processing logic (BPL 220) and the cache 160. The cache manager 225 may maintain the access nodes 260 in memory and performs the following exemplary operations: [AN]get_next_an(ISP)—A procedure that returns the next access node 260 in the highest priority list; [AN]get_an(ISP,AN-Idx)—A process that returns the access node 260 of the specified access node index 265.

[0114] Each of these operations allows BPL 220 to request and receive from cache 160 an access node 260 for a given ISP. In some embodiments, cache manager 225 may receive each of these operations and quickly identify the external memory base address of a tile 250 based on attributes such as symbol, side, and price, e.g., using symbol registry 270. Note that, in general, the addresses used by the processing means for these operations may include off-chip DRAM addresses, on-chip block RAM, or both, depending on the location of the access node. Once the base address of a tile 250 in the appropriate memory is determined, the tile 250 corresponding to the given ISP may be fetched by cache manager 225 from the appropriate memory (e.g., external memory such as DRAM 240) and, in some embodiments, stored in a relatively fast memory such as on-board FPGA block RAM L0 cache 230.

[0115] (Change tile position)

[0116] As is clear from the above description of tile 250, all of its elements, including access node array 290, self-contained linked lists 350 and 360, and access node index 265 relative to the tile, enable tile 250 to be "memory location independent" and therefore relocatable. That is, even if tile 250 is moved to another memory location (e.g., from external DRAM 240 to FPGA block RAM 230 or elsewhere within DRAM 240), all of the data for tile 250 (including access nodes) and its linked list can be accessed and traversed without requiring any changes to tile 250. Therefore, in some embodiments, such as those described above, matching-related processing can be performed while accessing tile 250 in fast FPGA block RAM 230.

[0117] The get_next_an and get_an operations performed by the cache manager 225 in some embodiments are described in more detail below.

[0118] (get_next_an)

[0119] After fetching the relevant tile 250 corresponding to a given ISP into FPGA block RAM 230, cache manager 225 may return the next access node 260 in that tile 250 in appropriate priority order to BPL 220. That is, in some embodiments, cache manager 225 may return the access node 260 at the top of the most recent non-empty, highest priority list in the corresponding tile 250.

[0120] Thus, when processing large executions where a waiting order with a relatively small quantity is matched multiple times against a counterpart order with a large quantity, BPL 220 may repeatedly call get_next_an on the same ISP. In some embodiments, successive calls to get_next_an on the same ISP traverse the priority list 350 in FIFO order, moving on to the next highest priority list 350 when all Access Nodes from the current priority list have been processed. All Access Nodes for a given ISP are stored in fast FPGA block RAM, allowing get_next_an requests to be processed as quickly as possible without having to fetch data from external DRAM.

[0121] In some embodiments, when all access nodes 260 for a particular ISP have been processed and get_next_an is called for that same ISP, the cache manager 225 may move to the next price level (i.e., fetch the next tile 250, which is the tile with the same symbol, same side, and next price, from DRAM into FPGA block RAM) and traverse the priority list in the new tile 250 as described above. Thus, thanks to the tile 250 structure, the BPL 220 does not need to be aware of or implement logic to determine the "next order" in the order sequence. The access nodes 260 are already organized according to the desired execution priority in one or more linked lists.

[0122] (get_an)

[0123] Unlike get_next_an, which traverses the priority list to return access nodes 260 from a given ISP's fetched tile 250, get_an (also from a given ISP's fetched tile 250) returns a specific access node 260 for a given access node index 265. That is, rather than traversing the priority list, cache manager 225 may index access node array 290 to return a specific access node 260 for a given access node index 265. This scenario is most likely to be encountered when BPL 220 processes a cancel request for an existing waiting order, since such a waiting order may already have an associated access node index 265 stored in the corresponding cell 210.

[0124] (Optimizations such as pre-fetching)

[0125] In some embodiments, one or more optimizations may be implemented, as detailed below.

[0126] (pre-fetching for get_next_an optimization)

[0127] In some embodiments, get_next_an may be expected to "automatically" traverse multiple price levels. That is, cache manager 225 may optionally perform some type of pre-fetching of tiles 250. In such an embodiment, when get_next_an is called for a requested ISP, cache manager 225 may pre-fetch one or more tiles 250 with a finite number of orders for one or more next price levels into FPGA block RAM, even while access nodes 260 in the first tile 250 of the requested ISP are still being processed by BPL 220. In this way, block RAM 230 can ensure that the next best priced access node 260 is already available before it is requested by BPL 220.

[0128] (get_next_an optimization)

[0129] When cache manager 225 receives a get_next_an request from BPL 220, it may provide the next access node 260 to BPL 220 before the tile 250 containing that access node 260 has been completely loaded into FPGA block RAM 230. When processing a get_next_an request from BPL 220, cache manager 225 may first need to load the tile 250 corresponding to the given ISP into FPGA block RAM 230. However, it should be clear that the access node index 265 of the access node 260 at the top of the highest priority list is already known when tile header 270 is loaded into FPGA block RAM 230. Therefore, cache manager 225 may provide the appropriate access node 260 to BPL 220 when the access node 260 with that access node index 265 in access node array 290 is loaded into FPGA block RAM 230, even before the entire tile 250 has been loaded.

[0130] (Free list optimization)

[0131] Some embodiments may optimize the free list 360 by taking advantage of the typical situation (described above in connection with optimizing get_next_an) in which the access nodes in the access node array 290 of a tile 250 are sequentially loaded into FPGA block RAM 230. Like the access nodes in the priority list 350, the access nodes in the free list 360 may be accessed by index into the access node array. In such embodiments, it may be desirable to use access nodes 260 with lower access node indexes 265. That is, when an access node 260 is removed from a priority list 350 to a free list 360, the access node 260 may not be pushed (added) to the back of the free list 360. Rather, in some embodiments, the access node 260 may be pushed onto the free list 360 such that the access node 260 with the lower access node index 265 is popped (removed) from the free list 360 first, regardless of release (arrival) order. This may increase the likelihood that the requested access node 260 will have a low access node index 265 value and thus be available early in FPGA block RAM 230. For example, in some embodiments, access nodes 260 may be added to a free list 360 ordered by access node index 265 value. Such optimization may be implemented using, for example, a bit mask, bit field, bit vector, memory lookup table, etc., that has a bit for each access node 260 in tile 250 and sets the bit to true when the corresponding access node index 265 is freed.

[0132] In another embodiment, when an access node 260 is released from priority list 350, cache manager 225 may compare the value of access node index 265 (in access node array 290) of that access node 260 to a threshold (which may be predetermined, configurable, or dynamically determined based on the characteristics of the system). In such an embodiment, if the value of access node index 265 of the released access node 260 is less than or equal to the threshold, the access node 260 may be pushed to the top of free list 360. Conversely, if the value of access node index 265 is greater than the threshold, the access node 260 may be pushed to the bottom of free list 360. In such an embodiment, when popping a new access node 260 from the top of free list 350, priority may tend to be given to access nodes 260 with lower access node 265 values ​​over access nodes 260 with higher access node 265 values.

[0133] In some embodiments, as an additional optimization, the cache manager 225 may periodically re-index the free lists 360 of the access nodes 260 within a tile 250 (e.g., as a background process) to ensure that the values ​​of their access node indexes 265 remain in numerical order as closely as possible.

[0134] (get_an optimization)

[0135] It may also be possible for BPL 220 to begin processing an access node 260 before the entire corresponding tile 250 has been loaded into FPGA block RAM 230. This may be advantageous when BPL 220 issues a get_an operation to request an access node 260 at a particular access node index 265. In such a scenario, cache manager 225 may determine the appropriate offset within tile 250 where the access node 260 at the requested access node index 265 would be located in the tile's access node array 290, and begin reading the tile at that offset, thereby quickly returning the requested access node 260 to BPL 220 before the entire tile has been loaded into FPGA block RAM 230. In other words, at least one access node may be accessible to BPL 220 for processing before the entire tile has been loaded into FPGA block RAM 230.

[0136] (How to process requests for access nodes)

[0137] 6 and 7 are flow diagrams illustrating a method 500 for processing requests for access nodes in some embodiments of cache manager 225. Method 500 may be performed by cache manager 225 described above in connection with FIGS.

[0138] At block 510, the cache manager 225 receives a request for an access node 260 (AN) for a given product, side, and price (ISP). This request may be from, but is not limited to, the book processing logic (BPL) 220, the ticker plant 140, etc., and may be received via an interface. For example, the request may be via the get_an interface, get_next_an interface, etc., as described above.

[0139] At block 520, the cache manager 225 determines whether the current tile 250 for the current ISP (i.e., the given product, the given side, and the current price) has been pre-fetched and loaded into FPGA block RAM 230. If it is determined that the current tile 250 has not been pre-fetched into FPGA block RAM 230, the tile 250 for the current ISP is loaded from DRAM 240 into on-board FPGA block RAM 230. In some embodiments, the cache manager 225 may track the “current price” for the given product and the given side that may be closest to the given price and that has an active open order (i.e., an active access node stored in cache 160). In some embodiments, the “current tile” may correspond to the tile for the given product, the given side, and the current price. For example, if an active access node at the given price in the request does not exist in cache 160, the current price may differ from the given price.

[0140] As discussed in connection with pre-fetch optimization, in some embodiments, tiles of the current ISP may typically already be loaded into FPGA block RAM 230 of cache 160 before a request for an AN of the current ISP is received.

[0141] In some embodiments, block 530 and block 550 (described in more detail below) may then be performed in parallel.

[0142] In some embodiments, at block 530, the cache manager 225 determines whether the tile 250 for the next ISP (i.e., the given product, given side, and next-closest price to the current price) has already been loaded into FPGA block RAM 230. If it is determined that the tile 250 for the next ISP has not yet been loaded into block RAM, the tile 250 for the next ISP may be pre-fetched from DRAM 240 into FPGA block RAM 230. In some embodiments, the cache manager 225 may track (e.g., using a bit field, a memory lookup table, etc.) which tile 250 contains an active access node 260, such that the next-closest price may be the price that is next-closest to the current price and contains an active access node 260. Pre-fetching the next tile 250 in this manner ensures that the next-closest priced tile is already in FPGA block RAM 230 before that tile 250 may be needed to service any request requiring an access node.

[0143] In block 550 (which may be performed in parallel with the processing of block 530 in some embodiments), the cache manager 225 identifies the requested access node 260 in FPGA block RAM 230 within the current tile 250 already loaded into FPGA block RAM 230. This processing of block 550 may vary depending on the nature of the request and the specific contents of the current tile. Figure 7 illustrates the processing of block 550 in some embodiments in more detail.

[0144] At block 560, the cache manager 225 returns the requested access node 260 from the current ISP's tile 250 from FPGA block RAM 230. This process involves copying the access node's data contents from FPGA block RAM 230 to memory accessible to the component that made the request (e.g., BPL 220, ticket plant 140, etc.).

[0145] At block 570, the cache manager 225 frees up the requested access node 260 in the current tile 250, thereby making the access node's memory available to other orders. In some embodiments, this may involve moving the requested access node 260 from the prioritized collection of access nodes in the tile 250 (e.g., one of the prioritized lists 350) to the collection of free access nodes for the tile (e.g., the free list 360) by modifying in FPGA block RAM 230 one or more of the head and tail references in the current tile that were loaded into FPGA block RAM 230. For example, if the process desires to remove an access node 260 from the head of priority list 350 in tile 250 and place it at the tail of the free list for that tile, the process may involve modifying the value of that priority list's head reference 370 in FPGA block RAM 230 to set it to the value of another access node index in the current tile 250, and modifying the value of free list's tail reference 380 in FPGA block RAM 230 to set it to the value of the access node index of the access node to be returned. In some embodiments, the process of block 570 may be performed before the process of block 560.

[0146] 7 illustrates in detail the operation of block 550 of method 500 of FIG. 6, i.e., locating the requested access node 260 within the current tile 250. The cache manager 225 may locate the requested access node 260 in a variety of ways based on the nature of the request. At block 551, the method determines whether the request provides an access node index IDX, such as a request that may be made using the "get_an" interface described above. An access node index may typically be provided in a request for an access node if the requester already knows the specific access node, such as when part of a request to cancel an existing pending order.

[0147] If an access node index IDX is provided in the request, the method proceeds to block 555. At block 555, the cache manager 225 identifies an access node 260 in the access node array of the current tile 250 loaded into block RAM based on the access node index (IDX). The access node index IDX may be used to calculate the offset of the requested access node 260 in the access node array 290.

[0148] Conversely, an access node request may not provide an access node index, such as when using the "get_next_an" interface described above. Such access node requests are typically issued as part of the process of matching or filling a new counterpart order, and the cache manager 225 may be required to return the next access node 260 for a given ISP. In such a scenario, the cache manager 225 may proceed to block 552 and determine whether the current tile 250 contains an active access node 260, i.e., an access node corresponding to the pending, unfilled order. In the course of matching or filling a large counterpart order (which may involve multiple partial matches with existing, pending orders), the "get_next_an" interface may be repeatedly invoked with the same ISP, in which case the cache manager 225 may have already returned all active access nodes 260 from the current tile 250 to the requestor (in previous requests). In some embodiments, determining whether a tile contains an active access node 260 may involve checking the values ​​of one or more fields in the tile header 310, such as the number of open orders in the tile 250 or the quantity of open units in the tile 250.

[0149] If it is determined that the current tile 250 does not contain an active access node 260, then the cache manager 225 updates the current price at block 553. In some embodiments, this may involve updating the current price to the next closest price whose corresponding tile contains an active access node. Then, processing returns to block 520 of FIG. 6, which may be executed.

[0150] Conversely, if it is determined that the current tile includes one or more active access nodes, the method 500 proceeds to block 554. At block 554, the cache manager 225 uses one or more pairs of head 370 and tail 380 reference information associated with one or more prioritized groups of access nodes 260 within the current tile loaded into FPGA block RAM 230 to identify the access node index IDX of the highest priority access node 260 within the one or more prioritized groups. In some embodiments, such as embodiments of the method 500, the head 370 and tail 380 reference information may be access node index values ​​that may be utilized to identify an access node within the access node array 290, as described in connection with block 555.

[0151] In embodiments where a tile 250 includes multiple prioritized groups 350, the cache manager 225 may attempt to identify an access node 260 in the highest priority prioritized group 350 before proceeding to the next highest priority prioritized group 350, generally proceeding from highest priority to lowest priority within each prioritized group 350. Also, in some embodiments, each prioritized group 350 may be sorted. For example, if the prioritized groups 350 are implemented as linked lists, the next highest priority access node 260 may be identified from the top of each list 350 by following the head-of-list reference 370 within the current tile.

[0152] Once the access node index IDX of the highest priority access node 260 is identified, the method proceeds to block 555, where the cache manager 225 identifies the access node 260 in the access node array 290 of the current tile 250 based on the access node index IDX, as described above. The method then proceeds to block 560 of FIG. 6.

[0153] As discussed above in connection with FIG. 1 , electronic trading system 100 may include ticker plant 140. Specifically, ticker plant 140 may be utilized to provide various participant devices with real-time access to market data. Ticker plant often reflects the same real-time market data managed by matching engine book 150. While the foregoing primarily describes systems and methods for minimizing the need for external memory access from matching engine book (MEB) 150, such systems and methods may also be incorporated into ticker plant 140.

[0154] 8 is a schematic diagram illustrating one such embodiment of an automated trading system 700 with a ticker plant 710 that maintains a separate order book in the form of a memory cache 720. The gateway 110, sequencer 130, open order database 170, matching engine book 150, book processing logic (BPL) 220, cache manager 225 and symbol registry 270 contained within matching engine book 150, and cache 160 have been described above. For the sake of brevity, a description of these components will be omitted.

[0155] 8, ticker plant 710 has its own cache manager 712 and symbol registry 714 for managing and accessing tiles in its own cache 720. Ticker plant 710, which also has an internal memory cache (not shown), may be implemented with fixed hardware logic such as an FPGA and / or ASIC. The structure and operation of cache manager 712, symbol registry 714, and cache 720 may be substantially, if not identical to, the structure and operation of cache manager 225, symbol registry 270, and cache 160 of matching engine book 150 described above.

[0156] To keep the state of the order book in external cache 160 up to date, the fixed logic of ticker plant 140 may be configured to passively monitor confirmation messages from matching engine book 150 for various trading events, such as, but not limited to, confirmations for requests to place buy or sell orders, confirmations for requests to cancel orders, confirmations for requests to replace orders, confirmations for requests to modify orders, etc. Ticker plant 140 may also passively monitor for messages indicating that a particular order has been filled. In the illustrated embodiment, such messages may be forwarded directly to cache manager 712 of ticker plant 710 via sequencer 130.

[0157] Using these messages, the fixed logic of the ticker plant 710 may request the cache manager 712 to modify tiles in the cache 720 by adding, deleting, or modifying tiles containing open order data (e.g., stored in the access nodes) that indicate open orders for a given product, side, and price tuple. In this way, the cache manager 712 of the ticker plant 710 may maintain an up-to-date order book in the cache 720 that reflects the same order book maintained in the cache 160 of the matching engine book (MEB) 150.

[0158] In response to a market data feed request from a participant device, the fixed logic of the ticker plant 710 may request data on open orders for a particular instrument, side, and price from the cache manager 712 (e.g., from an access node 260). The cache manager 712 may then fetch a tile from its cache 720, as described above, and load the tile into an internal memory cache of the cache manager 712 or the cache 720. Once loaded, the cache manager 712 may retrieve the requested open order data from the tile and return the data to the requesting logic of the ticker plant 710 for further processing as part of a response data feed 730.

[0159] In some embodiments, the cache manager 712 of the ticker plant 710 may be configured to accept requests requesting all information about a given instrument, side, and price. Alternatively, or in addition, the cache manager 712 of the ticker plant 710 may be configured to accept requests requesting specific information about a given instrument, side, and price, such as, but not limited to, the number, quantity, and total quantity of open orders (e.g., number of open trades) for a given instrument, side, and price. In some embodiments, the cache manager 712 may be configured to respond to requests requesting information such as, but not limited to, the best bid and ask prices for a given instrument, which may be provided from an internal source, such as the symbol registry 714.

[0160] 9 is a schematic diagram illustrating another embodiment of an automated trading system 800 with a ticker plant 810 that maintains an independent order book in its own cache 820. In the illustrated embodiment, the ticker plant 810 includes a cache manager 812 and a symbol registry 814 for managing and accessing tiles in the cache 820. The structure and operation of the cache manager 812, symbol registry 814, and cache 820 are substantially identical to the structure and operation of the cache manager 712, symbol registry 714, and cache 720 of the ticker plant 710 described above in connection with FIG.

[0161] 9, however, the ticker plant 810 is configured to maintain an open book in a cache 820 based on market reactions 834 transmitted over a network to participant devices (120 in FIG. 1). Specifically, a matching engine book (MEB) server 830 may be any MEB server, such as the MEB server 150 described above, capable of accepting order inputs 832 and outputting various market reactions 834 to participant devices.

[0162] In this manner, to keep the state of the order book in external cache 820 up to date, the fixed logic of ticker plant 810 may be configured to accept and passively monitor market reactions 834 from matching engine book 830 to various trading events, such as, but not limited to, confirmations for requests to place buy or sell orders, confirmations for requests to cancel orders, confirmations for requests to substitute orders, confirmations for requests to modify orders, messages indicating that a particular order has been filled, etc. Ticker plant 810 may receive such market reactions 834 via any type of external network, such as a public network or a private network.

[0163] Using these messages, the fixed logic of the ticker plant 810 may request the cache manager 812 to modify tiles in the external multi-tiered memory cache 820 by adding, deleting, or modifying tiles containing open order data (e.g., access node 260) indicating open orders for a given product, side, and price tuple. In this manner, the cache manager 812 of the ticker plant 810 may maintain an up-to-date order book in the external multi-tiered memory cache 820 that mirrors the open book maintained by any matching engine book (MEB) server 830. As previously mentioned, the logic of the ticker plant 810 may request market data, such as open order data, from the cache manager 812 in response to a market data feed request for a particular product, side, and price from a participant device.

[0164] (Implementation options)

[0165] While the preceding discussion has been primarily in the context of a Matching Engine Book (MEB), data feed service, or ticker plant, it should be understood that the same design configurations may be applied to other components of a matching engine system or other types of high performance processors. That is, these configurations may also be advantageous in other types of "matching" applications, such as search engines, image recognition, database engines, etc., especially where data is organized in some predetermined order.

[0166] Additionally, the memory and processing resources necessary to implement the described functionality may be implemented as one or more special-purpose or general-purpose processors configured to perform the functions detailed herein. Such special-purpose processors may include application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs), which are physical and electrical configurations of general-purpose components to perform the functions detailed herein. Such general-purpose processors may execute special-purpose software or microcode stored in one or more memory resources, such as random access memory (RAM), flash memory, solid-state drives (SSDs), or other non-transitory processor-readable media.

[0167] In general, the methods, systems, and devices described above are merely illustrative. Various procedures or components may be omitted, substituted, or added as appropriate in various configurations. For example, in alternative configurations, the methods may be performed in a different order than described, and / or various steps may be added, deleted, and / or combined. Additionally, features described in connection with a particular configuration may be combined in various other configurations. Separate aspects or components of each configuration may also be combined. Furthermore, because technology evolves, many of the components are merely illustrative and do not limit the scope of the disclosure or claims.

[0168] Specific details are provided herein to provide a thorough understanding of exemplary configurations (e.g., implementations). However, configurations may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have not been described in unnecessary detail so as not to obscure the configurations. This description presents only exemplary configurations and is not intended to limit the scope, applicability, or configuration of the claims. Rather, the foregoing description of each configuration provides those skilled in the art with the necessary context to enable them to practice the described technology. Various changes may be made in the function and arrangement of each component without departing from the spirit and scope of the present disclosure.

[0169] In addition, each configuration may be described as a process depicted as a flow diagram or block diagram. While each process may be described as a sequential process, many of the processes may be performed in parallel or in parallel. The order of the processes may also be changed. A process may include additional steps not shown in the diagram. In addition, each example of the method may be implemented in hardware, software, firmware, middleware, microcode, hardware description language, or any combination thereof. When implemented in software, firmware, middleware, or microcode, program code or code segments to perform the necessary tasks may be stored in a non-transitory computer-readable medium such as a storage medium. The described tasks may be performed by a processing means executing the program code.

[0170] While several exemplary configurations have been described, various modifications, variations, and equivalents may be employed without departing from the spirit of the present disclosure. For example, each of the above elements may be part of a larger system where other rules may override or alter the application of the present invention. Also, multiple processes may be performed before, during, or after the operation of each of the above elements.

[0171] That is, the foregoing description has specifically shown and described exemplary embodiments, but those skilled in the art will recognize that various changes in form and detail may be made therein without departing from the legal scope of this patent as encompassed by the appended claims.

[0172] (Further implementation options)

[0173] It should be understood that the workflow of the exemplary embodiment described above may be implemented in many other ways. In some cases, each of the various "data processing means" may be realized by a physical, virtual, or cloud-based general-purpose computer equipped with peripheral devices such as a central processing unit, memory, mass storage devices such as disks, one or more communication interfaces, and one or more input / output (I / O) devices. The general-purpose computer serves as a processing means and performs the processes described above, for example, by loading software instructions into the processing means and executing the instructions to perform the functions described herein.

[0174] As is known in the art, such a computer may include a system bus, which is a set of hardware lines used to transmit data between components of a computer or processing system. The bus is like one or more shared conduits connecting the various components of a computer system (e.g., one or more central processing units, disks, various memories, input / output ports, network ports, etc.) and enabling the movement of information among them. Attached to the system bus are one or more central processing units that execute computer instructions. The system bus also typically includes an I / O device interface for connecting disks, memories, and various input / output devices. One or more network interfaces allow connection to various other devices attached to a network. The one or more memories provide volatile and / or nonvolatile storage for computer software instructions and data used to implement an embodiment. A mass storage device, such as a disk, provides nonvolatile storage for computer software instructions and data, for example, used to implement the various procedures described herein.

[0175] That is, embodiments may typically be implemented in hardware, custom-designed semiconductor logic, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), firmware, software, or any combination thereof.

[0176] In certain embodiments, the procedures, devices, and processes described herein are implemented as a computer program product that provides at least a portion of the software instructions for the system, such as a computer-readable medium (e.g., one or more removable storage media, such as DVD-ROMs, CD-ROMs, floppy disks, tapes, etc.). Such a computer program product may be installed by any suitable software installation procedure known in the art. In other embodiments, at least a portion of the software instructions may be downloaded via a wired and / or communication and / or wireless connection.

[0177] Some embodiments may be implemented as instructions stored on a non-transitory machine-readable medium, which may be read and executed by one or more procedures. A non-transitory machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). Examples of non-transitory machine-readable media may include read-only memory (ROM); random access memory (RAM); storage such as magnetic disk-based storage media, optical storage media, flash memory-based devices, etc.

[0178] Additionally, firmware, software, routines, or instructions may be described herein as performing particular processes and / or functions, although it will be apparent that such descriptions are included herein for convenience only and that such processes actually occur when a computing device, processor, controller, or other device executes the firmware, software, routines, instructions, etc.

[0179] It should also be understood that the block diagrams and system diagrams may contain more or fewer elements, may be arranged differently, or may be presented in different ways, but it should also be understood that some implementations may require specific block diagrams or network diagrams, and that there may be a particular number of instances of the block diagrams or network diagrams illustrating the implementation of an embodiment.

[0180] Also possible are embodiments that utilize cloud data processing services such as tools like Amazon Web Services, Google Cloud Platform, and the like.

[0181] That is, further embodiments may be implemented using various computer architectures and / or physical computers and / or virtual computers and / or cloud computers and / or any combination thereof. Accordingly, the computer systems described herein are for illustrative purposes only and are not limiting of the embodiments.

[0182] Although the foregoing description has shown and described exemplary embodiments in detail, those skilled in the art will recognize that various changes in form and detail may be made therein without departing from the statutory scope of this patent as encompassed by the appended claims.

Claims

1. 1. An electronic data processing system comprising: data processing means configured to perform one or more market functions; storage means accessed by said data processing means to organize stored data into one or more tiles; each tile further comprising: an array of access nodes representing open orders for a given product, side and price; a metadata field for the array of access nodes; and one or more head and / or tail references that organize the array of access nodes into one or more prioritized groups of active and / or free access nodes; Including, the system.

2. 10. The system of claim 1, wherein the access node further includes a reference to a cell data structure having additional data indicative of the order.

3. 10. The system of claim 1, wherein the one or more prioritized groups are arranged based on one or more attributes of access nodes in the array of access nodes, the one or more attributes including at least sequence, time of receipt, or quantity.

4. 2. The system of claim 1, wherein the one or more prioritized groups are each implemented as a linked list, each linked list further including a predetermined reference from among the head reference information and tail reference information, and each access node in the array includes a reference to the next or previous access node in the linked list.

5. 2. The system of claim 1, wherein the one or more prioritized groups are each implemented as a docked list, each docked list including a predetermined one of the head reference information and tail reference information, and each access node in the array including a reference to a next access node and a reference to a previous access node.

6. 2. The system of claim 1, wherein the storage means further includes an on-chip block random access memory (block RAM) located on a semiconductor chip that includes the processing means, and the storage means further includes an off-chip dynamic random access memory (DRAM) that is not located on the semiconductor chip that includes the processing means, and wherein the two or more tiles are stored contiguously so that the two or more tiles can be accessed with a single address parameter.

7. 7. The system of claim 6, wherein the source and destination addresses by which said processing means accesses said storage means include one or more of an off-chip DRAM address and an on-chip block RAM address.

8. 10. The system of claim 1, wherein the one or more tiles further include a reference to another tile such that the number of access nodes is a predetermined number and the total number of access nodes for a given product, side, and price exceeds the predetermined number of access nodes.

9. 2. The system of claim 1, wherein at least one access node contained within a given tile becomes accessible to said processing means before transfer of the entire given tile is complete.

10. 10. The system of claim 1, wherein the one or more tiles further include a free list ordered by index into the array of access nodes.

11. 6. The system of claim 5, wherein at least one of the tiles is configured to allow the processing means to move an access node between two of the prioritization groups by rewriting the reference information to the previous access node and the reference information to the next access node.

12. 3. The system of claim 2, wherein the cell data structure includes static order data stored in a data structure separate from the one or more tiles.

13. 13. The system of claim 12, wherein the cell data structure includes fields indicating an access node index corresponding to a product, a side, a price, and a cell, respectively, and the processing means is capable of identifying a corresponding access node within at least one of the tiles using the product, side, price, and access node index.

14. 2. The system of claim 1, wherein each access node includes a reference to a corresponding said cell data structure.

15. 10. The system of claim 1, wherein the one or more market features include one or more matching engine books.

16. 10. The system of claim 1, wherein the one or more market functions include one or more market data feeds.

17. 2. The system of claim 1, wherein the processing means is implemented by fixed logic, the fixed logic comprising any of the following technologies: Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), and other embedded hardware technologies.

18. 1. A computer program product on a computer-readable medium for use in performing market functions on a data processing system, comprising: First instructions for accepting access nodes each referencing a cell data structure representing order data relating to a product, a side, and a price; second instructions for inserting the access nodes into one or more tiles, each of the one or more tiles including an array of the access nodes for a given product, side, and price, metadata fields for additional order data for the given product, side, and price, and at least head and tail reference information for organizing the access nodes in the array into one or more prioritized groups; third instructions for processing the array of access nodes to perform the market function; A computer program product comprising:

19. 1. An electronic data processing system comprising: one or more data processing means; one or more storage means accessed by said one or more data processing means to organize stored data into one or more tiles, said storage means including on-chip block random access memory (block RAM) and off-chip dynamic random access memory (DRAM) located on a semiconductor chip comprising at least one of said one or more data processing means, each of said one or more tiles including an array of access nodes representing orders for a particular product, side, and price (ISP), and one or more head references and / or tail references organizing said access nodes into one or more prioritized groups of active access nodes and a group of free access nodes; wherein the one or more data processing means further comprises: Accepting a request for an access node of a given ISP; reading tiles of the given ISP from the DRAM into the block RAM; Identifying in the block RAM the requested access node within the tile of the given ISP loaded into the block RAM; returning from the block RAM the requested access node from the tile of the given ISP that was loaded into the block RAM; The system is configured as follows:

20. 20. The system of claim 19, wherein the one or more data processing means further comprises: a system configured to move the requested access node from the one or more prioritized collections of active access nodes to the collection of free access nodes, the movement comprising modifying reference information of at least one of the one or more head reference information and / or tail reference information in the block RAM.

21. 21. The system of claim 20, wherein the requests for access nodes of a given ISP include a first request for a first access node of the given ISP, the first request being associated with a new order, and wherein identifying the requested access node within the tile of the given ISP in the block RAM further includes identifying the first access node in a first prioritized group of the one or more prioritized groups in the block RAM by the one or more head references and / or tail references.

22. 22. The system of claim 21, wherein the one or more data processing means further comprises: receiving a second request associated with the new order requesting a second access node of the given ISP; Identifying the requested second access node within the given ISP tile in the block RAM; returning from the block RAM the requested second access node from the tile of the given ISP that was loaded into the block RAM; wherein the identifying further comprises identifying the second access node within the first prioritized group in the block RAM by the one or more head references and / or tail references.

23. 22. The system of claim 21, wherein the one or more data processing means further comprises: receiving a second request associated with the new order requesting a second access node of the given ISP; Identifying the requested second access node within the given ISP tile in the block RAM; returning from the block RAM the requested second access node from the tile of the given ISP that was loaded into the block RAM; wherein the identifying further comprises identifying the second access node within a second prioritized group in the block RAM by the one or more head references and / or tail references.

24. 22. The system of claim 21, wherein the given ISP comprises a given product, a given side, and a first price, the tiles of the given ISP comprise a first tile, and the one or more data processing means further comprises: receiving a second request associated with the new order requesting a second access node of the given ISP; reading a second tile for the given product, the given side, and a second price from the DRAM into the block RAM; determining whether the first tile includes an active access node in the one or more prioritized groups within the first tile; Identifying the requested second access node in the second tile in the block RAM; returning from the block RAM the requested second access node from the second tile loaded into the block RAM; wherein the identifying further includes identifying the second access node within a prioritized group of the one or more prioritized groups within the second tile in the block RAM by one or more head references and / or tail references within the second tile.

25. 25. The system of claim 24, wherein the one or more data processing means are configured to begin loading the second tile before accepting the second request for the second access node.

26. 21. The system of claim 20, wherein each access node is uniquely identified by the given ISP and an index value in the array of access nodes, and wherein accepting a request requesting an access node of a given ISP further comprises accepting a request for an order cancellation request requesting an access node of a given ISP and a given index value, and wherein identifying the requested access node within the tile of the given ISP in the block RAM further comprises identifying the access node having the given index value in the array of access nodes in the block RAM.

27. 20. The system of claim 19, wherein the tiles of the given ISP are read from the DRAM into the block RAM before accepting a request for an access node of the given ISP.

Images