Deep trace memory system for a protocol analyzer

[0002] This application claims benefit to Provisional Application 60/065,782 filed Nov. 17, 1997.

[0003] The present invention relates generally to the field of diagnostic equipment, testers and analyzers for use with communication interfaces among computing devices. More specifically, the present invention relates to the management of large amounts of trace memory for protocol analyzers, and particularly in relation to the use of a hardware search engine in a protocol analyzer having a deep trace memory that is connected to a separate host processor.

[0004] Protocol analyzers are used as diagnostic and testing tools at various stages of the development, integration and maintenance of electronic computing devices. Typically, a protocol analyzer is designed for use with a particular electrical communication interface protocol, such as ATA, SCSI, Ethernet or Fibre Channel. In a typical use, the protocol analyzer is connected to the communication interface of the computing system being tested to record communication activity on the interface. The communication activity is captured and recorded in a dedicated trace buffer associated with the protocol analyzer, and then analyzed and/or presented to the user for the purpose of diagnosing, testing or maintaining the communication interface.

[0005] It will be apparent that the size of the trace buffer necessarily limits the amount of communication activity that can be recorded by the protocol analyzer. As the transfer speeds of communication interfaces among computing systems have increased, the need for larger or deeper trace buffers has also increased. In the early days of modern communication interfaces, trace buffers were relatively small (1K buffer) and were implemented as cache memories directly connected to a processor within the protocol analyzer, as shown, for example, in U.S. Pat. No. 4,949,252. When faster communication interfaces were developed, such as the Ethernet protocol, the size of the trace buffer increased (65K buffer) and filtering techniques were applied to minimize the amount of trace data which needed to be captured, as shown, for example, in U.S. Pat. No. 5,442,639.

[0006] While smaller size trace buffers were adequate to record communication activity for several minutes on moderate speed communication interfaces, such as the ATA or SCSI protocols, larger trace buffer depths are necessary to record communication activity for the same period of time on faster communication interfaces such as the Fibre Channel protocol. Examples of buffer sizes in existing Fibre Channel protocol analyzers include the Xyratex TP-5-100-PA+ Fibre Channel Protocol Analyzer Plus (3 MB to 24 MB), the Ancot FCA-5010 Fibre Channel Analyzer (524,000 event trace memory), and the Finisar GT-A Fibre Channel Protocol Analyzer (4 MB to 256 MB).

[0007] Managing the large amount of data generated by faster communication interfaces is difficult. Most of the faster communication interfaces today operate using packet data transfers in which packets of data, each with an associated header, are communicated among devices on the interface. One of the ways that the large amounts of data are managed in a packet data transfer system is to tightly integrate the communication buffer that receives the data packets from the communication interface with the processor. The communication buffer and the processor are typically interconnected by a common bus having a relatively large bandwidth in order to allow operations to be performed by the processor on the data packets within the communication buffer at the speeds that are required to keep up with the data transfer rate of the communication interface.

[0008] Different techniques have been proposed for improving the operational efficiency of buffers for packet data transfer communication interfaces in terms of the way in which the memory of the communication buffer is managed. One approach is to apply a filtering technique in order to reduce the amount of data that must be recorded to only those packets of data that are particularly of interest. Examples of various filtering techniques for packet data communication buffer management are shown in U.S. Pat. Nos. 5,648,965 and 5,761,424. Another technique is to capture only the header information associated with each data packet as shown, for example, in U.S. Pat. No. 5,526,283. Alternatively, it has been proposed to randomly select packets to be analyzed to minimize processor and buffer capacity requirements as shown, for example, in U.S. Pat. No. 5,315,580. The use of a serial state machine separate from the communication processor has also been proposed to handle communication packet processing as shown, for example, in U.S. Pat. No. 5,247,517.

[0009] Unfortunately, many of the techniques used in conventional data packet communication buffer management are not applicable to trace buffer management in a protocol analyzer because the trace buffer must be able to capture and retain significant volumes of data packets for purposes of subsequent analysis of an entire segment of a transfer; whereas communication buffers only temporarily hold data packets until they have been processed in a serial fashion by the device to which they have been sent.

