Jesus,
I looked over the steps you described, and I do not see any obvious
problems. However, Tom and I have not tested the 'test' SPEC2K inputs
very much, we performed most work with the 'ref' inputs.
The error you are getting may be related to the simulator executing
more instructions than are supported by the live-point being used.
Again, this does not seem to be the case given the arguments you are
using, but perhaps it is occuring anyway.
Please tell us if you are contiunuing to have this problem with the
'ref' inputs. If so, we will try to recreate this error so we can debug
it. Thanks!
Roland
== == ==
== Roland Wunderlich -- [email protected]
== Computer Architecture Laboratory at Carnegie Mellon
Jesus Hernandez Tapia wrote:
> Hi again !
>
> I have downloaded TurboSMARTS, and compiled all the tools and simulators with
> gcc 2.95.3 ( SimpleScalar configured as ALPHA).
>
> I am trying to go trough the example included in the documentation (mcf
> benchmark with the test input), and I am having some problems in the final
> stages. Here is a step by step description of what I am doing :
>
> SETUP :
> TurboSMARTS directory: ~/ss3
> Mcf executable ( compiled for alpha) : ~/ss3/CINT2000/181.mcf/exe/mcf_peak.ev6
> Test input for mcf benchmark:
> ~/SPEC_2000/benchspec/CINT2000/181.mcf/data/test/input/inp.in
>
> 1) Obtain the estimated value for the k parameter:
>
> ./sim-outorder -estimate_k 1:3.0:3.0
> CINT2000/181.mcf/exe/mcf_peak.ev6
> /home/jtapia/SPEC_2000/benchspec/CINT2000/181.mcf/data/test/input/inp.in
>
> output:
>
> Determined checkpoint library size for sample_CPI_mean @ Z=3.00 pctError=3.00
> Library Size: 14938 Corresponding k: 13 Unit size: 1000
>
>
> 2) Create live-points library:
>
> ./sim-mklvpt -sampling 13 -library mcf-test
> CINT2000/181.mcf/exe/mcf_peak.ev6
> /home/jtapia/SPEC_2000/benchspec/CINT2000/181.mcf/data/test/input/inp.in
>
> This step creates files: mcf-test.00.lvpt and mcf-test.01.lvpt
>
> The output is:
>
> sim: ** simulation statistics **
> sim_ckpt_insn 47064000 # total number of instructions included
> in
> live-points
> sim_pop_insn 203947105 # total number of instructions in
> application
> sim_num_ckpt 15688 # Number of checkpoints collected
> sim_ckpt_lines 2967072 # Number of cache lines stored in all
> live-points
> lines_per_ckpt 189.1300 # average cache lines per live-point
> sim_sample_size 15688 # sample size when sampling is enabled
> sim_sample_period 13000 # sampling period when sampling is enabled
> sim_elapsed_time 891 # total simulation time in seconds
> sim_pop_rate 228896.8631 # simulation speed (in all simulated
> insts/sec)
> (snip)
>
>
> 3) Shuffle the live-points library:
>
> ./shuffle mcf-test
>
> This step creates files: shuffled.mcf-test.00.lvpt and
> shuffled.mcf-test.01.lvpt
>
> Output:
> Wrote: 15688
>
>
> 4) The problem happens when I try to do the baseline experiment:
>
> ./sim-oolvpt -all_lvpts -library shuffled.mcf-test -paired:write mcf.baseline
>
> CINT2000/181.mcf/exe/mcf_peak.ev6
>
> The process stops with the following output:
>
> Impetus-version-tag: sim-oolvpt - TurboSMARTSim 1.0
> WATTCH_ENABLED true # wattch code is enabled
> WATTCH_DYNAMIC_POWER false # wattch does not use dynamic power
>
> 128 live-points done. CPI: 2.2448 Current conf. (Z=3.00): +/- 32.47%.
> CTRL-C
> to stop now.
> fatal: non-speculative fault (2) detected @ 0x1200096e0
>
>
>
> Am I doing something wrong?
> I have tried with gcc/test inputs and I am having the same kind of error .
> Would it be because of the size of the test inputs?
> I am running everything again with gcc and the reference inputs, I'll post
> the
> results.
>
> Any help will be greately appreciated ,
>
> Sorry for the long post and thank you for reading it.
>
> Regards,
>
> Jesus
>
> _______________________________________________
> SimFlex mailing list
> [email protected]
> https://sos.ece.cmu.edu/mailman/listinfo/simflex
> SimFlex web page: http://www.ece.cmu.edu/~simflex
From penglu01 at hotmail.com Thu Dec 8 22:52:59 2005
From: penglu01 at hotmail.com (lu peng)
List-Post: [email protected]
Date: Thu Dec 8 22:53:20 2005
Subject: [Simflex] A question about Synchronization
Message-ID: <[email protected]>
An HTML attachment was scrubbed...
URL:
http://sos.ece.cmu.edu/pipermail/simflex/attachments/20051209/2f812307/attachment.html
From twenisch at ece.cmu.edu Fri Dec 9 16:21:12 2005
From: twenisch at ece.cmu.edu (Thomas Wenisch)
List-Post: [email protected]
Date: Fri Dec 9 16:20:49 2005
Subject: [Simflex] Re: A question about Synchronization
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <pine.lnx.4.53l-ece.cmu.edu.0512091606560.3...@dalmore.ece.cmu.edu>
Hi Lu,
On Fri, 9 Dec 2005, lu peng wrote:
> Hi Tom,
>
> How are you doing? I am trying to understand the simflex implementation
> mechanism of Synchroniztion. For example, if multiple processors in a CMP
> system compete
> for a critical section, who will first enter the CS? Random or any priority?
> As a virtual machine, does the simflex implement this arbitrator? If so,
> could you
> point which file & function?
There is no explicit synchronization component in SimFlex.
Synchronization works exactly as it would on a real SPARC machine. For
example, in a critical section, one CPU will acquire a lock (most likely
via some read-modify-write instruction) by setting a memory flag. Other
CPUs will then spin waiting for the lock to be released.
Whether this is fair, deadlock free, etc, is completely up to the
software. In the event of races, whichever one gets to the lock variable
first wins. In the CMP, the point of serialization is the L2 cache. In
the DSM, the point of serialization is in the protocol engine/local engine
components.
Flexus maintains cache coherence and memory consistency (relative
ordering of memory operations across CPUs) exactly as real SPARC CPUs.
You can configure Flexus for either sequential consistency or total store
order consistency. If you are not familiar with memory consistency
issues, I suggest starting with the following paper:
"Shared Memory Consistency Models: A Tutorial" S. Adva, K. Gharachorloo.
Digital WRL research reort 95/7, Sept. 1995.
>
> Thanks and wish you will have a great holday.
Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University
>
> Lu
>
>
>
From penglu01 at hotmail.com Mon Dec 12 17:36:03 2005
From: penglu01 at hotmail.com (lu peng)
List-Post: [email protected]
Date: Mon Dec 12 17:36:11 2005
Subject: [Simflex] About x86 module of Simflex
In-Reply-To: <pine.lnx.4.53l-ece.cmu.edu.0512091606560.3...@dalmore.ece.cmu.edu>
Message-ID: <[email protected]>
An HTML attachment was scrubbed...
URL:
http://sos.ece.cmu.edu/pipermail/simflex/attachments/20051212/fb4761ba/attachment.html
From twenisch at ece.cmu.edu Tue Dec 13 14:43:40 2005
From: twenisch at ece.cmu.edu (Thomas Wenisch)
List-Post: [email protected]
Date: Tue Dec 13 14:43:30 2005
Subject: [Simflex] Re: About x86 module of Simflex
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <pine.lnx.4.53l-ece.cmu.edu.0512131439370.25...@dalmore.ece.cmu.edu>
Hi Lu,
We do not have out-of-order x86 support. There are no immediate plans to
implement out-of-order x86, as we (at CMU) have already made substantial
investment in tuning our commercial applications on sparc platforms. We
will, however, be releasing toolkits for our TPC-C and TPC-H setups in the
near future.
Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University
On Mon, 12 Dec 2005, lu peng wrote:
>
> Hi Tom,
>
> Thank you for your reply. I noticed that some others are using x86 module of
> simflex. I also checked a post in July. Seems that you only had an in order
> x86
> module. Do you have an out-of-order x86 module now?
>
> Thanks,
>
> Lu
>
>
>
