Reprogramowanie FPGA przez uC: Jak skonfigurować logikę w czasie rzeczywistym?

Mon Feb 08, 2010 6:59 pm   

Witam.

Zastanawiam się nad pewnym rozwiązaniem. Ogólnie mam uC który musi
obrabiać pewne sygnaly cyfrowe na granicy możliwości sprzetowych
(predkość podejmowania decyzji). Jako ze większośc z tych decyzji opiera
się o prostą logikę kombinatoryczną, sporadycznie wzbogaconą o
"przerzutnik" w algorytmie tak sobie myślę nad małym FPGA[1]
konfigurowanym/programowanym przez uC. Kluczowe tutaj jest
konfigurowanie run-time (zależy od wybranego algorytmu przez operatora).
Przełaczanie pomiedzy różnymi "programami" w FPGA może być powolne,
istota jest tutaj możliwośc reprogramowania przez sam procesor a nie
szybkiego programowania.

Niestety musze znac odpowiedzi na pare prostych pytań zanim zaczne w
ogóle nad tym mysleć.

a) czy proceosory (ogólnie) z wbudowanym FPGA pozwalają na
reprogramowanie tego FPGA z poziomu programu ? Jesli tak, to czy
reprogramowanie odbywa się we flash (martwie sie o ilość cykli).

b) czy operacja zamiany logiki na zawartośc flash/ram FPGA wymaga
stosowania skomplikowanych algorytmów czy moze istnieje sensowny sposób
przekształcenia układu kombinatorycznego zapisanego za pomoca + * / na
wsad do FPGA ?

c) gdzie moge poczytać o samym procesie syntezy ukladu opisanego
kombinatorycznie + ewentualne przerzutniki do wsadu FPGA? Wystarczy bez
szczegółów, nie na tym poziomie o tym myślę. Iteresuje mnie złożoność
tego projektu - nawet tylko dla jednego typu układu. Szczególnie czy
taka uproszczona synteza jest możliwa w małej ilości RAM cpu.

d) Czy FPGA może przeprogramowac swój fragment? Zastanawiam się nad
możlwością wsadzenia do FPGA całości (uC + kawałek logiki) i zmianą
konfiguracji w run-time - czy to możliwe?

[1] "FPGA" to słowo które opisuje dowolna technologie ukladów
programowalnych, niekoniecznie FPGA wlasnie. Sam nie wiem co to być
powinno, na razie rozglądam sie ogólnie.

Mon Feb 08, 2010 10:45 pm   

On 08/02/2010 17:59, Sebastian Biały wrote:

1. Nie da sie miec jednego wsadu i jakims CS przelaczac rodzaj
algorytmu? Jak sprytnie napiszesz, to moze zajac niewiele wiecej niz
jeden algorytm (np: uzyc enable tylko dla jakichs krokow).
2. Jesli chcesz 'tworzyc' wsady do CPLD/FPGA on-line (wg parametrow
uzytkownika) to ciezkie zadanie - chyba nikt nie udostepnia sposobu
kompilacji.
3. FPGA to sa kosci wiekszej pojemnosci, gdzie config jest ladowany z
zewnetrznej pamieci/procesora do wewnetrznego SRAM, CPLD to 'mlodszy
brat', gdzie config jest trzymany w EEPROMie w kosci (i AFAIK nie da sie
przeprogramowac bez JTAGa).


--
Jerry1111

Mon Feb 08, 2010 11:00 pm   

Jerry1111 wrote:

Algorytmow jest duzo, w zasadzie konfiguruje je uC na żądanie. Moge je
wszystkie zaszyć, ale może własnie prościej jest je wrzucić w formie
specjalizowanej.


Ano wlasnie o to pytam. Jesli całośc procesu jest słabo udokumentowana i
tajemnicza - pomysl odpada.


Wiem że są FPGA dynamicznie rekonfigurowane, ale niekoniecznie o to mi
chodzi. W zasadzie to ja potrzebuje prosty układ kombinatoryczny z fmax
~ 20MHz rekonfigurowalny w dowolny sposób z uC. Czasem z jakimiś
przerzutnikami. jesli zagadnienie jest ogólnie trudne, to sprawę
pozostaje mi odłozyc na półke na lepsze czasy.

Mon Feb 08, 2010 11:13 pm   

On 08/02/2010 22:00, Sebastian Biały wrote:

Sa, ale duze. A ja mam wrazenie ze Tobie na mniejszych zalezy.


Ja bym popatrzyl czy da sie jakis 'duzy' algorytm zrobic, z ktorego
potem metodami 'enable' mozna by wlaczac/wylaczac jakies bloki. Albo
miec np: dwa 8-bitowe slowa stanu dla kazdej operacji (np: jesli w
pierwszym bajcie d0=1 to pierwszy krok algorytmu to OR, jesli w drugim
bajcie d0=1 to pierwszy krok to AND) - cos takiego nie bedzie (za)
trudne. Ot, takie proste szybkie ALU.

Jak to masz, to wtedy moglbys by 3-4 rodziny algorytmow zmieniac poprzez
zmiane stanu kilku pinow. Do EPM570 (CPLD Altery) wejdzie troche kodu (a
logika na rejestrach konfiguracyjnych nie rozdmucha za bardzo wsadu).

Duzo masz operacji na tych danych?

--
Jerry1111

Tue Feb 09, 2010 12:03 am   

Jerry1111 wrote:

