Optymalizacja deserializacji danych z AD9272 na FPGA Xilinx XC6SLX45 przy 80MHz

Witam,

Mam problem, pierdylnełem opis na grupę dyskusyjną Xilinxa. Czasami dają sensowne odpowiedzi, czasami nie. A problem kurde pilny!! Poniżej daję kopię tego co do nich nabazgrałem po hamerykańsku. Jeżeli macie jakieś pomysły dot. rozwiązania problemu, to weźcie coś podpowiedzcie. Bo q..va tydzień+ już nad tym ślęczę i nie mam do Pani Nędzy pomysła jak to rozkminić..

Poniżej szczegóły po hamerykańsku:

Hi,

I've got a problem on my custom board. Based on XC6SLX45-324. OK, let's make you know what I whant to do. Step by step:

1) Deserialization of data from just only one channel of AD9272. In fact, the logic works fine according to my idea (2 shift registers+bits aligment). However, it works fine up to 20MHz main (frame) clock frequency.

2) In fact, I should capture the data from AD9272 reliably @80MHz!!

3) For sure I've got the timing problems, because the design works fine @20MHz and at higher frequenies fails. NOT a simulation, a real world!! LVDS signals are well routed on my PCB and equally terminated by both TX/RX devices (AD9272/XCS6SLX45)

3) I've tried to use SelectIO Interface Winard 4.1 . Let's go page by page:

Page 1:

- Component name : del_line (name says what I intend to do. Just a delay of some tap data delay [ps] in order to match the clocking "eye")

- Data Bus direction: Configure inputs to the device
- I/O signaling : differential
- I/O signaling stardant: LVDS 2.5

Page 2:

All the checkboxes are unchecked, External data width is set to "1".

Page 3:

- Delay Inserted Into Data Routing : I select *FIXED*, initialy set to *0*

Page 4:

- Clock Signaling : Differantial/LVDS 2.5
- Clock Buffer : BUFIO2
- Active Clock Edge : Both Rising and Falling
- Input DDR data aligment : Both Clock Edges: none
- IDDR reset type : ASYNC

Page 5:

Delay inserted Into clock routing : 0

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

OK, then I click OK, wait a little, report says that the IP has been succesfuly genrated!!

Well, now I put my new generated module into schematics. New generated module has such a ports:

Outputs:

DATA_IN_TO_THE_DEVICE(1:0) - no question, understand it as 2 incoming data on pos and neg clock edge.

Inputs:

DATA_IN_FROM_PINS_P(0:0) - LVDS(+) one wire "bus" as specified on core requirement
DATA_IN_FROM_PINS_N(0:0) - LVDS(-) one wire "bus" as specified on core requirement

CLK_IN_P/N - LVDS input clock pair from external device (AD9512)


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

ATTENTION!! Here are problematic inputs and outputs:

1) IP core generator makes 2 additional inputs:

- CLK_RESET and IO_RESET. I've GND'ed both of them on my sch. Implementation process says ERROR about the unknown CLK_RESET pin!

- OK, I've created a new sch module according to IP Core VHDL generated module.
- Implementation : succesfull!!

2) NOTHING on CLK_OUT !! Constant logical '0'.!!

3) For sure, there is no problem on my PCB. When I implement a test design with
CLK+/CLK- into the FPGA => IBUFGDS => CLK any counter => any bit into the output, then I see on my scope, everything works fine.

4) I'm affraid, that something is wrong with the IP wizard. Can you help me in this matter?

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.

Ano właśnie.. Czy A ma sensownie rozwiązane problemy deserializatorów 12-16b?

Jakoś nic nie widzę na temat PLL.

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

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..


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

Rozumiem że źródłem zegara jest ADC i działa do 20MHz. Czyli bit clock

jest w okolicach 160 - 200 MHz. Zgadza się?

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.

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


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

http://www.analog.com/static/imported-files/data_sheets/AD9272.pdf

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

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�.

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.





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.

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



Altera te� ma jakiego� wizarda. Ja z niego nie korzysta�em, robi�em na

piechotďż˝.


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.






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�.


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.




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.





Jeste� na 100% pewien �e to co dostajesz przy 20MHz jest ok ?

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.


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.


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



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.



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




Jaki� wizard maj� ale go nie u�ywa�em.



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


Sam kod ma tu raczej niewiele do rzeczy.

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

Implementacji.



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.


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órych 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łapiesz 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 przeczytaj 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 ISERDES needed for the 8 channels reset and synchronized together.

Attached is a sketch of how we implement the ADC to FPGA interface in our TSW1200. 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 latches the data on the rising edge and again on the falling edge. Then it ourputs 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 is 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 load those 12 bits of sample data into a parallel register to hold the deserialized sample. The way to determine when to load the data into the parallel register is to look at the FCLK or frame clock signal. I bring the frame 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 clock right away; consider the frame clock to be a data bit with a known pattern 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 sig
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.

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

Regards,

Richard

