On Fri, Dec 16, 2011 at 3:56 PM, Julius Baxter <[email protected]> wrote: > On Fri, Dec 16, 2011 at 3:47 PM, Matthew Hicks <[email protected]> wrote: >> On Fri, Dec 16, 2011 at 3:06 AM, Richard Herveille <[email protected]> >> wrote: >>> >>> > The problem, perhaps, is that the register clear is assuming that r0 >>> > really is 0...??? Perhaps the first thing we should be doing is loading >>> > r0 with a 0: >>> > >>> > l.movhi r0,hi(0) >>> > l.ori r0,r0,0 >>> >>> >>> I don't think that piece of code loads R0 with '0' ... >>> Assume R0 is NOT zero then: >>> >>> movhi r0,hi(0) --> set MSBs to 0 >>> ori r0,r0,0 --> logic OR of R0 with R0 and '0' ... This does NOT clear >>> the LSBs!! >>> >>> >>> >>> Richard >>> >> >> Actually, all you need is l.movhi, which clears the lower 16-bits. >> > > I agree. > > Stefan, your use of "l.andi r0, r0, 0" still won't work because in > simulation 1'bX & 1'b0 = 1'bX
I think I'm actually wrong on this. My intuition tells me anything with an X in it goes to X, so they're to be avoided at all costs. But section 4.1.8 of http://www.cs.bilkent.edu.tr/~ozturk/cs223/VerilogLangRefManual.pdf tells me I'm wrong and 1'b0 & 1'bX = 1'b0 Whoops. But in a processor, I'm not sure you want to be bringing X through the ALU for an operation like that. I'd feel safer with l.movhi r0 which, has no source registers and so has no reason to be putting X into your ALU which might get through to your control path. (It's probably bad design if it is, though.) Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
