RISC implementation questions

Hi there

I have some general question for implementing a general RISC architecture. I have coded so far the fetch, decode, execute and writeback stage.

1) Next step is to implement forwarding. Do I have here a 2:1 multiplexer in front of the alu that takes as input the output of the alu of the former cycle and the source register and the decode stage then sets the multiplexer select signal ?

2) How is it working with a NOP instruction? Does there the alu "execute" for example a R0 = R0 + R0. As R0 is always zero this doesnt have any effect. Or is there somehow an additional signal from the decode stage that tells the alu to do nothing?

3) Normally the writeback is done in the first half of the clock cycle whereas the registers are read in the second half in the decode register. Does this mean that the decode logic just works in the second half of the clock cycle or does it do some stuff in the first clock cycle and then just read out the operands in the second half of the cycle?

I know some easy questions but would be helpful for understanding to know this ;)

Cheers, Patrick

Reply to
Patrick
Loading thread data ...

"Patrick" wrote

Typically the 2:1 muxes are *ahead* of the ALU input operand registers. Call them A and B.

Then one pipeline recurrence might be A -> ALU -> result mux -> A fwd mux -> A etc, assuming you have no MEM pipeline stage.

Yes.

No, rather it probably does an add of 0 + 0.

It all depends upon your datapath and pipeline design. Once the IR is latched in FFs it is decoded "continuously".

See also:

formatting link
formatting link

Jan Gray

Reply to
Jan Gray

Thanks for your answers Jan, one more issue

In the end there will be a Mem Pipeline. In that case I have a 3:1 mux and the decode logic selects then the correspoding value to use, either the forward of the alu, of the mem or of the register file. Is that correct?

Cheers, Patrick

Reply to
Patrick

Yes, Patrick, that's exactly right. Note, if you have a shifter, or jump-and-link, or anything else that produces a value into a register, you may need to mux that result in and forward that as well.

Another good reference is Computer Organization and Design by Patterson and Henessey.

Have fun! Jan.

Reply to
Jan Gray

Patrick schrieb:

That depends on your architecture. If you use flags like ZERO or CARRY which are set on every ALU operation coding NOP as "ADD r0, r0, r0" might not be a good idea.

Otherwise, as your register r0 is read-only, you can do this and get your NOP for free in terms of required opcodes. Likewise you can emulate register moves with "ADD r_dest, r_source, r0".

If you can encode your NOP instruction as "0...0" life will be easier as internal FPGA memories cells are typically set to 0 on configuration.

Best regards Andreas

Reply to
Andreas Hofmann

Have a look at "Logic and Computer Design Fundamentals" by Mano and Kime, 2nd edition pages 542-562

Ben

Reply to
Ben Popoola

I am just implementing the backend of the processor and some issues came up where I am not so sure how to handle them in a proper way. Lets assume I have two Execution Units (1 cycle delay), one memory pipeline (2 cycle delay) and one multiplier(n cycle delay). Lets say I wanna have two write back ports to the register file, so normally they are occupied by the two integer execution units. If there is a load in the memory pipeline then I need in the end one of the write ports and its not possible that both EXECUTION units write a result back. In other words, I cant do an NOP with ADD r0, r0, r0 as then two entities (if the mempipe has dealt with a load instruction) try to write to one write ports. So I assume I need here two additional signals that tell me that either the output of the alu is valid and should be written into the regfile or that the load is finished and has fetch a valid value from the datacache that is ready to be written back into the regfile. Is this a good approach or complete nonsense?

Cheers

Reply to
Patrick

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.