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;

do góry

W dniu 26.05.2011 21:20, Piotr pisze:
> Witam!
>
> Mam straszny problem z VHDL'em. Potrzebuje połączyć pewne klocki.
Zmusza Cię ktoś do używania VHDL?

> 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...
Czym zamieniasz na schemat?

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

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

google+powyższe.

--
Pozdrawiam
Michoo

do góry

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

do góry

W dniu 27.05.2011 18:08, Piotr pisze:
> 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.
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.

--
Pozdrawiam
Michoo

do góry

"Michoo" <m...@v...pl> wrote in message
news:irqcai$fl1$1@news.onet.pl...
>W dniu 27.05.2011 18:08, Piotr pisze:
>> 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.
> Namieszałeś:
> Nie można 'łączyć' w ogóle różnych typów. Żeby je połączyć musisz

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.

do góry

W dniu 28.05.2011 13:49, Lelek@ pisze:
> 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.
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...

--
Pozdrawiam
Michoo

do góry

W dniu 2011-05-28 19:46, Michoo pisze:
> W dniu 28.05.2011 13:49, Lelek@ pisze:
>> 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.
> Imo zmienne, stałe i liczby są całkiem zgodne z intuicją programisty.

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

> Natomiast myślenie tak o sygnałach jest pierwszym krokiem do kłopotów...

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.


--
Pozdrawiam
MD

do góry

W dniu 28.05.2011 20:41, Mario pisze:
> 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.
Można. Na kilku architekturach, które obsługują pracę na 2 zboczach ;)

--
Pozdrawiam
Michoo

do góry

"Mario" <m...@p...onet.pl> wrote in message
news:irrflv$vsc$1@news.onet.pl...

>
>> Natomiast myślenie tak o sygnałach jest pierwszym krokiem do kłopotów...
>
> 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.

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.

do góry

W dniu 2011-05-28 23:02, Lelek@ pisze:
>
> "Mario" <m...@p...onet.pl> wrote in message
> news:irrflv$vsc$1@news.onet.pl...
>
>>
>>> Natomiast myślenie tak o sygnałach jest pierwszym krokiem do kłopotów...
>>
>> 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.
>
> 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.

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

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

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

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

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

--
Pozdrawiam
MD

do góry