Design Problem 5 Solution

Transcription

1 CSE 260 Digital Computers: Organization and Logical Design Design Problem 5 Solution Jon Turner Due 5/3/05 1. (150 points) In this problem, you are to extend the design of the basic processor to implement a stack that can be used for calling subroutines. Specifically, you are to add a new register to the processor called SP (for stack pointer) and six instructions. These instructions are designed for use with a stack that grows downward in memory. The new instructions and their encodings are defined below Read SP. ACC := SP Write SP. SP := ACC Push. M[SP] := ACC; SP := SP Pop. ACC := M[SP+1] := ACC; SP := SP Return. PC := M[SP+1]; SP := SP + 1. bxxx Call. M[sp] := PC; PC := 0xxx; SP := SP 1. Your design notes should include a diagram similar to the one on page 6-20 of the notes, showing where the stack pointer fits within the processor. Your diagram should show all connections between the stack pointer and other components of the system. Your design notes should also include timing diagrams like those on page 6.25, for each of the new instructions. Highlight all changes you make to the processor VHDL. Demonstrate the use of the new instructions by writing a program that includes a recursive subroutine sumvals(k) that returns the value k. Write sumvals based on the following pseudo-code. sumvals(k) if k=0 then return 0; else return k + sumvals(k 1); Your test program should include a top level call to sumvals with an argument of 5. Use the call and return functions to branch to and from sumvals. You will also need to push the current value of k onto the stack when you make the recursive call to sumvals. Remember to pop this value off, before you return. The argument to sumvals and the returned value can be passed either in the accumulator or on the stack. The value returned to the main program should be stored in location 001f on completion of the program. Run a functional simulation of the processor with your program running. Your simulation should show all the processor registers, including sp, as well as the processor state and tick. Include a zoomed-out display of the simulation run that allows one to see how the values of - 1 -

2 SP and ACC change. Also, include detailed views of the start of the run, the middle of the run (where sumvals returns for the first time) and the end of the run. Annotate the simulation output to identify what is happening in the program at various points. Look at the synthesis report for the processor, in particular the part that describes the number of flip flops and lookup tables uses (LUTs). Do your best to explain the numbers. Can you account for all the flip flops reported? How does the number of LUTs compare to the number of flip flops (excluding those accounted for by the memory)? Based on your knowledge of the processor logic, does the number of LUTs seem reasonable? Why or why not? - 2 -

3 Design notes adding stack to simple processor. The objective of this project is to extend the basic processor to include a stack that can be used for calling subroutines. This involves adding a stack pointer (SP) to the set of processor registers and implementing the six instructions shown below Read SP. ACC := SP Write SP. SP := ACC Push. M[SP] := ACC; SP := SP Pop. ACC := M[SP+1] := ACC; SP := SP Return. PC := M[SP+1]; SP := SP + 1. bxxx Call. M[sp] := PC; PC := 0xxx; SP := SP 1. The Read and Write SP instructions simply involve transferring values between the ACC and SP registers. Since they don t require access to memory, they can be implemented in a single clock tick. The Push instruction involves writing the value of the ACC onto the stack. That is, it requires a write to memory and we can implement the instruction using the same timing of events that is used in the direct store instruction. The Call instruction also requires a write to memory. The Pop and Return instructions require reading from memory. These can use the same timing as the direct load instruction. Block diagram. The figure below shows the modified block diagram for the processor. The main addition is the SP, which has connections to and from the ACC for the Read and Write SP instructions. The SP output also connects to the address bus and there is an increment circuit that allows the value of SP+1 to be placed on the address bus. The other changes to the block diagram involve the program counter. To implement the call and return instructions, we must be able to load the value of the PC from the data bus and put its value on the data bus. The circuitry required to enable this has been added to the block diagram. Addr Data IREG LD decode PC LD + IAR LD SP LD + +1 ACC LD compare ALU OP Control Logic (combinational circuit) mem_en mem_rw state tick

