Specifications: Due Tuesday Sept 30

[Alan Tse]

Reply for any specs you've modified to this thread.
include skeleton, and behavioral expectation.

I'll post an example in a second.

[Alan Tse]

module io (addr, clk, din, dout, ioIn, ioOut, ioSelect, we);
   input [31:0] addr, // address
        din, // input from ram, sync
        ioIn; // input to IO, async
   input     clk, // clk
        we, // write enable
        ioSelect; // selects DP0 or DP1;
   output [31:0] dout, //output to ram, sync
         ioOut; //output of IO, async

Specification:
ioOut is asynchronous; if (ioSelect), ioOut = DP1, else ioOut = DP0.
ioIn is asynchronously inputted.
dout is a synchronous sampled ioIn. Every posedge it should become whatever value ioIn is.

every posedge if (we), check address.
if (0xfffffff0) DP0 = din
if (0xfffffff4) DP1 = din
otherwise nothing should change.

[Michael Chen]

Alan, are u sure u want io to be asyn, because datamem is syncronous, it will mess things up.  We should handle io the same way as regular memory. 

[Alan Tse]

The interface to the memory is synchronous. The only thing that isn't synchronous is the IO stuff. However, whenever we look at the IO stuff and interfade to memory, it is sampled anyway, so it becomes synchronous.

Make sense?

[Alan Tse]

Modified because of updated specs.
Specification (Changes only):
ioIn is asynchronously inputted.
dout set by addr:
if (0xfffffff0) dout = DP0
if (0xfffffff4) dout = DP1
if (0xfffffff8) dout = ioIn // this is sampled so sync
else dout = dout

[Alan Tse]

module datamem (addr, clk, din, dout, we, ioIn, ioOut, ioSelect);
   input [31:0] addr, //address
        din, // data in to memory
        ioIn; // ioBus into memory
   input     clk, // clock
              we, //enable write
        ioSelect; // DP# on ioOut
   output [31:0] dout, // data out of memory
         ioOut; // ioBus out

Specification:
If (addr[31]) din should go to io.v as specified in io.v. dout should be ioIn.
else din, dout should go to the ram.

we should be passed to both ram and io only if (addr[31]) specifies that it goes to io or ram.

[Alan Tse]

module ioInput(clk, ioIn);
   input clk; // clock
   output [31:0] ioIn; //output from text file

Specs:
Every limit clock cycles, this will read a new value from inputFile into ioIn.

This should feed dataMem during simulation.

[Alan Tse]

Reset signal inputted.

[Alan Tse]

module monitor(clk, address, instruction, memOutput, regOutA, regOutB, aluOut, nextPc);
   input clk;
   input [31:0] address,
        instruction,
        memOutput,
        regOutA,
        regOutB,
        aluOut,
        nextPc;

Specifications:
Identical function as before, but with extended instruction recognition, and inputs and outputs must come from different times in the pipeline.

Monitor has its own internal pipeline carrying what it can through. So if monitor needs a value at execute stage, give that value only then.
Monitor will NOT print until it reaches memory stage (4th stage). Current incarnation DOES not handle stalls and pipeline flushes. We'd have to add another signal.
Signals input:
IF:
instruction,
ID:
nextPc - only if we decide branches here. Mike/Brian you'll needa decide where I get nextPc
EX:
regOutA, - before ALU,
regOutB, - before ALU,
address - after ALU
aluOut, - after ALU
MEM:
memOutput

[Alan Tse]

Address should be coming in id stage since its the address of the instruction read from memory.

Also, I might need to know pc+4 for jal so we can verify $ra is being saved correctly. I'm assuming we're getting this from ALUOUT, since ALUOUT is saving into the register anyway.

[Alan Tse]

added 1-bit stall signal.

Expects to receive in id stage.

[Alan Tse]

module processor(
           clk,
         rst,
         rel,
         ioSelect,
         ioIn,
         ioOut,
         pc,
         stat);
   input [31:0] ioIn; //input via switches, only 8 lower bits will have changeable values
   input     clk, //clock
        rst, //reset
        rel, //release
        ioSelect;   //Selects DP0 or DP1
   output [31:0] pc,    //current pc counter for single step
         ioOut; //output to leds
   output [7:0]  stat; //break signals stat

Spec:
Datapath should go into here I guess before it goes to board. Probably should add a debug signal for the oscilliscope.
Processor should perform completely as we expect the onboard chip to perform.

Note: This is really beta.

[Michael Chen]

Are we going to put the slt and shift operation outside of the alu, we need to decide this asap.

[Brandon Ooi]

It might be useful to keep them in and put more control lines. It looks like we have a LOT of functions we haven't implemented.

[Michael Chen]

how are we handling mult and mflo mfhi, in decode or execution, execution is probably better choice, because we need the rs and rt, which might be from the previous instruction

[Alan Tse]

I'd say execution. Ta's also said it during lecture.
All that happens for multu is we get it started, and then dont' let any functions use multu/mfhi/mflo until the multiplier is ready.

[Michael Chen]

Since memory is syncronous, we will not store the output of the memory in another register, it will be send directly to the mux, and then to regFile.  Alan, io need to be syncronous also, how you implement it is up to you, but the interface should be the same as datamem. 

Did anyone figure out how xilinx implement muxes?  The 2 or 3 level muxes is time killer. 

[Alan Tse]

The interface between io, and everything else when its interfaced IS synchronous. The ioIn and ioOut are async but they NEVER interact directly with the datapath. The only time you'll see a value from ioIn is AFTER its been sampled by dout.

[Michael Chen]

I will not put ioInput on the design doc, since it's a small module that we won't see in the top level.  Only top level design need to be on the design doc. You are free to write small module inside your module.  

[Michael Chen]

Since we have a single cycle of branch delay, jal will store pc+8 into ra.

[Brian Wolf]

module regIfId(clk,PC_in,inst_in,PC_out,inst_out);
    input clk;
     input [31:0] PC_in;
     input [31:0] inst_in;
    output [31:0] PC_out;
    output [31:0] inst_out;

Registers between Instruction Fetch and Instruction Decode stages of the pipeline.  PC_out and inst_out are updated with the value of PC_in and inst_in respectively on the rising edge of the clock.

(Note, I've removed inputs from instmem.v and when I created "increment" I accidentally called it incrementer.v  Please make these changes to the design doc as well.)

[Michael Chen]

I already created increment.v.  Why are you storing inst in ifId?  It's a synchronous output from the memory, it's one cycle later, we don't need more delay.  At any rate, you don't need to use a special module, just varReg.  Remember, we are going to use enb and reset to handle the stall and break. 

[Michael Chen]

address might be coming from IF stage, because pc is being updated, nextPc is coming in during the ID stage, for branch, next PC is either pc+4 or pc+4 + extendImmediate

I added break to signal to monitor too.

[Alan Tse]

Make sure you're replying to the proper message, otherwise we can't collapse stuff we needa collapse.

As for address, its the memory address of the instruction being decoded. So the first will in theory be 0x0, second is 0x4, etc.

As for the other stuff, as long as you update the specs, it'd fine.

My question is why monitor needs a break signal. Break is just an instruction right? I can read the instruction and place it properly. If you're worried about behavior, such as the monitor should stop outputting text, I can write it in, but I don't think I need a specific signal to do it.

[Michael Chen]

Monitor now takes in rst, it should reset itself, because we might reset the cpu in the middle to test other functionality.  I took out the break signal.  You should detect it for verification purpose.  If you take the pc during decode stage, the address is pc+4, so you need to subtract 4 to get the correct result.