Chcę przenieść układ rakiety na układ FPGA inny niż Zynq (alterna Stratix V), który nie zawiera jądra ARM używanego do uruchamiania riscv-fesvr. Jak mogę uruchomić port? Czy ktoś próbował uruchomić układ rakietowy na takiej planszy? Czy mogę wskazać na pewne zasoby?Układ rakietowy na układach FPGA innych niż Zynq
Jest to głównie kwestia powiązań, ponieważ Rocket Chip nie używa niczego specyficznie dla Zynq. Jeśli ten interfejs zostanie wykonany prawidłowo, nie powinieneś zmieniać pk/linux ani samego układu Rocket Chip. Musisz oblać Rocket Chip dla docelowej FPGA i połączyć się z nim za pomocą serwera Frontend (fesvr).
Do zawijania Rocket Chip, patrzę na najwyższe oczekiwane IO (RocketChip.scala), które przede wszystkim obejmuje HostIO (dla HTIF) i MemIO (dla DRAM). Aby uzyskać dodatkowe informacje na temat tych interfejsów, skonsultowałbym się z slides z first workshop. Nasz aktualny wrapper (rocketchip_wrapper.v) multipleksuje te interfejsy przez AXI do rdzenia ARM hosta, na którym działa fesvr.
Twoja propozycja wysłana na listę mailingową z uruchomionym programem fesvr na rdzeniu NIOS II i komunikowanie się z nim za pośrednictwem AXI może działać. Będzie to wymagać modyfikacji (fesvr-zedboard.cc) w celu dopasowania interfejsu AXI, który NIOS zapewnia oprogramowaniu. Takie podejście może wymagać najmniej nowego rozwoju, ale soft-core pochłonie zasoby FPGA i może być wolniejsze.
Innym sposobem na osiągnięcie tego byłoby uruchomienie serwera frontonu na komputerze podłączonym do karty za pośrednictwem sieci Ethernet. Będziesz musiał stworzyć most między Memio Rocket Chip a pokładową pamięcią DRAM. Będziesz także musiał uruchomić HTIF przez ethernet, który będzie wymagał innego mostu pomiędzy Hostio i MAC sieci Ethernet. Wiele lat temu fesvr wspierał to (fesvr-eth.cc), ale ten kod nie został utrzymany i prawie na pewno będzie trzeba go zaktualizować.
To wszystko zakłada, że chcesz uruchomić procesor w sposób uwięziony. Aby uczynić go samodzielnym uruchamianiem, będzie wymagało więcej pracy. Trwają prace nad specyfikacją platformy, która to ujednolici, ale do tego czasu będziesz musiał zaprojektować własną lub nadal używać spętanych rakiet Rocket.
Spójrzmy na przykład użycia rdzenia rakietowego wewnątrz przenośnego VHDL na najwyższym poziomie. Ten projekt ma bardzo podobną strukturę do Leon3, który może być bardzo łatwy do przeniesienia na dowolną kartę FPGA. Zobacz:
mam przeniesiony jednordzeniowy procesor rakietowym na Non-Zynq FPGA (tablice: ML605 i KC705) i jestem zainteresowany, aby przenieść go na inne cele (patrz powyższy komunikat "https://github.com/sergeykhbr/riscv_vhdl "). Jeśli więc chcesz użyć proponowanego projektu vhdl i jesteś gotowy do współpracy, myślę, że mogę ci w tym pomóc, a jako wynik dodaj plik projektu Quartus do repozytorium.
Dodatkowo istnieje możliwość ponownego wykorzystania licencjonowanych peryferiów GPL zaimplementowanych w 'grlib': http://www.gaisler.com/index.php/downloads/leongrlib. takich jak MAC, kontroler SD i wiele innych.
Interfejs hosta w rdzeniu ARM jest zamapowany jako ogólny obiekt zamówienia IO odwzorowany w pamięci. Interfejs tworzy plik/dev/mem w rdzeniu ARM, a następnie rdzeń rakiety uzyska dostęp do tej fizycznej pamięci. Czy mam rację? Więc nie sądzę, że istnieje jakiś konkretny dostęp AXI zapewniony przez to. Więc co muszę zmienić w kodach fesvr? Ponadto, jak uzyskać przesunięcie stosowane w mmap (dev_paddr)? – user2888398
Ponadto, gdy już zainstaluję zmodyfikowaną wersję fesvr, generuję określone pliki w katalogu budowania. Jak mam korzystać z tego nowego fesvr? Gdzie go uwzględnić, aby móc z niego korzystać? – user2888398
Wszystko, co mogę znaleźć: Podczas instalacji fesvr-zynq, nie zapomnij skopiować również biblioteki (build/libfesvr.so do/usr/local/lib na płycie).Czy możesz to wyjaśnić? – user2888398