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.