2012/2/24 Ouabache Designworks <[email protected]>: > > > 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 >
Yes, this should be fixed in ORPSoCv3. The structure allows for it, but I haven't implemented proper test support yet, so I will put a note on the wiki for now. -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: [email protected] ______________________________________________ FPGA, ASIC, DSP - embedded SoC design _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
