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

GitHub149[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/GvQzyg09:51
GitHub149migen/master b5b29f6 Sebastien Bourdeauducq: bank/description/CSRStorage: set reset property of storage for use in test benches09:51
GitHub151[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/JcPJBg11:27
GitHub151migen/master 12deaa9 Sebastien Bourdeauducq: flow/network/DataFlowGraph: add_buffered_connection11:27
lekernellarsc, https://github.com/sbourdeauducq/dvidebug12:19
larscwhat's the original resolution supposed to be?12:49
lekernelbut several frames, so the repeat is normal12:51
lekernelI just get 2 megabytes of raw data (plus padding) from the HDMI red channel12:52
larscand you stored each 10bit character in a 16bit word in memory?13:18
lekernelso much memory bandwidth, so much memory capacity, so little time :)13:36
lekerneljust a hack anyway13:37
larscI really wonder where these extra two hsyncs come from after the first few data bits13:48
larscIf you ignore them you get 641 bytes of de14:00
lekernelah, I think that's actually a dma bug14:01
lekernelthe 16-bit words are reversed in 128-bit memory bus words14:02
lekernelI have it fixed, but the ISE shitware fails timing with that seemingly innocuous fix14:02
lekernelprobably easier to fix that in the python script, lol14:04
larscyea that makes sense, since it is 6xde,2xhs14:05
larsckind of funny that it still syncs at the correct offset14:59
larscand the decoded image data now looks worse15:02
lekernelgot 480 lines between vsyncs too?15:08
larscah! http://metafoo.de/tst.ppm15:11
lekernelaha! what did you change?15:13
larscswapped w1 and w215:14
larscplus the reordering15:14
Fallenouhehe I can read the text out of it :)15:14
lekernelcan you send a diff?15:17
larscalthough I'm not quite sure why swapping w1 and w2 is necessary15:35
larscunless you reverse the bitorder somewhere15:38
lekernelwell maybe the bit order is fucked too15:39
lekernelraw_words = raw_words[4:-4] <== another workaround?15:39
larscwell the last 4 bytes seem to be markes 0xdede15:40
larscand the the first full 128bit word seems to start at offset 415:41
lekernelhmm, I see15:41
lekernellet me fix that correctly :)15:42
lekernelbtw http://pastebin.com/f4uG1i6X15:44
larscit tried something like that and it took forever15:45
lekerneland indexing the list doesn't? weird...15:46
larscwhat I did was sum([list(reversed(list(x))) for x in zip(it, it, it, it, it, it, it, it)], [])15:46
lekernelmy code is regularly slow here15:47
lekernel"fast enough" as Pythoners say15:48
larscI guess the swapping makes sense, since the bits are of course stored in reveresed order. The first bit is the lowest bit15:55
larscbit 9 in the data word is bit 0 in the datastream15:55
lekernellarsc, pushed new raw_dvi file without the alignment problem and with the words in the right order15:56
lekernelwell if git doesn't crash15:57
larscwhat exactly did you change?15:59
larsccause I now get lots of words where the upper 6bits are non zero16:00
lekernelI aligned the DMA buffer on a memory word boundary (forgot to do it - stupid mistake) which was causing the messed up words at the beginning (which you worked around with [4:-4])16:01
lekerneland put the 16-bit words in order in the 128-bit word (ISE says timing is not met, but it appears to work anyway)16:02
lekernelhmm yes, the upper 6 bits are funny16:03
lekernelmaybe coming from the timing issue :) let's keep the reversed bits then...16:03
lekernels/reversed bits/reversed words16:03
lekernelah, the joys of FPGA debugging16:04
larscwell it seems to work if I just ignore them16:04
lekernelyes, same here16:05
lekernelalso the character sync is stable at 916:05
lekernelwithout having to use a large value for the counter threshold16:05
larscactually it's the lower 6 bits we need to ignore16:07
lekernellet's use a design that meets timing and try to avoid having too many loose ends ...16:09
lekernelcorrection: the character sync is still unstable ...16:13
lekernelit looks as if the 8b10b decoding is wrong... let's try with a color gradient16:21
larscthe one on hw?16:21
lekernelboth I think16:21
lekernelthey're almost the same code. but here the hw doesn't do any decoding, so we're not affected by those hw bugs16:22
lekerneldata from the red channel is dumped directly into DRAM after phase detection (which just adjusts the IO timing and doesn't do character boundary detection or anything)16:23
larscbut the image looks more or less fine doesn't it?16:23
lekernelno, it doesn't... look eg at the antialiased text16:23
lekernelit should be a progressive color changes, but here there are spikes everytime16:24
lekernela full gradient should show this problem very well16:24
lekernelah, actually sync is on blue :)16:29
lekernelnot red16:29
lekerneland we're sampling the *blue* channel right now16:29
lekerneland the gradient is totally messed, just as I expected16:30
larscso the dvi spec is wrong?16:35
larscthere has to be a sample of an 10bit 8bit pair somewhere on the internet16:37
lekernelaccording to wikipedia: "The method is a form of 8b/10b encoding but using a code-set that differs from the original IBM form."16:38
lekernelso be careful16:38
lekernelthe values from p.29 of http://etdncku.lib.ncku.edu.tw/ETD-db/ETD-search-c/getfile?URN=etd-0905106-235808&filename=etd-0905106-235808.pdf match ...16:52
larsccan you send out an image with just one color and see if the pixel values match?17:05
lekernelhmm, this sounds tricky since my GPU does gamma/color temperature adjustement... not sure how to disable this17:08
lekernelp.13 "The 9th bit indicates no encoding is required to minimize transitions, as there are no transitions between each bit [Figure 12]. "17:11
lekernelso there are cases when TMDS does not change the original bits? at first sight, it seems to me the decoding algo from the DVI spec always changes the original data17:12
larscif the 9 bit is set you invert bits 7 to 017:13
lekernelthat's the DC balance bit17:13
lekernelbut the second step which actually minimizes transitions is controlled by bit 817:14
lekernelaccording to the DVI spec this switches between XOR and XNOR17:14
lekernelaccording to this silicon image paper, this switches between no-change and some encoding17:14
larscbut that doesn't seem to be right either17:24
larsccan you try a gray gradient?17:29
lekernelthat's exactly like a gray gradient... we're only sampling the blue channel17:29
larscit should be if everything is alright17:30
lekernelyou think there is inter-channel crosstalk?17:31
larscbut if you take a look at the decoded image the colors are correct if there is an equal ammount of red/green/blue17:31
larscotherwise they seem to be messed up17:31
larscon the other hand the gradient tool icon has a gray gradient and looks wrong as well17:34
larschm, in the transmitter I just posted he also seems to invert bit 817:36
larscor the 9th bit17:36
larscat least sometimes17:36
larschm, wrote a encoder in python and there seems to be indeed a problem somewhere17:58
larsc1/4 of the decoded values is wrong17:58
larscah no, was the encoder17:59
larscnope, decoder is alright18:02
larscjust tried all possible values18:02
lekernelwhite is decoded as 7f18:03
lekernelinstead of ff18:03
lekerneland black 00 -> 0118:03
larscwhats the raw value for white?18:05
lekernelit should be ff - but the GPU might do some color correction before sending to HDMI18:05
lekernel01 instead of 00 might be normal, but 7f instead of ff looks wrong18:06
larscI mean the raw 8b10b value you receive18:06
lekernel0b1010000000 or 0b000111111118:07
lekernelit seems18:07
lekernelI also get some 0b100111111118:08
lekerneland 0b001000000018:09
larscI get 0b0011010101 0b1000101010 0b0101111111 0b111000000018:10
larscthat's like inverted18:10
larsctry to insert a b = ~b & 0x3ff at the beginning of decode18:11
lekernelstill looks wrong ...18:14
larsccan you push the grayscale data? I think I might figured it out18:32
lekernellarsc, done18:48
lekernelthe two resulting "gradients" are exactly the same, so it does not look like electrical noise/failure19:08
lekernelunless it's some "clever" electrical bug again...19:09
larsci've ploted b[9] and b[8] and where it fails is where b[8] is 119:13
larscmaybe they got a different definition of xor ;)19:13
larscalso the noise seems to be in the upper bit19:31
larscif I mask it out the colors are much more uniform19:32
lekerneltrying an "all white" picture atm19:37
lekernelit becomes an gray picture with values oscillating between 7e and 7f19:39
lekernelthe pattern is regular, it's a 7f image with a 1px 7e vertical bar every 7 pixels19:42
lekernelthe original values for 7e are ['0010000000', '1001111111'] and for 7f ['1010000000', '0111010101', '0001111111']19:48
larscin which order are they?19:48
lekernel0001111111 1010000000 0001111111 1010000000 0001111111 101000000019:51
lekernelcorresponds to six consecutive 7f pixels19:52
lekernelwhat are the two possible values for 255?19:56
lekernel0011111111 and ?19:57
lekernelah 100000000019:57
lekernelhow come we see a "1010" pattern there?19:58
lekernelI see two options... (1) my computer does not send 255 (2) the electrical layer is fucked19:59
lekernel(2) would more likely produce random noise than regular patterns and repeatable failures, though....20:00
lekernel0101010101 and 1110101010 also encode 255, but that's hardly "transition minimized" ...20:04
larscwell, it's always the 7th bit that flips20:04
larscor well is kind of random20:04
larscbut the error is regular20:06
larscI also doubt that this is right http://pastebin.com/jM1kUbYz20:38
larscis this at 75Hz?20:40
lekernellet me try 60Hz20:41
larscdoesn't really matter I just wanted to confirm the timing20:43
larscso we see 0b1010101011 instead of 0b1101010100 and 0b0101010100 instead of 0b001010101120:48
lekernelthat's how it looks like at 60Hz21:03
lekernelwhat a fucked up bug21:03
lekernel(was a white/black gradient)21:03
Fallenouyou seem very close to get it it work completely!21:03
Fallenouit to*21:04
lekernelno, I'm actually completely lost about what could cause such a terribly confusing behavior21:04
lekerneland that's with decoding on the PC, decoding on the FPGA is yet another story...21:05
Fallenouhappy debugging then :)21:06
FallenouI'm calling it a day for me21:06
larsclekernel: is that with masking out the 7th bit?21:06
lekernelno, it's not! :)21:07
lekernelconfusing heh?21:07
larscfunny, that's how it looks for me when i masked it out21:07
lekernelit's just 60Hz21:07
lekernelyes, so that was the first thing I checked ...21:07
lekerneland the 7th bit is NOT masked21:07
larscanother interesting part is we get the control characters at the time we'd expect them, but they are simply the wrong characters21:10
lekernel800*600 @56Hz is super fucked21:11
lekernelthe character sync oscillates wildly21:11
lekernelit generally seems the problems get worse when the pixel clock increases21:15
larscmaybe you've activated some kind of anti-tampering mode21:22
lekernelso, the m1r4 design has "plenty of visible short-circuits and DRC displays more than 500 errors"21:52
lekernel(trying to get a board with integrated hdmi into production ...)21:53
GitHub103[milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/QPvXMw21:58
GitHub103milkymist-ng/master 26c0261 Sebastien Bourdeauducq: Remove unneeded file21:58
GitHub103milkymist-ng/master 53e5c4f Sebastien Bourdeauducq: build: only add UCF constraints for the cores that are present21:58
lekerneloh yes, they did the layout in PADS and then converted to Altium ...22:02
lekernelwith errors22:02
lekerneland then gerbers are coming from PADS, which explains why the boards worked even though the altium files are fucked22:02
lekernelnothing works today22:03
--- Fri May 3 201300:00

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