#milkymist IRC log for Thursday, 2013-05-30

GitHub95[mibuild] sbourdeauducq pushed 1 new commit to master: http://git.io/YFzgVQ09:08
GitHub95mibuild/master 548f268 Sebastien Bourdeauducq: platform/rhino: rename ismm data out signal to locked09:08
wpwrak(pattern degeneration) if it's a problem with phase differences, knowing how the correct pattern gets distorted would allow to quantify the phase error, which in turn may (*) allow picking the most stable value14:24
wpwrak(*) assuming you can adjust the phase14:24
lekernelthe clock/phase relationship is already adjusted using oversampling with edge detection14:37
lekernelthe system samples at 2x the data rate and adjusts the data input delay to make the middle extra sample have 50% of 1's and 50% of 0's at each transition14:38
lekernelyou have to do this sort of thing because the skew is spec'd to many bit times in HDMI/DVI14:39
lekerneland can be different for each channel14:39
wpwrakmaybe this algorithm gets thrown off sometimes ?15:18
wpwrakit may also not be phase directly but bit width. e.g., a "1" may be longer or shorter than a "0". so if you take random samples from a perfectly balanced stream, you should actually see more of one type than of the other15:19
wpwrakand if you try to force your detection to yield 50/50, you'd basically have to hop around the phase15:20
lekernelno it doesn't - it's under software control, only runs at 2Hz and prints results on the serial console15:22
wpwrakone way to find out if this is the case would be by disabling phase adjustment and just collecting samples at the bit clock. then see what ratio you get. if you're close to 50/50, then there's no issue. if it's more like 30/70, then there may be an issue15:22
lekernelthe delay only oscillates by a few dozen ps15:22
wpwrakhmm, so you have the delay (ps) for fine-tuning plus a larger offset for the skew (multi-bit, so in the many ns range)15:24
lekernelyes15:24
lekernelfine tuning is done to recover bits15:25
lekernelthen there is character synchronization to recover words15:25
wpwrakah, i see15:25
lekerneland finally inter-channel deskew to make the words match on all 3 channels (done by exploiting the fact that hsync/vsync happen exactly at the same time on the 3 channels)15:26
wpwrakokay, that sounds reasonable. the 50/50 fine-tuning could still settle on being very close to an edge15:27
lekernelcharacter synchronization is done by checking for all 9 possible shifts of the concatenation of the last 2 words, and if one of those shifts keeps yielding the same valid control word then it gets selected15:28
wpwrak"the same" control word ? the same as what ?15:29
lekernelduring a blank period the control words are repeated. it checks for this.15:29
wpwrakokay15:30
lekernelthis avoids false positive since control words have more transitions than normal data15:30
wpwraksounds good. tricky protocol :)15:30
wpwrakbut the fine-tuning still seems suspicious. if you have edges at times 0 and 1, it could settle, say, on 0.1, and never realize it's at risk of getting thrown off by even a slight disturbance, right ?15:32
lekernelok so the algo works like this:15:33
lekernelat transitions (and only at transitions) it checks for the middle sample15:33
lekernelif you have a transition like15:33
lekernel0 ---[0]---> 1 then you are probably sampling too early, since the middle sample is still in the 0 region15:34
wpwrakbit in:  ...abc...  then if (a != b) sample(c);  ?15:34
wpwrakoh, i see that way15:34
lekernel0 ---[1]---> 1 then you are probably sampling too late, since the middle sample has arrived in the 1 region15:34
lekerneland same for 1->0 transitions15:35
lekernelthen you increment/decrement a counter when it's early/late15:35
wpwrakokay, you're sampling the edge. good. that should be precise then. it also answers my next question, how you know which way to tune :)15:35
lekerneland if counter reaches a certain absolute value, then you adjust the input data delay by some dozen ps15:36
lekernelthe way it's done is: the gateware signals the software when the counter has reached that point (and freezes the counter), then the software has to change the delay and reset the counter15:37
wpwrak001 and 110 are both treated as the same "early" ? or do you distinguish 0->1 and 1->0 transitions15:37
lekerneldetected as the same early15:37
wpwrakso non-50/50 duty cycles should cancel each other out if the threshold is large enough. good.15:38
lekernelI've actually tested that thing with a cable like this: https://pbs.twimg.com/media/BF4h83xCUAAI_Jb.jpg:large15:39
wpwrak;-))15:39
lekerneland the delay resulting from this algo is smaller on the shortened pair15:39
lekernels/smaller/longer15:40
wpwrakcan you run three counters, one at -1 delay, one at 0 (i.e., like the one you have now), the third at +1 delay ? that would allow you to tell whether the delay adjustment conclusion was correct15:43
lekernelno, there's only one delay unit per io pin15:44
wpwrakdarn15:44
lekernelbut that thing really seems to work... there's little oscillation15:44
lekernelonly by a couple taps of the delay unit, which is a couple dozen ps15:45
lekerneland adjusting the delay does not corrupt the data going through the delay unit15:45
wpwrakso you have good edges but bad bits ? hmm ...15:45
lekernelremember the erroneous words happen in bursts15:46
lekernelprobably much shorter than the 500ms period of the software phase adjustements15:46
lekernelso they may cause a shift by one tap, but you won't notice it from the rest of the noise15:47
wpwrakso you know how phase/delay adjustments are related to error bursts ? (in the time of occurrence)15:47
lekernelno, I don't15:47
lekernelthe system only adjusts by one tap (dozen ps) maximum every 500ms15:48
lekernelan short error burst happening between two phase adjustements will be lost in the noise15:48
lekernelnote that during many phase adjustement periods, WER=015:49
lekernelthe error burst happen maybe every 2s or so15:49
wpwrakhow often does the bit skew adjuster run ?15:50
lekernelevery 500ms15:50
lekerneland it only does correction by one tap maximum15:50
lekernelevery time15:50
lekernelit's only meant to compensate for temperature and voltage drift15:50
wpwraki mean the one that matches shifted patterns15:50
lekernelthere is of course a faster calibration when the port is plugged15:50
lekernelthe character synchronization? it's hardware and it's on at all times15:51
wpwrakyeah, seems that the fine-tuning is off the hook for now15:51
wpwrak(char sync)  you said it only runs in blank periods. that's between lines or between frames ?15:52
lekernelboth15:52
larsconced it is synced it shouldn't get out of sync again, right?15:54
wpwrakis the source allowed to drop/insert bits ? i.e., can the skew "jump" ?15:54
wpwrakthere are two types of errors i see: 1) incorrect hsync timing ("late"), and 2) stray error bursts in the pixel data15:56
lekernelthe character synchronization switches every time there are 8 *consecutive* appearances of one of the 4 possible control words at the *same* shift position15:56
wpwrakso that suggests synchronization is normally not lost for very long. if a desync event can happen only on horizontal retrace, that would be incompatible with that being the culprint15:57
wpwraks/print/prit/15:57
lekernelnote that the pictures are 100% perfect and WER=0 when there is no DCM_CLKGEN ...15:57
wpwrakand that only happens between lines or frames15:57
lekernelI think the DCM may intermittently lose lock and output a broken clock15:58
wpwrakbut then the fine-tuning ought to run wild15:58
lekernel? why15:58
lekernelno15:58
wpwrakif the clock goes off15:58
wpwrakwell, unless the clock just glitches15:59
lekernelif it goes wrong for less than 500ms you'd only see a shift by one tap15:59
lekernelthen software resets the counter, and if the clock was OK for the next 500ms the tap simply goes back at next phase adj15:59
lekerneland there's also some oscillation by 1-3 taps at all times, so it's really going to be lost in the noise16:00
wpwrakdvisampler0_pix is affected by the DCM ?16:01
lekernelall pix* clocks are from DCM -> PLL16:01
lekernelor just PLL now16:01
wpwrakhow long is the bit period, in taps ?16:01
lekernellots16:01
lekernelmore than 5016:02
lekernel+/- the nice 300% PVT Xilinx has half-spec'd on the IODELAY16:02
wpwrakhmm, if the DCM-PLL combo jitters, i should have seen this16:02
wpwraki.e., here: http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/fpga-2pix-hdmi-clk-ok.png16:03
lekernelit could be some sort of internal FPGA crosstalk too... which could explain the problems when the SDRAM is read on the other board16:03
lekernelI wonder if the CLKGEN removal fixes that too16:03
lekernelwill try...16:03
wpwrak(50 taps) okay, so +/- 3 shouldn't matter16:04
wpwrakif the clock briefly goes out of phase, a comparison between good and bad patterns would still show that16:08
lekernellet me just do that if I run into problems with the PLL alone... I feel I could spend a lifetime investigating every slowtan6 quirk...16:31
lekerneland memory controller issues are causing more damage atm16:32
GitHub136[migen] sbourdeauducq pushed 2 new commits to master: http://git.io/qWvPNQ16:47
GitHub136migen/master f0b0942 Sebastien Bourdeauducq: bitreverse: fhdl/tools -> genlib/misc16:47
GitHub136migen/master ebbd5eb Sebastien Bourdeauducq: bus/csr/SRAM: better handling of writes to memories larger than the CSR width16:47
GitHub58[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/zds_Ag16:49
GitHub58migen/master cebfe78 Sebastien Bourdeauducq: genlib/misc: fix import16:49
lekernelFallenou, what's wrong with turning the MMU off when entering kernel mode?19:12
GitHub161[milkymist-ng] sbourdeauducq pushed 4 new commits to master: http://git.io/4QGM2g19:42
GitHub161milkymist-ng/master 6d71e09 Sebastien Bourdeauducq: cif: move to milkymist folder19:42
GitHub161milkymist-ng/master 084aa64 Sebastien Bourdeauducq: dvisampler/clocking: remove DCM_CLKGEN19:42
GitHub161milkymist-ng/master 30f5ef8 Sebastien Bourdeauducq: software/videomixer: remove unneeded DCM resets19:42
Fallenoulekernel: I don't know exactly, I've just been told it's not the good thing to do, but I keep digging :)20:51
Fallenouuntil I can see the big picture20:51
Fallenoumaybe that was rubish20:51
Fallenougoing to read the last two answers tomorrow20:52
Fallenougn820:52
--- Fri May 31 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!