The memory needed for the software, GNU grep, and the area of the FPGA required for the implementation of approaches which are mentioned in the chapter 3 and 4are showed in the Table 6.1. The regular expression tested is
which has occurrences of at the end and ranges from 8 to 28. This
performance and comparison.
The software program, GNU grep version 2.4, runs on a m
( | ) * ( | )a b a a b k
k ( | )a b k
regular expression denotes all sequences of and in which the
symbol from the end is an . Below we introduce the environment of the simulation,
achine with an 800 MHz Pentiu
epends on the text. The performance of the 's
a b's (k+1)th
a
m III Xeon processor and 2 GB RAM running Linux (Red Hat 6.2). GNU grep is the UNIX command and it uses the DFA for searching. The memory reported (showed in the second and third columns of Table 6.1) is the maximum memory used by the invocation grep. It uses an effective storage-reduction technique, “lazy transition evaluation”. The transition function is only computed when the DFA is run.
Computed transitions are kept in a cache. Before a transition is made, the cache is examined. If the required transition is not in the cache, it is computed and stored for a subsequent use. Table 6.1 shows the result of simulation, and the data about GNU grep is quoted from [1].
The performance of the GNU grep d
worst case is obtained by inputting the text which has all kinds of situation - taking the regular expression for an instance, the text contains , , and . As increases, the memory and the time required reach unacceptable level since the complete transition function is constructed. The time mentioned above consists of the DFA construction time and the time searching the text. As is 19, the time required is 87309.38 seconds (24.2525 hours). For best case, because there is only one transition constructed, the memory required is still a constant when changes.
The performance of the approach proposed in [1] is obtained using Xilinx Foundation tools running on a 450 MHz Pentium III and the target device is the Virtex XCV100 FPGA. The performance of our approach is carried out by using Quartus II 4.0 running on a Pentium 4 and the target device is the APEX EP20K600EBC-6521X.
Table 6.1 shows the result of simulation, and the data about the approach proposed in [1] is quoted from [1].
The performance of the approach in [1] depends on . As changes, the area
s dominates the construction time and the time for processing per character is in O(1). k also determines the performance of our approach . Compared with the appro
requires O k area. However, it leads to longer time required since the construction ( ) time consists of the time for compiling the HDL code and the time for FPGA configuration. Because our approach generates the HDL code, the circuit can be implemented on ASIC and all kinds of FPGAs. Furthermore, the design software can easily optimize the circuit.
k k
required grows in . The construction time includes the time for the NFA construction tim e for configuration bits generation and the time for
ach in [1] , using our approach only ( 2)
O k e, the tim
configuring the FPGA. The last two term
k GNU grep
Approach in [1] Our approach k
13 16.11 s 0.005 s 29 ms 36 s
14 82.88 s 0.01 s 33 ms 37 s
15 345.33 s 0.03 s 34 ms 37 s
16 1383.55 s 0.04 s 34 ms 36 s
17 5499.60 s 0.08 s 37 ms 37 s
18 21900.36 s 0.17 s 37 ms 36 s
19 87309.38 s 0.34 s 31 ms 37 s
28 39 ms 37 s
Table6.2: the time required (Notice that definitions of the time in all columns are not the same)
Chapter 7
Conclusion
In this paper, we present the approach that constructs the NFA circuit for regular expression matching by automatically generating HDL code. Approaches in [1]
require area and time for process per character (1 clock). However, the approach proposed in this paper only needs area and still time for processing per character. This new approach reduces the area required significantly and utilities the area efficiently. We implement metacharacters often used, and thus applications in reality become practicable. These applications include Snort, Clamav, and so on.
( 2)
O n O(1)
( )
O n O(1)
Advantages of generating the HDL code can let the optimization easier and fanout problems can be solved. Besides, the output of our approach are feasible for all kinds of FPGAs and ASIC. If generating the netlist, the optimization and fanout problem would be difficult to handle, and the design in [1] is only for a specific FPGA.
From the discussion above, we know that this new method provides a general solution for regular expression matching in hardware. The flexibility of this new method includes debug, suitable device, optimization, easily modifying the circuit, and so on. About area, the requirement is reduced from O n( 2) to O n( ) and the
References
[1] R. Sidhu and V.K. Prasanna. Fast Regular Expression Matching using FPGAs, Proceedings of IEEE Symposium on Field-Programmable Custom Computing Machines,pp. Apr. 2001.
[2] John E. Hopcroft and Jeffery D. Ullman. Introduction to Automata Theory, Languages, and Computation 2nd edition. Addison-Wesley, 2000.
[3] M. Main, W. Savitch. Data structures & other objects using C++ 2nd edition.
Addison-Wesley Longman, 2001.
[4] W. Wolf. Modern VLSI design 3rd edition. Prentice Hall, 2002
[5] E. Tau, D. Chen, I. Eslick, J. Brown, and A. DeHon. Afirst generation DPGA implementation. In FPD’94- Third Canadian Workshop of Field-Programmable Devices, pages 138-143, May 1995.
[6] S. Trimberger, D. Carberry, A. Johnson, and J. Wong. A time-multiplexed FPGA.
In J. Arnold and K. L. Pocek, editors, Processings of IEEE Workshop on FPGAs for Custom Computing Machines, pages 22-28, Napa, CA, April 1997.
[7] R. P.S. Sidhu, A. Mei, S. Wadhwa, and V. K. Prasanna. A self-reconfigurable gate
array architecture. In FPGA’99. Proceedings of the 1999 ACM/SIGDA Seventh International Symposium on Field Programmable Gate Arrays, Aug. 2000.
[8] A. V. Aho. Handbook of Theoretical Computer Science, Volume A Algorithms and Complexity, chapter 5. MIT Press/Elsevier, 1990.
[9] Friedl, Jeffrey E. F. Mastering regular expressions, O'Reilly, 2002
[10] Schwartz, Randal L. Christiansen, Tom. Learning Perl, O'Reilly & Associates, 1997
[11] Tom Christiansen and Nathan, Torkington. Perl cookbook, O'Reilly & Associates, 1998