Przestrajany generator sygnału prostokątnego FPGA

[kaamil115]

Witam,

Jak w tytule usiłuję zrealizować przestrajany generator sygnału prostokątnego, czyli nic innego jak dzielnik częstotliwości wzorcowej ze zmienną wartością dzielnika. Poniżej przedstawiam kod VHDL. Niestety po zaimplementowaniu go do maximatora nie działa. Byłbym wdzięczny za każde konstruktywne sugestie. Po wgraniu kod powinien generować sygnał wyjściowy o mniejszej częstotliwość co pół okresu (sygnał wzorcowy 400MHz).

Kod: Zaznacz cały

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity    DIVIDER_2 is

port(
clk:     in STD_LOGIC;
O    :     out STD_LOGIC
);

end DIVIDER_2;

   
architecture DIVIDER_2 of DIVIDER_2 is   
   
   signal divider: integer range 0 to 20000:=666;      -- USTAWIAMY DZIELNIK
   signal counter: integer range 0 to 2000:=0;   
   signal OI : STD_LOGIC;
   
   begin
   O <= OI;
   
   process (clk) is 
   
      begin
      if rising_edge (clk) then
      
         if (counter < divider) then
         counter <= counter + 1;
         else
         OI <= not OI;
         counter <= 0;
         divider <= divider + 1;
         end if;
      
      end if;
   
   end process;

end DIVIDER_2;

07161a34d94af.png

Pozdrawiam,
Kamil

[Antystatyczny]

A w jakim celu zwiększasz wartość dzielnika? Chodzi mi o wiersz "divider <= divider + 1;"

[kaamil115]

No właśnie chodzi mi to o to przestrajanie, to znaczy co pół okresu ma zmniejszyć częstotliwość. Docelowo wartość dzielnika wynikała by z pewnego pomiaru. Ale w tak prostym przypadku nie działa.

[Antystatyczny]

Zgadza się, nie działa... Nie działa, bo za każdym razem, gdy wykryjesz zbocze na wejściu, testujesz, czy licznik jest mniejszy od dzielnika. Jeśli nie jest mniejszy, oddalasz się od spełnienia warunku, bo inkrementujesz dzielnik. Wywal ten wiersz, o którym wspomniałem i wtedy sprawdzisz, czy sam dzielnik częstotliwości działa. Przestrajania nie uzależniałbym od impulsów wejściowych ( w ten sposób), bo to zwyczajnie nie ma sensu. Licznik impulsów wejściowych goni dzielnik... i nigdy nie dogoni.

[kaamil115]

Jak to goni, przecież na początku inicjalizowany jest pewną wartośćią. Spełniony jest pierwszy warunek, zatem inkrementuje licznik aż nie osiągnie wartości inicjalizującej dividera (666), warunek nie jest już spełniony przechodzi do elsa zeruje licznik, neguje wyjście oraz wrzuca nową wartość większą o jeden dzielnika?

Bez tego wiersza o którym wspominasz, dzielnik działa na stałą częstotliwość, a chodzi mi tu o możliwość jej zmiany z każdym okresem/półokresem sygnału wyjściowego.

[Antystatyczny]

Jeśli licznik jest mniejszy od dzielnika, inkrementuj licznik. W przeciwnym wypadku zaneguj wyjście, zresetuj licznik i zwiększ wartość dzielnika. No tak, mój błąd w myśleniu. W takim razie kod wygląda na poprawny. Co masz dokładnie na myśli pisząc, że nie działa? Masz na wyjściu jakikolwiek przebieg?

[kaamil115]

No właśnie bez linii kody inkrementującej dzielnik wszystko działa jak trzeba, stabilny przebieg o stałej częstotliwości. Jeśli jednak mamy inkrementację dzielnika na wyjściu wyskoczy kilka impulsów o nieregularnej długości potem sygnał wchodzi w stan wysoki (przebieg obserwowany na oscyloskopie).

