control path design and lab 3
play

Control Path Design and Lab 3 1 Separating Control From Data The - PowerPoint PPT Presentation

Control Path Design and Lab 3 1 Separating Control From Data The datapath is where data moves from place to place. Computation happens in the datapath No decisions are made here. Things you should find in a datapath Muxes


  1. Control Path Design and Lab 3 1

  2. Separating Control From Data • The datapath is where data moves from place to place. • Computation happens in the datapath • No decisions are made here. • Things you should find in a datapath • Muxes • Registers • ALUs • Wide busses (34 bits for data. 17 bits for instructions) • These components are physically large • In a real machine, their spatial relationship are important. • Mostly about wiring things up. 2

  3. Separating Control From Data • Control is where decisions are made • Things you will there • State machines • Random lots of complex logic • Little state (maybe just a single register) • Spatial relationships are harder to reason about or exploit. • Because they are qualitatively so different, we will use different coding styles for each. • These are best practices from people who build real chips. • Following them will save you lots of pain • If you don’t follow them, and you have problem, the TAs and I will tell you to go fix the coding style issues first. 3

  4. reset clk control outputs Control inputs Control Signals controlling the datapath Signals providing information to control Data inputs Outputs Datapath reset clk 4

  5. Designing the Control Path • Identify control lines • Inputs from datapath. • Outputs to datapath. • Draw out the state machine • Transitions are defined by inputs from the datapath. • Figure out how the output lines should be set for each state. • Implement! 5

  6. Identifying Outputs • Any element of the control path that has a control input • muxes • alus • enabled registers • Outputs to the outside world that are not data • Data valid lines • If you designed your datapath correctly, this should be all of them. 6

  7. Identify the Inputs • These are all the bits of information that the datapath generates to allow your design to make decisions. • If you thought through your datapath carefully, you should already know what these are. 7

  8. Draw the State Machine • The state machine implements the states that your datapath can be in. • Any activity that takes multiple cycles needs its own state • Blocking on IO • Multi-cycle operations. • Any time an output control line depends on anything but the input control lines from the same cycle, you will need one or more new states. • State transitions are a function of input lines. • Write down the formula for each transition. 8

  9. Computing Outputs • For each state, write down how to compute the outputs from the inputs. • This can be different for different states. • Make a table that describes how each control line will be computed in every state. 9

  10. Implement! • Now that you have a complete design, you can implement. • The control unit should be one module with three always blocks and one register. • One block computes the state transitions. (always@(*)) • One block computes the outputs. (always@(*)) • One block implements the register for the state. (always @ (posedge clk or reset) • Use ‘localparam’ to define state names. -- No magic numbers! (0 and 1 are not magic) 10

  11. Computing State Transitions always @(*) begin // Default is to stay in the same state state_next = state; case ( state ) STATE_1 : if ( something && something_else) state_next = ANOTHER_STATE; ANOTHER_STATE : if ( sky_falls ) state_next = SCREAM; SCREAM : state_next = WAIT; ... endcase end 11

  12. Computing Outputs always @(*) begin //Default control signals some_mux_sel_out = SOME_MUX_SEL_X; reg_en_out = 1'b0; case ( state ) STATE_1: begin some_mux_sel_out = 1’b1; end ANOTHER_STATE: if ( sufficient_love_in ) begin reg_en_out = 1’b1; end else if ( is_monday_in ) begin reg_en_out = 1’b0; end ... endcase end 12

  13. Implementing the State always @(posedge clk or reset) if (reset) state <= WAIT; else state <= state_next; 13

  14. GCD Example • See the 02_Verilog2.pdf slides from last week. • And the implementation I uploaded. 14

  15. TrivialScalar TrivialScalar_Control -- Lab 3 run_stall_reset regfile_write_en dmem_write_en read_write_req op_code inst reg_sel +1 next_pc r1 r2 v1 Reg ALU Decode File 0 PC Imem imm r_data v2 ld_data Dmem result st_data addr in_ack out_ack out_data in_data out_req in_req IO Interface 15

  16. 16

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend