Получение трассировки физического адреса из GEM5 - PullRequest
2 голосов
/ 06 апреля 2020

Я пытался извлечь физический адрес, к которому приложение обращалось, чтобы проанализировать попадания в строки.

При этом я следил за этой страницей с небольшими изменениями из-за версии изменить.

Я исправил CacheConfig.py как:

system.monitor2 = CommMonitor()
system.monitor2.trace = MemTraceProbe(trace_file = "CT_mon2.trc.gz")
system.monitor2.slave = system.l2.mem_side

system.membus.slave = system.monitor2.master
system.l2.cpu_side = system.tol2bus.master

И запустил код:

build/X86/gem5.opt --debug-flag=CommMonitor configs/example/se.py --caches --l2cache --l2_size=2MB --mem-type=DDR4_2400_16x4 -c        tests/test-progs/mm/bin/x86/linux/mm --cpu-type=TimingSimpleCPU

ММ - это двоичный файл из простого умножения матрицы:

// C program to multiply two square matrices. 
#include <stdio.h>
#define N 4 

// This function multiplies mat1[][] and mat2[][], 
// and stores the result in res[][] 
void multiply(int mat1[][N], int mat2[][N], int res[][N])
{
    int i, j, k;
    for (i = 0; i < N; i++)
    {
        for (j = 0; j < N; j++)
        {
            res[i][j] = 0;
            for (k = 0; k < N; k++)
                res[i][j] += mat1[i][k]*mat2[k][j];
        }
    }
}

int main()
{
    int mat1[N][N] = { {1, 1, 1, 1},
                    {2, 2, 2, 2},
                    {3, 3, 3, 3},
                    {4, 4, 4, 4}};

    int mat2[N][N] = { {1, 1, 1, 1},
                    {2, 2, 2, 2},
                    {3, 3, 3, 3},
                    {4, 4, 4, 4}};

    int res[N][N]; // To store result 
    int i, j;
    multiply(mat1, mat2, res);

    printf("Result matrix is \n");
    for (i = 0; i < N; i++)
    {
        for (j = 0; j < N; j++)
        printf("%d ", res[i][j]);
        printf("\n");
    }

    return 0;
}

После декодирования «CT_mon2.tr c .gz» трассировка памяти отображается как:

5,u,15360,64,256,11500
6,u,183808,64,2,101000
5,u,18816,64,256,187000
6,u,183744,64,2,285000
5,u,18880,64,256,357000
6,u,171072,64,3,438000
6,u,171648,64,3,526000
6,u,172032,64,3,601000
6,u,174528,64,3,689000
5,u,18944,64,256,765000

Третий указывает на физический адрес.

То, что я путаю, это часть "у". Начиная с этапа декодирования, все, что не считано (r) или записано (w), обозначается как «u».

При отладке команды повторялись с «UpgradeFailResp» и «ReadCleanReq».

Я ожидал следа с чтением и записью, но я не уверен, что здесь происходит.

Может кто-нибудь сказать мне, что мне не хватает?

Или даже лучший способ получить физический адрес будет огромной помощью.

Спасибо, jwlee

...