Speaking of debug, what will be the strategy for mor1kx: --debug stub or -- adbg (this was giving problems the last time I tried, and although it works with or1200 the adbg's RTL needs a lot of rewriting... just ask Verilator why)
? We are sort of planning a Bluetooth Low energy chip using an open source processor and LM32 appears a serious contender to mor1kx. OR1200 is out of the question. On Tue, Apr 29, 2014 at 7:21 AM, Stefan Kristiansson < [email protected]> wrote: > On Tue, Apr 29, 2014 at 2:28 AM, Julius Baxter <[email protected]> > wrote: > > > > I like the idea of not bothering with a true SPR to store this state, > > because you're checking it anyway when l.b[n]f'ing after the l.swa. > > It's also a bit of state which you don't need to save during an > > exception. My only concern is that it's not visible to a debugger, but > > I'm not sure it really matters. > > > > I don't think this is generally visible to debuggers on other CPUs, so > I also doubt it's an issue. > Does anyone else have any insight on this? > > > In terms of implementation, have you found the additional > > infrastructure required (I presume exposure of the atomic access state > > per processor to some snoop logic near the shared memory) to > > complicate matters? > > AFAIK, you don't need to export the atomic access state, what you need > to do is expose the snoop addresses to the atomic access logic. > In the implementation I've done, snooping isn't done at all (i.e., > it's only for single core), however as seen in the Stefan > Wallentowitz's message in the other thread, he has added this logic: > > https://github.com/wallento/mor1kx/commit/2372e0b69eb1091f377a1ea32072758f219ce294 > > > Do these accesses appear like peripheral accesses > > (that is, to volatile memory areas like anything with address bit 31 > > set, typically) to the caches, so that they are never cached? > > > > No, in terms of load/store instructions, they act exactly the same as > l.lwz and l.sw. > > Stefan > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc > -- Jose T. de Sousa, PhD Office: +351 213 100 213 R. Alves Redol 9 1000-029 Lisboa Portugal
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
