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