Zestaw uruchomieniowy na FPGA Gowin serii GW1N-9

[FlyingDutch]

Cześć,

odnośnie kompilatora skrośnego dla RISC-V dla ISA rv32i po poprawnym sklonowaniu repozytorium z Github:

https://github.com/riscv-collab/riscv-gnu-toolchain

próbowałem zbudować komilator komendami:

./configure --with-multilib-generator="rv32i-ilp32--;rv32imafd-ilp32--"
  
 make newlib

ale kończyło się to błędami kompilacji.

Udało mi się znaleźć kompilator skrośny dla rv32i już zbudowany w postaci binarnej:

https://github.com/stnolting/riscv-gcc-prebuilt

Zainstalowałem wersję "rv32i-131023" :

za pomocą komend bash'a:

$ sudo mkdir /opt/riscv
  
$ sudo tar -xzf riscv32-unknown-elf.gcc-13.2.0.tar.gz -C /opt/riscv/
  
$ export PATH=$PATH:/opt/riscv/bin

Sprawdziłem kompilację pliku "firmware.c" z podkatalogu "picosoc" dla projektu "picosoc" (zamieszczony dwa posty wyżej w tym wątku) i przebiegła ona bez błędów. Tak więc sprawa kompilatora dla soft-core o architekturze rv32i jest rozwiązana.

Pozdrawiam

[FlyingDutch]

Cześć,

ostatnio przeprowadziłem próby z dwoma wersjami soft-core RISC-V, były to projekty:

https://github.com/YosysHQ/picorv32/tree/master/picosoc

https://github.com/sipeed/TangNano-9K-example/tree/main/picotiny

Oba projekty były oparte o rdzeń CPU picorv32. Bez problemu udało się je zsyntetyzować w "Gowin EDA" (FPGA Designer) i wczytać na płytkę developerską z FPGA Gowin serii 9LV. problemem było natomiast wczytanie skompilowanego firmware'u (program w C skompilowany kompilatorem skrośnym dla RISC-V).

Do ładowania oprogramowania do rdzenia CPU słuzył tutaj  skrypt napisany w Pythonie o nazwie "pico-programmer.py" :

https://github.com/sipeed/TangNano-9K-example/blob/main/picotiny/sw/pico-programmer.py

Niestety wywołanie tego skryptu z właściwymi parametrami (port serial z CPU na FPGA z soft-core oraz nazwa skompilowanego pliku firmware):

bofh@4core:~/FPGA_DevBoard/picotiny/sw$ python3 pico-programmer.py example-fw-flash.v /dev/ttyUSB0
Read program with 11760 bytes
  - Waiting for reset -
    ..........
Picorv32-isp not detected or not in isp mode
Check serial port or check reset button
bofh@4core:~/FPGA_DevBoard/picotiny/sw$ 

nieodmiennie kończyło się błędem (timeout portu serial). Próbowałem sprawdzić poprawne dziąłanie klawisza reset dla soft_CPU (i reset wewnętrznego portu serial) i wszystko wydaje mi się OK w kodzie VHDL. Szukałem też informacji w sieci. ale nie znalazłem nic, co mogłoby pomóc w rozwiązaniu problemu.

Postanowiłem więć użyć innego bardziej zaawansowanego soft-core CPU (RISC-V) o nazwie "neorv32" o czym napiszę w nastepnym poście.

Pozdrawiam

[FlyingDutch]

Cześć,

jak już napisałem z powodu niemożności załadowania programu binarnego do poprzednich wersji soft-core CPU opartego na rdzeniu "picorv32" postanowiłem uzyć duzo bardziej zaawansowanego rdzenia "NEORV32" także opartego na rdzeniu CPU RISC-V. Tutaj link do repozytorium projektu na Github'ie:

https://github.com/stnolting/neorv32/tree/main

A tutaj link do dokumentacji:

https://stnolting.github.io/neorv32/#_rationale

Powodami wybrania tego rdzenia były:

1) Jasno zdefiniowany bootloader i jego działanie

2) Prebuilt GCC toolchains (kompilator skrośny dla ISA riscv32i)

3) Obszerna i dokładna dokumentacja

4) Duża liczba peryferiów dla MCU możliwych do wybrania w implementacji

