Digital System Design 1

1. Digital System Design 1 Introduction to A Hardware Programming Language (AHPL) Veton Këpuska

2. Introduction • Interested in a description of what the computer does in terms of the sequencing of operations and the flow of information from one point to another in the computer. • With the completion of this description, development of logic diagrams, schematics, wiring tables, etc., becomes largely a mechanical procedure, subject to considerable automation. • In previous chapter a few of the conventions of AHPL were established. • Following sections would focus on the semantics of AHPL language. • One section will be devoted to complete presentation of the language syntax. Veton Këpuska

3. Operand Conventions Veton Këpuska

4. Operand Conventions (2) • Distinction between variables and literals is important: • Variable is a name by which we refer to operands; • Literal is an actual value for an operand. X = Y + 1; • In AHPL† literal values are assigned to physical entities such as registers and buses. • AHPL is a clock-mode language, so that a new value may be assigned to a physical entity only once each clock period. • The output of a memory element or a bus bit is called a signal rather than a variable. • A value may be assigned to a signal once each clock period. Veton Këpuska

5. Example: • MA ← PC; • The previous statement which it shall usually be referred to as transferring the contents of the register PC to MA,can be interpreted as “updating the signal outputs of register MA, with the current signal value of PC”. • This update takes place at the end of each clock period in which the statement is active. • In AHPL, the operators can not be omitted; thus MA, is the name of a single signal and cannot be interpreted as M ∧ A Veton Këpuska

6. Operand Conventions (3) • Variables • Unlike transfer statements involving signals, statements updating variables have no fixed relation to real time and do not represent actual hardware elements. • Variables in AHPL will appear in combinational logic unit description. • Variables do not represent physical elements in the network but will play a role in specification of the network. • Vectors • A vector is simply a collection of operands arranged in a one-dimensional array. • Dimension of the vector (i.e., number of elements in a vector), will be denoted with ρ. • Registers of more than one bit a considered to be vectors. • If the PC register contains 18 bits then ρ PC = 18; individual positions are denoted by PC[0], PC[1], …, PC[17]; PC[i] denoting ith position (zero origin indexing). Veton Këpuska

7. Operand Conventions (4) • Matrix: it is a two dimensional array of operands, as illustrated bellow: Veton Këpuska

8. Operand Conventions (5) • ith row of a matrix M, denoted by M<i>: (M<i>[0], M<i>[1], …, M<i>[ρ1-1]) • jth column of a matrix M,denoted by M[j]: (M<0>[j], M<1>[j], …, M<ρ2-1>[j]) • Computer systems models by 2-dimensional arrays: • RAM • Stack • M<i:k> array consisting of rows i through k. • M[r:n] array consisting of columns r through n. Veton Këpuska

9. AHPL Operators • BOOLEAN: Variables (or Registers) have only values of this type. • INTEGER: to facilitate the description of complex combinational logic networks introduction if this type is necessary. It is important to note that the use of this integer type and operators therein is only a descriptive mechanism of the network. • NOTE: Combinational logic networks themselves only process BOOLEAN values. Veton Këpuska

10. Binary and Unary Operators of AHPL Veton Këpuska

11. Examples of Boolean Operators • x∧(1, 0, 1) = (x, x, x) ∧(1, 0, 1) =(x,0, x) • Let U = (1,1,0,1,0,0), V = (0,1,1,1,1,0), x = 1 & y = 0: • U ∧ V = (0,1,0,1,0,0) • U ∨ V = (1,1,1,1,1,0) • x ⊕ V = (1,0,0,0,0,1) • y’⊕ U = (0,0,1,0,1,1) • Rational operator (xRy) evaluates to 1 if the relation R is satisfied and to 0 otherwise. The relation R may be any of the relations that typically compare numbers (=, >, ≥, <, ≤): • (4 > 3) = 1 • (4 < 3) = 0 Veton Këpuska

12. Mixed Operators • Much of the power of the AHPL derives from the mixed operators, which operate on various combinations of scalars, vectors, and matrices. Veton Këpuska

13. Examples of Mixed Operators • The concatenate operator: • If X=(1, 1, 0) & Y=(1, 0, 1) thenZ← X, Y;with the value of Z=(1,1,0,1,0,1) • M!N – row concatenation is valid only if M and N have the same number of columns. The result is a matrix whose first ρ2 M are rows of M and whose last ρ2 N rows are of N. • One or more of the arguments of row concatenation may be a vector as exemplified in next slide. Veton Këpuska

