FPGA - Xilinx

Witam,

Jakoś nic nie widzę na temat PLL. Z tego co pamiętam zegar powinien wchodzić na PLL i być odtwarzany lokalnie. Na początku powinien być CDR i deserializer. Później 10B/8B dekoder itd..

Rozumiem że źródłem zegara jest ADC i działa do 20MHz. Czyli bit clock jest w okolicach 160 - 200 MHz. Zgadza się?

Jeżeli nie ma 8B/10B to jak jest z synchronizacją ?

Mogę pomóc jedynie teoretycznie bo zazwyczaj jestem od A , nie od X.

Adam

W dniu czwartek, 17 października 2013 12:58:53 UTC+2 użytkownik Adam Górski napisał:

Ano właśnie dlatego, że skorzystałem z Wizarda, kiery tam domyślnie winien go używać.

ano dokładnie coś w tym stylu, tak przynajmniej wynika z dosyć pokrętnych objaśnień w UG700.pdf i UG381.pdf od X.

Owszem, żródłem budzika jest ADC, ale zapyla za 80MHz. ADC jest 12-to bitowy (AD9272), więc mamy 80x12 = 960MHz (DDR bit-budzik). Napędzam dziada przez programowalnego dystrybutora cykania (AD9512), więc dżiter jest stosunkowo mały. Programowo ustawiam dzielnik na AD9512 na 20/40/80 MHz. A więc jak mam 20MHz(bit clock=240MHz), wszystko jest OK przy moim dyskretnym projekcie z wykorzystaniem IBUFGDS i IDDR2. Na wyższych częstotliwościach niestety idzie się paść. Ale nie w tym rzecz!! Chodzi o to,że przy wykorzystaniu logicora, na jego ałtpucie zegarowym (clkout) jest kompletne milczenie.

Synchro jest dziabrane sygnałem FRAME. Z tym akurat ni ma problemu. nie 8, nie 10, ale w moim przypadku 12b. Zerknij na :

Ano właśnie.. Czy A ma sensownie rozwiązane problemy deserializatorów 12-16b? Bo z X jak widać mam kurewski problem!!

Altera też ma jakiegoś wizarda. Ja z niego nie korzystałem, robiłem na piechotę.

Jak widzę analog ma dev kita do tego układu i na pierwszym zdjęciu z opisu występuje toto z płytą na której siedzi X. Zapytaj o kody to tego X - powinni Ci podesłać.

Jesteś na 100% pewien że to co dostajesz przy 20MHz jest ok ? Jeżeli tak to rozjeżdżają się gdzieś czasy. Zwykle PLL mają możliwość przesuwania fazy jednego zegara względem drugiego i prawdopodobnie to pomoże w twoim przypadku. Można to zrobić nawet dynamicznie.

Ja tak sobie robie 16bitowego PWM przy 100kHz. Normalnie potrzebowałbym około 6,5GHz zegara, ale właśnie daje się to zrobić przy pomocy przesuwania fazy PLL.

Jakiś wizard mają ale go nie używałem.

Adam

W dniu czwartek, 17 października 2013 17:35:21 UTC+2 użytkownik Adam Górski napisał:

Ano właśnie. To co wyskrobałem na piechotę, działa na 20MHz. Na wyższych częstotliwościach rozjeżdża mi się to pieroństwo. Na bank nie trafiam cykaniem budzika w środek "oczka" bitu danych. Baa!! Mało tego, wiem co trzeba zrobić, ino za cholerę nie wiem jak!! Ano trzeba o parę pikosekund przesunąć dane względem budzika. X ma takiego prymitywa IODELAY2, ale dokumentacja jest do tego też tak pokitranie napisana, że nie daję se z tym rady.

Jasne że podesłali. Ino że mają to na Virtexa4. Przerobiłem kod na Spartana6 (inne prymitywy) no i niestety lipa. Jakoś tam działa, ale niestety błędnie.

Raczej tak. w dokumentacji AD9272 jest tabelka nr. 12. Jak każę scalakowi, to wypluwa określone dane testowe. Przy 20MHz wszystko jest OK. Na wyższych częstotliwościach poprawnie działają ino trywialne testy typu same jedynki, bądź same zera.

Też to wiem, ino nie wiem jak to zrobić w X.

Tylko jak to zrobić z użyciem IODELAY2 w X?

A mógłbyś podzielić się fragmentem kodu? snipped-for-privacy@gmail.com Chętnie podeślę Ci też swoją bazgraninę (VHDL).

W dniu 2013-10-17 21:24, snipped-for-privacy@gmail.com pisze:

Sam kod ma tu raczej niewiele do rzeczy. W opisie do serdesów (ug381.pdf strona 78) widzę że są one 4 bitowe i max można połączyć dwa ze sobą. Wychodzi na to że max można odebrać 8 bitów w obrębie SERDES-a.

Może to być właśnie Twój problem. Jeżeli wizard pozwala zrobić 12 bitowego to raczej nie przez połączenia do kaskadowania. Może coś tam kombinować poza serdesem. I tak to trochę wygląda bo 240Mb/s to jeszcze poleci po "user logic" ale 480 i 960 zwłaszcza to już niekoniecznie.

