Taka ciekawostka mi się ostatnio pojawiła: grupa urządzeń będzie sie
komunikowała przez kilkudziesięciometrową linię za pomocą M-LVDS lub
B-LVDS (jako następca dla RS-485 half duplex, niech spoczywa w pokoju) z
prędkością 100-200Mbps. Taka prędkość oznacza FPGA, żaden procesor sobie
nie poradzi. To nawet fajnie, projekt będzie ciekawszy. Tylko trzeba to
FPGA czymś skonfigurować. Wymagania trwałościowe jak to zwykle u mnie,
flash nie jest nawet rozważany, więc zostaje FRAM, MRAM lub starodawny
układ FPGA antifuse. Potrzeba nieco mniej niż megabit, więc patrzę na ceny:

https://pl.mouser.com/ProductDetail/Cypress-Semicond
uctor/FM25VN10-G?qs=pA5MXup5wxGUOnPqXyyPhg%3D%3D

38.80 za 100 szt. OK, ale pojawiły się też pamięci memrystorowe o
całkiem apetycznym retention time rzędu miliona lat w temperaturze 65
stopni:

https://pl.mouser.com/ProductDetail/Avalanche-Techno
logy/AS3001204-0054X0ISAY?qs=eP2BKZSCXI6QNYQukdvSPg%
3D%3D

po 26.73 dla 100 szt. Tylko są takie ciekawe procesory TI z pamięcią
FRAM zamiast flash; dla kostki 128kB:

https://pl.mouser.com/ProductDetail/Texas-Instrument
s/MSP430FR5962IRGZR?qs=6BVwEky2YVxmw%2FnfZ4%252BK2Q%
3D%3D

cena wychodzi 16.28zł i niewiele więcej dla wersji 256kB (2Mbit).
Oszczędzając więc 10 złotych dostaję jeszcze całkiem przyjemny procesor
m.in. z ADC, którego FPGA nie ma. To żaden problem zmieścić wszystko w
FPGA, ale skoro mogę w procesor wrzucić obsługę większości "bzdur", to
warto -- w C pisze się znacznie szybciej niż w VHDL. Obudowy VQFN48 i
SO8 są wymiarowo podobne, a skoro i tak muszę mieć na płytce takiego czy
innego scalaka, to co mi za różnica, co w nim siedzi... Ciekawe czasy.
Tyle się pisze o rewolucji SoC, a w praktyce ciagle lepiej wychodzi
ulepić to sobie z osobnych elementów.

Pozdrawiam, Piotr

do góry

W dniu 2021-04-25 o 21:53, Piotr Wyderski pisze:
> Taka ciekawostka mi się ostatnio pojawiła: grupa urządzeń będzie sie
> komunikowała przez kilkudziesięciometrową linię za pomocą M-LVDS lub
> B-LVDS (jako następca dla RS-485 half duplex, niech spoczywa w pokoju) z
> prędkością 100-200Mbps. Taka prędkość oznacza FPGA, żaden procesor sobie
> nie poradzi. To nawet fajnie, projekt będzie ciekawszy. Tylko trzeba to
> FPGA czymś skonfigurować. Wymagania trwałościowe jak to zwykle u mnie,
> flash nie jest nawet rozważany, więc zostaje FRAM, MRAM lub starodawny
> układ FPGA antifuse. Potrzeba nieco mniej niż megabit, więc patrzę na ceny:
>
> https://pl.mouser.com/ProductDetail/Cypress-Semicond
uctor/FM25VN10-G?qs=pA5MXup5wxGUOnPqXyyPhg%3D%3D
>
>
> 38.80 za 100 szt. OK, ale pojawiły się też pamięci memrystorowe o
> całkiem apetycznym retention time rzędu miliona lat w temperaturze 65
> stopni:
>
> https://pl.mouser.com/ProductDetail/Avalanche-Techno
logy/AS3001204-0054X0ISAY?qs=eP2BKZSCXI6QNYQukdvSPg%
3D%3D
>
>
> po 26.73 dla 100 szt. Tylko są takie ciekawe procesory TI z pamięcią
> FRAM zamiast flash; dla kostki 128kB:
>
> https://pl.mouser.com/ProductDetail/Texas-Instrument
s/MSP430FR5962IRGZR?qs=6BVwEky2YVxmw%2FnfZ4%252BK2Q%
3D%3D
>
>
> cena wychodzi 16.28zł i niewiele więcej dla wersji 256kB (2Mbit).
> Oszczędzając więc 10 złotych dostaję jeszcze całkiem przyjemny procesor
> m.in. z ADC, którego FPGA nie ma. To żaden problem zmieścić wszystko w
> FPGA, ale skoro mogę w procesor wrzucić obsługę większości "bzdur", to
> warto -- w C pisze się znacznie szybciej niż w VHDL.
No ale procesor Ci tej transmisji nie obsłuży, tyle że może on wgrać
program do jakiego fpga i już osobnego procka nie musisz dawać. ale
nadal musisz na tą trasmisję w vhdl-u program napisać :)


