Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.

atom1477 10 Jul 2021 22:32 1455 14
  • DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Jest to kontynuacja tego artykułu.

    No to jak zrobić te 500 GHz?
    Zacznijmy od błędów bloków DELAY, bo to one są kluczem do zwiększenia rozdzielczości.
    Teoretycznie taki blok powinien posiadać kroki co ileśtam ps.
    Np. co 20 ps.
    Czyli tak:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Każde kolejne ustawienie to suma poprzednich kroków, a więc coraz większe opóźnienie. Gdyby kroki były sobie równe, to były by to po prostu jednostajnie wzrastające schodki, tak jak na powyższym wykresie.
    Można też przedstawić kroki na innym typie wykresu. Pokazując ich rozmieszczenie w "czasie":
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Na razie nie widać tu nic ciekawego, bo kroki są sobie równe.
    W praktyce jednak nie są sobie równe. Jest jakiś rozrzut pomiędzy wartością każdego kroku, każdego bloku DELAY, jak i pomiędzy wszystkimi egzemplarzami FPGA.
    Narastanie wartości DELAY nie będzie już liniowe:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Rozmieszczenie wartości w "czasie" będzie więc wyglądało tak:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    I to są wartości dla jednego konkretnego bloku DELAY w konkretnym układzie FPGA. Inny układ będzie miał inne wartości. Inny blok w tym samym układzie FPGA też będzie miał inne wartości.
    Najważniejsze jest to, że pomiary wykazały że te wartości są całkiem stabilne.
    Jak jakiś krok ma 18.5 ps, to trzyma tę wartość. Niewiele się ona zmienia z temperaturą czy ze zmianami napięcia. Pewnie wynika to z tego że takie delaye są realizowane jako linie transmisyjne, a nie jako obwody opóźniające RC.
    Jakieś zmiany oczywiście są, ale znając ich dryft z temperaturą i napięciem, można to skalibrować.
    To jest kolejny klucz do zwiększenia rozdzielczości.

    Wcześniej pisałem że użyłem DELAYów o kroku 20ps, a główny PWM miał taktowanie 250MHz. W praktyce przy taktowaniu 250MHz, da się zrobić FRPWMa tylko z DELAYów 100ps. Bo wystarcza 64 kroki aby mieć 6.4 ns opóźnienia, a więc więcej niż krok niskorozdzieczego PWMa (4 ns).
    Przy 20ns też by się dało, gdyby kroków było ponad 200.
    W praktyce jednak żaden układ FPGA nie ma tak dużej ilości kroków.
    Max jaki znalazłem to 128, co przy 20 ps daje łączne opóźnienie równe 2.56 ns. Za mało aby pokryć cały krok niskorozdzielczego PWMa.
    Żeby mieć ponad 4 ns, trzeba połączyć 2 DELAYe w szereg:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    W najprostszej wersji, gdy dojdziemy do maksymalnego ustawienia jednego DELAYa, zaczynamy jechać drugim.
    Ale można też inaczej. Żeby to zauważyć trzeba sobie umieścić wartości opóźnień obu DELAYów na jednym wykresie:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Jak widać wartości są różne.
    Żeby ustawić 20 ps, nie musimy korzystać z pierwszego niebieskiego DELAYa (ograniczając użycie czerwonego do końca zakresu).
    Możemy skorzystać z drugiego od razu, bo on da nam ustawienie bliższe potrzebnemu nam 20 ps (pierwszy ma z 18 ps).
    Tak samo w innych miejscach. Np. od 120 do 160 ps, mamy wartości DELAYów czerwonych i niebieskich na przemian, co mniej więcej 10 ps. Czyli trochę nam wzrasta ilość możliwych do ustawienia wartości.
    Ale to nie koniec.
    Żeby ustawić np. 60 ps, wcale nie musimy się ograniczać do wyboru 60 ps na jednym DELAYu (który w praktyce ma 60.5 ps), albo 60 ps na drugim DELAYu (który w praktyce ma 57.4 ps).
    Można ustawić 20 ps na jednym a 40 ps na drugim.
    Albo po 30 ps na obu.
    Albo 40 ps na jednym a 20 ps na drugim.
    Trzeba sobie zrobić wykres wszystkich kombinacji aby zobaczyć co to daje.
    Słabo to widać na pierwszych wartościach, więc daję wykres dla szerszego zakresu:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Wartości DELAY: ustawienia o numerach 0...19 = delaye o wartościach 0 ps...380ps (teoretycznie, gdyby nie było rozrzutów wartości).
    Niebieskie: DELAY 1 (czyli DELAY 2 ustawiony na 0)
    Czerwone: DELAY 2 (czyli DELAY 1 ustawiony na 0)
    Zielone: kombinacje ustawień DELAY 1 i DELAY2 (oba DELAY ustawione powyżej 0)
    Nim większa liczba, tym więcej kombinacji do ustawienia.
    Np. do ustawienia 2 mamy tylko 3 kombinacje:
    Code:
    DELAY1 = 2, DELAY2 = 0
    
    DELAY1 = 0, DELAY2 = 2
    DELAY1 = 1, DELAY2 = 1

    Ale dla ustawienia 10, mamy już 11 kombinacji (teoretycznie, w praktyce zależy to od tego ile faktycznie pikosekund ma każde ustawienie):
    Code:
    DELAY1 = 10, DELAY2 = 0
    
    DELAY1 = 9,  DELAY2 = 1
    DELAY1 = 8,  DELAY2 = 2
    DELAY1 = 7,  DELAY2 = 3
    DELAY1 = 6,  DELAY2 = 4
    DELAY1 = 5,  DELAY2 = 5
    DELAY1 = 4,  DELAY2 = 6
    DELAY1 = 3,  DELAY2 = 7
    DELAY1 = 2,  DELAY2 = 8
    DELAY1 = 1,  DELAY2 = 9
    DELAY1 = 0,  DELAY2 = 10

    Tylko na początku i na końcu, mamy ograniczoną ilość kombinacji.
    Tu dałem przykład dla 20 kroków, ale taki DELAY ma zwykle 64/128 kroków.
    Już dla 20 kroków widać że szybko wzrasta zagęszczenie kombinacji (zielone kropki na wykresie).
    Począwszy od 300 ps, mamy już prawie jeden ciąg zielonych kropek.
    Jest więc z czego wybierać. Można ustawić 300 ps, 305 ps, 307 ps, 309 ps, 311 ps, itd.
    A nie tylko ustawiać co 20 ps.

    Podsumowując, potrzeba tutaj mieć spełnione 4 warunki:
    1. DELAYe muszą mieć rozrzut wartości, aby powstawały losowe kombinacje.
    2. Muszą być użyte co najmniej 2 DELAYe w szeregu, aby w ogóle dało się układać kombinacje ustawień.
    3. Rozrzut wartości DELAYów musi być stabilny. Albo przynajmniej być wolnozmienny, aby dawać się kalibrować w locie.
    4. Taki PWM nie zadziała bez kalibracji przy pierwszym uruchomieniu. Jest to pewna niedogodność, ale do zaakceptowania.

    W moim przypadku użycie dwóch DELAYów dawało jeszcze za mały rozrzut wartości, więc postanowiłem spróbować z trzema.
    Ilość kombinacji w takim przypadku wzrasta drastycznie.
    To jest ogromny ciąg danych, więc ograniczę trochę zakres danych.
    Założę że używa się tylko 20 pierwszych ustawień DELAYów, a nie wszystkich 128 ustawień.
    W takim wypadku jest 20 * 20 = 400 kombinacji ustawienia 2 DELAYów.
    Oraz 20 * 20 * 20 = 8000 kombinacji ustawienia 3 DELAYów.
    Dla 2 DELAYów, mamy maksymalne ustawienie równe około:
    19 * 20 ps + 19 * 20ps = 760 ps.
    Zbierając wszystkie wartości razem (niebieskie, czerwone i zielone kombinacje jako jeden kolor) wyjdzie taki wykres:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    O wiele ciekawszy będzie jednak wykres przedstawiający jaka jest odległość pomiędzy kolejnymi ustawieniami. Czyli przedstawiający wartości delt. Uzyskamy go konwertując jeden wykres w drugi, o tak:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Cały wykres będzie wyglądał tak:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Przypominam że to jest dla 2 DELAYów, i 400 kombinacji.
    Uzyskujemy opóźnienia od 0 do 760 ps (ns wykresie sięga 800 ps, ze względu na rozrzut wartości: średnie opóźnienie bloków DELAY było trochę większe niż 20 ps).
    Jak widać, delty w środkowej części (gdzie kombinacji jest najwięcej) spadają poniżej 10 ps.
    Czyli jak ograniczymy się do stosowania opóźnień od 150 do 750 ps, to będziemy mieli rozdzielczość z 10 ps.
    Ale dla 3 DELAYów ilość kombinacji wzrasta drastycznie. Będzie aż 8000 kombinacji:
    Maksymalne opóźnienie do ustawienia równe około:
    19 * 20 ps + 19 * 20ps + 19 * 20ps = 1140 ps
    Wykresy:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Tutaj mamy już tak wiele kombinacji, że dla opóźnień od 200 do 1000 ps żadna delta już nie przekracza 1 ps. W całym zakresie 200...1000 ps można przebierać do woli. Znajdziemy tam dowolną wartość z rozdzielczością lepszą niż 1 ps.

    W praktyce, ze względu na niewielkie pływanie wartości, oraz błędy podczas pomiaru tych wartości przed ich stablicowaniem, faktyczna rozdzielczość będzie trochę mniejsza.
    Precyzyjniej mówiąc, wartości ciągle będzie tyle samo, ale już nie będzie można być pewnym że zachowają monotoniczność (że nie zmienią kolejności).
    Żeby być pewnym monotoniczności, trzeba założyć sobie mniejszą rozdzielczość.
    Mi z pomiarów wyszło że daje się tym sposobem uzyskać rozdzielczość rzędu 2 ps.
    Wymaga to dokładnej kalibracji i ponawiania jej w locie podczas pracy FRPWMa. Oraz bardzo precyzyjnego zegara taktującego (i jeszcze kilku innych rzeczy).
    Nie mniej jednak tyle udaje się uzyskać.
    I to jest właśnie te 500 GHz wirtualnego taktowania, i jakim pisałem.

    Problem jest tylko taki że w tej wersji nie możemy używać małych opóźnień DELAYów, bo tam rozdzielczość jest mała.
    Musimy zacząć np. od 400 ps, i iść tylko do góry*.
    Ale łatwo tą wadę wyeliminować z końcowego sygnału FRPWMa:
    DIY FRPWM o rozdzielczości pikosekundowej, na układzie FPGA. Część 2.
    Po prostu pierwsze zbocze FRPWMa też przesuwamy o te 400 ps, a drugie o 400 ps + potrzebną wartość. Tym sposobem da się ustawiać "potrzebną wartość" już od 0 ps, mimo że DELAYe zawsze będą pracować dla ustawień powyżej 400 ps**.

    No i tyle. To jest całość. Pomysł prosty, a tyle zabawy żeby go zaimplementować albo wyjaśnić jego działanie.
    "Układ" nie ma obudowy, więc nie można go krytykować :D
    Całość jest zaimpementowana w FPGA, jako "softcore".
    Ewentualnie mogę jeszcze zrobić opisy jak to kalibrować.

    * Od góry zakres też powinniśmy ograniczyć, ale on się tam ograniczy niejako sam: zakres ustawianych opóźnień jest znacznie szerszy niż krok niskorozdzielczego PWMa, więc nigdy nie będziemy mieli konieczności skorzystać z tych górnych wartości.

    ** Można też obejść się bez przesuwania pierwszego zbocza, ale to wymaga odpowiedniego modyfikowania wartości ustawianej w drugim zboczu. Już tego nie będę opisywał żeby nie komplikować. Taka metoda ma jednak zaletę w niektórych FPGA, gdzie ustawienie DELAY na wartość 0 da się zrobić szybciej niż
    na jakąś inną wartość (gdy blok DELAY ma wejście RESET, a ustawianie wartości odbywa się za pomocą sygnałów STEP i DIR co trwa o wiele dłużej).

    Cool! Ranking DIY
    Can you write similar article? Send message to me and you will get SD card 64GB.
    About Author
    atom1477
    Level 43  
    Offline 
    atom1477 wrote 18957 posts with rating 783, helped 1379 times. Been with us since 2005 year.
  • #2
    krisRaba
    Level 30  
    atom1477 wrote:
    Po prostu pierwsze zbocze FRPWMa też przesuwamy o te 400 ps, a drugie o 400 ps + potrzebną wartość. Tym sposobem da się ustawiać "potrzebną wartość" już od 0 ps, mimo że DELAYe zawsze będą pracować dla ustawień powyżej 400 ps**.

    Sprytne :D

    Dodano po 44 [minuty]:

    Hmm, ale czy to nie będzie tak, że chcąc uzyskać wspomnianą rozdzielczość 2ps na bazie 3 DELAYów trzeba zbudować coś w rodzaju LUT, która zawiera wartości do wpisania do każdego bloku, by uzyskać dany krok (będący wynikiem kalibracji)?
    Przykładowo wcześniej było o krokach 100ps i ich było kilka(naście), to niech tych kalibrowanych kroków będzie 500 lub 1000, razy 3 wartości po kilka bitów (nie wiem, czy da się organizować pamięć poniżej bajta, ewentualnie sklejać, by jeden bajt przepisywany był odpowiednio do delayów), to robi się niezły LUTek ;)

    Druga rzecz, to kalibracja. Czy ona musi odbywać się za pośrednictwem pomiaru z zewnątrz? Czy da się też to ogarnąć w środku? Bo skoro sztucznie operujemy poza zegarem, to zakładam, że nie mamy zegara, który przechwyci zbocza z odpowiednią rozdzielczością?
    Bo jakiś dzielnik częstotliwości chyba tego nie ogarnie?
  • #3
    atom1477
    Level 43  
    krisRaba wrote:
    Hmm, ale czy to nie będzie tak, że chcąc uzyskać wspomnianą rozdzielczość 2ps na bazie 3 DELAYów trzeba zbudować coś w rodzaju LUT, która zawiera wartości do wpisania do każdego bloku, by uzyskać dany krok (będący wynikiem kalibracji)?

    No tak.
    Dlatego pisałem że trzeba zmierzyć i stablicować wartości.

    krisRaba wrote:
    Przykładowo wcześniej było o krokach 100ps i ich było kilka(naście), to niech tych kalibrowanych kroków będzie 500 lub 1000, razy 3 wartości po kilka bitów (nie wiem, czy da się organizować pamięć poniżej bajta, ewentualnie sklejać, by jeden bajt przepisywany był odpowiednio do delayów), to robi się niezły LUTek ;)

    W FPGA można organizować dowolne pamięci. Np. 16, 17 czy 18 bitowe.
    Jedna pamięć np. 21-bitowa, może trzymać współczynniki od razu do 3 DELAYów (po 7 bitów na DELAYa).

    krisRaba wrote:
    Druga rzecz, to kalibracja. Czy ona musi odbywać się za pośrednictwem pomiaru z zewnątrz? Czy da się też to ogarnąć w środku?

    Nie musi być z zewnątrz. Da się w środku.
    Ale to kolejny dość specyficzny blok, którego opis był by dość długi.
    Prościej jest to zrobić z zewnątrz.

    krisRaba wrote:
    Bo skoro sztucznie operujemy poza zegarem, to zakładam, że nie mamy zegara, który przechwyci zbocza z odpowiednią rozdzielczością?

    Pomiar na zewnątrz robimy pośrednio. Z użyciem konwertera czas-napięcie. I potem mierzymy po prostu napięcie.
  • #4
    Janusz_kk
    Level 31  
    Wszystko fajnie tyle że dla początkujących niestrawne bo brak kodu i objaśnienia do niego.
  • #5
    krisRaba
    Level 30  
    Bo to nie na Arduino ;)

    Sama zasada działania i jej opis też jest tutaj ok wg mnie i da się zrozumieć jak to działa i w jaki sposób obchodzi standardowe ograniczenia zegara.
    Można w sumie dodać coś na temat implementacji w FPGA choć nie wiem, czy do zrozumienia coś to wniesie.

    Dodano po 3 [minuty]:

    Bardziej przydatne wg mnie byłoby pokazanie układu, na którym to było testowane, jak dokładnie zbierane były pomiary, jeśli np. była automatyzacja typu wyjście PWM podane na RC, to zawinięte na ADC, dane wyplute przez interfejs do PC, gdzie zebrane tym i tym, obrobione tamtym..
  • #6
    Marek_Skalski
    VIP Meritorious for electroda.pl
    @atom1477 Interesujący artykuł. A możesz napisać gdzie i do czego potrzebujesz PWM z odpowiednikiem zegara 500 GHz?
    Jeżeli to jest sterowanie silnika, to jego bezwładność mechaniczna zazwyczaj ogranicza zapotrzebowanie w okolicach kilku/kilkunastu kHz. Przykładowo z mojego podwórka, pozycjonowanie modułu mechanicznego z waflem krzemowym z dokładnością poniżej 1 nm wymaga raptem 7-10 kHz. Kompensacja drgań w mikroskopie elektronowym, aby uzyskać rozdzielczość na poziomie 50 pm (piko!), to też pasmo kilku kHz. Aktualnie nie nam bardziej dokładnych urządzeń mechanicznych, wiec to chyba nie takie zastosowanie.
    Jeżeli to jest sterowanie stopni kluczujących w zasilaczu, to rozdzielczość PWM jest ściśle powiązana z rozdzielczością ADC w pętli sprzężenia zwrotnego, a to wynik z przyjętych parametrów dynamicznych i tutaj też nie gonimy w GHz. Jeżeli jest potrzeba zmniejszyć tętnienia, to stopień się dubluje lub dodaje więcej sekcji pracujących z przesunięciem fazowym.

    W przypadku opisywanego urządzenia, jego opracowanie wymaga dość dużo czasu i jest bardzo wrażliwe na zmiany komponentów. Jak sam zauważyłeś, dla każdego egzemplarza trzeba zebrać i przetrawić sporo danych, aby uzyskać sensowne działanie. Ma to sens w przypadku produktów realizowanych w pojedynczych sztukach, na jakieś specjalne zamówienie - bardzo specyficzne zastosowanie. Jakaś uczelnia?
  • #7
    atom1477
    Level 43  
    krisRaba wrote:
    Bo to nie na Arduino ;)

    Sama zasada działania i jej opis też jest tutaj ok wg mnie i da się zrozumieć jak to działa i w jaki sposób obchodzi standardowe ograniczenia zegara.

    Dokładnie.
    Brak kodu jest celowy. Po prostu ten cały pomysł nie opiera się na kodzie.
    Dodatkowo 95% programistów (jak nie więcej) jest programistami uC, a nie CPLD/FPGA. Oni by nie zrozumieli kodu "równoległego", bo są przyzwyczajeni do kodu "liniowego".
    Dodatkowo układ jest w zasadzie schematem. Nie ma obowiązku robić go za pomocą kodu. Można go też poskładać z bloczków schematowych.
    To nie projekt dla początkujących, gdzie trzeba dać kod i opisywać jego każdą linijkę. Zakładam raczej że to jest dla ludzi którzy już umieją programować na FPGA, i bez problemu sobie odtworzą kod modulatora PWM.

    krisRaba wrote:
    Bardziej przydatne wg mnie byłoby pokazanie układu, na którym to było testowane, jak dokładnie zbierane były pomiary, jeśli np. była automatyzacja typu wyjście PWM podane na RC, to zawinięte na ADC, dane wyplute przez interfejs do PC, gdzie zebrane tym i tym, obrobione tamtym..

    To jest coś na trzecią cześć artykułu, jeżeli było by zainteresowanie na tą trzecią część.
    Obecne części wyszły dość długie, a wiem że tak długie artykuły nieprzyjemnie się czyta. Skracałem jak mogłem, a i tak wyszło długie. Stąd nie ma tam kodów czy innych rzeczy na jakich braki się skarżycie :D

    Marek_Skalski wrote:
    A możesz napisać gdzie i do czego potrzebujesz PWM z odpowiednikiem zegara 500 GHz?

    To powstało jako rozwiązanie uniwersalne, gdy tylko się zorientowałem że to można w miarę prosto zrobić. Ale już kilka zastosowań się znalazło.
    Jedno to przetwornica wysokiej częstotliwości z cyfrowym sprzężeniem zwrotnym.
    Innych na razie wolę nie zdradzać :D

    W każdym razie: nie na uczelni.

    Głównym celem, skoro już wpadłem na pomysł jak to zrobić, było to po prostu zrobić. I niech czeka na zastosowania, bo w przyszłości na pewno się pojawią.
  • #8
    khoam
    Level 40  
    atom1477 wrote:
    Jedno to przetwornica wysokiej częstotliwości z cyfrowym sprzężeniem zwrotnym.

    Naprawdę chciałbym zobaczyć, jak wygląda przetwornica pracująca z częstotliwością 500GHz, czy chociaż 50GHz. Rozumiem, że taki układ to już dość zaawansowana technika mikrofalowa?
  • #9
    zdziwiony
    Level 23  
    Może do czegoś takiego Szyk_fazowany Jak Atom zniknie to znaczy że służby czytają elektrodę. Trza przyznać, że chłop ma głowę nie od parady.
  • #10
    atom1477
    Level 43  
    khoam wrote:
    atom1477 wrote:
    Jedno to przetwornica wysokiej częstotliwości z cyfrowym sprzężeniem zwrotnym.

    Naprawdę chciałbym zobaczyć, jak wygląda przetwornica pracująca z częstotliwością 500GHz, czy chociaż 50GHz.

    500GHz to nie jest częstotliwość PWMa sterującego przetwornicą, tylko częstotliwość taktująca PWM.
    Częstotliwość sygnału PWM jest zawsze wielokrotnie mniejsza od częstotliwości taktującej. Dokładnie to 2^n razy mniejsza (gdzie n to ilość bitów PWMa)(albo 2*2^n, jak PWM jest symetryczny).
    U mnie przetwornica ma kilka MHz. Po prostu n jest duże.
  • #11
    acctr
    Level 20  
    Jaki zastosowałeś algorytm wyboru DELAYów? Tutaj z powodzeniem sprawdzi się programowanie dynamiczne. Jest podobieństwo do problemu wydawania reszty.
  • #13
    jestam
    Automation specialist
    Obydwie części artykułu są bardzo dobre.

    Pomysł i zasada działania powinny być zrozumiałe dla każdego inżyniera. Implementację zrobi ten, kto potrzebuje i potrafi; kto potrzebuje i nie potrafi zgłosi się do kolegi :-)

    Ciekaw jestem sposobu kalibracji wewnątrz FPGA.
  • #14
    atom1477
    Level 43  
    Można to skalibrować za pomocą generatora pierścieniowego.
    W pierwszej części podawałem linka (choć nie w tym celu go podawałem):
    https://www.xilinx.com/support/documentation/application_notes/xapp872.pdf
    Ustawiamy Delay = 0, i mierzymy okres przebiegu (można częstotliwość, ale wtedy trzeba przeliczać).
    Ustawiamy pierwszy krok czyli Delay = 1. Powiedzmy że ten krok ma katalogowo mieć 20ps.
    I patrzymy o ile wzrósł okres przebiegu. Krok wynosi tyle o ile wzrósł. Wzrósł o 19.5ps, to tyle ma krok. Prościej się nie da.
    Pomiar częstotliwości/okresu jest jednym z najprostszych do cyfrowego wykonania precyzyjnych pomiarów.
    Więc mimo prostoty, uzyskamy sporą dokładność pomiaru.

    Praktycznie można to zrobić na 2 sposoby:
    1. Zrobić konfigurowalnego PWMa, który pozwala się skonfigurować w generator pierścieniowy.
    2. Użyć dwóch projektów bitstream. FPGA i tak zwykle jest konfigurowane z zewnątrz. Można więc mieć jeden projekt do kalibrowania, a drugi do normalnego działania.

    Ja użyłem jeszcze innej metody. Kalibruję z zewnątrz. Tak mi było wygodniej, mimo że to wtedy nie jest już projekt na jednym układzie scalonym (nie wystarcza samo FPGA).
  • #15
    jestam
    Automation specialist
    Dziękuję, to mi wystarczy. :-)