GitHub149 | [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/GvQzyg | 09:51 |
---|---|---|
GitHub149 | migen/master b5b29f6 Sebastien Bourdeauducq: bank/description/CSRStorage: set reset property of storage for use in test benches | 09:51 |
GitHub151 | [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/JcPJBg | 11:27 |
GitHub151 | migen/master 12deaa9 Sebastien Bourdeauducq: flow/network/DataFlowGraph: add_buffered_connection | 11:27 |
lekernel | larsc, https://github.com/sbourdeauducq/dvidebug | 12:19 |
larsc | what's the original resolution supposed to be? | 12:49 |
lekernel | 640*480 | 12:51 |
lekernel | but several frames, so the repeat is normal | 12:51 |
lekernel | I just get 2 megabytes of raw data (plus padding) from the HDMI red channel | 12:52 |
larsc | and you stored each 10bit character in a 16bit word in memory? | 13:18 |
lekernel | yes | 13:35 |
lekernel | so much memory bandwidth, so much memory capacity, so little time :) | 13:36 |
lekernel | it's | 13:37 |
lekernel | just a hack anyway | 13:37 |
larsc | I really wonder where these extra two hsyncs come from after the first few data bits | 13:48 |
larsc | If you ignore them you get 641 bytes of de | 14:00 |
lekernel | ah, I think that's actually a dma bug | 14:01 |
lekernel | the 16-bit words are reversed in 128-bit memory bus words | 14:02 |
lekernel | I have it fixed, but the ISE shitware fails timing with that seemingly innocuous fix | 14:02 |
lekernel | probably easier to fix that in the python script, lol | 14:04 |
larsc | yea that makes sense, since it is 6xde,2xhs | 14:05 |
larsc | kind of funny that it still syncs at the correct offset | 14:59 |
larsc | and the decoded image data now looks worse | 15:02 |
lekernel | got 480 lines between vsyncs too? | 15:08 |
larsc | ah! http://metafoo.de/tst.ppm | 15:11 |
lekernel | aha! what did you change? | 15:13 |
larsc | swapped w1 and w2 | 15:14 |
larsc | plus the reordering | 15:14 |
Fallenou | hehe I can read the text out of it :) | 15:14 |
lekernel | can you send a diff? | 15:17 |
larsc | http://pastebin.com/MdN7bpPw | 15:20 |
lekernel | thanks | 15:22 |
larsc | although I'm not quite sure why swapping w1 and w2 is necessary | 15:35 |
larsc | unless you reverse the bitorder somewhere | 15:38 |
lekernel | well maybe the bit order is fucked too | 15:39 |
lekernel | raw_words = raw_words[4:-4] <== another workaround? | 15:39 |
larsc | well the last 4 bytes seem to be markes 0xdede | 15:40 |
larsc | and the the first full 128bit word seems to start at offset 4 | 15:41 |
lekernel | hmm, I see | 15:41 |
lekernel | let me fix that correctly :) | 15:42 |
lekernel | btw http://pastebin.com/f4uG1i6X | 15:44 |
larsc | it tried something like that and it took forever | 15:45 |
lekernel | and indexing the list doesn't? weird... | 15:46 |
larsc | what I did was sum([list(reversed(list(x))) for x in zip(it, it, it, it, it, it, it, it)], []) | 15:46 |
lekernel | my code is regularly slow here | 15:47 |
lekernel | "fast enough" as Pythoners say | 15:48 |
larsc | I guess the swapping makes sense, since the bits are of course stored in reveresed order. The first bit is the lowest bit | 15:55 |
larsc | bit 9 in the data word is bit 0 in the datastream | 15:55 |
lekernel | larsc, pushed new raw_dvi file without the alignment problem and with the words in the right order | 15:56 |
lekernel | well if git doesn't crash | 15:57 |
lekernel | wtf... | 15:58 |
lekernel | done | 15:58 |
larsc | what exactly did you change? | 15:59 |
larsc | cause I now get lots of words where the upper 6bits are non zero | 16:00 |
lekernel | I 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 |
lekernel | and 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 |
lekernel | hmm yes, the upper 6 bits are funny | 16:03 |
lekernel | maybe coming from the timing issue :) let's keep the reversed bits then... | 16:03 |
lekernel | s/reversed bits/reversed words | 16:03 |
lekernel | ah, the joys of FPGA debugging | 16:04 |
larsc | well it seems to work if I just ignore them | 16:04 |
lekernel | yes, same here | 16:05 |
lekernel | also the character sync is stable at 9 | 16:05 |
lekernel | without having to use a large value for the counter threshold | 16:05 |
larsc | actually it's the lower 6 bits we need to ignore | 16:07 |
lekernel | let's use a design that meets timing and try to avoid having too many loose ends ... | 16:09 |
lekernel | correction: the character sync is still unstable ... | 16:13 |
lekernel | it looks as if the 8b10b decoding is wrong... let's try with a color gradient | 16:21 |
larsc | the one on hw? | 16:21 |
lekernel | both I think | 16:21 |
lekernel | they're almost the same code. but here the hw doesn't do any decoding, so we're not affected by those hw bugs | 16:22 |
lekernel | data 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 |
larsc | but the image looks more or less fine doesn't it? | 16:23 |
lekernel | no, it doesn't... look eg at the antialiased text | 16:23 |
lekernel | it should be a progressive color changes, but here there are spikes everytime | 16:24 |
lekernel | a full gradient should show this problem very well | 16:24 |
lekernel | ah, actually sync is on blue :) | 16:29 |
lekernel | not red | 16:29 |
lekernel | and we're sampling the *blue* channel right now | 16:29 |
lekernel | and the gradient is totally messed, just as I expected | 16:30 |
lekernel | http://milkymist.org/gradient_bug.png | 16:33 |
larsc | yep | 16:35 |
larsc | so the dvi spec is wrong? | 16:35 |
larsc | there has to be a sample of an 10bit 8bit pair somewhere on the internet | 16:37 |
lekernel | according 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 |
lekernel | so be careful | 16:38 |
lekernel | the 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 |
larsc | can you send out an image with just one color and see if the pixel values match? | 17:05 |
lekernel | hmm, this sounds tricky since my GPU does gamma/color temperature adjustement... not sure how to disable this | 17:08 |
lekernel | http://www.siliconimage.com/docs/SiI-WP-007-A.pdf | 17:11 |
lekernel | p.13 "The 9th bit indicates no encoding is required to minimize transitions, as there are no transitions between each bit [Figure 12]. " | 17:11 |
lekernel | so 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 data | 17:12 |
larsc | if the 9 bit is set you invert bits 7 to 0 | 17:13 |
lekernel | that's the DC balance bit | 17:13 |
lekernel | but the second step which actually minimizes transitions is controlled by bit 8 | 17:14 |
lekernel | according to the DVI spec this switches between XOR and XNOR | 17:14 |
larsc | yes | 17:14 |
lekernel | according to this silicon image paper, this switches between no-change and some encoding | 17:14 |
larsc | but that doesn't seem to be right either | 17:24 |
larsc | http://hamsterworks.co.nz/mediawiki/index.php/Dvid_test | 17:24 |
larsc | can you try a gray gradient? | 17:29 |
lekernel | that's exactly like a gray gradient... we're only sampling the blue channel | 17:29 |
larsc | it should be if everything is alright | 17:30 |
lekernel | you think there is inter-channel crosstalk? | 17:31 |
larsc | but if you take a look at the decoded image the colors are correct if there is an equal ammount of red/green/blue | 17:31 |
larsc | otherwise they seem to be messed up | 17:31 |
larsc | on the other hand the gradient tool icon has a gray gradient and looks wrong as well | 17:34 |
larsc | hm, in the transmitter I just posted he also seems to invert bit 8 | 17:36 |
larsc | or the 9th bit | 17:36 |
larsc | at least sometimes | 17:36 |
lekernel | http://milkymist.org/gradient_bug_gray.png | 17:37 |
larsc | hm, wrote a encoder in python and there seems to be indeed a problem somewhere | 17:58 |
larsc | 1/4 of the decoded values is wrong | 17:58 |
larsc | ah no, was the encoder | 17:59 |
larsc | nope, decoder is alright | 18:02 |
larsc | just tried all possible values | 18:02 |
lekernel | white is decoded as 7f | 18:03 |
lekernel | instead of ff | 18:03 |
lekernel | and black 00 -> 01 | 18:03 |
larsc | whats the raw value for white? | 18:05 |
lekernel | it should be ff - but the GPU might do some color correction before sending to HDMI | 18:05 |
lekernel | 01 instead of 00 might be normal, but 7f instead of ff looks wrong | 18:06 |
larsc | I mean the raw 8b10b value you receive | 18:06 |
lekernel | 0b1010000000 or 0b0001111111 | 18:07 |
lekernel | it seems | 18:07 |
lekernel | I also get some 0b1001111111 | 18:08 |
lekernel | and 0b0010000000 | 18:09 |
larsc | I get 0b0011010101 0b1000101010 0b0101111111 0b1110000000 | 18:10 |
larsc | that's like inverted | 18:10 |
larsc | try to insert a b = ~b & 0x3ff at the beginning of decode | 18:11 |
lekernel | still looks wrong ... | 18:14 |
larsc | can you push the grayscale data? I think I might figured it out | 18:32 |
lekernel | larsc, done | 18:48 |
lekernel | the two resulting "gradients" are exactly the same, so it does not look like electrical noise/failure | 19:08 |
lekernel | unless it's some "clever" electrical bug again... | 19:09 |
larsc | i've ploted b[9] and b[8] and where it fails is where b[8] is 1 | 19:13 |
larsc | maybe they got a different definition of xor ;) | 19:13 |
larsc | also the noise seems to be in the upper bit | 19:31 |
larsc | if I mask it out the colors are much more uniform | 19:32 |
lekernel | trying an "all white" picture atm | 19:37 |
lekernel | it becomes an gray picture with values oscillating between 7e and 7f | 19:39 |
lekernel | the pattern is regular, it's a 7f image with a 1px 7e vertical bar every 7 pixels | 19:42 |
lekernel | the original values for 7e are ['0010000000', '1001111111'] and for 7f ['1010000000', '0111010101', '0001111111'] | 19:48 |
larsc | in which order are they? | 19:48 |
lekernel | 0001111111 1010000000 0001111111 1010000000 0001111111 1010000000 | 19:51 |
lekernel | corresponds to six consecutive 7f pixels | 19:52 |
lekernel | what are the two possible values for 255? | 19:56 |
lekernel | 0011111111 and ? | 19:57 |
lekernel | ah 1000000000 | 19:57 |
lekernel | how come we see a "1010" pattern there? | 19:58 |
larsc | yep | 19:58 |
lekernel | I see two options... (1) my computer does not send 255 (2) the electrical layer is fucked | 19:59 |
lekernel | (2) would more likely produce random noise than regular patterns and repeatable failures, though.... | 20:00 |
lekernel | 0101010101 and 1110101010 also encode 255, but that's hardly "transition minimized" ... | 20:04 |
larsc | well, it's always the 7th bit that flips | 20:04 |
larsc | or well is kind of random | 20:04 |
larsc | but the error is regular | 20:06 |
larsc | I also doubt that this is right http://pastebin.com/jM1kUbYz | 20:38 |
larsc | is this at 75Hz? | 20:40 |
lekernel | yes | 20:41 |
lekernel | let me try 60Hz | 20:41 |
larsc | doesn't really matter I just wanted to confirm the timing | 20:43 |
larsc | so we see 0b1010101011 instead of 0b1101010100 and 0b0101010100 instead of 0b0010101011 | 20:48 |
lekernel | that's how it looks like at 60Hz | 21:03 |
lekernel | http://milkymist.org/60hz.png | 21:03 |
lekernel | what a fucked up bug | 21:03 |
lekernel | (was a white/black gradient) | 21:03 |
Fallenou | you seem very close to get it it work completely! | 21:03 |
Fallenou | it to* | 21:04 |
lekernel | no, I'm actually completely lost about what could cause such a terribly confusing behavior | 21:04 |
lekernel | and that's with decoding on the PC, decoding on the FPGA is yet another story... | 21:05 |
Fallenou | happy debugging then :) | 21:06 |
Fallenou | I'm calling it a day for me | 21:06 |
Fallenou | gn8! | 21:06 |
larsc | lekernel: is that with masking out the 7th bit? | 21:06 |
lekernel | no, it's not! :) | 21:07 |
lekernel | confusing heh? | 21:07 |
larsc | funny, that's how it looks for me when i masked it out | 21:07 |
lekernel | it's just 60Hz | 21:07 |
lekernel | yes, so that was the first thing I checked ... | 21:07 |
lekernel | and the 7th bit is NOT masked | 21:07 |
larsc | another interesting part is we get the control characters at the time we'd expect them, but they are simply the wrong characters | 21:10 |
lekernel | 800*600 @56Hz is super fucked | 21:11 |
lekernel | the character sync oscillates wildly | 21:11 |
lekernel | it generally seems the problems get worse when the pixel clock increases | 21:15 |
larsc | maybe you've activated some kind of anti-tampering mode | 21:22 |
lekernel | so, the m1r4 design has "plenty of visible short-circuits and DRC displays more than 500 errors" | 21:52 |
lekernel | ahem | 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/QPvXMw | 21:58 |
GitHub103 | milkymist-ng/master 26c0261 Sebastien Bourdeauducq: Remove unneeded file | 21:58 |
GitHub103 | milkymist-ng/master 53e5c4f Sebastien Bourdeauducq: build: only add UCF constraints for the cores that are present | 21:58 |
lekernel | oh yes, they did the layout in PADS and then converted to Altium ... | 22:02 |
lekernel | with errors | 22:02 |
lekernel | and then gerbers are coming from PADS, which explains why the boards worked even though the altium files are fucked | 22:02 |
lekernel | GNNMNMNMGH | 22:03 |
lekernel | nothing works today | 22:03 |
--- Fri May 3 2013 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!