W dniu środa, 27 maja 2015 12:09:27 UTC+2 użytkownik J.F. napisał:

>
> Funkcja logiczna wydaje znacznie prosztsza.
> Ale moze nie doceniam kompilatora.
>
> Jesli masz wszystko przygotowane ... moze bys zrobil drugi projekt w
> alternatywnej wersji, tylko jak to ocenic - % zajetosci zasobow,
> wyliczona maksymalna czestotliwosc pracy, czas pracy kompilatora ?
> To ostatnie najmniej istotne :-)
>
>
Jako jedeny moduł w FPGA, Twoja wersja zajmuje minimalnie mniej zasobów czysto
logicznych (LUT's), ale tyle samo Flip-Flopów, co jest akurat oczywiste (rejestr
posuwny). Natomiast w całości mojego projektu zastosowanie modułu w/g Twojego pomysłu
- na odwrót. Dzieje się tak zapewne dlatego, że mapowanie w przypadku wykorzystania
większej liczby zasobów zaczyna być bardziej "agresywne". Algorytmów nie znamy, więc
są to czyste spekulacje z mojej strony. Prędkość praktycznie ta sama, można to
popychać ~140MHz.

do góry

Użytkownik napisał w wiadomości grup
W dniu środa, 27 maja 2015 12:09:27 UTC+2 użytkownik J.F. napisał:
> Funkcja logiczna wydaje znacznie prosztsza.
> Ale moze nie doceniam kompilatora.
> Jesli masz wszystko przygotowane ... moze bys zrobil drugi projekt w
> alternatywnej wersji, tylko jak to ocenic - % zajetosci zasobow,
> wyliczona maksymalna czestotliwosc pracy, czas pracy kompilatora ?
> To ostatnie najmniej istotne :-)
>
>
>Jako jedeny moduł w FPGA, Twoja wersja zajmuje minimalnie mniej
>zasobów czysto logicznych (LUT's), ale tyle samo Flip-Flopów, co jest
>akurat oczywiste (rejestr posuwny). Natomiast w całości mojego
>projektu zastosowanie modułu w/g Twojego pomysłu - na odwrót. >Dzieje
>się tak zapewne dlatego, że mapowanie w przypadku wykorzystania
>większej liczby zasobów zaczyna być bardziej "agresywne". Algorytmów
>nie znamy, więc są to czyste spekulacje z mojej strony. Prędkość
>praktycznie ta sama, można to popychać ~140MHz.

No, to ciekaw jestem jak to kompilator zrealizowal.

Dodawanie 32 liczb 11-bit- wydaje mi sie, ze to bardzo wredna funkcja.
Oczywiscie mozna zrealizowac zwyklymi sumatorami dwoch liczb, nawet
tyle samo ich trzeba, ale czas propagacji powinien wzrosnac.
Jak zrobil "liniowo" a nie "drzewem binarnym", to nawet sporo wzrosnac
...

Chyba, ze nawet nie zblizyles sie do granicy szybkosci ...

J.

do góry

W dniu środa, 27 maja 2015 17:40:54 UTC+2 użytkownik J.F. napisał:

>
> No, to ciekaw jestem jak to kompilator zrealizowal.
>
> Dodawanie 32 liczb 11-bit- wydaje mi sie, ze to bardzo wredna funkcja.
> Oczywiscie mozna zrealizowac zwyklymi sumatorami dwoch liczb, nawet
> tyle samo ich trzeba, ale czas propagacji powinien wzrosnac.
> Jak zrobil "liniowo" a nie "drzewem binarnym", to nawet sporo wzrosnac
> ...

W FPGA jest trochę inaczej i nie należy, wręcz NIE WOLNO myśleć w kategoriach bramek
logicznych i połączeń między nimi i wydawałoby się wynikających z tego czasów
propagacji. Tutaj masz generatory funkcji, które w obrębie pojedyńczego CLB są niczym
innym jak pamięcią statyczną i realizują dowolną funkcję logiczną n-zmiennych
(n-zależne od typu FPGA). Jest to właściwie LUT(look up table), w którym wartości
zmiennych wejściowych stanowią adres do gotowego wyniku. Oczywiście taka kobyła jak
sumator 32 liczb 11-bitowych nie wlezie w pojedyńczy LUT, więc czasy propagacji są
pomiędzy poszczególnymi CLB, ale jest to mocno zniwelowane..

>
> Chyba, ze nawet nie zblizyles sie do granicy szybkosci ...
>

Na próbę pocisnąłem to na 80MHz, co akurat w moim projekcie nie ma sensu. Też
działa!!

do góry

W dniu środa, 27 maja 2015 17:40:54 UTC+2 użytkownik J.F. napisał:
> Użytkownik napisał w wiadomości grup
> W dniu środa, 27 maja 2015 12:09:27 UTC+2 użytkownik J.F. napisał:
> > Funkcja logiczna wydaje znacznie prosztsza.
> > Ale moze nie doceniam kompilatora.
> > Jesli masz wszystko przygotowane ... moze bys zrobil drugi projekt w
> > alternatywnej wersji, tylko jak to ocenic - % zajetosci zasobow,
> > wyliczona maksymalna czestotliwosc pracy, czas pracy kompilatora ?
> > To ostatnie najmniej istotne :-)
> >
> >
> >Jako jedeny moduł w FPGA, Twoja wersja zajmuje minimalnie mniej
> >zasobów czysto logicznych (LUT's), ale tyle samo Flip-Flopów, co jest
> >akurat oczywiste (rejestr posuwny). Natomiast w całości mojego
> >projektu zastosowanie modułu w/g Twojego pomysłu - na odwrót. >Dzieje
> >się tak zapewne dlatego, że mapowanie w przypadku wykorzystania
> >większej liczby zasobów zaczyna być bardziej "agresywne". Algorytmów
> >nie znamy, więc są to czyste spekulacje z mojej strony. Prędkość
> >praktycznie ta sama, można to popychać ~140MHz.
>
> No, to ciekaw jestem jak to kompilator zrealizowal.
>
> Dodawanie 32 liczb 11-bit- wydaje mi sie, ze to bardzo wredna funkcja.
> Oczywiscie mozna zrealizowac zwyklymi sumatorami dwoch liczb, nawet
> tyle samo ich trzeba, ale czas propagacji powinien wzrosnac.
> Jak zrobil "liniowo" a nie "drzewem binarnym", to nawet sporo wzrosnac
> ...


A jednak Twój pomysł jest lepszy!! Postanowiłem rozszerzyć zagadnienie do 64 liczb.
No i od tego momentu zaczęły się chece. Zasoby i czas propagacji poszły ostro w górę,
podczas gdy w/g Twojej porady nadal wszystko jest cacy.

do góry

Użytkownik napisał w wiadomości grup
W dniu środa, 27 maja 2015 17:40:54 UTC+2 użytkownik J.F. napisał:
>> No, to ciekaw jestem jak to kompilator zrealizowal.
>
>> Dodawanie 32 liczb 11-bit- wydaje mi sie, ze to bardzo wredna
>> funkcja.
>> Oczywiscie mozna zrealizowac zwyklymi sumatorami dwoch liczb, nawet
>> tyle samo ich trzeba, ale czas propagacji powinien wzrosnac.
>> Jak zrobil "liniowo" a nie "drzewem binarnym", to nawet sporo
>> wzrosnac

>A jednak Twój pomysł jest lepszy!! Postanowiłem rozszerzyć
>zagadnienie do 64 liczb. No i od tego momentu zaczęły się chece.
>Zasoby i czas propagacji poszły ostro w górę, podczas gdy w/g Twojej
>porady nadal wszystko jest cacy.

Ciesze sie, ze choc raz teoria zgadza sie z praktyka :-)