Obudowy VQFN48 i
> SO8 są wymiarowo podobne, a skoro i tak muszę mieć na płytce takiego czy
> innego scalaka, to co mi za różnica, co w nim siedzi... Ciekawe czasy.
> Tyle się pisze o rewolucji SoC, a w praktyce ciagle lepiej wychodzi
> ulepić to sobie z osobnych elementów.
Może to wynika z tego że trudno zrobić wszystkie 'ukłądanki' zkilku
klocków, zawsze czegoś brakuje, a na procku zrobisz prawie wszystko
dokładając jeden czy dwa klocki.
Na tej samej zasadzie nie przyjeły za bardzo się procki z rozbudowanymi*
układami analogowymi typu wzmacniacze czy inne, trochę lepiej jest z
prockami z cpld ale też szału nie ma.

* nie liczę z pojedynczymi wzmacniaczami czy komparatorami.
--
Janusz

do góry

Janusz wrote:

> No ale procesor Ci tej transmisji nie obsłuży, tyle że może on wgrać
program do jakiego fpga i już osobnego procka nie musisz dawać. ale
nadal musisz na tą trasmisję w vhdl-u program napisać

I tak bym musiał to zrobić. Co jest swoją drogą ciekawe, bo np. MachXO2
wspierają coś, co się nazywa gearbox. W wariancie maksymalnym powstają 4
zegary przesunięte o 45 stopni i logika dwuzboczowa na każdym z nich.
Przy odczycie pinu dostajesz nie bit, lecz 8 bitów wartości wejściowych,
każdy dla odpowiedniego slotu czasowego. Przy zapisie -- symetrycznie.
FPGA sobie działa na lichych 50MHz, a oversampling masz jakby chodziła
na 400MHz. Fantastyczna sprawa.

> Może to wynika z tego że trudno zrobić wszystkie 'ukłądanki' zkilku
klocków, zawsze czegoś brakuje, a na procku zrobisz prawie wszystko
dokładając jeden czy dwa klocki.

W większości robię już na FPGA, procki mnie drażnią. *Zawsze* coś jest
skopane albo nie pasuje do reszty. Jak się pojawi potrzeba reagowania w
rozsądnym czasie na zdarzenia równoległe, to się w ogóle robi bida.

Zdziwiło mnie trochę, że procesor z pamięcią, będący zasadniczo dawcą
tej pamięci, jest znacznie tańszy od samej pamięci. A jak już jest, to i
inne proste rzeczy opędzi i wyśle FPGA wysokoprzetworzony raport po tym
samym SPI, którym ją zaprogramował.

Pozdrawiam, Piotr

do góry

On 25/04/2021 21:53, Piotr Wyderski wrote:
> B-LVDS (jako następca dla RS-485 half duplex, niech spoczywa w pokoju) z
> prędkością 100-200Mbps. Taka prędkość oznacza FPGA, żaden procesor sobie
> nie poradzi.

Hmmm a jaka jest przewaga takiej magistrali skoro:

1) LAN 100Mbit to raczej rzecz spotykana w wielu ARMach i raczej sobie
radzą.

2) Po co komu czytać z predkoscią 100Mbit czujnik temperatury z lagiem
20sek, jak to zwykle jest w modbudbusowym dziadostwie. Serio jest jakies
zastosowanie dla takich prędkości w miejscu starego modbusa ;)? Już
widzę jak w pocie czoła firmy dorabiają na kolanie dodatkową płytkę z
iface 100Mbit do jakiegoś projektu z przed 30 lat na 8051 "bo okres
przejściowy a klient chce".