[Antystatyczny]

A czy zmienne divider i counter nie powinny mieć takich samych dopuszczalnych zakresów?

[kaamil115]

Zmodyfikowałem, wciąż nie działa lecz z pewną różnicą. Przebieg z kanału 2 to nasze wyjście O:

2d94e97626434.png

Na początku kilka "dziwnych impulsów" następnie stan wysoki z jednostkowymi negacjami trwającymi około 1 cyklu zegarowego.

[Antystatyczny]

Z tym zakresem zmiennych zmierzam do tego, że divider może mieć wartość nawet 20000, a counter zaledwie 2000. Jeśli zmienna divider osiągnie wartość powyżej 2000, w jaki sposób counter ją dogoni? Counter dotrze do wartości 2000, a potem co? Wejdzie w stan saturacji, czy ulegnie przepełnieniu? Tej architektury zupełnie nie znam, więc nie wiem co się stanie. Rozumiem jednak, że każdy okres wyjściowy ma być "o jeden dłuższy" od poprzedniego.

[kaamil115]

Tak, rozumiem. Mój poprzedni post obrazuje sytuację w której wyrównałem obie wartości. Kod obecnie jest następujący:

Kod: Zaznacz cały

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity    DIVIDER_2 is

port(
clk:     in STD_LOGIC;
O    :     out STD_LOGIC
);

end DIVIDER_2;

   
architecture DIVIDER_2 of DIVIDER_2 is   
   
   signal divider : integer range 0 to 20000:=666;      -- USTAWIAMY DZIELNIK
   signal counter: integer range 0 to 20000:=0;   
   signal OI : STD_LOGIC;
   
   begin
   O <= OI;
   
   process (clk) is 
   
      begin
      if rising_edge (clk) then
      
         if (counter < divider) then
         counter <= counter + 1;
         else
         OI <= not OI;
         counter <= 0;
         divider <= divider + 1;
         end if;
      
      end if;
   
   end process;

end DIVIDER_2;

Oscylogram prezentuje moment startu więc wartość dividera < counter_max_value przez kilka-set półokresów inkrementacji.

[Antystatyczny]

Kod wygląda poprawnie... Tzn. nie widzę w nim jakichś błędów logicznych. Jedyne, do czego mógłbym się ewentualnie przyczepić, to brak wiedzy nt. zachowania się zmiennych w momencie osiągnięcia swych maksymalnych wartości. Nasycają się, czy przepełniają?

[kaamil115]

Wydaje mi się, że następuje przepełnienie.

[Antystatyczny]

Na wszelki wypadek spróbowałbym programowo zapętlić divider. Coś w stylu:

Kod: Zaznacz cały

if(divider > 19999) then
divider <= 0;
end if;


Aha, w takim kodzie nie brakuje nawiasów? W Twoim kodzie widzę zagnieżdżenie dwóch warunków i nie mam pewności, czy taka forma jest prawidłowo interpretowana. Pytam, bo nie znam tego języka (o ile mogę to tak określić).

[kaamil115]

W nawiasie zawierają się jedynie warunki, jeśli chodzi o instrukcje po then wykonywane są współbieżnie, a oddzielane średnikami.
Dodałem zerowanie dividera, w konsekwencji czego otrzymałem quasisinusoidalny przebieg 50MHz na wyjściu..

[Antystatyczny]

Dodałem zerowanie dividera, w konsekwencji czego otrzymałem quasisinusoidalny przebieg 50MHz na wyjściu..

Ok, czyli mniej więcej o to Ci chodziło?

[kaamil115]

Nie, chodzi mi o uzyskanie dzielnika częstotliwości wzorcowej, który mogę przestrajać co okres/półokres.
Czyli kod, który zamieściłem pierwotnie docelowo powinien wygenerować pierwszy puls o czasie trwania 666 zliczeń, kolejne odpowiednio: 667,668,669... czyli naprzemiennie stan wysoki i niski, liczby oznaczają ilość zboczy narastających 400MHz czyli 2.5ns * 666 idt.

