Uwaga: *celowo* nie zadaję tego pytania na grupie typowo elektronicznej, bo zakładam
wysoką podatność tego pytania na wzniecenie flejma. Zakładam natomiast, że na tej
grupie jest co najmniej kilka osób, które są programistami, ale temat FPGA rozpoznały
i mają na ten temat wyrobioną przez praktykę opinię.

Pytanie: jeżeli potraktujemy FPGA jako alternatywę[*] dla mikrokontrolerów w
podobnych zastosowaniach, to w jakim kierunku polecilibyście eksplorację dla kogoś,
kto potrafi ogarnąć się z mikrokontrolerem? Docelowo chodzi o zastosowania w
przetwarzaniu danych (przykład: firewall lub jakiś inny tool sieciowy) lub sygnałów
(przykład: przetwarzanie dźwięku).

Luźne założenia:

- raczej VHDL niż Verilog
- narzędzia raczej open-source niż zamknięte

Na standardowych sklepach znalazłem dwie fajne płytki:

https://kamami.pl/zestawy-uruchomieniowe/179815-tera
sic-de0-nano-zestaw-startowy-z-ukladem-fpga-z-rodzin
y-cyclone-iv-firmy-altera.html

https://kamami.pl/zestawy-uruchomieniowe/560134-arti
x-7-35t-arty-zestaw-ewaluacyjny-dla-fpga-artix-7.htm
l?search_query=fpga&results=271

Jedna jest z układem Altery, druga Xilinx. Ta druga jest dla mnie o tyle ciekawa, że
ma złącze Ethernet, kompatybilność ze złączami Arduino też pobudza wyobraźnię.

Pytanie: yes, no, cancel? :-)

Coś w tym temacie warto szczególnie albo czegoś szczególnie nie warto? Literatura
szczególnie warta polecenia? Itd.

[*] Pisząc "alternatywa" mam świadomość płynności granicy oraz istnienia np. opcji
połączenia tych dwóch rozwiązań w jednym układzie. Chodzi o alternatywne metody pracy
z punktu widzenia programisty a nie o rozważania co jest jednoznacznie lepsze.

Dziękuję za wskazówki,

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 2016-02-13 00:15, Maciej Sobczak wrote:
> Pytanie: jeżeli potraktujemy FPGA jako alternatywę[*] dla mikrokontrolerów w
podobnych zastosowaniach
>, to w jakim kierunku polecilibyście eksplorację dla kogoś

Sugeruje kierunek hybrydowy. To znaczy normalny CPU + FPGA. Głównie
dlatego że pozwala to na szybki start programiście.

Z grubsza masz 3 rozwiązania:

1) Zynq. Sprowadza się to do jednego kawałka krzemu z CPU ARM i FPGA.
Dzieki kilku sztuczkom komunikacja CPU <> logika jest znaczenie szybsza
niż w osobnych kostkach. Ceny wyssane z brudnego palca maketoida więc
sie nie przestrzasz.

2) CPU + FPGA na osobnych płytkach. Czasem ma to ciekawe własności, np.
mozna przekonfigurowac FPGA z CPU. Wadą jest powolność komunikacji, ale
bywa że to nie wada.

3) Rdzeń popularnego uC zaimplementowany w FPGA. Niestety wymaga dość
drogich i duzych FPGA, a np. implementacja ARM potyka się o patenty. Są
darmowe core CPU, ale to nie arm ale np. MIPS albo SPARC. Duzo
rękodzieła, chyba że weźmiesz gotowiec (Nios, MicroBlaze).

>, kto potrafi ogarnąć się z mikrokontrolerem?

Hybryda pozwoli na latwiejsze wejście w świat fpga.

> Luźne założenia:
> - raczej VHDL niż Verilog

Niestety VHDl jest w odwrocie z uwagi na zdumiewające tempo rozwoju
narzedzi do testowania w verilogu w ostatnich latach.

> - narzędzia raczej open-source niż zamknięte

Świat EDA składa się w 99% z komercyjnych, absurdalnie drogich,
popsutych i czerpiących całymi garściami z lat 60-tych narzędzi. W
dodatku zajmujących kikadziesiąt GB. Na porządku dziennym jest
szyfrowanie modeli, brak wymiany danych między środowiskami, brak wersji
darmowych (a jak są to są poobcinane). Chory sen pijanego marketoida. Sorry.

