Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #28309 > unrolled thread

FPGA z punktu widzenia programisty

Back to article view | Back to pl.comp.programming

Contents

  FPGA z punktu widzenia programisty Maciej Sobczak <see.my.homepage@gmail.com> - 2016-02-12 15:15 -0800
    Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-13 10:15 +0100
      Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-13 12:56 +0100
      Re: FPGA z punktu widzenia programisty Maciej Sobczak <see.my.homepage@gmail.com> - 2016-02-13 14:51 -0800
        Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-14 10:56 +0100
          Re: FPGA z punktu widzenia programisty Maciej Sobczak <see.my.homepage@gmail.com> - 2016-02-14 07:54 -0800
            Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-14 18:06 +0100
        Re: FPGA z punktu widzenia programisty "Pszemol" <Pszemol@PolBox.com> - 2016-02-27 06:56 -0600
          Re: FPGA z punktu widzenia programisty "M.M." <mmarszik@gmail.com> - 2016-02-27 06:59 -0800
            Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-27 18:33 +0100
              Re: FPGA z punktu widzenia programisty "M.M." <mmarszik@gmail.com> - 2016-02-27 12:04 -0800
                Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-27 21:29 +0100
                  Re: FPGA z punktu widzenia programisty "Pszemol" <Pszemol@PolBox.com> - 2016-02-27 16:10 -0600
                    Re: FPGA z punktu widzenia programisty RW <bloody_rabbit@gazeta.pl> - 2016-02-27 16:42 -0600
                      Re: FPGA z punktu widzenia programisty "Pszemol" <Pszemol@PolBox.com> - 2016-02-28 09:38 -0600
                        Re: FPGA z punktu widzenia programisty Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2016-02-28 15:45 +0000
          Re: FPGA z punktu widzenia programisty Maciej Sobczak <see.my.homepage@gmail.com> - 2016-02-29 00:37 -0800
            Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-29 19:43 +0100
              Re: FPGA z punktu widzenia programisty fir <profesor.fir@gmail.com> - 2016-03-06 01:49 -0800
      Re: FPGA z punktu widzenia programisty Wojciech Muła <wojtek.mula@gmail.com> - 2016-02-16 02:15 -0800
        Re: FPGA z punktu widzenia programisty Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2016-02-18 14:59 +0000
        Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-18 19:15 +0100
          Re: FPGA z punktu widzenia programisty "M.M." <mmarszik@gmail.com> - 2016-02-18 13:13 -0800
            Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-19 10:16 +0100
              Re: FPGA z punktu widzenia programisty "M.M." <mmarszik@gmail.com> - 2016-02-19 06:14 -0800
                Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-19 15:37 +0100
                  Re: FPGA z punktu widzenia programisty "M.M." <mmarszik@gmail.com> - 2016-02-19 07:34 -0800
                  Re: FPGA z punktu widzenia programisty Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2016-02-19 20:11 +0000
                    Re: FPGA z punktu widzenia programisty "M.M." <mmarszik@gmail.com> - 2016-02-19 14:06 -0800
                      Re: FPGA z punktu widzenia programisty Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2016-02-19 22:38 +0000
                      Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-20 12:18 +0100
                        Re: FPGA z punktu widzenia programisty "M.M." <mmarszik@gmail.com> - 2016-02-20 05:51 -0800
                          Re: FPGA z punktu widzenia programisty Sebastian Biały <heby@poczta.onet.pl> - 2016-02-20 15:13 +0100
                          Re: FPGA z punktu widzenia programisty Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2016-02-20 23:46 +0000
                            Re: FPGA z punktu widzenia programisty "M.M." <mmarszik@gmail.com> - 2016-02-22 02:30 -0800
                              Re: FPGA z punktu widzenia programisty Roman W <bloody_rabbitREMOVETHIS@gazeta.pl> - 2016-02-22 19:54 +0000
                                Re: FPGA z punktu widzenia programisty "M.M." <mmarszik@gmail.com> - 2016-02-22 14:30 -0800
                                  Re: FPGA z punktu widzenia programisty RW <bloody_rabbit@gazeta.pl> - 2016-02-27 15:24 -0600
    Re: FPGA z punktu widzenia programisty kropelka@gmail.com - 2016-02-15 09:04 -0800
    Re: FPGA z punktu widzenia programisty platformowe głupki <NOSPAMtestowanije@go2.pl> - 2016-02-17 18:50 +0100
      Re: FPGA z punktu widzenia programisty szemrany <szemrany@offline.off> - 2016-02-17 20:19 +0100
        Re: FPGA z punktu widzenia programisty platformowe głupki <NOSPAMtestowanije@go2.pl> - 2016-02-18 16:24 +0100
          Re: FPGA z punktu widzenia programisty platformowe głupki <NOSPAMtestowanije@go2.pl> - 2016-02-18 16:27 +0100
            Re: FPGA z punktu widzenia programisty "Pszemol" <Pszemol@PolBox.com> - 2016-02-27 06:37 -0600
              Re: FPGA z punktu widzenia programisty platformowe głupki <NOSPAMtestowanije@go2.pl> - 2016-02-28 15:38 +0100
                Re: FPGA z punktu widzenia programisty "Pszemol" <Pszemol@PolBox.com> - 2016-02-28 09:39 -0600
                  Re: FPGA z punktu widzenia programisty platformowe głupki <NOSPAMtestowanije@go2.pl> - 2016-03-02 17:59 +0100
                    Re: FPGA z punktu widzenia programisty "Pszemol" <Pszemol@PolBox.com> - 2016-03-05 07:52 -0600
                      Re: FPGA z punktu widzenia programisty platformowe głupki <NOSPAMtestowanije@go2.pl> - 2016-03-06 19:44 +0100
      Re: FPGA z punktu widzenia programisty "Pszemol" <Pszemol@PolBox.com> - 2016-02-27 06:41 -0600
        Re: FPGA z punktu widzenia programisty platformowe głupki <NOSPAMtestowanije@go2.pl> - 2016-02-28 15:40 +0100
          Re: FPGA z punktu widzenia programisty "Pszemol" <Pszemol@PolBox.com> - 2016-03-05 07:53 -0600

