On Fri, Oct 11, 2013 at 2:19 PM, Olof Kindgren <[email protected]> wrote: > On Thu, Oct 10, 2013 at 3:24 PM, Julius Baxter <[email protected]> > wrote: >> >> On Thu, Oct 10, 2013 at 12:31 PM, Davide Rossi <[email protected]> >> wrote: >> > Hi Julius, >> > >> > We are definitively interested in using the gcc regression test for a >> > functional verification of evoultions of the processor as you suggested >> > during the OpenRISC conference. >> > Could you provide some details about how test is performed on the or1200 >> > or >> > mor1kx and/or a link to a document online explaining the procedure? >> > >> > I put also Michael Gautschi, who is the person who has actually done the >> > work on the OR1200 I've presented at during the OpenRISC conference. >> >> Hi guys, >> >> Very good to meet you at ORCONF on the weekend Davide. We were very >> interested to hear about your work, it seems you have achieved an >> appreciable improvement of the OR1200's performance, and it'd be great >> if you could keep the community in the loop with any future >> developments. We'd very much like to see the patches for the work >> you've done so far. >> >> As I was asking when we spoke, I'm interested to know your >> verification plan for the CPU. It's something the project struggles >> with in general, and it'd be great to get more people thinking about >> this. >> >> The approach so far has been to write some directed tests (in C and >> assembly, some in Verilog to test debug features) and see if Linux >> works. Some useful additional test stimulus can be found in the GCC C >> test suite. We compile each of the tests against the bare-metal newlib >> library and launch them in the sim (usually on a cycle-accurate model >> generated by Verilator as that runs 100s of times faster than Icarus). >> Obviously this assumes the compiler is fine and any bugs will be the >> RTL's fault, which has been the case so far. We can compare the >> results of the GCC regression suite run against the RTL model with the >> results from running against or1ksim. They should, ideally, be >> identical. >> >> This process is not documented, but in the mor1kx-dev-env environment >> (on my github, it's a fork of orpsocv2 and I would advise against >> using it for development - efforts should be focused elsewhere such as >> ORPSoCv3 and a unified test suite) I have a script which allows you to >> point to the GCC source directory, and it will compile each of the >> tests and run them. >> >> >> https://github.com/juliusbaxter/mor1kx-dev-env/blob/master/scripts/make/Makefile-gccregression.inc >> >> It's far from the best way to do it, and it's not quite running it the >> way the scripts in GCC run it, but it's better than nothing. >> >> As I mentioned earlier, we'd really like a unified test case project >> to be developed, combining the C and assembly tests from or1ksim, >> ORPSoCv2 and the new ones which have been developed in mor1kx-dev-env. >> But that's in the works (perhaps something I'll get to hack on soon, >> we've been talking about it for years, so it's about time we do >> something on it). >> >> So I hope this is useful to you. Let me know if you have any other >> questions. And don't forget we're in #openrisc on irc.freenode.net if >> you'd like to continue discussions there. >> >> I'm CC'ing the mailing lists as I think this is useful information to >> have on the record. >> >> Cheers >> >> Julius >> _______________________________________________ >> OpenRISC mailing list >> [email protected] >> http://lists.openrisc.net/listinfo/openrisc > > > I created an or1k-tests repo under the openrisc organization on github. We > can decide on structures later, but for now, I think we should just dump > tests from mor1kx-dev-env and orpsocv2 there to have something to start with
Thanks for doing that Olof. With regards to the structure, I think we should at least have the distinction between plain C and assembly tests which should all be able to run and complete on almost any or1k machine (so have no dependency on peripherals), and those which are designed to be used on systems which have at least a certain set of peripherals. I'll start (or contribute to if someone beats me to it) another thread on how I suggest we could initially set up such a repo. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
