On Tue, Dec 04, 2012 at 01:11:47PM -0500, Peter Gavin wrote: > On Tue, Dec 4, 2012 at 7:22 AM, Stefan Kristiansson < > [email protected]> wrote: > > > Actually, reading your message again and giving this some more thought > > I kind of see what you mean, if you want to have the register output > > ready when you are doing the instruction decoding, you're kind of screwed > > since you don't have the register address in the l.nop instruction. > > > > Ideally, you'd connect the RA and RB fields directly from instruction > cache's output port to the address port of the register file (assuming > synchronous SRAMs). >
Yes, this was exactly what I realised that you meant. I guess I was a bit 'homeblind' working on the mor1kx cappuccino pipeline for the last week or so, there we use the addresses in decode stage for the register file (i.e. register output is ready in execute stage). Doing so, we are of course only able to resolve branches in decode stage for branches to immediates, but they are far more common than jump to register. I guess for architectures like Mips it's a lot more important to have the register output in decode stage, since their conditional branches also depend on having the register output ready. Apart from resolving branches early, are there other benefits of having the RA and RB fields directly connected to icache output? Another aspect is of course that the SRAM outputs of the register file is potentially slow paths, registering it for execute stage might be beneficial in that regard. Otoh, there is bound to be a bit of logic hooked up to the register file addresses to handle hazards and if you want to get the instruction as fast as possible during a icache refill you're bound to kind of connect it straight to the data input of the instruction bus (which potentially will be a very long slow path). This is just me speculating though, I haven't really looked closer at the pros and cons, so if you have any hands on experience, let us know. > If the nop format was changed so that e.g. bits 20-16 always held the value > 3, that would do the trick. > Yes, or perhaps just define it as a new 'debug' instruction (which is essentially the same). In any case, I think it sounds like a good idea. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