Page 1 of 3  [1] 2 3  Next page →

#28309 — FPGA z punktu widzenia programisty

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-terasic-de0-nano-zestaw-startowy-z-ukladem-fpga-z-rodziny-cyclone-iv-firmy-altera.html

https://kamami.pl/zestawy-uruchomieniowe/560134-artix-7-35t-arty-zestaw-ewaluacyjny-dla-fpga-artix-7.html?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

[toc] | [next] | [standalone]

#28311

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-terasic-de0-nano-zestaw-startowy-z-ukladem-fpga-z-rodziny-cyclone-iv-firmy-altera.html
> https://kamami.pl/zestawy-uruchomieniowe/560134-artix-7-35t-arty-zestaw-ewaluacyjny-dla-fpga-artix-7.html?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.

[toc] | [prev] | [next] | [standalone]

#28313

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 :)

[toc] | [prev] | [next] | [standalone]

#28314

> 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

[toc] | [prev] | [next] | [standalone]

#28315

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.

[toc] | [prev] | [next] | [standalone]

#28316

> 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

[toc] | [prev] | [next] | [standalone]

#28317

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

[toc] | [prev] | [next] | [standalone]

#28344

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:40365df0-3d24-4b83-a0fd-a6540604b6b9@googlegroups.com...
>> 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.

Proces wymaga mnóstwo dobrych narzędzi do analizy, symulacji, testowania.
Nie podchodz do FPGA jak do procesora wykonującego rozkazy z pamięci.
W FPGA budujesz nowy układ elektroniczny, ze wszystkimi tego konsekwencjami.

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

