Kolejne pokolenie deweloperów logiki programowalnej

Dawno, dawno temu, przed erą syntezy logicznej, inżyniera można było poprosić o zbudowanie czysto logicznego układu. Było to w czasach, gdy mieliśmy radary, ale nie było mikrokontrolerów, istniało cyfrowe przetwarzanie sygnału, ale nie było dostępnych od ręki procesorów sygnału cyfrowego. Mimo to posiadaliśmy cyfrowo przetwarzane sygnały radaru.

W tamtych czasach od świeżo upieczonego inżyniera oczekiwano, że będzie wiedział, jak projektować sprzęt analogowy i cyfrowy oraz jak tworzyć oprogramowanie. Obawiam się, że czasy tak szerokich umiejętności w zakresie inżynierii elektrycznej mijają i martwię się o przyszłość projektowania logicznego. Powiedziano kiedyś, że gdy Twoim jedynym narzędziem jest młotek, to każdy problem wygląda jak gwóźdź. Czy dotarliśmy do momentu, w którym każdy problem wygląda jak problem z oprogramowaniem?

Jeśli wpiszesz w wyszukiwarkę „zastosowania FPGA”, wyświetli Ci się lista zastosowań z czołówki elektrotechniki. Od sztucznej inteligencji i przetwarzania mowy, aż po komunikację i przetwarzanie obrazu. Problem z tymi zastosowaniami polega na tym, że nie są one proste i na pewno nie są dla początkujących. Krzywa uczenia się dotycząca wdrażania takich zastosowań jest stroma i obejmuje kilka poważnych zagadnień.

Trzeba poznać same programowalne urządzenia logiczne, ich zintegrowane środowisko programistyczne (IDE - każdy producent ma swoje własne), nowe paradygmaty programowania (np. języki opisu sprzętu HDL - Hardware Description Language - oraz ich współbieżność i pojęcie czasu), a także zrozumieć same zastosowania. Są to tematy, którymi zajmują się tylko eksperci. To nie wróży dobrze kolejnemu pokoleniu inżynierów projektowania logicznego, którzy chcieliby wykorzystać swoje umiejętności w tym zakresie. Pierwszy krok jest po prostu za trudny. Myślę, że zniechęca to do zainteresowania się tym obszarem, a tym samym zmniejsza liczbę osób, które w przyszłości staną się adeptami programowania układów logicznych. W Internecie można przeczytać wiele historii osób sfrustrowanych obecnym stanem projektowania logiki programowalnej. Istnieje także wiele społeczności typu open source, które próbują to rozwiązać. Wiele osób sądzi, że ratunkiem będzie metaprogramowanie - jest to technika programowania, w której program traktuje inny program jako swoje dane.

Firmy zajmujące się programowalną logiką są w kropce. Z jednej strony inwestorzy wymagają opracowywania coraz bardziej wydajnych i drogich chipów, a z drugiej strony stosunkowo mniej osób jest w stanie z nich korzystać. Proponowanym przez nich rozwiązaniem jest przekształcenie twórców oprogramowania w projektantów sprzętu i robią to za pomocą nowych narzędzi.

Kompilatory syntezy wysokiego poziomu (HLS - High-Level Synthesis) przenoszą abstrakcyjność projektowania na jeszcze wyższy poziom, a to sprawia, że jeszcze dalej odchodzimy od korzeni projektowania logicznego. To niezwykłe, że potrafimy tworzyć zaawansowane projekty sprzętu jedynie na podstawie opisów oprogramowania, ale w ten sposób tracimy naturalną atrakcyjność projektowania logicznego. Jestem daleki od stwierdzenia, że człowiek może działać optymalniej niż komputer. Po prostu myślę, że w przeszłości projektowanie prostych układów było łatwiejsze. Problem polega na tym, że w porównaniu do przeszłości, dziś trudniej zaprojektować proste układy.

Pamiętam satysfakcję z uruchomienia ręcznie wykonanego układu logicznego. Dzięki sprytowi można było zminimalizować liczbę potrzebnych urządzeń. Kiedy na początku lat 90. uczyłem się logiki programowalnej, jeszcze bardziej ucieszył mnie fakt, iż mogłem zastosować swoją wiedzę z zakresu projektowania obwodów, by zainstalować swój układ w jednym urządzeniu składającym się ze 128 elementów logicznych i to ja wybrałem każdy z tych elementów. Nie było to uzależnione od wiedzy jakiegoś nieznanego mi twórcy algorytmów.