> Na standardowych sklepach znalazłem dwie fajne płytki:
> https://kamami.pl/zestawy-uruchomieniowe/179815-tera
sic-de0-nano-zestaw-startowy-z-ukladem-fpga-z-rodzin
y-cyclone-iv-firmy-altera.html
> https://kamami.pl/zestawy-uruchomieniowe/560134-arti
x-7-35t-arty-zestaw-ewaluacyjny-dla-fpga-artix-7.htm
l?search_query=fpga&results=271
> Jedna jest z układem Altery, druga Xilinx. Ta druga jest dla mnie o tyle ciekawa,
że ma złącze Ethernet, kompatybilność ze złączami Arduino też pobudza wyobraźnię.
> Pytanie: yes, no, cancel? :-)

Szukaj Zynq jeśli pieniądze to nie problem.

do góry

On 2016-02-13 10:15, Sebastian Biały wrote:
> Szukaj Zynq jeśli pieniądze to nie problem.

Tu jest jedna z popularniejszych:

http://store.digilentinc.com/zybo-zynq-7000-arm-fpga
-soc-trainer-board/

A tu kilka:

http://zedboard.org/

Świetny przykład jak 50zł (fpga) + 50zł (arm) = 300zł w świecie eda :)

do góry

> Sugeruje kierunek hybrydowy. To znaczy normalny CPU + FPGA. Głównie
> dlatego że pozwala to na szybki start programiście.

To pozwala na połączenie metod sekwencyjnych z równoległymi i tu bym widział główną
zaletę. Przy czym jako CPU rozumiem uC.

> Z grubsza masz 3 rozwiązania:
>
> 1) Zynq. Sprowadza się to do jednego kawałka krzemu z CPU ARM i FPGA.

Tak. Ciekawe.

> 2) CPU + FPGA na osobnych płytkach.

Tak. Albo na tej samej płytce. Przecież nikt mi nie zabroni wlutowania dwóch układów
(uC i FPGA) obok siebie - co pewnie ułatwiłoby też zrobienie równoległej "magistrali"
do szybszej komunikacji pomiędzy nimi.

> Czasem ma to ciekawe własności, np.
> mozna przekonfigurowac FPGA z CPU.

Tak. Mam pewne urządzenie, w którym można zrobić przyjemny dla użytkownika update i
przypuszczam że właśnie tak to się odbywa.

> 3) Rdzeń popularnego uC zaimplementowany w FPGA.

Jestem tego świadomy, ale nie o to mi chodzi.

> > Luźne założenia:
> > - raczej VHDL niż Verilog
>
> Niestety VHDl jest w odwrocie

Czyli co - coraz gorszy jest? :-)

> z uwagi na zdumiewające tempo rozwoju
> narzedzi do testowania w verilogu w ostatnich latach.

Rozumiem, ale nie przeszkadza mi to. Interesuje mnie minimalizacja ilości użytych
narzędzi, więc to, że wokół Veriloga ich przybywa, nie jest dla mnie argumentem
przeciwko VHDL. :-)

Wyobrażam to sobie tak, że podobnie jak w przypadku uC, proces wymaga nominalnie
dwóch narzędzi: a) translatora, który przerobi źródło w VHDLu na coś, co można b)
wgrać do układu. Tak to działa w przypadku popularnych uC.

> > - narzędzia raczej open-source niż zamknięte
>
> Świat EDA składa się w 99% z komercyjnych, absurdalnie drogich,
> popsutych i czerpiących całymi garściami z lat 60-tych narzędzi.

Szkoda. Więc upraszczamy pytanie: czy jeśli zminimalizujemy zestaw narzędzi do tych
dwóch wymienionych powyżej (czyli translator + upload), to zmieścimy się w
open-source, czy nie da rady? To jest dość poważny argument przy porównaniach z uC. I
nie chodzi o samą cenę nabycia tych narzędzi, tylko o metodę ich rozwoju i filozofię
użycia.

> Szukaj Zynq jeśli pieniądze to nie problem.

Czy ten wybór ma wpływ na dalszy wybór narzędzi?

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 2016-02-13 23:51, Maciej Sobczak wrote:
>> 2) CPU + FPGA na osobnych płytkach.
> Tak. Albo na tej samej płytce.

