On 12/1/12, Peter Gavin <[email protected]> wrote: > Hi guys, > > Since we're doing ISA updates, I think might be useful to add a halt > instruction. In the simulator, it could be used to actually halt the > simulation. In a real CPU, this should probably just put the CPU to sleep > until an interrupt occurs.
Hi Pete, I'm easy on this - I believe ARM have the "WFI" instruction, or wait-for-interrupt, which is just what you propose, so there's certainly precedent for this sort of thing. I have added this functionality to the pronto-espersso pipeline in the mor1kx by making the l.j 0 instruction (0x00000000) shut down the fetch stage and only restart to service tick timer or PIC interrupts. (I intend to add a checker, too, to test if we ever see a "l.j 0" insn and the PIC or TT units aren't set up then clearly something is wrong, and warn.) This isn't the best solution, but I think it's perfectly reasonable to add implementation-dependent behavior like that to achieve the sort of thing you're suggesting here. But probably what you want is something with defined behavior in terms of power-saving modes, like what clocks can be turned off or reduced in frequency, what the longest "wake" latency is, etc. > > I also think we should deprecate the l.nop hacks we have everywhere in the > various simulators. They're primarily used for I/O and halting the > simulator. Since pretty much every implementation includes a UART, and a > UART is pretty easy to implement, perhaps we should (for example) modify > the or1ksim testsuite to output its diagnostic messages on the UART instead > of using nops. This would also help with building a testsuite that can run > on both simulators and real systems. I quite like the l.nop trickery, and if anything I'd like for us to use more of them! :) UARTs are too slow to simulate in Icarus, and for small point tests of functionality, 99% of your simulation cycles will be spent printing out the finish message. I'm totally into the idea of having a unified test suite, that's really what we want to end up with, and certainly something which is capable of running in sim and on physical targets. But there's going to be tests which just cannot be run in simulation due to time (ie, running millions of test vectors through the multiplier) and we'll need a way of separating those, or configuring the same software to run a reduced set. We could perhaps introduced the concept of a "debug UART" which is l.nop printchars in sim and an actual UART in physical implementations. That would be pretty cool. But I'd say stick with the l.nop trickery even for that debug output on physical targets, so that the binary remains the same. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