W międzyczasie ewolucja objęła zarówno projektowanie układów logicznych, jak i projektowanie oprogramowania. Nasza rzeczywistość stała się w dużej mierze światem programowania obiektowego (OOP - object-oriented programming), a biblioteki powszechnie stosowanych wzorców projektowych są dobrze udokumentowane i łatwo dostępne w bibliotekach kodu. Moim wyborem jest niegdyś popularna książka Wzorce projektowe, elementy oprogramowania obiektowego wielokrotnego użytku Ericha Gammy i wsp. Co ciekawe, projektowanie sprzętu na początku było obiektowe, ale jego rozwój utknął w martwym punkcie wraz z wprowadzeniem języków opisu sprzętu. Nawet jeśli języki opisu sprzętu uwzględniają wielokrotny użytek wzorców, biblioteki projektowe zawierają najbardziej podstawowe funkcje. Gdy wpiszesz w wyszukiwarkę „układy scalone serii 7400” to znajdziesz kilka wczesnych wzorców projektowania sprzętu. Ciekawe, że Meilir Page-Jones w swojej książce Fundamentals of Object-Oriented Design in UML, odwołuje się do układów scalonych jako przykładów projektowania obiektowego o wysokiej spójności i niskim sprzężeniu. Jednak w pogoni za coraz bardziej złożonymi programowalnymi urządzeniami logicznymi, oddaliliśmy się od prostych i bezpośrednich układów logicznych. Dzisiejsze metodologie projektowania zależą od algorytmu komputerowego, który wdraża układy logiczne. Myślę, że takie podejście stanowi barierę dla początkujących programistów.

Można zapytać ile wierszy kodu zawierała pierwsza gra Pong, którą można było podłączyć do telewizora?. Odpowiedź brzmi zero. Była ona oparta tylko i wyłącznie na sprzęcie (ilustracja 1) - zero oprogramowania! Wydaje mi się, że niewielu świeżo upieczonych inżynierów byłoby w stanie stworzyć taką grę nie wykorzystując oprogramowania. Spytaliby raczej „a po co to robić?”. Odpowiedziałbym im, że to ważne ze względu na perspektywę i świadomość, że po prostu da się to zrobić. I że to prostsze, niż myślą.

Ilustracja 1: schemat gry Pong (Ilustracja: znaleziona za pośrednictwem bloga Adafruit, źródło nieznane)

IEEE (Instytut Inżynierów Elektryków i Elektroników) opublikował w 2019 r. listę ulubionych i najmniej lubianych języków programowania. Wynika z niej, że inżynierowie kochają Pythona. Myślę, że to prawda. Kilka lat temu byłem sędzią na konkursie projektowania Texas Instruments i zauważyłem, że 9 na 10 zespołów studentów w swoich projektach korzystało właśnie z Pythona. Język opisu sprzętu (VHDL) z programu VHSIC oraz Verilog nie znalazły się ani na liście ulubionych, ani znienawidzonych języków. Być może redaktorzy instytutu nie wzięli ich pod uwagę, ale, co bardziej prawdopodobne, myślę że badani po prostu nie brali pod uwagę języków HDL. Jeśli to prawda, to ten fakt świadczy o tym, że niewielu inżynierów w ogóle myśli o tych językach, a nawet o układach logicznych jako takich - a to źle wróży przyszłości projektowania układów logicznych.

Co można z tym zrobić? Jak zachęcić inżynierów do przyglądania się problemom i poszukiwania ich rozwiązań w oprogramowaniu lub sprzęcie? W końcu większość problemów można rozwiązać na obydwa sposoby. Mam pewien pomysł.

Myślę, że platforma Arduino pobudziła zainteresowanie oprogramowaniem u wielu młodych ludzi. Zaczynają studia, by zostać inżynierami i informatykami. Jak to się dzieje? Platforma Arduino „złagodziła” krzywą uczenia się opracowywania oprogramowania. Sprawiła, że praca nad oprogramowaniem jest mniej zniechęcająca.

