Micro Programmed Control Unit

CHAPTER 6: Microprogrammed Control Unit Design6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9. 6.10. 6.11. Introduction Terminology Microprogrammed Control: Advantages and Disadvantages Components of Microprogrammed Control Unit Clock Period Computation Microprogrammed Control Example Generic Microsequencer Microprogram Optimization: Definition Microinstruction Encoding Example Microprogram Optimization Algorithm Complex Microprogramming Structures

1

M. Balakrishnan: Only for limited circulation for the Ethiopian class

CHAPTER 6: Microprogrammed Control Unit Design6.1. Introduction Microprogramming is an alternative to what is referred to as hardwired approach for designing the control part of a system. The state machine implementations shown in chapter 4 are referred to as hardwired implementations. The key benefit of microprogramming is its flexibility in making design changes without having to redesign or rewire the system. This makes it extremely useful during the design and development phase as frequent modifications are inevitable at this stage. Status Signals Data Part Control Signals Figure 6.1 Control-Data Interaction The control part and the data part (also referred to as data path) are the two major components of any system. These parts interact via two sets of signals the status signals from the data to the control and the control signals from the control to the data part. The data part contains the resources for storing and performing operations (transformations) on data values whereas the control part sequences these operations/data transfers in a specific order to implement the algorithm. The control part controls the sequence of operations by issuing the control signals in a specific order. As in most algorithms, the sequence of operations to be performed is not independent of the data values i.e. it does depend on the result of intermediate operations on specific data. The data operation results required for such flow control are conveyed by the data part to the control part by a set of signals called status signals. These signals typically capture the result in a binary form as whether a particular condition (e.g. a > b) is true or false. This clear separation of the design into control and data in some sense represent an extreme design approach. In most complex designs, one would find a less ideal situation with control part also performing some data operations and data part also implementing some control steps. For an experienced designer this may be easy to handle but for a student learning to design, it is strongly felt that this distinction between control and data and a strict separation between the two be clearly enforced. In the initial stages, this ensures faster development through a systematic debug methodology. Over a period, the designer learns to consciously integrate data operations in control and control steps in data units for efficiency reasons. An algorithm today is best captured in terms of what is referred to as RTL description. RTL stands for register transfer level and primarily involves primitive operations and transfer of data between registers or storage elements. These are typically operations which can be performed in one step (or simply one cycle) in the hardware. For this to happen, all such primitive operations in the RTL description are supported by combinational units in the data path which can implement those operations. A more detailed description and examples of RTL would follow in the next two chapters. Control Part

2


RTL descriptions typically do not separate control and data parts. From such an RTL description, the control can be synthesized through one of the following options: Extract FSM and synthesize using hardwired logic Extract a microprogram and synthesize microprogrammed control Extract FSM (Moore machine) and synthesize using microprogrammed control In an unstructured manual design approach one can also use what is referred to as adhoc controller which does not go through a structured intermediate step of FSM or Microprogramming. 6.2. Terminology Before we discuss microprogramming in detail, we would like to clearly define the associated terminology. Text box titled Figure 6.2 presents the most important terms related to microprogramming. The name microprogram comes from the level at which this program exists. In case of the processor or microcontroller, it is at a level even lower than the machine level i.e. it is internal to the machine and represents the internal control of the machine. Normally this level is not visible to the user. A set of microinstructions which implements the control by both providing the control signals and testing the conditions/status signals to take control flow decisions is referred to as microprogram. Microinstructions are the components of a microprogram as a collection of microinstructions represent a microprogram. These microinstructions may be either written directly in the binary from or in a symbolic form with one-to-one mapping to the binary form. In some sense they represent a single control step and carry signals for activating all the data units required for carrying out operations in that specific step. For the purposes of this book, we would always associate one clock period with each control step which means each microinstruction takes one clock period to execute. Each microinstruction consists of a number of control signals which activate different components in the data part to perform these operations concurrently. Each of the indivisible unit operations is referred to as micro-operation and refers to the most primitive controllable operation in the microarchitecture of the design. A microinstruction is nothing but a set of micro-operations which are concurrently executed in a specific step. Not all micro-operations can be executed concurrently as each of them requires some resources and mainly contention for the same resource prevents concurrency among pairs of micro-operations. e.g. In a data part with ALU, taking operands from two registers connected to the ALU input ports, adding them and storing in another register connected to the ALU output port is a micro-operation. Such a micro-operation cannot be activated concurrently with another micro-operation which utilizes the same ALU for performing subtraction. It should be clear that a single micro-operation may require multiple control signals; apart from function select of ALU, the add micro-operation defined above may require control signals for bringing/routing the register operands to the ALU input ports, taking the ALU output to the result register input port and control signal for latching the result register.

