Maciej G.

Maciej G. Projektant /
Programista, Famor
S.A.

Temat: ElbertV2 - problem z zegarem z IPCore - PLL

Witam,

ponieważ potrzebowałem szybszego zegara niż znajduje się na płytce Elbert V2 (12 MHz) - zewnętrzny generator kwarcowy postanowiłem użyć IPCore (ISE Webpack 14.7) "Single DCM_SP" dla Spartan 3A. Patrz obrazek:

http://www.dropbox.com/s/5jjenuc71ui5xbs/IPCore_PLL.pn...

Oczywiście wcześniej utworzyłem nowy projekt w ISE Webpack.

Gdy otworzyły się okna do ustawiania parametrów IP Core, wybrałem następujące opcje (patrz obrazki):

https://www.dropbox.com/s/23zw9f09mxh083f/ClockWiz1.png...

https://www.dropbox.com/s/fsmrrfa2emigyyt/ClockWiz2_.pn...

Środkowy ekran z parametrami (opcje buforów) zostawiłem domyślnie. Częstotliwość wyjściową pętli PLL ustawiłem na 16 MHz.

Gdy IP Core się wygenerował wszedłem na wygenerowany template VHDL dla pętli pll i wkleiłem kod do projektu:

https://www.dropbox.com/s/j4qiodxwu8sjfur/ISE_PLL_Proj....

Oto główny plik projektu (projekt.vhd):


library IEEE;
library UNISIM;
use IEEE.STD_LOGIC_1164.ALL;
use UNISIM.VComponents.all;

entity projekt is
Port ( clk : in STD_LOGIC;
rst : in STD_LOGIC;
clkSynth : inout STD_LOGIC;
clkout : out STD_LOGIC);
end projekt;

architecture Behavioral of projekt is

COMPONENT pll
PORT(
CLKIN_IN : IN std_logic;
RST_IN : IN std_logic;
CLKFX_OUT : OUT std_logic;
CLKIN_IBUFG_OUT : OUT std_logic;
CLK0_OUT : OUT std_logic;
CLK0_OUT1 : OUT std_logic
);
END COMPONENT;
component divider is
Port ( clk : in STD_LOGIC;
clk_out : inout STD_LOGIC := '0');--clk_out 1MHZ
end component;
signal clkBuf : STD_LOGIC;
signal clkPLL : STD_LOGIC;
signal clkO1 : STD_LOGIC;

begin

zegar : pll PORT MAP(
CLKIN_IN => clk,
RST_IN => rst,
CLKFX_OUT => clkPLL,
CLKIN_IBUFG_OUT => clkBuf,
CLK0_OUT => clkout,
CLK0_OUT1 => clkO1
);
dzielnik : divider port map (clkPLL, clkSynth); --2MHz clock out

end Behavioral;



Tutaj kod dzielnika częstotliwości(divider.vhd):


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;

entity divider is
generic (
NBit : natural := 25;
Div : natural := 16_000_000
);
Port ( clk : in STD_LOGIC;
clk_out : inout STD_LOGIC := '0');
end divider;

architecture divider_arch of divider is

signal cnt: std_logic_vector(Nbit -1 downto 0) := (others=>'0');

begin

