Breker atakuje weryfikację spójności systemu

Wspaniałą cechą rozwiązań architektonicznych zwiększających przepustowość jest to, że oferują duże ulepszenia. Z tego powodu wiele procesorów na chipie z (częściowo) współdzielonymi hierarchiami pamięci podręcznej jest obecnie powszechne w procesorach serwerowych. Ale ten duży zysk wiąże się ze znaczną dodatkową złożonością weryfikowania prawidłowego zachowania. W modelu pamięci współdzielonej wartość przechowywana w adresie pamięci logicznej pojawia się nie tylko w pamięci głównej (DRAM), ale także potencjalnie w wielu wbudowanych pamięciach podręcznych, a nawet prawdopodobnie w buforach w strukturze koherencji. Rodzi to problem spójności — dla danego adresu pamięci logicznej wszystkie powinny zawierać tę samą wartość we wszystkich okolicznościach, ale czy tak jest? Breker atakuje ten problem weryfikacji spójności za pomocą swojej technologii syntezy testów, patrząc na pełną spójność systemu w systemach heterogenicznych.

Wyzwania w zakresie spójności

Widok pamięci logicznej może stać się niespójny, gdy dwa lub więcej procesorów pracuje z własną lokalną kopią wartości pod wspólnym adresem i jeden aktualizuje swoją wartość lokalną, nieznaną drugiemu. Następuje chaos, ponieważ każdy z procesorów pracuje z własnym spojrzeniem na rzeczywistość. Sama spójna struktura ma strukturę obsługującą dane w locie, takie jak bufory zapisu wstecznego. Weryfikacja spójności musi również zająć się tymi kwestiami. A potem oczywiście urządzenia peryferyjne mogą zapisywać bezpośrednio do pamięci głównej przez DMA, nieznane wewnętrznym pamięciom podręcznym.

Oczywiście potrzebny jest jakiś mechanizm do synchronizacji wspólnych wartości, gdy jest to wymagane. Ale to musi być lekkie. Synchronizacja wiąże się z opóźnieniem, które może znacznie zmniejszyć przewagę wydajnościową buforowania, chyba że jest używana tylko wtedy, gdy jest to absolutnie konieczne. Problem z opóźnieniami jest jeszcze większy, jeśli weźmiemy pod uwagę wielogniazdowe płyty procesorowe z pamięcią współdzieloną połączone ze sobą za pośrednictwem CXL. Zwiększanie złożoności rozwiązań.

Sprytne techniki służą do szpiegowania zawartości i zmian w pamięci podręcznej, aby określić, kiedy konieczna jest aktualizacja synchronizacji. Obejmują one szpiegowanie i systemy spójności oparte na katalogach, które oznaczają adresy pamięci podręcznej (a dokładniej linie pamięci podręcznej) jako czyste (spójne) lub nieprawidłowe, z różnymi udoskonaleniami. Metody te muszą przebiegać cienką linią między minimalizowaniem wpływu na wydajność netto, a eliminacją możliwych ucieczek. Ucieczki są możliwymi przypadkami, w których niespójny warunek może przetrwać.

TrekApp Spójność systemu Breker

Aby sprawdzić, czy projekt nie przekracza tej cienkiej granicy, inżynierowie weryfikujący muszą niezależnie opracować testy, które ich zdaniem obejmą wszystkie możliwe przypadki. Spójność pamięci podręcznej, struktury i we/wy we wszystkich wariantach sterowania (zasilanie, przerwania, taktowanie itp.), przez które projekt może przechodzić cyklicznie. Właśnie tam pojawia się aplikacja Breker Trek System Coherency.

Adnan Hamid, założyciel Breker, zaczynał wiele lat temu od weryfikacji spójności w AMD. Pomysły, które tam rozwinął, dotyczące weryfikacji spójności pamięci podręcznej i ogólnie metod weryfikacji systemu, wbudował w Brekera. Z biegiem czasu rozwiązanie koherencji rozszerzyło się, obejmując również koherencję sieci szkieletowej i IO oraz interakcję z przełączaniem zasilania itp. Po udowodnieniu tej możliwości z kilkoma głównymi klientami, Breker ogłosił produkt na niedawnym DAC 2021 w San Francisco.

Adnan oferuje wgląd: aby wiedzieć, jak osiągnąć miarodajną weryfikację spójności, najpierw musisz wiedzieć, jak mierzyć zasięg. Podobnie jak w przypadku każdego celu pokrycia na poziomie systemu, metryki pokrycia RTL nie są pomocne. Bardziej przydatne jest pokrycie najpierw maszyny stanu menedżera spójności na pamięć podręczną, z wariantami wartości pamięci podręcznej i kroku adresowego, następnie podobne pokrycie interakcji między pamięciami podręcznymi, a następnie pokrycie przez syntetyczny zestaw testów tortur opartych na oprogramowaniu, skrzyżowanych z mocą i inne przejścia, działające na emulatorze. System Coherency TrekApp obsługuje to wszystko.

A co z ucieczkami?

Porozmawiaj z każdym, kto pracuje nad spójnymi projektami, a wszyscy powiedzą ci, że mają problemy ze spójnością po krzemie. Zbliżenie się do tej cienkiej linii bez jej przekroczenia jest naprawdę trudne. W końcu próbujesz w weryfikacji przed krzemem modelować ogromną przestrzeń stanów za pomocą małego zestawu testów, nawet jeśli przeprowadzasz dziesiątki tysięcy testów. Biorąc pod uwagę, że wyczerpujące testy nie są nawet w przybliżeniu możliwe, sztuczka polega na znalezieniu najlepszego praktycznego zestawu testów do przeprowadzenia. Ponieważ będzie to nieuchronnie niekompletne, TrekApp System Coherency rozciąga się nawet na post-krzem, pomagając diagnozować awarie krzemu. Być może zmiana władzy w trakcie synchronizacji. Lub przerwanie niestety zsynchronizowane z aktualizacją znacznika. Zdaniem Adnana ta nauka po krzemie pomoże udoskonalić plan weryfikacji przed krzemem. Aby zmniejszyć, jeśli nie wyeliminować ucieczki po krzemie.

Ciekawe rzeczy, nawiasem mówiąc obsługiwane zarówno dla systemów opartych na Arm, jak i RISC-V, ostatnio zatwierdzone w komunikacie prasowym z Nuclei System Technology. Możesz dowiedzieć się więcej TUTAJ.

Przeczytaj także:

WEBINAR: Adnan o wyzwaniach związanych z weryfikacją bezpieczeństwa

Breker przechyla kapelusz na formalne wykresy w weryfikacji bezpieczeństwa PSS

Weryfikacja, RISC-V i rozszerzalność

Udostępnij ten post przez: Źródło: https://semiwiki.com/eda/306824-breker-atttacks-system-coherency-verification/