Prototypowanie układów FPGA

Dalsze informacje: Tablica bramek programowalna przez użytkownika

Programowalne przez użytkownika prototypowanie macierzy bramek ( prototypowanie FPGA ), określane również jako prototypowanie oparte na FPGA, prototypowanie ASIC lub prototypowanie system-on-chip (SoC), to metoda prototypowania układów scalonych typu system -on-chip i specyficznych dla aplikacji projektów obwodów scalonych na układach FPGA do weryfikacji sprzętu i wczesnego rozwoju oprogramowania .

Metody weryfikacji projektowania sprzętu , a także wczesne współprojektowanie oprogramowania i oprogramowania sprzętowego stały się głównym nurtem. Dobrą metodą stało się prototypowanie projektów SoC i ASIC z jednym lub kilkoma układami FPGA i oprogramowaniem do automatyzacji projektowania elektronicznego (EDA).

Dlaczego prototypowanie jest ważne

  1. Uruchomienie projektu SoC na prototypie FPGA jest niezawodnym sposobem upewnienia się, że jest on funkcjonalnie poprawny. Można to porównać do sytuacji, w której projektanci polegają wyłącznie na symulacjach oprogramowania w celu sprawdzenia, czy ich projekt sprzętu jest solidny. Około jedna trzecia wszystkich obecnych projektów SoC jest bezbłędna podczas pierwszego przejścia krzemu, a prawie połowa wszystkich ponownych obrotów jest spowodowana błędami logiki funkcjonalnej. Pojedyncza platforma prototypowania może zapewnić weryfikację funkcjonalności projektowania sprzętu, oprogramowania układowego i aplikacji przed pierwszym przebiegiem krzemu.
  2. Czas wprowadzenia produktu na rynek (TTM) został skrócony dzięki prototypowaniu FPGA: w dzisiejszym społeczeństwie napędzanym technologią nowe produkty są wprowadzane szybko, a brak gotowego produktu w danym oknie rynkowym może kosztować firmę znaczną część przychodów . Jeśli produkt zostanie wypuszczony zbyt późno w oknie rynkowym, produkt może stać się bezużyteczny , co będzie kosztować firmę jej kapitał inwestycyjny w produkt. Po procesie projektowania układy FPGA są gotowe do produkcji, podczas gdy układy ASIC ze standardowymi komórkami potrzebują ponad sześciu miesięcy, aby wejść do produkcji.
  3. Koszt rozwoju: Koszt rozwoju projektu ASIC/SoC w technologii 90 nm wynosi około 20 milionów USD, a sam zestaw masek kosztuje ponad 1 milion USD. Oczekuje się, że koszty rozwoju projektów 45 nm przekroczą 40 milionów dolarów. Przy rosnących kosztach zestawów masek i ciągłym zmniejszaniu rozmiaru układów scalonych minimalizacja liczby ponownych obrotów ma kluczowe znaczenie dla procesu rozwoju.

Projekt do prototypowania

Projektowanie na potrzeby prototypowania ( DFP ) odnosi się do projektowania systemów, które nadają się do prototypowania . Wiele przeszkód napotykanych przez zespoły programistyczne, które przyjmują prototypy FPGA, można sprowadzić do trzech „praw”:

  • SoC są większe niż układy FPGA
  • SoC są szybsze niż układy FPGA
  • Projekty SoC są wrogie FPGA

Umieszczenie projektu SoC w prototypie FPGA wymaga starannego planowania, aby osiągnąć cele prototypowania przy minimalnym wysiłku. Aby ułatwić rozwój prototypu, najlepsze praktyki zwane Design-for-Prototyping wpływają zarówno na projektowania SoC , jak i procedury projektowe stosowane przez zespoły projektowe. Zalecenia proceduralne obejmują dodanie konwencji DFP do standardów kodowania RTL, zastosowanie środowiska symulacyjnego zgodnego z prototypami oraz ustanowienie strategii debugowania systemu wspólnie z zespołem programistów.

Problemy z partycjonowaniem

Ze względu na rosnącą złożoność obwodów i kurczący się czas wprowadzania na rynek, rośnie potrzeba weryfikacji projektów układów scalonych (ASIC) i układów typu system-on-chip (SoC) specyficznych dla aplikacji. Platformy sprzętowe stają się coraz bardziej widoczne wśród inżynierów weryfikujących ze względu na możliwość szybkiego testowania projektów systemów za pomocą wbudowanych zegarów magistrali w porównaniu z zegarami symulacyjnymi, które mogą nie zapewniać dokładnego odczytu zachowania systemu. Te wielomilionowe projekty bramek są zwykle umieszczane na platformie prototypowej z wieloma układami FPGA z sześcioma lub więcej układami FPGA, ponieważ nie są one w stanie zmieścić się w całości na jednym układzie FPGA. Im mniej układów FPGA projekt musi zostać podzielony na partycje, aby zmniejszyć wysiłek projektanta. Po prawej stronie znajduje się zdjęcie platformy prototypowej opartej na FPGA, wykorzystującej konfigurację dual-FPGA.

