Re: [Gems-users] Checking new protocol

[Dan Gibson <degibson@xxxxxxxx>]

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
>