Closed ashleyjr closed 10 years ago
I dont see how that new file represents decoder, it only has one control signal when there are multiple control outputs
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 ?
The design of the behavioural is down to you guys, id of just thought the I/Os of each module would match.
Ok, if no objections I will continue on the current path
@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.
@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