Komunikacja ARM z FPGA przez SPI

Początkowo myślałem, że to żart, ale nie -- czterech doktorów inżynierów to napisało:

formatting link
Następny będzie LED blinker?

Pozdrawiam, Piotr

Reply to
Piotr Wyderski
Loading thread data ...

To nie żart, to punktoza za polskich uczelniach.

Reply to
Atlantis

Punktoza to jedna sprawa, ale pomijając absurdalność tej pracy, zastanawia mnie też, czemu doktory nie wiedzą, co jest przyczyną, że na zegarze 24MHz uzyskują 2MiB/s zamiast teoretycznych 3MiB/s.

Doktory nie mają analizatora stanów, by sobie rzucić okiem, co się naprawdę dzieje na szynie stuprocentowo *synchronicznej* i spróbować dociec przyczyny w (niewłaściwej) konfiguracji procka?

Pozdrawiam, Piotr

Reply to
Piotr Wyderski

Tego pisma nie ma w wykazie pism, za które przyznawane są punkty. Może w AGH liczą Na sztuki?

P.P.

Reply to
Paweł Pawłowicz

W dniu 2021-06-18 o 00:24, Piotr Wyderski pisze:

Ba... kiedyś na jakiejś konferencji naukowej pamiętam, że ktoś opublikował i wygłosił referat nt. obsługi seriala w ośmiobitowym PIC...

Reply to
MiSter

Nie wiem czy doktory są w posiadaniu analizatora stanów logicznych, ale z całą pewnością można stwierdzić, że ty masz kryształową kulę.

Reply to
Kaczin

SPI to magistrala synchroniczna i ma zasadniczo tylko dwa tryby pracy: coś jest nadawane, albo nic nie jest nadawane. Jak nic nie jest nadawane, to na analizatorze pomiędzy bajtami jest widoczna gołym okiem dziura i jak na dłoni widać, co zawiniło. Nie trzeba snuć teorii o wait states.

Dokładnie coś takiego debugowałem sobie przed dwoma tygodniami, no ale to było w ramach uczciwej roboty, a nie jako "Praca wykonana w ramach realizacji projektu rozwojowego." Publikacji z tego raczej nie będzie, nawet w Przeglądzie Technologii Komunikacyjnych i Męczenia Węża.

Piotr

Reply to
Piotr Wyderski

"Implementation of fast and *reliable*". Polski abstrakt wyraźnie mniejszy i w innym temacie a tekst znowu w trzecią stronę.

Może jednak w pełnym tekście jest coś odkrywczego mimo kiepskiego tytułu i jeszcze gorszego abstraktu PL? Choć przyznaje że przeglądnąłem i jakoś nie zaczepiło mi się o nic oko :/

Ponadto na końcu jest dopisek że to w ramach jakiegoś grantu:

formatting link
"58.PBR VIN R03 0061 06/2009Przenośny system diagnozowania maszyn wirnikowych wykorzystujący metody synchronizowane cyklem roboczymAkademia Górniczo-Hutnicza im. St. Staszica2009-08-012011-12-31963200.00963200.00"

Gdzieś dawno temu ktoś wytargał taką pracę naukową o miganiu diodą na jednej z grup, tak dla śmiechu. Jednak, jak się przeczytało nie tylko abstrakt, to się okazało że oceniono jak migać tak, aby ludzie oko widziało jak najwięszy stosunek jasność/moc. To było dość skomplikowane matematycznie, z modelowaniem oka, działania mózgu itd itp i wyszło że można oszczędzić ileśtam procent mocy, sterując LEDem w okreslony sposób (bodaj dwoma poziomami jasności, nie pamiętam dokładnie konkluzji).

Tylko że tutaj pewnie tak nie będzie ;)

Reply to
heby

Sądzisz, że oni o tym nie wiedzą?

Reply to
Kaczin

Wiem, że do tego używasz LA5032 :)

Wiem, że ten analizator potrafi dekodować Modbus.

Interesuje mnie na jakim poziomie szczegółowości jest ta transmisja dekodowana? Czy np. nie rozjeżdżają się ramki?

Szukam jakiegoś sprawdzonego rozwiązania i nie wiem czy ten analizator nada się do tego.

MiSter

Reply to
MiSter

Nie mam pojęcia, co oni wiedzą, widzę tylko to, co napisali. A napisali tak:

"Podsumowując uzyskana maksymalna teoretyczna szybkość transmisji dla częstotliwości 24 MHz wynosi 3 MB/s. Rzeczywista zmierzona szybkość transmisji wynosiła około 2 MB/s. Warto podkreślić, że dla relatywnie dużego bloku transmitowanych danych naddatek przyjętego protokołu transmisji jest znikomy i raczej nie wpływa na powyższą degradacje. Dlatego zmieszenie transmisji należy upatrywać w dodatkowych stanach oczekiwania wprowadzanych w procesorze ARM, układ FPGA zgodnie z przyjętym protokołem nie może wprowadzać dodatkowych opóźnień transmisji."