Aldec FPGA-based prototyping platform with dual FPGA configuration.
Rozwiązanie do prototypowania HES-7 ASIC firmy Aldec

Projekty systemów RTL lub listy sieci będą musiały zostać podzielone na partycje na każdym FPGA, aby móc dopasować projekt do platformy prototypowej. Wprowadza to nowe wyzwania dla inżyniera, ponieważ ręczne partycjonowanie wymaga ogromnego wysiłku i często skutkuje niską szybkością (testowanego projektu). Jeśli można zmniejszyć liczbę partycji lub cały projekt umieścić na jednym układzie FPGA, wdrożenie projektu na platformę prototypowania staje się łatwiejsze.

Zrównoważ zasoby FPGA podczas tworzenia partycji projektowych

Tworząc partycje obwodów, inżynierowie powinni najpierw przyjrzeć się dostępnym zasobom oferowanym przez FPGA, ponieważ projekt zostanie umieszczony na strukturze FPGA. Architektura każdego FPGA zależy od producenta, ale głównym celem partycjonowania projektu jest uzyskanie równej równowagi wykorzystania zasobów FPGA. Różne zasoby FPGA obejmują tablice przeglądowe (LUT), przerzutniki D , blokowe pamięci RAM , cyfrowe procesory sygnałowe (DSP), bufory zegara itp. Przed przystąpieniem do równoważenia partycji projektowych warto również przeprowadzić globalną optymalizację logiki w celu usunąć nadmiarową lub nieużywaną logikę. Typowy problem, który pojawia się przy tworzeniu zrównoważonych partycji, polega na tym, że może to prowadzić do konfliktu synchronizacji lub zasobów, jeśli odcięcie dotyczy wielu linii sygnałowych. Aby mieć w pełni zoptymalizowaną strategię partycjonowania, inżynier musi wziąć pod uwagę takie kwestie, jak ograniczenia taktowania/zasilania oraz rozmieszczenie i trasowanie, przy jednoczesnym zachowaniu zrównoważonego podziału między układami FPGA. Ścisłe skupienie się na jednym problemie podczas podziału może spowodować kilka problemów w innym.

Umieszczanie i trasowanie partycji

Aby osiągnąć optymalne miejsce i trasowanie dla projektów podzielonych na partycje, inżynier musi skupić się na liczbie pinów FPGA i sygnałach między FPGA. Po podziale projektu na oddzielne układy FPGA liczba sygnałów między układami FPGA nie może przekraczać liczby pinów w układzie FPGA. Bardzo trudno jest tego uniknąć, gdy projekty obwodów są ogromne, dlatego sygnały muszą wykorzystywać strategie, takie jak multipleksowanie z podziałem czasu (TDM), w którym wiele sygnałów może być przesyłanych pojedynczą linią. Te liczne sygnały, zwane podkanałami, są kolejno przesyłane przez linię w szczelinie czasowej. Gdy współczynnik TDM jest wysoki, częstotliwość zegara magistrali musi zostać zmniejszona, aby pomieścić szczeliny czasowe dla każdego podkanału. Zmniejszenie częstotliwości zegara ogranicza przepustowość systemu.

Wymagania czasowe

Projekty systemów zwykle obejmują kilka domen zegarowych z sygnałami przechodzącymi przez oddzielne domeny. Wbudowane oscylatory zegara i globalne linie zegara zwykle łagodzą te problemy, ale czasami te zasoby mogą być ograniczone lub nie spełniać wszystkich wymagań projektowych. Wewnętrzne zegary powinny być zaimplementowane w układach FPGA, ponieważ połączenia linii zegara i buforów zegara są ograniczone między układami FPGA. Projekty z zegarem wewnętrznym, które są podzielone na wiele układów FPGA, powinny replikować generator zegara w układzie FPGA, zapewniając niskie przesunięcie zegara między sygnałami między układami FPGA. Ponadto każda bramkowana logika zegara powinna zostać przekształcona tak, aby zegar umożliwiał zmniejszenie pochylenia podczas pracy z wysokimi częstotliwościami zegara.

Skrzyżowania domen zegarowych nie powinny być dzielone na osobne układy FPGA. Sygnały przechodzące przez skrzyżowanie powinny być utrzymywane wewnątrz pojedynczego układu FPGA, ponieważ dodatkowy czas opóźnienia między układami FPGA może powodować problemy w innej domenie. Zaleca się również, aby sygnały przesyłane pomiędzy układami FPGA były taktowane w rejestrach.

Debugowanie

Jednym z najtrudniejszych i najbardziej czasochłonnych zadań w prototypowaniu układów FPGA jest debugowanie projektów systemów. Termin ukuty na to to „piekło FPGA”. Debugowanie stało się trudniejsze i bardziej czasochłonne wraz z pojawieniem się dużych, złożonych układów ASIC i układów SoC. Aby debugować prototyp FPGA, sondy są dodawane bezpośrednio do projektu RTL w celu udostępnienia określonych sygnałów do obserwacji, syntezy i pobrania na platformę prototypu FPGA.