Zapomnialem dopisać: krzemu. Oczywiście na jednym PCB.

>> Niestety VHDl jest w odwrocie
> Czyli co - coraz gorszy jest? :-)

Nie wiem czy gorszy. Z punktu widzenia tego gdzie siedzę verilog jest
kumulacją wszelkiego zła (z punktu widzenia teorii języków
programowania). I jednocześnie jest znacznie mniej verbose niż vhdl. W
dodatku verilog wymyslano na kolanie dzięki czemu ma fundamentalne bugi,
natomiast vhdl wymyslali matematycy (kradnąc adę :) dzięki czemu
szybciej zużywasz klawiaturę.

Tak czy inaczej verilog ma obecnie najlepiej zorganizowane testowanie
jednostkowe i kompleksowe i widać rozwoj. vhdl ma zaś ten sam problem co
C++: nowy feature? W przyszyłm dziesięcioleciu może...

>> z uwagi na zdumiewające tempo rozwoju
>> narzedzi do testowania w verilogu w ostatnich latach.
> Rozumiem, ale nie przeszkadza mi to.

Musi. Z tego powodu że popularnośc rdzeni w verilogu rośnie. To powoduje
że często nie masz wyboru innego jak verilog.

Co prawda większość mechanizmów syntezy i symualcji radzi sobie z mixed
language, ale to jest spory kłopot ponieważ te jezyki nie są wprost
kompatybilne na "poziomie drutów", mają inną filozofię i terzeba dobrze
wiedzieć co się robi.

> Interesuje mnie minimalizacja ilości użytych narzędzi

Zakladając że użyjesz tylko narzędzi do syntezy i symulacji i tak
zassasz 30GB szitu ktory zawieras wszystko co tylko dali radę upchnąć.

> Wyobrażam to sobie tak, że podobnie jak w przypadku uC
>, proces wymaga nominalnie dwóch narzędzi:
> a) translatora, który przerobi źródło w VHDLu na coś

Synteza. Z grubsza zmienia algorytmy na bramki i druty. Oczywiście nie
wszystkie konstrukcje sa syntezowalne. Niektóre syntezują się inaczej
niż byś chciał choćby dlatego że w FPGA nie ma algroytmiki. Z tego
powodu projekty hdlowe pisze się często 2 razy: raz behavioralnie a raz
na poziomie rtl. I tylko rtl jest syntezowalne i da się zaimplementować
w sprzęcie.

> , co można b) wgrać do układu.

Tu już prosciej, zazwyczaj w tym celu jest albo jtag albo jakaś pamięć
(albo symulator w postaci cpu).

>>> - narzędzia raczej open-source niż zamknięte
>> Świat EDA składa się w 99% z komercyjnych, absurdalnie drogich,
>> popsutych i czerpiących całymi garściami z lat 60-tych narzędzi.
> Szkoda. Więc upraszczamy pytanie: czy jeśli zminimalizujemy zestaw narzędzi
> do tych dwóch wymienionych powyżej (czyli translator + upload)
>, to zmieścimy się w open-source

Nie. Z grubsza dlatego że architektura fpga jest zamknięta. To oznacza
że OS narzędzia syntezy nie tylko nie wiedzą jakie bloki funkcjonalne
generować ale nie wiedzą też jak stworzyć bitstream do wgrania do fpga.
To wie tylko narzędzie producenta danego chipa. Ostatnio obwieszczono
światu że jakiś darmowy syntezer dał rade wygenerować bitstream do CPLD
(ktorego już chyba nie ma na rynku). To świadczy o tym jak daleko w tyle
są programy OS.

>, czy nie da rady?

Nie da rady. Rynek EDA jest zupełnie inny niż rynek uC. Zachowanie
producentów jest raczej podobne do MicroChipa niż Atmela.

> I nie chodzi o samą cenę nabycia tych narzędzi, tylko o metodę ich rozwoju i
filozofię użycia.

Filozofia użycia sprawadza się do 2 elementów:

a) "a co to jest make"? Zaś po mojej odpowiedzi "ale my i tak zawsze
budujemy od zera bo jest pewniej".

b) "na h.. nam jakieś systemy kontroli wersji, mamy ftpa".

