2011/12/16 Richard Herveille <[email protected]>: >> 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
Hi again, After reading the arch spec and considering legacy RTL, I agree that we shouldn't make software that presumes that r0 is zero at startup. Citing from the or1k Koran: "An implementation may have several sets of GPRs and use them as shadow registers, switching between them whenever a new exception occurs. The current set is identified by the SR[CID] value. An implementation is not required to initialize GPRs to zero during the reset procedure. The reset exception handler is responsible for initializing GPRs to zero if that is necessary." In general, we have to be careful not to turn or1200 into an FPGA-only implementation -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: [email protected] ______________________________________________ FPGA, ASIC, DSP - embedded SoC design _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
