[vhdl] Dlaczego mi wciąga tyle makroceli

Poniższy "kod" wciąga mi 76 makroceli w CPLD, dlaczego tak się dzieje? Praktycznie to są 2 multipleksery, jeden licznik 17 bitowy i rejestr przesuwny też 17 bitowy, wydawało mi się że max. ok 40 makrocel pujdzie a tu taka niespodzianka.

entity main is

Port (

M_CLK : in STD_LOGIC; DATA_CLK : in STD_LOGIC; DATA_IN: in STD_LOGIC; MEM_C : in STD_LOGIC; DIAG0 : out STD_LOGIC; ADDR_1: out STD_LOGIC_VECTOR (16 downto 0); ADDR_2: out STD_LOGIC_VECTOR (16 downto 0); DATA_1: inout STD_LOGIC_VECTOR (7 downto 0); DATA_2: inout STD_LOGIC_VECTOR (7 downto 0); DATA_OUT: out STD_LOGIC_VECTOR (7 downto 0) );

end main;

architecture Behavioral of main is

signal counter: STD_LOGIC_VECTOR (16 downto 0); signal addr_shift_reg: STD_LOGIC_VECTOR (16 downto 0);

begin

ADDR_1 <= counter when MEM_C='1' else addr_shift_reg; ADDR_2 <= counter when MEM_C='0' else addr_shift_reg; DATA_OUT <= DATA_1 when MEM_C='1' else DATA_2;

process(M_CLK) begin