14. Examples of Mixed Operators (2) • “!” Row Concatenation Operator: • “⊤” Binary encode Operator • 8 ⊤100 = (0,1,1,0,0,1,0,0) • 8 ⊤0 = (0,0,0,0,0,0,0,0) Veton Këpuska

15. Examples of Mixed Operators (3) • “⊙” Reduction Operator: • z← ⊙/X; where ⊙ may be any binary operator and it signifies that • z = (( …((X[0] ⊙ X[1]) ⊙ X[2]) …) ⊙ X[p-1]) • z ← ∨/V; will be zero “0” if and only if every element of V is zero “0”. • z ← ∧/V; will be one “1” if and only if every element of V is one “1”. • Reduction and Matrixes: • X← ⊙/M; indicates that each row is reduced individually, resulting in a vector of dimensions ρ2 M. • X← ⊙//M; indicates that each column is reduced individually, resulting in a vector of dimensions ρ1 M. Veton Këpuska

16. Example of Reduction Operator applied to a Matrix • For a given matrix: Then, • ∨/M = (1,1,1); • ∨//M = (1,1,0,1); • ∧(∨//M ) = 0; Veton Këpuska

17. AHPL Complete Description:Procedures and Functions • A typical large digital system will consist of a number of interconnected subsystems. • Even though, design problem will often be limited to a single module – it is important to have a clear understanding of the relationship of that module to other modules in of the system. Veton Këpuska

18. MODULE NAME DECLARATION MODULE CONTROL SEQUENCE PROCEDURE … END SEQUENCE MODULE TRANSFERS SYSTEM UNIT FUNCTIONS UNIT … UNIT Syntax of a AHPL System Block Structure: Veton Këpuska

19. AHPL Modules (2) • Procedures: • Descriptions of modules containing memory and control • Functions • Combinational logic units only • Its outputs may be used: • Within any procedural module • Non recursively within any other combinational logic unit. Veton Këpuska

20. Combinational Logic Unit Examples • Increment Function: • INC(REG) – which is an n-bit vector representation of a binary number determined by increasing by 1 modulo 2n the number stored in register REG. In hardware terms: • REG← INC(REG) –merely means treating REG as a counter and incrementing that counter. Veton Këpuska

21. Module Description • NAME • A LIST OF DECLARATIONS • MEMORY • All flip-flops, registers, and memory arrays that will appear in the control sequence of a given module must be dimensioned in a MEMORY declaration. • INPUTS & OUTPUTS • Vectors of input and output lines as well as individual lines must be declared. • BUSES • Each BUS must be declared and dimensioned. • Communication BUS must be declared separately (see bellow). • LABLES • Used to rename portions of a larger register. • It may be used to call for a particular hardware realization of a register such as an MSI part. • COMBUSES • A communication bus may be formally defined as a bus on which the contents may be determined by more than one module. This bus must be declared separately as COMBUS, thus recording the fact that this bus is connected to set of input/output lines of the module. • It is not necessary to also include communications bus among the INPUT and OUTPUT declarations. • CLUNITS • A CONTROL SEQUENCE • A LIST OF INDIVIDUAL CONNECTION STATEMENTS • TERMINATION Veton Këpuska

22. MODULE:List of Declarations Example MODULE: DATA SELECTOR MEMORY: INREG[12]; OUTREG[12]; A[4]; s; INPUTS: X[12]; OUTPUTS: Z[12]; inready; outready; • This example illustrates the declaration of registers and individual memory elements. • An array will be dimensioned as M<m>[n]: • m – number of rows • n – number of columns. • M if it represents a memory array it should be assumed to have m-words of n-bits each. Veton Këpuska

23. MODULE:Control Sequence – End Sequence END of Module • Following declarations is the control sequence of a module consisting of : • A series of action statements. • END SEQUENCE – termination statement of a control sequence. • A number of optional statements (Intended to be applicable at all times regardless of the step in the control sequence active during the current clock period) indicating: • Individual transfers and Connection statements. • A combinational logic network generating an output as a function of the registers. This function would apply continuously regardless of the state of the control unit. • END – statement. Veton Këpuska