Jeśli w ogóle dokonujesz wyboru pomiędzy FPGA a uC na podstawie
dostępności narzędzi open source to moim zdaniem zabierasz się
do sprawy od dupy strony... Najpierw poznaj FPGA, dowiedz się co to,
jak się to je i czym się to je, zrób jakiś prosty przykład, zasymuluj,
przetestuj, zoptymalizuj na maksymalne MHz lub na minimalną ilość
LE a potem się zabieraj za filozofowanie w Twojej konkretnej aplikacji
co będzie dla Ciebie lepsze. 

[toc] | [prev] | [next] | [standalone]

#28345

On Saturday, February 27, 2016 at 1:57:07 PM UTC+1, Pszemol wrote:

> Jeśli w ogóle dokonujesz wyboru pomiędzy FPGA a uC na podstawie
> dostępności narzędzi open source to moim zdaniem zabierasz się
> do sprawy od dupy strony... Najpierw poznaj FPGA, dowiedz się co to,
> jak się to je i czym się to je, zrób jakiś prosty przykład, zasymuluj,
> przetestuj, zoptymalizuj na maksymalne MHz lub na minimalną ilość
> LE a potem się zabieraj za filozofowanie w Twojej konkretnej aplikacji
> co będzie dla Ciebie lepsze.

Czu FPGA nadają się do sieci neuronowych? W necie można znaleźć 
informacje że uzyskuje się na FPGA przyspieszenie od 4 do 100
razy, a to spora różnica, bo dla 4 razy to na pewno nie warto
się bić. Sieci neuronowe to głównie mnożenie macierzy, często
są to małe macierze i rzadkie, rozmiar np. 10^4 floatów w tym
99.5% zer. 

Czy np. taki algorytm da się na FPGA zoptymalizować?

float x = 0;
for( i=0 ; i<50 ; i++ )
  x += v1[ non_zero[i] ] * v2[ non_zero[i] ];
return x;


Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28346

On 2016-02-27 15:59, M.M. wrote:
> Czy np. taki algorytm da się na FPGA zoptymalizować?
> float x = 0;
> for( i=0 ; i<50 ; i++ )
>    x += v1[ non_zero[i] ] * v2[ non_zero[i] ];
> return x;

a) kilkaset wielobitowych multiplekserów
b) 50 jednostek mnożących
c) 1 *dupny* sumator równoległy

Więc da się, ale ta odpowieź jest i tak bezużyteczna bo nie wiadomo co 
dalej z x i czy na pewno znajdziesz fpga o takich parametrach. Dlatego 
bywa że FPGA robi jednak obliczenioa w sposob mieszany: 
równoległo-szegerowy.

[toc] | [prev] | [next] | [standalone]

#28347

On Saturday, February 27, 2016 at 6:34:40 PM UTC+1, Sebastian Biały wrote:
> On 2016-02-27 15:59, M.M. wrote:
> > Czy np. taki algorytm da się na FPGA zoptymalizować?
> > float x = 0;
> > for( i=0 ; i<50 ; i++ )
> >    x += v1[ non_zero[i] ] * v2[ non_zero[i] ];
> > return x;
> 
> a) kilkaset wielobitowych multiplekserów
> b) 50 jednostek mnożących
> c) 1 *dupny* sumator równoległy
> 
> Więc da się, ale ta odpowieź jest i tak bezużyteczna bo nie wiadomo co 
> dalej z x i czy na pewno znajdziesz fpga o takich parametrach. Dlatego 
> bywa że FPGA robi jednak obliczenioa w sposob mieszany: 
> równoległo-szegerowy.

Ok, dzięki za odpowiedź. Mogłem się domyślać, że przyspieszenie zależy od
wielu czynników i bez testów na konkretnym sprzęcie i konkretnej 
implementacji, niewiele da się powiedzieć. A może zapytam jeszcze inaczej: w
jakich zadaniach uzyskuje się największe przyspieszenie i jakie to są
różnice względem wielordzeniowego CPU albo GPU? Uzyskuje się czasami 
przyspieszenia rzędu 1tys - 10tys razy?

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#28348

