On Sat, Apr 21, 2012 at 4:58 PM, Ouabache Designworks <[email protected]> wrote: > > >>> Regarding invalidate on reset thing, I don't like that idea. I've >>> proposed a clarification to the BIRs which will make it obvious this >>> must be done in software. >>> >>> >> >> I don't like the invalidate on reset neither ;) >> > > Ok, Which reset are we talking about? We have the initial asynchronous > power on reset where everything is unknown and we should treat cache as > invalid and we have the synchronous soft reset from the debugger where we > may want to preserve the state of the cache. > > In either case reset will disable the ic_en and dc_en signals so that > software can sort it out before reenabling the cache. > > > > Our problem is that we only have one reset input pin into the or1200 so the > logic cannot separate these two types of reset and deal with each of them > in different ways. What we need to do is to create a clkgen block inside > of the or1200 instead of relying on the soc to provide that function. This > block would have separate inputs for the async power on reset, the soft > reset from the debugger and the test_logic_reset from the jtag tap.
Any implementation with the power management block would most likely have that. But I see what you mean - the current reset setup is basically one big hack (partly due to me.) > > By doing this we have multiple resets inside the core that can do one thing > at power on and something else when the debugger takes control. So a power > on reset could invalidate and disable the cache but a soft reset only > disables it. > > We can also do multicycle resets. There will be a async reset that is active > while the power on reset is active and for 2 additional clocks to sync the > deasserting edge to clock. This would only go to a small amount of logic. > The bulk of the logic would be on the sync reset that is active while the > async reset is asserted or while the soft reset from the debugger is active > or for an additional 32 clocks after both inputs are inactive. > > This 32 clock multicycle reset is very useful. For example during the async > reset I can force all 0's onto the address and data going to the R0-R31 > while asserting the write strobe. Now I can guarantee that R0 will be all > 0's out of reset. By adding the multicycle reset I can mux in a 5 bit > counter on the address line during the soft reset and as it counts it will > clear all the rest of the registers. You can't do that when you only have > one reset pin because you need access to the registers while the cpu is held > off from booting. > > The biggest advantage from adding a clkgen module inside of the or1200 is > that we no longer have to have every flipflop in the chip test reset against > the `OR1200_RST_LEVEL define The clkgen module will need to do that but it > controls the polarity of the reset going to the rest of the or1200 and we > can simply define that as active high and be done with it. > > I do have a design for a clkgen module that I have been using that I could > check in. It would add the extra input pins and could drop in to the current > design. If anyone then wanted to add logic that must run only at power on > then my block would provide the reset signal that it needs to do that. If you'd like to propose some additional reset block for the OR1200 please do that, but let's not have that discussion take over in a thread regarding cache control registers. I'm still not convinced we need to go to all of the effort of providing a multiple-reset system to do something which is not making the CPU unusable at boot and can be done later in software. It also adds area and complexity and thus potential for bugs to creep in. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
