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) • 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_happiness_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) if (reset) state <= WAIT; else state <= state_next; or dff #( .WIDTH(3) ) state_dff ( .d(state_next), .q(state), .clk(clk), .reset(reset) ); 13

  14. Trivialscalar State Machine other inst HALT RUN HALT instruction in_ack signal the READ out_ack following instruction signal IO cycle LD WRITE READ instruction instruction DMEM in_ack low IO READ WRITE out_ack low 14

  15. State Transition Conditions Current state DMem Run halt IO Read IO WRite Read Run Halt Next state IO READ IO Write DMem Read 15

  16. Control line settings run_stall_reset_sel dmem_write_en read_write_req reg_sel regfile_write_en op_code in_req out_req Run Halt IO Read IO Write DMem Read 16

  17. GCD Example • See the slides from last week • And the implementation on the web site. 17

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