Nie przesadzam. Lata 60-te, zarowno w obsłudze narzedzi jak i w
mentalności userów i nic nie wskazuje na zmiany. Miałem kiedyś nadzieje
że to kwestia poczekania aż problem sam się rozwiąże bilogicznie, ale
nie... to tak nie zadziałało.

PS. Niedawno verilog wzbogacił się o obiektowość (potrzebną przy
testowaniu w symulatorach). To tak strasznie bolało programistów
hdlowych że rynek zapełnił się narzedziami ktore myślą i piszą kod tego
typu za nich.

>> Szukaj Zynq jeśli pieniądze to nie problem.
> Czy ten wybór ma wpływ na dalszy wybór narzędzi?

Wybór vendora FPGA oznacza przywiązanie się do jakiegoś narzędzia. Model
pamięci DDR będzie inny u jednego a inny u drugiego. Zawartość FPGA też
(np. układy mnożące, peryferia itd). Może pisać częsciowo abstrakcyjnie,
ale w HDLu nie wymyslono tego tak skutecznie jak w normalnych językach.
Tam masz druty i tyle, a abstrakce zapewnia się w taki sposób że się nią
nikt nie przejmuje.

Zerknij na OpenCores dla sportu. Przygotuj się na utratę szarych komórek
po zerknięciu w niektóre projekty. Tak, Ci sami ludzie piszą tworzą
elektronikę do respiratorów.

do góry

> Nie. Z grubsza dlatego że architektura fpga jest zamknięta.

OK. To mi bardzo dużo wyjaśnia. Faktycznie inaczej, niż przy uC (przyjmijmy
Cortex-M), gdzie każdy producent (albo nawet seria układów) ma inny rozkład
peryferiów w pamięci, ale przynajmniej mogę użyć tego samego kompilatora do programów
przeznaczonych na różne układy i jakoś się bronić stosując różne abstrakcje. To już
spore ułatwienie.
Szkoda, że rynek FPGA się tak nie uporządkował.

> Wybór vendora FPGA oznacza przywiązanie się do jakiegoś narzędzia.

Rozumiem. Stąd, jak przypuszczam, bardziej trwałe wybory - jak się jakaś firma
zdecyduje np. na Xilinksa, to do końca świata pałuje układy tylko na tym.

Z drugiej strony - skoro wybór vendora jest tak istotny, to może faktycznie warto od
razu wycelować w Zynq.

> Zerknij na OpenCores dla sportu. Przygotuj się na utratę szarych komórek
> po zerknięciu w niektóre projekty. Tak, Ci sami ludzie piszą tworzą
> elektronikę do respiratorów.

Kompletnie mnie to nie dziwi. Z innej perspektywy, ale dochodzę do wniosku, że branża
systemów krytycznych ma największy problem z jakością HR.
Dlatego nawet nie zamierzałem korzystać z tego, co ta branża produkuje (patrz
wspomniana minimalizacja ilości narzędzi), miałem nadzieję na samodzielną eksplorację
terenu. Muszę jednak przyznać, że bardzo starannie mnie do tego zniechęcasz. :-)

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 2016-02-14 16:54, Maciej Sobczak wrote:
>> Wybór vendora FPGA oznacza przywiązanie się do jakiegoś narzędzia.
> Rozumiem. Stąd, jak przypuszczam, bardziej trwałe wybory - jak
> się jakaś firma zdecyduje np. na Xilinksa, to do końca świata pałuje
układy tylko na tym.

Nie, nie przesadzajmy. Kod hdlowy jest przenośny. Problemy pojawiają się
kiedy chcesz korzystać ze specyficznych cech układów. W Twoim wypadku
(dodatkowy CPU) ma to znaczenie zarówno kiedy wsadzą dodatkowo arma na
krzem jak i gdy chcesz zrobić CPU w FPGA (nios/microblaze). Tam
przywiązanie do vendora jest bardzo bolesne.

> Z drugiej strony - skoro wybór vendora jest tak istotny
>, to może faktycznie warto od razu wycelować w Zynq.

Zynq jest wazny kiedy masz do czynienia z duzym strumieniem cpu<->fpga.
Masz? Jeśli nie to czesto rozsądnie jest wstawić arma za $5 i fpga jako
osobne kości.

