Method and apparatus for accelerated format translation of data in a delimited data format

Information

  • Patent Grant
  • 9633093
  • Patent Number
    9,633,093
  • Date Filed
    Tuesday, October 22, 2013
    11 years ago
  • Date Issued
    Tuesday, April 25, 2017
    7 years ago
Abstract
Various methods and apparatuses are described for performing high speed format translations of incoming data, where the incoming data is arranged in a delimited data format. As an example, the data in the delimited data format can be translated to a fixed field format using pipelined operations. A reconfigurable logic device can be used in exemplary embodiments as a platform for the format translation.
Description
INTRODUCTION

A delimited data format is a common format used for passing data between data processing systems or over networks, particularly with respect to passing record-oriented data. Delimited data formats are platform-independent, and they use a very simple set of tags to represent data. With a delimited data format, data characters are organized into a plurality of fields. A field delimiter (FDL) character is used to separate data fields, a record delimiter (RDL) character is used to separate records, and a shield character is used to shield data characters within data fields that also happen to serve as the field delimiter character or the record delimiter character.


The comma separated value (CSV) format is a common delimited data format. With the CSV format, a comma is typically used as the FDL character, a newline is typically used as the RDL character, and a quotation mark is typically used as the shield character. However, other characters can be employed. For example, a pipe or tab character as the FDL character, an apostrophe character as the shield character, etc. FIG. 1 shows an exemplary portion of a record in a delimited data format.


In the example of FIG. 1, the record is a patient medical record 100 comprising a plurality of different fields (e.g., name, address, etc.). The data from this record 100 can be represented in the CSV format via data 102 in FIG. 1. Each field 104i of the record can be separated by the FDL character 106. However, it may be the case that the character used as the FDL character 106 also exists within the data as a data character. In the example of FIG. 1, this is shown by the commas 110 that are present in the data for Fields 1 and 3 (1041 and 1043). In such situations, to prevent a misinterpretation of these commas as field delimiters, the CSV format operates to use a shield character 108 at the start and end of the field that contains the data character 110 which matches the FDL character 106. In the example of FIG. 1, quote marks serve as the shield character 108. Thus, the data St. Louis, Mo. becomes “St. Louis, Mo.”. The use of shield characters raises another possible misinterpretation with respect to data characters 112 in a field that happen to match the shield character 108 (see the quotation marks used for the data string (“Jim”) in Field 1 (1001)). To prevent a misinterpretation of these quotation marks as shield characters, the CSV format also operates to use a shield character 108 adjacent the data character that happens to match the shield character. Thus, the data string (“Jim”) appears as (““Jim””) in the CSV format.


Delimited data formats present significant challenges in connection with processing the delimited data using software. The inherently serial process of moving byte by byte through a file to look for delimiters and shield characters does not map well to general purpose processors. For example, suppose it is desired to validate whether the zip code field of the file shown in FIG. 1 contains a valid zip code. A software-based system would need to process each byte of the file up through Field 4 (1044) in order to know that Field 4 has been located. Only then can the processing software validate the zip code data. This byte-by-byte processing requirement creates a bottleneck that detracts from the throughput of a processing system.


As solution to this problem, the inventors disclose various techniques for performing high speed format translations of incoming data, where the incoming data is arranged in a delimited data format.


In accordance with an exemplary aspect disclosed herein, the data in the delimited data format can be translated into outgoing data having a structured format, the structured format being configured to permit a downstream processing component to jump directly to a field of interest in the outgoing data without requiring that component to analyze all of the bytes leading up to the field of interest.


An example of a structured format that can be used toward this end is a fixed field format. With a fixed field format, each field of the outgoing data has a fixed length and is populated with data characters that belong to the same field of the incoming data. If there are not enough data characters for that incoming field to fill the fixed length of the outgoing field, then padding characters can be added to the outgoing field. By employing fields of a fixed length, any downstream processing can quickly and easily target specific fields of the outgoing data for further processing by simply jumping to the location of the targeted field. Because the fixed field layout is well-defined, a downstream processing component will be able to know the byte offset for the field of interest, which means that only simple pointer arithmetic would be needed for the processing component to jump to the field of interest.


In an exemplary embodiment, a reconfigurable logic device can be employed to perform this data translation. As used herein, the term “reconfigurable logic” refers to any logic technology whose form and function can be significantly altered (i.e., reconfigured) in the field post-manufacture. This is to be contrasted with a general purpose processor (GPP), whose function can change post-manufacture, but whose form is fixed at manufacture. An example of a reconfigurable logic device is a programmable logic device (PLD), such as a field programmable gate array (FPGA). As used herein, the term “general-purpose processor” (or “GPP”) refers to a hardware device having a fixed form and whose functionality is variable, wherein this variable functionality is defined by fetching instructions and executing those instructions, of which a conventional central processing unit (CPU) is a common example. Exemplary embodiments of GPPs include an Intel Xeon processor and an AMD Opteron processor. Furthermore, as used herein, the term “software” refers to data processing functionality that is deployed on a GPP or other processing devices, wherein software cannot be used to change or define the form of the device on which it is loaded. By contrast, the term “firmware”, as used herein, refers to data processing functionality that is deployed on reconfigurable logic or other processing devices, wherein firmware may be used to change or define the form of the device on which it is loaded.


Furthermore, the data translation task can be broken down into a plurality of subtasks, where each subtask can be performed by a plurality of data processing modules arranged to operate in a pipelined fashion with respect to each other. Thus, while a downstream module in the pipeline is performing a subtask on data that was previously processed by an upstream module in the pipeline, the upstream module in the pipeline can be simultaneously performing its subtask on more recently received data. An exemplary data translation pipeline can comprise (1) a first module configured to convert the incoming data arranged in the delimited data format to an internal format stripped of the field delimiter characters and the record delimiter characters of the incoming data while preserving the data characters of the incoming fields, (2) a second module downstream from the first module, the second module configured to remove the shield characters from the converted data having the internal format, and (3) a third module downstream from the second module, the third module configured to translate the output of the second module to the outgoing data having the fixed field format.


Through such a modular approach, the pipeline is amenable to accelerated data translation via any of a number of platforms. As mentioned above, reconfigurable logic can be used as a platform for deploying the modules as hardware logic operating at hardware processing speeds via firmware deployed on a reconfigurable logic device. Moreover, such a pipeline is also amenable to implementation on graphics processor units (GPUs), application-specific integrated circuits (ASICs), chip multi-processors (CMPs), and other multi-processor architectures.


The inventors also disclose that the pipeline can be configured to ingest and process multiple characters per clock cycle. This data parallelism can be another source for acceleration relative to conventional solutions.


These and other features and advantages of the present invention will be described hereinafter to those having ordinary skill in the art.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 depicts an example of data organized into a delimited data format.



FIG. 2 depicts an exemplary translation engine in accordance with a disclosed embodiment.



FIG. 3 depicts an exemplary system comprising a translation engine and a data processing stage downstream from the translation engine.



FIG. 4 depicts an exemplary system comprising a translation engine, a data processing stage downstream from the translation engine, and a translation engine downstream from the data processing stage.



FIG. 5 depicts an exemplary system similar to that of FIG. 4, specifically showing field-specific data processing operations within the data processing stage.



FIG. 6 depicts an exemplary fixed field format.



FIG. 7 depicts the data of FIG. 1 organized in a fixed field format.



FIGS. 8(a) and (b) depict examples of suitable platforms for the translation engine.



FIGS. 9(a) and (b) depict exemplary printed circuit boards for use as a coprocessor for the embodiments of FIGS. 8(a) and (b).



FIG. 10 depicts an example of how a firmware pipeline can be deployed across multiple reconfigurable logic devices.



FIG. 11 depicts an example of a pipeline that can be deployed by a translation engine to convert delimited data to fixed field data.



FIG. 12 depicts an exemplary pipeline for a variable record gate (VRG) module.



FIG. 13 depicts a state machine for an exemplary quote masker circuit.



FIGS. 14(a) and (b) depict exemplary delimiter finder circuits.



FIG. 15 depicts an exemplary shift register logic circuit and an exemplary field identifier logic circuit.



FIG. 16 depicts an exemplary quote removal (QRM) module.



FIG. 17(a) depicts an exemplary variable-to-fixed (V2F) module.



FIG. 17(b) depicts a state machine for the V2F module of FIG. 17(a).



FIG. 18 depicts an exemplary pipeline that can be deployed by a translation engine to convert fixed field data to delimited data.



FIG. 19 depicts an exemplary fixed-to-variable (F2V) module.



FIG. 20 depicts an exemplary quote addition (QAD) module.



FIG. 21 depicts an exemplary variable inverse record gate (VIRG) module.



FIG. 22 depicts an exemplary arrangement for a processing module, where the processing module includes a bypass path and a processing path.





DETAILED DESCRIPTION


FIG. 2 depicts an exemplary translation engine 202 that is configured to translate an incoming byte stream 200 having a delimited data format into a reformatted byte stream 204 having the structured format that is geared toward high performance downstream processing such that a downstream processing component can jump directly to fields without analyzing the data characters of the reformatted byte stream 204. As noted, this structured format can be a fixed field format. Once again, FIG. 1 shows exemplary data that can serve as byte stream 200. As will be understood, the bytes of the byte stream 200 can serve as data characters, record delimiters characters, field delimiter characters, and shield characters.



FIG. 3 shows the delivery of the reformatted byte stream 204 to a data processing stage. The data processing stage will be able to select fields of the reformatted byte stream for targeted processing without further analyzing the data characters of the reformatted byte stream 204, thereby greatly improving the throughput performance of the system. The data processing stage then performs data processing operations on the selected fields to generate a processed byte stream 302. This processed byte stream 302 can also exhibit the structured format of the reformatted byte stream 204. The data processing stage 300 can be implemented in software via a GPP, in firmware via reconfigurable logic, or any other platform desired by a practitioner.


For example, the data processing stage can be configured to perform various processing operations as part of data quality checking in connection with extract, transfer, and load (ETL) operations for a database. Some exemplary processing operations can include:

    • Address Validation: A field expected to contain an address can have the address data validated as to whether it exhibits a correct postal service-recognized address format.
    • Email Validation: A field expected to contain an email address can be validated as to whether it exhibits a correct email address format.
    • Date Validation: A field expected to contain a date can be validated as to whether it exhibits a date in the correct range and format.
    • Query/Replace: The data characters in a selected field can be translated from one set to another set (e.g., mapping codes from one code set to another code set or replacing codes with natural language descriptions of such codes).
    • Field Masking/Tokenization: The data characters in a select field can be obfuscated or tokenized for security purposes.
    • Filtering/Searching: The data characters in selected fields can be matched against various search criteria.


      It should be understood that these are but a few of exemplary data processing operations that can be performed by the data processing stage 300.


Furthermore, it should be understood that these data processing operations can be legacy data processing operations that are implemented in software on processors of a practitioner. Also, if desired, a practitioner can deploy such data processing operations via reconfigurable logic to achieve still further acceleration. Examples of hardware-accelerated data processing operations that can be performed by the data processing stage 300 include the data processing operations disclosed by U.S. Pat. Nos. 7,636,703, 7,702,629, 8,095,508 and U.S. Pat. App. Pubs. 2007/0237327, 2008/0114725, 2009/0060197, and 2009/0287628, the entire disclosures of each of which being incorporated herein by reference.



FIG. 4 depicts an exemplary embodiment where the processed byte stream 302 is translated by a translation engine 400 into a byte stream 402 having a target format. For example, a practitioner may desire that the system re-translate the byte stream 302 back into a delimited data format. In such an embodiment, the translation engine 400 can perform the complementary inverse of the translation operations performed by translation engine 202 to return the data to the delimited data format. Translation engine 400 can also be hardware-accelerated via reconfigurable logic and modularized via processing modules arranged in a pipeline as explained in connection with the translation engine 202.



FIG. 5 depicts a similar system that highlights how the output of the translation engine 202 can feed field-specific data processing operations 500 at the data processing stage 300. It should also be understood that for software-based embodiments of the data processing stage 300, record-specific threads can be running in parallel to provide additional acceleration.



FIG. 6 depicts an exemplary fixed field format that can be exhibited by byte stream 204. Each field of the data has a fixed length (e.g, 128 bytes, etc.). The translation engine 202 can operate to populate each field of the fixed field output with data characters of the corresponding field in the byte stream having the delimited data format. Should there not be enough data characters in the byte stream to fill the fixed field, padding characters can be added to complete the field. In the event that there is insufficient space in the fixed field for all data characters in a field of the delimited data format byte stream, the translation engine 202 can flag a data overflow condition and take appropriate measures through exception handling logic. FIG. 7 depicts an example where the data of FIG. 1 has been translated into a fixed field format where each field has a fixed length of 24 bytes. It should be well understood that a field length of 24 bytes is exemplary only, and other field lengths can be readily employed. It should also be understood that each field need not have the same fixed length. For example, a practitioner can choose to define a field length of 36 bytes for Field 1, a field length of 64 bytes for Field 2, a field length of 64 bytes for Field 3, a field length of 16 bytes for Field 4, and so on. A practitioner can choose such fixed field lengths for each field based on expected characteristics of the data.


In an embodiment where the translation engine 202 is implemented in reconfigurable logic, examples of suitable platforms for such a translation engine 202 are shown in FIGS. 8(a) and (b). FIG. 8(a) depicts a system 800 employs a hardware-accelerated data processing capability through coprocessor 840 to process the incoming byte stream 200. Within system 800, a coprocessor 840 is positioned to receive byte stream 200 that streams into the system 800 from a network 820 (via network interface 810).