3


Microprogram: A set of microinstructions which represents the control for implementing a specific algorithm on a given data part. Microinstruction: Each microinstruction consists of a set of control signals which correspond to a set of micro-operations which are activated concurrently in one control step. Micro-operations: Each micro-operation is an indivisible register transfer operation which may require one or more control signals to be activated. Microinstruction format: Microinstruction format refers to the specific organization of control signals in the form of microinstruction fields and their bit position that defines the microinstruction. Microsequencer: The role of the microsequencer is to generate a sequence of addresses for the microprogram ROM taking into account the status signals originating from the datapart. These addresses are used to fetch the next microinstruction and thus the microsequencer is also known as the next address generator. Control/Microprogram ROM: This is memory unit where the set of control signals which constitutes the microinstructions and consequently microprogram are stored. Microprogram register: The microprogram register acts as an interface between the control and data parts it contains the current microinstruction that is being executed by the data part in a given control step/clock cycle.

Figure 6.2 Definition of terms related to Microprogramming To understand the functionality of the remaining terms, refer to figure 6.3 which shows a block diagram of a typical microprogrammed system. The microsequencer is a key component which continuously generates the sequence of addresses for the control ROM and thus is also referred to as the next address generator. The microsequencer typically contains a register called microprogram counter (PC) which has a role in relation to microprogram that is very similar to the role program counter (PC) has vis-a-vis the program in a processor. The sequence of addresses generated in some sense encapsulates the control flow of the algorithm and thus the microsequencer has to respond to the status signals originating from the data part. Control/microprogram ROM stores the microprogram in the form of a sequence of microinstructions. Each bit of the microprogram corresponds to the control signals required to activate the data part or a signal required to help generate the next address. A set of bits (or a word of microprogram) fetched simultaneously constitute a microinstruction and correspond to the control signals that are activated concurrently. A larger microprogram width usually means a larger and more concurrent data part. The vertical size of the microprogram in some sense defines the complexity of the algorithm being implemented. The word ROM is used in a legacy sense and very often the miroprogram today is stored in a RAM so that the control can be easily modified. Still by and large, when the module is executing, microprogram control does not change (at least not rapidly) and thus the behavior is more like a ROM.

4


The microinstruction once fetched needs to be stored and a register named microinstruction register is used for that. The width of this register is the same as the microprogram width. To those familiar with the processor architecture, they can relate this to the instruction register which typically stores the opcode and other related control information for the machine program execution. This register in some sense allows overlap of execution of the current microinstruction with the generation (status generation + next address generation + next microinstruction access) of the next microinstruction. Introducing more registers can help overlap more of these steps and thus achieve a higher degree of pipelining. It is a synchronous design with both the control part and the data part executing in one clock cycle. The clock is explicitly not shown in the diagram but register is clocked and work on an active edge (rising or falling). Further, it is assumed that all registers in the data part that could affect the status and thus the microinstruction through the microsequencer also operate at the same edge. Control signals

Sequencer

-pgm ROM

reg.

Data Part

Status signals

Figure 6.3 Block Diagram of a Microprogrammed Unit

6.3. Microprogrammed Control: Advantages & Disadvantages Microprogrammed control evolved in early 60s and was very popular for implementing digital systems including mainframe computers. The main reason for its popularity was its flexibility which allowed the control to be easily updated without the need to redesign the interconnections or printed circuit boards. In the case of computers, it enabled the micro-architecture to be cleanly isolated from the instruction set thorough this layer of microprogramming. This enabled the same instruction set to be used for processors implemented using multiple generation of semiconductor devices or even from multiple vendors supporting very different micro-architectures through instruction set emulation. The main advantage is that the system software and tools like compilers can be shared across multiple hardware platforms. The longevity of IBM 360 instruction set owes considerably to this feature which is referred to as emulation. We now enumerate specific advantages and disadvantages of the microprogrammed approach vis-vis hardwired or random logic approach.