On 2016-02-27 21:04, M.M. wrote:
> Ok, dzięki za odpowiedź. Mogłem się domyślać, że przyspieszenie zależy od
> wielu czynników i bez testów na konkretnym sprzęcie i konkretnej
> implementacji, niewiele da się powiedzieć. A może zapytam jeszcze inaczej: w
> jakich zadaniach uzyskuje się największe przyspieszenie

W zadaniach wykazujących silną równoległość w milionach prostych zagadnień.

> i jakie to są
> różnice względem wielordzeniowego CPU albo GPU?

Nie da się na to odpowiedzieć. Pewne zadania są aobsolutnie niemozliwe 
do realizacji na CPU/GPU ze względu na przykład na czas odpowiedzi - nie 
tyle szybko co pewnie. Jeśli sterujesz silnikiem obrabiarki to nie 
niestistotne jak szybkiego peceta wsadzisz - zawsze system operacyjny 
uzna że warto wyłączyć wszystkie taski i zająć się katalogowaniem 
pornoli zamiast odczytem stanu krańcówki. FPGA stosujesz tam gdzie masz 
od groma prostych operacji. Najprostszym przykładem jest analiza obrazu 
per pixel. Miliony pixeli - miliony równoległych wątków o prostych 
zadaniach.

> Uzyskuje się czasami
> przyspieszenia rzędu 1tys - 10tys razy?

Wstaw dowolną liczbę i pewno się takie porównanie trafi.

Zamiast dopytywać - weź sobie jakąś płytke ewaluacyjną z xilinxem albo 
alterą (DE1 np). Znajdziesz duzo przykładow. Poczujesz. Dyskutowanie o 
tym czy kangur jest lepszy od autobusu jest nie na miejscu.

[toc] | [prev] | [next] | [standalone]

#28350

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message 
news:nat121$6au$1@node2.news.atman.pl...
> Zamiast dopytywać - weź sobie jakąś płytke ewaluacyjną z xilinxem albo 
> alterą (DE1 np). Znajdziesz duzo przykładow. Poczujesz. Dyskutowanie o tym 
> czy kangur jest lepszy od autobusu jest nie na miejscu.

Też mam takie wrażenie że koledzy domyślają się, że FPGA
"to taki CPU tylko szybszy" i pytają ile razy szybszy...
Tymczasem FPGA to zupełnie inny zwierzaczek i cieżko porównać. 

[toc] | [prev] | [next] | [standalone]

#28351

On Sat, 27 Feb 2016 16:10:29 -0600, Pszemol wrote:

> "Sebastian Biały" <heby@poczta.onet.pl> wrote in message
> news:nat121$6au$1@node2.news.atman.pl...
>> Zamiast dopytywać - weź sobie jakąś płytke ewaluacyjną z xilinxem albo
>> alterą (DE1 np). Znajdziesz duzo przykładow. Poczujesz. Dyskutowanie o
>> tym czy kangur jest lepszy od autobusu jest nie na miejscu.
> 
> Też mam takie wrażenie że koledzy domyślają się, że FPGA "to taki CPU
> tylko szybszy" i pytają ile razy szybszy... Tymczasem FPGA to zupełnie
> inny zwierzaczek i cieżko porównać.

FPGA nie ma problemow ktore sa zmora oprogramowania low-latency na PC, np. 
to ze kiedy komputer PC siedzi i czeka na sygnaly z zewnatrz, to kod ktory 
mialby na nie reagowac moze zostac wypchniety z cache CPU do pamieci.

RW

[toc] | [prev] | [next] | [standalone]

#28354

