Spodnia strona, która faktycznie będzie znajdować się na górze – jeszcze bez dołączonego wyświetlacza LCD. Widoczne są liczne kondensatory odsprzęgające w pobliżu FPGA.

Ta sama strona płytki, tym razem z podłączonym ekranem LCD. Sam ekran jest za pomocą dwustronnej taśmy samoprzylepnej umocowany tak, aby znajdował się nieco ponad płytką PCB i kondensatorami. Kabel debuggera mieści się zaledwie kilka milimetrów od kondensatora.

Warstwa sprzętowa była łatwiejszą częścią. Teraz czas na programowanie mikrokontrolera i projekt FPGA. To powinno być ciekawe.

Testowanie

Oczywiście pierwszym krokiem podczas testów jest podłączenie napięcia i uruchomienie urządzenia. Zapaliła się czerwona dioda LED – to już sukces. Następnie trzeba sprawdzić, czy mikrokontroler pracuje za pomocą debuggera ST-Link/v2 i spróbować połączyć się z układem za pomocą OpenOCD.

Wykorzystuję dostarczony przez producenta skrypt, który konfiguruje interfejs i wybrany mikrokontroler tak, jak gdyby była to płytka testowa F4 Discovery. Operacja zakończyła się sukcesem, zatem mikrokontroler powinien być teraz gotowy do zaprogramowania.

Kod testowy mikrokontrolera

Napisałem kilka małych programów testowych, aby sprawdzić różne funkcje płytki. Wszystkie kody są dostępne na Githubie. Kody wykorzystują bibliotekę stm32plus, która pozwala wykorzystać bogate funkcje układów peryferyjnych STM32. Choć biblioteka stm32plus nie obsługuje bezpośrednio mikrokontrolerów z serii F42x, wystarczy wykorzystać kod zbudowany dla serii F40x i nie używać żadnych funkcji związanych z dodatkowymi układami peryferyjnymi dostępnymi w modelu F429

GpioD<DefaultDigitalOutputFeature<10,11> > pd;
// loop forever switching it on and off with a 1 second
// delay in between each cycle
for(;;) {
pd[10].reset();
pd[11].set();
MillisecondTimer::delay(1000);
pd[10].set();
pd[11].reset();
MillisecondTimer::delay(1000);
}

Jest to kod migający naprzemiennie diodami LED.

Jednym z drobnych problemów, które trzeba było ominąć, było uruchomienie kodu i skonfigurowanie częstotliwości rdzenia na 180 MHz, używając tylko wewnętrznego oscylatora.  Po resecie i przed wywołaniem funkcji main() każdy program STM32 wywołuje procedurę, która konfiguruje drzewo zegara i ustala szybkości różnych szyn.

Nie mogłem znaleźć żadnego przykładowe kodu ST inicjalizującego model F429 przy użyciu wewnętrznego zegara wysokiej szybkości (HSI) o częstotliwości 16 MHz. Firma dostarcza arkusz Excela przeznaczony dla modeli F40x. Wykorzystałem go jako punkt wyjścia i skonfigurowałem mnożnik PLL tak, aby uzyskać taktowanie rdzenia 180 MHz. Przy okazji uporządkowałem kod ST – każdy, kto widział kiedyś dostarczony przez ST kod w języku C zrozumie, dlaczego. Gotowy kod uruchomieniowy jest dostępny na Githubie.

/*
* These are the key constants for setting up the PLL using 16MHz HSI as the source
*/

enum {
VECT_TAB_OFFSET = 0,      // Vector Table base offset field. This value must be a multiple of 0x200.
PLL_M           = 16,     // PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N
PLL_N           = 360,
PLL_P           = 2,      // SYSCLK = PLL_VCO / PLL_P
PLL_Q           = 8       // USB OTG FS, SDIO and RNG Clock =  PLL_VCO / PLL_Q (note 45MHz unsuitable for USB)
};

Sprawdziłem po kolei wszystkie układy peryferyjne – nie było żadnych problemów. Wyjścia GPIO, EEPROM oraz najważniejsze SDIO działały poprawnie. W tym momencie byłem bardzo zadowolony, choć nie dotknąłem nawet układu FPGA.

Konfiguracja FPGA

Konfiguracja FPGA przebiega analogicznie do programowania mikrokontrolera. Należy utworzyć skompilowany plik i korzystając z protokołu opracowanego przez producenta przesłać go do układu, o ile jest on już w stanie rozpocząć pracę. Różnica między FPGA a mikrokontrolererem jest taka, że ich konfiguracja jest ulotna – znika po wyłączeniu zasilania, zatem FPGA należy rekonfigurować za każdym razem po włączeniu zasilania.

Firma Xilinx zapewnia wiele różnych metod konfiguracji, które są świetnie udokumentowane. Wybrałem metodę o nazwie „slave serial”, która polega na wgraniu strumienia bitów przez zewnętrzny układ (mikrokontroler) za pomocą łącza szeregowego. Poniżej widać schemat z dokumentacji Xilinx, który przedstawia możliwy sposób konfiguracji. Usunąłem z niego wyprowadzenia JTAG, z których nie korzystam.

