seblovett / VLSI

VLSI design project
0 stars 1 forks source link

Alu decoder #78

Closed ashleyjr closed 10 years ago

ashleyjr commented 10 years ago

@mw92 While cutting back the controller I found the decoder wasn't compatible with the design. I cobbled one together in a different branch. See AluDecode_170314: aluDecode.sv . Does this describe everything the decoder does?

Bearing in mind flag stuff is handled in the alu model

mw92 commented 10 years ago

I dont see how that new file represents decoder, it only has one control signal when there are multiple control outputs

ashleyjr commented 10 years ago

True but I believe in the behavioural we don't want those control signals. We're abstracted form any nasties; for example sh8,sh4,sh2,sh1 concatenation just become a Op1 << Op2.

We can expand our model to be more accurate of the actual hardware. The question is a what level do we stop, when our behavioural is almost a netlist? More control signals may be worth pursuing. Thoughts @seblovett ?

mw92 commented 10 years ago

The design of the behavioural is down to you guys, id of just thought the I/Os of each module would match.

ashleyjr commented 10 years ago

Ok, if no objections I will continue on the current path

seblovett commented 10 years ago

@mw92 I would agree to an extent that the I/Os should match, but I say treat the Alu and Alu decoder as one behavioural module. I/ps to decoder should be Opcode[4:0], A[15:0], B[15:0], CFlag outputs: AluResult[15:0], Flags[3:0] (N.B. the Alu Override is probably best suited in datapath.sv @ashleyjr we'll chat about this briefly today, or if you want to come in before our meet, I should be in labs from 10:45 onwards.