scons: `build/ALPHA/gem5.debug' is up to date.
scons: `build/ALPHA_MOESI_hammer/gem5.debug' is up to date.
scons: `build/ALPHA_MESI_CMP_directory/gem5.debug' is up to date.
scons: `build/ALPHA_MOESI_CMP_directory/gem5.debug' is up to date.
scons: `build/ALPHA_MOESI_CMP_token/gem5.debug' is up to
Hi Brad,
The SimpleTimingPort is a packet queue, so the functionality would have
been the same (just with an infinite buffer). Hence, there is no point in
reverting any code. Instead we have to decide what is sensible to model
and then change it to reflect that.
What is the RubyPort actually
changeset 67c8fbe5d629 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=67c8fbe5d629
description:
stats: Bump pc-simple-timing-ruby stats
This patch simply brings the stats for the pc-simple-timing-ruby
regression up to date. The particular regression
Hi folks,
I've been working on re-doing the integration between Gem5 and SST.
The basic idea is to have SST provide the memory hierarchy (caches, main
memory, etc) to processor cores that are provided by Gem5. I've created
an External Connector MemObject that provides a mechanism for SST to
changeset 0679c3554ba3 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=0679c3554ba3
description:
config: correct example ruby scripts
A couple of recent changesets added/deleted/edited some variables
that are needed for running the example ruby
Thanks Andreas for the responses. I think we will eventually determine the
best solution here if we keep this thread up. Let's keep the information
flowing.
So your response brings up several thoughts on my end:
- SimpleTimingPort may be a packet queue today, but back when the RubyPort was