[0010] In each of the existing Fibre Channel protocol analyzers, the trace buffer memory is physically located within the same chassis as the processor which operates the protocol analyzer, and, like conventional communication buffers, is connected to the processor by a relatively large bandwidth bus-like data transfer path. Having the trace memory physically contiguous with the processor allows for the processor in the protocol analyzer to have relatively efficient access to these large trace memories. Unfortunately, this requires that these devices be implemented using bus-interface connections on a standard PC board that are connected either as part of a desktop or tower personal computer configuration, or as part of a special purpose portable computer (a non-laptop device typically weighing more than 10 pounds and often referred to as a luggable computer).

[0011] In addition, most of the existing Fibre Channel protocol analyzers have utilized static random access memory (SRAM) to implement a deep trace buffer memory because of the speed and ease of memory management of such SRAM. SRAM has several disadvantages, however. First, it has a relatively high power consumption that can require larger, heavier and more expensive power supplies to support larger and deeper trace memories. Second, a trace buffer memory implemented in SRAM will be relatively larger than the same size trace buffer implemented in dynamic random access memory (DRAM). Unfortunately, some types of DRAM are more difficult to use in the context of a high speed trace buffer memory due to the potential conflict between the periodic refresh cycle of the DRAM and the need to write into the DRAM at a high bandwidth in order to capture traces from a high-speed communication interface, such as the Fibre Channel interface.

[0012] Another challenge faced by existing Fibre Channel protocol analyzers relates to the ability to search through a trace in the trace buffer memory looking for a particular data pattern. Protocol analyzers typically provide a search feature in which the trace buffer is scanned to look for a pattern defined by the user. In the prior art, this function is performed by the processor of the protocol analyzer, which for a PC-based analyzer would be the computer processor. To accomplish this, the computer processor must download the data from the trace buffer into the main memory of the computer processor, and a software routine is used to search for the specified data pattern in the main memory of the host processor. There are two disadvantages to this technique. First, it requires at least a partial download of the trace buffer into the main memory of the computer processor. This download can take a significant amount of time, depending upon the bandwidth of the connection between the trace buffer and the main memory of the computer processor. Second, the speed of the search is necessarily limited to the speed of the software algorithm as executed by the computer processor. Although it is known to incorporate test hardware circuitry into memory chips for the purpose of verifying the proper operation of those chips, as shown for example, in U.S. Pat. Nos. 5,247,648 and 5,406,566, such test circuitry has not been used in place of a software search routine to locate a particular data pattern that may or may not be present in a trace buffer.

[0013] Protocol analyzers have other potential design considerations that impact the manner in which trace buffers are preferably managed. One of the chief design considerations is the portability of the protocol analyzer. One approach to providing a highly flexible and extremely portable protocol analyzer is represented by the PassPort™ portable test chassis SCSI protocol analyzer offered by I-Tech Corp., the assignee of the present invention. Conventional SCSI protocol analyzers have been either desktop or tower PC-hosted devices that are not portable, or specially designed portable pieces of equipment that offer far less functionality and adaptability than a PC-hosted device. In contrast, the PassPort™ chassis contains a specialized motherboard in a relatively small case weighing less than 3 pounds that connects to a laptop PC via a parallel port cable and provides all of the capabilities of PC-hosted devices, without the need for specially designed portable pieces of test equipment.

[0014] Although portability is a desirable design objective for a protocol analyzer, this advantage has been achieved to date only by decoupling the processor from the trace buffer and imposing a relatively low bandwidth interface between the two. In the context of the requirements of managing a deep trace buffer memory for a high speed packet data communication interface, however, this approach would only aggravate the difficulties in managing the massive amounts of data that a Fibre Channel trace buffer, for example, must store and manage.

[0015] While existing Fibre Channel protocol analyzers are able to provide the deep trace buffers required for capturing and diagnosing packet data transfers on these high speed communication interfaces, it would be desirable to provide a Fibre Channel protocol analyzer that was more convenient and portable, and that was not necessarily constrained by the need to have the deep trace memory located contiguous with the host processor for the protocol analyzer. It would also be desirable to provide a deep trace buffer that could overcome the disadvantages of utilizing large memory transfers to the main memory of the host processor and software search algorithms to locate data patterns in the trace buffer.

[0016] The present invention is a deep trace buffer management system for a protocol analyzer. The protocol analyzer is preferably connected to a laptop computer equipped with the software that implements a host processor. The protocol analyzer preferably is housed in a portable chassis separate from the host processor and has a host port to connect to the host processor through a relatively small bandwidth port. An interface port connects the protocol analyzer to the communication interface under analysis. Logic circuitry controls selective write operations of traces from the interface port to a trace buffer and selective read operations of traces from the trace buffer to the host port in response to parameters as directed by the host processor. A hardware search engine in the protocol analyzer locates specified data patterns within the trace buffer as directed by the host processor without the need to download data from the trace buffer to the main memory of the host processor.