5


Advantages: Structured and flexible design: The design is extremely flexible, as any change requires only a modification in the contents of the ROM. The control part hardware structure is more or less fixed as opposed to a random logic design where even a simple change like a control output shifted from one state to another may require a change of interconnections or even logic gates. Testing sequences can be easily incorporated: Testing a system both for faults in implementation as well as for faults developing over time due to component failure require considerable effort and cost. In microprogrammed systems as all the components are being controlled from the control ROM, it is relatively easy to develop test sequences that activate various components in a controlled manner to test the complete system components functioning. The cost in terms of additional ROM words storing these test microinstructions. On the other hand, random logic control would require considerable additional circuitry including may be fresh interconnections to achieve the same results. Easy to document and debug: Documenting a design is a key to achieve longevity in its life. The documentation enables engineers other than designers to both upgrade and maintain the system. A system with microprogrammed control is much easier to document and maintain as the basic functionality is captured in microinstruction format and the algorithm in the microprogram. Both these are relatively easy to document, test and modify vis--vis a complex control circuit in the form of a large number of gates. The growth in complexity in understanding the design does not grow so fast with the increase in size of the microprogram, whereas the same cannot be said about the hardwired control.

Disadvantages: Expensive especially for small designs: For simple designs, microprogrammed control can be an overkill as components like ROM and microsequencer can add to its cost substantially. Slower than random logic: A key reason why microprogramming is not used in many production systems is that it can be much slower than random logic in terms of clock period. This is because the large components like ROM and microsequencer add to the delay and make the clock slower. Higher power consumption: Memory components tend to be more power consuming because of its full decoding vis--vis custom logic design. Though a detailed study including quantification in this area is missing, but it is expected that microprogrammed control is likely to be more power consuming than hardwired custom logic. Unsuitable for supporting pipelining: Microprogramming just like classical assembly or high-level language programming is primarily a sequential control programming paradigm. As almost all processors today support instruction pipelining ranging from three to even ten plus stages, microprogrammed control has become unsuitable at least for implementing control of the processors. Such a deep pipelining also implies a high degree of concurrency with multiple stages operating in a relatively distributed manner (e.g. need to stall). Such designs cannot be efficiently implemented using a centralized controller. HDLs hide logic complexity: Increasingly, designs start by capturing the specifications in terms of HDL (Verilog/VHDL) descriptions as a FSM for the control part or even RTL which integrates data and control part. From this description, the synthesis tools take over and automatically generate the hardwired or random logic. Thus, the designer never sees the

6


underlying logic complexity. Further, maintenance and upgradation of the design is also done only using the source HDL descriptions. The disadvantages explain the key reasons for its relative unpopularity in designing the modern processors which employ pipelining to increase processing throughput. Most ASICs still use sequential control based on FSMs (and thus sequential) but as they almost always start from HDL descriptions and thus hide logic complexity from the designer, use of microprogramming has considerably declined. On the other hand, we still include microprogramming and microprogrammed control unit design in this text as this gives a unique insight into the control part by giving it a structure. In some designs, variants of this approach still appear though the control may not be completely microprogrammmed.

6.4. Components of Microprogrammed Control Unit In this section we would describe the major components of a microprogrammed control unit. Not only the components would be identified but also their role as well as their generic sizes would be defined to get a better understanding of a micoprogrammed control unit.

n | Sequencer | k | 1 MUX | s | S n | -pgm ROM NXw w | m reg | Data Part

Figure 6.4 Block Diagram of a Sized Microprogrammed Control Unit Figure 6.4 is essentially the same block diagram as figure 6.3 but with one important difference. Now the sizes of all the interconnections have been symbolically labeled. First we start with the microinstruction format. A microinstruction contains a set of control signals that activate various data part components simultaneously and also help define the next microinstruction to be executed. Microinstruction format refers to the mapping of individual microinstruction bits to the control signals. In some sense this refers to encoding of control signals in the microinstruction into various fields. More details and also options on encoding are discussed in section 6.9.

7


