On Fri, Feb 24, 2012 at 6:58 AM, R. Diez <[email protected]>wrote:
> > I also noticed that, although the top-level test driver is a makefile, it > breaks when running in parallel mode (when invoking GNU Make with option -j > N). The tests must be run sequentially, so that only one CPU ever gets busy. > > Regards, > R. Diez > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc > I don't think that you can run the suite in parallel because all the sims run in the sim/run directory and they all use the same sram.vmem file to link to their rom image file. To fix this you would need to create a separate subdirectory for each sim AND pass the filename for the rom image into the sim as a parameter. That way you can also support multicore designs that have more than one rom image file. It also eliminates the need for the /sim/out directory since all log and vcd dump files are stored inside a separate directory. Thats what I do in my design environment. I create a sim/icarus directory and underneath that I have a separate subdirectory for each simulation. You want to give each tool its own separate space in case you ever want to use more than one at a time. I don't link the rom image file but rather pass the relative path name into the sim. The bits only live in the /sw directory where they were compiled. With all the multicore processors out there this would be a useful change to make for orpsocv3. You also want to break the dependency where each sim is locked in with a software test and you call the sim by calling the software test. I do sims where one piece of software is used by many different sims. I can change the parameters for each sim as well and stimulus and responses on a sim by sim basis. You need that flexibility if you ever want to build a complete test suite. John Eaton
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