Jakoś na procesory z niewielką programowalną logika nie mogę się
doczekać. Kilkaset makrocel bylo by wystarczające do zastapnienia
drogich fpga w wielu zastosowaniach. Zamiast tego dostaje absurdalnie
drogie Zynq i płot z patentów.

> Z innej perspektywy, ale dochodzę do wniosku, że branża
> systemów krytycznych ma największy problem z jakością HR.

Wbrew pozorom ostatnio w EDA testowanie kodu stało się celem ktory
decyduje o dopuszczeniu rozwiązań na rynek. Więc pojawiło się od groma
narzędzi, które błyskawicznie przerosły narzędzia stosowane w "zwykłym"
programowaniu pod względem zarządzania testami.

Problemem nie jest to czy kod jest przetestowany. Problemem jest to że z
uwagi na tradycje developerskie w EDA kod jest *dziadowski* i
przetestowany jednocześnie. Poprawia komfort psychiczny menagerów ale
programisci pracują w toskycznym środowisku.

> miałem nadzieję na samodzielną eksplorację terenu.

No więc istnieje cos takiego jak ghdl, icarus, wtyczki do eclipse itd.
Ale finalna syntezę/implementację wykonujesz w narzedziu vendora.

> Muszę jednak przyznać, że bardzo starannie mnie do tego zniechęcasz. :-)

Ponieważ strasznie się zawiodłem na EDA. Czego się nie dotkniesz jest
zawsze inaczej niż w normalnym programowaniu, od groma debilizmów
przekutych na "standardy przemyslowe", niezrozumiale zachowania
producentów, trzepanie kasy na bardzo kiespkim oprogramowaniu, zamknięte
prawie wszystko, innowacje przez więcej gigabajtów ikonek, impelemntacje
standardów przez "my wiemy lepiej" i *stada* ludzi mówiących Ci że
jesteś idiotą że tak to widzisz. Bo wszystko jest ok: zawsze tak było.

PS. Jesli chcesz się tylko pobawić to kup płytke z prostym fpga, olej
programowanie szeregowe tylko od razu na głeboką wodę.

do góry

W dniu sobota, 13 lutego 2016 00:15:02 UTC+1 użytkownik Maciej Sobczak napisał:
> Coś w tym temacie warto szczególnie albo czegoś szczególnie nie warto? Literatura
szczególnie warta polecenia? Itd.
Po prostu sciagnij sobie np. Quartusa ze strony Altery (o ile nie trafisz na przerwe
konserwacyjna,
oni raz w tygodniu wylaczaja serwery z downloadem, zeby, no nie wiem, wentylatory
naoliwic?)
i zobacz jak wyglada caly workflow. W samym srodowisku (bez fizycznego FPGA) mozesz
zrobic
wszystko poza dzialaniem ukladu na rzeczywistej kostce. Tam jeszcze wypada sciagnac
ModelSima
do symulacji dzialania (stare Quartusy mialy prosty symulator, ale zdecydowali sie
tego pozbyc
na korzysc podpinania zewnetrznego oprogramowania wprost z horroru) ukladow.

Jesli chodzi o alternatywne metody pracy to mozesz sobie oskryptowac w TCLu niektore
czynnosci.

Na studiach implementowalem mikroprocesor w FPGA, wolalbym o tym zapomniec;)

Pozdrawiam,
--
Karol Piotrowski

do góry

On Saturday, February 13, 2016 at 10:16:37 AM UTC+1, Sebastian Biały wrote:
> On 2016-02-13 00:15, Maciej Sobczak wrote:
> > Pytanie: jeżeli potraktujemy FPGA jako alternatywę[*] dla mikrokontrolerów w
podobnych zastosowaniach
> >, to w jakim kierunku polecilibyście eksplorację dla kogoś
>
> Sugeruje kierunek hybrydowy. To znaczy normalny CPU + FPGA. Głównie
> dlatego że pozwala to na szybki start programiście.

Co sądzisz o tym? (OpenCL na FPGA)
https://www.altera.com/products/design-software/embe
dded-software-developers/opencl/overview.html

w.

do góry

vhdl to moim zdaniem język stworzony przez ludzi chorych umysłowo...
próbowałem się z nim oswoić, ale nie dałem rady...

do góry