Well, it seems this is most likely caused by a bug I reported for b3. The url is http://www.m5sim.org/flyspray/task/287 And it seems the problem is not corrected in b4. ---------------------------------------- > Date: Wed, 9 Jan 2008 15:25:28 -0800 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: [m5-users] ALPHA SE Something is wrong with sqrtt > CC: m5-users@m5sim.org > > To clarify, I set opLat=24 and issueLat=12 for FloatSqrt in > FuncUnitConfig.py in order to fix the problem. > > -Rick > > Rick Strong wrote: >> I think you may be right about the latency. I went into >> src/cpu/o3/FuncUnitConfig.py and set the latency of FloatSqrt to 12, >> and it appears to work. I hope that points someone in the right >> direction and towards a solution. >> >> -Rick >> >> Kevin Lim wrote: >>> Hi Rick, >>> >>> There may be an issue with the CPU thinking there's no activity left >>> due to the long latency of the instruction, and then not waking up >>> properly when the instruction completes. I'm not sure why it'd be on >>> that instruction in particular though. I'm going to try your example >>> and see if I can get some more information about why it might be >>> doing this. This may take me some time as I don't have a clean up to >>> date tree at the moment. Could you send me your exact command line, >>> as well as any diffs on any of the configuration files you made? >>> >>> In the meantime, try this: in your configuration file where you >>> select the O3CPU (most likely Simulation.py if you're just using our >>> default configs), try setting the parameter "activity" to 1. This >>> should (hopefully) prevent the O3CPU from going to sleep if it's >>> inactive. If the program runs properly as a result, then this is >>> most likely the culprit. You may get very minor statistics >>> differences if you set this to 1. >>> >>> Kevin >>> >>> Rick Strong wrote: >>>> Hi all, >>>> >>>> I have been tracking down a problem with resuming a few benchmarks >>>> which include (fma3d, ammp, apsi, mgrid, and others) at certain >>>> checkpoints. The culprit appears to be a sqrtt (FloatSqrt) operation >>>> that gets stuck at the head of the queue and stalls the detailed >>>> model (O3CPU). If I run the benchmark in AtomicSimpleCPU there is no >>>> problem. I have confirmed that sqrtt is at the head of the queue in >>>> four samples (two in ammp and two in apsi). The simulation ends with >>>> ("Exiting @ cycle 9223372036854775807 because simulate() limit >>>> reached.") . The same symptoms are seen in other benchmarks >>>> suffering a similar phenomena and I guess that sqrtt may also be the >>>> culprit. If anyone has some insight on what might be happening, it >>>> would be appreciated. >>>> >>>> -Rick >>>> _______________________________________________ >>>> m5-users mailing list >>>> m5-users@m5sim.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>> >>>> >>> >> >> > > _______________________________________________ > m5-users mailing list > m5-users@m5sim.org > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