Zobacz jak to jest połączone po kompilacji ( brak lepszego słowa )

Jeżeli łączy to w obrębie normalnej logiki to raczej można zapomnieć o odbieraniu prawie 1Gb/s.

Odbieranie przy takiej prędkości możliwe jest tylko przy użyciu serdesa.

pzdr

Adam

W dniu pi±tek, 18 pa¼dziernika 2013 00:39:46 UTC+2 u¿ytkownik Adam G órski napisa³:

m Górski napisa³:

a?em, robi?em na

Na wy¿szych czêstotliwo¶ciach rozje¿d¿a mi siê to pieroñstwo. Na bank nie trafiam cykaniem budzika w ¶rodek "oczka" bitu danych. Baa!! Ma³o tego, wiem co trzeba zrobiæ, ino za cholerê nie wiem jak!! Ano trzeba o parê pikosekund przesun±æ dane wzglêdem budzika. X ma taki ego prymitywa IODELAY2, ale dokumentacja jest do tego te¿ tak pokitranie napisana, ¿e nie dajê se z tym rady.

szym zdj?ciu z

siedzi X. Zapytaj o kody to tego

od na Spartana6 (inne prymitywy) no i niestety lipa. Jako¶ tam dzia³a, ale niestety b³êdnie.

za 80MHz. ADC jest 12-to bitowy (AD9272), wi?c mamy 80x12 = 960MH z (DDR bit-budzik). Nap?dzam dziada przez programowalnego dystrybut ora cykania (AD9512), wi?c d?iter jest stosunkowo maï¿ ½y.

c jak mam 20MHz(bit clock=240MHz), wszystko jest OK przy moim dyskretnym projekcie z wykorzystaniem IBUFGDS i IDDR2. Na wy?szych cz? stotliwo?ciach niestety idzie si? pa??. Ale nie w tym rzecz!! Chodzi o to,?e przy wykorzystaniu logicora, na jego a?tpucie zegarowym (clkout) jest kompletne milczenie.

st ok ?

lakowi, to wypluwa okre¶lone dane testowe. Przy 20MHz wszystko jest OK. N a wy¿szych czêstotliwo¶ciach poprawnie dzia³aj± ino trywialne tes ty typu same jedynki, b±d¼ same zera.

gdzie? czasy.

fazy jednego zegara wzgl?dem

we i

odebraæ 8

Te¿ ju¿ to przerabia³em. Sk³ada³em 2 SERDESy w sze¶ciobitowca i zatrzaskiwa³em na zboczach FRAME. Jakby cosik chcia³o dzia³aæ, ale nie do koñca. Jak zwykle, test na samych zerach lub jedynkach przechodzi . Na innych testach niby te¿ jestem blisko, ale co poniektóre bity ¶w iruj±.

tam

szcze

W pe³ni siê zgadzam z Tob±. Tak czy inaczej jestem prawie pewien, ¿ e wystarczy pomanewrowaæ pikosekundami z wykorzystaniem IODELAY2. Tylko j ak tego pieroñstwa u¿yæ to za cholerê nie wiem!! Diabelnie pokrêt na dokumentacja.

Implementacji.

mnieæ o

erdesa.

Te¿ tak my¶la³em, ale chyba jednak siê da. Tak na nosa czujê ¿e da siê. Jak wy¿ej wspomnia³em, testy ¶wiruj± tylko na niektóry ch bitach, wiêc jestem blisko. Wydaje mi siê, ¿e trzeba pomanewrowa æ tylko pikosekundami opó¿nieñ danych, coby budzik trafi³ w oczko . Tylko jak u¿ywaæ IODELAY2, to za cholerê nie wiem. Jak masz ochot ê i czas, to poczytaj dokumentacjê. Mo¿e Ty lepiej to ode mnie za³a piesz i co¶ podpowiesz. X z regu³y ma bdb dokumentacjê, ale akurat w tym temacie oceniam na ndst. A ¿e chyba raczej da siê to zrobæ, to pr zeczytaj poni¿ej co napisa³ mi gostek z TI:

Hi,

I had not seen the XAPP1064 before, but just took a quick glance at it. I am familiar with the XAPP866 and we do *not* implement the interface to the ADS5282 that way in our TSW1200. We found the use of the ISERDES and the DCM blocks to be overly complex and we found it difficult to get all the IS ERDES needed for the 8 channels reset and synchronized together.

Attached is a sketch of how we implement the ADC to FPGA interface in our T SW1200. The TSW1200 uses a Virtex4, but i believe the Spartan6 should also have the IDELAY cells available.

The first thing that must be accomplished is getting the data latched into the FPGA using the DDR bit clock. The IDDR cell was used which simply latc hes the data on the rising edge and again on the falling edge. Then it our puts the rising edge bit and the falling edge bit on the same clock edge. Since the DDR clock from the ADC is centered in the valid timing of the bit , and in the FPGA the clock must go through a clock buffer, there must be a way of making the data bit get to the IDDR cell at the right time to meet the setup and hold time of the IDDR cell. The IDELAY cell is used to delay the data to meet setup and hold times intot he IDDR.

