#milkymist IRC log for Saturday, 2013-09-14

lekernelfixed video-out on the first board (that had only the red channel). green and blue were short-circuited to ground by the TVS or its solders.09:18
lekernelHDMI 0, 2 and 3 are fully OK on that one too. HDMI-1 shows the same symptoms as the other board. this looks suspicious.09:22
lekernelcould be just a ISE/slowtan bug, though ...09:23
lekernelwhat? the slowtan6 differential phase detector works on the first try?15:14
GitHub0[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/0XApYA15:18
GitHub0milkymist-ng/master ffe4bff Sebastien Bourdeauducq: dvisampler: use hard differential phase detector15:18
lekernelhmm, the bad news is the PLL VCO needs to be kept in the 400-1080MHz range, and pixel clocks have more variation than that15:22
lekernelI suppose the LM32 will have to send dynamic reconfiguration commands to the PLLs to adapt to different pixel clock ranges ...15:23
larschere is some C code to reconfigure the mmcm: https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/clk/clk-axi-clkgen.c15:32
GitHub51[mibuild] sbourdeauducq pushed 1 new commit to master: http://git.io/Yo7F3Q17:39
GitHub51mibuild/master ebe8a27 Sebastien Bourdeauducq: mixxeo: swap pairs 0 and 1 on DVI117:39
lekernelall works now :)17:39
azonenberglekernel: re your PLL problems18:31
azonenbergwhat are you trying to mux?18:31
lekernelclock from two HDMI ports18:31
azonenbergxilinx has an appnote on dynamic pll reconfiguration if it comes to that18:31
azonenbergbut that's for changing multipliers and stuff18:31
lekernelas I don't have enough PLLs to dedicate one to each port18:31
azonenbergSo why will a BUFGMUX not work?18:32
azonenbergnot enough BUFGs?18:32
lekernelyes, it will come to that, but for a different reason - keeping the VCO in the specified frequency range over large variations of the pixel clock18:32
azonenbergi'm thinking {IBUFG_1, IBUFG_2} -> BUFGMUX -> PLL18:32
lekernelthree BUFGs?18:32
azonenbergBut that has nothign to do with muxing18:32
azonenbergIn any case, three BUFGs is a serious cost18:32
azonenbergconsidering you only have 1618:32
azonenbergSince this is source-synchronous data you need to preserve phase18:33
lekernelI have tried {IBUF, IBUF} -> BUFGMUX -> PLL18:33
azonenbergAn IBUF doesnt use dedicated routing, afaik18:33
lekerneland the BUFGMUX wont p&r18:33
azonenberg(compared to an IBUFG)18:33
lekernelIBUFG = IBUF + BUFG in series18:33
lekerneland BUFG and BUFGMUX are the same physical resource18:34
azonenberglekernel: Yes, i know18:34
azonenbergHmm18:34
azonenbergoh18:34
azonenbergWhere are your clock inputs located?18:34
azonenbergwhat pins on which chip?18:34
lekernelalso, I'm careful about putting various elements before the PLL. experience with the M1 shows that it tends to cause all sorts of weird PLL behavior.18:35
azonenbergSo, if you want to use one BUFGMUX18:35
lekernelhttp://www.ohwr.org/projects/video-fpga-hdmi-dvi-ethernet/repository/revisions/master/changes/MIXXEO_PCB/Project%20Outputs%20for%20MIXXEO/SCHEMATIC/MIXXEO.PDF18:35
azonenbergYou are going to be routing the clocks from two different pins to one BUFGMUX18:36
azonenbergthe dedicated routing may not exist18:36
azonenbergif you do two BUFGs it will definitely work18:36
azonenbergWhat are the clock net names?18:37
lekerneland yes, there are various annoying restrictions on what clock pin can go to what BUFG18:37
azonenbergHow many clock domains are you using in total?18:37
azonenbergand how many muxes do you need?18:37
lekernelI need to mux the HDMI ports 4:218:38
lekerneleach brings one clock18:38
azonenbergSo you need a two 4:1 clock muxes...18:38
lekernelclocks are HDMIx_TMDS_CLK_p18:38
lekernel2:118:38
azonenbergso inputs 1/2 are muxed to output 1 etc?18:39
azonenbergand 3/4 are muxed to 2?18:39
lekernelthe HDMI receivers can DMA the whole DRAM, and you can simulate a complete mux in software :)18:39
lekernelso yes, we can do that18:39
lekernelor whatever works18:39
azonenbergSo if you have a BUFG for each of the 4 inputs18:39
azonenbergthen two BUFGMUXs18:39
azonenbergthat's six total18:40
azonenbergdo you have enough to spare that many?18:40
lekernelyeah, I have 7 left18:40
azonenbergIncluding the two muxed clocks?18:40
azonenbergor not18:40
azonenbergEither way, if it fits18:40
azonenbergThen problem solved18:40
lekernelhmm, it's dirty, but it could work...18:41
azonenbergI'm actually in the middle of debugging myself... been hunting this one on and off for ten days18:41
azonenbergmy ethernet subsystem randomly stops processing frames after a while18:41
azonenbergas best i can tell it's blocking waiting for a DMA-done acknowledgement from RAM, but the RAM thinks it sent the ack18:41
azonenbergso it's getting dropped somewhere and i haven't yet found where18:41
lekernelthe next problem is to drive the SERDES clocks of the HDMI ports that are in different banks from the same PLL18:41
azonenbergthe same pll?18:42
azonenberghmm... another bufg? :p18:42
azonenbergno, too fast for that18:42
lekernelnot at 1GHz18:42
lekernelyou need to use each bank's dedicated BUFPLL18:42
lekerneland I'm quite sure Xilinx fucked up again on PLL->BUFPLL routing18:42
azonenbergDCM jitter is obvs way too high for this18:42
azonenbergI assume it's too late to go to 7 series?18:43
azonenbergartix7 has way more plls18:43
lekernelthough I have a spare PLL output...18:43
azonenberg(and 32 global clocks)18:43
lekernelso I should be able to stay in the "one PLL output to one BUFPLL" configuration from the reference designs (xilinx wisdom is "anything that isn't in a reference design will have bugs and/or not work at all")18:44
azonenbergafaik, "one PLL to one BUFPLL" is the only possible config18:44
azonenbergi think the BUFPLL is physically wired directly to the PLL and you either use it or don't18:45
lekernelso why is it that from a single PLL, you can drive BUFPLLs in several banks?18:45
azonenbergI didn't think that was possible18:45
lekernelthere are fewer PLLs than IO banks18:46
azonenbergi thought you were supposed to use the pll right next to that bnak18:46
azonenbergbank*18:46
azonenberghmm, sec18:46
lekernelso there has to be something like that18:46
azonenbergUG382... there are two BUFPLLs per bank18:46
lekernelyes, so on the lx45 that makes 8, and there are only 4 PLLs18:47
lekernelso it's not as simple as 1 BUFPLL hardwired to 1 PLL18:47
azonenbergRead UG382 page 5318:47
azonenbergdoesnt answer all the questions but provides some insight18:47
azonenberglooking at the routing in fpga_editor might be of help too18:48
GitHub51[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/5436IA18:54
GitHub51milkymist-ng/master d421aae Sebastien Bourdeauducq: dvisampler: do more deserialization with the ISERDES18:54
lekernelhmm... so I'll try the six-BUFG solution + BUFPLL's on different PLL outputs18:54
lekernelfor the two ports on bank 1, #1 should be enough18:55
lekernelthanks18:55
azonenbergBtw, if you read the table on page 5418:56
azonenbergit looks like CLKOUT0 and CLKOUT1 of the PLL are the only ones that can drive BUFPLLs18:56
lekernelbtw it's only 4 BUFGs, no?18:56
lekernel{IBUF, IBUF+BUFG} -> BUFGMUX should be enough18:57
mumptaimoin19:53
--- Sun Sep 15 201300:00

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