DOC PREVIEW
UCSD CSE 141L - Control Path Design and Lab 3

This preview shows page 1-2-3-4-5-6 out of 17 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Control Path Design and Lab 31Separating 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.2Separating 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.34ControlDatapathSignals controlling the datapathSignals providing information to controlOutputsData inputsControl inputscontrol outputsclkresetclkreset5Designing 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!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.6Identify 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.7Draw 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.8Computing 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.9Implement!•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)10Computing State Transitions11always @(*) 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 endComputing Outputs12 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 ) beginreg_en_out = 1’b1; end else if ( is_monday_in ) beginreg_en_out = 1’b0; end ... endcase endImplementing the State13 always @(posedge clk) if (reset) state <= WAIT; else state <= state_next;ordff #( .WIDTH(3) ) state_dff ( .d(state_next), .q(state), .clk(clk), .reset(reset) );Trivialscalar State Machine14IOREADIOWRITEHALTRUNWRITEinstructionout_ack signalREADinstructionin_acksignalHALTinstructionDMEM READLDinstructionthefollowingcycleother instin_ack lowout_ack lowState Transition Conditions15RunhaltIO ReadIO WRiteDMem ReadRunHaltIO READIO WriteDMem ReadCurrent stateNext stateControl line settings16RunHaltIO ReadIO WriteDMem Readrun_stall_reset_seldmem_write_enread_write_reqreg_selregfile_write_enop_codein_reqout_req17GCD Example•See the slides from last week•And the implementation on the web


View Full Document

UCSD CSE 141L - Control Path Design and Lab 3

Download Control Path Design and Lab 3
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Control Path Design and Lab 3 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Control Path Design and Lab 3 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?