On Sun, Feb 16, 2014 at 10:38 AM, Sébastien Bourdeauducq <[email protected]> wrote: > On 02/16/2014 02:42 AM, Stefan Kristiansson wrote: >> As I already mentioned in the #m-labs IRC channel a while back, >> there's already implementations (mor1kx) that are faster than LM32 in >> benchmarks. > > Hmm, when I tried synthesizing it (without MMU), the clock frequency was > noticeably lower than LM32's. This is a serious problem as it will slow > down not only the core (which might offset the speed improvement you are > talking about), but the whole system-on-chip. That is, unless there are > clock domain transfers around the CPU, but those increase bus latency > and further kill the CPU performance. >
As I also mentioned before was that last I tried synthesizing mor1kx in the (now dated) milkymist-ng soc, I passed the 83 MHz timing constraint without errors. I now tested with the git head of mor1kx, and it went through without timing errors. I however noticed that I had a couple of local changes to https://github.com/skristiansson/milkymist-ng-mor1kx that I hadn't pushed. Could you try with the set of parameters I'm using, they should match what lm32 supports and what you are using. For your convenience, these are the parameters I'm speaking about. https://github.com/skristiansson/milkymist-ng-mor1kx/blob/master/milkymist/mor1kx/__init__.py If you are still getting poor results with that set of parameters (or either case), could you share the setup you are using, so I could take a peek at where the critical paths are. >> As for area, it is hard to make a *really* small OpenRISC 1000 >> implementation, since there are features in the architecture that >> prevents that (a lot of SPRs that are mandatory for example). > > Can those be removed from the specification? > No, probably not from the specification (or more precisely, I don't think we want to remove them). Let me give an example, we have a set of SPRs that gives information about what units are present, the version, revision etc of the core. That's stuff we want to have there, and generic software cares about it. Now, if you have a set of very specialized software that only care about a given set of features, you could probably care less about what version the core is and what set of units are present. Those particular SPRs doesn't of course take a lot of space, but they serve a good example of the "problem". But hey, it's open source, so you're also of course free to rip out all cruft of it and make it as spec non-compliant as you wish =) Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