4 Instruction timing. Timing diagrams showing when various events occur in the new instruction appear below. In the Read and Write SP instructions, the only events are the loading of the ACC and SP, which occur at the end of the instruction. For the Pop and Return instructions, we have to read data from memory, using SP+1 as the memory address. The value returned from memory is stored in either the ACC or the PC, depending on the instruction. The SP is incremented at the end of the instruction. Alternatively, one can implement this instruction with the SP incremented before the memory access. This would require adding logic at the end of the instruction fetch. The Push and Call instructions involve writing information to memory from either the ACC or the PC. In both cases, the address comes from the SP. The overall timing is the same as the direct store. The SP is decremented at the end of the instruction and in the case of the call, the PC is loaded with a new value from the IREG at the end of the instruction. clk Read SP Write SP Pop Return mem_en mem_rw abus sp+1 sp+1 dbus ram ram pc sp acc clk Push Call mem_en mem_rw abus sp sp dbus acc pc pc sp - 4 -

5 Processor VHDL. The processor VHDL is shown below. All changes have been highlighted. entity cpu is port ( clk, reset : in std_logic; m_en, m_rw : out std_logic; abus : out std_logic_vector(adrlength-1 downto 0); dbus : inout std_logic_vector(wordsize-1 downto 0); -- signals "exported" so they can be monitored in post-p&r simulation pcx, iarx, spx : out std_logic_vector(adrlength-1 downto 0); iregx, accx, alux : out std_logic_vector(wordsize-1 downto 0) ); end cpu; architecture cpuarch of cpu is type state_type is ( reset_state, fetch, halt, negate, mload, dload, iload, dstore, istore, branch, brzero, brpos, brneg, add, rsp, wsp, push, pop, call, ret -- instructions involving stack ); signal state: state_type; type tick_type is (t0, t1, t2, t3, t4, t5, t6, t7); signal tick: tick_type; signal pc: std_logic_vector(adrlength-1 downto 0); -- program counter signal ireg: std_logic_vector(wordsize-1 downto 0); -- instruction register signal iar: std_logic_vector(adrlength-1 downto 0); -- indirect address register signal acc: std_logic_vector(wordsize-1 downto 0); -- accumulator signal sp: std_logic_vector(wordsize-1 downto 0); -- stack pointer signal alu: std_logic_vector(wordsize-1 downto 0); -- alu output begin alu <= (not acc) + x"0001" when state = negate else acc + dbus when state = add else (alu'range => '0'); pcx <= pc; iregx <= ireg; spx <= sp; iarx <= iar; accx <= acc; alux <= alu; process(clk) -- perform actions that occur on rising clock edges function nexttick(tick: tick_type) return tick_type is begin -- return next logical value for tick case tick is when t0 => return t1; when t1 => return t2; when t2 => return t3; when t3 => return t4; when t4 => return t5; when t5 => return t6; when t6 => return t7; when others => return t0; end case; end function nexttick; procedure decode is begin -- Instruction decoding. case ireg(15 downto 12) is when x"0" => if ireg(11 downto 0) = x"000" then state <= halt; elsif ireg(11 downto 0) = x"001" then state <= negate; elsif ireg(11 downto 0) = x"002" then state <= rsp; elsif ireg(11 downto 0) = x"003" then - 5 -

6 state <= wsp; elsif ireg(11 downto 0) = x"004" then state <= push; elsif ireg(11 downto 0) = x"005" then state <= pop; elsif ireg(11 downto 0) = x"006" then state <= ret; else state <= halt; when x"1" => state <= mload; when x"2" => state <= dload; when x"3" => state <= iload; when x"4" => state <= dstore; when x"5" => state <= istore; when x"6" => state <= branch; when x"7" => state <= brzero; when x"8" => state <= brpos; when x"9" => state <= brneg; when x"a" => state <= add; when x"b" => state <= call; when others => state <= halt; end case; end procedure decode; procedure wrapup is begin -- Do this at end of every instruction state <= fetch; tick <= t0; end procedure wrapup; begin if clk'event and clk = '1' then if reset = '1' then state <= reset_state; tick <= t0; pc <= (pc'range => '0'); ireg <= (ireg'range => '0'); acc <= (acc'range => '0'); iar <= (iar'range => '0'); sp <= (sp'range => '0'); else tick <= nexttick(tick) ; -- advance time by default case state is when reset_state => state <= fetch; tick <= t0; when fetch => if tick = t1 then ireg <= dbus; if tick = t2 then decode; pc <= pc + '1'; tick <= t0; when halt => tick <= t0; -- do nothing when negate => acc <= alu; wrapup; -- load instructions when mload => if ireg(11) = '0' then -- sign extension acc <= x"0" & ireg(11 downto 0); else acc <= x"f" & ireg(11 downto 0); wrapup; when dload => if tick = t1 then acc <= dbus; if tick = t2 then wrapup; when iload => if tick = t1 then iar <= dbus; if tick = t4 then acc <= dbus; if tick = t5 then wrapup; - 6 -

