Блог

Я пишу, потому что в настоящее время я работаю над проектом с использованием симулятора gem5 для имитации конфигурации ARM bigLITTLE, в которой большой кластер ЦП имеет L2, а маленький кластер ЦП — нет. То есть я хотел бы смоделировать систему, в которой маленькие ядра еще проще, чем их конфигурация по умолчанию. Я запускаю проект, используя полный системный файл bigLITTLE (т.Е. gem5/configs/example/fs_bigLITTLE.py ). Возможно ли настроить систему таким образом?

Моей первоначальной мыслью было изменить файл python так, чтобы конфигурация небольшого кластера состояла из следующего:

 class LittleCluster(devices.CpuCluster):
    def __init__(self, system num_cpus, cpu_clock, cpu_voltage="1.0V"):
        cpu_config = [ ObjectList.cpu_list.get("MinorCPU"), devices.L1I, devices.L1D, devices.WalkCache, None]
        super(LittleCluster, self).__init__(system, num_cpus, cpu_clock, cpu_voltage, *cpu_config)
 

или, говоря простым языком, укажите None в качестве имени класса SimObject для L2. К сожалению, как и следовало ожидать, это приводит к сбою системы, поскольку gem5 ожидает, что объект подключит порты.

Моей следующей идеей было написать новый SimObject с именем EmptyCache, который наследует класс кэша от gem5, но ничего не делает. То есть при каждом обращении к кэшу этот объект будет возвращать false, и он будет настроен на отсутствие тегов, данных или задержки ответа. Однако это вызывает проблемы с согласованностью кешей L1 в небольшом кластере, поэтому я изменил его так, чтобы он удалял любой блок кэша, который он «попадает», прежде чем возвращать false (следующее основано на предыдущем сообщении в списке рассылки gem5-users: https://www.mail-archive.com/gem5-users@gem5.org/msg16882.html )

 EmptyCache::access(PacketPtr pkt, CacheBlk *amp;blk, Cycles amp;lat, PacketList amp;writebacks)
{
    if (Cache::access(pkt, blk, lat, writebacks) {
        Cache::evictBlock(blk);
    }

    return false;
}
 

Похоже, это решает проблемы согласованности, описанные выше, с кэшами L1, но, похоже, это вызывает проблемы с согласованностью в шине памяти (которая реализует класс SystemXBar (который реализует класс CoherentXBar)).

На данный момент я чувствую себя в значительной степени застрявшим и был бы признателен за любые советы, которые вы могли бы предоставить! Спасибо!

Редактировать: я продолжал пытаться добиться прогресса в этом проекте, несмотря на неудачи в этом направлении, изменяя gem5/configs/example/arm/devices.py досье. Я отметил, что одним из способов решения этой проблемы было бы добавить кэш-память MinorCPU с частными элементами, а затем установить кластер MinorCPU непосредственно на шину памяти при подключении основного кластера ЦП к системе кэширования, но проблема в этом направлении заключается в несоответствии между пакетами для младшего и старшего кластеров.

А именно, в кэшах есть несколько утверждений и операторов panic_if, которые предполагают, что конкретное перечисление MemCmd и / или что пакет «имеет отправителей». Естественно, я предполагаю, что эта проблема связана с этой настройкой моделирования, потому что симулятор фактически работает без нее, но есть ли способ настроить симулятор в этом направлении, чтобы между основным и второстепенным кластерами ЦП было какое-то подобие согласованности?

Еще раз спасибо за вашу помощь!