[0017] The preferred embodiment of the present invention is configured for a Fibre Channel interface having a serial transfer rate of at least 1 gigabit/second. The trace buffer is preferably divided into dual channels, one channel that stores traces from a first channel connection, and another channel that stores traces from a second channel connection. In the preferred embodiment, the host port is a PC parallel port and the interface port provides a pair of channel connections to the interface. In an alternate embodiment, the host processor is more closely connected with the protocol analyzer by an internal bus and the protocol analyzer uses the hardware search engine instead of the main memory in the host processor to improve the search performance of the system. In one embodiment, the trace buffer comprises at least two interleaved banks of memory formed of at least two megabytes of dynamic random access memory (DRAM) chips. The traces are stored in each bank of the trace buffer on alternating clock cycles to enable a sufficient bandwidth between the trace buffer and the channel connection to support the high data transfer speeds associated with the Fibre Channel interface. Alternating clock cycles between the two banks of DRAM chips also enables the DRAM chips to be refreshed on the opposite alternating clock cycles. In another embodiment, the trace buffer comprises a single bank of fast DRAM chips for each channel connection where the fast DRAM chips have a bandwidth sufficient to support the high data transfer speeds associated with the Fibre Channel interface.

[0018] The advantages of the present invention are that the hardware search engine can search the entire contents of the trace buffer for a specified data pattern in less than 10 seconds, and preferably in less than 3 seconds for a fully configured trace buffer of 256 Mbytes. The hardware search engine is configured to conduct a search of the trace buffer at a search rate of greater than 1 Mbyte every 20 milliseconds. This search rate is significantly faster than even most DMA transfers by which data could be transferred from the trace buffer to the main memory of the host processor, let alone accomplish a software search of the transferred data in the main memory. By separating the protocol analyzer from the host processor, the preferred embodiment of the present invention allows the host processor to be implemented using a conventional laptop PC and the protocol analyzer can be truly portable, having a chassis that is less than 750 cubic inches and weighs less than 10 pounds.

[0019] FIG. 1 is a high level system block diagram showing pertinent data storage hardware and process.

[0020] FIG. 2 is another high level system block diagram showing pertinent data transfer hardware and process.

[0021] FIG. 3 is yet another high level system block diagram showing pertinent search hardware and associated process.

[0022] FIG. 4 is a high level block diagram of the hardware for the search engine of the present invention.

[0023] FIG. 5 is a logic block diagram depicting data storing process implemented in the preferred embodiment of the present invention.

[0024] FIG. 6 is a logic block diagram depicting a searching process implemented in the preferred embodiment of the present invention.

[0025] FIG. 7 is a logic block diagram showing data transfer process implemented in the preferred embodiment of the present invention.

[0026] FIG. 8 is a simplified block diagram of the deep trace buffer memory management system of the present invention.

[0027] As shown generally in FIG. 8, a system for analyzing a communication interface comprises host processor 2 and a protocol analyzer 4. For conceptual clarity, not all of the detailed elements implementing the preferred embodiment are shown. Preferably, the host processor 2 is a laptop computer provided with software to implement the operation of the host processor on the laptop computer. Alternatively, the host processor could be implemented in a non-portable computer if the protocol analyzer is intended to be a permanent monitoring fixture for the given communication interface. As with any PC-based computer known in the art, the host processor 2 includes at a minimum a user interface 102, a computer processor 104 and a main memory 106 that are interconnected with each other by a conventional bus interface 108. Preferably, the protocol analyzer 4 is housed in a portable chassis separate from the host processor 2. In this embodiment, the protocol analyzer 4 has a host port 28 that provides a relatively low speed interface to the host processor having a smaller bandwidth connection, and an interface port 10 that provides a connection between a deep trace buffer memory 6 and the communication interface. In an alternate embodiment, the protocol analyzer and the host processor are housed in the same chassis and the host port 28 may provide a relatively faster connection, such as an internal bus connection in the form of a PCI bus or an ISA bus. In this embodiment, the bus interface 28 between the protocol analyzer 4 and the host processor 2 is separate from the interface between the trace buffer 6 and a hardware search engine 30 of the protocol analyzer 4 and is also separate from the bus interface 108 between computer processor 104 and the main memory 106 of the host processor 2.