7 -- store instructions when dstore => if tick = t4 then wrapup; when istore => if tick = t1 then iar <= dbus; if tick = t7 then wrapup; -- branch instructions when branch => pc <= x"0" & ireg(11 downto 0); wrapup; when brzero => if acc = x"0000" then pc <= x"0" & ireg(11 downto 0); wrapup; when brpos => if acc(15) = '0' and acc /= x"0000" then pc <= x"0" & ireg(11 downto 0); wrapup; when brneg => if acc(15) = '1' then pc <= x"0" & ireg(11 downto 0); wrapup; -- arithmetic instructions when add => if tick = t1 then acc <= alu; if tick = t2 then wrapup; -- stack instructions when rsp => acc <= sp; wrapup; when wsp => sp <= acc; wrapup; when push => if tick = t4 then sp <= sp - '1'; wrapup; when pop => if tick = t1 then acc <= dbus; if tick = t2 then sp <= sp + '1'; wrapup; when call => if tick = t4 then pc <= x"0" & ireg(11 downto 0); sp <= sp - '1'; wrapup; when ret => if tick = t1 then pc <= dbus; if tick = t2 then sp <= sp + '1'; wrapup; - 7 -

8 when others => state <= halt; end case; end process; process(clk) begin -- perform actions that occur on falling clock edges if clk'event and clk ='0' then if reset = '1' then m_en <= '0'; m_rw <= '1'; abus <= (abus'range => '0'); dbus <= (dbus'range => 'Z'); else case state is when fetch => if tick = t0 then m_en <= '1'; abus <= pc; if tick = t2 then m_en <= '0'; abus <= (abus'range => '0'); when dload => if tick = t0 then m_en <= '1'; abus <= x"0" & ireg(11 downto 0); if tick = t2 then m_en <= '0'; abus <= (abus'range => '0'); when iload => if tick = t0 then m_en <= '1'; abus <= x"0" & ireg(11 downto 0); if tick = t2 then m_en <= '0'; abus <= (abus'range => '0'); if tick = t3 then m_en <= '1'; abus <= iar; if tick = t5 then m_en <= '0'; abus <= (abus'range => '0'); when dstore => if tick = t0 then m_en <= '1'; abus <= x"0" & ireg(11 downto 0); if tick = t1 then m_rw <= '0'; dbus <= acc; if tick = t3 then m_rw <= '1'; if tick = t4 then m_en <= '0'; abus <= (abus'range => '0'); dbus <= (dbus'range => 'Z'); when istore => if tick = t0 then m_en <= '1'; abus <= x"0" & ireg(11 downto 0); if tick = t2 then m_en <= '0'; abus <= (abus'range => '0'); if tick = t3 then m_en <= '1'; abus <= iar; if tick = t4 then m_rw <= '0'; dbus <= acc; if tick = t6 then m_rw <= '1'; if tick = t7 then m_en <= '0'; abus <= (abus'range => '0'); dbus <= (dbus'range => 'Z'); when add => - 8 -

