Kaczin wrote:

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

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

do góry

W dniu 18.06.2021 o 23:18, Piotr Wyderski pisze:
> Kaczin wrote:
>
>> Sądzisz, że oni o tym nie wiedzą?
>
> 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.
>

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

--
Kaczin

do góry

MiSter wrote:

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

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

> Wiem, że ten analizator potrafi dekodować Modbus.

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

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

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

do góry

Kaczin wrote:

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

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

do góry

W dniu 2021-06-18 o 10:17, Piotr Wyderski pisze:
> Atlantis wrote:
>
>> To nie żart, to punktoza za polskich uczelniach.
>
> Punktoza to jedna sprawa, ale pomijając absurdalność tej pracy,
Tyle że w tej 'pracy' nic nie ma, jedynie tabelki z 'osiągami' i tyle.
Liczyłem na program do fpga a tu nic.


--
Janusz

do góry

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

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

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ę.

>> Wiem, że ten analizator potrafi dekodować Modbus.
>
> Potrafi, ale akurat nie mam teraz niczego rozmawiającego po Modbus, więc
> się nie podłączę i nie odpowiem na Twoje pytania.

Próbowałem darmowego(przez 14 dni)
https://www.serial-port-monitor.org/modbus-scanner/


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


>     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.

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


> udało mi się odkryć kilka nieudokumentowanych sztuczek firmy Lattice i w
> oparciu o nie przeprogramowywać FPGA w kilka milisekund. Programatorowi

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

do góry

Piotr Wyderski <b...@p...com> wrote:
> Atlantis wrote:
>
> > To nie ?art, to punktoza za polskich uczelniach.
>
> 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?

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.

--
Waldek Hebisch

do góry

a...@m...uni.wroc.pl wrote:

> Pisza ze na ARM chodzi Linux. No to masz 1000 powodow ze
> cos sie moze przytkac.

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.

> Ogolniej, to jest na poziomie (gorszych) notek aplikacyjnych
> producentow. Nic odkrywczego, ale ludziom ktorzy tego wczesniej
> nie robili moze sie przydac.

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."

> Inna sprawa ze takie
> publikacje nie powinni sie liczyc do "dorobku naukowego",
> co najwyzej jako popularyzacje/rozpowszechnianie.

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

do góry

Piotr Wyderski <b...@p...com> wrote:
> a...@m...uni.wroc.pl wrote:
>
> > Pisza ze na ARM chodzi Linux. No to masz 1000 powodow ze
> > cos sie moze przytkac.
>
> Ale to jest ich zadanie, by to wyja?ni?. W tym celu m.in. mo?e na ARMie
> przesta? chodzi? Linux.

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

> 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.

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

> > Ogolniej, to jest na poziomie (gorszych) notek aplikacyjnych
> > producentow. Nic odkrywczego, ale ludziom ktorzy tego wczesniej
> > nie robili moze sie przydac.
>
> 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?.

Autorzy twierdza ze pisali w VHDL...

> 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.

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.

> 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."
>
> > Inna sprawa ze takie
> > publikacje nie powinni sie liczyc do "dorobku naukowego",
> > co najwyzej jako popularyzacje/rozpowszechnianie.
>
> 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?.

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.

> 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.

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

--
Waldek Hebisch

do góry

MiSter wrote:

> OK. Jakoś założyłem, że 32 kanały to minimum.

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

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

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

do góry