Najpierw sklonowałem repozytorium neorv32 lokalnie i próbowałem korzystając z jednego z dostarczonych templates zsyntetyzować projekt w "Gowin EDA" ale nie zakończyło się to sukcesem z powodu skomplikowanej struktury plków żródłowych w języku VHDl (kilka podkatalgów ze źródłami i potrzeba skompilowani a części z nich jako biblioteki VHDL). Postaniowiłem sobie ułatwić życie i najpierw przetestować syntezę rdzenia NEORV32 w Xilinx Vivado (þlytka FPGA z Spartn7 Xilinx'a). Skorzystałem z jednego z gotowych skryptów w języku TCL z tego repozytorium:

https://github.com/stnolting/neorv32-setups

a dokładnie tego skrytpu:

https://github.com/stnolting/neorv32-setups/blob/main/vivado/arty-a7-test-setup/create_project.tcl

Uruchomienie tego skryptu w konsoli Vivado utworzyło kompletny projekt z prawidłowo zaimportowanymi plikami źródłowymi VHDL. Co prawda projekt był dla innej płytki FPGA z Artixem7 a nie Spartanem7, ale wystarczyło dostosować układ FPGA i zmienić plik "user constraints" (.xdc) dla mojem płytki FPGA.

Tak zmodyfikowany projekt Vivado zsyntetyzował się bez błędów i udało mi się go załadować do zestawu FPGA  ze Spartanem7 (pracuję pod OS Linux):

Jak widać na zrzucie ekranu struktura projektu jest mocno skomplikowana. Po wczytaniu do płytki FPGA pliku konfiguracyjneo z soft-core NEORV32 połączyłem się z portem serial dla CPU (/dev/ttyUSB0). Uruchomił się bootloader NEORV32 - patrz zrzut ekranu:

wcisnałem po kolejji klawisz "e" a potem "u" - bootloader rozpoczął oczekiwanie na przesłanie firmware (wersja binarna) poretm serial - wtedy z drugiej konsili wydałem komendę:

$ cat neorv32_exe.bin > /dev/ttyUSB0

w celu przesłania skompilowanego programu C (przykład Blink) do soft-core CPU. Niestety kończy się to błędem:

ERR_EXE

wyświetlanym przez bootloader. No i znowu będę musiął rozpocząć proces mający na celu ustalenie przyczyny błęðu.

Program C był skompilowany kompilatorem z tego projektu zainstalowanym wcześniej:

https://github.com/stnolting/riscv-gcc-prebuilt

tak, jak to opisałem kilka postów wcześniej. Kompilacja przykładu blink zakończyła się bez błędów:

bofh@4core:~/NEORV32/neorv32-setups-main/neorv32/sw/example/demo_blink_led$ make bin
Memory utilization:
   text	   data	    bss	    dec	    hex	filename
   1096	      0	      0	   1096	    448	main.elf
Compiling ../../../sw/image_gen/image_gen
bofh@4core:~/NEORV32/neorv32-setups-main/neorv32/sw/example/demo_blink_led$

Jeśli ktoś ma jakieś pomysły, co poszło nie tak to będę wdzieczny za ich przedstawienie.

BTW: zapomniałem dodać, że przed wydaniem komendy: "cat neorv32_exe.bin > /dev/ttyUSB0" wcześniej ustawiłem prędkość portu /dev/ttyUSB0 za pomocą komendy:

$ stty -F /dev/ttyUSB0 19200

Próbowałem też przesyłać firmware do portu serial za pomocą komendy "sz":

sudo apt-get install lrzsz

sz -b neorv32_exe.bin /dev/ttyUSB0

W tym drugim przypadku bootloader w nieskończoność czekał na przesłanie firmware (nie było żadnej reakcji bootloader'a).

Próbowałem też ustawić wszystkie parametry portu  /dev/ttyUSB0 komendą:

bofh@4core:~$ sudo stty -F /dev/ttyUSB0 19200 cs8 -parenb -cstopb

przed  wysyłaniem pliku binarnego, ale nie zmieniło to w żaden sposób działania bootloader'a.

Update: w katalogu projektu NEORV32 "/home/bofh/NEORV32/neorv32-setups-main/neorv32/sw/image_gen" znalazłem skrypt o nazwie: "uart_upload.sh" :

https://github.com/stnolting/neorv32/blob/main/sw/image_gen/uart_upload.sh

Próby użycia tego skryptu do upload'u firmware'u kończyły sie jednak jednym z dwóch błędów:

bofh@4core:~/NEORV32/neorv32-setups-main/neorv32/sw/image_gen$ sudo sh uart_upload.sh /dev/ttyUSB0 neorv32_exe.bin
Bootloader response error.
Reset processor before starting the upload.
bofh@4core:~/NEORV32/neorv32-setups-main/neorv32/sw/image_gen$

lub w stanie po reset FPGA:

bofh@4core:~/NEORV32/neorv32-setups-main/neorv32/sw/image_gen$ sudo sh uart_upload.sh /dev/ttyUSB0 neorv32_exe.bin
Uploading... Upload error.
bofh@4core:~/NEORV32/neorv32-setups-main/neorv32/sw/image_gen$ 

upload startował i po kilku sekundach był ten drugi błąd: "Uploading... Upload error"

Pozdrawiam

Edytowano Listopad 4, 2023 przez FlyingDutch
update

[FlyingDutch]

Cześć,

znalazłem w repozytorium bardziej szczegółowy opis bootloader'a w dokumencie:

https://github.com/stnolting/neorv32/blob/main/docs/datasheet/software_bootloader.adoc

Może to pomoże mi rozwiązać problem.

Update:

W końcu udało mi się ustalić jak bootloader (wersja binarna) jest wbudowany w soft-core NEORV32 - dzieje się to w pliku źródłowym VHDL o nazwie "neorv32/rtl/core/neorv32_bootloader_image.vhd" - patrz link:

https://github.com/stnolting/neorv32/blob/main/rtl/core/neorv32_bootloader_image.vhd

Zastanawiałem się jak się ma binarny obraz booloadera wbudowywany w projekt FPGA soft-core do pliku źródłowego programu bootloadera w języku C - patrz link:

https://github.com/stnolting/neorv32/blob/main/sw/bootloader/bootloader.c

Teraz już wiem - trzeba skompilować program bootloadera kompilatorem skrośnym dla RISC-V  i zamienić postać binarną(skompilowaną) na plik w formacie takim jak jest w pliku "neorv32/rtl/core/neorv32_bootloader_image.vhd", czyli wartości hex - jedna w wierszu (da się to zrobić prostym skryptem np. w Pythonie).

Chcę przekompilować program bootloadera w C, tak abym wyrzucał więcej informacji diagnostycznych prez UART'a.

Pozdrawiam

 

Edytowano Listopad 5, 2023 przez FlyingDutch
update

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[FlyingDutch]

Cześć,

w końcu bootloader zadziałał prawidłowo:

bofh@4core:~/NEORV32/neorv32-setups-main/neorv32/sw/image_gen$ sudo sh uart_upload.sh /dev/ttyUSB0 neorv32_exe.bin
Uploading... Done.
bofh@4core:~/NEORV32/neorv32-setups-main/neorv32/sw/image_gen$

Użyłem tego skryptu dostarczonego z projektem. Przyczyną nie działania wcześniej było wybranie złego targetu dla kompilacji kompilatorem skrośnym dla RISC_V. Myslałem, że do załadowania programu potrzebna jest jago wersja bez nagłowka (bin) i do kompilacji użyłem komendy:

make bin

a okazało się iż przez bootloader była oczekiwana wersja z pełnym nagłówkiem. Po kompilacji za pomocą:

make exe

i użyciu tego nowo skompilowanego pliku binarnego booloader zadziałał prawidłowo 🙂

Pozdrawiam

[FlyingDutch]

Cześć,

dzisiaj załadowałem do soft-core NEORV32 benchmark "coremark". Źródła benchmark'u "coremark" były w podkatalogu projektu z przykładami:

https://github.com/stnolting/neorv32/tree/main/sw/example/coremark

Po skompilowaniu kompilatorem skróśnym dla RISC-V program wykonywalny miał rozmiar niecałe 20 KB. Musiałem w projekcie FPGA zwiększyć lokalną pamięć instrukcji soft-cpu do 20 KB:

entity neorv32_test_setup_bootloader is
  generic (
    -- adapt these for your setup --
    CLOCK_FREQUENCY   : natural := 50000000; -- clock frequency of clk_i in Hz
    MEM_INT_IMEM_SIZE : natural := 20*1024;   -- size of processor-internal instruction memory in bytes
    MEM_INT_DMEM_SIZE : natural := 6*1024     -- size of processor-internal data memory in bytes
  );

Po wczytaniu pliku konfiguracyjnego projektu do FPGA - mogłem załadować program binarny z benchmarkiem "coremark" poprzez bootloader do NEORV32. Uruchomiłem program w pamięci soft-cpu i musiałem trochę poczekać na wynik (benchmark był liczony dla 2000 iteracji. Na zrzucie ekranu poniżej wyniki tego benchmarku:

Soft processor NEORV32 był taktowany zegarem 50 Mhz. Wynik "coremark" dla tego soft-core to 14 iteracji na sekundę. Dzieląc 14/50 MHz wychodzi wynik: 0.28 iteracji /s na 1 MHz, co jest słabym wynikiem. Poniżej zamieszczam trochę wyników tego benchmarku dla różnych mikroprocesorów:

https://en.wikichip.org/wiki/coremark-mhz

https://www.st.com/content/st_com/en/arm-32-bit-microcontrollers/arm-cortex-m4.html

Jak widać dla ARM Cortex-M1 coremark wynosi 1.85 iteracji/s na Mhz, a dla ARM cortex-M4 - 3.42. Tak słaby wynik wynika z faktu, że nasz soft-processor nie ma zaimplementowanych operacji mnożenia i dzielenia oraz modułu floating-point (benchmark "coremark" mocno opiera się o operacje rachunkowe i np. mnożenie macierzy).

Tutaj link do "coremark" na GitHub'ie:

https://github.com/eembc/coremark/blob/main/README.md

Postaram się teraz dodać instrukcje mnożenia i dzielenia do soft-cpu NEORV32 i zobaczę jakie będą wyniki "coremark"

Update:

jednak instrukcje mnożenia i dzielenia (integer - stałoprzecinkowe) były zaimplementowane. Dodałem blok FPU (floating-point unit) i flagę,  aby używać błoków DSP do mnożenia i dzielania. Zobaczymy jakie będą wynik "coremark" po tych zmianach.

Niestety dodanie FPU nie zmieniło wcale wyników "coremark". Ciekaw jestem jaki jest wynik "coremark" dla soft-core "Microblaze" Xilinx'a, będę musiał to poszukać.

Udało mi się znaleźć wyniki "coremark" dla soft-cpu Xilinx'a "Microblaze" - wyniki sa ne tej stronie WWW:

https://www.jblopen.com/microblaze-benchmarks-part-1-coremark-performance/

Jak widać średni wynik "coremark" dla Xilinx Microbleze wynosi około 2 iteracji/s / MHz - z tego wynika, że ogólnie procesory implementowane w układach FPGA są malo wydajne. Wniosek dość smutny, jeśli ktoś chciałby uzywać soft-core CPU w "prawdziwych" projektach.

Pozdrawiam

Edytowano Listopad 7, 2023 przez FlyingDutch
update

[FlyingDutch]

Cześć,

dzisiaj wlutowałem ostatni brakujący element sprzętowy - czytnik kart uSD z interfejsem SPI (widoczny po lewej stronie płytki:

Pozdrawiam

[FlyingDutch]

Cześć,

ostatnio kolega @H1M4W4R1 dołączył do projektu i zaprojektował nową bardziej profesjonalną wersję płytki PCB dla tego zestawu FPGA. Schemat układu został już wczesniej przeze mnie zweryfikowany w pierwszej wersji prototypu i wszystkie podzespoły sprzętowe działają poprawnie. W tej wersji płytki PCB sygnały szybkozmienne i pary różnicowe zostały zaprojektowane z kontrolą dlugości ścieżek. To co wyróznia ten zestaw to fakt, iż każdy z czterech banków pinów I/O układu FPGA może być zasilane jednym z trzech wartości napięcia: 3,3V , 2,5V i 1,2 V. Poza tym ma wyprowadzone na złącza aż 64 piny I/O - w gotowych zestawach developerskich FPGA przeważnie jest wyprowadzonych poniżej 30 pinów I/O co uniemożliwia implementację większych projektów.

Podaję link do nowej wersji PCB dla tego zestawu umieszczonej w poście kolegi @H1M4W4R1:

Docelowo chcę na Github'ie umieścić projekt sprzętowy dla tego zestawu jak i przykładowe projekty w językach Verilog i VHDL.

Czekam na wasze komentarze, co sądzicie o takim zestawie developerskim FPGA?

Pozdrawiam

[FlyingDutch]

Cześć,

dzisiaj przyszły płytki do tego zestawu FPGA od Chińczyków. Nie mam jeszcze wszystkich częśći - brakuje mi headrerów, switchy, DIP-Switchy i układów FTDI, ale dzisiaj zamówiłem brakujące części i kiedy przyjdą biorę się za montaż trzech sztuk.

Pozdrawiam

[H1M4W4R1]

31 minut temu, FlyingDutch napisał:

Chyba kilka rezystorów dałem ciut za blisko krawędzi... Ale to ujdzie w tłumie, to prototyp... No i te przelotki w ringu trochę duże wyszły, ale mimo to płytkę wykonali całkiem ładnie. Teraz tylko modlić się, by działała bez problemów...