A single microinstruction consists of various blocks of signals, all requiring different number of bits depending on the design. The data part in figure 6.4 is assumed to require m bits as control signals and that is one field. The microsequencer is capable of performing number of control actions primarily towards selecting the next address. More details of the microsequencer follow in section 6.6. These are encoded in k bits and referred to as as sequencer control. The number of status lines originating from the data part which can influence the next address are S signals. In any one microinstruction one of these signals is selected by the multiplexer. This multiplexer is controlled by the s select lines (equivalent to log2S) which is shown as the third field. Finally the field next address which is n bits wide specifies the branch address in case of branch sequencer action. All these add upto w bits in the microinstruction format as shown in figure 6.5 and table 6.1. Though figure 6.5 and table 6.1 defines only four broad fields, usually there are many subfields under these fields especially in the data part control field. m k s n

1

2

3

4

Figure 6.5 Microinstruction Format (to be read in conjunction with table 6.1)

Field No. Field name 1 Data Part Control Signals 2 Sequencer Control / Action Select 3 Status Control Select 4 Branch Address (for jumps etc) Total microinstruction width

Size (bits) m k s n w

Remarks on Size Complexity of data part Options for next address selection s = log2S n = log2N w=m+k+s+n

Table 6.1 Generic Microinstruction Fields Once the microinstruction fields are defined, now it would be possible to describe the sizes of the various control unit components in terms of these symbolic sizes. Table 6.2 describes all the major components. Component Data part Sequencer Status MUX -pgm ROM -instr-register Remark on Size m control inputs and S status outputs k+ n + 1 inputs, n outputs S status inputs, s select lines, 1 output ( s > log2S ) N X w bits ( n > log2N where n is the no of address inputs ) w= m+k+s+n Table 6.2 Components and their Sizes Data part clearly has m control inputs and S status outputs. The value m in some sense reflects the concurrency and thus indirectly complexity of the data part. Please note the m control signals have nothing to do with the data inputs or primary inputs to the system. In some

8


specific cases, role of a primary input is only to control the machine. e.g. a start signal coming from an external source triggers the start of the algorithm. In such cases, for the sake of generality we assume the external input received by the data part, still goes through it as a status signal to control the flow. This is shown in figure 6.6. : Primary Inputs

Data Part

Control Part

Primary Outputs Figure 6.6 Primary Input as a status signal The microsequencer ( Sequencer) has k + n + 1 inputs corresponding to the k sequencer instruction bits, n branch address bits, 1 selected status line from the status MUX and n next address bits going to the microprogram ROM. The status MUX is used to select one of the S status lines coming from the data part using the s status select lines coming from the microinstruction. The microprogram ROM (-pgm ROM) or control ROM is of size N X w where N is the total number of microinstructions or the length of the microprogram. This obviously corresponds to the complexity of the algorithm in terms of number of states. The microinstruction register (-instr-register) is w bits wide and corresponds to the sum of widths of all the fields. While mapping the control flow onto the microprogrammed control, it is generally transformed into one in which each state has only 2 outgoing edges (i.e. one out of two possible destinations). This makes implementation much easier as after executing a given microinstruction it will either execute the next state or some other microinstruction specified by the branch address. This decision is made by the microsequencer based on the status line selected by the statusMUX. More complex multi-way branches are also possible in microprogrammed control but requires special treatment which is beyond the scope of this book.

9


6.5. Clock Period Computation Clock period is an important contributor to the performance of any synchronous digital system. This is because the total time (T) taken in executing an algorithm is given by T = tclk X nclk (6.1)

The minimum clock period is constrained by the longest delay path from any register output(/primary input) to any register input(/primary output). For the microprogrammed control, the clock period computation is shown. For that we first enumerate the relevant delays of the components. tdp: tstatus: tsta_mux: tseq: tROM: treg: Maximum delay in data part Maximum delay for status generation in data part Delay of status multiplexer Microsequencer delay Microprogram ROM delay Register delay (includes setup time)

tdp is the maximal data part delay path whereas tstatus is the maximum delay of the path generating the status signals. P3 P1

Sequencer

-pgm ROM NXw

reg

Data Part

P5

P4

P2 Figure 6.7 Clock period computation: Identified delay paths Figure 6.7 identfies five paths which can constrain the clock period. Out of these five, the three that is P3, P4 and P5 are dominated by P2 as they contain only subset of the delays involved in P2. Thus the clock period can be expressed as the maximum of the P1 and P2 delay. tclk > max { tdp , tstatus + tsta_mux + tseq + tROM * + treg } (6.2)

10


