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

//Olof
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc

Reply via email to