W dniu 2013-10-17 21:24, stchebel@gmail.com pisze:

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







Altera te� ma jakiego� wizarda. Ja z niego nie korzysta�em, robi�em na



piechotďż˝.





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.













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�.





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.









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.











Jeste� na 100% pewien �e to co dostajesz przy 20MHz jest ok ?



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.





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.





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







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.







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









Jaki� wizard maj� ale go nie u�ywa�em.







A mógłbyś podzielić się fragmentem kodu? stchebel@gmail.com

Chętnie podeślę Ci też swoją bazgraninę (VHDL).





Sam kod ma tu raczej niewiele do rzeczy.

W opisie do serdesów (ug381.pdf strona 7 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.


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órych 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łapiesz 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 przeczytaj poniżej co napisał mi gostek z TI:

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




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.


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:

1) IDATAIN - input signal from IOB. No i już jest problem. Przecież dane mam LVDS. Czyli co? Domyślam się, że najpierw muszę wleźć przez IBUFDS. Zgadza się?

2) CLK - IODELAY Clock input. Jaki cholera clock i po co?

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

4) CE, INC - no fajna sprawa, ino za cholerę nie wiem jak to obsługiwać. No bo jak przyłożę jedynkę na CE (Enable increment/decrement), to niby mam możliwość zwiększania/zmniejszania opóźnienia za pośrednictwem pinu INC. Czyli jak do diabłą?! Jak przywalę '1' na INC to zwiększę opóźnienie czy zmniejszę. No i kurde o ile? Jak mam kontrolować wartość zmiany ? Ni cholery nie łapię!

No i teraz atrybuty:

1) DATA_RATE - SDR lub DDR. A co to ma do rzeczy?

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

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.


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:

W dniu 2013-10-18 13:37, stchebel@gmail.com pisze:

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









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.





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:



1) IDATAIN - input signal from IOB. No i już jest problem. Przecież dane mam LVDS. Czyli co? Domyślam się, że najpierw muszę wleźć przez IBUFDS. Zgadza się?



Tak najpierw odbiornik LVDS.



2) CLK - IODELAY Clock input. Jaki cholera clock i po co?



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.





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



4) CE, INC - no fajna sprawa, ino za cholerę nie wiem jak to obsługiwać. No bo jak przyłożę jedynkę na CE (Enable increment/decrement), to niby mam możliwość zwiększania/zmniejszania opóźnienia za pośrednictwem pinu INC. Czyli jak do diabłą?! Jak przywalę '1' na INC to zwiększę opóźnienie czy zmniejszę. No i kurde o ile? Jak mam kontrolować wartość zmiany ? Ni cholery nie łapię!



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.



No i teraz atrybuty:



1) DATA_RATE - SDR lub DDR. A co to ma do rzeczy?



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.



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





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ł:
W dniu 2013-10-18 13:37, stchebel@gmail.com pisze:

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









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.





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:



1) IDATAIN - input signal from IOB. No i już jest problem. Przecież dane mam LVDS. Czyli co? Domyślam się, że najpierw muszę wleźć przez IBUFDS. Zgadza się?



Tak najpierw odbiornik LVDS.



2) CLK - IODELAY Clock input. Jaki cholera clock i po co?



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.





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



4) CE, INC - no fajna sprawa, ino za cholerę nie wiem jak to obsługiwać. No bo jak przyłożę jedynkę na CE (Enable increment/decrement), to niby mam możliwość zwiększania/zmniejszania opóźnienia za pośrednictwem pinu INC. Czyli jak do diabłą?! Jak przywalę '1' na INC to zwiększę opóźnienie czy zmniejszę. No i kurde o ile? Jak mam kontrolować wartość zmiany ? Ni cholery nie łapię!



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.



No i teraz atrybuty:



1) DATA_RATE - SDR lub DDR. A co to ma do rzeczy?



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.



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





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

lub wysoce prawdopodobne.



Pzdr



Adam

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

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

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.











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:







1) IDATAIN - input signal from IOB. No i już jest problem. Przecież dane mam LVDS. Czyli co? Domyślam się, że najpierw muszę wleźć przez IBUFDS. Zgadza się?







Tak najpierw odbiornik LVDS.







2) CLK - IODELAY Clock input. Jaki cholera clock i po co?







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.











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







4) CE, INC - no fajna sprawa, ino za cholerę nie wiem jak to obsługiwać. No bo jak przyłożę jedynkę na CE (Enable increment/decrement), to niby mam możliwość zwiększania/zmniejszania opóźnienia za pośrednictwem pinu INC. Czyli jak do diabłą?! Jak przywalę '1' na INC to zwiększę opóźnienie czy zmniejszę. No i kurde o ile? Jak mam kontrolować wartość zmiany ? Ni cholery nie łapię!







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.







No i teraz atrybuty:







1) DATA_RATE - SDR lub DDR. A co to ma do rzeczy?







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.







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











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



lub wysoce prawdopodobne.







Pzdr







Adam



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


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

Daj znać jaki wynik.