#apertus IRC Channel Logs

morning folks!

Bertl: got some preliminary results with the connector test, for now without a connector, as we didn't have a soldering iron handy, but interesting nonetheless. The pins were just bridged with a resistor wire (held together by mechanical force).

https://files.niemo.de/freq_tap_res_wire.png

and to count successes / errors currently a simple counter is transmitted, if last_received + 1 != current_received it is counted as an error

indeed interesting ...

well 250MHz DDR

one thing to note is, that the delay refclock was connected to the output serdes clock

so at every frequency 32 delay taps should be half a clock period

(which with DDR means it should move over the complete range of one bit in 32 taps once)

Bertl: really, how do they work?

well it says that

IIRC, it's about 200-210MHz

the high end 7series can go higher and thus create shorter delays

hmm yeah maybe, however I think the results show that it seems to work for other frequencies aswell

also there is xapp707 which has some interesting things about different refclock frequencies for idelayctrl (though for virtex-4 i think)

vup: do you get a ready signal from IDELAYCTRL at your frequencies (and do you check for it before testing)?

Bertl: it is broken out as an axi reg so i could check

Should be easy to do some quick checks for the low frequencies tho

medical scissors?

so it is not the most scintific setup possible

even for 50Mhz and 330Mhz

fclk_ready?

idelay_crl_rdy

okay

yes

so how does the IDELAYCTRL know that 50Mhz isn't 100MHz with 2 clock cycles high/low

Maybe it means that in the case of changing the frequency?

If it has some internal pll it could know that it was low for x clock cycles of the previous clock

well, not the delay element, the delay control element

i.e. it would be way more likely that it generates 200MHz out of 100Mhz or even 50MHz

Or how does it know what the input frequency is?

i dont know a lot about that but i think the +-10% variation for the clock in the datasheet are realistic if they use an on silicon osc of some kind

as I said, my best guess would be a narrow band PLL

(i.e. PLL locking and delaying way out of specified range)

I guess one thing that we could try is looking at a fixed data frequency and then trying different idelayctrl refclock frequencies, that help clear something up

yep, good idea

off for now ... bbl