[0028] As shown in more detail in FIGS. 1 and 2, the interface port 10 in one embodiment preferably includes a dual port fifo buffer 12 and the deep trace buffer memory 6 is preferably comprised of a pair of fast page DRAM banks of memory 14, 16 that require refresh control. In another embodiment, interface port 10 may include a dual port fifo buffer 12 and a single synchronous DRAM bank of memory 14. It will be understood that the detailed description of the first embodiment with reference to FIGS. 1 and 2 with a dual port fifo 12 and a pair of DRAM banks 14, 16 is described in terms of a 36 bit wide data path, the second embodiment having a dual port fifo buffer and a single bank of DRAM is preferably implemented in terms of a 40 bit wide data path to more easily format the trace capture of the Fibre Channel interface, although the data path could be any width desired.

[0029] Logic circuitry 8 controls selective write operations of traces from the interface port 10 to the trace buffer 6 and selective read operations of traces from the trace buffer 6 to the host port 28 in response to parameters as directed by a user through the host processor 2. As described hereinafter in further detail, the protocol analyzer 4 includes a hardware search engine 30 that locates specified data patterns within the trace buffer 6 as directed by the user through the host processor 4.

[0030] The communication interface for which the protocol analyzer 4 of the present invention is preferably designed is a Fibre Channel interface having a serial transfer rate of packet data of at least 1 gigabit/second, although the present invention would work equally as well with other communication interfaces previously discussed. In this embodiment, the low speed interface 28 that serves as the host port is a PC parallel port. This provides a convenient and standard connection to the laptop computer that serves as the host processor 2. Alternatively, other relatively low speed, smaller bandwidth ports such as a serial interface or Ethernet connection, for example, could serve as the host port in the embodiment in which the protocol analyzer 4 is physically separated from the host processor 2.

[0031] In the preferred embodiment of a Fibre Channel interface as shown in FIG. 8, the interface port 10 provides a pair of channel connections (10a, 10b) to the communication interface and the trace buffer is divided into dual channels, one channel 6athat stores traces from a first channel connection 10aand another channel 6bthat stores traces from a second channel connection 10b. The pair of channel connections 10a, 10bare provided because the Fibre Channel interface typically provides for a pair of connections comprising an inbound connection and an outbound connection. To monitor both of these connections, it is preferred that the protocol analyzer also be equipped with a pair of channel connections 10a, 10b. It should be noted that the description of the preferred embodiment with respect to FIGS. 1 and 2 sets forth the detailed implementation of a deep memory trace buffer for a single channel. To accomplish the dual channel mode described above, the trace buffer for a single channel would be replicated, one for each channel connection.

[0032] Now turning to the drawings and more particularly FIG. 1 thereof, it will be observed that it depicts the principal components of the data storage hardware and process in accordance with one embodiment of the principle of the invention. Depicted there are high speed interface 10 which is interconnected, via conventional data communication paths as shown, with preferably dual port memory 12 configured as a first-in-first out (fifo). Also included are conventional data communication between dual port memory 12 and DRAM bank 14 and DRAM bank 16. Further, address counter 18 is in data communication with DRAM bank 14 and DRAM bank 16. Hardware 18 controls write address counter 20 read address counter 22 and address full counter 24, which allow dual port memory 12 to act as a fifo. These counters may be of the type normally available with current state of the art READ/WRITE address counters.

[0033] Now turning to FIG. 2, it will be observed that it depicts address counter 18 and its interconnection with DRAM bank 14 and DRAM bank 16 as shown in FIG. 1. Register/demultiplexor 26 is in data communication with DRAM bank 14 and DRAM bank 16. Data transferred from the DRAM banks is preferably stored in 36 bit register and multiplexed on to low speed interface 28 thereby enabling data transfer. Although all of these features are not required to implement data transfer as contemplated by the principles of the present invention and thus some of them are optional, it is deemed apparent that each of the features illustrated add to the usefulness and modular implementation of deep memory option.

[0034] Now turning to FIG. 3, it will be observed that it illustrates practice of the principles hereof in cooperation with and implementation of search engine 30. Thus, according to FIG. 3, the data storage component and process of FIG. 1 interconnects with search engine 30 via conventional data communication channel to perform a search for data matching the desired data pattern. For illustrative purposes, the output of search engine 30 is shown as a match found flag.