Now the the serial data is latched into the FPGA correctly, the next step i s to deserialize the data back down to the sample clock rate. To do this i build a shift register of flipflops after the IDDR cell until i have my 12 bits of sample data held in flipflops. Then at the right time i need to l oad those 12 bits of sample data into a parallel register to hold the deser ialized sample. The way to determine when to load the data into the parall el register is to look at the FCLK or frame clock signal. I bring the fram e clock into an IDDR cell just like it was another data channel. Don't be misled by the name of the signal as frame clock and try to use it as a cloc k right away; consider the frame clock to be a data bit with a known patter n so that you can look at the frame clock to see where the first bit of the sample data is when you deserialize the data. I look for the place in the frame clock pattern where the bit was low and next it was high to tell me when to make the signal to load the deserialized data in to the parallel da ta register. Only *then* do i take the frame clock signal from the IDDR ce ll and route it to a clock buffer to become the sample clock inside the FPG A to clock the deserialized data samples.

I find this to be the simplest and most robust way of getting the serial da ta from the ADS5282 into an FPGA, without the need for PLLs or DCMs or ISER DES.

Regards,

Richard

W dniu 2013-10-18 09:39, snipped-for-privacy@gmail.com pisze:

nal to load the deserialized data in to the parallel data register. Only*then* do i take the frame clock signal from the IDDR cell and route it to a clock buffer to become the sample clock inside the FPGA to clock the deserialized data samples.

Gdzie widzisz problem z dodaniem IDELAY ? Z tego co czyta³em ma to prosty interfejs z sygna³em INC / DEC delay. Czyli podobnie jak w A jedna iteracja z tymi sygna³ami powoduje zwiêkszenie lub zmniejszenie opó¼nienia o ile¶ tam ps. No i trzeba jechaæ a¿ siê zatrzasn± dobre dane.

Pzdr

Adam

W dniu piątek, 18 października 2013 10:09:34 UTC+2 użytkownik Adam Górski napisał:

Dokładnie tak samo se to wyobrażam jak piszesz. Problem z tym, że nie za bardzo chwytam ten IODELAY2. OK, napiszę co wiem(rozumiem), a czego kompletnie nie załapuję. Jeżeli Ty rozumiesz czego ja niestety nie, i jeżeli mi to wytłumaczysz, to jest nadzieja że jakoś to w końcu zadziała na 80MHz. OK, krok po kroku:

3) DATAOUT, DATAOUT2 - rozumiem, nie mam pytań

No i teraz atrybuty:

Jeżeli możesz coś wyjaśnić, będę wdzięczny.

W dniu 2013-10-18 13:37, snipped-for-privacy@gmail.com pisze:

Tak najpierw odbiornik LVDS.

W elemencie opóźniającym jest zapewne logika/maszyna stanów która wymaga taktowania do działania. do sygnału dec/inc potrzebujesz zegara. Tak jak ja to widzę nie ma on żadnego wpływu na opóźnienie.

To są sygnały od interfesju. CLK,INC,CE to interfejs do kontrolowania tego ficzeru. Czyli jeżeli aktywne CE to zależnie od INC/DEC zwiększa lub zmniejsza. Jeżeli brak CE to nie ma zmian opóźnienia. Jest tam jeszcz chyba BUSY sygnał który jest ustawiony podczas przestrajania opóźnienia.

DDR to SDR konwersja jest umieszczona w IO wiec trzeba wiedzieć do czego to podłączyć. W/g mnie więc chodzi tylko o sposób podłączenia.

To są tylko moje opinie bazujące na wiedzy A. Ale uważam że prawdziwe lub wysoce prawdopodobne.

Pzdr

Adam

W dniu piątek, 18 października 2013 13:49:54 UTC+2 użytkownik Adam Górski napisał:

====================

Dzięki za porady. Jutro się za to wezmę.

W dniu 2013-10-18 18:00, snipped-for-privacy@gmail.com pisze:

Daj znać jaki wynik.

Adam

W dniu sobota, 19 października 2013 10:26:08 UTC+2 użytkownik Adam Górski napisał:

W dniu sobota, 19 października 2013 10:26:08 UTC+2 użytkownik Adam Górski napisał:

Jasne, że tak! Póki co co dzięki Twoim wskazówkom zaimplementowałem IODELAY2. Plus jest taki, że widać różnicę w efektach, czyli IODELAY2 działa. Mało miałem dzisiaj czasu, więc zrobiłem to na "odpierdul" ot tak dla przetestowania z atrybutami "Fixed Delay" raz ustawione na 10 raz na 50. Ot tak "na pałę". Są różnice w działaniu, więc Twoje wskazówki już się przydały. OK, Jutro wyskrobię kawałek interfejsu i softu coby na "półautomacie" sprawdzić działanie tego bałaganu. Dam znać o wynikach..