9 if tick = t0 then m_en <= '1'; abus <= x"0" & ireg(11 downto 0); if tick = t2 then m_en <= '0'; abus <= (abus'range => '0'); -- instructions involving the stack when push => if tick = t0 then m_en <= '1'; abus <= sp; if tick = t1 then m_rw <= '0'; dbus <= acc; if tick = t3 then m_rw <= '1'; if tick = t4 then m_en <= '0'; abus <= (abus'range => '0'); dbus <= (dbus'range => 'Z'); when pop => if tick = t0 then m_en <= '1'; abus <= sp + '1'; if tick = t2 then m_en <= '0'; abus <= (abus'range => '0'); when call => if tick = t0 then m_en <= '1'; abus <= sp; if tick = t1 then m_rw <= '0'; dbus <= pc; if tick = t3 then m_rw <= '1'; if tick = t4 then m_en <= '0'; abus <= (abus'range => '0'); dbus <= (dbus'range => 'Z'); when ret => if tick = t0 then m_en <= '1'; abus <= sp + '1'; if tick = t2 then m_en <= '0'; abus <= (abus'range => '0'); when others => -- do nothing end case; end process; end cpuarch; - 9 -

10 Program. The test program appears below. The main program simply calls the subroutine and then stores the returned value in location 001f. The recursive subroutine checks to see if the argument is zero and if so, simply returns (note that the argument and return value are passed in the ACC). If it must make a recursive call, it first stores the argument on the stack and checks to see if the recursive call would cause the stack to overflow (we limit the stack to the last half of memory). The value returned by the recursive call is added to the argument stored on the stack and the result of this addition is returned to the calling program. -- program using recursive subroutine to add ram(0) <= x"103f"; -- SP := x3f ram(1) <= x"0003"; ram(2) <= x"1005"; -- call sumvals(5) ram(3) <= x"b00a"; ram(4) <= x"401f"; -- save result in location x1f ram(5) <= x"0000"; -- halt -- sumvals(k) -- recursively computes k -- algorithm: if k=0 return 0 else return k+sumvals(k-1) -- argument and result passed in accumulator ram(8) <= x"0000"; -- temp1 ram(9) <= x"0000"; -- temp2 ram(10) <= x"700c"; -- if ACC = 0 then return ram(11) <= x"600d"; ram(12) <= x"0006"; ram(13) <= x"0004"; -- store ACC on stack ram(14) <= x"4008"; -- temp1 := ACC ram(15) <= x"0002"; -- if recursive call would cause stack overflow, halt ram(16) <= x"4009"; ram(17) <= x"1fde"; ram(18) <= x"a009"; ram(19) <= x"8015"; ram(20) <= x"0000"; ram(21) <= x"2008"; -- ACC := temp1 ram(22) <= x"1fff"; -- call sumvals(acc-1) ram(23) <= x"a008"; ram(24) <= x"b00a"; ram(25) <= x"4008"; -- add result to argument stored on stack ram(26) <= x"0005"; ram(27) <= x"a008"; ram(28) <= x"0006"; -- return ram(31) <= x"0000"; -- result of computation

11 Simulation results. The results shown below are a zoomed out view of the first third of the simulation run. While details are not visible at this scale, certain things can be seen, as highlighted by the annotations. Specifically, we can see values that are placed on the stack and we can observe changes to the stack pointer and accumulator. The ACC values that are stable for longer periods are the arguments to the sumvals subroutine. stack pointer accumulator stack locations return addr stacked arg stacked arg return addr

12 More simulation results. The results shown below are a zoomed out view of the middle third of the simulation run. stack pointer accumulator

13 Still more simulation results. The results shown below are a zoomed out view of the last third of the simulation run. Here, we can see the results being returned as the recursive subroutine calls unwind stack pointer accumulator final result 15=

14 Simulation details of start of execution. This view shows the instructions preceding the top level call to sumvals, the call itself and the instructions that check to see if the argument is zero. SP := x3f call sumvals(5) if k=0 return

15 Simulation details of start of execution. This segment shows the instructions leading up to the first recursive call of sumvals. Notice that the argument is pushed on the stack and stored in a temporary location. Then the SP value is stored in a temporary location, so we can check it against the limit on the stack value. push ACC temp1 := ACC check for overflow

16 Simulation details of middle of execution. This segment is from the point in the simulation where the recursion starts to unwind. Note that in this case, the call to sumvals returns when it detects that the argument is zero. call sumvals(0) if ACC=0 then return

17 Simulation details of middle of execution. This segment continues the previous segment. Here, the penultimate recursive call to sumvals is adding the value returned to the value it had previously placed on the stack. This is then returned as the subroutine value. return value from recursive call + stored value

18 Simulation details of end of execution. This segment shows the end of execution. In particular, it shows the completion of the top level call to sumvals, followed by the completion of the main program. Note that in sumvals, the argument that was previously stored on the stack is now added to the value that was returned from the recursive call to sumvals. Also note that on completion, SP is equal to 3f, indicating that the stack is now empty. The returned value of 000f is stored in location 001f in the main program. complete top level call save returned value

19 Synthesis report. An abridged version of the synthesis report appears below. This is the synthesis report for the processor only. It does not include the memory. Notes have been added at various points, discussing specific numbers. These are highlighted in bold. Release i - xst G.38 Copyright (c) Xilinx, Inc. All rights reserved.... TABLE OF CONTENTS 1) Synthesis Options Summary 2) HDL Compilation 3) HDL Analysis 4) HDL Synthesis 5) Advanced HDL Synthesis 5.1) HDL Synthesis Report 6) Low Level Synthesis 7) Final Report 7.1) Device utilization summary 7.2) TIMING REPORT... ========================================================================= * HDL Synthesis * ========================================================================= Synthesizing Unit <cpu>. Related source file is C:/260designs/sequential/vhdlAM/cpuStack/cpu.vhd. Found finite state machine <FSM_0> for signal <state> States 20 Transitions 49 Inputs 23 Outputs 20 Clock clk (rising_edge) Reset reset (positive) Reset type synchronous Reset State reset_state Power Up State reset_state Encoding automatic Implementation LUT The section above shows the synthesis of the main controller state machine. It shows 20 states, which is consistent with expectations, since there is a state for each of the 18 instructions, plus a reset state and a fetch state. Found finite state machine <FSM_1> for signal <tick> States 8 Transitions 148 Inputs 20 Outputs 25 Clock clk (rising_edge) Reset reset (positive) Reset type synchronous Reset State t0 Power Up State t0 Encoding automatic Implementation LUT The above section shows the synthesis of the tick state machine. This has eight states, as expected. Found 1-bit register for signal <m_en>. Found 1-bit register for signal <m_rw>

