> I know that for Xilinx the register file is implemented using two block RAMs > which have their contents initialized to zero on start-up. If this is true > of other FPGAs, then there should be no problem. In cases where the reg file > is uninitialized RAM, software generally initializes it anyway, which will > cause a write of 0 to r0. By the way r0 is still written using my patch, it > just always is written with a value of zero.
SRAM-LUT based FPGAs normally write all LUT, DFFs, and bRAM contents. If no pre-loaded value is given, then they're written with '0' (which explains the reset value of FPGA DFFs). This is also part of their BIST procedure. Fused FPGAs don't have this feature, neither do ASICs. It is these cases that you need to handle. So writing '0' during first boot-up (I understand that a simple l.movhi r0,hi(0) is enough) ensures that. I do not see the benefit of adding the additional logic that always writes a '0' (read would be better btw). > As far as using r0 as an special backup register for exception handlers, this > would create unportable code given the lack of direction from the > architecture specification and assumes that the interrupted code isn't r0 for > its own special purposes. To me, there is no way software can safely treat > r0 as anything but 0. Without a clear definition of the behavior of r0, it > is turtles all the way down. I miss the point where R0 behaviour is not clearly defined? R0 must be '0'. How this is achieved is implementation specific; it might be hardwired, it might not be. If your software must operate on any possible implementation then you have to clear the register at boot-up (even if that might not be required). For normal operations R0 can only be read, it may not be used as a destination register. The manual specifically specifies this. The reason for this is that R0 might not be hardwired to zero. Using it as a destination register messes up its intended behaviour. The ONLY exception is during boot-up. Richard > > > ---Matthew Hicks > _______________________________________________ > Openrisc mailing list > [email protected] > http://lists.opencores.org/listinfo/openrisc _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