do góry

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:s64hb0$2nali$...@p...wsisiz.edu.pl.
..
>Taka ciekawostka mi się ostatnio pojawiła: grupa urządzeń będzie sie
>komunikowała przez kilkudziesięciometrową linię za pomocą M-LVDS lub
>B-LVDS (jako następca dla RS-485 half duplex, niech spoczywa w
>pokoju) z prędkością 100-200Mbps. Taka prędkość oznacza FPGA, żaden
>procesor sobie nie poradzi.

Chyba, ze ma wbudowane interfejsy.

Nie ma jakis gotowych?
To ciekawe co klienci powiedza na jakis "proprietary protocol".

> To nawet fajnie, projekt będzie ciekawszy. Tylko trzeba to FPGA
> czymś skonfigurować. Wymagania trwałościowe jak to zwykle u mnie,
> flash nie jest nawet rozważany,

W praktyce nie jest chyba taki zly, przynajmniej na 10 lat :-)

A procesora tam nie masz? Bo gdzies program trzeba trzymac.

>więc zostaje FRAM, MRAM lub starodawny układ FPGA antifuse. Potrzeba
>nieco mniej niż megabit, więc patrzę na ceny:

[...]
> Tylko są takie ciekawe procesory TI z pamięcią FRAM zamiast flash;
> dla kostki 128kB:

>https://pl.mouser.com/ProductDetail/Texas-Instrumen
ts/MSP430FR5962IRGZR?qs=6BVwEky2YVxmw%2FnfZ4%252BK2Q
%3D%3D

>cena wychodzi 16.28zł i niewiele więcej dla wersji 256kB (2Mbit).
>Oszczędzając więc 10 złotych dostaję jeszcze całkiem przyjemny
>procesor m.in. z ADC, którego FPGA nie ma. To żaden problem zmieścić
>wszystko w FPGA, ale skoro mogę w procesor wrzucić obsługę większości
>"bzdur", to warto -- w C pisze się znacznie szybciej niż w VHDL.

Ale szybka komunikacje Ci to rozwiaze, czy jeszcze jakies FPGA tez
bedzie trzeba ?

>Obudowy VQFN48 i SO8 są wymiarowo podobne, a skoro i tak muszę mieć
>na płytce takiego czy innego scalaka, to co mi za różnica, co w nim
>siedzi... Ciekawe czasy. Tyle się pisze o rewolucji SoC, a w praktyce
>ciagle lepiej wychodzi ulepić to sobie z osobnych elementów.

Ale czy to nie jest ciagle to samo co dawniej - mieszanie technologii
(krzemowej) niemile widziane jest ?

J.

do góry

heby wrote:

> 1) LAN 100Mbit to raczej rzecz spotykana w wielu ARMach i raczej sobie
> radzą.

1. W ARM masz zazwyczaj tylko MAC, musisz dodać PHY. LVDS wystaje wprost
z FPGA i wystarczy dodać 3 oporniki dopasowujące impedancję.

2. Chodzi o sieć multidrop do przesyłania danych w czasie rzeczywistym.
Ethernet nie ma takich gwarancji. Na wspólnym drucie węzły będą
próbowały wysyłać swoje dane w losowych odstępach i przy większej ich
liczbie pasmo zostanie zjedzone przez rozwiązywanie kolizji. Multimaster
to błąd w matriksie, USB czy modbus mają to rozwiązane znacznie sensowniej.

3. ARM z ethernetem odpowie masterowi jak mu sie zachce, FPGA od razu.
Albo dostanę po kilku mikrosekundach reakcję węzła, albo nie i
zatrzymujemy system awaryjnie.

> 2) Po co komu czytać z predkoscią 100Mbit czujnik temperatury z lagiem
> 20sek, jak to zwykle jest w modbudbusowym dziadostwie. Serio jest jakies
> zastosowanie dla takich prędkości w miejscu starego modbusa ;)?

Mam strumień ok. 3Mbps real-time z każdego węzła.

Pozdrawiam, Piotr

do góry

J.F. wrote:

> Chyba, ze ma wbudowane interfejsy.

Tylko dwie firmy na świecie produkują procesory z trwałą pamięcią
programu. Jedna z nich robi 8051, więc nawet nie czytam dalej, a druga
nie ma interfejsów szybszych niż 5Mbps.