Ale nadal jestem ciekaw jak on to zrobil z 32 liczbami, ze tak dobrze
bylo :-)

J.

do góry

W dniu piątek, 29 maja 2015 13:39:46 UTC+2 użytkownik J.F. napisał:

>
> Ciesze sie, ze choc raz teoria zgadza sie z praktyka :-)

Jeżeli teoria nie zgadza się z praktyką, to tym gorzej dla praktyki :)))
Eeee tam.., jeżeli w cyfrówie wymiśli się coś BANALNIE prostego, to nie ma bata we
wsi, coby to nie działało.. Podałeś też pomysł z wykorzystaniem akumulatora..
Toż to pierwsze o czym pomyślałem, ale doszedłem do wniosku, że to lipa.. No bo po
n+1 mlasknięciach zegara akumulator się "przekręci". Resetowanie co n-mlasknięć jest
też beż sensu, bo tracę dane R(n downto 0)!!

Ale..., Twój pomysł z akumulatorem + mój pomysł z rejestrem posuwnym ma sens.

Robimy taki akumulator : Acc:=Acc+A(n)-A(0). A(n) - aktualna próbka z ADC, A(0) -
n-mlasknięć starsza próbka z FIFO. Owym FIFO może być właśnie rejestr posuwny. Innymi
słowy A(i) leci równolegle na akumulator i rejestr posuwny. Wyjście z rejestru (na
końcu), to A(0). Minimalne zużycie zasobów FPGA dla dowolnego 'n', powinno śmigać na
ciężkich MHz. Jutro sprawdzę na 'żywym organiźmie'. Dzięki za pomysły, sensownie się
z Tobą gada !!


>
> Ale nadal jestem ciekaw jak on to zrobil z 32 liczbami, ze tak dobrze
> bylo :-)
>
> J.

do góry