Microprogrammed control compares poorly with hardwired logic generally because the ROM delay is significantly higher than other components. This implies P2 dominates over other delays and becomes the constraint to slow down the clock period and thus the performance. Normal approach to removing a constraint originating from a long delay path is to introduce registers to break the path and in some sense pipeline the activities happening in that path. This will directly decrease the clock period but has the potential of increasing the number of clocks as well as the complexity of the control. Thus such transformations have to be carried out based ion comprehensive analysis.

P1

Sequencer

R E G

-pgm ROM NXw

reg

Data Part

P2 Figure 6.8(a) A Two Stage Pipeline in the Control Path P1

Sequencer

R E G

-pgm ROM NXw

reg

Data Part

R E G P2 Figure 6.8(a) A Three Stage Pipeline in the Control Path

11


Figures 6.8(a) and 6.8(b) show the same path broken into two stages and three stages respectively. The equation 6.2 gets modified to equation 6.3 in case one register is introduced between the microsequencer and microprogram ROM and equation 6.4 in case another register is introduced to latch the status before the status multiplexer. Please note all these registers are assumed to be clocked by the same clock. Figure 6.8(a) manages to isolate the Control ROM delay and 6.8(b) further manages to isolate the tstatus from the rest of the path delays. tclk > max { tdp , tstatus + tsta_mux + tseq + treg, tROM } tclk > max { tdp , tsta_mux + tseq + treg, tROM, tstatus } (6.3) (6.4)

As already pointed out this can have an impact on number of clocks. The readers who are familiar with instruction level pipelining as part of computer architecture can easily correlate this situation with that. In case of figure 6.8(a), any jump would be delayed by one cycle and it may always not be possible to get a condition evaluated one cycle before performing a branch. Alternative would be to fill up a Nop microinstruction which essentially increases the number of clock cycles to execute the algorithm. In case of figure 6.8(b), the status or branch condition has to be generated two cycles before the actual branch can be affected. This again means one may have to introduce Nop microinstructions as this may not be possible in many situations as the data on which the status is generated may be available only just before the branch. In the previous discussion, it has been shown that pipelining can be used to decrease the clock period, but may also result in increasing the number of clock cycles. Therefore, to get optimal performance, a careful decision has to be made regarding how many stages of pipelining are suitable such that benefits of clock period reduction are not overtaken by the loss due to increase in number of clock cycles. 6.6. Microprogrammed Control Example In the previous subsections, we have introduced the terminology as well as components. To firm up the discussion and to increase the readers understanding, in this subsection we present a simple case study of a microprogrammed control implementation. The general design steps are: Design the data part and identify the control and status signals Identify control flow requirements to complete control-data interface and the block diagram Generate the symbolic microprogram Finalize the microinstruction format Design the microsequencer Generate the binary microcode or control ROM contents Figure 6.9 Design Steps in Microprogrammed Design We will illustrate this design process with an example of designing the microprogrammed control unit of a GCD computer.

12


X Y start

16 16

GCD Computer

16

Z

eoc

Figure 6.10 Block Diagram of a 16-bit GCD Computer Figure 6.10 shows the block diagram of the GCD Computer. We clearly identify all the inputs and outputs along with their data widths. The computer is intended to find GCD of two 16 bit positive integers i.e. X 1 and Y 1. Output is also a 16-bit positive integer i.e. Z 1. The module starts computation once the start signal arrives by first accepting the inputs and then executing the algorithm in figure 6.11. Once the computation finishes, a signal end of computation or eoc becomes valid. This can be used by both the modules supplying the input (to get the status for giving the next set of inputs) and the module reading the result. begin s: wait till (start = 1); input x,y; eoc := 0; while (x != y) do if (x>y) then x := x-y else y := y-x endif; endwhile; z := x; eoc := 1; goto s; end;

Figure 6.11 GCD Algorithm Figure 6.11 describes the psuedocode of the algorithm. It is not in particularly any specific language but describes the sequence of steps required to compute GCD by repeatedly subtracting the smaller number from the larger number and replacing the larger number by the result of subtraction. Step 1: Design of the Data Part with associated Control and Status Signals From the algorithm we derive the data part shown in figure 6.12 for our GCD computer. All registers and flip-flops are clocked with the same clock and without losing any generality we assume they trigger at the rising edge of the clock. The data part shown in figure 6.12 is derived by systematically analyzing the operations required by the algorithm and instantiating components for