process(clk)
begin
if (clk'event and clk='1') then
if cnt < Div then
cnt <= cnt+1;
else
cnt <= (others=>'0');
clk_out <= not clk_out;
end if;
end if;
end process; end divider_arch;



A tutaj plik ucf dla projektu:


NET "clk" LOC = "P129" | PERIOD = 12MHz;
NET "rst" LOC = "P80" | PULLUP;
NET "clkSynth" LOC = "P46"; //LED
NET "clkout" LOC = "P11";


Tutaj zamieszczam cały kod projektu "ISE Webpack":

https://www.dropbox.com/s/dk6ywxybuo2tvns/PLL1.zip?dl=0

Problem polega na tym, że nie mogę obejrzeć na oscyloskopie, czy analizatorze stanów logicznych (ten drugi pasmo do 100MHz) wygenerowanego z pętli PLL zegara (dzieliłem go także na dzielniku częstotliwości przez różne wartości) widzę tylko bardzo cienki "szpilki co jakiś czas. Dałem też zegar z pętli PLL na dzielnik, a po nim na rejestr przesuwny z wyjściami na 8 LED (bez pętli PLL ten projekt działa poprawnie).

Zmieniałem piny wyjściowe w Elbercie, kombinowałem z różnymi parametrami dla generacji IP Core - wszystko bez żadnego rezultatu.

Macie może jakieś pomysły co robię nie tak ?

Na "Maximatorze" z "Max10" Altery IP core z pętlą PLL działa (chociaż przebiegi są mocno odkształcone). Siedzę nad tym problemem już drugi dzień i powoli kończą mi się pomysły.

PozdrawiamTen post został edytowany przez Autora dnia 28.12.17 o godzinie 11:28
Maciej G.

Maciej G. Projektant /
Programista, Famor
S.A.

Temat: ElbertV2 - problem z zegarem z IPCore - PLL

Cześć,

problem już rozwiązany - czasem aż wstyd się przyznać jakie człowiek robi błędy. Przy generacji IP Core pętli PLL zaznaczyłem sygnał RESET (aktywny poziomem wysokim). Na push-buttonie w Elbercie bez wciśnięcia jest 1 logiczna i pętlaPLL była ciągle resetowana - to był powód nie działania projektu ;)

Pozdrawiam
Jakub Tyburski

Jakub Tyburski Asystent dydaktyczny
- Wojskowa Akademia
Techniczna w War...

Temat: ElbertV2 - problem z zegarem z IPCore - PLL

Zdarza się :) Aż mi przypomniałeś jedne zajęcia przed świętami ze studentami, gdzie też popełnili taki błąd i metodą eliminacji kolejnych przeszkód po ponad godzinie doszliśmy do tego :) W każdym razie spokojnie jak na wojnie i ważne że działa :)
Maciej G.

Maciej G. Projektant /
Programista, Famor
S.A.

Temat: ElbertV2 - problem z zegarem z IPCore - PLL

Cześć Jakub,

miło Cię znów usłyszeć. Dzięki petli PLL mam na Elbercie PicoBlaze działający z zegarem 120Mhz (czyli teoretycznie 60 MIPS'ów - prosty program w assemblerze do mrugania diodą LED na razie)

Chcę metodą praktyczną ustalić max. zegar z jakim na Elbercie PicoBlaze będzie działał. Taki mam pomysł - patrz link na Forbot.pl, gdzie opisałem ten pomysł (mam nick "FlyingDutch"):

https://www.forbot.pl/forum/topics51/picoblaze-z-jaka-m...

Pewnie jesteś w stanie podać dużo lepszą procedurę testową ;)

Cieszę się bardzo bo gwiazdor przyniósł mi jako prezent pod choinkę zestaw "Mimas V2" (NumatoLab ze Spartanem 6):

https://docs.numato.com/doc/mimas-v2-spartan-6-fpga-dev...

Pozdrawiam
Jakub Tyburski

Jakub Tyburski Asystent dydaktyczny
- Wojskowa Akademia
Techniczna w War...

Temat: ElbertV2 - problem z zegarem z IPCore - PLL