24. Time Keeping Example • In many systems it is necessary to keep track of time in parallel with any activities that might be in progress. This can be implemented with: • COUNT← INC(COUNT); After END SEQUENCE statement. END SEQUENCECOUNT*a← INC(COUNT);Z = X∧ REG. END Veton Këpuska

25. AHPL Statements Only operations that satisfy the constraints imposed by available hardware are included in AHPL. AHPL Selection Operators Veton Këpuska

26. AHPL Statements (2) • AHPL Control Sequence Statements: • DV←OCLV; • DV – target vector: • Single register, or • One or more memory elements assembled by any of the list of selection operators (see table in previous slide). • OCLV – origin combinational logic vector (OCL). • Each element of an OCLV is a combinational logic expression whose arguments may be elements from any of the following: • Memory elements • Inputs • Combinational logic units • Buses • Constants • Only 0, 1, and n bit encoding of a decimal number d (n ⊤ d) can be used as constant. Veton Këpuska

27. AHPL Statements (3) • AHPL Logic Operators • AHPL Logic Operators Precedence: • NOT • All selection operators except concatenate • ∧ • ∨ or ⊕ • Concatenate Veton Këpuska

28. Syntax of a Control-Sequence Step Null Connection statement Action Clocked Transfer Transfers and Connections Control sequence step →(F)/(S) Branch →(Si) Null DEAD END Veton Këpuska

29. DV←OCLV DV←OCLM * F Clocked Transfer DM*F←OCLV DM*F←OCLM*G Forms of Clocked Transfers and Connection Statements • OCLV is a vector • OCLM is a matrix BUS=OCLV BUS=OCLM * F Connection Statement Z=OCLV Z=OCLM*F Veton Këpuska

30. Examples: • If OCLM is (A!B!C), ifF = (f,g,h) and theDVisD, then the second transfer form represents previously introduced expression: D← (A!B!C) * (f,g,h); • Similarly, if the matrix DM were to represent (A!B!C), and if the OCLVwereD, then the third transfer form would coincide with previously introduced expression: (A!B!C) * (f,g,h) ←D; Veton Këpuska

31. Remarks • In all cases it has to be noted that expressions selected on the right has to have the same number of elements as the destination vector selected on the left. • Furthermore, it should be noted that a distinction is made from the connection to a pre-declared bus from a connection statement that routs an OCLV to a vector of module outputs. • There is no logical difference between a connection to an output vector Z and connection to a bus. • If the number of anticipated inputs is very large, one would usually use a pre-declared bus. • Where output networks route only a few data vectors, the notation Z = OCLV may be used. Veton Këpuska

32. Example of Realization of Conditional Connection • 10 BUS = (A!B) *(f1,f2); The sequence depicted above if it is used after END SEQUNCE its realization would not require AND-ing the condition variables f1 and f2 to the output of a control flip-flop as contrasted to the realization of the same statement if used before END SEQUENCE. This depicted in following schematics. Veton Këpuska

33. Realization of Conditional Statement in Control Sequence Veton Këpuska

34. Realization of Conditional Statement after END SEQUENCE Veton Këpuska

35. Using Combinational Logic Units • Lets consider: C = (A[0]∧B[0]) ⊕ ((A[1]∧B[1]) ∧ (A[2]∧B[2]) ∧ (A[3]∧B[3])), (A[1]∧B[1]) ⊕ ((A[2]∧B[2]) ∧ (A[3]∧B[3])), (A[2]∧B[2]) ⊕ (A[3]∧B[3]), (A[3]∧B[3]), • If the same expression were to appear more than once in a AHPL module description, it would be a saving in effort in addition to adding clarity to the code if this statement could be abbreviated and this abbreviated form be reused as needed; e.g. C = LOGIC(A;B); • The previous expression will be referred to as a function or combinational logic unit. • This notation is restricted to refer only to combinational logic networks. • The following chart depicts the structure of a function. Veton Këpuska

36. Combinational Logic Unit (Function) Description CLUNIT: LOGIC (A;B) BODY END Declarations … Connections … Veton Këpuska