if (M_CLK'event and M_CLK='1') then counter<=counter+1; end if;

end process;

process(DATA_CLK) begin

if (DATA_CLK'event and DATA_CLK='1') then

addr_shift_reg<=addr_shift_reg(15 downto 0)&DATA_IN;

end if;

end process;

end Behavioral;

Reply to
Maksymilian Dutka
Loading thread data ...

obejrzyj sobie schemat RTL to zrozumiesz dlaczego, i co zrobic by bylo mniej

Reply to
Greg(G.Kasprowicz

Greg(G.Kasprowicz) pisze:

Obadam go dokładnie dziś wieczorem, ale wczoraj jak zerknąłem to wyglądało tak jakby na wyjściach były przerzutniki, tylko nie bardzo wiem jak się ich pozbyć...

Reply to
Maksymilian Dutka

A jakie konkretnie cpld ? Bo mam wrazenie ze w tych multiplekserach klopot:

Czy przypadkiem w tej architekturze zeby zmienic zrodlo danych dla pinu nie trzeba poswiecic jednej makroceli ?

J.

Reply to
J.F.

Próbuje to upchać w XC9572.

Reply to
Maksymilian Dutka

Czyli wlasnie to. Pin IO masz przylaczony "na stale" tylko do jednej makroceli, i jesli ma przelaczac miedzy dwoma rejestrami .. to potrzebujesz dodatkowe makrocele na te rejestry. Bo ta podlaczona do IO bedzie tylko multiplekserem.

No chyba ze oba zegary sa w miare synchroniczne, wtedy mozna sprobowac zaszalec - dac dwa rejestry wyjsciowe, ktore w zaleznosci od MEM_C beda pelnily funkcje rejestru szeregowego lub licznika.

J.

Reply to
J.F.

niedobrze :(

Chce podłączyć do CPLD 2xSRAM. Do jednej kostki SRAM po interfejsie szeregowym uC będzie wpisywał dane, z drugiej CPLD ma je wypluwać w danym tempie (do wyświetlacza LCD). W dowolnej chwili pamięci mają być zamienione miejscami. Może jakoś inaczej udało by się to rozwiązać?

Jeżeli nie to pewnie jakieś TTL-e będę musiał dołożyć do CPLD...

Reply to
Maksymilian Dutka

A nie wystarczy ci czasu zeby byla tylko jedna kostka i pomiedzy odczytami dokonywac wpisy i ?

Nie ma sensu - w ogolnosci to uzyj wiekszej kostki.

A w szczegolnosci .. architektura na oko pozwala zrealizowac to co pisze powyzej, tylko jak to zapisac, zeby VHDL poprawnie zintepretowal i zrealizowal ...

cos takiego mi chodzi: if (MEM_C='0') then if (M_CLK'event and M_CLK='1') then rej1<=rej1+1; else if (DATA_CLK'event and DATA_CLK='1') then rej1 <= rej1(15 downto 0)&DATA_IN;

a dla drugiego if (MEM_C='1') then if (M_CLK'event and M_CLK='1') then rej2<=rej2+1; else if (DATA_CLK'event and DATA_CLK='1') then rej2 <= rej2(15 downto 0)&DATA_IN;

Jeszcze kwestia zeby przelaczyc w odpowiednim momencie jak nowa ramka bedzie .. albo dolozyc do powyzszego przepisanie biezacej wartosci licznika. Uprzedzam ze PT moze zabraknac.

A ten zegar z procka nie jest przypadkiem duzo wolniejszy ? Moze da sie to zrobic jako automatr synchroniczny na M_CLK ?

J.

Reply to
J.F.

Nie, bo chce żeby obraz generował AVR, niestety zbyt szybko tego robić nie będzie, gdyby pisał po "aktywnej" pamięci to na wyświetlaczu by było widać jak obraz jest przerysowywany, a tak to sobie na spokojnie narysuje wszystko co trzeba w drugiej pamięci.

W drodze jest FPGA, ale jakby udało mi się to zrobić na CPLD które kosztuje kilka razy mniej to by było dobrze.

Jak będę w domu to będę próbował.

To już nie problem

Jest,

Próbowałem ale nie powodowało to oszczędności.

Reply to
Maksymilian Dutka

J.F. pisze: > On Thu, 06 Dec 2007 11:24:57 +0100, Maksymilian Dutka wrote: >> J.F. pisze: >>> No chyba ze oba zegary sa w miare synchroniczne, wtedy mozna sprobowac >>> zaszalec - dac dwa rejestry wyjsciowe, ktore w zaleznosci od MEM_C beda pelnily funkcje rejestru szeregowego lub licznika. >> Chce podłączyć do CPLD 2xSRAM. Do jednej kostki SRAM po interfejsie szeregowym uC będzie wpisywał dane, z drugiej CPLD ma je wypluwać w danym tempie (do wyświetlacza LCD). >

Nie, bo chce żeby obraz generował AVR, niestety zbyt szybko tego robić nie będzie, gdyby pisał po "aktywnej" pamięci to na wyświetlaczu by było widać jak obraz jest przerysowywany, a tak to sobie na spokojnie narysuje wszystko co trzeba w drugiej pamięci.

W drodze jest FPGA, ale jakby udało mi się to zrobić na CPLD które kosztuje kilka razy mniej to by było dobrze.

Jak będę w domu to będę próbował.

To już nie problem

Jest,

Próbowałem ale nie powodowało to oszczędności.

Reply to
Maksymilian Dutka

Moze rysowac pod innym adresem. a potem pyk .. i pobieramy dane z innego obszaru. A linii 16 jednak ubywa..

A tu koledzy mowili ze FPGA potanialo i sie nie oplaca CPLD :-) Ale takie np 95108 ?

Ewentualnie - moze to podziel na dwa 9572.

Wydaje mi sie ze jednak pewien problem :-)

Ale ja w kwestii powyzszego pomyslu - to sporo zmienia jesli mozemy jeden zegar uzyc.

J.

Reply to
J.F.

(...)

Z tym że wtedy pasowało by zrobić jakieś FIFO, poza tym ciężko kupić szybką pamięć SRAM, ale nie wykluczam takiego rozwiązania.

Już jest dosyć duży skok cenowy..

Chyba wolę jakąś prostą logikę w postaci TTL dodać.

(...)

jak licznik będzie mi wskazywał zero i będzie żądanie przełączenia pamięci no to siup.

Na pewno główny będzie z 10 razy szybszy niż ten do komunikacji z uC.

Reply to
Maksymilian Dutka

Tak nie bardzo widze potrzebe - jesli czasu pomiedzy odczytami starcza, a zapisy masz rzadkie.

Ja o ambitniejszym myslalem - w dowolnym momencie. Wietrze pare problemow :-)

J.

Reply to
J.F.

W sensownej cenie to są SRAM-y 70nS, co 166nS trzeba wysyłać dane do LCD, tak że z czasami jest prawie "na styk". Można by też wsadzić DRAM-y, ale to już za duże komplikacje jak na CPLD

Częściej to nie bardzo by się dało: część ekranu by była z jednej pamięci część z drugiej, podejrzewam że było by widać mrugnięcie.

Reply to
Maksymilian Dutka

Korzystając z porad J.F., (za co Mu dziękuje) zrobiłem coś co się mieści w 43 makrocelach.

entity main is

Port ( M_CLK : in STD_LOGIC; DATA_CLK : in STD_LOGIC; DATA_IN: in STD_LOGIC; MEM_C : in STD_LOGIC; ADDR_1: out STD_LOGIC_VECTOR (16 downto 0); ADDR_2: out STD_LOGIC_VECTOR (16 downto 0); DATA_1: in STD_LOGIC_VECTOR (7 downto 0); DATA_2: in STD_LOGIC_VECTOR (7 downto 0); DATA_OUT: out STD_LOGIC_VECTOR (7 downto 0) ); end main;

architecture Behavioral of main is

signal rej1: STD_LOGIC_VECTOR (16 downto 0); signal rej2: STD_LOGIC_VECTOR (16 downto 0); signal last_data_clk: STD_LOGIC;

begin

ADDR_1<=rej1; ADDR_2<=rej2;

DATA_OUT <= DATA_1 when MEM_C='1' else DATA_2; process(M_CLK) begin if(M_CLK'event and M_CLK='1') then

if (MEM_C='0') then rej1<=rej1+1; if(last_data_clk = not DATA_CLK) then rej2<=rej2(15 downto 0)&DATA_IN; last_data_clk <= DATA_CLK; end if; else rej2<=rej2+1; if(last_data_clk = not DATA_CLK) then rej1<= rej1(15 downto 0)&DATA_IN; last_data_clk <= DATA_CLK; end if; end if; end if;

end process; end Behavioral;

Reply to
Maksymilian Dutka

To ci bedzie chyba na obu zboczach zegara przesuwalo .. czy to moze nawet lepiej ?

J.

Reply to
J.F.

Chyba lepiej, w każdym razie prościej w CPLD, a uC sobie z tym poradzi.

Reply to
Maksymilian Dutka

w CPLD to trudniej. potrzebnych PT przybywa. Ale skoro sie miesci to nie ma co oszczedzac :-)

Przy softwareowym wysylaniu chyba nawet lepiej.

J.

Reply to
J.F.

No właśnie dodałem generowanie reszty sygnałów dla LCD, i znowu sie nie mieści ;(, ale tym razem nie podoba mu się że mam tyle i/o, chodź pinów starcza...

Ale z tym to już sobie jakoś poradzę.

Reply to
Maksymilian Dutka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.