Od C do Silicon: jak wdrożyć oprogramowanie / oprogramowanie układowe jako sprzęt?

W świetle tego pytania zastanawiałem się, czy istnieje dość standardowy proces przekształcania rozwiązania programowego w implementację sprzętową. Wybacz mi i mojej wyobraźni, ale czy byłby kompilator, który mógłby wziąć program C i skompilować go pod względem schematu tranzystorów, rezystorów itp., A może nawet dobrze znanych płytek drukowanych?

Zdaję sobie sprawę, że mógłbym patrzeć na ten scenariusz z niewłaściwej perspektywy. Z mojego własnego doświadczenia wynika, że ​​zazwyczaj masz sprzęt, który ktoś zaimplementował jako rozwiązanie programowe (emulacja sprzętu). Czy ta koncepcja w ogóle istnieje? W jaki sposób robią to większe firmy, takie jak rutowanie programowe vs. sprzętowe IP?

Nie, nie ma standardowego rozwiązania do przekształcania oprogramowania w sprzęt. Ogólnie rzecz biorąc, biorąc pod uwagę oprogramowanie, które nie zostało napisane z myślą o implementacji sprzętowej, nie można łatwo przekształcić go w sprzęt bez ogromnych strat i nieefektywności. Zwykle najlepiej jest po prostu zrobić układ z procesorem i pamięcią ROM i umieścić oprogramowanie w pamięci ROM.

Przez lata istniały kompilatory, które przyjmowałyby kod „C-Like” i kompilowały go w sprzęt - podobnie jak VHDL lub Verilog w kompilację sprzętową. Ale kluczową rzeczą jest to, że jest to „C-Like”, a nie C. Nadal nie możesz wziąć na przykład programu C / C ++, który oblicza PI i magicznie przekształca go w sprzęt, który oblicza PI. Większość tych języków C-Line zniknęła lub nie jest używana w żadnej liczbie. Jedną z bardziej popularnych wersji tego jest SystemC , ale należy zauważyć, że nie jest to C / C ++ i nie jest użyteczny w przypadku ogólnego „napiszmy oprogramowanie, a następnie skompilujmy je w sprzęt”. Nadal musisz „napisać sprzęt, który również może zostać skompilowany w oprogramowanie”.

Przełączniki i routery zazwyczaj mają sprzęt, który wykonuje większość często używanych i krytycznych funkcji routera (wyszukiwanie elementów w tablicach routingu, zarządzanie kolejkami itp.) W sprzęcie, a następnie wykorzystują procesor do wykonywania wszystkich nietypowych funkcji (obsługa wyjątków, błędów, aktualizacji tabeli routingu itp.). Pod wieloma względami jest to podobne do działania nowoczesnego procesora, w którym najczęściej używane kody są wykonywane sprzętowo, a czasami niektóre z nich są faktycznie implementowane w oprogramowaniu (na przykład instrukcje zmiennoprzecinkowe, gdy nie ma FPU).

Najbliższą rzeczą byłby kompilator C-to-Hardware (C2H) Altera . Może zrobić to, co sugerujesz. Ale są wyzywające zastrzeżenia. Nie możesz zamienić żadnego kodu C w sprzęt, ani nie chciałbyś tego. Jednak określone funkcje działają dość dobrze i można zaobserwować dramatyczny wzrost wydajności.

Zazwyczaj zaimplementowałbyś procesor softcore NIOS II w FPGA Altera. Następnie napisałbyś dla niego kod ANSI C, tak jak każdy inny procesor. Następnie powiedz, że jedna z funkcji C, którą napisałeś, wiąże się z ciężką matematyką, która przyniosłaby korzyści pod względem wydajności z równoległego wykonywania. Wywołujesz kompilator C2H, powiedz „Implement in Hardware”, co zasadniczo zmienia tę funkcję w urządzenie peryferyjne procesora softcore NIOS II.

Oto przykład kodowania obliczenia Mandelbrota w ANSI C, a następnie implementacji go w sprzęcie:

Algorytm Mandelbrota akcelerowany przez kompilator C2H powoduje zwiększenie szybkości przynajmniej 60x w porównaniu z tym samym algorytmem działającym na najszybszym procesorze Nios II z wykorzystaniem poziomu optymalizacji kompilatora 2 (-O2). Ten wzrost prędkości wynika z równoległości i szybkich prędkości iteracji, które może zapewnić sprzęt, co nie jest możliwe z jednostki przetwarzania ogólnego przeznaczenia.

Wracając do twojego przykładu, procesor NIOS II może uruchomić Linuksa. Niektóre funkcje, które byłyby konieczne do wykonywania zadań routingu, mogłyby skorzystać z przyspieszenia sprzętowego. Najprawdopodobniej działałby lepiej niż zwykły router programowy. Ale nigdy nie zbliży się do wydajności specjalnie zaprojektowanych dedykowanych układów ASIC.

W tytule wspominasz o „C to Silicon”, aw ciele wspominasz o produktach na poziomie płyty. Skoncentruję się na części tego równania, które istnieje -> przepływy projektowe „C na krzem”. C samo w sobie nie jest naturalnym dopasowaniem do opisu sprzętu, ponieważ brakuje mu pewnego fundamentalnego wsparcia dla wewnętrznej paralelności sprzętu, potrzeby zapobiegania warunkom wyścigowym i innym problemom, i nie jest szczególnie wyraziste w możliwości reprezentowania tych koncepcji. Lub nie tak bardzo jak Verilog i VHDL.

Kod C, który można zsyntetyzować (tzn. Można go przekształcić w opis sprzętu), a tutaj sprzęt = logika cyfrowa, nie wygrałby żadnych konkursów programistycznych ocenianych przez twórców oprogramowania.

Oto lista niektórych znanych dostawców dostarczających narzędzia C -> Silicon dla tłumu ASIC.

• Forte Cynthesizer

• Katapulta mentorów

• BlueSpec C

• Synopsys Synphony (ex- Synfora)

• Cadence C-to-Silicon

Przekształcenie oprogramowania w sprzęt nie jest całkowicie trywialnym zadaniem, jeśli oczekujesz rozsądnego sprzętu. Sprzęt zwykle wymaga więcej architektury, aby ostrożnie zarządzać zużyciem zasobów, które odnosi się do powierzchni / kosztów. To powiedziawszy, istnieje wiele narzędzi, które przyjmują C w jakiejś formie, pozwalają dodawać informacje specyficzne dla sprzętu (na przykład, jaki jest interfejs sprzętowy?) I generować zoptymalizowany sprzęt. Biegli użytkownicy mogą łatwo uzyskać lepsze wyniki w krótszym czasie niż ręcznie kodowane RTL.