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?

do góry

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

do góry

W dniu czwartek, 17 października 2013 12:58:53 UTC+2 użytkownik Adam Górski napisał:
> Witam,
>
>
>
> 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_she
ets/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!!

do góry

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

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

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

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

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


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.

>>
>> 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_she
ets/AD9272.pdf

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

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


Adam

do góry

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? s...@g...com
Chętnie podeślę Ci też swoją bazgraninę (VHDL).

do góry

W dniu 2013-10-17 21:24, s...@g...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? s...@g...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 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

do góry

W dniu piątek, 18 października 2013 00:39:46 UTC+2 użytkownik Adam Górski napisał:
> W dniu 2013-10-17 21:24, s...@g...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? s...@g...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 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.
>

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 świrują.

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

W pełni się zgadzam z Tobą. Tak czy inaczej jestem prawie pewien, że wystarczy
pomanewrować pikosekundami z wykorzystaniem IODELAY2. Tylko jak tego pieroństwa użyć
to za cholerę nie wiem!! Diabelnie pokrętna dokumentacja.

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

do góry

W dniu 2013-10-18 09:39, s...@g...com pisze:
>> >
>> >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
>

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

do góry

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.

do góry

W dniu 2013-10-18 13:37, s...@g...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

do góry