The computer system defined by processor 812 and RAM 808 can be any commodity computer system as would be understood by those having ordinary skill in the art. For example, the computer system may be an Intel Xeon system or an AMD Opteron system. Thus, processor 812, which serves as the central or main processor for system 800, preferably comprises a GPP (although this need not be the case).


In this exemplary embodiment, the coprocessor 840 comprises a reconfigurable logic device 802. Preferably, the byte stream 200 streams into the reconfigurable logic device 802 by way of system bus 806, although other design architectures are possible (see FIG. 9(b)). The reconfigurable logic device 802 can be a field programmable gate array (FPGA), although this need not be the case. System bus 806 can also interconnect the reconfigurable logic device 802 with the processor 812 as well as RAM 808. In an exemplary embodiment, system bus 806 may be a PCI-X bus or a PCI-Express bus, although this need not be the case.


The reconfigurable logic device 802 has firmware modules deployed thereon that define its functionality. The firmware socket module 804 handles the data movement requirements (both command data and target data) into and out of the reconfigurable logic device, thereby providing a consistent application interface to the firmware application module (FAM) chain 850 that is also deployed on the reconfigurable logic device. The FAMs 850i of the FAM chain 850 are configured to perform specified data processing operations on any data that streams through the chain 850 from the firmware socket module 804. Examples of FAMs that can be deployed on reconfigurable logic in accordance with the exemplary translation engine 202 are described below.


The specific data processing operation that is performed by a FAM is controlled/parameterized by the command data that FAM receives from the firmware socket module 804. This command data can be FAM-specific, and upon receipt of the command, the FAM will arrange itself to carry out the data processing operation controlled by the received command. For example, within a FAM that is configured to perform a shield character find operation, the FAM's shield character find operation can be parameterized to define the character that will be used as the shield character. In this way, a FAM that is configured to perform a shield character find operation can be readily re-arranged to perform a different shield character find operation by simply loading parameters for a new shield character in that FAM. As another example, a command can be issued to the one or more FAMs that are configured to find a delimiter character (e.g, a record delimiter character or field delimiter character) so that the FAM can be tailored to different delimiter characters without requiring a full reconfiguration of the reconfigurable logic device.


Once a FAM has been arranged to perform the data processing operation specified by a received command, that FAM is ready to carry out its specified data processing operation on the data stream that it receives from the firmware socket module. Thus, a FAM can be arranged through an appropriate command to process a specified stream of data in a specified manner. Once the FAM has completed its data processing operation, another command can be sent to that FAM that will cause the FAM to re-arrange itself to alter the nature of the data processing operation performed thereby. Not only will the FAM operate at hardware speeds (thereby providing a high throughput of data through the FAM), but the FAMs can also be flexibly reprogrammed to change the parameters of their data processing operations.


The FAM chain 850 preferably comprises a plurality of firmware application modules (FAMs) 850a, 850b, . . . that are arranged in a pipelined sequence. However, it should be noted that within the firmware pipeline, one or more parallel paths of FAMs 850i can be employed. For example, the firmware chain may comprise three FAMs arranged in a first pipelined path (e.g., FAMs 850a, 850b, 850c) and four FAMs arranged in a second pipelined path (e.g., FAMs 850d, 850e, 850f, and 850g), wherein the first and second pipelined paths are parallel with each other. Furthermore, the firmware pipeline can have one or more paths branch off from an existing pipeline path. A practitioner of the present invention can design an appropriate arrangement of FAMs for FAM chain 850 based on the processing needs of a given translation operation.


A communication path 830 connects the firmware socket module 804 with the input of the first one of the pipelined FAMs 850a. The input of the first FAM 850a serves as the entry point into the FAM chain 850. A communication path 832 connects the output of the final one of the pipelined FAMs 850m with the firmware socket module 804. The output of the final FAM 850m serves as the exit point from the FAM chain 850. Both communication path 830 and communication path 832 are preferably multi-bit paths.


The nature of the software and hardware/software interfaces used by system 800, particularly in connection with data flow into and out of the firmware socket module are described in greater detail in U.S. Patent Application Publication 2007/0174841, the entire disclosure of which is incorporated herein by reference.



FIG. 8(b) depicts another exemplary embodiment for system 800. In the example of FIG. 8(b), system 800 includes a data store 842 that is in communication with bus 806 via disk controller 814. Thus, the byte stream 200 that is streamed through the coprocessor 840 may also emanate from data store 842. Furthermore, the data store 842 can be the target destination for the output from the translation engine 202 and/or the data processing stage 300 if desired by a practitioner. Data store 842 can be any data storage device/system, but it is preferably some form of mass storage medium. For example, data store 842 can be a magnetic storage device such as an array of Seagate disks.



FIG. 9(a) depicts a printed circuit board or card 900 that can be connected to the PCI-X or PCI-e bus 806 of a commodity computer system for use as a coprocessor 840 in system 800 for any of the embodiments of FIGS. 8(a)-(b). In the example of FIG. 9(a), the printed circuit board includes an FPGA 802 (such as a Xilinx Virtex 5 or an Altera Stratix V FPGA) that is in communication with a memory device 902 and a PCI-e bus connector 904. A preferred memory device 902 comprises SRAM and DRAM memory. A preferred PCI-X or PCI-e bus connector 904 is a standard card edge connector.



FIG. 9(b) depicts an alternate configuration for a printed circuit board/card 900. In the example of FIG. 9(b), one or more network controllers 908, and one or more network connectors 910 are also installed on the printed circuit board 900. Any network interface technology can be supported, as is understood in the art. Hardware logic can be used as the internal connector between the FPGA, memory, and network controller. It should be noted that a disk interface technology can be used in addition to or in place of the network controller and network connector shown in FIG. 9(b).


It is worth noting that in either the configuration of FIG. 9(a) or 9(b), the firmware socket 804 can make memory 902 accessible to the bus 806, which thereby makes memory 902 available for use by an OS kernel as the buffers for transfers to the FAMs from a data source with access to the bus. It is also worth noting that while a single FPGA 802 is shown on the printed circuit boards of FIGS. 9(a) and (b), it should be understood that multiple FPGAs can be supported by either including more than one FPGA on the printed circuit board 900 or by installing more than one printed circuit board 900 in the system 800. FIG. 10 depicts an example where numerous FAMs in a single pipeline are deployed across multiple FPGAs.


Translation Engine 202



FIG. 11 depicts an exemplary pipeline that can be employed by the translation engine 202. The pipeline can comprise (1) a first module configured to convert the incoming data arranged in the delimited data format to an internal format stripped of the field delimiter characters and the record delimiter characters of the incoming data while preserving the data characters of the incoming fields, (2) a second module downstream from the first module, the second module configured to remove the shield characters from the converted data having the internal format, and (3) a third module downstream from the second module, the third module configured to translate the output of the second module to the outgoing data having the fixed field format. In this example, the first module can be referred to as a variable record gate (VRG) module, the second module can be referred to as a quote removal module (QRM) given that quote marks are used as the shield character in this example, and the third module can be referred to as a variable-to-fixed (V2F) module. Each module can be configured to operate in parallel in a pipelined manner. As such, while the V2F module is operating on data previously processed by the VRG and QRM modules, the QRM module is operating on data previously processed by the VRG module, and the VRG module is operating on newly received data, and so on as data continues to stream into the pipeline.


VRG Module:



FIG. 12 depicts an exemplary arrangement for a VRG module. The components of the VRG module shown in FIG. 12 can also be implemented as modular circuits in a pipelined chain. The VRG module can generate an output byte stream that is marked with control data to identify information such as which bytes correspond to a start of record, an end of record, a start of field, and an end of field. Thus, downstream modules need not reparse the bytes to gather that information. With reference to the operations described herein, it should be understood that the various circuit components of the VRG module can process the bytes of the byte stream in chunks (e.g., 64 bit (8 byte) or 128 bit (16 byte) chunks) per clock cycle. Thus, the component circuits can be configured to provide data parallelism by ingesting and processing multiple characters in the byte stream per clock cycle.


A first circuit in the VRG can be configured to process the shield characters that are present in the byte stream 200 to distinguish between the bytes that are eligible for downstream consideration as to whether they correspond to a delimiter character (e.g., the bytes that are present in a field that has not been shielded by a shield character) and the bytes that are ineligible for downstream consideration as to whether they correspond to a delimiter character (e.g., the bytes that are present in a field that has been shielded by a shield character). In this example, such a circuit can be referred to as a quote masker (QM) circuit.


A second circuit in the VRG that is downstream from the QM circuit can be configured to process the output of the QM circuit to locate the presence of delimiter characters in the byte stream. In this example, such a circuit can be referred to as a delimiter finder (DLF) circuit.


A third circuit in the VRG that is downstream from the DLF circuit can be configured to process the output of the DLF circuit to detect empty fields, remove the delimiter characters from the byte stream, and mark the bytes which correspond to data characters at the start of a record and end of a record. In this example, such a circuit can be referred to as a shift register logic (SRL) circuit.


A fourth circuit in the VRG that is downstream from the SRL circuit can be configured to process the output of the SRL circuit to generate a field identifier that identifies which field each data character of the byte stream belongs to and mark the bytes which correspond to data characters at the start of a field and end of a field. In this example, such a circuit can be referred to as a field ID logic (FIDL) circuit.



FIG. 13 provides additional detail regarding the QM circuit. Once again, in this example, the shield character is a quote mark, so quotes will be used throughout this example to refer to the shield character. However, it should be understood that characters other than quote marks could be used as the shield character. As noted, the QM circuit is configured to mark each byte of the byte stream with an indicator of whether or not it is a valid candidate as a delimiter (i.e. NOT protected by the shield character). FIG. 13 depicts exemplary state diagrams that can be employed by the QM circuit to implement this task. FIG. 13 shows two states: CLOSED (“Close Quote”) and OPEN (“Open Quote”). In the CLOSED state, which is the initialization state, the quotes have been closed, and characters are open for consideration as a delimiter. While in this state, any character that is not a quote character will be marked with a “Delimiter Valid” (DV) flag set to true, meaning that the character is a candidate delimiter character. Upon observing a quote character, this machine will transition to the OPEN state, meaning that the data is inside a quote and thus shielded by the quote character. Any character other than a quote character will be marked with a DV flag set to false, indicating that the character is not a candidate to be a delimiter. Upon detection of another quote character, this state machine will transition back to CLOSED, meaning that next character is no longer being shielded by quote marks. This toggling behavior also accommodates the possible presence of double quotes in the byte stream which are meant to internally shield data characters that happen to be quote marks (see the portion of Field 1 in FIG. 1 comprising “Jim”—all of Field 1 has been shielded by quote marks, so that quote mask should not change upon encountering the internal double quotes in the byte stream). From the open data state, if a quote mark is detected in the byte stream, the state machine will transition to the closed quote state, while any other character in the byte stream means the state machine will remain in the open data state.


It should be understood with the diagram of FIG. 13 that one can ignore the DV status bits for the actual quote characters because configuration restrictions prevent shield characters and delimiter characters from overlapping. In this model, some quotes will be marked as valid, and others will not, but regardless of their marking they will never be considered a delimiter, as will be understood upon review of FIG. 14.


The QM circuit thus outputs the bytes of the byte stream where each byte is associated with a DV flag to indicate whether the associated byte should be processed to assess whether it contains a delimiter character.



FIG. 14(a) provides additional detail regarding an example of a DLF circuit. A data register can be loaded with the current byte under consideration. A mask register can be loaded with the DV flag associated with the byte loaded in the register. A first match key register can be loaded with the RDL character, and a second match key register can be loaded with the FDL character. The byte in the data register can be logically ANDed with the DV data in the mask register. Thus, from the description above, (1) if a byte has been identified by the QM register as being eligible for consideration as to whether it contains a delimiter character, its associated DV flag is equal to 1, and the output of the AND operation will pass the byte to a matching stage, and (2) if a byte has been identified by the DV register as being ineligible for consideration as to whether it contains a delimiter character, its associated DV flag is equal to 0, and the output of the AND operation will pass a zero value to a matching stage (thereby causing the matching stage to find no match with respect to the delimiter characters which are assumed to be different characters than the zero value).


A first comparator in the matching stage compares the RDL character with the AND operation output. Based on the outcome of that comparison, a control signal can be applied to a multiplexer to govern whether an RDL flag associated with the byte under consideration will go to a state indicating the byte under consideration corresponds to the RDL character (e.g., high) or to a state indicating the byte under consideration does not correspond to the RDL character (e.g., low). Similar matching logic can be employed to test the AND operation output against the FDL character to yield an FDL flag associated with the byte under consideration. Furthermore, for embodiments where the DLF circuit is implemented in reconfigurable logic, the parallelism capabilities provided by the reconfigurable logic mean that the RDL character matching operation and the FDL character matching operation can be performed simultaneously.


Thus, the output of the DLF circuit shown by FIG. 14(a) will be a stream of outgoing bytes and their associated RDL and FDL flags.



FIG. 14(b) depicts an example of a DLF circuit where the DLF circuit is configured to ingest multiple characters per clock cycle (e.g., 3 characters per clock cycle as shown in the example of FIG. 14(b)). Thus, the data shift register through which the byte stream is passed will have a multi-character data width (once again, a 3 character width in this example). Similarly, the data shift register through which the DV mask is passed will also have a data width that corresponds to the data width of the data shift register for the byte stream. Each clock cycle, the 3 characters of the data shift register and the DV masks corresponding to those three characters can be processed in parallel through replicated AND gates, comparators, and multiplexers to test the characters for matches against the RDL character and the FDL character. Upon completion of a cycle, the data shift registers can be configured to perform a shift by three characters to load the next set of characters for processing.



