Re: [Gems-users] Checking new protocol


Date: Wed, 15 Feb 2006 09:26:26 -0600 (CST)
From: Mike Marty <mikem@xxxxxxxxxxx>
Subject: Re: [Gems-users] Checking new protocol
> - Is there any manual for the random tester? How does it work? Does it need
> any configuration file?
>

The basics of running the tester is described on the "Debugging a
Protocol" page on the documentation wiki.  But the email Dan just sent
covers more of this.

> - 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.
>

The tester has several different modes.  It can playback traces, perform
some microbenchmarks, and more.  However to test the correctness of a
protocol, the default mode should be used.

The basic idea is that the tester generates a sequences of coherence
operations between processors, with large amounts of false sharing, and
actually checks the data values to ensure that coherence was not violated.
We typically set the "RANDOMIZATION" network parameter to true so that the
interconnect will randomly delay messages.  This excites potential
coherence bugs.

The default tester.defaults file has RANDOMIZATION set to true, and
g_SYNTHETIC_DRIVER and g_DETERMINISTIC_DRIVER set to false.  This is what
you want to stress-test a protocol.  It also configures the L1 and L2
caches sizes to be extremely small to excite request/writeback races.

A solid test run should be at least 500,000 transactions specified by the
"-l" parameter.

--Mike


[← Prev in Thread] Current Thread [Next in Thread→]