Dostawcy FPGA oferują szereg standardowych narzędzi do debugowania, w tym ChipScope i SignalTAP. Narzędzia te mogą sondować maksymalnie 1024 sygnały i wymagają znacznych zasobów LUT i pamięci. W przypadku SoC i innych projektów wydajne debugowanie często wymaga jednoczesnego dostępu do 10 000 lub więcej sygnałów. Jeśli błąd nie jest w stanie zostać przechwycony przez oryginalny zestaw sond, uzyskanie dostępu do dodatkowych sygnałów skutkuje sytuacją „idź do domu na cały dzień”. Wynika to z długich i złożonych przepływów CAD do syntezy oraz miejsca i trasy, których ukończenie może zająć od 8 do 18 godzin.

Ulepszone podejścia obejmują narzędzia takie jak Certus firmy Tektronix lub EXOSTIV firmy Exostiv Labs.

Certus zapewnia lepszą widoczność na poziomie RTL do debugowania opartego na FPGA. Wykorzystuje wysoce wydajny koncentrator wielostopniowy jako podstawę swojej sieci obserwacyjnej w celu zmniejszenia liczby LUT wymaganych na sygnał w celu zwiększenia liczby sygnałów, które można sondować w danej przestrzeni. Możliwość przeglądania dowolnej kombinacji sygnałów jest unikalna dla Certus i przełamuje jedno z najbardziej krytycznych wąskich gardeł prototypowania.

EXOSTIV wykorzystuje dużą zewnętrzną pamięć masową i transceivery gigabitowe do wydobywania głębokich śladów z FPGA działającego z dużą prędkością. Ulepszenie polega na możliwości widzenia dużych śladów w czasie jako ciągłego strumienia lub w seriach. Umożliwia to eksplorowanie rozszerzonych scenariuszy debugowania, których nie można osiągnąć za pomocą tradycyjnych technik oprzyrządowania wbudowanego. Rozwiązanie twierdzi, że oszczędza zarówno zasoby we / wy FPGA, jak i pamięć FPGA kosztem transceiverów gigabitowych, co poprawia widoczność o współczynnik 100 000 i więcej.

Zobacz też

  1. ^ „FPGA vs ASIC: różnice między nimi i którego użyć? - Centrum pomocy Numato Lab” . numato.com . Źródło 17 października 2018 r .
  2. ^ a b „SOCcentral: maksymalne wykorzystanie prototypowania ASIC za pomocą układów FPGA (EE Times Programmable Logic Designline 30794)” . Zarchiwizowane od oryginału w dniu 2 lutego 2013 r . Źródło 9 października 2012 r .
  3. ^ Rittman, Danny (5 stycznia 2006). „Prototypowanie nanometrów” (PDF) . Projekt Taydena . Źródło 7 października 2018 r .
  4. ^ a b „Prototypowanie FPGA do strukturalnej produkcji ASIC w celu obniżenia kosztów, ryzyka i TTM” . Zaprojektuj i użyj ponownie . Źródło 7 października 2018 r .
  5. ^ „Prototypowanie projektów systemów na układach FPGA” . Nowa elektronika. 22 marca 2011 . Źródło 22 marca 2011 r .
  6. ^ „Najlepsze praktyki dotyczące prototypowania FPGA algorytmów MATLAB i Simulink” . EEJournal . 25 sierpnia 2011 . Źródło 8 października 2018 r .
  7. ^ a b c d e „Biała księga współautorów Aldec i Xilinx„ Prototypowanie HES-7 ASIC ” , wymagana rejestracja
  8. ^ „Prototypowanie FPGA: chodzi o oprogramowanie - 2007-11-02 - Electronics Weekly” . Zarchiwizowane od oryginału w dniu 22 stycznia 2013 r . Źródło 9 października 2012 r .
  9. ^ http://www.fpga-faq.com/FAQ_Pages/prototyping.pdf [ bez adresu URL PDF ]
  10. ^ „Multipleksowanie z podziałem czasu” . www.inetdaemon.com . Źródło 8 października 2018 r .
  11. ^ „Piekło FPGA” . zipcpu.com . Źródło 5 listopada 2019 r .
  12. ^ „Pierwsze kroki z układami FPGA” (PDF) . {{ cite web }} : CS1 maint: stan adresu URL ( link )
  13. ^ „Tektronix wstrząsa prototypowaniem, wbudowane oprzyrządowanie podnosi płyty do statusu emulatora” . Dziennik inżynierii elektronicznej . 30 października 2012 . Źródło 30 października 2012 r .
  14. ^ „Exostiv Labs ogłasza dostępność swojego rozwiązania„ EXOSTIV ”do debugowania FPGA” . Projektuj i używaj ponownie. 14 października 2015 . Źródło 25 listopada 2015 r .
  15. ^ „Przełam wąskie gardła w prototypowaniu ASIC” . 23 października 2012 . Źródło 30 października 2012 r .
  16. ^ „Dlaczego EXOSTIV?” . 14 października 2015 . Źródło 25 listopada 2015 r .
  17. ^ „Prototypowanie ASIC / SoC” . Źródło 12 kwietnia 2020 r .

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=FPGA_prototyping&oldid=1106137789 ”