Magdy A. Bayoumi and Lois M. Delcambre. The Center for Advanced ... Southwestern Louisiana in 1988 and 1990, respectively. From 1983 to 1986 he was with ...
169
VLSI implementation of a systolic database machine for relational algebra and hashing * Khaled M. Elleithy Computer Engineering Department, King Fahd University, Dhahran 31261, Saudi Arabia
Magdy A. Bayoumi and Lois M. Delcambre The Center for Advanced Computer Studies, University of Southwestern Louisiana, Lafayette, LA 70504, USA
Received 21 July 1990
Abstract. Database machines (DBMs) are motivated by the need for high speed query processing. Systolic arrays provide a promising future implementation for DBMs. A systolic architecture for a DBM capable of performing relational algebra operations is introduced in this paper. The array also supports the basic operations for hashing: member, insert and delete, in constant time. A VLSI implementation using a 3~ CMOS technology is analyzed. The systolic array is simple because it employs only one basic cell type. Using only one cell type reduces design time and cost and enhances reliability of DBMs.
Keywords. Database machines, systolic arrays, relational algebra, hashing, VLSI.
1. Introduction
A special purpose processor that performs database operations is often called a database machine (DBM). DBMs are motivated by the need for high speed query processing, particularly in an interactive environment [28]. Figure 1 shows a DBM used as a backend processor for a conventional host. * An early version of this paper appeared in the Third Annual Parallel Processing Symposium [29]. Elsevier INTEGRATION, the VLSI journal 11 (1991) 169-190 0167-9260/91/$03.50 © 1991 - Elsevier Science Publishers B.V.
170
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra
The functionality of a DBM can vary from a simple search capability to a complete machine. For this research, we concentrate on query processing due to its p o p u l a r i t y [ 2 - 5 ] a n d s i m p l i c i t y , w e a d o p t t h e r e l a t i o n a l m o d e l [1] a n d t h u s p r e s e n t a D B M t h a t is r e l a t i o n a l l y c o m p l e t e . W e a l s o p r o v i d e s u p p o r t f o r h a s h i n g so that our DBM can be used for simple updates as well queries. A s y s t o l i c a r r a y [ 6 - 1 1 ] is a s p e c i a l a r c h i t e c t u r e t h a t r e l i e s o n t h e a p p l i c a t i o n o f s i m p l e p r o c e s s i n g c e l l s in a n a r r a y s t r u c t u r e . M o t i v a t e d b y t h e s i m p l i c i t y o f r e l a t i o n s a n d t h e r e p e t i t i v e n a t u r e o f t h e r e l a t i o n a l a l g e b r a o p e r a t o r s , in t h i s p a p e r w e p r e s e n t a cell d e s i g n f o r a D B M . W e u s e a s i n g l e cell, y e t t h e r e s u l t i n g
Khaled M. Elleithy received his B.Sc. degree in Computer Science and Automatic Control from Alexandria University in 1983. He received his first M.Sc. Degree in computer networks from the same university in 1986. He received his second M.Sc. and Ph.D. Degrees in Computer Science from the Center for Advanced Computer Studies at the University of Southwestern Louisiana in 1988 and 1990, respectively. From 1983 to 1986 he was with the Computer Science Department, Alexandria University, Egypt, as a Lecturer, Dr. Elleithy is presently an Assistant Professor at the Department of Computer Engineering, King Fahd University of Petroleum and Minerals, Duhran, Saudi Arabia. His current research interests are in the area of Design Automation, Computer Architecture and VLSI. He has special interests in the area of formal high level synthesis. He has published over a dozen research papers in these areas. Dr. Elleithy is a member of the IEEE, IEEE Computer Society and IEEE Circuits and Systems Society. He is also a member of Phi Kappa Phi. Magdy A. Bayoumi received the B.Sc. and M.Sc. degrees in Electrical Engineering from Cairo University, Cairo, Egypt the M.Sc. degree in Computer Engineering from Washington University, and the Ph.D. degree in Electrical Engineering from the University of Winsdor, Canada. Since August, 1985, he has been with the Center for Advanced Computer Studies at the University of Southwestern Louisiana, Lafayette, where he is an Associate Professor. From 1982 to 1985 he was an instructor at the University of Windsor, where he taught courses on Electronics Microcomputer Systems, Logic Design, Digital Systems and Computer Organization. He is the Editor of the new series, Advances in VLSI Signal Processing (Ablex Publishing Co.). He is on the editorial board of the International Journal of Computer Aided VLSI Design. He is currently engaged in research in the areas of VLSI Design, Digital Signal Processing Architectures, Fault Tolerant Architectures, and Formal Hardware Verification. Dr. Bayoumi is a founding member of the VLSI Systems and Applications CAS Technical Committee where he is a chairman elect. He serves on the IEEE ASSP Technical Committee on VLSI. He is a member of the Technical Committee of the IEEE VLSI Signal Processing Workshop. He is an associate editor of the circuit and device magazine. Dr. Bayoumi won the USL 1988 researcher of the year award. He is a senior member of IEEE. He is also a member of ACM and Sigma Xi. Lois Deleambre is an Associate Professor of Computer Science at The Center for Advanced Computer Studies, University of Southwestern Louisiana in Lafayette, Louisiana. She is also the Associate Director of the recently formed Apparel Computer Integrated Manufacturing Center at USL. She is responsible for developing the emerging research agenda and for promoting technology transfer and standards activities within the A-CIM Center. Her research interests are in database and knowledge-based systems with current interest in object-oriented database systems, rule processing in an expert database system, and the formal specification and enforcement of data model semantics. She received a Ph.D. in Computer Science from the University of Southwestern Louisiana in 1982, an M.S. in - Mathematical Sciences from Clemson University, and a B.S. in Mathematics with a minor in Computer Science from the University of Southwestern Louisiana.
K.M. Elleithy et al. / VLS1 systofic database machine for relational algebra
171
Terminals
E= ~,
,
Fig. 1. D a t a b a s e m a c h i n e connected to the host.
systolic array is general enough to support the relational algebra and hashing. By using a single cell type that is quite simple, the resulting DBM is easy to design and cost effective to manufacture. Previous work dealing with relational algebra used arrays of different cells such that each operation is performed by one of these cells [20-24]. This makes the array very complex. Although hashing is a related problem, researchers generally handle it separately. Arrays of linear time complexities have been presented to solve hashing related problems [12]. The main contribution of this work is that we use only one systolic cell type that is capable of performing the relational algebra operations and solving the hashing problems in constant time. In Section 2 we review prior work. Section 3 presents the motivation for this new machine. Section 4 provides a review of the relational data model. In Section 5 we introduce a new systolic database machine and explain the operation of the array for relational algebra. In Section 6 we show how to use the array in the hashing mode. In Section 7 a VLSI implementation is analyzed. Finally, Section 8 offers conclusions.
2. Prior work Most of the database machines previously proposed depend on the relational model, for example [13-17]. Some of them can support other models. We introduce here a 3-dimensional model to study DBMs based on Qadah's [18] model. The three dimensions are (Fig. 2): (1) Processor-memory organization: which includes Single Instruction Single Data (SISD), Single Instruction Multiple Data (SIMD), Multiple Instruction Multiple Data (MIMD), Systofic Arrays, and Wave-front Arrays. (2) Query processing location: which describes where the query is processed; it can be on disk, or off disk, or hybrid.
172
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra
QueryProcessingLocation Off-Disk Hybrid On-Disk
Processor
Organization I
I
SISD
SIMD
I
I
MIMD
Systolic & WavefrontArrays
R e l a t ~
Indexing and Hashing Level Fig. 2. A modified database machine space. (3) Indexing and Hashing level: where the level of indexing can be on the page, or the relation or the database itself. In general indexing is used to prevent reading the whole database when searching for a certain record. Hashing can be used instead of indexing. So the third dimension is indexing and hashing level. For a comparison between hashing and indexing refer to [19]. The machine introduced by Lehman [20] is a fast machine for a special type of transaction. These transactions satisfy the following constraints: they use only simple queries with only few operations, and they are repeated m a n y times. For example, depositing a check in a banking system. A structure of the array is shown in Fig. 3. To avoid consistency problems that arise from scheduling, Lehman showed that finding an optimal consistent schedule is NP-C problem. Song [21] introduced a design that is based on a few basic cells interconnected together in the form of a complete binary tree. The tree machine proposed in [22] has been used by Song [21] to handle the sort operation and relational operations
II
Input
r--Ln
Input_ ~
_
r-~
r-~
r~
r-~
I
II
r-~
r-'~
I r-~
~
r:J-3 _ r-~ _ r-t-1 _
I
I
I
I
FLIRESULTS
STAGE I STAGE 2 STAGE 3 Fig. 3. A piece of an SQA chip [20].
RESULT~
1(,.M. Elleithy et al. / V L S I systolic database machine for relational algebra
173
Input Root Node
Output Root Node
Fig. 4. Tree machine [21].
such as project, join, and union. Figure 4 shows the tree machine. Arden's [23] aim was to design a D B M that is capable of performing any operation in a constant time, he used an associative search in which all data elements may be I
[
I/O
l CB
CB
CI
ICB
I
°"°'-4 I
Igo?2b°r I
I
I11111 Fig. 5. Single Relation Module (SRM) [23]. VP = Value processor; TP = Tuple processor; CP = Column processor; RP = Relation processor.
174
K.M. Elleithy et al. / VLS1 systolic database machine for relational algebra
Fig. 6. k i n - k i n systolic database system.
processed at the same time. The main building block of the proposed system is a single relation module (SRM) and it is shown in Fig. 5. Lin's [24] work aims to apply all possible operations each in a different cell. Figure 6 shows the DBM of Lin and Lin. Panneerselvam [12] introduced an array for hashing which performs the hashing operations in a time proportional with the bucket length.
3. Motivations beyond a new S D B M
Previous works suffer from the following disadvantages and drawbacks: (a) Although there is a logical relation between the techniques used to access the database and the queries performed on the database, none of the reported techniques exploit this point. It is not enough to have a machine that performs the database's queries very fast, while there is a bottleneck in accessing the data.
K.M. Elleithy et al. / VLS1 systolic database machine for relational algebra
175
(b) Many of the reported techniques are using different types of cells. Lin [24] is using a different cell type for each operation, which leads to eight different cells for his array. This approach has a negative impact on the array's space and regularity. It also may be difficult to extend the array to new operations because it may require new cell types. (c) Reported works for hashing operations [12], show how the operations are done in a number of cycles proportional to the bucket length although they can be done in constant time. (d) Lehman's array [20] has 50% utilization and low utilization leads to low throughput. (e) Low throughput is a result of having only one output at each cycle [21]. (f) Lehman's machine [20] is intended for a limited type of transaction. Performance degradation is expected if the transactions do not meeting these constraints. (g) Some DBMs use associative arrays [23] which are very complicated to be implemented, and do require complex control circuitry. In our design we are trying to eliminate these drawbacks to enhance the performance. Our strategy is as follows: (a) Introducing a machine that supports both hashing and relational algebra to speed up both accessing, and modifying the data and queries. (b) Using only one simple cell type to minimize area, and provide regularity. (c) Performing hashing operations in constant time. (d) Exploiting the parallelism in the design to improv e utilization. (e) Providing every cell in the array with one output per cycle to increase the throughput. (f) Supporting general types of transactions without affecting the performance. (g) Using simple control circuitry. In Section 5, we introduce a new SDBM which realizes the previous strategy. But first, we briefly review the relational model.
4. Relational data model
The relational model represents the database using just one basic unit, the relation. The database consists of a number of relations. Each relation has a number of attributes. The number of attributes in a relation is the degree of the relation. Each attribute i has a domain D, which is the set of all possible values the attribute i can take. Given a relation R with the attributes A 1, A 2. . . . . A n, such that A, has domain D~ then:
RGD~×D2X...XD
~
For relational model we use a query language to express the user's queries. Examples of equivalent [14] formal query languages are the relational algebra [1] and the relational calculus [25].
176
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra
Now we present a brief description of the relational algebra operations. A complete explanation can be found in [19, 26, 27]. (1) Select (o): selects the tuples in relation R which satisfies the condition C.
%(R) (2) Project (~r): lists the required attributes from a relation R. Repeated tuples will be removed. 7ratt,.att ...... art. ( R )
(3) Cartesian product ( × ) : contains all tuples resulting from the given set of relations by concatenating a tuple from each relation.
RaXR2X...×R
.
(4) Union (U): contains the set of all tuples in all the given relations. n
U R, i=l
(5) Difference ( - ) : contains the tuples belonging to the first relation and not found in the second relation. E1- E2 To perform union and difference operations, the relations must be union compatible, which means they have the same degree, same attributes and same domains. The previous five operations are the basic operations which form a minimum set of operations that can be used to represent any other operation. One other non basic operation is the join operation. Although it can be performed using other operations, it is introduced for it's importance. (6) Join (0): it is like the cartesian product followed by a select. R I I × IoR2=oo( R~ × R2)
5. A n e w S D B M
In this section, we introduce a systolic architecture that performs the basic operations used in relational algebra. We will use a general cell that can perform all the required operations. We will show how each operation is performed. Indexing or hashing can be used to avoid sequential searching to access the data. In general hashing is better in supporting queries that contains equality type constraints such as: Select att 1, a t t 2 , . . . , att n from R i where attj = C
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra d
177
Collect
b tester = cond b= a. flag collect = cond (a,c) d=a.c
Fig. 7. A systolic cell.
In this case the average lookup time is constant irrespective of the database size provided the tuples are hashed on att x Indexing supports queries which have range constraints such as: Select attl, a t t 2 , . . . , a t t n from R i where attj ~< C 1, att k ~< C2 It is difficult to support both hashing and indexing in the same machine because of hardware overhead, so either hashing or indexing is generally chosen depending on the most likely type of queries. Basic cell
Only one cell type will be used to perform: cartesian product, join, selection, projection, set difference and intersection. We choose to implement the intersection and set difference (to obtain the union) in order to reduce the complexity of the basic cell. T h e basic cell is shown in Fig. 7. The cell has two inputs a and c. The outputs are b, d and collect. The cell has a unit called tester. Inputs a and c are fed to the tester. The tester is loaded b y a condition - cond - before starting the operation of the array. The condition depends on the operation we want to perform. The input tuples in a and c are tested against cond. If cond is true then output collect is true. If cond is false then output collect is false. Output d is the concatenation of a and c. O u p u t d is collected if collect is true, otherwise output d is ignored. Output b is always equal to input a concatenated to a flag. In all the operations the flag is true except in the case of set difference. T h e operation for the basic cell can be summarized as follows: tester = cond; b = a - flag; collect --- cond( a, c) ; d=a.c
178
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra
Cartesian product If a relation A has p tuples and a relation B has q tuples then the cartesian product has p * q tuples. The systolic cell has two inputs a and c. The first relation B will be in input a. Every clock cycle a new tuple will be p u m p e d through input a: B~ in the first cycle, B 2 in the second cycle, e t c . . . For the other relation A, at the first clock cycle only tuple A 1 will be p u m p e d through input c. That is A~ and B1 will meet in the first cell at the first clock cycle. Concatenating these two tuples gives the first tuple in the cartesian product. In the second clock cycle B~ will move to the second cell and B 2 will be in the first cell. A 1 will be the input to the first cell and A 2 will be the input to the second cell. So, in the second clock cycle we get ~B2A~) from the first cell, and ~B~A2) form the second cell. Figure 7 shows how one relation will be p u m p e d on the input a and the other relation on input c. The output d will contain the concatenation of inputs a and c. The collect will be true always. Figure 8 shows the overall array while performing the cartesian product operation. Since there is no condition to be applied to this operation, the output d will always be collected, which means that collect will be true always. This can be accomplished by loading the tester with a condition which is always true before starting. Figure 9 is an example of the cartesian product of relations A = { a, d, e } and B = { a, b, c} The array can be easily used in a pipelining fashion without any modifications. Figure 10 shows an example of pipelining. If the size of relation A is n, and B is m, with n ~< m, then the number of ceils required is n and the number of cycles is n + m - 1. Thus, the cartesian product is performed in linear time and space.
Join In the join operation we have a condition that must be satisfied on both relations. The tester will be loaded with the test condition before doing the Join. The join operation is like the cartesian product, except that there is a condition
.....B3B2B,
)
.........
T A A A
1 1 1
A
2
A2
A3
Fig. 8. Cartesian product, union, join and intersection operations.
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra aa
true
false
false
true
false
179
Cycle I 8
a
ba
true
ad
true
bd
Cycle 2
a
Cycle 5
ca
d
a
_
true
d
false
cd
true
ae
e
true
be
Ir
Collected
Output
true
Cycle 4
d
Cycle 5
false
e false
true
ce
e
Fig. 9. I l l u s t r a t i o n of the c a r t e s i a n p r o d u c t . A = { a, d, e }, B = { a, b, c } a n d flag is always true.
that must be satisfied by each tuple in the result relation. Each time a concatenation operation is done, the condition is tested. If the condition is true, then the collect will be true and the output tuple will be in the result relation. Figure 8 shows the array while performing the join operation. Intersection
The intersection of two relations A and B will contain the tuples that are in both relations. A tuple from one relation will be in the input a and a tuple from the other relation will be in the input c. To do the intersection we must satisfy the condition a = c. This condition is loaded in the tester. If this is true then the collect is true. Figure 8 shows the array under the intersection operation. Notice that the previous three operations are performed in the same way. One relation is in one of the inputs such that a tuple is p u m p e d in every cycle, the other relation is in the other input such that one tuple is p u m p e d in the first cycle, two in the second, etc. The only difference is in the test condition loaded in the tester.
180
K.M. Elleithy et al. / V L S I systolic database machine f o r relational algebra Be
true
be
true
false
false
true
false
Cycle I a
Cycle 2
~d
e
ca
Cycle 3
d
true
e ×k true
Cycle4
bd
_
true
d
e
cd true
be true
d uk tru..._.~e
Cycle 5
k
zk true ~ ~
Cycle 6
true
ae
•
BXA
Q
CXD
e
be true
×x true
x
e
.yx trtJe x
xz ~
true
c
z_~ k
x
z
Fig. 10. Illustration of pipelining cartesian product. A = ( a , d, e}, B = ( a , b, c}, C = ( x , y, z}, D = { k, x, z } and flag is always true.
Set difference The set difference of the two relations A and B will contain tuples that belong to A and do not belong to B. A tuple from one relation will be in the input a and a tuple from the other relation will be in the input c. The condition that we must satisfy will be a < > b, for all b in relation B. If this is true then the collect will be true. Figure 11 shows the array under the set difference operation. The flag field in cell i is formed as follows: if(cond, = true and flag~_ 1 = true) then flag~ = true For the last cell (n) we have the following condition: if flag, = true then collect, = true
K.M. Elleithy et aL / VLSI systolic database machine for relational algebra
B3B2B 1
)
)I
1
)
181
) .........
T A A I
A 2
A
A2
A3
I
3
Fig. 11. Set difference operation.
If collect, is true this means that tuple a is different from all tuples in B and in this case a is in the output relation. There is a slight modification in output d of the last cell to avoid concatenating inputs a and c because they are the same.
false
aa
Cgcle I
false
false
a
a
d
C~cle2
be true
Cycle 3
ca true
ed false
a
false
d
e
bd
a
Cycle 4
e
true
a
d
false
cd
false
e
true
b
true
B -A -
d
false
Cycle 5
--
e
false
--
c
true
e
Fig. 12. Illustration of the set difference. A = {a, d, e}, B = ( a , b, c}, T: flag is true, F: flag is false.
182
K.M. Elleithy et al. / V L S I systolic database machine for relational algebra "l"
. . . . .
" t 1 "
" p 1 "
l"
B3B2B1~
)
I
I
. . . . . . . . .
I
Fig.13. Selectandprojectoperations. Output d for the last cell is equal to input a. Figure 12 shows an example of the set difference operation. The number of cycles required to perform the set difference is n + m, since it is required for the last tuple in input a to pass through the whole array. The space and time complexities are linear.
Selection The selection operation deals with only one relation. This makes us use only one input for the tuples of the relation. This means that the concatenation operation done by the systolic cell gives as an output the same input tuples. The condition loaded in the tester will be the condition C associated with the selection operation, if this is true then the collect will be true. Figure 13 shows the array under the selection operation. The output may be collected from any cell. To minimize the time it is collected from the first cell.
Projection The projection must produce the required tuples with no duplicates. We will use the same sorter used by Lin and Lin [24]. In this case the collect will be true always. Figure 13 shows the operation of the array under the projection operation. Note that we have only one relation, so input b will be empty. If the condition is true, the collect output will be true and the tuple in the output d will be in the result relation. All unary and binary relational algebra operations are performed by our SDBM using only one cell type. Theorem 1. The cartesian product, join, intersection, set difference, select and project operations are performed by the SDBM in O(n) space and time complexities, provided the array size is n.
Proof. From the previous discussion it is clear that it is required a number of cycles equal n + m - 1 to perform any of operations. For the space complexity the size of the array is equal to the size of the smaller relation. This means that the number of cycles required and the array size are of the same order as relation's size. []
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra
183
6. Hashing mode The SDBM will be used to support hashing, including the basic operations:
member, insert, and delete. The array will not be used to store the whole database because this is not practical for a large database. The database is stored in the secondary storage. If it is required to perform a hashing operation then the appropriate bucket is loaded from the secondary storage to the array. The necessary condition we impose on the hashing function is that it has a bucket size comparable to a practical array's size. Let us give a brief description of the basic operations: Member(Elem, Buck): Given a bucket Buck and an element Elem, it is required to know if Elem is in Buck: Insert(Elem, Buck): Given a bucket Buck and an element Elem, it is required to insert Elem in the appropriate place in Buck given that Buck is sorted. Repeated elements are allowed to be inserted. Delete(Elem, Buck): Given a bucket Buck and an element Elem, it is required to delete Elem from Buck. If Elem is not in Buck nothing happens. The array in the case of hashing is working in a hashing mode. In this mode if Elem is in input a for the first cell in the array then it propagates through all cells in the same clock cycle. The reason for this is that we need to check Elem against all Elements of Buck at the same time.
Member Figure 14 shows how to implement the member operation. The required Elem is the input a for the first cell in the array. Different elements of Buck will be in inputs c for different cells. The tester is loaded with the equality condition. If Elem is a m e m b e r in Buck then all collect outputs will be false except at least one will be true (The n u m b e r of true collect depends on how m a n y times Elem is
TTI, Elem
)
I
81 BI
,
I
B2 B2
Fig. 14. Hashing mode.
B3 B3
. . . . . . . . .
184
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra
repeated in Buck). Since the array is working in the hashing mode then Elem will propagate through the array in one clock cycle, which means that the result is obtained in one clock cycle. lnsert
Figure 14 shows the implementation of the insert operation. The condition loaded in the tester is the less-than condition. All cells which have inputs that are less-than Elem will have collect equal to true. The first cell with an output false shows where to insert Elem. Our element should be inserted before the first cell that has false collect. If all cells have true collect then we insert Elem at the end of the bucket. If all collects are false then we insert Elem at the beginning of the bucket. Such an implementation allows for the insertion of repeated elements. Delete
Figure 14 shows the operation of the array while performing the delete operation. The condition loaded in the tester is the equality condition. If Elem exists in Buck then at least one collect will be true. If all collect are false the Elem is not in Buck. After one clock cycle we will know the position of the element to be deleted if it exists.
Theorem 2. The member, insert and delete operations are performed by the SDBM in 0(1) space and time complexities. Proof. From the previous discussion it is clear that only one clock cycle is required to perform any of the member, insert or delete operations. For the space complexity, the size of the array is the same size as the buckets. A good hashing function should generate buckets of equal sizes such that the size is constant. So, the size of the array is constant and does not depend on the database size. []
7. VLSI implementation A prototype of the proposed cell is implemented using a 3~-CMOS technology. The characteristics of the implemented cell is as follows: [1] A and C inputs are 4-bit busses representing 4-bit tuples. [2] Output B is a 4-bit bus. [3] Output D is an 8-bit to represent the concatenation of A and C. [4] F _ 1 is the input flag for cell i and F~ is the output flag. [5] CL is the collect line which is determined by the input conditions. [6] The following operations are implemented: cartesian product, join, intersection, set difference, member, insert, and delete. The operations are done on the input tuples A and C. Table 1 summerizes the conditions required for each operation and the values of CL, F/ and D r
185
K.M. Elleithy et al. / V L S I systolic database machine for relational algebra
Table 1 Conditions and outputs for different operations. Operation
Condition
CL
Cartesian product Join Intersection Set difference Member Insert Delete
none < = > ~< >/ < > = () = < =
1 cond(A, cond(A, cond(A, cond(A, cond(A, cond(A,
C) C) C) C) C) C)
F/
Di
1 1 1 C dFi_ 1 1 1 1
A- C A.C A A A A A
F o r t h e j o i n o p e r a t i o n w e c h o o s e t o i m p l e m e n t t h e c o n d i t i o n s < , = , > , ~~, a n d < > . O t h e r c o n d i t i o n s m a y b e c h o s e n o r a d d e d . T h e c h o i c e o f t h e c o n d i t i o n s is p r a c t i c a l l y d e t e r m i n e d b y t h e e x p e c t e d t y p e s o f q u e r i e s . F o r s i m p l i c i t y w e a r e n o t i m p l e m e n t i n g t h e s e l e c t i o n o p e r a t i o n a l t h o u g h it m a y b e implemented as the join operation. Implementing the selection operation requires additional control lines.
Design process
The required conditions for different operations are provided as control signals t o t h e cell. T a b l e 1 s h o w s t h a t t w e l v e d i f f e r e n t c o n d i t i o n s a r e u s e d u s e d . F o u r c o n t r o l s i g n a l s ( K 0, K 1, K 2, g 3) w i l l d e t e r m i n e t h e e x a c t o p e r a t i o n a n d t h e e x a c t condition. Table 2 shows the control signal selection assignment.
Table 2 Control signals selection assignment K3
K2
K1
Ko
Condition
Function
0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
= = = none < < >
Member Delete Intersection Cartesian product Insert Set difference Not used Not used Join Join Join Join Join Join Not used Not used
~< >t = > < < >
186
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra CLOCK
CONTROL SELECT
J I
/ 00,°.
LDA
D
LDC
--
One bit
ii I
Four bits Eight bits
Fig. 15. Functional block diagram of the systolic cell.
The cell is divided into two four sub-modules as shown in Fig. 15. The first module consists of two 4-bit data latch to latch in the data tuples A and C. The second module has eight transmission gates connected to the output D to provide a tristate output. The third module is a comparator circuitry which is used to compare the tuples A and C. Three control signals are produced: A < C, A = C, and A > C. The control signals are fed to the fourth module with the select control lines (K0, K 1, K 2, K3) to generate F~ and CL. The Magnitude comparator (dbcm) is designed using static CMOS gates. The Combinational logic (dbcl) is designed using Domino circuit technique with a minor modification: the output buffer is replaced by a D-latch, so that the CL output remains valid after the Evaluation period. Since Domino circuit requires that the cascading to be noninverting to prevent premarure discharge while F, circuitry requires an inverting cascading, two stages of dynamic CMOS circuit are used for the F, generator. A clock delay element is used to delay the clock to the second stage. The output F~ is also latched. For the I / O circuitry the data-in circuit is composed of two 4-bit D-latch, while the data-out consists of eight transmission gates. A layout of the systolic cell is shown in Fig. 16.
Timing analysis The timing diagram of the cell is shown in Fig. 17. There are two phases occur during a single clock period, the precharge phase and the evaluation phase. During the precharge phase, dmcl sub-module is precharged, while the tuples A,
K.M. Elleithy et al. / VLS1 systolic database machine for relational algebra
Fig. 16. Layout for the systolic cell.
187
188
K.M. Elleithy et al. / VLS1 systolic database machine for relational algebra h ...........
tp -'- . . . . . . . . . . . . . . . .
/
1(-tsa- _m>,tha, < -thda- >I
'|
, < - t s c - - >', thc t < -thdc->,
I
LDA
LDA
K
. . . . . .
harge . . . . .
I ....
D
B
F LAG
COLLECT
.
.
.
.
.
.
.
>~ - - Evrsl uBtion -j-- . . . .
.
I
l:;% •
tdcm . . . . . .
[---Adcl--~ddd- / ~ |t / / ~ ~ z ~ A T" IAA" . . . . . . . . . .OUT . . . . . . . . . .OF . . . . . . .PREVIOUS . ,4"LCY.C. . . . . .E Z ~ ' ~ Y///////.~//////~ DATA 0 UT 0F PREVI0 US CYCLE"//////////'~C~.~ 0 UT~I/'/~ v C / / / / / / ~ / / / / / . 4 ' ~2.~g//J~'//Z
~///////~~H////////~ ~//////~///////
~/A~//~
Y////.//////C//////~DATA OUT OF PREVIOUS C Y C L E ~ / / / / / / / / / / ~ O U T I ' ~ / / / ~
I
I
I
SYMBOLS: (tp = Clock period; tsa, tsc = Setup time for A and C; tha, thc = Hold time for LDA and LDC; thda, thdc = Hold time for A and C after trail e d g e of LDA and LDC; tdcm = C o m p a r a t o r time delay; tdcl = Output generator time delay; tdo = Output circuits time delay; tsk = Control signals (ko-k3) setup time; and thk = Control signals (ko-k3) hold time)
Fig. 17. Timing diagram for the systolic cell. and C i are latched in from the data busses. The data latched by the input D-latch is presented to the comparator circuit. A propagation delay (tDCM) is required before the output becomes valid and be ready for processing by dmcl. The first half cycle of the clock must be longer than tDCM to eliminate the possibility of charge sharing. The dmcl circuitry has a delay (tDCL) after receiving the inputs before the outputs become valid. Since the output latches of CL and F, are level triggered and enabled during the second half of the period, the half period of the clock must also be longer than tDCL to allow sufficient time for the latches to latch in the output.
8. Conclusions
A SDBM based on the relational database model which supports the relational algebra is introduced in this paper, Only one basic cell type is used to perform the
K.M. Elleithy et al. / VLS1 systolic database machine for relational algebra
189
basic relational algebra operations: cartesian product, join, intersection, set difference, selection and projection. A linear array is used to perform the required operations. Relational algebra operations are performed with linear time and space complexities. The array is also used to perform the basic operations of hashing: member, insert and delete. The hashing operations are performed in a constant time. The array is capable of performing two tasks--relational database and hashing--which were used to be handled previously separately. Pipelining can be used easily without any modifications. Using one building block makes the array simple which reduces the design time, reduces cost and has a positive impact on reliability. Other relational algebra operations can be added directly to the tester or implemented using the other basic operations. A prototype of the proposed cell has been implemented in 3~-CMOS technology. There are several aspects that need to be explored in the design, which are very important in any database application. Examples of these aspects are: recovery from crashes, concurrency control, and enforcing security and integrity.
Acknowledgements The first author gratefully acknowledges support from the King Fahd University of Petroleum and Minerals. The second author acknowledges the support by the National Science Foundation under Grant MIP-8809811.
References [1] Codd, E.F., A relational model for large data banks, Commun. A C M 13 (Jun. 1970) 377-387. [2] Astrahan, M.M., M.W. Blasgen, D.D. Chamberlin, K.P. Eswaran, J.N. Gray, P.P. Griffiths, W.F. King, R.A. Lorie, P.R. McJones, J.W. Mehl, G.R. Putzolu, I.L. Traiger, B.W. Wade, and V. Waston, System R: a relational approach to database mangement, A C M Trans. DB syst. 1 (2) (Jun. 1976) 97-137. [3] Stonebraber, M., Retrospection on a Database System, A C M Trans. DB Syst. 5 (2) (1980) 225-240. [4] IBM, Query-by-example Terminal User's Guide, SH 20-2078-0, IBM, White Plains, NY, 1978. [5] IBM, S Q L / R T Database Programmer's Guide, IBM, White Plains, NY, 1985. [6] Kung, H.T., Let's design algorithms for VLSI systems, Proc. Conf. VLSI: Arch., Des., Fabr., California Institute of Technology, pp. 65-90, Jan. 1979. [7] Foster, M.J. and H.T. Kung, The design of special purpose VLSI chips, Computer 13 (1) (Jan. 1980) 26-40. [8] Kung, H.T., Special purpose devices for signal and image processing: An opportunity in VLSI, Proc. SP1E, Vol. 241, Real-time signal processing III, Society of Photo-Optical Instrumentation Engineers, July 1980, pp. 76-84. [9] Blackmer, J., P. Kuekes, and G. Frank, A 200 MOPS systolic processor, Proc. SP1E, Vol. 298, Real-Time Signal Processing IV, Society of Poto-Optical Instrumentation Engineers, 1981. [10] Bromley, K., J.J. Symanski, J.M. Speiser, and H.J. Whitehouse, Systolic array processor developments, in: VLS1 Systems and Computations, H.T. Kung, R.F. Sproull, and G.L. Steele Jr., (Eds.), Carnegie Mellon University, Computer Science Press, pp. 273-284, Oct. 1981. [11] Kung, H.T., and P.L. Lehman, Systolic (VLSI) arrays for relational database operations, Proc. ACM-Sigmod 1980 Intl. Conf. Manager. Data, pp. 105-16, May 1980.
190
K.M. Elleithy et al. / VLSI systolic database machine for relational algebra
[12] Panneerselvam, G., G.A. Jullien, W.C. Miller, New architecture for systolic hashing, Proc. Intl. Conf. Systolic Arrays, pp. 73-82, May 1988. [13] Yau, S.S., and H.S. Fung, Associative processor architecture--A survey, A C M Computing Surveys 9 (1) (Mar. 1977) 3 27. [14] DeFiore, C., N. Stillman and P., Berra, Associative techniques in the solution of data management problems, Proc. 1971 A C M National Conf., 1971. [15] DeFiore, C., and P.B. Berra, A data management system utilizing an associative memory, AFIPS Conf. Proc., Vol. 42, pp. 181-185, 1973. [16] Moulder, R., An implementation of a data management system on associative processor, A F I P S Conf. Proc., Vol. 42, pp. 171-179, 1973. [17] Linde, R., R. Gates and T. Peng, Associative processor application to real-time data management, AFIPS Conf. Proc., Vol. 42, pp. 187-195, 1973. [18] Qadah, G.Z., A relational database machine: analysis and design, Ph.D. thesis, Dept. of Comp. Sc., Uni. of Michigan, 1983. [19] Date, C.J., Introduction to Database Systems, Vol. 1 (Addison-Wesley Publishing Company, Inc., 1985). [20] Lehman, P.L., Systolic arrays for rapid processing of simple database transaction, Ph.D. thesis, Dept. of Comp. Sc., Carnegie Mellon University, 1984. [21] Song, S.W., On a high performance VLS! solution to database problems, Ph.D. thesis, Dept. of Comp. Sc., Carnegie Mellon University, Aug. 1981. [22] Bentley, J.L., and H.T. Kung, A tree machine for searching problems, Proc. of 1979 Intl. Conf. on Parallel Processing, IEEE, pp. 257-266, Aug. 1979. [23] Arden, B.W., and R. Ginosar, A single relation module for a database machine, Proc. 8-th Ann. Symp. Comput. Arch., pp. 227-237, 1981. [24] Lin, Y.C., and F.C. Lin, A family of systolic arrays for relational database operations, Proc. Intl. Conf. Systolic Arrays, Oxford, England, 1986. [25] Codd, E.F., Relational completeness of database sublanguages, R. Rustin (Ed.), Database Systems (Prentice-hall, Englewood Cliffs, N J, pp. 65-98, 1972). [26] Korth, H.F., A Silberschatz, Database System Concepts (McGraw-Hill, Inc., 1986). [27] J.D., Ullman, Database Systems (Computer Science Press, Inc., 1982). [28] R.C. Goldstein, Database Technology and Management (John Willey & Sons, Inc., Chap. 15, 1985). [29] Elleithy, K.M., M.A. Bayoumi, and L.M. Delcambre, A systolic machine for relational database and hashing, Proc. Third Ann. Parallel Process. Symp., pp. 621-635, Mar. 1989.