> Nie ma jakis gotowych?

Nic mi o tym nie wiadomo. W MCU nawet megabitowy CAN to ciągle pewien
luksus. To jeden z głownych powodów, dla których sobie dałem spokój z
procesorami, szkoda życia. Mam np. ADC taktowany ~50MHz, mały procesor
by nawet nie potrafił tego zassać, a co dopiero przetworzyć. A dla FPGA
za 20 złotych to drobiazg. Zobacz sobie choćby iCE40UP05 -- tanie
niskoenergetyczne maleństwo, a ma 8 jednostek MAC, 30 małych RAMów i 4
duże. Chodzi mi po głowie zrobienie na tym w ramach zabawy demodulatora
koherentnego do DCF77 -- przecież to będzie liczyło Fourierem korelacje
wzajemne jak szatan! A mówimy o kostce 7x7mm, a nie o płycie z DSP.

> To ciekawe co klienci powiedza na jakis "proprietary protocol".

Nic, bo nie sa przewidziani na tym etapie. Będą rozmawiali z busmasterem.

> A procesora tam nie masz? Bo gdzies program trzeba trzymac.

Nie chciałem mieć, tj. nie było takiej potrzeby. FPGA potrafi sama
zassać konfigurację po SPI. Ale skoro długowieczny ROM na SPI jest
znacznie droższy od procesora z takim ROMem, a dodatkowy układ na płytce
dalej jest jeden, sztuka jest sztuka, to będę procesor miał.

> Ale szybka komunikacje Ci to rozwiaze, czy jeszcze jakies FPGA tez
> bedzie trzeba ?

Małe FPGA kosztuje tyle, co procesor, więc zamiast procesora wolę na
płytkę dać FPGA i się nie zastanawiać, czy da radę i czy errata bloku
komunikacyjnego obejmuje mój przypadek użycia. Więc to FPGA jest
obywatelem pierwszej kategorii. Procesor ma ją zaprogramować i nie
przeszkadzać. No, skoro już jest, to coś tam ostatecznie dostanie do
roboty z listy zadań FPGA, ale generalnie jest zbędny. Wygrał ceną.

> Ale czy to nie jest ciagle to samo co dawniej - mieszanie technologii
> (krzemowej) niemile widziane jest ?

Jakoś TI daje radę. I gdyby chip MRAM/FRAM kosztował taniej od tego
procka, to wątku by w ogóle nie było. Mnie naprawdę jest wszystko jedno,
czy FPGA się skonfiguruje jako SPI master czy SPI slave, umie i tak i tak.

Pozdrawiam, Piotr

do góry

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:s64sk3$2nqpq$...@p...wsisiz.edu.pl.
..
J.F. wrote:
>> Chyba, ze ma wbudowane interfejsy.

>Tylko dwie firmy na świecie produkują procesory z trwałą pamięcią
>programu. Jedna z nich robi 8051, więc nawet nie czytam dalej, a
>druga nie ma interfejsów szybszych niż 5Mbps.

Ale tego wymagania nie pisales.

Tylko ... skoro nie robia, to widac nikomu niepotrzebne :-P

>> Nie ma jakis gotowych?

>Nic mi o tym nie wiadomo. W MCU nawet megabitowy CAN to ciągle pewien
>luksus.

CAN to teraz w samochodach - nie powinno brakowac.

>To jeden z głownych powodów, dla których sobie dałem spokój z
>procesorami, szkoda życia. Mam np. ADC taktowany ~50MHz, mały
>procesor by nawet nie potrafił tego zassać, a co dopiero przetworzyć.
>A dla FPGA za 20 złotych to drobiazg. Zobacz sobie choćby
>iCE40UP05 -- tanie niskoenergetyczne maleństwo, a ma 8 jednostek MAC,
>30 małych RAMów i 4 duże. Chodzi mi po głowie zrobienie na tym w
>ramach zabawy demodulatora koherentnego do DCF77 -- przecież to
>będzie liczyło Fourierem korelacje wzajemne jak szatan! A mówimy o
>kostce 7x7mm, a nie o płycie z DSP.

