Blas,
I'm not an expert on the tester myself, so I may be corrected:
Blas Cuesta wrote:
I have some questions about the random tester.
- Is there any manual for the random tester? How does it work? Does it need
any configuration file?
To my knowledge, there is no manual for the tester. The tester works by
approximating a "worst-case-like" interleaving of memory requests to
stress-test a protocol. The random tester does NOT do any formal
model-checking, but does provide good test coverage. The tester DOES
have a configuration file: $GEMS/ruby/config/tester.defaults (these
values override those provided in rubyconfig.defaults).
- On what is the random tester based to check the correctnes of the protocols?
I mean, I would like to know if it uses some generated code from the slicc
files (for example, funtions like getState or setState) or, otherwise, it
only checks that requests are eventually satisfied in a finite period of
time. I want to know that, because the code that runs my modified simulator
is not the same than the generated code from the slicc files. I have done
some changes in the generated files because of slicc limitations.
To Ruby (and the protocol under test), the tester appears to be a group
of processors that issue memory requests. These memory requests tend to
be for similar addresses, again to exercise the coherence mechanisms.
The tester uses its own sub-class of Driver, and runs stand-alone
(without Simics). Whenever a protocol is successfully built, the tester
is also built for that protocol. The executable resides in
$GEMS/ruby/[host type]/generated/[protocol name]/bin/, and is named
tester.exec. Therefore, I would expect that your manual changes to your
protocol should be usable within the tester, provided you have not
modified the interface that a Driver uses to interface with Ruby's
sequencer.
Here is the help output of the tester:
Options:
-h --help
-p <arg> --processors <arg>
-l <arg> --length <arg>
-r <arg> --random <arg>
-z <arg> --trace_input <arg>
-c <arg> --component <arg>
-v <arg> --verbosity <arg>
-o <arg> --debug_output_file <arg>
-s <arg> --start <arg>
-b <arg> --bandwidth <arg>
-t <arg> --threshold <arg>
-k <arg> --think_time <arg>
-q <arg> --locks <arg>
-n <arg> --network <arg>
-a <arg> --procs_per_chip <arg>
-e <arg> --l2_caches <arg>
-m <arg> --memories <arg>
Option --processors (-p) is required.
Either option --length (-l) or --trace_input (-z) must be specified.
Debug components:
s: System
N: Node
q: Queue
e: Event Queue
n: Network
S: Sequencer
t: Tester
g: Generated
l: SLICC
Q: Network Queues
T: Time
i: Network Internals
b: Store Buffer
c: Cache
p: Predictor
a: Allocator
Thus invoking:
$GEMS/amd64-linux/generated/MOSI_SMP_bcast/bin/tester.exec -p 16 -a 1 -l
10000
Would test a 16-proccessor SMP configuration with the MOSI_SMP_bcast
protocol (one processor per chip), for a duration of 10000. I am unsure
what the unit of duration is--I suspect it may be memory requests from
"processor 0", though I could be mistaken.
I hope this information is helpful.
Thanks.
Best regards,
Blas.
Regards,
Dan
The random tester is designed to stress-test the correctness of the
protocols. It catches many errors, but does not have 100% coverage.
--Mike
Blas Cuesta wrote:
Hello!
I have done some modifications in the Token Coherence protocol
implementation
and I would like to check if these changes are correct. Is there any way to
check it? I run some simulations and, If any of them does not fail, I
suppose
the changes are correct. Could anyone tell me if there is another more
reliable method?
Thanks,
Blas.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
|