13


supporting those operations. Computation (arithmetic and logical) required in the algorithm need to be supported by corresponding ALUs, variables require storage elements to keep the values and the data transfer required for performing the operations need to be supported by interconnections among these ALUs and storage elements apart from primary inputs and outputs. Following the above approach, we instantiate a 16-bit comparator and a 16-bit subtractor for arithmetic operations and three registers R1, R2 and R3 for storing initial as well as intermediate values of X,Y and final value of result Z respectively. A primary input start and a flip-flop which can be set and reset for eoc are also instantiated. Now performing the required data transfers, we realize that some inputs require multiple inputs to be connected and in each such case we also instantiate a multiplexer. start X Y

mux

mux

R1

R2

mux

mux

Comparator

Subtractor

eoc eoc

R3 Z

Figure 6.12 Data part of the GCD Computer From the data part of figure 6.12, we have identified the control and status signals required by the controller. Figure 6.13 lists the control and status signals on the left. Control Signals: { S_R1, S_R2, S_OP1, S_OP2, L_R1, L_R2, L_R3, C_eoc, P_eoc } Status Signals: ( eq, gt, start }

14


startStart S_R1 S_R2 L_R1 L_R2 S_OP1 S_OP2 eq

X

Y

mux

mux

R1

R2

mux

mux

Comparatorgt L_R3 P_eoc C_eoc

Subtractor

eoc

R3 Z

eoc

Figure 6.13 Data part of the GCD Computer annotated with Control and Status Signals Step 2: Identify control flow requirements to complete control-data interface and the block diagram The next step in our process is to identify the control flow requirements of the algorithm. The control flow requirements can be identified directly from the algorithm. But as we have already introduced FSM as a method of capturing control, we draw the FSM just to illustrate the control flow as distinct from the data computation requirements. Figure 6.14 shows the state machine with S0 as the initial state where the machine waits for the start signal to begin computing the GCD. In state S1, the initialization as well as data input is performed. In state S2 the comparison is carried out followed by different actions depending on first whether the the values are equal or not and then which value is greater. Thus in seven states the algorithm can be executed. The data operations associated with various states are not indicated in the diagram as we do not intend to proceed with synthesizing the control from this FSM.

15


S0 start S1 eq S6

Start

S2 eq S3

gt

gt

S4

S5

Figure 6.14 FSM diagram of the GCD computer. Now it is easy to identify all the control flow requirements of the algorithm as the state machine is also available as a reference. There are three types of control flows that need to be supported in our microprogrammed control.

Next microinstruction.(e.g.. S1->S2) goto M[i+1]; where i is the present instruction number Conditional branch. (e.g.. S0->S1). if (cond) then goto M[j] where j is the branch instruction number else goto M[i+1] and i is the present instruction number Unconditional branch. (e.g.. S6->S0) goto M[j]; where j is the branch instruction number

Figure 6.15 Control Flow requirements From these control flow requirements, we arrive at corresponding microsequencer instructions. These instructions in some sense define the range that need to be supported by the microseuqencer. Next or continue (cont) Conditional jump (cjmp) Unconditional jump (jmp) M. Balakrishnan: Only for limited circulation for the Ethiopian class

16

To implement these microsequencer instructions we will need the following control part signals: seq_ins (2 bits) to specify one of the three microsequencer instructions{cont, cjmp, jp} cond_sel (2 bits) to choose between the three status or condition inputs {eq, gt, start} br_adr (3 bits) to specify the address (range 0..6) of the microinstruction to branch to. At this stage we redraw the figure 6.4 and label all the widths as per the requirements of the GCD control and data part implementation.

3

Sequencer

3

-pgm ROM 8X16 2 1

16

reg

9

Data Part

2 3

Figure 6.16 GCD Control block diagram labeled with line widths Step 3: Generate the symbolic microprogram Now we are in a position to write out a symbolic microprogram for our GCD computer. Note that each step in out microprogram corresponds to a state in our state diagram of Fig.6.14 but that may always not be the case. The microprogram in table 6.3 is written in three columns. First corresponds to the microinstruction label or address, the second corresponds to the data operation Data operation M0 M1 M2 M3 M4 M5 M6 S_R1 = X, L_R1 (R1

Micro Programmed Control Unit

Documents

Transcript of Micro Programmed Control Unit