On Thu, Dec 15, 2011 at 10:09 AM, Julius Baxter <[email protected]>wrote:
> On Thu, Dec 15, 2011 at 3:57 PM, Matthew Hicks <[email protected]> > wrote: > > The method I used is just as synthesizable as the readmem tasks, plus you > > don't need to keep an external file. The method I used is also more > modular > > and scalable than readmem. > > > > I agree that a better fix is to correct the OR32 boot code, but I also > like > > initializing the memories to make RTL simulation closer to hardware > > execution. > > > > If you want to make the RTL simulation closer to what you experience > with hardware, I would fill the RAMs with random values, not zeroes. > > I agree. > Sometimes it's good to have X go everywhere, because it doesn't let > you get away with not initialising things properly. In this case I > think X is a good thing. > > I agree here to, but when the software doesn't initialize things properly, it is a pain to debug. The simulation doesn't just stop, it locks. > In what way is the Linux boot code not compatible with RTL simulation, > ie where is it using registers before initialising them? > The caches and the register file are the main problems that I know of. The TLBs may or may not be a problem. With the register file, specifically r0 is the problem, the rest are initialized to 0. ---Matthew Hicks
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