[j23]

Kompletnie nie znam się na składni VHDL, ale czy dałoby radę w tym wypadku zrobić to tak, że powinna być pewna hierarchiczność przy kontroli tych zmiennych, tzn. zrobić jedną zmienną (nadrzędną, kontrolującą, bazową) do której pozostałe się odwołują. Do tej nadrzędnej (o największej wartości) powinna następować taka synchronizacja. To jest taki trochę problem i użycie algorytmu, który w "Symfonii C++" Pan Jerzy Grębosz opisywał wtedy kiedy pisał o synchronizacji trzech zegarów elektronowych, no i żeby te trzy zsynchronizować trzeba było użyć czwartego nadrzędnego jako synchronizatora. Nie wiem czy dobrze trafiłem z tą odpowiedzią.

[ZbeeGin]

Cóż. Przede wszystkim musimy sobie wyjaśnić jedno: VHDL to nie język programowania, tylko język opisu sprzętu. "Signal" to nie zmienna tylko nazwana grupa bitów, która na podstawie treści opisu behawioralnego (treści "architecture") może stać się: po prostu sygnałem, np. wyjściem jakiejś bramki lub magistralą, pojedynczym przerzutnikiem, zespołem przerzutników w formie rejestru zatrzaskowego, licznika lub rejestru przesuwającego.
Zmienne a sygnały to dwie różne rzeczy w języku VHDL. Stany "signal" zostaną zmienione współbieżnie ale w przypadku zmiany w bloku synchronicznym "process" dopiero po przejściu procesu i będzie obowiązywać ostatnie przypisanie. Zmienne zaś zmieniane są natychmiast w miejscu ich zmiany.

Jeśli chcesz przetestować dzielnik czy działa to nie robi się tego w sposób automagiczny, który sam sobie coś zmienia. Chcesz zrobić preskaler, którym będziesz przecież sterować z zewnątrz. Takie rzeczy robi się za pomocą odpowiednio napisanego testbencha. To w nim będziesz sobie zadawał wartości w osi czasu i obserwował jak zachowuje zaprojektowana struktura logiczna preskalera jeszcze na etapie projektowania. Robienie tego "na żywca" nie daje Ci żadnej możliwości przetestowania co tak naprawdę dzieje się wewnątrz i wyłapania błędów!

[kaamil115]

Witam, wypowiedź ZbeeGin nic a nic nie wniosła do analizy, nie posłużył się żadnymi przydatnymi wskazówkami. Udało mi się jednak znaleźć rozwiązanie problemu, może komuś kiedyś okaże się pomocne.

Kod: Zaznacz cały

process (clk) is
begin
   if rising_edge(clk) then  --generator
      licznik<= licznik + NCO_inkr;
      if (licznik(31) = '1') then
         ster <= '1';
      else
         ster <= '0';
      end if;
   end if;         
end process;

Rozwiązaniem problemu jest NCO, mamy licznik o rozdzielczości 32bitowej (2^32) inkrementujemy go wartością (NCO_inkr), wartość ta definiuje nam wartość częstotliwości sygnału wyjściowego (ster). W celu zadawania konkretnej częstotliwości wystarczy zmieniać wartość NCO_inkr.

[ZbeeGin]

Witam, wypowiedź ZbeeGin nic a nic nie wniosła do analizy, nie posłużył się żadnymi przydatnymi wskazówkami.

Masz prawo do własnego zdania, ale pewnie jeszcze nie raz "zatrzaśniesz" się nie dokonując symulacji i pojedziesz "na żywca". Testbench i symulacja przez stymulowanie jednostki projektowej to podstawa w "programowaniu" FPGA. Ende.

[piotrva]

400 MHz to nie za dużo?
Jakich portów IO używasz?
I popieram ZbeeGin - symulację i testbenche obowiązkowo.