VHDL - typy. Problem :(

May 26, 2011 12 Replies

Witam!



Mam straszny problem z VHDL'em. Potrzebuje połączyć pewne klocki. Już na samym początku nie wiem o co chodzi z tym:


-- ***************************************************8



PACKAGE eight_bit_int IS SUBTYPE BYTE IS INTEGER RANGE -128 TO 127; TYPE ARRAY_BYTE IS ARRAY (0 TO 3) OF BYTE; END eight_bit_int;



LIBRARY work; USE work.eight_bit_int.ALL;



LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.std_logic_arith.ALL;



ENTITY CORDIC IS PORT (Clk_50MHz : IN STD_LOGIC; x_in, y_in : IN BYTE; r, phi, eps : OUT BYTE); END CORDIC;


-- **************************************************


Niby rozumiem, ale dlaczego jak zamieniam to na schemat to wejście i wyjście to np: x_in(0:6). Dlaczego skoro jest od -128 do 127 to ma tylko



7 bitów, a nie 8???! Przecież to jest 255 wartości...


Czy mógłby mi ktoś podpowiedzieć jak to zrobić by połączyć to z układem, który ma na wyjściu STD_LOGIC_VECTOR(7 DOWNTO 0).? Mogę zmienić wyjście ewentualnie w tamtym układzie.



Jednak ten układ łączy się z układem który na wejściu ma IN(7:0). Mam problem z tym typem BYTE. Najchętniej bym go zamienił na STD_LOGIC_VECTOR. Gdy próbuje zamienić i zamiast BYTE dać STD_VECTOR_LOGIC(0 TO 7) dla wejść i wyjść. Następnie sygnały dać STD_VECTOR_LOGIC (0 TO 3). To mam masę błędów np. r <= x(3) jest zle.


Proszę o jakas podpowiedź, bo jestem początkujący. Nie idę na łatwiznę. Już trochę zrobiłem, najgorzej, że muszę to co sam napisałem połączyć z tym kodem.



Prosze o pomoc.


Wklejam cały kod tego układu, jeśli ma to znaczenie:


PACKAGE eight_bit_int IS SUBTYPE BYTE IS INTEGER RANGE -128 TO 127; TYPE ARRAY_BYTE IS ARRAY (0 TO 3) OF BYTE; END eight_bit_int;



LIBRARY work; USE work.eight_bit_int.ALL;



LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.std_logic_arith.ALL;



ENTITY CORDIC IS PORT (Clk_50MHz : IN STD_LOGIC; x_in, y_in : IN BYTE; r, phi, eps : OUT BYTE); END CORDIC;



ARCHITECTURE Behavioral OF CORDIC IS SIGNAL x, y, z : ARRAY_BYTE; BEGIN



PROCESS BEGIN WAIT UNTIL Clk_50MHz = '1'; r <= x(3); phi <= z(3); eps <= y(3); IF y(2) > 0 THEN x(3) <= x(2) + y(2) /4; y(3) <= y(2) - x(2) /4; z(3) <= z(2) + 14; ELSE x(3) <= x(2) - y(2) /4; y(3) <= y(2) + x(2) /4; z(3) <= z(2) - 14; END IF; IF y(1) > 0 THEN x(2) <= x(1) + y(1) /2; y(2) <= y(1) - x(1) /2; z(2) <= z(1) + 26; ELSE x(2) <= x(1) - y(1) /2; y(2) <= y(1) + x(1) /2; z(2) <= z(1) - 26; END IF; IF y(0) > 0 THEN x(1) <= x(0) + y(0); y(1) <= y(0) - x(0); z(1) <= z(0) + 45; ELSE x(1) <= x(0) - y(0); y(1) <= y(0) + x(0); z(1) <= z(0) - 45; END IF; IF x_in > 0 THEN x(0) <= x_in; y(0) <= y_in; z(0) <= 0; ELSIF y_in > 0 THEN x(0) <= y_in; y(0) <= - x_in; z(0) <= 90; ELSE x(0) <= - y_in; y(0) <= x_in; z(0) <= - 90; END IF; END PROCESS;



END Behavioral;


W dniu 26.05.2011 21:20, Piotr pisze:

Zmusza Cię ktoś do używania VHDL?

Czym zamieniasz na schemat?

TO_INTEGER(SIGNED(jakis_wektor)) - robi integer z vectora std_logic_vector(jakiś_integer,rozmiar_wektora) - w 2 stronę

google+powyższe.

Dziękuję. Już sobie poradziłem z tym problemem. Błąd leżał w zakresie integer'a. Nie może być tak, że łącze wyjsce vectorowe z wejściem integer i integer ma mniejszy zakres niż można zapisać na vectorze i odwrotnie. Teraz działa i chyba o to chodziło.

Pozdrawiam serdecznie

W dniu 27.05.2011 18:08, Piotr pisze:

Namieszałeś: Nie można 'łączyć' w ogóle różnych typów. Żeby je połączyć musisz dokonać konwersji. Zazwyczaj jest to konwersja do vectora - wtedy musisz zapewnić odpowiednie rozmiary, ale nic nie stoi na przeszkodzie, żeby zrobić:

signal a : std_logic_vector(3 downto 0); signal b : std_logic_vector(4 downto 0);

b <= a&"0";

b <= "0"&a;

b(3 downto 0) <= a;

b(4 downto 1) <= a;

a <= b(3 downto 0);

etc.

No bo VHDL czy Verilog są językami opisu sprzętu, a nie językami programowania i nie można łączyć tradycyjnego myślenia o zmiennych, stałych, liczbach z tym co sie projektuje. Projektuje się schemat na TTL-ach rozpisany w równania.

W dniu 28.05.2011 13:49, Lelek@ pisze:

Imo zmienne, stałe i liczby są całkiem zgodne z intuicją programisty. Natomiast myślenie tak o sygnałach jest pierwszym krokiem do kłopotów...

W dniu 2011-05-28 19:46, Michoo pisze:

Kontrola typów jest bardzo restrykcyjna i niezbyt przez to zgodna z intuicją programisty.

No tak ale to przegięcie, że w jednym procesie nie można dać (CLK'event and CLK='1') oraz (CLK'event and CLK='0') czyli, że nie można najpierw coś zrobić na zboczu narastającym a później coś innego na opadającym.

W dniu 28.05.2011 20:41, Mario pisze:

Można. Na kilku architekturach, które obsługują pracę na 2 zboczach ;)