"Raczej" i "należy upatrywać" sugerują, że nie wiedzą. Przesłali blok danych, zmierzyli czas i im wyszło 66% maksimum. Na wykresie z analizatora niczego nie "należy upatrywać", bo wszystko widać. W moim układzie taktowanie to 8MHz przy prędkość SPI 8Mbit/s. Interfejs transferuje *dokładnie* jeden bit na cykl, mam 100% wykorzystanie pasma.

Piotr

Reply to
Piotr Wyderski

I twój interfejs działa ze 100% skutecznością, tak? Błędy transmisji się nie zdarzają?

Reply to
Kaczin

LA5016. Nie miałem jeszcze potrzeby skorzystania ze wszystkich 16 kanałów jednocześnie, więc 32 tym bardziej.

Potrafi, ale akurat nie mam teraz niczego rozmawiającego po Modbus, więc się nie podłączę i nie odpowiem na Twoje pytania.

To bardzo dobry i intuicyjny w obsłudze analizator z masą bardzo wygodnych i dopracowanych dekoderów protokołu. Szczerze polecam, ale ma swoje wady:

  1. Rozumie tylko szyny single-ended. Transmisji LVDS, a takich mam teraz dużo, nie rozumie, więc trzeba kombinować z przystawką-odbiornikiem. 2. Kanały nie są idealnie wyrównane pod względem czasu propagacji. Przy pomiarze na zakresie 500MHz potrafi się pomylić o nanosekundę i zbocza przebiegów w teorii doskonale synchronicznych z rzadka trafiają do różnych kubełków, sugerując nieistniejące przesunięcie czasowe. Normalnie nie jest to problem, ale jak się akurat debuguje nadajnik emulujący LVDS, to można na pewien czas pójść w maliny.

Ale w swojej klasie cenowej to jest znakomity przyrząd i oszczędził mi mnóstwo życia. Dzięki podsłuchiwaniu nim JTAGa w programatorze MachXO2 udało mi się odkryć kilka nieudokumentowanych sztuczek firmy Lattice i w oparciu o nie przeprogramowywać FPGA w kilka milisekund. Programatorowi zajmuje to kilkanaście sekund, choć tryb nazywa się "Fast SRAM programming".

Pozdrawiam, Piotr

Reply to
Piotr Wyderski

Błędy transmisji na SPI i szynie długości 2cm? Nie, nie zdarzają się. Po stronie procesora DMA dba o stałe wypełnienie buforów SPI i interfejs pracuje z maksymalną wydajnością. Po stronie FPGA strumień z procesora wygląda jak rozmowa z jąkającym się ślimakiem. Układ bez wielkiego wysiłku obsługuje jeszcze drugi interfejs z efektywną częstotliwością taktowania ~700MHz -- tu szyna ma wiele metrów i błędy się zdarzają.

Piotr

Reply to
Piotr Wyderski

Tyle że w tej 'pracy' nic nie ma, jedynie tabelki z 'osiągami' i tyle. Liczyłem na program do fpga a tu nic.

Reply to
Janusz

W dniu 2021-06-18 o 23:37, Piotr Wyderski pisze:

OK. Jakoś założyłem, że 32 kanały to minimum. Kiedyś to i 100 kanałów było mało, jak się debugowało np. Motorolkę 68000. Potem nastała era ChipScope i takie analizatory poszły w odstawkę.

Próbowałem darmowego(przez 14 dni)

formatting link

Coś wyrzuca dużo Checkum BAD, próbowałem dopytać w czym problem, niestety nie odpisali. Tzn. odpisali, że analizują problem :)

Od kilku lat nie jestem w temacie FPGA, ale domyślam się, że to popędzasz FPGA, czy korzystasz ze wspomnianego ChipScope Xilinxa?

Tak. Ogólnie to każdy analizator to bardzo dobre narzędzie. Swego czasu korzystałem z analizatora USB, w wielu protokołach można było zobaczyć vendor-specific feature :)

MiSter

Reply to
MiSter

Pisza ze na ARM chodzi Linux. No to masz 1000 powodow ze cos sie moze przytkac. Jak im 2MiB/s wystarcza to sie nie dziwie ze nie wnikali co sie przytyka.

Ogolniej, to jest na poziomie (gorszych) notek aplikacyjnych producentow. Nic odkrywczego, ale ludziom ktorzy tego wczesniej nie robili moze sie przydac. Inna sprawa ze takie publikacje nie powinni sie liczyc do "dorobku naukowego", co najwyzej jako popularyzacje/rozpowszechnianie.

Reply to
antispam

Ale to jest ich zadanie, by to wyjaśnić. W tym celu m.in. może na ARMie przestać chodzić Linux. Ile linii ma program w C wysyłający przez SPI dane z maksymalną prędkością interfejsu?

// inicjalizacja rejestrów

for(int i in dużo) { while(SPI_TX_BUSY); SPI_TX_BUF=0x55; }

W drugim kroku, po sprawdzeniu oscyloskopem, że GPIO działa, ta pętla powinna zostać przeniesiona na DMA.