Problem polega na tym, że interfejs konfiguracji FPGA jest zasilany z napięcia VCCAUX o wartości 2,5 V, a mikrokontroler z napięcia 3,3 V. Na szczęście Xilinx to przewidział i opracował dokument referencyjny, który opisuje bezpieczny sposób konfiguracji FPGA z mikrokontrolera zasilanego napięciem 3,3 V.

Pełny sens dodatkowych układów został szczegółowo opisany przez Xilinx, natomiast postaram się go krótko streścić. Rezystory ograniczające prąd i rezystor bocznikujący obok stabilizatora 2,5 V pochłaniają nadmierny prąd, dzięki czemu stabilizator nie zobaczy prądu wpływającego do jego wejść, który potencjalnie mógłby uszkodzić układ.

Szybkość konfiguracji

Skompilowany i nieskompresowany plik binarny dla XC3S50 ma rozmiar 440.096 bitów. Maksymalna szybkość linii danych szeregowych dopuszczana przez Xilinx to 66 MHz, w przypadku kompresji – 20 MHz. Te wartości są podane w specyfikacji układu jako FCCSER.

Mój projekt wykorzysta niemal cały układ FPGA, zatem kompresja w czasie transmisji zapewniana przez FPGA nie jest użyteczna – mogę skorzystać z maksymalnej częstotliwości transmisji 66 MHz. Teoretycznie mogę zaprogramować FPGA w ciągu 440.096 / 66.000.000 * 1000 = około 7 ms. W praktyce występuje dodatkowy narzut na przesuwanie bitów na wyjściu i monitorowanie zmiany stanu pinów INIT_B oraz DONE. Ostatecznie wersja debug oprogramowania producenta może zaprogramować układ w ciągu około pół sekundy.

Kod źródłowy klasy odpowiedzialnej za konfigurację jest dostępny na Githubie. Kod wykorzystuje plik binarny skompilowany wewnątrz programu mikrokontrolera i umieszczony razem z nim w pamięci Flash. Sposób realizacji tej techniki jest przedstawiony tu.

Testowanie FPGA

Gdy mogę już skonfigurować FPGA, czas sprawdzić, czy montaż układu domową metodą powiódł się. Oczywiście w tym celu spróbuję zamigać diodą, co w elektronice stanowi odpowiednik „Hello World”.

Programowanie układów Xilinx

Gdy decydowałem się na naukę języka opisu sprzętu (HDL), dostępne do wyboru języki ograniczały się do dwóch opcji: VHDL lub Verilog. VHDL przypominał trochę takie stare języki, jak Pascal lub Ada. Verilog przypominał z kolei nieco C (to błędne wrażenie). Wolałem ścisłą i zrozumiałą składnię VHDL. Ponieważ pod względem możliwości między tymi językami nie ma różnicy, wybrałem VHDL. Zawodowi projektanci FPGA często znają obydwa te języki.

Xilinx oferuje darmowe środowisko projektowe ISE Webpack, które wymaga aż 17 GB miejsca na dysku. Środowisko zawiera narzędzia, które są jednocześnie rozbudowane i skomplikowane. Początkujący projektanci mogą preferować zintegrowane środowisko, które pomaga zrozumieć przebieg pracy – Xilinx oferuje takie dwa.

ISE Design Suite jest pierwszą opcją, którą polecam początkującym. Jest stworzone w języku skompilowanym do kodu maszynowego, zatem pracuje dość szybko i nie zużywa zbyt wielu zasobów podczas pracy narzędzi syntezy.

Nawigator projektu ISE jasno pokazuje przebieg syntezy. Łatwy w użyciu interfejs pozwala tworzyć i uruchamiać symulacje. Co ważne, pomaga zrozumieć znaczenie wielu dostępnych opcji linii komend.

Drugą możliwością jest stworzenie projektu za pomocą narzędzia Plan Ahead, którego nie polecam. Plan Ahead jest najwyraźniej napisane w Javie i z tego powodu bardzo obciąża system podczas syntezy. Na słabszym laptopie zauważyłem, ze zużycie procesora sięga 100% nawet podczas przeglądania plików wyjściowych pod kątem zmian. Jednak Plan Ahead jest wygodnym narzędziem do planowania rozkładu wyprowadzeń I/O – wyświetla wizualizację obudowy podczas wyboru pinów.

Jakiś czas temu rozpocząłem pracę z ISE Design Suite. Gdy przyzwyczaiłem się do metody pracy i opcji linii komend, przeszedłem na środowisko obsługiwane w całości z linii komend z użyciem mojego ulubionego edytora tekstu i narzędzia do budowy SCons. W tym projekcie nie używałem GUI ISE.

Jedną rzeczą, nad którą Xilinx zupełnie nie panuje, jest możliwość pracy z narzędziami z linii komend wraz z narzędziami do kontroli wersji. Narzędzia będą tworzyły dziesiątki plików wyjściowych, pośrednich i raportów w wielu podkatalogach katalogu źródłowego. Trzeba zmienić zasady za pomocą plików SConcript i .gitignore, aby opanować ten bałagan. Co więcej, program coregen.exe popełnia kardynalny błąd, modyfikując swój plik wejściowy. Przez to git zawsze widzi, że plik został zmodyfikowany. Zadaję sobie pytanie, czy zespoły piszące te narzędzia same faktycznie pracują z systemem kontroli wersji.