"RW" <bloody_rabbit@gazeta.pl> wrote in message 
news:Kc2dnZXFmo7Eu0_LnZ2dnUU78bHNnZ2d@brightview.co.uk...
> On Sat, 27 Feb 2016 16:10:29 -0600, Pszemol wrote:
>
>> "Sebastian Biały" <heby@poczta.onet.pl> wrote in message
>> news:nat121$6au$1@node2.news.atman.pl...
>>> Zamiast dopytywać - weź sobie jakąś płytke ewaluacyjną z xilinxem albo
>>> alterą (DE1 np). Znajdziesz duzo przykładow. Poczujesz. Dyskutowanie o
>>> tym czy kangur jest lepszy od autobusu jest nie na miejscu.
>>
>> Też mam takie wrażenie że koledzy domyślają się, że FPGA "to taki CPU
>> tylko szybszy" i pytają ile razy szybszy... Tymczasem FPGA to zupełnie
>> inny zwierzaczek i cieżko porównać.
>
> FPGA nie ma problemow ktore sa zmora oprogramowania low-latency na PC,
> np. to ze kiedy komputer PC siedzi i czeka na sygnaly z zewnatrz, to kod 
> ktory
> mialby na nie reagowac moze zostac wypchniety z cache CPU do pamieci.

No ale my tu chyba nie próbujemy zastąpić peceta używając FPGA
tylko komputer "embeded" który zbudowany jest na innych kontrolerach
i nie używa pecetowych technik jak wirtualnych dysków czy memory swappów.
Techniki embedded to też inny zwierzaczek niż świat pecetów z GB RAM i GHz. 

[toc] | [prev] | [next] | [standalone]

#28356

On Sun, 28 Feb 2016 09:38:17 -0600, "Pszemol" <Pszemol@PolBox.com> 
wrote:
> No ale my tu chyba nie próbujemy zastąpić peceta używając FPGA
> tylko komputer "embeded" który zbudowany jest na innych kontrolerach
> i nie używa pecetowych technik jak wirtualnych dysków czy memory 
swappów.

Niektórzy próbują.

RW

[toc] | [prev] | [next] | [standalone]

#28357

> Jeśli w ogóle dokonujesz wyboru pomiędzy FPGA a uC na podstawie
> dostępności narzędzi open source to moim zdaniem zabierasz się
> do sprawy od dupy strony...

Niekoniecznie. Z punktu widzenia zleceniodawcy wybór między uC i FPGA jest szczegółem implementacyjnym. Być może dla ściśle określonych wymagań ten wybór redukuje się do jednego, ale nadal jest to szczegół implementacyjny.

Z kolei z punktu widzenia zespołu ten wybór dokonuje się przy udziale czynników nietechnicznych (patrz też problem wyboru języka programowania do projektu), czyli kulturowych. Ja chcę wiedzieć, jak duża jest zbieżność kulturowa pomiędzy odpowiednimi procesami, bo od tego zależy, czy kogoś przekonam do robienia projektu w taki lub inny sposób. Wybór zależy też od ceny narzędzi, ich dostępności, oraz dostępności narzędzi w różnych kombinacjach.

> Najpierw poznaj FPGA, dowiedz się co to,
> jak się to je i czym się to je,

Po to jest ten wątek.

> zrób jakiś prosty przykład, zasymuluj,
> przetestuj,

Taki mam zamiar.

> a potem się zabieraj za filozofowanie

A potem klient mi powie, że wybiera tą tańszą opcję a koledzy z zespołu, że wybierają znane im narzędzia i sposoby pracy. Właśnie dlatego w tytule wątku napisałem "z punktu widzenia programisty" a nie "z punktu widzenia projektanta układów scalonych".

Inaczej mówiąc, pytanie brzmi: czy FPGA *rozszerza* warsztat programisty (nawet jeśli oznaczałoby to niewykorzystanie pełnego potencjału tej technologii).

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

[toc] | [prev] | [next] | [standalone]

#28358

On 2016-02-29 09:37, Maciej Sobczak wrote:
> Inaczej mówiąc, pytanie brzmi: czy FPGA *rozszerza* warsztat programisty

Zdecydowanie. Tylko że tak samo rozszerza erlang, clojure, opencl, 
haskel ale jakoś nie widać aby to wpływało na jakość oprogramowania 
światowego. Dalej tłucze się masowo dziadostwo. Jako przykład mogę podać 
niedaleką firmę która użyła bogatego FPGA tylko po to żeby do środka 
wsadzić jakiś mierny CPU (Z80 o ile pamiętam) i sterować prostym 
silnikiem i kilkoma krańcówkami. Dziadostwo jest wszechobecne a wielu 
FPGA zamiast coś poszerzać to wręcz przeciwnie, ogranicza horyzont.