37. Example: • The digital network represented by the following AHPL module description performs a logical function on sequences of 3 bits appearing in consecutive clock periods on input line x. The “8’s complement” of each sequence of 3 bits appears after a two-clock period delay on output line, z. The slicing of the bit string into 3 bit sequences is resynchronized each time control line, go, goes to “0”. The eight’s complemeting function is accomplished by the combinational logic unit COMP(W), which has three output lines, The input, W, is also a 3-bit vector. Construct a logic block diagram of the data unit described by this module. Veton Këpuska

38. AHPL Code MODULE: EIGHTS COMPLEMENTER INPUTS: x, go. MEMORY: Y[2]. OUTPUTS: z. CLUNITS: COMP[3] • Y←Y[1], x; z = Y[0]; →(go’)/(1). • Y ←Y[1], x; z = Y[0]; →(go’)/(1). • z =COMP[0](Y,X);Y = COMP[1:2](Y, x); # Rightmost two out of 3 output →1. # lines of CLUNIT whose 3 # arguments are (Y, x) END Veton Këpuska

39. Data Unit for Eight’s Complementer Veton Këpuska

40. Eight’s Complementing Function: Truth Table • Eight’s complement: output[0:2] = input’[0],input’[1],input’[2] + 1; Veton Këpuska

41. Eight’s Complementing Function: Karnaough Maps Comp[0:2] Comp[0] Comp[1] Comp[2] Veton Këpuska

42. Boolean Expressions of 8’st Complement • COMP[0] =(x∨Y[1])∧Y’[0]∨(Y[0]∧Y’[1]∧x’) • COMP[1] =(x∨Y[1])∧(x∧Y[1])’ • COMP[2] =x Veton Këpuska

43. MODULE NAME DECLARATION MODULE CONTROL SEQUENCE PROCEDURE … END SEQUENCE MODULE TRANSFERS SYSTEM UNIT FUNCTIONS UNIT … UNIT Combinational Logic Unit Descriptions • Recall the structure of the AHPL description of a system/subsystem, which at the highest level is broken down into procedures and functions: Veton Këpuska

44. Syntax for Declarations of CLUNITs CLUNIT: (Name) INPUTS: (Input List) OUPUTS: (Output List) CLUNITS: (List of nested CLUNITS) CLUNIT Description CTERMS: (Connection Points) BODY (Connection Activity) END Veton Këpuska

45. Combinational Logic Unit Descriptions (2) • AHPL uses a structured syntax for combinational logic unit description. • This makes it possible for a hardware compiler program in one pass to: • process a description step by step, and to • generate a network wire list for the corresponding combinational logic unit. • Responsibility of the designer to make sure that AHPL CLU description is correct (e.g., that it does indeed represent an implementation of the desired logic function). • Root syntax detailing the declaration part of a combinational logic unit description is given in following figure in the next slide. • The syntax for declarations of inputs and outputs and nested clunits does not differ form that of modules. • Internal signals that are the targets of connection statements are now also declared as CTERMS. This permits the hardware compiler program to know in advance the points that must connected by connection statements and makes it possible to process a description in one pass. Veton Këpuska

46. CLU Description of a “FULL ADDER” • “Full Adder” refers to a circuit that accomplishes the addition of two corresponding bits. This process entails accepting a carry bit form the full adder of the preceding stage and generates a sum bit and a carry bit to the next full adder. • Inputs: • x – input bit of the first source, • y – input bit of the second source, • cin – carry bit from previous stage full adder. • Outputs: • sum – summation of x and y, • cout – carry bit. Veton Këpuska

47. CLU Description of a “FULL ADDER” (2) • Truth Table Veton Këpuska

48. CLU Description of a “FULL ADDER” (3) • Karnaugh Map: sum cout Veton Këpuska

49. CLU Description of a “FULL ADDER” (2) • sum = (xy’ cin’) + (x’ ycin’) + (x’ y’cin) + (xycin) = x⊕ y⊕cin • cout = (x y) + (x cin) + (y cin) = ((x⊕ y) cin) + (xy) • AHPL Implementation: CLUNIT: FULLADD (x; y; cin) INPUTS: x; y; cin. OUTPUTS: FULLADD[2]. CTERMS: a; b; c; sum; cout; BODY a = x⊕ y; b = xy; sum = a⊕ cin; c = a cin; cout = b +c; FULLADD[0] = cout; FULLADD[1] = sum; END Veton Këpuska

50. Wiring of Full Ader Veton Këpuska