NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Zwięzły zapis sumowania 16 sekcji rejestru posuwnego w VHDL - jak to uprościć?
Guest
Sun May 24, 2015 2:37 am
Problem jest w zasadzie rozwinięciem poprzedniego wątkaDo rzeczy, układ ma obliczać coś takiego: C=|R(0)+...+R(15)-R(16)-....-R(31)|, gdzie C,R(i)-liczby 11 bitowe bez znaku. R(i) są to kolejne sekcje rejestru posuwnego, w którym na pierwszą sekcję jest podawana 11 bitowa liczba "A" (bez znaku). Układ działa poprawnie zarówno na symulatorze jak i na żywym organiźmie. Wszystkie operacje +/- zrobiłem krok po kroku. A co gdybym miał pierdyljon sekcji rejestru posuwnego?
Jak to zwięźlej zapisać? Kod wygląda tak:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
library UNISIM;
use UNISIM.VComponents.all;
entity amod is
Port ( A : in STD_LOGIC_VECTOR (10 downto 0);
CLK : in STD_LOGIC;
C : out STD_LOGIC_VECTOR (10 downto 0));
end amod;
architecture Behavioral of amod is
type Shift_Register_Type is array (31 downto 0) of std_logic_vector(10 downto 0);
signal Cs:std_logic_vector(14 downto 0):="000000000000000";
signal Rejestr:Shift_Register_Type;
begin
process(CLK)
begin
if rising_edge(CLK) then
Rejestr<=Rejestr(30 downto 0)&A;
Cs<=std_logic_vector(to_unsigned(abs(to_integer(signed('0'&Rejestr(0)))+
to_integer(signed('0'&Rejestr(1)))+
to_integer(signed('0'&Rejestr(2)))+
to_integer(signed('0'&Rejestr(3)))+
to_integer(signed('0'&Rejestr(4)))+
to_integer(signed('0'&Rejestr(5)))+
to_integer(signed('0'&Rejestr(6)))+
to_integer(signed('0'&Rejestr(7)))+
to_integer(signed('0'&Rejestr(
))+
to_integer(signed('0'&Rejestr(9)))+
to_integer(signed('0'&Rejestr(10)))+
to_integer(signed('0'&Rejestr(11)))+
to_integer(signed('0'&Rejestr(12)))+
to_integer(signed('0'&Rejestr(13)))+
to_integer(signed('0'&Rejestr(14)))+
to_integer(signed('0'&Rejestr(15)))-
to_integer(signed('0'&Rejestr(16)))-
to_integer(signed('0'&Rejestr(17)))-
to_integer(signed('0'&Rejestr(1
))-
to_integer(signed('0'&Rejestr(19)))-
to_integer(signed('0'&Rejestr(20)))-
to_integer(signed('0'&Rejestr(21)))-
to_integer(signed('0'&Rejestr(22)))-
to_integer(signed('0'&Rejestr(23)))-
to_integer(signed('0'&Rejestr(24)))-
to_integer(signed('0'&Rejestr(25)))-
to_integer(signed('0'&Rejestr(26)))-
to_integer(signed('0'&Rejestr(27)))-
to_integer(signed('0'&Rejestr(2
))-
to_integer(signed('0'&Rejestr(29)))-
to_integer(signed('0'&Rejestr(30)))-
to_integer(signed('0'&Rejestr(31)))),15));
end if;
end process;
C<=Cs(14 downto 4);
end Behavioral;
Jakub Rakus
Guest
Guest
Sun May 24, 2015 8:38 pm
On 24.05.2015 02:37, stchebel@gmail.com wrote:
Quote:
Problem jest w zasadzie rozwinięciem poprzedniego wątkaDo rzeczy, układ ma obliczać coś takiego: C=|R(0)+...+R(15)-R(16)-....-R(31)|, gdzie C,R(i)-liczby 11 bitowe bez znaku. R(i) są to kolejne sekcje rejestru posuwnego, w którym na pierwszą sekcję jest podawana 11 bitowa liczba "A" (bez znaku). Układ działa poprawnie zarówno na symulatorze jak i na żywym organiźmie. Wszystkie operacje +/- zrobiłem krok po kroku. A co gdybym miał pierdyljon sekcji rejestru posuwnego?
Jak to zwięźlej zapisać? Kod wygląda tak:
ciach
Jak to zwięźlej zapisać? Kod wygląda tak:
ciach
Można użyć funkcji, która wygeneruje taką sumę dla zadanej liczby
sygnałów, w funkcji trzeba by wykorzystać for ... loop. Można też
bezpośrednio w procesie użyć for ... loop.
--
Pozdrawiam
Jakub Rakus
Guest
Sun May 24, 2015 11:34 pm
W dniu niedziela, 24 maja 2015 22:38:20 UTC+2 użytkownik Jakub Rakus napisał:
Quote:
On 24.05.2015 02:37, stchebel@gmail.com wrote:
Problem jest w zasadzie rozwinięciem poprzedniego wątkaDo rzeczy, układ ma obliczać coś takiego: C=|R(0)+...+R(15)-R(16)-....-R(31)|, gdzie C,R(i)-liczby 11 bitowe bez znaku. R(i) są to kolejne sekcje rejestru posuwnego, w którym na pierwszą sekcję jest podawana 11 bitowa liczba "A" (bez znaku). Układ działa poprawnie zarówno na symulatorze jak i na żywym organiźmie. Wszystkie operacje +/- zrobiłem krok po kroku. A co gdybym miał pierdyljon sekcji rejestru posuwnego?
Jak to zwięźlej zapisać? Kod wygląda tak:
ciach
Można użyć funkcji, która wygeneruje taką sumę dla zadanej liczby
sygnałów, w funkcji trzeba by wykorzystać for ... loop. Można też
bezpośrednio w procesie użyć for ... loop.
Problem jest w zasadzie rozwinięciem poprzedniego wątkaDo rzeczy, układ ma obliczać coś takiego: C=|R(0)+...+R(15)-R(16)-....-R(31)|, gdzie C,R(i)-liczby 11 bitowe bez znaku. R(i) są to kolejne sekcje rejestru posuwnego, w którym na pierwszą sekcję jest podawana 11 bitowa liczba "A" (bez znaku). Układ działa poprawnie zarówno na symulatorze jak i na żywym organiźmie. Wszystkie operacje +/- zrobiłem krok po kroku. A co gdybym miał pierdyljon sekcji rejestru posuwnego?
Jak to zwięźlej zapisać? Kod wygląda tak:
ciach
Można użyć funkcji, która wygeneruje taką sumę dla zadanej liczby
sygnałów, w funkcji trzeba by wykorzystać for ... loop. Można też
bezpośrednio w procesie użyć for ... loop.
No więc właśnie tak kombinowałem.
Pseudokod:
for i in 0 to 15 loop
Cs<=Cs+R(i)-R(i+16)
end loop;
I wyszedł z tego akumulator
(Jakub Rakus
Guest
Guest
Mon May 25, 2015 7:52 pm
On 24.05.2015 23:34, stchebel@gmail.com wrote:
Quote:
No więc właśnie tak kombinowałem.
Pseudokod:
for i in 0 to 15 loop
Cs<=Cs+R(i)-R(i+16)
end loop;
I wyszedł z tego akumulator
(
Bo to nie można tego zrobić na sygnałach tylko na variable wewnątrz
procesu. I wtedy nie <= tylko :=.
--
Pozdrawiam
Jakub Rakus
Guest
Mon May 25, 2015 11:27 pm
W dniu poniedziałek, 25 maja 2015 21:52:12 UTC+2 użytkownik Jakub Rakus napisał:
Quote:
On 24.05.2015 23:34, stchebel@gmail.com wrote:
No więc właśnie tak kombinowałem.
Pseudokod:
for i in 0 to 15 loop
Cs<=Cs+R(i)-R(i+16)
end loop;
I wyszedł z tego akumulator(
Bo to nie można tego zrobić na sygnałach tylko na variable wewnątrz
procesu. I wtedy nie <= tylko :=.
No więc właśnie tak kombinowałem.
Pseudokod:
for i in 0 to 15 loop
Cs<=Cs+R(i)-R(i+16)
end loop;
I wyszedł z tego akumulator
(
Bo to nie można tego zrobić na sygnałach tylko na variable wewnątrz
procesu. I wtedy nie <= tylko :=.
OK, dzięki! Teraz działa.
J.F.
Guest
Guest
Tue May 26, 2015 8:36 am
Użytkownik napisał w wiadomości grup
Quote:
Problem jest w zasadzie rozwinięciem poprzedniego wątkaDo rzeczy,
układ ma obliczać coś takiego: C=|R(0)+...+R(15)-R(16)-....-R(31)|,
gdzie C,R(i)-liczby 11 bitowe bez znaku.
R(i) są to kolejne sekcje rejestru posuwnego, w którym na pierwszą
sekcję jest podawana 11 bitowa liczba "A" (bez znaku).
Układ działa poprawnie zarówno na symulatorze jak i na żywym
organiźmie.
Wszystkie operacje +/- zrobiłem krok po kroku. A co gdybym miał
pierdyljon sekcji rejestru posuwnego?
Jak to zwięźlej zapisać? Kod wygląda tak:
układ ma obliczać coś takiego: C=|R(0)+...+R(15)-R(16)-....-R(31)|,
gdzie C,R(i)-liczby 11 bitowe bez znaku.
R(i) są to kolejne sekcje rejestru posuwnego, w którym na pierwszą
sekcję jest podawana 11 bitowa liczba "A" (bez znaku).
Układ działa poprawnie zarówno na symulatorze jak i na żywym
organiźmie.
Wszystkie operacje +/- zrobiłem krok po kroku. A co gdybym miał
pierdyljon sekcji rejestru posuwnego?
Jak to zwięźlej zapisać? Kod wygląda tak:
Czy ja dobrze rozumiem ze mamy rejestr przesuwny o 32 slowach 11
bitowych,
co takt zegara slowa wprowadzamy nowa wartosc, reszte przesuwamy, i
wyliczamy sume pierwszych 16 slow minus suma drugich 16 slow ?
Pomijajac trudnosci jak to zwiezle w VHDL zapisac ... pomysleliscie
jak to powinno byc zrealizowane ? Czy zdajecie sie na optymalizator ?
:-)
Bo sumator 32 liczb jest dosc kosztowny, ciekawe - kompilatorowi
pamieci zabraknie przy optymalizacji funkcji, czy zrealizuje
kaskadowo.
A im wiecej slow w tym rejestrze, tym ciezsze zadanie.
To sie w krzemie realizuje inaczej ...
J.
J.F.
Guest
Guest
Wed May 27, 2015 8:40 am
Użytkownik napisał w wiadomości grup
dyskusyjnych:b145b622-569c-4b81-991a-acb893cd1e3f@googlegroups.com...
W dniu wtorek, 26 maja 2015 10:36:42 UTC+2 użytkownik J.F. napisał:
Quote:
Czy ja dobrze rozumiem ze mamy rejestr przesuwny o 32 slowach 11
bitowych,
co takt zegara slowa wprowadzamy nowa wartosc, reszte przesuwamy, i
wyliczamy sume pierwszych 16 slow minus suma drugich 16 slow ?
Dobrze rozumiesz.
Pomijajac trudnosci jak to zwiezle w VHDL zapisac ... pomysleliscie
jak to powinno byc zrealizowane ? Czy zdajecie sie na
optymalizator ?
:-)
Bo sumator 32 liczb jest dosc kosztowny, ciekawe - kompilatorowi
pamieci zabraknie przy optymalizacji funkcji, czy zrealizuje
kaskadowo.
A im wiecej slow w tym rejestrze, tym ciezsze zadanie.
Robię to na spartanie6 (XCS6LX45) i nie ma żadnego problemu z
implementacją.
bitowych,
co takt zegara slowa wprowadzamy nowa wartosc, reszte przesuwamy, i
wyliczamy sume pierwszych 16 slow minus suma drugich 16 slow ?
Dobrze rozumiesz.
Pomijajac trudnosci jak to zwiezle w VHDL zapisac ... pomysleliscie
jak to powinno byc zrealizowane ? Czy zdajecie sie na
optymalizator ?
:-)
Bo sumator 32 liczb jest dosc kosztowny, ciekawe - kompilatorowi
pamieci zabraknie przy optymalizacji funkcji, czy zrealizuje
kaskadowo.
A im wiecej slow w tym rejestrze, tym ciezsze zadanie.
Robię to na spartanie6 (XCS6LX45) i nie ma żadnego problemu z
implementacją.
A jest jakas szansa zobaczyc jak to kompilator zrobil ?
Ewentualnie - ile makrocell mu to zajelo, jakie opoznienia wyszly ?
Quote:
To sie w krzemie realizuje inaczej ...
Jak?
Jak?
Pomysl pierwszy - rysunek by sie przydal, ale moze sie uda slowami:
32 rejestry w szeregu, tylko ze na wejsciu kazdego (z wyjatkiem
pierwszego) z nich umieszczasz sumator A i wyjscia poprzednego
rejestru.
Tym sposobem drugi rejestr widzi R1= A+A(-1), [A(-n) - A opoznione
o n cykli)
R2 = A+R1 = A+ A(-1) + A(-2) [bo w miedzyczasie sie o cykl opoznilo]
itd.
Gdzies w polowie musisz wstawic roznice A-R(15)
Pomysl drugi - jesli jest zwykla suma, to ona co cykl zmienia sie
tylko o nowy wyraz, ktory wchodzi do sumy, i ostatni, ktory wypada.
Czyli wystarczy jeden akumulator S, w ktorym co cykl liczymy
S = S +A - A(-31)
Oczywiscie na poczatku trzeba wyzerowac i S i wszystkie rejestry R,
aby byla zgodnosc
.
Ty masz roznice dwoch sum, to sie wyrazenie nieznacznie skomplikuje.
J.
Guest
Wed May 27, 2015 8:48 am
W dniu wtorek, 26 maja 2015 10:36:42 UTC+2 użytkownik J.F. napisał:
Quote:
Użytkownik napisał w wiadomości grup
Problem jest w zasadzie rozwinięciem poprzedniego wątkaDo rzeczy,
układ ma obliczać coś takiego: C=|R(0)+...+R(15)-R(16)-....-R(31)|,
gdzie C,R(i)-liczby 11 bitowe bez znaku.
R(i) są to kolejne sekcje rejestru posuwnego, w którym na pierwszą
sekcję jest podawana 11 bitowa liczba "A" (bez znaku).
Układ działa poprawnie zarówno na symulatorze jak i na żywym
organiźmie.
Wszystkie operacje +/- zrobiłem krok po kroku. A co gdybym miał
pierdyljon sekcji rejestru posuwnego?
Jak to zwięźlej zapisać? Kod wygląda tak:
Czy ja dobrze rozumiem ze mamy rejestr przesuwny o 32 slowach 11
bitowych,
co takt zegara slowa wprowadzamy nowa wartosc, reszte przesuwamy, i
wyliczamy sume pierwszych 16 slow minus suma drugich 16 slow ?
Problem jest w zasadzie rozwinięciem poprzedniego wątkaDo rzeczy,
układ ma obliczać coś takiego: C=|R(0)+...+R(15)-R(16)-....-R(31)|,
gdzie C,R(i)-liczby 11 bitowe bez znaku.
R(i) są to kolejne sekcje rejestru posuwnego, w którym na pierwszą
sekcję jest podawana 11 bitowa liczba "A" (bez znaku).
Układ działa poprawnie zarówno na symulatorze jak i na żywym
organiźmie.
Wszystkie operacje +/- zrobiłem krok po kroku. A co gdybym miał
pierdyljon sekcji rejestru posuwnego?
Jak to zwięźlej zapisać? Kod wygląda tak:
Czy ja dobrze rozumiem ze mamy rejestr przesuwny o 32 slowach 11
bitowych,
co takt zegara slowa wprowadzamy nowa wartosc, reszte przesuwamy, i
wyliczamy sume pierwszych 16 slow minus suma drugich 16 slow ?
Dobrze rozumiesz.
Quote:
Pomijajac trudnosci jak to zwiezle w VHDL zapisac ... pomysleliscie
jak to powinno byc zrealizowane ? Czy zdajecie sie na optymalizator ?
:-)
Bo sumator 32 liczb jest dosc kosztowny, ciekawe - kompilatorowi
pamieci zabraknie przy optymalizacji funkcji, czy zrealizuje
kaskadowo.
A im wiecej slow w tym rejestrze, tym ciezsze zadanie.
Robię to na spartanie6 (XCS6LX45) i nie ma żadnego problemu z implementacją.
Quote:
To sie w krzemie realizuje inaczej ...
Jak?
J.F.
Guest
Guest
Wed May 27, 2015 10:09 am
Użytkownik napisał w wiadomości grup
dyskusyjnych:7ba3c1df-aa38-42e9-96a5-55679d72c497@googlegroups.com...
W dniu środa, 27 maja 2015 10:40:37 UTC+2 użytkownik J.F. napisał:
Quote:
A jest jakas szansa zobaczyc jak to kompilator zrobil ?
Ewentualnie - ile makrocell mu to zajelo, jakie opoznienia wyszly ?
Można to zobaczyć na edytorze wyroutowanego układu, ale analizę tego
pozostawiam raczej mnichom z Shaolin, albo tym co mają czasu w
nadmiarze.
Makrocele to masz w CPLD. Ja robię na FPGA raczej dosyć małym, ale i
tak ilość zasobów logicznych jest taka, że ten konkretny problem
zajmuje kompletnie nieistotny procent. W ogóle o tym nawet nie myślę.
Opóźnienia jak najbardziej możesz monitorować, >ewentualnie narzucić
swoje constraintsy. Ja tego nawet nie robię, zostawiam to
kompilatorowi "as is", układ działa poprawnie na 20MHz.
Pomysl pierwszy - rysunek by sie przydal, ale moze sie uda slowami:
32 rejestry w szeregu, tylko ze na wejsciu kazdego (z wyjatkiem
pierwszego) z nich umieszczasz sumator A i wyjscia poprzednego
rejestru.
Rozumiem, że coś w tym stylu:
http://www.fotoszok.pl/show.php/2420352_sumator.jpg.html
Ewentualnie - ile makrocell mu to zajelo, jakie opoznienia wyszly ?
Można to zobaczyć na edytorze wyroutowanego układu, ale analizę tego
pozostawiam raczej mnichom z Shaolin, albo tym co mają czasu w
nadmiarze.
Makrocele to masz w CPLD. Ja robię na FPGA raczej dosyć małym, ale i
tak ilość zasobów logicznych jest taka, że ten konkretny problem
zajmuje kompletnie nieistotny procent. W ogóle o tym nawet nie myślę.
Opóźnienia jak najbardziej możesz monitorować, >ewentualnie narzucić
swoje constraintsy. Ja tego nawet nie robię, zostawiam to
kompilatorowi "as is", układ działa poprawnie na 20MHz.
Pomysl pierwszy - rysunek by sie przydal, ale moze sie uda slowami:
32 rejestry w szeregu, tylko ze na wejsciu kazdego (z wyjatkiem
pierwszego) z nich umieszczasz sumator A i wyjscia poprzednego
rejestru.
Rozumiem, że coś w tym stylu:
http://www.fotoszok.pl/show.php/2420352_sumator.jpg.html
Dokladnie.
Quote:
Pomysl drugi - jesli jest zwykla suma, to ona co cykl zmienia sie
tylko o nowy wyraz, ktory wchodzi do sumy, i ostatni, ktory wypada.
Czyli wystarczy jeden akumulator S, w ktorym co cykl liczymy
S = S +A - A(-31)
Jasne, można i tak i owak, niemniej jednak nie dostrzegam żadnych
zalet w stosunku do przyjętego rozwiązania.
tylko o nowy wyraz, ktory wchodzi do sumy, i ostatni, ktory wypada.
Czyli wystarczy jeden akumulator S, w ktorym co cykl liczymy
S = S +A - A(-31)
Jasne, można i tak i owak, niemniej jednak nie dostrzegam żadnych
zalet w stosunku do przyjętego rozwiązania.
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 :-)
J.
Guest
Wed May 27, 2015 11:55 am
W dniu środa, 27 maja 2015 10:40:37 UTC+2 użytkownik J.F. napisał:
Quote:
A jest jakas szansa zobaczyc jak to kompilator zrobil ?
Ewentualnie - ile makrocell mu to zajelo, jakie opoznienia wyszly ?
Można to zobaczyć na edytorze wyroutowanego układu, ale analizę tego pozostawiam raczej mnichom z Shaolin, albo tym co mają czasu w nadmiarze.
Makrocele to masz w CPLD. Ja robię na FPGA raczej dosyć małym, ale i tak ilość zasobów logicznych jest taka, że ten konkretny problem zajmuje kompletnie nieistotny procent. W ogóle o tym nawet nie myślę. Opóźnienia jak najbardziej możesz monitorować, ewentualnie narzucić swoje constraintsy. Ja tego nawet nie robię, zostawiam to kompilatorowi "as is", układ działa poprawnie na 20MHz.
Quote:
To sie w krzemie realizuje inaczej ...
Jak?
Pomysl pierwszy - rysunek by sie przydal, ale moze sie uda slowami:
32 rejestry w szeregu, tylko ze na wejsciu kazdego (z wyjatkiem
pierwszego) z nich umieszczasz sumator A i wyjscia poprzednego
rejestru.
Tym sposobem drugi rejestr widzi R1= A+A(-1), [A(-n) - A opoznione
o n cykli)
R2 = A+R1 = A+ A(-1) + A(-2) [bo w miedzyczasie sie o cykl opoznilo]
itd.
Gdzies w polowie musisz wstawic roznice A-R(15)
Rozumiem, że coś w tym stylu:
http://www.fotoszok.pl/show.php/2420352_sumator.jpg.html
Quote:
Pomysl drugi - jesli jest zwykla suma, to ona co cykl zmienia sie
tylko o nowy wyraz, ktory wchodzi do sumy, i ostatni, ktory wypada.
Czyli wystarczy jeden akumulator S, w ktorym co cykl liczymy
S = S +A - A(-31)
Oczywiscie na poczatku trzeba wyzerowac i S i wszystkie rejestry R,
aby byla zgodnosc
.
Quote:
Ty masz roznice dwoch sum, to sie wyrazenie nieznacznie skomplikuje.
Jasne, można i tak i owak, niemniej jednak nie dostrzegam żadnych zalet w stosunku do przyjętego rozwiązania.
Pzdr.
J.F.
Guest
Guest
Wed May 27, 2015 3:40 pm
Użytkownik napisał w wiadomości grup
W dniu środa, 27 maja 2015 12:09:27 UTC+2 użytkownik J.F. napisał:
Quote:
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.
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.
Guest
Wed May 27, 2015 5:26 pm
W dniu środa, 27 maja 2015 12:09:27 UTC+2 użytkownik J.F. napisał:
Quote:
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.
Guest
Wed May 27, 2015 7:29 pm
W dniu środa, 27 maja 2015 17:40:54 UTC+2 użytkownik J.F. napisał:
Quote:
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..
Quote:
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!!
J.F.
Guest
Guest
Fri May 29, 2015 11:39 am
Użytkownik napisał w wiadomości grup
W dniu środa, 27 maja 2015 17:40:54 UTC+2 użytkownik J.F. napisał:
Quote:
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.
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.
Guest
Fri May 29, 2015 12:48 pm
W dniu środa, 27 maja 2015 17:40:54 UTC+2 użytkownik J.F. napisał:
Quote:
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
...
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.
elektroda NewsGroups Forum Index - Elektronika Polska - Zwięzły zapis sumowania 16 sekcji rejestru posuwnego w VHDL - jak to uprościć?