Updates to DRAMSim2

[Paul Rosenfeld]

Hello all,

Recently, Arun has asked me to merge my 'develop' branch into master to fix some problems and add some features. Mostly I have been saving these so I wouldn't break SST with API changes, but I'm in the process of bringing the SST bindings that use DRAMSim2 up to date with the develop branch.

I think at this point I have commit access to the sst google code, but I don't just want to dump my changes straight there because as soon as I do, it will break all the nightly builds since the new version of DRAMSim2 is required.

Anyways, to make a long story short, what do I do to add my changes without breaking everything?

Thanks,

Paul

--
Paul Rosenfeld
prose...@gmail.com

[Hammond, Simon David (-EXP)]

Paul,

This is great news :).

Can we put them into a branch on the SST SVN and try that?

-- 

Simon Hammond

Scalable Computer Architectures (CSRI/146, 01422)

Sandia National Laboratories, NM, USA

--
You received this message because you are subscribed to the Google Groups "Structural Simulation Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to SST-simulato...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Paul Rosenfeld]

Alright, I've got the changes committed to a branch and will bang on the new interface with m5C to make sure everything looks OK.

--
Paul Rosenfeld
prose...@gmail.com

[Hammond, Simon David (-EXP)]

Thanks Paul, we are also using DRAMSim2 in memHierarchy, can you give us some direction what the API changes are?

S.

[Paul Rosenfeld]

Yes, I've updated those as well.

[Paul Rosenfeld]

In case anyone wants to take a look, the API changes were all very straightforward as I'd kept some shims in place to help make the transition easier. This commit contains the bulk of the changes: http://code.google.com/p/sst-simulator/source/detail?r=5825

I ran a M5+DRAMSim configuration and it appears to be working fine. I will try to sanity check the actual results tomorrow.

I had a few questions:
1. What is the easiest way to test the memHierarchy component with the new bindings?

2. One thing I'd like to do is to call a DRAMSim2 function upon exiting an M5 simulation. Is there some way I can register a DRAMSimWrap function to be called upon the exit event firing from m5?

3. It appears that all of the sample xml files for m5 have been removed and replaced with the genXML program. Is genXML able to generate any DRAMSimWrap configurations? I'm seeing something called ddrConfig, but I'm guessing that is for M5's physicalMemory component, but it just happens to use a DRAMSim ini file.

Thanks,

Paul

--
Paul Rosenfeld
prose...@gmail.com

[Moore, Branden James]

Hi Paul,

  The following tests in the '$SST/sst/elements/memHierarchy/tests/' directory use DRAMSim:

    * sdl-2.xml

    * sdl-3.xml

    * sdl3-2.xml

    * sdl4-2.xml

The output should match the corresponding .ref files.

As for the m5C DRAMSimWrap, that is being deprecated with our work on re-integrating the trunk of Gem5 with SST.   I wouldn't worry too much about integration there.  memHierarchy is our route going forward for interfacing with DRAMSim.  (And Gem5 can use memHierarchy, and thus DRAMSim).

- Branden

[Paul Rosenfeld]

Thanks, Brendan. It's good to hear that DRAMSimWrap (and friends) are going away.

I ran these xml files and the stats seem slightly different from the reference output. The summaries at the end seem fairly close (the new DRAMSim2 code seems to produce slightly lower latencies and lower standard deviations). I can't remember if I've changed any of the inner workings of DRAMSim2 timings between master and develop. I'll try to investigate further on the trunk version to see if I can figure out where the difference is coming from. I did some testing earlier on develop vs. master of DRAMSim2 and it appeared there were subtle timing changes between the two versions -- so perhaps I fixed a bug or changed some heuristic in the newer version. It was close enough where I wouldn't worry about it.

Either way, the old reference output isn't generated quite correctly. Based on the DRAMSim2 output, I see that these were probably generated using an old version of DRAMSim2. This old version assumed a 2GHz input clock frequency when in fact the frequency should be set to the same value as the "clock" parameter (which, in these xml files, appears to be 1GHz). Making that change would invalidate all of the reference output.

On that note, could someone point me to a utility function that can convert a string like "1GHz" to a value like 1000000000U ?

-Paul

[Paul Rosenfeld]

And ... I just realized I screwed up transposing your name, Branden. Sorry about that.

--
Paul Rosenfeld
prose...@gmail.com

[Moore, Branden James]

As long as you are comfortable with the new output begin correct, we have no problems updating the reference files.

As for converting the string to a value, look into the TimeConverter mechanisms.