> (nawet jeśli oznaczałoby to niewykorzystanie pełnego potencjału tej technologii).

Wykorzystanie pełnego potencjału FPGA jest bardzo trudne. Z wielu 
powodów, ale prawdę mówiąc największą przeszkodą w implementacji np. 
algorytmów DSP jest kłopot z dobyciu doświadczenia. Zazwyczaj 
implementuje się je zupełnie inaczej niż "ksiązkowo" gdzie wszystko 
opisano w jezykach szeregowych. Zdolni "programisci" hdl sa bardzo 
dobrze opłacaną i hermetyczną grupą, choć z tego co widzę niekoniecznie 
w PL.

Co ważne projekty OpenSource praktycznie nie istnieja. No dobra, 
istnieja jakies generatory VGA, implementacje prostych procesorów, 
filtry, koparki bitcoinów itp duperele, ale żeby znaleźc np. głupi 
enkoder mpeg to już problem. OS jest w kiepskim stanie.

[toc] | [prev] | [next] | [standalone]

#28362

W dniu poniedziałek, 29 lutego 2016 19:45:14 UTC+1 użytkownik Sebastian Biały napisał:
> On 2016-02-29 09:37, Maciej Sobczak wrote:
> > Inaczej mówiąc, pytanie brzmi: czy FPGA *rozszerza* warsztat programisty
> 
> Zdecydowanie. Tylko że tak samo rozszerza erlang, clojure, opencl, 
> haskel ale jakoś nie widać aby to wpływało na jakość oprogramowania 
> światowego. 

moim zdaniem opencl sie jednak przyjmie (bo to dosyc dobry pomysl,
chyba ze okaze sie ze znajdzie sie cos innego co lepiej dziala, ale
o tym przynajmniej poki co nic nie wiem) - niekrore rozwiazania
przyjmuja sie dosyc wolno bo ludzie sie wolno ucza, tak ze przykladowo moze minac takie z 15 lat 'opoznienia' nim niektore rzeczy sie upowszechnią - przynajmniej na to mi wyglada; to faktycznie sa zjawiska kulturowe ale programowanie to wogole stety czy niestety w ogromnej mierze 'zjawisko kulturowe' 



>Dalej tłucze się masowo dziadostwo. Jako przykład mogę podać 
> niedaleką firmę która użyła bogatego FPGA tylko po to żeby do środka 
> wsadzić jakiś mierny CPU (Z80 o ile pamiętam) i sterować prostym 
> silnikiem i kilkoma krańcówkami. Dziadostwo jest wszechobecne a wielu 
> FPGA zamiast coś poszerzać to wręcz przeciwnie, ogranicza horyzont.
> 
> > (nawet jeśli oznaczałoby to niewykorzystanie pełnego potencjału tej technologii).
> 
> Wykorzystanie pełnego potencjału FPGA jest bardzo trudne. Z wielu 
> powodów, ale prawdę mówiąc największą przeszkodą w implementacji np. 
> algorytmów DSP jest kłopot z dobyciu doświadczenia. Zazwyczaj 
> implementuje się je zupełnie inaczej niż "ksiązkowo" gdzie wszystko 
> opisano w jezykach szeregowych. Zdolni "programisci" hdl sa bardzo 
> dobrze opłacaną i hermetyczną grupą, choć z tego co widzę niekoniecznie 
> w PL.
> 
> Co ważne projekty OpenSource praktycznie nie istnieja. No dobra, 
> istnieja jakies generatory VGA, implementacje prostych procesorów, 
> filtry, koparki bitcoinów itp duperele, ale żeby znaleźc np. głupi 
> enkoder mpeg to już problem. OS jest w kiepskim stanie.

[toc] | [prev] | [next] | [standalone]

#28319

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/embedded-software-developers/opencl/overview.html

w.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | pl.comp.programming

csiph-web