logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Dlaczego sieciowe bloki IP w SoC musi być 'świadome' fizycznego układu w chipie

ghost666 29 Mar 2023 09:58 1158 0
  • Dlaczego sieciowe bloki IP w SoC musi być 'świadome' fizycznego układu w chipie
    Obecnie wielordzeniowe projekty układu typu system-on-chip (SoC) mogą składać się z setek bloków IP, zwykle zawierających do dziesięciu milionów bramek logicznych. Jednym ze sposobów, w jaki programiści SoC mogą tworzyć urządzenia o tak dużej złożoności, jest wykorzystanie sprawdzonych bloków IP dostarczonych przez zaufanych dostawców zewnętrznych. Nie ma sensu poświęcać tysięcy godzin na wymyślanie na nowo interfejsu USB 3.2 Gen x, jeśli jest on już dostępny jako gotowe rozwiązanie w postaci bloku IP. Zamiast tego inżynierowie mogą skoncentrować swoje wysiłki na stworzeniu własnej wewnętrznej logiki, który odróżni ich SoC od wszelkich konkurencyjnych układów.

    Jeśli chodzi o łączenie bloków IP, aby mogły one ze sobą rozmawiać, jedyną praktyczną opcją dla większości dzisiejszych układów SoC o dużej pojemności i złożoności jest użycie systemów sieci na chipie (NoC). Wiele osób nie zdaje sobie sprawy, że NoC to także blok IP, chociaż taki, który obejmuje cały SoC. Jeśli chodzi o tę technologię, zespoły projektowe mogą zdecydować o opracowaniu sieci NoC we własnym zakresie lub skorzystać ze sprawdzonego rozwiązania pochodzącego od zaufanego dostawcy zewnętrznego. Inną kwestią, którą architekci SoC mogą łatwo przeoczyć, jest konieczność, aby środowisko projektowe NoC było 'fizycznie świadome'. To radykalnie przyspiesza eksplorację przestrzeni potrzebnej do osiągnięcia optymalnej topologii NoC we front-endzie oraz finalizację procesu projektowania w zakresie back-endu

    Elementy tworzące sieć na chipie

    Sieć na chipie składa się z wielu elementów. Po pierwsze, każdy blok IP ma swoją własną charakterystykę interfejsu — taką jak szerokość danych i częstotliwość taktowania — i wykorzystuje jeden z wielu standardowych protokołów przyjętych przez przemysł SoC: OCP, APB, AHB, AXI, STBus i DTL. Do każdego z funkcjonalnych bloków IP należy podłączyć jeden lub więcej interfejsów, które następnie będą pakietować i serializować dane ze źródłowych bloków IP do znormalizowanej postaci odpowiedniej do transportu przez sieć. Z drugiej strony interfejsy dołączone do docelowych bloków IP będą konwertować przychodzące pakiety z powrotem na inne formy.

    Oprócz linii, łączących wszystko ze sobą, główny mechanizm transportowy NoC składa się głównie z przełączników i buforów. Switche te działają jak multipleksery z powiązanymi arbitrami lub demultipleksery z powiązaną logiką mapowania, wykorzystując dane docelowe umieszczone w nagłówku każdego pakietu do wyznaczania trasy od źródła do jego miejsca docelowego. Tymczasem bufory są używane jako elementy pamięci do agregowania danych wzdłuż ścieżki. Na przykład bufor może zostać szybko załadowany z bloku IP przy użyciu szybkiego zegara, który może następnie skierować swoją uwagę na inne zadania, podczas gdy inny blok IP przy użyciu wolniejszego zegara pobiera dane zgromadzone w buforze.

    Wreszcie, co z pewnością nie jest mniej ważne, do ścieżek sieci na chipie wstawiane są rejestry potoków, aby rozwiązać problemy z synchronizacją. Problemy te mogą być spowodowane koniecznością pokonywania dużych odległości przez dane w strukturze SoC.

    Mniejsze geometrie oznaczają większe problemy

    Gdy projekty SoC przechodzą do bardziej zaawansowanych procesów, tranzystory w chipie stają się coraz mniejsze i szybsze. Niestety rozmiar i prędkość ścieżek w układzie nie skalują się w tym samym tempie, co oznacza, że ​​mają one wyższy względny koszt pod względem powierzchni i pobieranej mocy. Oprócz faktu, że więcej logiki można zmieścić w tym samym obszarze przy użyciu urządzeń o mniejszej geometrii, same chipy stają się coraz większe, obsługując w ten sposób coraz więcej bloków IP w jednym układzie. Architektura ma również obecnie wyższe wymagania dotyczące parametrów pod względem częstotliwości taktowania, przepustowości danych i optymalizacji opóźnień ścieżek krytycznych. Duży SoC produkowany w technologii 7 nm może wymagać ponad 6000 rejestrów potoków. Deweloperzy muszą wziąć pod uwagę wiele parametrów przy określaniu, gdzie te rejestry muszą być zlokalizowane, aby spełnić wymagania dotyczące synchronizacji, jednocześnie starając się zminimalizować zajmowany obszar, wprowadzane opóźnienie i obciążenie elektryczne. Przy tak monumentalnym zadaniu, często w połączeniu z napiętym harmonogramem, ręczne wstawianie rejestrów potoków niezmiennie prowadzi do tworzenia zbyt złożonych projektów w celu zmniejszenia kosztownych iteracji na dalszym etapie projektowania systemu. Kolejnym kosztem jest większy zajmowany obszar, większe zużycie energii i większe opóźnienia. Co gorsza, ręczne wstawianie tych rejestrów jest podatne na błędy, co może łatwo prowadzić do zwiększonej liczby iteracji, pomimo dołożenia wszelkich starań, aby zapewnić wystarczającą liczbę potoków na wszystkich odpowiednich ścieżkach.

    Znaczna część złożoności wstawiania potoku dotyczy bloków IP sieci na chipie, które to łączą się z ogromną większością innych bloków IP w systemie. W związku z tym jest to jedyny blok IP, który przechodzi przez cały chip, więc ma najdłuższe ścieżki i najprawdopodobniej najczęściej przechodzi przez krytyczne punkty układu. Musi również reagować na zmiany inżynieryjne inicjowane przez architekturę jak i dział marketingu w trakcie projektu, co oznacza, że sieć na chipie jest często ostatnią zamrożoną strukturą, przed finalizacją projektu.

    Fizycznie świadome bloki IP dla sieci na chipie

    Połączenie kosztów związanych z ręcznym wprowadzaniem rejestrów potoków w połączeniu z koniecznością szybkiego dostosowywania się do zmieniających się wymagań stanowi doskonałą okazję do zautomatyzowanego rozwiązania. Biorąc pod uwagę wymagania fizyczne, świadoma rozkładu bloków na chipie technologia sieciowa może inteligentnie wstawiać rejestry potoków i sugerować odpowiednie lokalizacje dla ich umieszczenia zespołowi zajmującemu się układem. Narzędzia innych firm mają taką możliwość. Na początek konieczna jest znajomość względnego rozmieszczenia bloków IP i wszelkich powiązanych z tym kanałów routingu. Podczas późniejszych etapów procesu rozwoju SoC, fizyczny zespół projektowy będzie dysponował tymi danymi. W takim przypadku mogą dostarczyć te informacje w postaci plików w formacie wymiany bibliotek (LEF) i plików w formacie wymiany projektów (DEF). Jednak dane te zazwyczaj nie są dostępne na wczesnym etapie projektu, dlatego ważne jest, aby móc wykorzystać wszelkie dostępne szczegóły na wczesnym etapie. Przykładami wczesnych danych są obrazy, rysunki Visio, które obejmują widoki wysokiego poziomu planu chipu SoC lub szczegółowe dane LEF/DEF. Narzędzia projektowe innych firm mogą wykorzystywać te dane wejściowe do sugerowania odpowiednich układów (rysunek 1).

    Dlaczego sieciowe bloki IP w SoC musi być 'świadome' fizycznego układu w chipie
    Rys.1. Przykład wykorzystania narzędzi projektowych FlexNoC
    do wykorzystania różnych źródeł danych układu, aby pomóc
    w automatycznym umieszczaniu rejestrów potoków.


    Narzędzia wykorzystują te informacje wraz z wymaganiami dotyczącymi prędkości i przesyłu danych, aby automatycznie sugerować wstawienie i lokalizacje rejestrów potoków. Zespoły projektowe mogą interaktywnie pracować z narzędziami, aby eksperymentować z różnymi miejscami ich ustawienia. W zamian otrzymują dokładne oszacowania zależności czasowych i zajmowanego na chipie obszaru oraz lepsze zrozumienie tego, co można osiągnąć dzięki obecnej architekturze sieci na wcześniejszym etapie projektowania.

    Ponadto narzędzia projektowe innych firm mogą generować dane LEF/DEF powiązane z siecią na chipie, w tym sugerowane lokalizacje rejestrów potoków, do użytku z narzędziami projektowymi dla back-endu (patrz rysunek 2).

    Dlaczego sieciowe bloki IP w SoC musi być 'świadome' fizycznego układu w chipie
    Rys.2. Przykład projektu wykorzystuje narzędzia projektowe FlexNoC
    do wyprowadzania danych LEF/DEF powiązanych z NoC,
    w tym sugerowanych lokalizacji rejestrów potoków, do użytku
    z narzędziami P&R dla back-endu.


    Im szybciej tym lepiej

    Zezwolenie zespołom na interaktywną iterację na początku procesu projektowania SoC radykalnie zmniejsza liczbę iteracji między back-endem a front-endem potrzebnych do osięgnięcia synchronizacji poszczególnych elementów systemu. Mogą oni eksperymentować z różnymi topologiami sieci na chipie i automatycznie umieszczać rejestry potoków oraz oceniać wyniki różnych rozmieszczeń pod względem zajmowanego na chipie obszaru, zużywanej mocy i wnoszonego do transmisji opóźnienia. To z kolei zmniejsza koszty projektu, ryzyko projektowe, jak i czas wprowadzenia nowego produktu na rynek. Ponadto zmniejszenie liczby iteracji back-endu do front-endu ma istotny wpływ na jednorazowe koszty inżynieryjne (NRE), które zwykle osiągają szczyt w tej fazie cyklu projektowania SoC.

    Źródło: https://www.edn.com/why-network-on-chip-ip-in-soc-must-be-physically-aware/

    Fajne? Ranking DIY
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    https://twitter.com/Moonstreet_Labs
    ghost666 napisał 11960 postów o ocenie 10197, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
REKLAMA