Programując płytkę, można było wyeliminować ustawianie plików komend konsolidatora, ustandaryzować nazwy sygnałów, a IDE ukryły szczegóły kompilacji. Jednym z uroków Pythona jest to, że wymaga on ścisłego formatowania - na przykład wcięcia muszą być jednolite. Eliminuje to arbitralne wybory o niskich wartościach, a w efekcie upraszcza cały proces programowania, co z kolei zwiększa produktywność deweloperów. Potrzebujemy odpowiednika takiej platformy dla programowalnej logiki i cała branża musiałaby zacząć współpracować nad pewnym standardem.

Oto niektóre elementy, które wydają mi się ważne w budowaniu tego standardu. Arduino nie posiada wewnętrznej, rozbudowanej zdolności do modyfikowania swojej podstawowej architektury, np. uwzględniania zagnieżdżonych przerwań, więc załóżmy, że problemy logiczne, które mają być rozwiązane na platformie są na tyle proste, że dzisiejsze programowalne urządzenia logiczne mogą zmieścić się w ramach wszelkich ograniczeń czasowych. Płytka z programowalnymi urządzeniami logicznymi (programmable logic device board - PLDB) będąca odpowiednikiem Arduino, powinna mieć wystarczająco wolny zegar, aby zadziałał każdy projekt zawierający 1000 elementów logicznych. Oznacza to, że platforma wymaga jedynie weryfikacji funkcjonalnej.

Ponieważ wszyscy kochają Pythona, proponuję aby PLDB była obsługiwana właśnie przez ten język i zbudowana na szkielecie takim jak nMigen lub MyHDL (ilustracja 2), czy nawet Yosys RTLIL. Pozwoliłoby to początkującym symulować projekty układów logicznych za pomocą interpretowanego języka, tworzyć tablice prawdy i uzyskać dostęp do każdej innej dostępnej dla nich biblioteki Pythona. Skoro już mowa o bibliotece Pythona, używanie tego języka pozwala również społeczności na wykorzystanie indeksów pakietów Pythona (PyPI) w celu dystrybucji bloków sprzętowych wielokrotnego użytku, co pomaga rozwiązać problem braku solidnych, współdzielonych wzorców projektowych. nMigen, podobnie jak Python, wspiera metaprogramowanie, więc nawet jeśli szkielet ten będzie obsługiwał proste projekty, to platformę można wyskalować do obsługi złożonych projektów.

Ilustracja 2: szkielet oparty na Pythonie (źródła ilustracji: MyHDL.org i m-labs.hk)

Interfejs z głównego PC do PLDB powinien być złączem USB wraz z mikrokontrolerem wbudowanym w płytkę. Mikrokontroler powinien mieć interfejs programowania aplikacji dla głównego PC, by można było zapoznać się z konfiguracją PLDB i aby możliwe było automatyczne skonfigurowanie środowiska Pythona do programowania układów logicznych. Rezultatem takiego układu jest ukrycie szczegółów syntezy, miejsca i trasy oraz programowania przy jednoczesnym ułatwieniu symulacji funkcjonalnej na komputerze PC i jej realizacji na rzeczywistym sprzęcie.

Byście nie pomyśleli, że wszystkie proste problemy układów logicznych już rozwiązano, pozwólcie, że pokażę Wam kilka statystyk dotyczących sprzedaży mikrokontrolerów DigiKey. Ilustracja 3 ukazuje podział klas mikrokontrolerów, które kupują klienci, a ilustracja 4 ukazuje liczbę sprzedawanych jednostek każdej z klas. W sumie DigiKey posiada ponad 80000 numerów katalogowych mikrokontrolerów i magazynuje ponad 19000 mikrokontrolerów gotowych do natychmiastowej wysyłki do dowolnego miejsca na świecie. Liczby pokazują, że więcej inżynierów używa prostych 8-bitowych procesorów i że DigiKey dostarcza więcej 8-bitowych mikrokontrolerów niż jakiegokolwiek innego typu procesora. To oznacza, że prostych problemów jest więcej, niż tych złożonych.

Ilustracja 3: liczba klientów DigiKey kupujących dany typ mikrokontrolera (źródło ilustracji: DigiKey)

Ilustracja 4: liczba jednostek każdego typu mikrokontrolera sprzedawanych przez DigiKey (źródło ilustracji: DigiKey)

Naszym celem powinno być sprawienie, że nawet ci, którzy nie mają formalnego wykształcenia w zakresie projektowania układów logicznych, staną się entuzjastami logiki programowalnej. Aby to zrobić, musimy zmienić paradygmaty programowania.