[0035] Now turning to FIG. 4, the principal components of search engine 30 are shown. Search engine 30 includes two blocks of pattern RAM 32, a 4 bit counter 34 and a comparator 36. Received data R from DRAM bank 14 and DRAM bank 16 is directed to comparator 36. Likewise data from Pattern RAM 32 is communicated to comparator 36.

[0036] Referring now to FIG. 5, a data storing process logic chart is shown. The chart depicts high level sequential logic steps necessary to effect data storing process. Similarly, FIG. 6 shows a searching process logic chart. The chart depicts high level sequential logic steps implemented to read DRAM address counter to get location in DRAM. Further, FIG. 7 is a logic chart showing a data transfer process as implemented in a unidirectional data transfer logic sequence.

[0037] Referring now to FIG. 1 and FIG. 5 in more detail, deep memory option is triggered under logic step 40 to store data into trace memory. In operation, 36 bit data is received from the interface port 10 and passed through dual port memory 12 which is preferably a 16 deep dual port memory configured as a fifo. The deep memory option is initialized under logic step 42. Subsequently, data is entered under logic step 44. The data is stored in DRAM under decision block 46. If DRAM is full and/or an exit command is received, the session is terminated under logic step 48. In the alternate, if DRAM is not full and/or there is no exit command, the logic reverts back to logic step 44 to enter more data as apparent. Storing data into trace memory involves the cooperative elements of FIG. 1. Specifically, when data is entered in dual port memory 12, DRAM address counter 18 addresses 's DRAM. In a preferred operational sequence, DRAM address counter will start at address zero and an increment each time a 36 bit word is stored into each DRAM bank 14 and DRAM bank 16. Thus, in data storing process (See FIG. 5) DRAM bank 14 operates one cycle later than DRAM bank 16. Accordingly, for every write access to DRAM bank 14, there will be a corresponding access to DRAM bank 16. Further, DRAM address counter 18 is compared to user initiable terminal address register. When the two are equal, trace memory is full. This is similar to the condition depicted under decision logic step 46 wherein when DRAM is full, the session is terminated in accordance with logic step 48. In the alternate, based on user option, the analyzer may stop or start over-writing trace memory.

[0038] Dual port memory 12 preferably configured as a fifo is one of the essential components of the present invention. Specifically the unit plays an important role when an overwrite condition prevails in the analyzer. Under this scenario, the last three words received from the analyzer must be overwritten by the next three words from the analyzer. A 4 bit write pointer selects which address to store data in. It starts at zero and counts up with each data word stored.

[0039] When an overwrite occurs, the write pointer is decremented by three. A 4 bit read pointer is used to address the location of the next valid data word to be read out of the dual port fifo. The read pointer starts at address zero and increments each time a word is read out of the dual port fifo. Finally, a 4 bit full counter exists that indicates how much data is in the dual port fifo. The full counter increments on a write, decrements on a read, and decrements by 3 on an overwrite. Data is not allowed to be read out of the dual port fifo until 8 or more words are in the fifo. This ensures that at least 2 words are available to be written into DRAM bank 14 and DRAM bank 16, and that there is no chance of an overwrite occurring with this data.

[0040] Referring now to FIG. 6 in more detail, the searching process includes initiating the DRAM address counter 18 under logic step 50. Subsequently, the logic proceeds to set terminal address under logic step 52 to ending address of search. The search direction is set under logic step 54. Thereafter, the logic proceeds to fill pattern memory with preferably 16 desired data words and 16 don't care words under logic step 56. At the termination of filling, pattern memory, the logic proceeds to implement hardware search engine under logic step 58. The search engine is operated until a match is found or search is terminated under decision block 60. If a match is found DRAM address counter 18 is read to get the location in DRAM and the search ends under logic step 62. In the alternate, in the event a match is not found and/or the search terminated, the logic enters a subroutine in which the hardware search engine is set to look for a match or search complete signal/command.

[0041] Now turning to FIG. 3 in view of the discussion hereinabove, pertaining to FIG. 6, it will be observed that search engine 30 is in data communication with DRAM bank 14 and DRAM bank 16. Further, in accordance with FIG. 3, DRAM bank 14 operates 2 cycles (40 ns) later than DRAM bank 16. For every read access from DRAM bank 16 there will be a corresponding access from DRAM bank 14. The DRAM address counter 18 is initialized by the user to point to the first address in DRAM of the data to be searched. The terminal address register is initialized by the user to point to the last address in DRAM to be searched. Once hardware search is set under logic step 58, data is read out of the DRAM and fed into search engine 30. DRAM address counter 18 increments after each dual access to DRAM, and the hardware will continue reading data out of DRAM until the search is complete (address counter equals terminal address register) or until a match is found in accordance with decision block 60. (When halted by a match, the user can read the address pointer to find out where the match is located.)

