heby wrote:

> Wszystko zależy od zastosowań. Nie wiem co tam liczysz. Ale jeśli się
> komunikujesz, to jednak stawiam, że przetwarzasz *coś* szeregowo, a FPGA
> za małe aby implementować cpu w środku, więc będzie straszliwa orka albo
> bardzo trywialne zagadnienie z gatunku forward.

Nawet do tej najmniejszej wejdzie soft CPU i zostanie jeszcze połowa
zasobów, co jest swoją drogą zadziwiające. I tak miało być początkowo,
tylko potem okazało się, że procesor z pamięcią jest znacznie tańszy niż
sama pamięć, więc nie będzie soft core. Zepchnie się MCU z FPGA jakimś
SPI, rzeczy ciekawe zrobi w FPGA, pierdoły w MCU i będzie elegancko.
To uwalnia też dużo zasobów w FPGA do zastosowań czysto komunikacyjnych
-- 1200 da radę z palcem w nosie, 640 potencjalnie też. Problem z 640 to
nie za mało bramek, tylko brak wielofazowego PLL, więc potrafi
obsługiwać piny IO tylko z podwójną częstotliwością zegara. 1200 z
ośmiokrotną, co się bardzo przydaje przy odbiorze szybkiego strumienia.

> A jak zabranie zasobów?

Przecież to jest stosunkowo małe, znacznie mniejsze niż soft CPU. Wiele
klocków jest gotowych, m.in. SERDES z oversamplingiem. Jest wytrawiony
na krzemie przy pinach w dolnym banku, więc jego użycie to koszt zero --
pin i tak by musiał jakiś być. FPGA musi tylko zadecydować, czy widzi 0,
czy 1 i wysłać do dekodera a potem do FIFO. Nadawanie to jest w ogóle
banał, bo to nadajnik formuje impulsy i nie musi zgadywać, czy widzi 0,
1, czy jakś glitch na drucie. To on mówi, co jest na drucie. Mam
wrażenie, że dla Ciebie FPGA to zbiór LUTów i RAMów, a tam jest jeszcze
masa innych ciekawych bloczków.

> Ogólnie ^C^V w przypadku HDL czasami sie nie sprawdza tak jak się
> wydaje. Niech Ci zabraknie 1 LUTa i dupa.

Może mi też zabraknąc jednego bitu w MCU. Nie wymyślaj sztucznych problemów.

> Ten z Bytomia na pewno da radę, ale skoro przetwarzasz taką ilość danych
> to chyba ta magistrala nie jest dla Ciebie. Sam twierdziłeś że to łyka
> tylko 3MBity per node.

Ale te 3Mbps to jest wynik przetwarzania, które możesz nazwać kompresją.
Wejściowe strumienie są znacznie większe, tylko one w ogóle nie
opuszczają płytki, więc ich z punktu widzenia świata nie ma. I teraz
trzeba ten wynik szybko wysłać w świat.

> No ale styknie na to miganie diodą czy nie ;)? Jesli ten FPGA nic nie
> robi tylko przepycha dane dalej to ok. Myślałem że on coś poważniejszego
> robi, a to tylko takie międzymordzie wychodzi na to.

Robi całkiem złożone DSP. A że ze względu na duże możliwości LUTów,
m.in. zdolność do pracy jako dwuportowa pamięć rozproszona, efektywne
zapotrzebowanie na zasoby jest stosunkowo małe. Układ jest tak szybki,
że umożliwia powtórne użycie tego samego bloku do obróbki wielu różnych
źródeł danych. Wiele innych rzeczy da się z kolei rozwiązać sekwencerem:
ładuję blok danych do RAM i potem odtwarzam go w pętli jak sampel. LUTów
idzie tyle, co na licznik adresu tego RAM. Cała sekwencja zdarzeń jest
przeliczona na zewnątrz w pytongu i podana FPGA do wierzenia. Większość
moich układów sprowadza się do takiego czy inego zbioru sekwencerów i w
efekcie są bardzo zwarte. Przykro mi, jeśli Cię zawiodłem.

Pozdrawiam, Piotr