Praca skupia się na przepustowości połączenia, więc rezultat inny niż wartość maksymalna przy tak elementarnym interfejsie świadczy o niedbałości lub niekompetencji.

Nawet ludzie, którzy tego wcześniej nie robili domyślają się, że da się połączyć FPGA z MCU przez SPI. Zapewne chcieliby dowiedzieć się jak się robi np. SPI slave w Verilogu, ale z tej publikacji się nie dowiedzą. A szkoda, bo w tym problemie występuje co najmniej jedno przekroczenie domeny zegarowej i trzeba to "umić", z odpowiednią dyskusją konstrukcji synchronizatora dla czytelników. W przeciwnym razie, jak to ujął Kaczin, "interfejs nie będzie działał ze 100% skutecznością", bo im się przy tych prędkościach metastabilność będzie pojawiać co kilka milisekund.

Mam pewne przypuszczenia, że dokładnie tu leży inny ich problem:

"Doświadczalnie osiągniętą maksymalną częstotliwością transmisji danych jest 24 MHz, przy częstotliwości 48 MHz występują błędy podczas transmisji spowodowane najprawdopodobniej nie najlepszą jakością elektrycznego połączenia płyt ARM i FPGA."

Może tak, może nie -- nie pokazali kodu, to zostają tylko spekulacje. A spróbowały szanowne doktory skrócić i zaekranować te kabelki?

Dlatego wartość edukacyjna tej pracy jest zerowa. Abstrakt tej pracy powinien brzmieć "Udało nam się połączyć FPGA z ARM przez SPI, ale działa nam wolniej, niż powinno. Nie spróbowaliśmy wyjaśnić, dlaczego. Dziękujemy Ministerstwu Dziwnych Kroków za sfinansowanie naszej zabawy."

No ale czego się z niej dowiedziałeś, Waldku? Że się da połączyć procesor z FPGA za pomocą SPI? No to da się jeszcze UARTem, I2C, I3C i I2S. Bo jak, to się nie dowiedziałeś. Ja bym tego nie przyjął jako sprawodzania z laboratorium, a tym panom to ktoś opublikował.

W tym świetle "Elektronika dla Wszystkich" jawi się jako czasopismo z Listy Filadelfijskiej, bo tam się trzeba podzielić kodem z czytelnikami. Recenzent też jest znacznie bardziej wymagający.

Pozdrawiam, Piotr

Reply to
Piotr Wyderski

OMAP3530 to raczej wymaga dosc skomlikowanego inicjowania, bez gotowca (jak Linux) to sporo roboty.

Jak masz sporo warstw sofware to czesto wydajnosc jest nizsza niz "teoretyczna". Nazwij jak chcesz, ale to fakt.

Autorzy twierdza ze pisali w VHDL...

Moze jest naiwny (dla mnie na razie FPGA to teoria), ale synchronizacja szyn to powinien byc prosty standartowy blok. Tak a propo, przy zegarach z pracy synchronizatory przy pinach SPI bylyby prostsze.

Ze da sie polaczyc i uzyskac 2MiB na Linuxowym driverze. Ze calosc wymaga minimalnej modyfikacji standartowych blokow FPGA i ze zuzycie zasobow FPGA jest skromne. To sie moze wydawac oczywiste, ale np. ludzie ktorzy zakladali ze na Raspberry Pi obsluza klasyczne MIDI przekonali sie ze sa problemy.

No, o ile wiem w EdW norma bylo wystawianie binarek bez zrodel. Moze to sie zmienilo, ale piszemy o artykule z roku 2011.

Reply to
antispam

Teraz drutów ubywa, za to megaherców gwałtownie przybywa.

Kostek Xilinxa akurat ostatnio nie używam, podobnie z Alterą/Intelem. Ci producenci skupili się na układach high-end, z setkami IO i wynikającymi z tego dużymi i dziwnymi obudowami. Teraz głównie pracuję w zakresie 1-10kLUT, za to dostępność układu w obudowie QFN jest wielkim plusem. Da się zarówno sprawdzić jakość połączenia, jak i poroutować płytkę na czterech warstwach, co drastycznie obniża koszty PCB. Osiem warstw, ścieżki szerokości 0.07mm i wiercone laserowo microvias o średnicy 0.1mm to nie są ceny chińskie, a dokładnie takie parametry zaleca dokument dot. obudów WLSCP i BGA 0.4mm. Więc zostaje mi niemal wyłącznie Lattice i jakieś niszowe Microsemi.

ChipScope i podobne to są narzędzia do debugowania *wewnątrz* FPGA, a czasami zachodzi potrzeba pooglądania tego, co się dzieje "na drutach". No i jeśli te druty to LVDS, to LA5xxx sobie nie poradzi. Co jest dość dziwne, bo coś mi się mgliście kojarzy, że wewnątrz jest Cyclone IV, no ale co poradzić -- takiej funkcji nie dodali.

Pozdrawiam, Piotr

Reply to
Piotr Wyderski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.