"Maciej Sobczak" <s...@g...com> wrote in message
news:40365df0-3d24-4b83-a0fd-a6540604b6b9@googlegrou
ps.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.