Перевірка узгодженості системи атак Breker

Найцікавіше в архітектурних рішеннях для збільшення пропускної здатності полягає в тому, що вони пропонують значні покращення. Кілька процесорів на чіпі з (частково) спільною ієрархією кешу тепер є звичним явищем у серверних процесорах з цієї причини. Але ця велика перевага супроводжується значною додатковою складністю перевірки правильної поведінки. У моделі спільної пам’яті значення, що зберігається в адресі логічної пам’яті, з’являється не лише в основній (DRAM) пам’яті, але й потенційно в кількох вбудованих кешах і навіть, можливо, у буферах у когерентній структурі. Це викликає проблему узгодженості – для заданої адреси логічної пам’яті всі вони повинні містити однакові значення за будь-яких обставин, але чи так це? Breker атакує цю проблему перевірки когерентності за допомогою своєї технології синтезу тестів, розглядаючи повну когерентність системи в гетерогенних системах.

Проблеми зв'язності

Подання логічної пам’яті може стати неузгодженим, коли два чи більше процесорів працюють із власною локальною копією значення за спільною адресою, і один оновлює своє локальне значення, невідоме іншому. Настає хаос, коли процесори працюють зі своїм власним баченням реальності. Сама когерентна структура має структуру, що підтримує дані під час польоту, наприклад буфери зворотного запису. Перевірка узгодженості також повинна мати справу з цим. І тоді, звичайно, периферійні пристрої можуть записувати безпосередньо в основну пам’ять через DMA, невідомі внутрішнім кеш-пам’ятям.

Зрозуміло, що потрібен якийсь механізм для синхронізації спільних значень, коли це необхідно. Але він повинен бути легким. Синхронізація передбачає штраф за затримку, який може значно зменшити перевагу кешування у продуктивності, якщо не використовувати його лише за крайньої необхідності. Проблема затримки ускладнюється ще більше, якщо ви розглядаєте багатосокетні процесорні плати зі спільною пам’яттю, з’єднані між собою через CXL. Додавання більшої складності рішенням.

Розумні методи використовуються для спостереження за вмістом і змінами кешу, щоб визначити, коли потрібне оновлення синхронізації. Сюди входять стеження та системи узгодженості на основі каталогів, які позначають адреси кешу (точніше рядки кешу) як чисті (узгоджені) або недійсні з різними уточненнями. Ці методи повинні проходити тонку межу між мінімізацією чистого впливу на продуктивність і водночас гарантувати відсутність можливих виходів. Уникає можливих випадків, коли некогерентний стан може вижити.

Breker System Coherency TrekApp

Щоб переконатися, що проект не перетинає цю тонку межу, інженери з верифікації повинні самостійно створити тести, які, на їхню думку, охоплять усі можливі випадки. Узгодженість кеш-пам’яті, інтерфейсу та вводу-виводу в усіх варіаціях керування (живлення, переривання, тактова частота тощо), через які проект може циклічно змінюватись. Ось де на допомогу приходить додаток Breker Trek System Coherency.

Аднан Хамід, засновник Breker, багато років тому розпочав перевірку когерентності в AMD. Ідеї, які він розвинув там щодо перевірки когерентності кешу та методів перевірки системи загалом, він вбудував у Breker. Рішення узгодженості з часом було розширено, щоб також включити структуру та когерентність вводу-виводу та взаємодію з перемиканням живлення тощо. Після перевірки цієї можливості з кількома провідними клієнтами Брекер анонсував продукт на недавньому DAC 2021 у Сан-Франциско.

Аднан пропонує розуміння: щоб знати, як досягти значущої перевірки узгодженості, ви спочатку повинні знати, як виміряти покриття. Як і для будь-якої цілі покриття системного рівня, показники покриття RTL не є корисними. Більш корисним є охоплення спершу кінцевого автомата менеджера узгодженості для кешу з варіантами значень кешу та кроку адреси, потім подібне охоплення взаємодій між кешами, потім охоплення синтетичним набором програмних тестів тортур, схрещених із потужністю та інші переходи, що працюють на емуляторі. Додаток System Coherency TrekApp підтримує все це.

А як щодо втеч?

Поговоріть з будь-ким, хто працює з когерентним дизайном, і всі вони скажуть вам, що знаходять проблеми з когерентністю після кремнію. Наблизитися до цієї тонкої лінії, не перетинаючи її, справді досить важко. Зрештою, ви намагаєтесь у попередній верифікації кремнію змоделювати величезний простір станів за допомогою, порівняно, крихітного набору тестів, навіть якщо ви виконуєте десятки тисяч тестів. Враховуючи, що вичерпне тестування навіть віддалено неможливе, хитрість полягає в тому, щоб знайти найкращий практичний набір тестів для виконання. Оскільки це неминуче буде неповним, додаток System Coherency TrekApp поширюється навіть на пост-кремній, допомагаючи діагностувати несправності кремнію. Можливо, перехід живлення в середині синхронізації. Або переривання, на жаль, приурочене до оновлення тегу. На думку Аднана, це післясиліконове навчання допоможе вдосконалити план охоплення перед кремнієвою перевіркою. Щоб зменшити, якщо не усунути посткремнієві витоки.

Цікаві речі, які до речі підтримуються як для систем на базі Arm, так і для систем на основі RISC-V, нещодавно схвалені в прес-релізі Nuclei System Technology. Ви можете дізнатися більше ТУТ.

Також читайте:

ВЕБІНАР: Adnan on Challenges in Security Verification

Брекер підказує формальним графікам у перевірці безпеки PSS

Перевірка, RISC-V і розширюваність

Поділитися цим дописом через: Джерело: https://semiwiki.com/eda/306824-breker-attacks-system-coherency-verification/