20 Found 16-bit register for signal <abus>. Found 16-bit tristate buffer for signal <dbus>. Found 16-bit adder for signal <$n0080> created at line 252. Found 16-bit adder for signal <$n0096>. Found 16-bit adder for signal <$n0097> created at line 186. Found 16-bit subtractor for signal <$n0100>. Found 16-bit register for signal <acc>. Found 16-bit register for signal <iar>. Found 16-bit register for signal <ireg>. Found 16-bit register for signal <Mtridata_dBus> created at line 280. Found 1-bit register for signal <Mtrien_dBus> created at line 280. Found 16-bit register for signal <pc>. Found 16-bit register for signal <sp>. Found 48 1-bit 2-to-1 multiplexers. Summary: inferred 2 Finite State Machine(s). inferred 115 D-type flip-flop(s). inferred 4 Adder/Subtracter(s). inferred 48 Multiplexer(s). inferred 16 Tristate(s). Unit <cpu> synthesized. The above section summarizes the high level synthesis. We see registers for each of the processor registers, including the new SP. There are also registers for various signals that change value on clock edges. There are three adders indicated. This is one more than was used in the original processor and presumably is used to increment and decrement the SP. The registers listed above account for 115 flip flops. Note that this does not include the flip flops used by the state machines. INFO:Xst: HDL ADVISOR - Resource sharing has identified that some arithmetic operations in this design can share the same physical resources for reduced device utilization. For improved clock frequency you may try to disable resource sharing. ========================================================================= * Advanced HDL Synthesis * ========================================================================= Advanced RAM inference... Advanced multiplier inference... Advanced Registered AddSub inference... Selecting encoding for FSM_1... Optimizing FSM <FSM_1> on signal <tick> with one-hot encoding. Selecting encoding for FSM_0... Optimizing FSM <FSM_0> on signal <state> with one-hot encoding. Dynamic shift register inference... Note that one-hot encoding has been selected for the finite state machines. This means there will be one flip flop per state for these, adding 28 flip flops to the total. ========================================================================= HDL Synthesis Report Macro Statistics # FSMs : 2 # Adders/Subtractors : 4 16-bit subtractor : 1 16-bit adder : 3 # Registers : 38 1-bit register : bit register : 7 # Multiplexers : 3 16-bit 2-to-1 multiplexer : 3 # Tristates : 1 16-bit tristate buffer :

