Implementing row individual refresh rate

[konbick]

@shavvn since I saw you took over the code support I wanted to ask two questions:

1) I believe that at the moment the REFRESH operation affects the whole rank. If I wanted to implement a REFRESH operation that is more individual, lets say refresh certain rows on all banks at different time intervalls, would it be hard to implement? Any tip of how to approach code revision?

2) I've read all available information and all issues in github. I couldn't quite follow why the data_storage option has been taken off the code. I need a data_storage option to verify bits stored in a unusual manner. Thus I referred to version 2.1 where the data_storage option seems to have compiled without error (not true for the current version). I saw that in the trace parse function only trace files with .misc ending are supported to actually contain custom data. For quick testing I tried to revise the trace parsing in a way that would also write on dataStr when using .k6 trace files while adding a fourth column in the trace file for data. How should I format the 4th column? Is it 32bytes that are required and does it use the hexadecimal fassion?

As I have read before, you were not in charge of the data_storage branch, however, I thought maybe you have a hint for me.

Best regards Kon

[shavvn]

Hi @konbick ,

1. Yes in reality the DRAM does indeed refresh a few rows at a time, but still, when those rows are being refreshed the whole rank has to halt (if it's DDR3). It is unrealistic to maintain a data structure for each row for refresh purposes because it would consume a lot of memory (in software perspective). One easier workaround is to have some simple data structure in MemControlller that keeps track of which rows are refreshed.

2. I've not looked at data_stroage branch yet, but according to the existing code in parsing misc trace (~ line 300 in traceBasedSim.cpp):

if (dataStr.size() > 0 && transType == DATA_WRITE)
{
        // 32 bytes of data per transaction
        dataBuffer = (uint64_t *)calloc(sizeof(uint64_t),4);
        size_t strlen = dataStr.size();
        for (int i=0; i < 4; i++)
        {
            size_t startIndex = i*16;
            if (startIndex > strlen)
            {
                break;
            }
        size_t charsLeft = min(((size_t)16), strlen - startIndex + 1);
        string piece = dataStr.substr(i*16,charsLeft);
        istringstream iss(piece);
        iss >> hex >> dataBuffer[i];
    }
    PRINTN("\tDATA=");
    BusPacket::printData(dataBuffer);
}

The data column should be just hex characters like abcdef01354 (only first 64 chars will be parsed)

[konbick]

Hi @shavvn,

Thanks for your answer. I will look into the proposal you made for 1. shortly.

Right now I am trying to understand how the refresh schedule is implemented at the moment. Everything is simple and straight forward. However, there is one thing that I think to have read somewhere...but I cannot find it again...its driving me crazy: When the refreshCountdown in the MC ran down (=0) and the MC sets a flag for a needed refresh of a rank, I think to remember that I read somewhere that in another class (Rank or Bank or commandQueue, I am not sure) the actual refresh operation could be delayed (or stalled, if you want) a max of 8 times when something else was operated. Do you happen to know what I am talking about? Do I confuse it with something else? I am so sure that I read it somewhere but I cannot find it again...I think it was written in a comment somewhere.

Best regards Kon

[shavvn]

Yes what you said was documented in DDR specs, I've read that as well.

But DRAMSim2 doesn't implement this kind of scheme. DRAMSim2 always issue refresh on time except that there could be some cycles of delay for a refreshing because of some cleaning-ups need to be done before refresh, and this delay is only a small fraction of refresh interval.

[konbick]

Ah, thanks a lot! It was driving me crazy, I thought I had read exactly this in the commentaries of DRAMSim2. But my mind tricked me :)

[shavvn]

No problem:)