Oczywi¶cie, ¿e mo¿na. Musisz popatrzeæ w makra od celek jak siê to robi dla twojej architektury i zrobiæ normalne "instantiate" Nie mo¿na mówiæ o czym¶ najpierw czy pó¼niej na innym zboczu. Ty nie wykonujesz programu tylko syntetyzujesz logikê, sprawdzaj±æ co pewien czas jaki wychodzi z schemat z twojego kodu. To jest piêkne. Wszystko odbywa siê równolegle.

Stawiasz dwa D flip-flopy i masz dwa niezale¿ne "uk³ady scalone" w jednej logice ale taktowane tym samym zegarem. Do FPGA trzeba sie przyzwyczaiæ i zacz±æ my¶leæ inaczej ni¿ przy programowaniu.

Musisz sobie zdawaæ sprawê, ¿e jak masz 2 procesy nawet z tego samego zegara, podobne to dane na ich wyj¶ciach czy na wej¶ciach Df-f nie musz± wcale byæ w tej samej chwili i s± podatne na setup time czy hold time violations. Musisz sobie zdawaæ sprawê, ¿e do procesu clk'event nie mo¿esz doprowadziæ niezsynchronizowanych sygna³ów bo ci ich ten Df-f nie bedzie widzia³ albo generowa³ hazardy zamiast tego co oczekujesz.

W dniu 2011-05-28 23:02, Lelek@ pisze:

No ja wiem że w sensie topologii to jest równoczesne. W sensie przetwarzania sygnałów jest to dla mnie po kolei

Jakoś sobie poradziłem dwoma niezależnymi procesami. Ale różnych komunikatów, że się nie da zsyntezować, było po drodze sporo :)

Dopiero z tym zaczynam na Spartan 3. Stanowczo bardziej intuicyjne dla mnie wydaje się pisanie w C czy asm.

W dniu 2011-05-28 10:38, Michoo pisze:

Nie chodzilo mi o to, zeby polaczyc tak "bezposrednio". Dalej niestety nie wiem czemu to nie dziala. Nie zamieszczam calego kodu. Tylko to co jest zle. :(

entity IntegerNaVector is port ( we: in integer range 128 downto -127; wy: out std_logic_vector(7 downto 0)); end entity IntegerNaVector;

W procesie w architecture mam:

wy <= std_logic_vector(conv_signed(we, 8)); -- zle :(

Nie udalo mi sie tego w zaden sposob ominac. Port "we" na schemacie graficznym ma bity 0:6 - czyli 7 bitów. Nie wiem dlaczego tak jest. :( Przeciez to jest 256 wartosci. :(

Pozdrawiam Piotr

W dniu 2011.05.29 06:14, Piotr pisze:

Tak naprawdę, to jest to 255 wartości, ale w typowym zapisie U2, to to będzie 9 bitów :)... powinieneś dać 127 downto -128. Choć oczywiście to nie wyjaśnia ani nie rozwiązuje problemu. W tym Ci nie pomogę, bo to powód, dla którego przestałem lubieć VHDLa na rzecz Veriloga ;)...

Tutaj przydałby się cały kod tego modułu. Nie wiemy jakie biblioteki dołączyłeś - signed | unsigned? No i tak jak kolega Konop napisał 128 w U2 to jest liczba 9-bitowa :)

Poza tym zachęcam w definicji portów do używania typów std_logic, ewentualnie record lub array ale składających się z std_logic, wszelkie konwersje wewnątrz komponentów!!! Nie utrudniajmy pracy syntezerom.

Pozdrawiam,

Jerzy Gbur

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required