lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
mumptai has quit [Ping timeout: 258 seconds]
Martoni has joined #milkymist
kyak_ is now known as kyak
jaeckel_ is now known as jaeckel
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
lekernel has joined #milkymist
bhamilton has joined #milkymist
<GitHub149> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/GvQzyg
<GitHub149> migen/master b5b29f6 Sebastien Bourdeauducq: bank/description/CSRStorage: set reset property of storage for use in test benches
antgreen has joined #milkymist
mumptai has joined #milkymist
antgreen has quit [Ping timeout: 272 seconds]
<GitHub151> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/JcPJBg
<GitHub151> migen/master 12deaa9 Sebastien Bourdeauducq: flow/network/DataFlowGraph: add_buffered_connection
antgreen has joined #milkymist
kyak has quit [Quit: Lost terminal]
<larsc> what's the original resolution supposed to be?
<lekernel> 640*480
<lekernel> but several frames, so the repeat is normal
<lekernel> I just get 2 megabytes of raw data (plus padding) from the HDMI red channel
<larsc> and you stored each 10bit character in a 16bit word in memory?
bhamilton has quit [Read error: No route to host]
bhamilton has joined #milkymist
<lekernel> yes
<lekernel> so much memory bandwidth, so much memory capacity, so little time :)
<lekernel> it's
<lekernel> just a hack anyway
kyak has joined #milkymist
kyak has quit [Changing host]
kyak has joined #milkymist
<larsc> I really wonder where these extra two hsyncs come from after the first few data bits
<larsc> If you ignore them you get 641 bytes of de
<lekernel> ah, I think that's actually a dma bug
<lekernel> the 16-bit words are reversed in 128-bit memory bus words
<lekernel> I have it fixed, but the ISE shitware fails timing with that seemingly innocuous fix
<lekernel> probably easier to fix that in the python script, lol
<larsc> yea that makes sense, since it is 6xde,2xhs
jevin has quit [Quit: Textual IRC Client: www.textualapp.com]
jevin has joined #milkymist
<larsc> kind of funny that it still syncs at the correct offset
<larsc> and the decoded image data now looks worse
<lekernel> got 480 lines between vsyncs too?
<lekernel> aha! what did you change?
<larsc> swapped w1 and w2
<larsc> plus the reordering
<Fallenou> hehe I can read the text out of it :)
<lekernel> can you send a diff?
<lekernel> thanks
<larsc> although I'm not quite sure why swapping w1 and w2 is necessary
<larsc> unless you reverse the bitorder somewhere
<lekernel> well maybe the bit order is fucked too
<lekernel> raw_words = raw_words[4:-4] <== another workaround?
<larsc> well the last 4 bytes seem to be markes 0xdede
<larsc> and the the first full 128bit word seems to start at offset 4
<lekernel> hmm, I see
<lekernel> let me fix that correctly :)
<larsc> it tried something like that and it took forever
<lekernel> and indexing the list doesn't? weird...
<larsc> what I did was sum([list(reversed(list(x))) for x in zip(it, it, it, it, it, it, it, it)], [])
<lekernel> my code is regularly slow here
<lekernel> "fast enough" as Pythoners say
<larsc> I guess the swapping makes sense, since the bits are of course stored in reveresed order. The first bit is the lowest bit
<larsc> bit 9 in the data word is bit 0 in the datastream
<lekernel> larsc, pushed new raw_dvi file without the alignment problem and with the words in the right order
<lekernel> well if git doesn't crash
<lekernel> wtf...
<lekernel> done
<larsc> what exactly did you change?
<larsc> cause I now get lots of words where the upper 6bits are non zero
bhamilton has left #milkymist [#milkymist]
<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])
<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)
<lekernel> hmm yes, the upper 6 bits are funny
<lekernel> maybe coming from the timing issue :) let's keep the reversed bits then...
<lekernel> s/reversed bits/reversed words
<lekernel> ah, the joys of FPGA debugging
<larsc> well it seems to work if I just ignore them
<lekernel> yes, same here
<lekernel> also the character sync is stable at 9
<lekernel> without having to use a large value for the counter threshold
<larsc> actually it's the lower 6 bits we need to ignore
<lekernel> let's use a design that meets timing and try to avoid having too many loose ends ...
<lekernel> correction: the character sync is still unstable ...
<lekernel> it looks as if the 8b10b decoding is wrong... let's try with a color gradient
<larsc> the one on hw?
<lekernel> both I think
<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
<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)
<larsc> but the image looks more or less fine doesn't it?
<lekernel> no, it doesn't... look eg at the antialiased text
<lekernel> it should be a progressive color changes, but here there are spikes everytime
<lekernel> a full gradient should show this problem very well
<lekernel> ah, actually sync is on blue :)
<lekernel> not red
<lekernel> and we're sampling the *blue* channel right now
<lekernel> and the gradient is totally messed, just as I expected
<larsc> yep
<larsc> so the dvi spec is wrong?
<larsc> there has to be a sample of an 10bit 8bit pair somewhere on the internet
<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."
<lekernel> so be careful
jimmythehorn has quit [Quit: jimmythehorn]
Martoni has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0/20130329043827]]
zumbi has quit [Quit: Changing server]
<larsc> can you send out an image with just one color and see if the pixel values match?
<lekernel> hmm, this sounds tricky since my GPU does gamma/color temperature adjustement... not sure how to disable this
zumbi_ has joined #milkymist
<lekernel> p.13 "The 9th bit indicates no encoding is required to minimize transitions, as there are no transitions between each bit [Figure 12]. "
<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
<larsc> if the 9 bit is set you invert bits 7 to 0
<lekernel> that's the DC balance bit
<lekernel> but the second step which actually minimizes transitions is controlled by bit 8
<lekernel> according to the DVI spec this switches between XOR and XNOR
<larsc> yes
<lekernel> according to this silicon image paper, this switches between no-change and some encoding
<larsc> but that doesn't seem to be right either
jimmythehorn has joined #milkymist
<larsc> can you try a gray gradient?
<lekernel> that's exactly like a gray gradient... we're only sampling the blue channel
<larsc> it should be if everything is alright
<lekernel> you think there is inter-channel crosstalk?
<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
<larsc> otherwise they seem to be messed up
<larsc> on the other hand the gradient tool icon has a gray gradient and looks wrong as well
<larsc> hm, in the transmitter I just posted he also seems to invert bit 8
<larsc> or the 9th bit
<larsc> at least sometimes
<larsc> hm, wrote a encoder in python and there seems to be indeed a problem somewhere
<larsc> 1/4 of the decoded values is wrong
<larsc> ah no, was the encoder
<larsc> nope, decoder is alright
<larsc> just tried all possible values
<lekernel> white is decoded as 7f
<lekernel> instead of ff
<lekernel> and black 00 -> 01
<larsc> whats the raw value for white?
<lekernel> it should be ff - but the GPU might do some color correction before sending to HDMI
<lekernel> 01 instead of 00 might be normal, but 7f instead of ff looks wrong
<larsc> I mean the raw 8b10b value you receive
<lekernel> 0b1010000000 or 0b0001111111
<lekernel> it seems
<lekernel> I also get some 0b1001111111
<lekernel> and 0b0010000000
<larsc> I get 0b0011010101 0b1000101010 0b0101111111 0b1110000000
<larsc> that's like inverted
<larsc> try to insert a b = ~b & 0x3ff at the beginning of decode
<lekernel> still looks wrong ...
<larsc> can you push the grayscale data? I think I might figured it out
<lekernel> larsc, done
jevin has quit [Quit: Textual IRC Client: www.textualapp.com]
<lekernel> the two resulting "gradients" are exactly the same, so it does not look like electrical noise/failure
<lekernel> unless it's some "clever" electrical bug again...
<larsc> i've ploted b[9] and b[8] and where it fails is where b[8] is 1
<larsc> maybe they got a different definition of xor ;)
<larsc> also the noise seems to be in the upper bit
<larsc> if I mask it out the colors are much more uniform
<lekernel> trying an "all white" picture atm
<lekernel> it becomes an gray picture with values oscillating between 7e and 7f
<lekernel> the pattern is regular, it's a 7f image with a 1px 7e vertical bar every 7 pixels
<lekernel> the original values for 7e are ['0010000000', '1001111111'] and for 7f ['1010000000', '0111010101', '0001111111']
<larsc> in which order are they?
<lekernel> 0001111111 1010000000 0001111111 1010000000 0001111111 1010000000
<lekernel> corresponds to six consecutive 7f pixels
<lekernel> what are the two possible values for 255?
<lekernel> 0011111111 and ?
<lekernel> ah 1000000000
<lekernel> how come we see a "1010" pattern there?
<larsc> yep
<lekernel> I see two options... (1) my computer does not send 255 (2) the electrical layer is fucked
<lekernel> (2) would more likely produce random noise than regular patterns and repeatable failures, though....
<lekernel> 0101010101 and 1110101010 also encode 255, but that's hardly "transition minimized" ...
jevin has joined #milkymist
<larsc> well, it's always the 7th bit that flips
<larsc> or well is kind of random
<larsc> but the error is regular
<larsc> I also doubt that this is right http://pastebin.com/jM1kUbYz
<larsc> is this at 75Hz?
<lekernel> yes
<lekernel> let me try 60Hz
<larsc> doesn't really matter I just wanted to confirm the timing
<larsc> so we see 0b1010101011 instead of 0b1101010100 and 0b0101010100 instead of 0b0010101011
playthatbeat has quit [Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/]
playthatbeat has joined #milkymist
<lekernel> that's how it looks like at 60Hz
<lekernel> what a fucked up bug
<lekernel> (was a white/black gradient)
<Fallenou> you seem very close to get it it work completely!
<Fallenou> it to*
<lekernel> no, I'm actually completely lost about what could cause such a terribly confusing behavior
<lekernel> and that's with decoding on the PC, decoding on the FPGA is yet another story...
<Fallenou> happy debugging then :)
<Fallenou> I'm calling it a day for me
<Fallenou> gn8!
<larsc> lekernel: is that with masking out the 7th bit?
<lekernel> no, it's not! :)
<lekernel> confusing heh?
<larsc> funny, that's how it looks for me when i masked it out
<lekernel> it's just 60Hz
<lekernel> yes, so that was the first thing I checked ...
<lekernel> and the 7th bit is NOT masked
<larsc> another interesting part is we get the control characters at the time we'd expect them, but they are simply the wrong characters
<lekernel> 800*600 @56Hz is super fucked
<lekernel> the character sync oscillates wildly
<lekernel> it generally seems the problems get worse when the pixel clock increases
<larsc> maybe you've activated some kind of anti-tampering mode
<lekernel> so, the m1r4 design has "plenty of visible short-circuits and DRC displays more than 500 errors"
<lekernel> ahem
<lekernel> (trying to get a board with integrated hdmi into production ...)
<GitHub103> [milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/QPvXMw
<GitHub103> milkymist-ng/master 53e5c4f Sebastien Bourdeauducq: build: only add UCF constraints for the cores that are present
<GitHub103> milkymist-ng/master 26c0261 Sebastien Bourdeauducq: Remove unneeded file
<lekernel> oh yes, they did the layout in PADS and then converted to Altium ...
<lekernel> with errors
<lekernel> and then gerbers are coming from PADS, which explains why the boards worked even though the altium files are fucked
<lekernel> GNNMNMNMGH
<lekernel> nothing works today
lekernel has quit [Quit: Leaving]
mumptai has quit [Quit: Verlassend]