Potrzebuję opóźnić impuls - jak zrobić opóźniacz

Uzycie licznika z kodem Graya nie bedzie problemem - bedzie bardziej 'rownomiernie' dzialac.

Jitter... bedzie na poziomie tego wolniejszego zegara. Jedyne cyfrowe synchroniczne rozwiazanie to jeden monotoniczny licznik.

Jak sie to zacznie dzielic na >1 zegar, to mocno wzrosnie jitter. Poza tym co z dokladnoscia? Trza by zatrzymywac wolniejszy licznik w polowie, odmierzac czas wolnym licznikiem i potem wlaczac szybki licznik jeszcze raz. A serdesem podziele sobie problem na 8 albo 10 ;-)

Poza tym nie ma to za bardzo sensu - jak 4 bity musza chodzic na tych GHz, to rownie dobrze moga i 34 (plus kompensacja dla dlugosci sciezek). Ja nie musze _bardzo_ dokladnie czasu mierzyc, ale to musi byc bardzo powtarzalne.

W tej chwili staram sie znalezc jakiekolwiek asynchroniczne rozwiazanie, ino przy tych szybkosciach to bedzie analogowe => dupa blada ;-(

Dla 10ns czasu, 100ps jitter to +/- 1%, czyli 2%. Dla zminimalizowania jittera rozwazam jeszcze synchronizacje ukladu klienta z moim ukladem - jak sie to uda zrobic gonione z jednego zegara, to z sugestiami grupy bede pewnie w domu. Jak nie... to nie ;-)

/.../

pomieszalo nam sie pare rzeczy;

sam licznik jako taki - caly licznik pracuje z tym samym zegarem a jego 'szybka' czesc wytwarza clock_enable sygnal dla reszty lancucha przerzutnikow, w ten sposob wyzsze bity efektywnie pracuja z mniejsza czestotliwoscia, ale wszystkie FF sa taktowane tym samym zegarem;

moj pomysl opieral sie na tym, ze licznik jest taktowany zegarem ok. 100MHz i odmierza czas zgrubnie, do przesuwania impulsu o setki ps sluzy phase_shift w pll, nie ma wiec w nim gigahercowego licznika;

JA

przez tydzien mam jedynie dostep do laptopa z niemiecka klawiatura, odmawiam udzialu w dyskusji ... za dlugo trwa napisanie jednego zdania poprawnie

IMHO nie ma sensu. Jedyne co wygrasz, to troche mniejsze zuzycie energii. Timingi zostaja dokladnie takie same. Z drugiej strony jesli licznik w kodzie Graya (nie ma przeciwwskazan, to ni cholery nie ma sensu kombinowac).

Ja rozumiem, ale IMHO trzeba przesunac zegar dla licznika o wymagany czas. A wtedy problem o ktorym A. Grodecki wspominal (rownomiernosc pracy cholerstwa).

;-)

A ja czekam na efekt negocjacji z klientem. W koncu On tutaj decyduje...

z gory przepraszam jesli ukaza sie 2 kopie tej odpowiedzi, ale nie widze na onet tego, co wyslalem kilka minut temu,

Jerry1111 wrote:

jedank nie; rzecz w tym, ze przed kazdym F-F stoi dekoder, ktory ma rozpoznac stan 0xFFF..F poprzedzajacych przerzutnikow, jesli jest ich wiele, to chwile to trwa bo dekoder sklada sie z kilku 'sub-dekoderow'; jesli podzielisz jak wspominalem, 'duzy' dekoder ma wiecej czasu na rozpoznanie stanu 0xFF..F, dokladnie tyle czasu, ile potrzebuje 'maly' licznik by przejsc ze stanu 0x0 do stanu

0xF; stan 'malego' licznika nie jest rozpoznawany przez wielopoziomowy dekoder a podawany pojedyncza linia na wejscie clock_enable przerzutnikow licznika 'duzego'; efektywnie 32 bitowy licznik moze pracowac z szybkoscia, jaka da sie osiagnac dla licznika 4 bitowego;

kod Graya nie zwiekszy szybkosci licznika; ten kod da Ci jedynie tyle, ze rozpoznanie konkretnego stanu licznika jest wolne od szpilek, ktore powstaja w trakcie przelaczania sie F-F;

coz... moim zdaniem nie;

rownomoernosc nie jest problemem, jesli masz odmierzyc X taktow, ladujesz licznik liczba X-1 i liczysz w dol, sygnalem, ze uplynal zadany czas, jest zapalenie sie najstarszego bitu po 'przekreceniu' sie licznika przez zero - nie trzeba ekstra dekodera;

JA

JA napisał(a):

Nawet w technice TTL produkowane były dyskretne układy do generowania tzw szybkiego przeniesienia. Ale nie wiem o co chodziło. Pewnie właśnie o to o czym pisze JA.

Dokładnie :) I na dodatek ma zmniejszyć prawdopodobieństwo bedu w układzie, np z powodu opóźnień właśnie...

Jest jeszcze jeden problem - układy cyfrowe propagują nierównomiernie. Pamiętam taki problem przy dalmierzach laserowych robionych na ECL-ach. Okazało się, że licznik binarny ECL miał pewną "nierównomierność prawdopodobieństwa" wystąpienia określonych stanów! Trzeba było tę nierównomierność określać empirycznie a następnie mierzyć wynik przez funkcję odwrotną, i dopiero było przyzwoicie.

Generalnie nie ma się co chrzanić z problemem. Jesli klient płąci za urządzenie, a ktoś robi gotowy komponent i daje gearancję na jego parametry, to się takie komponent kupuje i zapomina o problemie...

Bardziej jak jakis hazard dla mnie brzmi. Bo skoro licznik i pominie jeden stan, to jaki bedzie nastepny?

Ja to wiem. Tylko wielkosc gotowego komponentu jeszcze o tym nie wie ;-(

Jerry1111 napisał(a):

Tu nie zachodzi problem pomijania stanów, tylko problem nierównomiernego w czasie pojawiania się stanów, nawet jeśli zegar jest idealny. I nie chodzi o proste opóżnienia na przeniesieniach. Raczej fluktuacje szumowe.

Ten gotowiec, który znalazłem, zdawał się spełniać Twoje założenia???

>

Aaa... oki. Za pozno juz dla mnie na czytanie odpowiedzi ze zrozumieniem ;-)

Tam jitter byl cos nie taki. Ale to parametr jeszcze do uzgodnienia z klientem. Zreszta pare innych 'kwiatkow' wyszlo jeszcze po drodze, wiec chyba nie bedzie tak zle.

Aczkolwiek nie mialem szczescia - sam tego malego ustrojstwa nie moglem znalezc.

A. Grodecki napisał:

oczywiscie, ze zegar nie dociera do wszyskich przerzutnikow skladajacych sie na licznik w tym samym czasie, wiec rozne stany moga 'pojawiac' sie z roznym opoznieniem; jesli jednak zastosujesz metode ladowania licznika odpowiednia wartoscia i liczenia w dol, to slabo wierze, ze nierownomiernosc bedzie wieksz niz plywanie zegara, ktory taktuje licznik;

JA

JA napisał(a):

A jednak. To nie przypadek teoretyczny, tylko praktyczny.

Z ciekawosci - pamietasz jak to w liczbach (GHz i ns) wygladalo?