Nie potrafie tego precyzyjnie określić. Zazwyczaj mam około 3-4 bramek *
i + z negacjami) jako jeden "algorytm" kombinatoryczny. W wersji lite. W
weesji wypas - około 10 bramek i przerzutnik. Niestety na razie nie jest
to okreslone, to luźne szacunki i nie chce wnikać w szczegóły. Jeśli
FPGA/CPLD w wersji mini nie potrafią być przeprogramowywane, to
przemyśle sprawę robiąć w środku jakies wlasnie proste sekwencyjne ALU.

Tue Feb 09, 2010 12:13 am   

On Tue, 09 Feb 2010 00:03:21 +0100, Sebastian Biały wrote:

Moze ci wystarczy wpisac tablice funkcji do pamieci ?


Mozna i tablice przejsc automatu wpisac.

J.

Tue Feb 09, 2010 11:00 am   

a moze by tak od innej strony - procesor risc i fpga w jednym? :)

zobacz sobie np. na uklad xilinx virtex-4 FX12.
masz tam przyzwoity (jak na embedded) rdzen powerpc
oraz reszte dobrodziejstw klasycznych fpga.

cenowo tez jest obecnie niezle, gotowe kity uruchomieniowe
kraza w sieci po 100.200$.

Tue Feb 09, 2010 5:24 pm   

Paweł wrote:

Nie jest mi potrzebny taki wypas.


Kompletnie bez sensu, to ma byc mały element z paronastoma bramkami.
Wole zredukowac koszt choćby dlatego że potrzebuje tego raz do roku użyć
kilkadziesiąt razy.

W zasadzie moje problemy rozwiązał by jakis AVR + maluteńki FPGA/CPLD.
Jeśli nie da się tego układu programowac, to pozostaje opisać coś na
kształt ALU w HDL i sterowac po mojemu.

Wed Feb 10, 2010 12:06 am   

Hmmm... a jaki to procesor? Nie wystarczy dać szybszą jednostkę??...


Są to dosyć skomplikowane operacje... wprawdzie na studiach
realizowaliśmy pewne przykłady "na kartce" i właściwie wszystko dało się
jakoś wyjaśnić, jednak rzuć okiem jak długo komercyjne programy "tłuką"
proste projekty do pliku wynikowego FPGA, to da Ci to pewien pogląd na
sytuację... Wszystko zależy od rodzaju funkcji... Znacznym problemem
jest tzw. dekompozycja, czyli rozłożenie jednej funkcji wielu zmiennych
na kilka funkcji mniejszej liczby zmiennych. Czasem jest to wręcz
banalne, czasem, skomplikowane... bloki w FPGA mają określoną ilość
wejść i czasem konieczne jest takie rozbijanie...

Ja proponowałbym zainteresowanie się szybszym procesorem, także
procesorami "programowanymi" do FPGA... Bierzesz gotowy rdzeń procesora,
piszesz sobie program. Procesor pracuje z programu z pamięci RAM
(wbudowanej w FPGA)... Sam pisałeś, że urządzenie wykorzystywane będzie
raz na jakiś czas... Więc gotowy klocek z FPGA plus gotowy program
"wzorcowy" na PCcie... Bierzesz ten gotowy program i wpisujesz
odpowiedni algorytm, programujesz i działasz ... całość programowania
odbywa się do pamięci RAM, więc nie ma problemu z ilością cykli. Co
więcej - nie przerabiasz "wsadu" do FGPA, tylko kompilujesz prosty
program dla jakiegoś proca, więc dzieje się to dosyć szybko...
Jeśli urządzenie ma być programowane nie przez PC - też nie ma
problemu... wsad dla takiego wirtualnego proca też łatwiej "zrobić na
piechotę" niż wsad dla FPGA...
Oczywiście wszystko zależy od tego jakiej rzeczywistej prędkości
potrzebujesz... Zapewne mógłbyś też olać FPGA i dać jakiś bardziej
"wypasiony" procesor...

--
Pozdrawiam
Konop

Wed Feb 10, 2010 6:00 pm   

W dniu 2010-02-09 17:24, Sebastian Biały pisze:

Jak AVR + maly FPGA by wystarczyl to moze maly Cortex-M3 to zalatwi ?
NXP ma takie dzialajace do 100 MHz, a krytyczne fragmenty kodu mozna
wykonywac z ramu.

Pozdr
AK

Wed Feb 10, 2010 6:24 pm   

AK wrote:

Żebyśmy suię dobrze zrozumieli - mnie interesuje malutki uklad
kombinatoryczny pracujący mozliwe szybko. W przypadku uC zawsze mam po
drodze problem wydajności GPIO i upierdliwego algorytmu zajmujacego mi w
procku 100% mocy. Nie wiem jak szybkie Cortex ma GPIO, ale przypuszczam,
że przecietny FPGA/CPLD ma szybsze.

Dla ciekawskich - potrzebuje wyzwolić "oscyloskop" dość nietypową
sekwencją stanów (na szczeście w lini czasu wystarczy jeden-dwa
przerzutniki w sytuacjach wypasionych).

Wed Feb 10, 2010 9:07 pm   

On 10/02/2010 17:24, Sebastian Biały wrote:

No to dowolnie maly Cyclone III/IV starczy.
Mozesz nawet sprobowac uzyc SignalTapa zeby zobaczyc jak Altera to
zrobila (analizator stanow w FPGA).

--
Jerry1111