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(sign
ed('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(8)))+
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(18)))-
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(28)))-
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;

do góry

On 24.05.2015 02:37, s...@g...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.

--
Pozdrawiam
Jakub Rakus

do góry

W dniu niedziela, 24 maja 2015 22:38:20 UTC+2 użytkownik Jakub Rakus napisał:
> On 24.05.2015 02:37, s...@g...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.
>

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 :((

do góry

On 24.05.2015 23:34, s...@g...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 :=.

--
Pozdrawiam
Jakub Rakus

do góry

W dniu poniedziałek, 25 maja 2015 21:52:12 UTC+2 użytkownik Jakub Rakus napisał:
> On 24.05.2015 23:34, s...@g...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 :=.
>

OK, dzięki! Teraz działa.

do góry

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 ?

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.

do góry

W dniu wtorek, 26 maja 2015 10:36:42 UTC+2 użytkownik J.F. napisał:
> 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 ?

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ą.

>
> To sie w krzemie realizuje inaczej ...
>
Jak?

do góry

Użytkownik napisał w wiadomości grup
dyskusyjnych:b145b622-569c-4b81-991a-acb893cd1e3f@go
oglegroups.com...
W dniu wtorek, 26 maja 2015 10:36:42 UTC+2 użytkownik J.F. napisał:
>> 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ą.

A jest jakas szansa zobaczyc jak to kompilator zrobil ?
Ewentualnie - ile makrocell mu to zajelo, jakie opoznienia wyszly ?

>> 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)


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.

do góry

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

>
> 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.

>
> >> 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

>
> 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.
>

Jasne, można i tak i owak, niemniej jednak nie dostrzegam żadnych zalet w stosunku do
przyjętego rozwiązania.

Pzdr.

do góry

Użytkownik napisał w wiadomości grup
dyskusyjnych:7ba3c1df-aa38-42e9-96a5-55679d72c497@go
oglegroups.com...
W dniu środa, 27 maja 2015 10:40:37 UTC+2 użytkownik J.F. napisał:
>> 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

Dokladnie.

>> 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.

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.

do góry