21 ========================================================================= ========================================================================= * Low Level Synthesis * ========================================================================= Optimizing unit <cpu>... Loading device for application Xst from file '2v250.nph' in environment C:/Xilinx. Mapping all equations... Building and optimizing final netlist... Found area constraint ratio of 100 (+ 5) on block cpu, actual ratio is 21. FlipFlop state_ffd9 has been replicated 1 time(s) FlipFlop state_ffd12 has been replicated 1 time(s) FlipFlop state_ffd13 has been replicated 1 time(s) FlipFlop state_ffd2 has been replicated 1 time(s) FlipFlop tick_ffd4 has been replicated 1 time(s) FlipFlop state_ffd19 has been replicated 1 time(s) FlipFlop state_ffd7 has been replicated 1 time(s) FlipFlop tick_ffd8 has been replicated 1 time(s) FlipFlop tick_ffd7 has been replicated 2 time(s) FlipFlop state_ffd17 has been replicated 1 time(s) FlipFlop ireg_15 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_14 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_13 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_12 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_11 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_10 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_9 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_8 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_7 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_6 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_5 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_4 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_3 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_2 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_1 has been replicated 1 time(s) to handle iob=true attribute. FlipFlop ireg_0 has been replicated 1 time(s) to handle iob=true attribute. This above section summarizes flip flop replication, which is done to improve performance for signals that have a high fanout. Replication adds 27 flip flops to the total we would expect otherwise. ========================================================================= * Final Report * ========================================================================= Final Results RTL Top Level Output File Name : cpu.ngr Top Level Output File Name : cpu Output Format : NGC Optimization Goal : Speed Keep Hierarchy : NO Design Statistics # IOs : 132 Macro Statistics : # Registers : 10 # 1-bit register : 3 # 16-bit register : 7 # Multiplexers : 3 # 2-to-1 multiplexer : 3 # Tristates : 1 # 16-bit tristate buffer : 1 # Adders/Subtractors :

22 # 16-bit adder : 3 # 16-bit subtractor : 1 Cell Usage : # BELS : 646 # GND : 1 # LUT1 : 43 # LUT1_L : 5 # LUT2 : 33 # LUT2_D : 1 # LUT2_L : 2 # LUT3 : 106 # LUT3_D : 1 # LUT3_L : 11 # LUT4 : 282 # LUT4_D : 6 # LUT4_L : 32 # MUXCY : 54 # MUXF5 : 7 # VCC : 1 # XORCY : 61 # FlipFlops/Latches : 170 # FDE_1 : 17 # FDR : 46 # FDRE : 35 # FDRS : 51 # FDRS_1 : 17 # FDS : 3 # FDS_1 : 1 # Clock Buffers : 1 # BUFGP : 1 # IO Buffers : 131 # IBUF : 1 # IOBUF : 16 # OBUF : 114 ========================================================================= Device utilization summary: Selected Device : 2v250fg456-6 Number of Slices: 290 out of % Number of Slice Flip Flops: 170 out of % Number of 4 input LUTs: 522 out of % Number of bonded IOBs: 131 out of % Number of GCLKs: 1 out of 16 6% The number of flip flops shown above is 170. This is exactly what one would expect, based on the numbers reported earlier ( =170). The number of LUTs cannot be so easily justified. Given that FPGAs are designed with one LUT per flip flop, it does seem surprising that the circuit implementing the processor uses more than three LUTs per flip flop. From the macro statistics just above, we see there are three 2:1 muxes (one LUT each, or 3 LUTs), three 16 bit adders (32 LUTs each, or 96 LUTs) and one 16 bit subtractor (32 LUTs). This gives us 131 LUTs, about one fourth the total shown in the final summary. Clearly the synthesizer is generating lots of logic that cannot be easily associated with high level blocks like adders, but one can t tell just from the synthesis report what these extra LUTs are being used for