IMO - i tak bedziesz jakiegos procka potrzebowal ... bo nawet jak
zdekodujesz w FPGA, to po co Ci ten sygnal?
No chyba, ze zegarek robisz ... a to ASIC :-)

Tzn zebysmy sie zrozumieli - nie namawiam do wciskania do procka
wszystkiego,
szczegolnie jesli zadanie pasuje do FPGA, a w procku bedzie za wolno.

>> A procesora tam nie masz? Bo gdzies program trzeba trzymac.

>Nie chciałem mieć, tj. nie było takiej potrzeby. FPGA potrafi sama
>zassać konfigurację po SPI. Ale skoro długowieczny ROM na SPI jest
>znacznie droższy od procesora z takim ROMem, a dodatkowy układ na
>płytce dalej jest jeden, sztuka jest sztuka, to będę procesor miał.

A, taki rachunek.

>> Ale szybka komunikacje Ci to rozwiaze, czy jeszcze jakies FPGA tez
>> bedzie trzeba ?

>Małe FPGA kosztuje tyle, co procesor, więc zamiast procesora wolę na
>płytkę dać FPGA i się nie zastanawiać, czy da radę i czy errata bloku
>komunikacyjnego obejmuje mój przypadek użycia. Więc to FPGA jest
>obywatelem pierwszej kategorii. Procesor ma ją zaprogramować i nie
>przeszkadzać. No, skoro już jest, to coś tam ostatecznie dostanie do
>roboty z listy zadań FPGA, ale generalnie jest zbędny. Wygrał ceną.

Moze nie tylko u Ciebie - masowa produkcja, to i niska cena :-)

>> Ale czy to nie jest ciagle to samo co dawniej - mieszanie
>> technologii (krzemowej) niemile widziane jest ?

>Jakoś TI daje radę. I gdyby chip MRAM/FRAM kosztował taniej od tego
>procka, to wątku by w ogóle nie było. Mnie naprawdę jest wszystko
>jedno, czy FPGA się skonfiguruje jako SPI master czy SPI slave, umie
>i tak i tak.

Tylko czy bys procka nie potrzebowal i tak ?
Bo IMO - czesc zadan lepiej pasuje do FPGA, czesc do procka.
Najlepiej miec oba :-)

J.

do góry

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:s64qb2$2nmuq$...@p...wsisiz.edu.pl.
..
heby wrote:
>> 1) LAN 100Mbit to raczej rzecz spotykana w wielu ARMach i raczej
>> sobie radzą.

>1. W ARM masz zazwyczaj tylko MAC, musisz dodać PHY. LVDS wystaje
>wprost z FPGA i wystarczy dodać 3 oporniki dopasowujące impedancję.

ale ryzyko, ze przepiecie spali wszystko.

>2. Chodzi o sieć multidrop do przesyłania danych w czasie
>rzeczywistym. Ethernet nie ma takich gwarancji. Na wspólnym drucie
>węzły będą próbowały wysyłać swoje dane w losowych odstępach i przy
>większej ich liczbie pasmo zostanie zjedzone przez rozwiązywanie
>kolizji. Multimaster to błąd w matriksie, USB czy modbus mają to
>rozwiązane znacznie sensowniej.

Ale przeciez switcha bedziesz mial, nie bedzie zadnych kolizji.

>3. ARM z ethernetem odpowie masterowi jak mu sie zachce, FPGA od
>razu.
>Albo dostanę po kilku mikrosekundach reakcję węzła, albo nie i
>zatrzymujemy system awaryjnie.

Cos w tym moze i jest, ale przeciez i ARM moze szybko reagowac na
pakiety ...

>> 2) Po co komu czytać z predkoscią 100Mbit czujnik temperatury z
>> lagiem 20sek, jak to zwykle jest w modbudbusowym dziadostwie. Serio
>> jest jakies zastosowanie dla takich prędkości w miejscu starego
>> modbusa ;)?

>Mam strumień ok. 3Mbps real-time z każdego węzła.

A coz to za cudo ?
No ale skoro tak, to pewnie potrzebujesz FPGA.

J.

do góry

On Mon, 26 Apr 2021 01:32:14 +0200, "J.F."
<j...@p...onet.pl> wrote:
> ale ryzyko, ze przepiecie spali wszystko.

Hyhy, ale wiesz nie użyje flash "bo to nie trwałe"....

--
Marek

do góry