Uzyskasz taką częstotliwość na jaką pozwala sam Spartan jeśli chodzi o same zegary :) Ot cała odpowiedź (w końcu tu jest taka dowolność implementacji, że można kombinować z rozstawem elementów i zmniejszaniem na takim Chip Planerze opóźnień na ścieżkach między danymi zasobami, a tym samym podbijaniem częstotliwości pracy). W dokumentacji podadzą ci, że np: 400 MHz wyciągniesz w układzie (tj. Spartanie), a w praktyce zapewniam cię, że wyciągniesz więcej (tak jak kiedyś robili testy w mym zakładzie na uczelni z niektórymi układami Xilinxa - w jednym przypadku udało się bez problemu wpuścić sygnał 800 MHz, choć po przejściu był on mocno zniekształcony i o niskiej amplitudzie - mimo to jednak o dziwo wszystko działało bez problemu!). Oczywiście wiem, że taki mikroprocek nie wykonuje poleceń wyłącznie przez jeden takt zegara,a przez wiele i nie będzie pracował z częstotliwością 800 MHz, gdyby taki sygnał przechodził przez Spartana. Niemniej jeśli się weźmie pod uwagę, że taki sygnał przejdzie, to
sumaryczna częstliwość procka też będzie coś koło tego , tylko niższa (np z 600 czy 700). Dlatego też możesz nawet odpuścić pętlę i zapiąć śmiało jakikolwiek generator funkcyjny (będziesz miał znacznie rzetelniejszą odpowiedź). Przy okazji zobaczysz jak sobie radzi układ i procek ze zniekształceniami zegara (czy jest stabilny wtedy czy jednak wymaga precyzyjnych źródeł, co też jest bardzo ważne, choć nie wiem czemu ignorowane). Co do programu testowego - mnie to uczyli, że się dąży do "zamulenia" jakichkolwiek procesorów, a więc najlepiej je obciążyć instrukcjami, które najdłużej się wykonują i jest ich najwięcej (tylko problem jest z ustaleniem takich instrukcji, a tym samym napisaniem stosownego kodu pod to). Tym samym polecam zacząć od sprawdzenia czasu wykonywania poszczególnych instrukcji i wyciągnięcia z tego wniosków (kto wie - może się okaże, że starczą w zupełności pętle for lub while, których mnie uczyli jako najuniwersalniejszy środek "zamulania" procków). Niemniej od biedy moożesz tak naprawdę pisać dowolne programy testowe - np: możesz robić jak w jednym programie (nie pamiętam jednak nazwy), że zmusza się procek do liczenia nie wiadomo jakiego rozwinięcia dziesiętnego liczby pi (pomysł z generatorem CRC też nie jest zły i można zastosować). Możesz też równie dobrze jakiś atak brute-force zrobić i przygotować pod to hasło, aby się męczył taki układ (tak naprawdę to sam się jak dotąd nie spotkałem z jakimś poważanym, uniwersalnym testem szybkości na jakiekolwiek procki - ale to właśnie dlatego, że w jednym np: dodawanie liczb wykona ci się w 5 taktów zegara, a w drugim w 10 i obiektywizm jest mocno zachwiany). I tyle :D Co do jeszcze obaw, że przestanie wyświetlać wyniki - nic nie szkodzi - po prostu będziesz próbował cokolwiek ustalić z poziomu oscyloskopu i już (metoda spartańska, ale nie niewykonalna! Poza tym w ten sposób będziesz miał wiedzę czy problemem jest zegar, że już jest mocno zniekształcony, czy też po prostu to, że są takie opóźnienia na wejściach z instrukcjami, że po prostu procek się nie wyrabia :D wtedy byś miał przy okazji odpowiedź ile instrukcji wchodzi maksymalnie, a tym samym jaka jest ostateczna częstotliwość takiego procka na Spartanie. Musiałbyś tylko wyprowadzić stosowne wyjścia z płytki wtedy i zapiąć się pod nie). Pamiętaj też, że taki procek zaimplementujesz w innym układzie FPGA to też będzie miał inne częstotliwości! :D Więc ciężko w zasadzie o obiektywizm i odniesienie tego tylko do samego procka (trzeba podać jakie FPGA zostało użyte do jego implementacji!) :DTen post został edytowany przez Autora dnia 28.12.17 o godzinie 16:22
Maciej G.

Maciej G. Projektant /
Programista, Famor
S.A.

Temat: ElbertV2 - problem z zegarem z IPCore - PLL

Jakub,

dzięki za wyczerpującą odpowiedź.

Pozdrawiam

Następna dyskusja:

Maximator - problem z sygna...




Wyślij zaproszenie do