FIG. 15 provides additional detail regarding the SRL circuit and the FIDL circuit. The SRL circuit and the FIDL circuit can cooperate to pack the data headed downstream. FDL and RDL characters are removed from the byte stream, a count of skipped fields (e.g., empty fields) is generated, and the data characters that serve as field and record boundaries are marked. Further still, each field can be tagged with a field identifier for use by downstream processing. The output of the FIDL circuit can thus be the data characters of the byte stream and control data associated with those characters. This control data can take the form of a structured module chain interface (SMCI) protocol. The SMCI protocol can include a start of field (SOF) data, end of field (EOF) data, start of record (SOR) data, end of record (EOR) data, field identifier data, and count data, the count data being indicative of how many bytes should be consumed (e.g., how many bytes are valid in a transaction (transmission of a data word). For a data width of 8 bytes, for example, the count can range from 0-8 depending upon how many of the bytes are valid.


The SRL, circuit of FIG. 15 can employ three shift registers—a data shift register through which the characters of the byte stream are pushed, a RDL shift register through which the RDL flag data is pushed, and a FDL shift register through which the FDL flag data is pushed.


Logic 1500 can be configured to:

    • Find the “leading” delimiter in the FDL or RDL register (the first character in the data register for which the corresponding FDL or RDL flag is high). The record/field found flag can be set as appropriate when a leading delimiter is found.
    • Check the RDL and FDL flags following the leading delimiter to determine if an empty or skipped field/record is present. An empty/skipped field is a field with no data. Such an empty/skipped field appears in the byte stream as back to back FDL characters (as indicated by the FDL flag data). An empty/skipped record is a record with no data. Such an empty/skipped record appears in the byte stream as back to back RDL characters (as indicated by the RDL flag data).
      • If there are back to back delimiters in the byte stream, determine a count of the empty fields/records and pull those off the shift register. This count is communicated as the Fields Skip output of the SRL circuit in FIG. 15.
      • If non-empty fields are found, use the position of the delimiter (communicated as a bit in the field/record found register) to indicate how much data to pull off for the given field. This information can be communicated as the Data Count output of the SRL circuit in FIG. 15.


The shift logic 1502 can then operate in a fashion to cause the shift register to consume or strip off the delimiters. Thus, when delimiter characters are found in the byte stream based on the SMCI data, the shift logic 1502 can cause the shift register to shift out the delimiter characters while holding a data valid signal low. In this fashion, the delimiter characters are effectively dropped from the outgoing data stream.


The FIDL circuit then takes in the output of the SRL circuit in a register output and processes that output to generate an EOR flag and EOF flag for the data characters in the byte stream. Based on the delimiter following the data being pulled, the logic can determine whether to send an EOF or EOR marker (by checking the delimiter that triggered then end of the field/record). Logic 1504 and 1506 operate as a counter that increments the Field ID each time a new field in a record is encountered (in response to the skipped count, the EOR flag and the EOF flag). Thus, the Field ID can operate as an array index such that the first field has a Field ID of 0, the second field has a Field ID of 1, and so on. Furthermore logic 1508 operates to generate SOR and SOF flags from the EOR and EOF flags. The SOR/SOF/EOF/EOR data, count data, and Field ID data produced by the FIDL circuit can serve as the SMCI protocol control data associated with the outgoing bytes.


It should also be understood that the VRG module can be internally pipelined such that the QM circuit, the DLF circuit, the SRL circuit, and the FIDL circuit are configured to operate simultaneously in a pipelined fashion.


QRM Module:



FIG. 16 depicts an exemplary arrangement for a QRM module. The QRM module is configured to strip the quotes used as the start and end of a field as shield characters and convert two consecutive quotes into a single quote.


The quote finder logic 1600 receives the data and SMCI signal from the VRG module output, and performs matching operations on the data to locate the characters that match the quote character. If a quote character in the data stream is at the start of a field (as indicated by the SOF flag in the SMCI control data), then the quote finder logic 1600 can mark that quote character for removal. If a quote character in the data stream is at the end of a field (as indicated by the EOF flag in the SMCI control data), then the quote finder logic 1600 can also mark that quote character for removal. Furthermore, if consecutive quote characters are found in the data stream, then the quote finder logic can mark the first quote for removal. Alternatively, the quote finder logic can be configured to merely mark the locations of quote characters in the data stream.


Thus, the quote finder logic 1600 provides the data stream, its associated SMCI control data, and the quote removal markers to quote conversion logic 1602. The quote conversion logic is configured to remove the single quotes from the data stream and replace the double quotes with single quotes. A shift register repacks the data from the quote conversion logic to accommodate the quote removals. Thus, the output of the shift register comprises the data stream and its corresponding SMCI control data.


The QRM module can also be internally pipelined such that the quote finder logic 1600, the quote conversion logic 1602 and shift register operate simultaneously in a pipelined fashion.


V2F Module:



FIG. 17(a) depicts an exemplary arrangement for a V2F module. The V2F module can hold a map of field lengths to use for the fixed field format. The V2F module can use this map to fit the fields of the data stream to their appropriate length in accordance with the target fixed field format. The V2F module will pad out any field in the data stream shorter than the specification field length with a padding character, which can be a configurable special character. For ease of reference, these padding characters can be referred to as zeros for purposes of discussion. The V2F module will also output an overflow error for any field in the data stream longer than the specification field length.


The LUT stores a table of field widths that can be sent in from software. This table will thus have the length for each field as specified by software on startup. Thus, it should be understood that through these specified field lengths, each of the fields of the output fixed field formatted-data can have its own length that need not be the same length as the other fields. The index into this table represents the ID of a given field, and the value at that location represents the given field length. The last field identifier, and consequently the last populated field in the LUT, is stored in a last field identifier (max_fid) which is stored separately from the LUT. It is worth noting that some fields in this table can have a specified length of zero, meaning they are to be eliminated from output data records. (This can be used to eliminate fields that are generally not present in the input data.)


An input state machine takes in the data stream and SMCI control data from the QRM module and compares it with the field identifiers from the LUT to reconcile the incoming fields with the expected fields for each record. The start of each field for the incoming data is marked in the SMCI data by the SOF flag while the end of each field is marked in the SMCI data by the EOF flag. Further still, the Field ID of the SMCI data will identify the field to which the current data of the data stream corresponds. From this information, the input state machine can transition between states of PROCESSING, COMPLETE, and OVERFLOW. FIG. 17(b) depicts an exemplary state machine diagram for the input state machine of FIG. 17(a).


In the PROCESSING state, if the field identifier for the incoming data (fid_in) matches the field identifier for the current field from the LUT (current_fid), then the incoming data can be sent to the output state machine for processing. However, while in the PROCESSING state, if fid_in does not match current_fid (and an EOR marker is not present), then this means that a gap in the incoming fields exists, and an empty field should be sent to the output state machine for processing. The next current_fid from the LUT is then processed.


If fid_in is greater than max_fid while the input state machine is in the PROCESSING state, the state machine transitions to the OVERFLOW state. This condition indicates that the input record included more fields than expected. While in the OVERFLOW state, the input state machine sends the overflow fields to the output state machine until an EOR marker is encountered in the incoming data. Upon encountering the EOR market in the incoming data, the input state machine will transition back to the PROCESSING state.


If fid_in does not match max_fid and the EOR marker is present in the incoming data while the input state machine is in the PROCESSING state, this means that the incoming record had fewer fields than expected and we transition to the COMPLETE state. While in the COMPLETE state, the input state machine sends size zero fields to the output state machine and increments to the next current_fid from the LUT. Once current_fid reaches max_fid, the input state machine transitions back to the PROCESSING state.


The input state machine reports a data value indicative of the size of each identified field as it receives SOF markers from the input SMCI interface (current_field_size). For empty fields that are added to fill in a gap in a record, the current_field_size can be zero. For non-empty fields, a counter can be employed to identify how many bytes are present in each field (from the SOF and EOF markers in the SMCI control data associated with the incoming data).


The output state machine operates to fill fields with bytes of the incoming data or padding characters as necessary, and identify those fields which are overflowing with bytes of the incoming data as necessary. The output state machine can progress from a PROCESSING state (during which time the data stream fills the output data shift register that contains the output field) to a PADDING state (during which time padding characters are added to the output field) upon detection of a field incomplete condition. The field incomplete condition can occur if the current_field_size for an input field is less than the corresponding field length for the output field. Once the output field has been filled to the current_field_size, the output state machine can transition to the PADDING state.


While in the PADDING state, the remaining space in the output field is filled with padding characters until the padding characters added to the output field have caused the output field to reach the size of its field length. The output state machine can then return to the PROCESSING state.


The output state machine can also progress from the PROCESSING state to the OVERFLOW START state upon detection of a field overflow condition. The field overflow condition can occur if the current_field_size for an input field is greater than the corresponding field length for the output field. If this condition is detected, the output state machine can transition to the OVERFLOW START state. When in the OVERFLOW START state, an overflow start command (CMD) can be sent and the data shift register is flushed. The output state machine then progresses to the OVERFLOW state (during which time the overflow data is sent). Upon encountering the EOF flag for the overflowing field, the output state machine will progress to the OVERFLOW END state. During the OVERFLOW END state, an overflow end command (CMD) can be sent, and the shift register is flushed. Thus, overflowing fields are framed by overflow commands in the output data.


A command/data multiplexer is configured to provide either the CMDs from the output state machine or the content of the data shift register (SR) as an output. The state of the output state machine will govern which multiplexer input is passed as the multiplexer output. Thus, if the output state machine is in the OVERFLOW START or OVERFLOW END states, the multiplexer will pass command data indicative of these states to the output. While the output state machine is in the PROCESSING, PADDING, or OVERFLOW states, the multiplexer will pass the content of the output data shift register to the output. Accordingly, the V2F will output a fixed field of data when no overflows are detected. If an overflow is detected, a CMD signal frames the overflow data so that exception handling can further process the overflowing field.


Thus, the V2F module is able to deliver the data of the input byte stream 200 to the data processing stage 300 as a byte stream in a fixed field format.


Translation Engine 400:


If it is desired to translate the processed data output of the data processing stage back to a delimited data format, the translation engine 400 can be configured with a pipeline of processing modules that effectively perform the inverse of the operations performed by the pipeline of FIG. 11. FIG. 18 depicts an exemplary pipeline that can be deployed by the translation engine 400. A fixed-to-variable (F2V) module can convert the incoming data in a fixed field format to the variable format having the SMCI control protocol. A quote addition (QAD) module downstream from the F2V module can insert shield characters into the data stream at appropriate locations as per the target delimited data format. A variable inverse record gate (VIRG) module downstream form the QAD module can insert FDL and RDL characters into the data stream at appropriate locations to thereby generate an output data stream in the target delimited data format.



FIG. 19 depicts an exemplary embodiment for the F2V module. Incoming data is shifted through a shift register, and a LUT of field lengths is used to ascertain the length of each incoming field. A field creator delineates the different fields of the incoming data and generates the associated SMCI control protocol data for those fields.



FIG. 20 depicts an exemplary embodiment for the QAD module. The QAD module can inspect the incoming data for shield characters and delimiter characters to insert shield characters at appropriate locations as per the delimited data format. For example, if it detects a data character within a field that does not serve as an FDL character but matches the FDL character, the QAD module will operate to wrap that field with quote marks. The QAD module can also operate to strip the incoming data of padding characters that may have been added to the fields to fillout the fixed fields. A special character logic in the QAD module can operate to detect and mark all special characters (shield characters, FDL characters, and RDL characters) in the data stream for populating the data and header queues. A padding clipper that then culls the data stream of padding characters and shift registers can be employed to repack the outgoing data.



FIG. 21 depicts an exemplary VIRG module. The VIRG module can take in the data output from the QAD module together with the associated SMCI control data to insert actual RDL characters and FDL characters at appropriate locations in the data stream via processing logic triggered by the SMCI control data and corresponding shift registers. Thus, the output of the VIRG module will be a stream of data in the delimited data format.


Selective Enabling and Disabling of Engines and Processing Modules:


It should also be understood that command data can be inserted into the data stream to enable and disable various modules of the processing pipeline deployed by the translation engine(s) as appropriate for a processing task. For example, in an embodiment where both translation engine 202 and translation engine 400 are employed (for example in reconfigurable logic), and if the destination for the delimited data is a database, a practitioner may choose to disable the translation engine 400. The disabled translation engine 400 would thus act as a pass through while remaining instantiated on the reconfigurable logic. As another example, if the incoming delimited data does not include shield characters, command data can be employed to disable the QM circuit of the VRG module and the QRM module. Such disabled modules would thus act as pass through components while remaining instantiated on the reconfigurable logic.



FIG. 22 depicts an exemplary arrangement for a processing module to support a selective enabling/disabling functionality. The module 2200 of FIG. 22 can include a command parser block, a logic block downstream from the command parser block, and a stream merge block downstream from the command parser block and the logic block.


The command parser block operates to receive the incoming data stream (which in this example is incoming data and associated SMCI control protocol; however, this need not be the case) and interpret the content of that stream to determine whether the incoming data is to be processed by the logic block or to bypass the logic block. Two criteria can determine whether data or commands will be processed by a module. For commands specifically, a module ID is present in a command to denote which specific module the command targets. There can be a special case for a module ID of zero that denotes the command applies to the entire chain. In addition to command routing, a context identifier can be used to denote which stream of data is currently being processed. Different modules can be bound to different contexts or streams.


Command messages are used to toggle the “plumbing” of a given module chain, turning modules ON or OFF (pass through) for a given context, and are used to mark changes in the active context. As a result, commands are sent through to set up the active data routes for a context and are used to denote which context is active. After the command setup, data will be processed by that configured chain until new commands arrive to enable/disable modules or toggle a context switch.


The command parser is responsible for inspecting command headers to note whether or not the command is intended for the given module, and it is responsible for following context switching commands that denote the active context.


When the module is in pass through, or is observing data from a context for which it is not bound, all data will be sent through the bypass channel 2202 rather than through the logic block. To disable an entire engine (such as translation engine 400), all of the modules that make up that engine can be disabled.


The logic block can implement any of the processing tasks described herein for the translation engine (e.g., the VRG module, the QM circuit, the V2F module, etc.).


The stream merge block operates to merge the output of the logic block and the information on the bypass channel to generate an output from the module. Data from the bypass channel will be given precedence over data from the logic block (if both are available), and the stream merge block is responsible for ensuring that data and commands are merged in on proper data boundaries.


The exemplary embodiments described herein can be used for a wide array of data processing tasks where performing data translations at low latency and high throughput are desired. Any enterprise in which data in a delimited format is widely used as the mode of communicating data records from location to location is expected to greatly benefit from use of the disclosed embodiments. For example, medical records and health care data are often communicated via a delimited data format and would benefit from improvements in how such data is processed (particularly in connection with data quality checking operations and database ETL operations).


While the present invention has been described above in relation to its exemplary embodiments, various modifications may be made thereto that still fall within the invention's scope. Such modifications to the invention will be recognizable upon review of the teachings herein. Accordingly, the full scope of the present invention is to be defined by the appended claims and their legal equivalents.

Claims
  • 1. A method comprising: receiving data in a delimited data format, wherein the received data in the delimited data format comprises (1) a plurality of data characters arranged in a plurality of fields, (2) a plurality of shield characters, and (3) a plurality of field delimiter characters, the field delimiter characters defining a plurality of boundaries between the fields;converting the received data to a fixed field format, wherein the converting step comprises the reconfigurable logic device (1) distinguishing between field delimiter characters and data characters in the received data based on the shield characters, (2) identifying the fields in the received data based on the field delimiter characters, and (3) arranging the data characters sharing the same identified fields into fixed-size fields such that the converted data comprises the data characters in the fixed-size fields stripped of the field delimiter characters and the shield characters;performing a plurality of processing operations on the converted data to generate processed data in the fixed field format;loading the processed data into a database; andwherein the converting step is performed by a reconfigurable logic device.
  • 2. The method of claim 1 wherein the converted data comprises a plurality of data fields, each data field having a known field length, wherein the processing operations comprise a plurality of field-specific data processing operations, and wherein the performing step comprises targeting a specific field of the converted data for a field-specific processing operation without analyzing the data content of the data fields.
  • 3. The method of claim 1 wherein the data processing operations comprise data quality checking operations as part of an extract, transfer, load (ETL) procedure.
  • 4. The method of claim 1 wherein the at least one of the processing operations is performed by software executed by a processor.
  • 5. The method of claim 1 wherein the converting step comprises converting a plurality of characters of the received data to the fixed field format per clock cycle.
  • 6. The method of claim 1 wherein the at least one of the processing operations is performed by a reconfigurable logic device.
  • 7. A method comprising: a reconfigurable logic device receiving an incoming stream comprising a plurality of bytes arranged in a delimited data format, the incoming byte stream being representative of data arranged in a plurality of fields, wherein the received byte stream comprises a plurality of data characters, a plurality of field delimiter characters, and a plurality of shield characters, the field delimiter characters defining a plurality of boundaries between the fields;the reconfigurable logic device processing the received byte stream, wherein the processing step comprises: the reconfigurable logic device distinguishing between field delimiter characters and data characters in the received byte stream based on the shield characters to identify the field delimiter characters that are present in the received byte stream; andthe reconfigurable logic device identifying the fields in the received byte stream based on the identified field delimiter characters; andthe reconfigurable logic device translating the received byte stream to an outgoing byte stream arranged in a fixed field format based on the identified field delimiter characters, the outgoing byte stream comprising a plurality of the data characters of the received byte stream arranged in a plurality of fixed-size fields, and wherein the translating step comprises the reconfigurable logic device arranging the data characters sharing the same identified field into the fixed-size fields such that the outgoing byte stream comprises the data characters in the fixed-size fields stripped of the field delimiter characters and the shield characters.
  • 8. The method of claim 7wherein the processing step further comprises the reconfigurable logic device identifying the shield characters that are present in the received byte stream.
  • 9. The method of claim 8 wherein the translating step comprises the reconfigurable logic device removing the identified field delimiter characters from the outgoing byte stream.
  • 10. The method of claim 9 wherein the translating step further comprises the reconfigurable logic device removing the identified shield characters from the outgoing byte stream.
  • 11. The method of claim 8 further comprising the reconfigurable logic device converting the received byte stream to an internal format tagged with associated control data that identifies the boundaries between the fields.
  • 12. The method of claim 11 wherein the converting step further comprises the reconfigurable logic device generating a shield character mask associated with the received byte stream to identify the bytes in the received byte stream that are eligible for consideration as to whether they contain a field delimiter character.
  • 13. The method of claim 12 wherein the converting step further comprises the reconfigurable logic device processing the bytes of the received byte stream and the generated shield character mask to generate field delimiter flag data associated with the received byte stream, the field delimiter flag data being indicative of whether an associated byte corresponds to a field delimiter character.
  • 14. The method of claim 13 wherein the incoming byte stream is further representative of a plurality of records, at least one of the records comprising at least one of the fields, the incoming byte stream further comprising a plurality of record delimiter characters, the record delimiter characters defining a plurality of boundaries between the records, and wherein the converting step further comprises the reconfigurable logic device processing the bytes of the received byte stream and the generated shield character mask to generate record delimiter flag data associated with the received byte stream, the record delimiter flag data being indicative of whether an associated byte corresponds to a record delimiter character.
  • 15. The method of claim 14 wherein the converting step further comprises the reconfigurable logic device identifying any empty fields that exist within the received byte stream based on the field delimiter flag data and the record delimiter flag data.
  • 16. The method of claim 15 wherein the converting step further comprises the reconfigurable logic device removing the field delimiter characters and the record delimiter characters from the internally formatted byte stream based on the field delimiter flag data and the record delimiter flag data.
  • 17. The method of claim 16 wherein the converting step further comprises the reconfigurable logic device generating control data associated with the internally formatted byte stream, the control data comprising (1) a start of field flag, (2) an end of field flag, (3) a start of record flag, (4) an end of record flag, and (5) a field identifier.
  • 18. The method of claim 11 wherein the shield character identifying step further comprises the reconfigurable logic device performing a shield character removal operation on the bytes of the received byte stream.
  • 19. The method of claim 18 wherein the shield character removal performing step comprises the reconfigurable logic device (1) distinguishing between the data characters that match the shield character and the shield characters, and (2) removing the identified shield characters.
  • 20. The method of claim 11 further comprising the reconfigurable logic device generating the outgoing byte stream in the fixed field format from the internally formatted byte stream and the associated control data.
  • 21. The method of claim 20 wherein the generating step further comprises the reconfigurable logic device filling a register corresponding to a fixed length field with the data characters of a field of the internally formatted byte stream based on the associated control data.
  • 22. The method of claim 21 wherein the generating step further comprises the reconfigurable logic device filling the register with padding characters if there are not enough data characters of the field of the internally formatted byte stream to complete the fixed length field.
  • 23. The method of claim 18 further comprising: the reconfigurable logic device providing the outgoing byte stream to a data processing component for processing thereby; andthe data processing component selectively targeting a field of the outgoing byte stream for processing without analyzing the data characters of the outgoing byte stream.
  • 24. The method of claim 23 further comprising: the reconfigurable logic device receiving processed data representative of the outgoing byte stream from the data processing component; andthe reconfigurable logic device translating the processed data back to the delimited data format.
  • 25. The method of claim 8 further comprising: the reconfigurable logic device converting the received byte stream to an internal format tagged with associated control data that identifies the boundaries between the fields;the reconfigurable logic device performing a shield character removal operation on the bytes of the received byte stream; andthe reconfigurable logic device generating the outgoing byte stream in the fixed field format from the internally formatted byte stream and the associated control data; andwherein the reconfigurable logic device performs the converting step, the shield character removal performing step, and the generating step simultaneously with respect to each other in a pipelined fashion.
  • 26. The method of claim 7 wherein the reconfigurable logic device performs the processing and translating steps for a plurality of characters in the byte stream per clock cycle.
  • 27. The method of claim 7 wherein the delimited data format comprises a comma separated value (CSV) format.
  • 28. The method of claim 7 further comprising: selectively targeting a field of the outgoing byte stream for processing without analyzing the data characters of the outgoing byte stream; andperforming a processing operation on the selectively targeted field; andwherein the selectively targeting and performing steps are performed by a processor downstream from the reconfigurable logic device.
  • 29. The method of claim 7 wherein the reconfigurable logic device comprises a field programmable gate array (FPGA).
  • 30. An apparatus comprising: a reconfigurable logic device configured to (1) receive an incoming stream comprising a plurality of bytes arranged in a delimited data format, the incoming byte stream being representative of data arranged in a plurality of fields, wherein the received byte stream comprises a plurality of data characters, a plurality of field delimiter characters, and a plurality of shield characters,the field delimiter characters defining a plurality of boundaries between the fields, (2) process the received byte stream to (i) distinguish between field delimiter characters and data characters in the received byte stream based on the shield characters to identify the field delimiter characters that are present in the received byte stream, and (ii) identify the fields in the received byte stream based on the identified field delimiter characters, and (3) translate the received byte stream to an outgoing byte stream arranged in a fixed field format based on the identified field delimiter characters, the outgoing byte stream comprising a plurality of the data characters of the received byte stream arranged in a plurality of fixed-size fields, wherein as part of the translation the reconfigurable logic device is further configured to arrange the data characters sharing the same identified field into the fixed-size fields such that the outgoing byte stream comprises the data characters in the fixed-size fields stripped of the field delimiter characters and the shield characters.
  • 31. The apparatus of claim 30 wherein the reconfigurable logic device comprises: a plurality of hardware logic circuits arranged in a pipeline, the hardware logic circuits configured to operate simultaneously in a pipelined fashion, the pipeline configured to perform the receive, process, and translate operations.
  • 32. The apparatus of claim 31 wherein the pipeline comprises: a first hardware logic circuit configured to convert the received byte stream to an internal variable format having associated control data to identify records and fields in the data;a second hardware logic circuit downstream from the first hardware logic circuit, the second hardware logic circuit configured to remove shield characters from the data in the internal variable format; anda third hardware logic circuit downstream from the second hardware logic circuit, the third hardware logic circuit configured to convert the data in the variable format into the outgoing byte stream in the fixed field format.
  • 33. The apparatus of claim 32 wherein the first hardware logic circuit is further configured to simultaneously test the same portion of the received byte stream to determine whether the tested stream portion comprises record delimiters or field delimiters.
  • 34. The apparatus of claim 31 wherein the pipeline is further configured to ingest and process a plurality of characters of the received byte stream per clock cycle.
  • 35. The apparatus of claim 32 wherein the received byte stream is further representative of a plurality of fields arranged in a plurality of records and further comprises a plurality of record delimiter characters, the record delimiter characters defining a plurality of boundaries between the records; and wherein the first hardware logic circuit is further configured to strip the field delimiter characters and record delimiter characters of the incoming stream from the converted data while preserving data characters of incoming fields in the converted data.
  • 36. The apparatus of claim 35 wherein the first hardware logic circuit is further configured to simultaneously test the same characters of the incoming stream to determine whether the tested characters are record delimiter characters or field delimiter characters.
  • 37. The apparatus of claim 30 wherein the reconfigurable logic device comprises: a variable record gate hardware logic circuit configured to convert the received byte stream to an internal variable format having associated control data to identify records and fields in the received byte stream.
  • 38. The apparatus of claim 30 wherein the reconfigurable logic device comprises: a shield character masker hardware logic circuit configured to mask fields of the received byte stream that are wrapped by shield characters.
  • 39. The apparatus of claim 38 wherein the reconfigurable logic device further comprises: a delimiter finder hardware logic circuit downstream from the shield character masker hardware logic circuit, the delimiter finder hardware logic circuit configured to detect delimiter characters in the received byte stream based on a mask generated by the shield character masker hardware logic circuit.
  • 40. The apparatus of claim 39 wherein the delimiter characters comprise field delimiter characters.
  • 41. The apparatus of claim 39 wherein the delimiter characters comprise record delimiter characters.
  • 42. The apparatus of claim 30 wherein the reconfigurable logic device comprises: a delimiter finder hardware logic circuit configured to detect delimiter characters in the received byte stream.
  • 43. The apparatus of claim 42 wherein the delimiter characters comprise field delimiter characters.
  • 44. The apparatus of claim 42 wherein the delimiter characters comprise record delimiter characters.
  • 45. The apparatus of claim 42 wherein the delimiter characters comprise field delimiter characters and record delimiter characters; and wherein the delimiter finder hardware logic circuit is further configured to simultaneously test whether the same portion of the received byte stream includes field delimiter characters or record delimiter characters.
  • 46. The apparatus of claim 30 further comprising: a processor, the processor configured to (1) selectively target a field of the outgoing byte stream for processing without analyzing the data characters of the outgoing byte stream, and (2) perform a processing operation on the selectively targeted field.
  • 47. The apparatus of claim 30 wherein the reconfigurable logic device comprises a field programmable gate array (FPGA).
  • 48. A method comprising: a reconfigurable logic device receiving an incoming stream comprising a plurality of bytes arranged in a delimited data format, the incoming byte stream being representative of data arranged in a plurality of fields, wherein the received byte stream comprises a plurality of data characters, a plurality of field delimiter characters, and a plurality of shield characters, the field delimiter characters defining a plurality of boundaries between the fields;the reconfigurable logic device processing the received byte stream to identify the field delimiter characters that are present in the received byte stream, wherein the processing step comprises: the reconfigurable logic device distinguishing between field delimiter characters and data characters in the received byte stream based on the shield characters; andthe reconfigurable logic device identifying the fields in the received byte stream based on the identified field delimiter characters; andthe reconfigurable logic device translating the received byte stream to an outgoing byte stream based on the identified field delimiter characters, the outgoing byte stream arranged in a structured format and being representative of the data in the fields of the received byte stream, the outgoing byte stream comprising a plurality of the data characters of the received byte stream, the structured format being configured to permit a downstream processing component to jump from field to field in the outgoing byte stream without analyzing the data characters of the outgoing byte stream, and wherein the translating step comprises the reconfigurable logic device arranging the data characters sharing the same identified field into fields of the structured format such that the outgoing byte stream comprises the data characters in the fields of the structured format stripped of the field delimiter characters and the shield characters.
  • 49. The method of claim 48 wherein the incoming byte stream is further representative of a plurality of records, at least one of the records comprising at least one of the fields, the incoming byte stream further comprising a plurality of record delimiter characters, the record delimiter characters defining a plurality of boundaries between the records; wherein the processing step further comprises the reconfigurable logic device identifying the record delimiter characters that are present in the received byte stream; andwherein the translating step further comprises the reconfigurable logic device translating the received byte stream to the outgoing byte stream having the structured format based on the identified field delimiter characters and the identified record delimiter characters.
  • 50. The method of claim 48 wherein the structured format is further configured to permit the downstream processing component to jump from record to record in the outgoing byte stream without analyzing the data characters of the outgoing byte stream.
  • 51. The method of claim 49 wherein the translating step further comprises the reconfigurable logic device removing the identified record delimiter characters from the outgoing byte stream.
  • 52. The method of claim 48wherein the processing step further comprises the reconfigurable logic device identifying the shield characters that are present in the received byte stream.
  • 53. The method of claim 52 wherein the translating step further comprises the reconfigurable logic device removing the identified shield characters from the outgoing byte stream.
  • 54. The method of claim 48 wherein the translating step further comprises removing the identified field delimiter characters from the outgoing byte stream.
  • 55. The method of claim 48 further comprising the reconfigurable logic device providing the outgoing byte stream to the downstream processing component for processing thereby.
  • 56. The method of claim 48 further comprising the downstream processing component performing a plurality of processing operations on the outgoing byte stream to generate processed data from the outgoing byte stream.
  • 57. The method of claim 56 wherein the processing operations include a plurality of extract, transfer, and load (ETL) database operations.
  • 58. The method of claim 56 wherein the processing operations comprise a plurality of data validation operations.
  • 59. The method of claim 48 further comprising the reconfigurable logic device translating the processed data back to the delimited data format of the received byte stream.
  • 60. The method of claim 48 wherein the downstream processing component is implemented on the reconfigurable logic device.
  • 61. The method of claim 48 wherein the downstream processing component is implemented in software on a processor.
  • 62. The method of claim 48 wherein the delimited data format comprises a comma separated value (CSV) format.
  • 63. The method of claim 48 wherein the structured format comprises a fixed field format.
  • 64. The method of claim 48 wherein the reconfigurable logic device performs the processing and translating steps for a plurality of characters in the byte stream per clock cycle.
  • 65. The method of claim 48 further comprising: a processor downstream from the reconfigurable logic device (1) selectively jumping to a field in the outgoing byte stream without analyzing the data characters of the outgoing byte stream, (2) performing a processing operation on that field after jumping thereto, and (3) repeating the selectively jumping and performing steps for a plurality of the fields in the outgoing byte stream.
  • 66. The method of claim 48 wherein the reconfigurable logic device comprises a field programmable gate array (FPGA).
CROSS-REFERENCE AND PRIORITY CLAIM TO RELATED PATENT APPLICATION

This patent application claims priority to U.S. provisional patent application Ser. No. 61/717,496, filed Oct. 23, 2012, and entitled “Method and Apparatus for Accelerated Format Translation of Data in a Delimited Data Format”, the entire disclosure of which is incorporated herein by reference.

US Referenced Citations (321)
Number Name Date Kind
3601808 Vlack Aug 1971 A
3611314 Pritchard, Jr. et al. Oct 1971 A
3729712 Glassman Apr 1973 A
3824375 Gross et al. Jul 1974 A
3848235 Lewis et al. Nov 1974 A
3906455 Houston et al. Sep 1975 A
4081607 Vitols et al. Mar 1978 A
4298898 Cardot Nov 1981 A
4314356 Scarbrough Feb 1982 A
4385393 Chaure et al. May 1983 A
4464718 Dixon et al. Aug 1984 A
4550436 Freeman et al. Oct 1985 A
4823306 Barbic et al. Apr 1989 A
4941178 Chuang Jul 1990 A
5023910 Thomson Jun 1991 A
5050075 Herman et al. Sep 1991 A
5101424 Clayton et al. Mar 1992 A
5140692 Morita Aug 1992 A
5161103 Kosaka et al. Nov 1992 A
5163131 Row et al. Nov 1992 A
5179626 Thomson Jan 1993 A
5226165 Martin Jul 1993 A
5243655 Wang Sep 1993 A
5249292 Chiappa Sep 1993 A
5255136 Machado et al. Oct 1993 A
5263156 Bowen et al. Nov 1993 A
5265065 Turtle Nov 1993 A
5267148 Kosaka et al. Nov 1993 A
5313560 Maruoka et al. May 1994 A
5319776 Hile et al. Jun 1994 A
5327521 Savic et al. Jul 1994 A
5339411 Heaton, Jr. Aug 1994 A
5347634 Herrell et al. Sep 1994 A
5371794 Diffie et al. Dec 1994 A
5388259 Fleischman et al. Feb 1995 A
5396253 Chia Mar 1995 A
5404411 Banton et al. Apr 1995 A
5404488 Kerrigan et al. Apr 1995 A
5418951 Damashek May 1995 A
5421028 Swanson May 1995 A
5432822 Kaewell, Jr. Jul 1995 A
5440723 Arnold et al. Aug 1995 A
5461712 Chelstowski et al. Oct 1995 A
5463701 Kantner, Jr. et al. Oct 1995 A
5465353 Hull et al. Nov 1995 A
5481735 Mortensen et al. Jan 1996 A
5488725 Turtle et al. Jan 1996 A
5497488 Akizawa et al. Mar 1996 A
5517642 Bezek et al. May 1996 A
5544352 Egger Aug 1996 A
5546578 Takada et al. Aug 1996 A
5651125 Witt et al. Jul 1997 A
5687297 Coonan et al. Nov 1997 A
5701464 Aucsmith Dec 1997 A
5704060 Del Monte Dec 1997 A
5712942 Jennings et al. Jan 1998 A
5721898 Beardsley et al. Feb 1998 A
5740466 Geldman et al. Apr 1998 A
5774835 Ozawa et al. Jun 1998 A
5774839 Shlomot Jun 1998 A
5781772 Wilkinson, III et al. Jul 1998 A
5781921 Nichols Jul 1998 A
5805832 Brown et al. Sep 1998 A
5813000 Furlani Sep 1998 A
5819273 Vora et al. Oct 1998 A
5819290 Fujita et al. Oct 1998 A
5826075 Bealkowski et al. Oct 1998 A
5864738 Kessler et al. Jan 1999 A
5870730 Furuya et al. Feb 1999 A
5886701 Chauvin et al. Mar 1999 A
5913211 Nitta Jun 1999 A
5930753 Potamianos et al. Jul 1999 A
5943421 Grabon Aug 1999 A
5943429 Händel Aug 1999 A
5978801 Yuasa Nov 1999 A
5987432 Zusman et al. Nov 1999 A
5991881 Conklin et al. Nov 1999 A
5995963 Nanba et al. Nov 1999 A
6006264 Colby et al. Dec 1999 A
6023760 Karttunen Feb 2000 A
6028939 Yin Feb 2000 A
6044407 Jones et al. Mar 2000 A
6058391 Gardner May 2000 A
6064739 Davis May 2000 A
6067569 Khaki et al. May 2000 A
6070172 Lowe May 2000 A
6073160 Grantham et al. Jun 2000 A
6105067 Batra Aug 2000 A
6134551 Aucsmith Oct 2000 A
6138176 McDonald et al. Oct 2000 A
RE36946 Diffie et al. Nov 2000 E
6147976 Shand et al. Nov 2000 A
6169969 Cohen Jan 2001 B1
6175874 Imai et al. Jan 2001 B1
6226676 Crump et al. May 2001 B1
6236980 Reese May 2001 B1
6279113 Vaidya Aug 2001 B1
6317795 Malkin et al. Nov 2001 B1
6336150 Ellis et al. Jan 2002 B1
6339819 Huppenthal et al. Jan 2002 B1
6370645 Lee et al. Apr 2002 B1
6377942 Hinsley et al. Apr 2002 B1
6381242 Maher, III et al. Apr 2002 B1
6389532 Gupta et al. May 2002 B1
6397259 Lincke et al. May 2002 B1
6397335 Franczek et al. May 2002 B1
6412000 Riddle et al. Jun 2002 B1
6430272 Maruyama et al. Aug 2002 B1
6456632 Baum et al. Sep 2002 B1
6463474 Fuh et al. Oct 2002 B1
6499107 Gleichauf et al. Dec 2002 B1
6535868 Galeazzi et al. Mar 2003 B1
6564263 Bergman et al. May 2003 B1
6578147 Shanklin et al. Jun 2003 B1
6625150 Yu Sep 2003 B1
6704816 Burke Mar 2004 B1
6711558 Indeck et al. Mar 2004 B1
6765918 Dixon et al. Jul 2004 B1
6772345 Shetty Aug 2004 B1
6785677 Fritchman Aug 2004 B1
6804667 Martin Oct 2004 B1
6807156 Veres et al. Oct 2004 B1
6839686 Galant Jan 2005 B1
6850906 Chadha et al. Feb 2005 B1
6870837 Ho et al. Mar 2005 B2
6877044 Lo et al. Apr 2005 B2
6886103 Brustoloni et al. Apr 2005 B1
6901461 Bennett May 2005 B2
6931408 Adams et al. Aug 2005 B2
6931545 Ta et al. Aug 2005 B1
6944168 Paatela et al. Sep 2005 B2
6978223 Milliken Dec 2005 B2
6980976 Alpha et al. Dec 2005 B2
6981054 Krishna Dec 2005 B1
7019674 Cadambi et al. Mar 2006 B2
7046848 Olcott May 2006 B1
7093023 Lockwood et al. Aug 2006 B2
7127424 Kemp, II et al. Oct 2006 B2
7139743 Indeck et al. Nov 2006 B2
7149715 Browne et al. Dec 2006 B2
7167980 Chiu Jan 2007 B2
7177833 Marynowski et al. Feb 2007 B1
7181437 Indeck et al. Feb 2007 B2
7181608 Fallon et al. Feb 2007 B2
7222114 Chan et al. May 2007 B1
7224185 Campbell et al. May 2007 B2
7225188 Gai et al. May 2007 B1
7251629 Marynowski et al. Jul 2007 B1
7287037 An et al. Oct 2007 B2
7305383 Kubesh et al. Dec 2007 B1
7305391 Wyschogrod et al. Dec 2007 B2
7363277 Dutta et al. Apr 2008 B1
7386564 Abdo et al. Jun 2008 B2
7408932 Kounavis et al. Aug 2008 B2
7411957 Stacy et al. Aug 2008 B2
7420931 Nanda et al. Sep 2008 B2
7444515 Dharmapurikar et al. Oct 2008 B2
7454418 Wang Nov 2008 B1
7457834 Jung et al. Nov 2008 B2
7461064 Fontoura et al. Dec 2008 B2
7467155 McCool et al. Dec 2008 B2
7478431 Nachenberg Jan 2009 B1
7480253 Allan Jan 2009 B1
7487327 Chang et al. Feb 2009 B1
7496108 Biran et al. Feb 2009 B2
7552107 Indeck et al. Jun 2009 B2
7558925 Bouchard et al. Jul 2009 B2
7565525 Vorbach et al. Jul 2009 B2
7636703 Taylor Dec 2009 B2
7660793 Indeck et al. Feb 2010 B2
7680790 Indeck et al. Mar 2010 B2
7685121 Brown et al. Mar 2010 B2
7685254 Pandya Mar 2010 B2
7701945 Roesch et al. Apr 2010 B2
7702629 Cytron et al. Apr 2010 B2
7783862 Cameron Aug 2010 B2
7805392 Steele et al. Sep 2010 B1
7840482 Singla et al. Nov 2010 B2
7917299 Buhler et al. Mar 2011 B2
7921046 Parsons et al. Apr 2011 B2
7945528 Cytron et al. May 2011 B2
7949650 Indeck et al. May 2011 B2
8095508 Chamberlain et al. Jan 2012 B2
8374986 Indeck et al. Feb 2013 B2
8407588 Hu et al. Mar 2013 B1
8620881 Chamberlain et al. Dec 2013 B2
8751452 Chamberlain et al. Jun 2014 B2
8768888 Chamberlain et al. Jul 2014 B2
9176775 Chamberlain et al. Nov 2015 B2
20010013048 Imbert de Tremiolles et al. Aug 2001 A1
20010014093 Yoda et al. Aug 2001 A1
20010052038 Fallon et al. Dec 2001 A1
20010056547 Dixon Dec 2001 A1
20020031125 Sato Mar 2002 A1
20020069370 Mack Jun 2002 A1
20020091691 Sharp Jul 2002 A1
20020095512 Rana et al. Jul 2002 A1
20020103663 Bankier et al. Aug 2002 A1
20020105911 Pruthi et al. Aug 2002 A1
20020129140 Peled et al. Sep 2002 A1
20020150248 Kovacevic Oct 2002 A1
20020162025 Sutton et al. Oct 2002 A1
20020166063 Lachman et al. Nov 2002 A1
20030009693 Brock et al. Jan 2003 A1
20030014521 Elson et al. Jan 2003 A1
20030014662 Gupta et al. Jan 2003 A1
20030018630 Indeck et al. Jan 2003 A1
20030023876 Bardsley et al. Jan 2003 A1
20030037037 Adams et al. Feb 2003 A1
20030043805 Graham et al. Mar 2003 A1
20030051043 Wyschogrod et al. Mar 2003 A1
20030065943 Geis et al. Apr 2003 A1
20030074582 Patel et al. Apr 2003 A1
20030110229 Kulig et al. Jun 2003 A1
20030115485 Milliken Jun 2003 A1
20030163715 Wong Aug 2003 A1
20030169877 Liu et al. Sep 2003 A1
20030177253 Schuehler et al. Sep 2003 A1
20030221013 Lockwood et al. Nov 2003 A1
20040019703 Burton Jan 2004 A1
20040028047 Hou et al. Feb 2004 A1
20040049596 Schuehler et al. Mar 2004 A1
20040054924 Chuah et al. Mar 2004 A1
20040064737 Milliken et al. Apr 2004 A1
20040100977 Suzuki et al. May 2004 A1
20040111632 Halperin Jun 2004 A1
20040117645 Okuda et al. Jun 2004 A1
20040162826 Wyschogrod et al. Aug 2004 A1
20040177340 Hsu et al. Sep 2004 A1
20040186804 Chakraborty et al. Sep 2004 A1
20040186814 Chalermkraivuth et al. Sep 2004 A1
20040196905 Yamane et al. Oct 2004 A1
20040199448 Chalermkraivuth et al. Oct 2004 A1
20040205149 Dillon et al. Oct 2004 A1
20050005145 Teixeira Jan 2005 A1
20050086520 Dharmapurikar et al. Apr 2005 A1
20050131790 Benzschawel et al. Jun 2005 A1
20050175010 Wilson et al. Aug 2005 A1
20050187844 Chalermkraivuth et al. Aug 2005 A1
20050187845 Eklund et al. Aug 2005 A1
20050187846 Subbu et al. Aug 2005 A1
20050187847 Bonissone et al. Aug 2005 A1
20050187848 Bonissone et al. Aug 2005 A1
20050187849 Bollapragada et al. Aug 2005 A1
20050187974 Gong Aug 2005 A1
20050195832 Dharmapurikar et al. Sep 2005 A1
20050229254 Singh et al. Oct 2005 A1
20060020715 Jungck Jan 2006 A1
20060031154 Noviello et al. Feb 2006 A1
20060031156 Noviello et al. Feb 2006 A1
20060031263 Arrouye et al. Feb 2006 A1
20060031737 Chugg et al. Feb 2006 A1
20060036693 Hulten et al. Feb 2006 A1
20060047636 Mohania et al. Mar 2006 A1
20060053295 Madhusudan et al. Mar 2006 A1
20060059213 Evoy Mar 2006 A1
20060129745 Thiel et al. Jun 2006 A1
20060198375 Baik et al. Sep 2006 A1
20060242123 Williams, Jr. Oct 2006 A1
20060259417 Marynowski et al. Nov 2006 A1
20060269148 Farber et al. Nov 2006 A1
20060294059 Chamberlain et al. Dec 2006 A1
20070011175 Langseth et al. Jan 2007 A1
20070011183 Langseth et al. Jan 2007 A1
20070011317 Brandyburg et al. Jan 2007 A1
20070011687 Ilik et al. Jan 2007 A1
20070061594 Ginter et al. Mar 2007 A1
20070067108 Buhler et al. Mar 2007 A1
20070067481 Sharma et al. Mar 2007 A1
20070078837 Indeck et al. Apr 2007 A1
20070094199 Deshpande et al. Apr 2007 A1
20070112748 Angell et al. May 2007 A1
20070112837 Houh et al. May 2007 A1
20070118500 Indeck et al. May 2007 A1
20070130140 Cytron et al. Jun 2007 A1
20070156574 Marynowski et al. Jul 2007 A1
20070156669 Marchisio et al. Jul 2007 A1
20070174841 Chamberlain et al. Jul 2007 A1
20070179935 Lee et al. Aug 2007 A1
20070209068 Ansari et al. Sep 2007 A1
20070237327 Taylor et al. Oct 2007 A1
20070244859 Trippe et al. Oct 2007 A1
20070260602 Taylor Nov 2007 A1
20070277036 Chamberlain et al. Nov 2007 A1
20070294157 Singla et al. Dec 2007 A1
20080005062 Gupta et al. Jan 2008 A1
20080021874 Dahl et al. Jan 2008 A1
20080030383 Cameron Feb 2008 A1
20080077582 Reed Mar 2008 A1
20080084573 Horowitz et al. Apr 2008 A1
20080086274 Chamberlain et al. Apr 2008 A1
20080104542 Cohen et al. May 2008 A1
20080109413 Indeck et al. May 2008 A1
20080114724 Indeck et al. May 2008 A1
20080114725 Indeck et al. May 2008 A1
20080114760 Indeck et al. May 2008 A1
20080126320 Indeck et al. May 2008 A1
20080133453 Indeck et al. Jun 2008 A1
20080133519 Indeck et al. Jun 2008 A1
20080243675 Parsons et al. Oct 2008 A1
20080307435 Rehman Dec 2008 A1
20090007197 Turner Jan 2009 A1
20090182683 Taylor et al. Jul 2009 A1
20090262741 Jungck et al. Oct 2009 A1
20090287628 Indeck et al. Nov 2009 A1
20090300054 Fisher et al. Dec 2009 A1
20100094858 Indeck et al. Apr 2010 A1
20100145902 Boyan et al. Jun 2010 A1
20100198850 Cytron et al. Aug 2010 A1
20100284532 Burnett et al. Nov 2010 A1
20110040701 Singla et al. Feb 2011 A1
20110078109 Griggs et al. Mar 2011 A1
20110123021 Tepper May 2011 A1
20120114119 Ahuja May 2012 A1
20120311411 Kirkpatrick Dec 2012 A1
20130151458 Indeck et al. Jun 2013 A1
20140114929 Henrichs et al. Apr 2014 A1
20140279864 Lopyrev et al. Sep 2014 A1
20150310077 Lancaster et al. Oct 2015 A1
20150310078 Lancaster et al. Oct 2015 A1
20150310087 Tidwell et al. Oct 2015 A1
Foreign Referenced Citations (44)
Number Date Country
0573991 Dec 1993 EP
0880088 Nov 1996 EP
0851358 Jul 1998 EP
0887723 Dec 1998 EP
0911738 Apr 1999 EP
02136900 May 1990 JP
03014075 Jan 1991 JP
09145544 Jun 1997 JP
2000286715 Oct 2000 JP
2001357048 Dec 2001 JP
2002101089 Apr 2002 JP
9010910 Sep 1990 WO
9409443 Apr 1994 WO
9737735 Oct 1997 WO
9905814 Feb 1999 WO
0041136 Jul 2000 WO
0122425 Mar 2001 WO
0139577 Jun 2001 WO
0161913 Aug 2001 WO
0180082 Oct 2001 WO
0180558 Oct 2001 WO
02061525 Aug 2002 WO
02082271 Oct 2002 WO
03100650 Apr 2003 WO
03036845 May 2003 WO
2004017604 Feb 2004 WO
2004042560 May 2004 WO
2004042561 May 2004 WO
2004042562 May 2004 WO
2004042574 May 2004 WO
2005017708 Feb 2005 WO
2005026925 Mar 2005 WO
2005048134 May 2005 WO
2006023948 Mar 2006 WO
2006096324 Sep 2006 WO
2007064685 Jun 2007 WO
2007087507 Aug 2007 WO
2008063973 May 2008 WO
2008063974 May 2008 WO
2009029842 Mar 2009 WO
2009089467 Jul 2009 WO
2009140363 Nov 2009 WO
2014066416 May 2014 WO
2015164639 Oct 2015 WO
Non-Patent Literature Citations (170)
Entry
International Search Report and Written Opinion for PCT/US2013/066224 dated Jan. 16, 2014.
Taylor, “Models, Algorithms, and Architectures for Scalable Packet Classification”, doctoral thesis, Department of Computer Science and Engineering, Washington University, St. Louis, MO, Aug. 2004, pp. 1-201.
Thomson Reuters, “Mellanox InfiniBand Accelerates the Exegy Ticker Plant at Major Exchanges”, Jul. 22, 2008, URL: http://www.reuters.com/article/pressRelease/idUS125385+22-Jul-2008+BW20080722.
Uluski et al., “Characterizing Antivirus Workload Execution”, SIGARCH Comput. Archit. News, vol. 33, No. 1, pp. 90-98, Mar. 2005.
Villasenor et al., “Configurable Computing Solutions for Automatic Target Recognition”, FPGAS for Custom Computing Machines, 1996, Proceedings, IEEE Symposium on Napa Valley, CA, Apr. 17-19, 1996, pp. 70-79, 1996 IEEE, Napa Valley, CA, Los Alamitos, CA, USA.
Waldvogel et al., “Scalable High-Speed Prefix Matching”, ACM Transactions on Computer Systems, Nov. 2001, pp. 440-482, vol. 19, No. 4.
Ward et al., “Dynamically Reconfigurable Computing: A Novel Computation Technology with Potential to Improve National Security Capabilities”, May 15, 2003, A White Paper Prepared by Star Bridge Systems, Inc. [retrieved Dec. 12, 2006]. Retrieved from the Internet: <URL: http://www.starbridgesystems.com/resources/whitepapers/Dynamically%20Reconfigurable%20Computing.pdf.
Weaver et al., “Very Fast Containment of Scanning Worms”, Proc. USENIX Security Symposium 2004, San Diego, CA, Aug. 2004, located at http://www.icsi.berkely.edu/˜nweaver/containment/containment.pdf.
Web-Pop (Professional Options Package) (www.pmpublishing.com).
West et al., “An FPGA-Based Search Engine for Unstructured Database”, Proc. of 2nd Workshop on Application Specific Processors, Dec. 2003, San Diego, CA.
Wooster et al., “HTTPDUMP Network HTTP Packet Snooper”, Apr. 25, 1996.
Yamaguchi et al., “An Approach for Homology Search with Reconfigurable Hardware”, Google, 2001, pp. 374-375.
Yamaguchi et al., “High Speed Homology Search with FPGAs”, Proceedings Pacific Symposium on Biocomputing, Jan. 3-7, 2002, pp. 271-282, vol. 7, Online, Lihue, Hawaii, USA.
Yan et al., “Enhancing Collaborative Spam Detection with Bloom Filters”, 2006, IEEE, pp. 414-425.
Yoshitani et al., “Performance Evaluation of Parallel Volume Rendering Machine Re Volver/C40”, Study Report of Information Processing Society, Mar. 5, 1999, pp. 79-84, vol. 99, No. 21.
Prosecution History for U.S. Appl. No. 14/060,339, filed Oct. 22, 2013 (Henrichs et al.).
Lockwood, “Platform and Methodology for Teaching Design of Hardware Modules in Internet Routers and Firewalls”, IEEE Computer Society International Conference on Microelectronic Systems Education (MSE'2001), Las Vegas, NV, Jun. 17-18, 2001, pp. 56-57.
Lockwood, “Protocol Processing on the FPX”, Field Programmable Port Extender: Jan. 2002 Gigabit Workshop Tutorial, Washington University, St. Louis, MO, Jan. 3-4, 2002.
Lockwood, “Simulation and Synthesis”, Field Programmable Port Extender: Jan. 2002 Gigabit Workshop Tutorial, Washington University, St. Louis, MO, Jan. 3-4, 2002.
Lockwood, “Simulation of the Hello World Application for the Field-Programmable Port Extender (FPX)”, Washington University, Applied Research Lab, Spring 2001 Gigabits Kits Workshop.
Madhusudan, “Design of a System for Real-Time Worm Detection”, Hot Interconnects, pp. 77-83, Stanford, CA, Aug. 2004, found at http://www.hoti.org/hoti12/program/papers/2004/paper4.2.pdf.
Madhusudan, “Design of a System for Real-Time Worm Detection”, Power Point Presentation in Support of Master's Thesis, Washington Univ., Dept. of Computer Science and Engineering, St. Louis, MO, Aug. 2004.
Mao et al., “Cluster-based Online Monitoring System of Web Traffic”, Dept. of Computer Science and Technology, Tsinghua Univ., Bejing, 100084 P.R. China.
Mosanya et al., “A FPGA-Based Hardware Implementation of Generalized Profile Search Using Online Arithmetic”, ACM/Sigda International Symposium on Field Programmable Gate Arrays (FPGA '99), Feb. 21-23, 1999, pp. 101-111, Monterey, CA, USA.
Moscola et al., “FPGrep and FPSed: Regular Expression Search and Substitution for Packet Streaming in Field Programmable Hardware”, Dept. of Computer Science, Applied Research Lab, Washington University, Jan. 8, 2002, unpublished, pp. 1-19, St. Louis, MO.
Moscola et al., “FPSed: A Streaming Content Search-and-Replace Module for an Internet Firewall”, Proc. of Hot Interconnects, 11th Symposium on High Performance Interconnects, pp. 122-129, Aug. 20, 2003.
Moscola, “FPGrep and FPSed: Packet Payload Processors for Managing the Flow of Digital Content on Local Area Networks and the Internet”, Master's Thesis, Sever Institute of Technology, Washington University, St. Louis, MO, Aug. 2003.
Navarro, “A Guided Tour to Approximate String Matching”, ACM Computing Surveys, vol. 33, No. 1, Mar. 2001, pp. 31-88.
Necker et al., “TCP-Stream Reassembly and State Tracking in Hardware”, School of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta, GA.
Niewczas et al., “A Pattern Matching Algorithm for Verification and Analysis of Very Large IC Layouts”, ACM, Apr. 1998, pp. 129-134.
Nunez et al., “The X-MatchLlTE FPGA-Based Data Compressor”, Euromicro Conference 1999, Proceedings, Italy, Sep. 8-10, 1999, pp. 126-132, Los Alamitos, CA.
Nwodoh et al., “A Processing System for Real-Time Holographic Video Computation”, Reconfigurable Technology: FPGAs for Computing and Application, Proceedings for the SPIE, Sep. 1999, Boston, pp. 129-140, vol. 3844.
Office Action for U.S. Appl. No. 14/694,622 dated Jun. 24, 2016.
Partial International Search Report for PCT/US03/15638 dated Feb. 3, 2004.
Prakash et al., “OC-3072 Packet Classification Using BDDs and Pipelined SRAMs”, Department of Electrical and Computer Engineering, The University of Texas at Austin.
Pramanik et al., “A Hardware Pattern Matching Algorithm on a Dataflow”; Computer Journal; Jul. 1, 1985; pp. 264-269; vol. 28, No. 3; Oxford University Press, Surrey, Great Britain.
Ramakrishna et al., “A Performance Study of Hashing Functions for Hardware Applications”, Int. Conf. on Computing and Information, May 1994, pp. 1621-1636, vol. 1, No. 1.
Ramakrishna et al., “Efficient Hardware Hashing Functions for High Performance Computers”, IEEE Transactions on Computers, Dec. 1997, vol. 46, No. 12.
Ramesh et al., “Automatic Selection of Tuning Parameters for Feature Extraction Sequences”, IEEE, Jun. 21-23, 1994, pp. 672-677.
Ratha et al., “Convolution on Splash 2”, Proceedings of IEEE Symposium on FPGAS for Custom Computing Machines, Apr. 19, 1995, pp. 204-213, Los Alamitos, California.
Ratha et al., “FPGA-based coprocessor for text string extraction”, IEEE, Sep. 11-13, 2000, pp. 217-221.
Roberts, “Internet Still Growing Dramatically Says Internet Founder”, Press Release, Caspian Networks, Inc.—Virtual Pressroom.
Roesch, “Snort—Lightweight Intrusion Detection for Networks”, Proceedings of LISA '99: 13th Systems Administration Conference; Nov. 7-12, 1999; pp. 229-238; USENIX Association, Seattle, WA USA.
Roy, “A bounded search algorithm for segmented channel routing for FPGA's and associated channel architecture issues”, IEEE, Nov. 11, 1993, pp. 1695-1705, vol. 12.
Sachin Tandon, “A Programmable Architecture for Real-Time Derivative Trading”, Master's Thesis, University of Edinburgh, 2003.
Schmerken, “With Hyperfeed Litigation Pending, Exegy Launches Low-Latency Ticker Plant”, in Wall Street & Technology Blog, Mar. 20, 2007, pp. 1-2.
Schmit, “Incremental Reconfiguration for Pipelined Applications”, FPGAs for Custom Computing Machines, Proceedings, The 5th Annual IEEE Symposium, Dept. of ECE, Carnegie Mellon University, Apr. 16-18, 1997, pp. 47-55, Pittsburgh, PA.
Schuehler et al., “Architecture for a Hardware Based, TCP/IP Content Scanning System”, IEEE Micro, 24(1):62-69, Jan.-Feb. 2004, USA.
Schuehler et al., “TCP-Splitter: A TCP/IP Flow Monitor in Reconfigurable Hardware”, Hot Interconnects 10 (HotI-10), Stanford, CA, Aug. 21-23, 2002, pp. 127-131.
Seki et al., “High Speed Computation of Shogi With FPGA”, Proceedings of 58th Convention Architecture, Software Science, Engineering, Mar. 9, 1999, pp. 1-133-1-134.
Shah, “Understanding Network Processors”, Version 1.0, University of California-Berkeley, Sep. 4, 2001.
Shalunov et al., “Bulk TCP Use and Performance on Internet 2”, ACM SIGCOMM Internet Measurement Workshop, 2001.
Shirazi et al., “Quantitative Analysis of FPGA-based Database Searching”, Journal of VLSI Signal Processing Systems for Signal, Image, and Video Technology, May 2001, pp. 85-96, vol. 28, No. 1/2, Kluwer Academic Publishers, Dordrecht, NL.
Sidhu et al., “Fast Regular Expression Matching Using FPGAs”, IEEE Symposium on Field Programmable Custom Computing Machines (FCCM 2001), Apr. 2001.
Sidhu et al., “String Matching on Multicontext FPGAs Using Self-Reconfiguration”, FPGA '99: Proceedings of the 1999 ACM/SIGDA 7th International Symposium on Field Programmable Gate Arrays, Feb. 1999, pp. 217-226.
Singh et al., “The EarlyBird System for Real-Time Detection on Unknown Worms”, Technical report CS2003-0761, Aug. 2003.
Sourdis and Pnevmatikatos, “Fast, Large Scale String Match for a 10Gbps FPGA-based Network Intrusion Detection System”, 13th International Conference on Field Programmable Logic and Applications, 2003.
Steinbach et al., “A Comparison of Document Clustering Techniques”, KDD Workshop on Text Mining, 2000.
Tan et al., “A High Throughput String Matching Architecture for Intrusion Detection and Prevention”, ISCA 2005: 32nd Annual International Symposium on Computer Architecture, pp. 112-122, 2005.
Tang et al., “A Novel Data Format Conversion Method Based on FPGA”, Cross Strait Quad-Regional Radio Science and Wireless Technology Conference, Jul. 26, 2011, pp. 1204-1207.
Tau et al., “Transit Note #114: A First Generation DPGA Implementation”, Jan. 1995, 9 pages.
Taylor et al., “Dynamic Hardware Plugins (DHP): Exploiting Reconfigurable Hardware for High-Performance Programmable Routers”, Computer Networks, 38(3): 295-310 (16), Feb. 21, 2002, and online at http://www.cc.gatech.edu/classes/AY2007/cs8803hpc—fall/papers/phplugins.pdf.
Taylor et al., “Generalized RAD Module Interface Specification of the Field Programmable Port Extender (FPX) Version 2”, Washington University, Department of Computer Science, Technical Report, Jul. 5, 2001, pp. 1-10.
Taylor et al., “Modular Design Techniques for the FPX”, Field Programmable Port Extender: Jan. 2002 Gigabit Workshop Tutorial, Washington University, St. Louis, MO, Jan. 3-4, 2002.
Taylor et al., “Scalable Packet Classification using Distributed Crossproducting of Field Labels”, Proceedings of IEEE Infocom, Mar. 2005, pp. 1-12, vol. 20, No. 1.
“A Reconfigurable Computing Model for Biological Research Application of Smith-Waterman Analysis to Bacterial Genomes” A White Paper Prepared by Star Bridge Systems, Inc. [retrieved Dec. 12, 2006]. Retrieved from the Internet: <URL: http://www.starbridgesystems.com/resources/whitepapers/Smith%20 Waterman%20Whitepaper.pdf.
“ACTIV Financial Announces Hardware Based Market Data Feed Processing Strategy”, for Release on Apr. 2, 2007, 2 pages.
“ACTIV Financial Delivers Accelerated Market Data Feed”, Apr. 6, 2007, byline of Apr. 2, 2007, downloaded from http://hpcwire.com/hpc.1346816.html on Jun. 19, 2007, 3 pages.
“DRC, Exegy Announce Joint Development Agreement”, Jun. 8, 2007, byline of Jun. 4, 2007; downloaded from http://www.hpcwire.com/hpc/1595644.html on Jun. 19, 2007, 3 pages.
“Lucent Technologies Delivers “PayloadPlus” Network Processors for Programmable, MultiProtocol, OC-48c Processing”, Lucent Technologies Press Release, downloaded from http://www.lucent.com/press/1000/0010320.meb.html on Mar. 21, 2002.
“Overview, Field Programmable Port Extender”, Jan. 2002 Gigabit Workshop Tutorial, Washington University, St. Louis, MO, Jan. 3-4, 2002, pp. 1-4.
“Payload Plus™ Agere System Interface”, Agere Systems Product Brief, Jun. 2001, downloaded from Internet, Jan. 2002, pp. 1-6.
“RFC793: Transmission Control Protocol, Darpa Internet Program, Protocol Specification”, Sep. 1981.
“Technology Overview”, Data Search Systems Incorporated, downloaded from the http://www.datasearchsystems.com/tech.htm on Apr. 19, 2004.
“The Field-Programmable Port Extender (FPX)”, downloaded from http://www.arl.wustl.edu/arl/ in Mar. 2002.
Aldwairi et al., “Configurable String Matching Hardware for Speeding up Intrusion Detection”, SIRARCH Comput. Archit. News, vol. 33, No. 1, pp. 99-107, Mar. 2005.
Amanuma et al., “A FPGA Architecture for High Speed Computation”, Proceedings of 60th Convention Architecture, Software Science, Engineering, Mar. 14, 2000, pp. 1-163-1-164, Information Processing Society, Japan.
Amer-Yahia et al., “XQuery 1.0 and XPath 2.0 Full-Text 1.0”, W3C Working Draft, http://www.w3.org/TR/query-full-text/, May 18, 2007—parts 1-4.
Anerousis et al., “Using the AT&T Labs PacketScope for Internet Measurement, Design, and Performance Analysis”, Network and Distributed Systems Research Laboratory, AT&T Labs-Research, Florham, Park, NJ, Oct. 1997.
Anonymous, “Method for Allocating Computer Disk Space to a File of Known Size”, IBM Technical Disclosure Bulletin, vol. 27, No. 10B, Mar. 1, 1985, New York.
Arnold et al., “The Splash 2 Processor and Applications”, Proceedings 1993 IEEE International Conference on Computer Design: VLSI in Computers and Processors (ICCD '93), Oct. 3, 1993, pp. 482-485, IEEE Computer Society, Cambridge, MA USA.
Artan et al., “Multi-packet Signature Detection using Prefix Bloom Filters”, 2005, IEEE, pp. 1811-1816.
Asami et al., “Improvement of DES Key Search on FPGA-Based Parallel Machine “RASH””, Proceedings of Information Processing Society, Aug. 15, 2000, pp. 50-57, vol. 41, No. SIG5 (HPS1), Japan.
Baboescu et al., “Scalable Packet Classification,” SIGCOMM'01, Aug. 27-31, 2001, pp. 199-210, San Diego, Califomia, USA; http://www.ecse.rpi.edu/homepages/shivkuma/teaching/sp2001/readings/baboescu-pkt-classification.pdf.
Baer, “Computer Systems Architecture”, 1980, pp. 262-265; Computer Science Press, Potomac, Maryland.
Baeza-Yates et al., “New and Faster Filters for Multiple Approximate String Matching”, Random Structures and Algorithms (RSA), Jan. 2002, pp. 23-49, vol. 20, No. 1.
Baker et al., “High-throughput Linked-Pattern Matching for Intrusion Detection Systems”, ANCS 2005: Proceedings of the 2005 Symposium on Architecture for Networking and Communications Systems, pp. 193-202, ACM Press, 2005.
Barone-Adesi et al., “Efficient Analytic Approximation of American Option Values”, Journal of Finance, vol. 42, No. 2 (Jun. 1987), pp. 301-320.
Behrens et al., “BLASTN Redundancy Filter in Reprogrammable Hardware,” Final Project Submission, Fall 2003, Department of Computer Science and Engineering, Washington University.
Berk, “JLex: A lexical analyzer generator for Java™”, downloaded from http://www.cs.princeton.edu/˜appel/modern/java/Jlex/ in Jan. 2002, pp. 1-18.
Bloom, “Space/Time Trade-offs in Flash Coding With Allowable Errors”, Communications of the ACM, Jul. 1970, pp. 422-426, vol. 13, No. 7, Computer Usage Company, Newton Upper Falls, Massachusetts, USA.
Braun et al., “Layered Protocol Wrappers for Internet Packet Processing in Reconfigurable Hardware”, Proceedings of Hot Interconnects 9 (HotI-9) Stanford, CA, Aug. 22-24, 2001, pp. 93-98.
Braun et al., “Protocol Wrappers for Layered Network Packet Processing in Reconfigurable Hardware”, IEEE Micro, Jan.-Feb. 2002, pp. 66-74.
Brodie et al., “Dynamic Reconfigurable Computing”, in Proc. of 9th Military and Aerospace Programmable Logic Devices International Conference, Sep. 2006.
Cavnar et al., “N-Gram-Based Text Categorization”, Proceedings of SDAIR-94, 3rd Annual Symposium on Document Analysis and Information Retrieval, Las Vegas, pp. 161-175, 1994.
Chamberlain et al., “Achieving Real Data Throughput for an FPGA Co-Processor on Commodity Server Platforms”, Proc. of 1st Workshop on Building Block Engine Architectures for Computers and Networks, Oct. 2004, Boston, MA.
Chamberlain et al., “The Mercury System: Embedding Computation Into Disk Drives”, 7th High Performance Embedded Computing Workshop, Sep. 2003, Boston, MA.
Chaney et al., “Design of a Gigabit ATM Switch”, Washington University, St. Louis.
Cho et al., “Deep Packet Filter with Dedicated Logic and Read Only Memories”, 12th Annual IEEE Symposium on Held-Programmable Custom Computing Machines, Apr. 2004.
Cho, “A Fast Regular Expression Indexing Engine”, Proc. of 18th Int'l Conv. on Data Engineering, 2001, pp. 1-12.
Choi et al., “Design of a Flexible Open Platform for High Performance Active Networks”, Allerton Conference, 1999, Champaign, IL.
Clark et al., “Scalable Pattern Matching for High Speed Networks”, Proceedings of the 12th Annual IEEE Symposium on Field-Programmable Custom Computing Machines, 2004; FCCM 2004, Apr. 20-23, 2004; pp. 249-257; IEEE Computer Society; Cambridge, MA USA.
Cloutier et al., “VIP: An FPGA-Based Processor for Image Processing and Neural Networks”, Proceedings of Fifth International Conference on Microelectronics for Neural Networks, Feb. 12, 1996, pp. 330-336, Los Alamitos, California.
Compton et al., “Configurable Computing: A Survey of Systems and Software”, Technical Report, Northwestern University, Dept. of ECE, 1999.
Compton et al., “Reconfigurable Computing: A Survey of Systems and Software”, Technical Report, Northwestern University, Dept. of ECE, 1999, presented by Yi-Gang Tai.
Cong et al., “An Optional Technology Mapping Algorithm for Delay Optimization in Lookup-Table Based FPGA Designs”, IEEE, 1992, pp. 48-53.
Crosman, “Who Will Cure Your Data Latency?”, Storage & Servers, Jun. 20, 2007, URL: http://www.networkcomputing.com/article/printFullArticleSrc.jhtml?article ID=199905630.
Cuppu and Jacob, “Organizational Design Trade-Offs at the DRAM, Memory Bus and Memory Controller Level: Initial Results,” Technical Report UMB-SCA-1999-2, Univ. of Maryland Systems & Computer Architecture Group, Nov. 1999, pp. 1-10.
Denoyer et al., “HMM-based Passage Models for Document Classification and Ranking”, Proceedings of ECIR-01, 23rd European Colloquim Information Retrieval Research, Darmstatd, DE, pp. 126-135, 2001.
Department of Computer Science & Engineering; “Technical Reports”; Publication (http://cse.seas.wustl.edu/Research/Publications.asp); Dec. 17, 2007; pp. 1-26; Washington University in St. Louis.
Dharmapurikar et al., “Deep Packet Inspection Using Parallel Bloom Filters,” IEEE Micro, Jan.-Feb. 2004, vol. 24, Issue: 1, pp. 52-61.
Dharmapurikar et al., “Deep Packet Inspection Using Parallel Bloom Filters,” Symposium on High Performance Interconnects (HotI), Stanford, California, 2003, pp. 44-51.
Dharmapurikar et al., “Design and Implementation of a String Matching System for Network Intrusion Detection using FPGA-based Bloom Filters”, Proc. of 12th Annual IEEE Symposium on Field Programmable Custom Computing Machines, 2004, pp. 1-10.
Dharmapurikar et al., “Longest Prefix Matching Using Bloom Filters,” SIGCOMM, 2003, pp. 201-212.
Dharmapurikar et al., “Robust TCP Stream Reassembly in the Presence of Adversaries”, Proc. of the 14th Conference on USENIX Security Symposium—vol. 14, 16 pages, Baltimore, MD, 2005; http://www.icir.org/vern/papers/TcpReassembly/TCPReassembly.pdf.
Dharmapurikar, “Fast and Scalable Pattern Matching for Content Filtering”, ACM, ANCS 05, 2005, pp. 183-192.
Ebeling et al., “RaPiD—Reconfigurable Pipelined Datapath”, University of Washington, Dept. of Computer Science and Engineering, Sep. 23, 1996, Seattle, WA.
Exegy Inc., “Exegy and HyperFeed to Unveil Exelerate TP at SIA Conference”, Release Date: Jun. 20, 2006, downloaded from http://news.thomasnet.com/companystory/488004 on Jun. 19, 2007, 4 pages.
Exegy Inc., “First Exegy Ticker Plant Deployed”, Release Date: Oct. 17, 2006, downloaded from http://news.thomasnet.com/companystory/496530 on Jun. 19, 2007, 5 pages.
Extended European Search Report for EP Application 13849798.7 dated Jul. 14, 2016.
Feldman, “High Frequency Traders Get Boost From FPGA Acceleration”, Jun. 8, 2007, downloaded from http://www.hpcwire.com/hpc.1600113.html on Jun. 19, 2007, 4 pages.
Feldmann, “BLT: Bi-Layer Tracing of HTTP and TCP/IP”, AT&T Labs-Research, Florham Park, NJ, USA.
Fernandez, “Template Matching of Binary Targets in Grey-Scale Images: A Nonparametric Approach”, Pattern Recognition, 1997, pp. 1175-1182, vol. 30, No. 7.
Forgy, “RETE: A Fast Algorithm for the Many Pattern/Many Object Pattern Matching Problem”, Artificial Intelligence, 1982, pp. 17-37, vol. 19.
Franklin et al., “An Architecture for Fast Processing of Large Unstructured Data Sets.” Proc. of 22nd Int'l Conf. on Computer Design, Oct. 2004, pp. 280-287.
Franklin et al., “Assisting Network Intrusion Detection with Reconfigurable Hardware”, Symposium on Field-Programmable Custom Computing Machines (FCCM 2002), Apr. 2002, Napa, California.
Fu et al., “The FPX KCPSM Module: An Embedded, Reconfigurable Active Processing Module for the Field Programmable Port Extender (FPX)”, Washington University, Department of Computer Science, Technical Report WUCS-01-14, Jul. 2001.
Gavrila et al., “Multi-feature Hierarchical Template Matching Using Distance Transforms”, IEEE, Aug. 16-20, 1998, vol. 1, pp. 439-444.
Google Search Results Page for “field programmable gate array financial calculation stock market” over dates of Jan. 1, 1990-May 21, 2002, 1 page.
Guerdoux-Jamet et al., “Systolic Filter for Fast DNA Similarity Search”, IEEE, 1995, pp. 145-156.
Gunther et al., “Assessing Document Relevance with Run-Time Reconfigurable Machines”, FPGAs for Custom Computing Machines, 1996, Proceedings, IEEE Symposium on, pp. 10-17, Napa Valley, CA, Apr. 17, 1996.
Gupta et al., “High-Speed Implementations of Rule-Based Systems,” ACM Transactions on Computer Systems, May 1989, pp. 119-146, vol. 7, Issue 2.
Gupta et al., “Packet Classification on Multiple Fields”, Computer Systems Laboratory, Stanford University, Stanford, CA.
Gupta et al., “PMM: A Parallel Architecture for Production Systems,” Proceedings of the IEEE, Apr 1992, pp. 693-696, vol. 2.
Gurtov, “Effect of Delays on TCP Performance”, Cellular Systems Development, Sonera Corporation, online at http://cs.helsinki.fi/u/gurtov/papers/pwc01.pdf.
Gyang, “NCBI BLASTN Stage 1 in Reconfigurable Hardware,” Technical Report WUCSE-2005-30, Aug. 2004, Department of Computer Science and Engineering, Washington University, St. Louis, MO.
Halaas et al., “A Recursive MISD Architecture for Pattern Matching”, IEEE Transactions on Very Large Scale Integration, vol. 12, No. 7, pp. 727-734, Jul. 2004.
Harris, “Pete's Blog: Can FPGAs Overcome the FUD?”, Low-Latency.com, May 14, 2007, URL: http://www.a-teamgroup.com/article/pete-blog-can-fpgas-overcome-the-fud/.
Hauck et al., “Software Technologies for Reconfigurable Systems”, Northwestern University, Dept. of ECE, Technical Report, 1996.
Hayes, “Computer Architecture and Organization”, Second Edition, 1988, pp. 448-459, McGraw-Hill, Inc.
Herbordt et al., “Single Pass, BLAST-Like, Approximate String Matching on FPGAs”, 14th Annual IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM'06), Apr. 2006, pp. 1-10, IEEE.
Hezel et al., “FPGA-Based Template Matching Using Distance Transforms”, Proceedings of the 10th Annual IEEE Symposium on Field-Programmable Custom Computing Machines, Apr. 22, 2002, pp. 89-97, IEEE Computer Society, USA.
Hirsch, “Tech Predictions for 2008”, Reconfigurable Computing, Jan. 16, 2008, URL: http://fpgacomputing.blogspot.com/2008—01—01—archive.html.
Hollaar, “Hardware Systems for Text Information Retrieval”, Proceedings of the Sixth Annual International ACM Sigir Conference on Research and Development in Information Retrieval, Jun. 6-8, 1983, pp. 3-9, Baltimore, Maryland, USA.
Hutchings et al., “Assisting Network Intrusion Detection with Reconfigurable Hardware”, FCCM 2002: 10th Annual IEEE Symposium on Field-Programmable Custom Computing Machines, 2002.
Jacobson et al., “RFC 1072: TCP Extensions for Long-Delay Paths”, Oct. 1988.
Jacobson et al., “Tcpdump—dump traffic on a network”, Jun. 30, 1997, online at www.cse.cuhk.edu.hk/˜cslui/CEG4430/tcpdump.ps.gz.
Johnson et al., “Pattern Matching in Reconfigurable Logic for Packet Classification”, College of Computing, Georgia Institute of Technology, Atlanta, GA.
Jones et al., “A Probabilistic Model of Information Retrieval: Development and Status”, Information Processing and Management, Aug. 1998, 76 pages.
Keutzer et al., “A Survey of Programmable Platforms—Network Proc”, University of California-Berkeley, pp. 1-29.
Koloniari et al., “Content-Based Routing of Path Queries in Peer-to-Peer Systems”, pp. 1-19, E. Bertino et al. (Eds.): EDBT 2004, LNCS 2992, pp. 29-47, 2004, copyright by Springer-Verlag, Germany.
Krishnamurthy et al., “Biosequence Similarity Search on the Mercury System”, Proceedings of the 15th IEEE International Conference on Application-Specific Systems, Architectures, and Processors (ASAP04), Sep. 2004, pp. 365-375.
Kulig et al., “System and Method for Controlling Transmission of Data Packets Over an Information Network”, pending U.S. Patent Application.
Lancaster et al., “Acceleration of Ungapped Extension in Mercury BLAST”, Seventh (7th) Workshop on Media and Streaming Processors, Nov. 12, 2005, Thirty-Eighth (38th) International Symposium on Microarchitecture (MICRO-38), Barcelona, Spain.
Li et al., “Large-Scale IP Traceback in High-Speed Internet: Practical Techniques and Theoretical Foundation”, Proceedings of the 2004 IEEE Symposium on Security and Privacy, 2004, pp. 1-15.
Lin et al., “Real-Time Image Template Matching Based on Systolic Array Processor”, International Journal of Electronics; Dec. 1, 1992; pp. 1165-1176; vol. 73, No. 6; London, Great Britain.
Lockwood et al., “Field Programmable Port Extender (FPX) for Distributed Routing and Queuing”, ACM International Symposium on Field Programmable Gate Arrays (FPGA 2000), Monterey, CA, Feb. 2000, pp. 137-144.
Lockwood et al., “Hello, World: A Simple Application for the Field Programmable Port Extender (FPX)”, Washington University, Department of Computer Science, Technical Report WUCS-00-12, Jul. 11, 2000.
Lockwood et al., “Parallel FPGA Programming over Backplane Chassis”, Washington University, Department of Computer Science, Technical Report WUCS-00-11, Jun. 12, 2000.
Lockwood et al., “Reprogrammable Network Packet Processing on the Field Programmable Port Extender (FPX)”, ACM International Symposium on Field Programmable Gate Arrays (FPGA 2001), Monterey, CA, Feb. 2001, pp. 87-93.
Lockwood, “An Open Platform for Development of Network Processing Modules in Reprogrammable Hardware”, IEC DesignCon 2001, Santa Clara, CA, Jan. 2001, Paper WB-19.
Lockwood, “Building Networks with Reprogrammable Hardware”, Field Programmable Port Extender: Jan. 2002 Gigabit Workshop Tutorial, Washington University, St. Louis, MO, Jan. 3-4, 2002.
Lockwood, “Evolvable Internet Hardware Platforms”, NASA/DoD Workshop on Evolvable Hardware (EHW'01), Long Beach, CA, Jul. 12-14, 2001, pp. 271-279.
Lockwood, “Hardware Laboratory Configuration”, Field Programmable Port Extender: Jan. 2002 Gigabit Workshop Tutorial, Washington University, St. Louis, MO, Jan. 3-4, 2002.
Lockwood, “Introduction”, Field Programmable Port Extender: Jan. 2002 Gigabit Workshop Tutorial, Washington University, St. Louis, MO, Jan. 3-4, 2002.
International Preliminary Report on Patentability (Chapter I) for PCT/US2015/027348 issued Nov. 3, 2016.
Office Action for U.S. Appl. No. 14/060,339 dated Aug. 8, 2016.
Prosecution History for U.S. Appl. No. 14/694,580, filed Apr. 23, 2015 (Lancaster et al.).
Prosecution History for U.S. Appl. No. 14/694,595, filed Apr. 23, 2015 (Lancaster et al.).
Prosecution History of U.S. Appl. No. 14/694,622, filed Apr. 23, 2015 (Tidwell et al.).
Related Publications (1)
Number Date Country
20140114908 A1 Apr 2014 US
Provisional Applications (1)
Number Date Country
61717496 Oct 2012 US