[0042] As discussed hereinabove, the search engine consists of preferably two blocks of RAM, each 36 bits wide by 16 deep, a 4 bit counter, and comparator 36. Referring now to FIG. 4, it is shown that the desired search pattern is written into one block of Pattern RAM 32 by the user, and don't care bits are written to the other Pattern RAM 32. Pattern RAM 32 holds the desired data and the don't cares of the search pattern. Thus the user has the ability to specify hi, low, or don't care for each bit of 16 sequential 36 bit words as the pattern to search for.

[0043] After the pattern RAM is initialized and the DRAM address pointer and terminal address registers are set, the hardware search process depicted in logic chart of FIG. 6 can be initiated for operation. At this point address counter for Pattern RAM 32 is zero, and the data out of Pattern RAM 32 is the desired data for the first word of the search pattern. A 36 bits of data from the DRAM, 36 bits of desired data from the pattern RAM 32, and 36 don't care bits from Pattern RAM 32 all go into the comparator 36 which generates a match signal. If a match occurs, the address counter of Pattern RAM 32 increments and the next word from DRAM is compared to the second word of the desired search pattern. If no match is found, the address counter of Pattern RAM 32 is cleared to zero, and the search starts all over again. If the address counter of Pattern RAM 32 reaches terminal count (15+ count up) a complete match has been found. When this condition is indicated or confirmed, the reading of DRAM is halted, and the user can find the location of the match in DRAM by reading DRAM address counter 18.

[0044] Referring now to FIG. 7, a logic chart depicting a data transfer process is shown. Specifically, the transfer process is initiated under logic step 70 by setting DRAM address counter 18 to starting address of data transfer. Subsequently, terminal address register is set to ending address data transfer under logic step 72. Thereafter, the logic proceeds to set for data transfer from DRAM to low speed host processor port 28 under logic step 74. Preferably, the low speed host processor port is internally connected to a 16 bit bus interface connection that provides connection between the protocol analyzer and deep memory trace board. As will be appreciated by those of skill in the art, the bus interface connection internal to the protocol analyzer advantageously operates very much like the PC ISA bus. Further, the data is read out of the deep trace memory under logic step 76 and subsequently the session is terminated under logic step 78.

[0045] The transfer of data from DRAM to the low speed terminal involves the cooperative operation of software logic as shown in FIG. 7 and hardware as shown in FIG. 2. Specifically, DRAM bank 14 operates 2 cycles (40 ns) later than DRAM bank 16. Thus, for every read access from bank 16 there will be a corresponding access from bank 14. The address counter is initialized by the user to point to the first address in DRAM of the data to be transferred. The terminal address register is initialized by the user to point to the last address in DRAM to be transferred. Once the data transfer on process is activated, data is read out of the DRAM and stored in a 36 bit register. Only one 36 bit word of the dual bank access is used, the other word is discarded. A second dual bank access is done when the next 36 bits of data is needed.

[0046] Once the data is in the 36 bit register, it is multiplexed onto the 16 bit low speed interface. When the user reads the data port, he will first get bits 35-32 of the first 36 bit word, followed by bits 31-16, and finally bits 15-0. Once bits 15-0 have been transferred, more data is read out of DRAM and moved into the 36 bit register. The address counter increments after every other read access of DRAM, and when the address counter equals the terminal address register, the data transfer is exited.

[0047] Accordingly the present invention provides a modular and expandable trace memory depth which advantageously implements a hardware search engine complementary with software for storing, data, transferring data and quickly find a desired data pattern. Specifically, the present invention discloses heretofore unknown apparatus and method in which a hardware search engine in cooperation with trace memory hardware, a low speed interface and DRAM banks and software implemented therein enable trace memory modular expansion.

[0048] Although the invention hereof has been described by way of example of a preferred embodiment, it will be evident that other adaptations and modifications may be employed without departing from the spirit and scope thereof. For example, other types of trace memory may be modularly structured for expansion.

[0049] The terms and expressions employed herein have been used as terms of description and not of limitation; and thus, there is no intent of excluding equivalents, but on the contrary it is intended to cover any and all equivalents that may be employed without departing from the spirit and scope of the invention.