lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
jimmythehorn has quit [Quit: jimmythehorn]
jimmythehorn has joined #milkymist
jimmythehorn has quit [Quit: jimmythehorn]
jimmythehorn has joined #milkymist
jimmythehorn has quit [Quit: jimmythehorn]
methril has quit [Quit: Leaving]
Martoni has joined #milkymist
mumptai has joined #milkymist
mumptai has quit [Ping timeout: 240 seconds]
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
sb0 has joined #milkymist
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
_florent_ has joined #milkymist
antgreen has quit [Ping timeout: 255 seconds]
Gurty has quit [Ping timeout: 246 seconds]
<wpwrak> things are looking good. something is coming, and it's from the local postal distribution center, merely some 10 blocks away. i hope it's the parcel, not just a note.
Gurty has joined #milkymist
_florent_ has quit [Ping timeout: 245 seconds]
qwebirc99730 has joined #milkymist
<wpwrak> sb0: shipment received ! with no customs hassles at all that's how i like it :)
<sb0> great!
<sb0> so now be careful: no 5V
<wpwrak> who uses 5 V ? ;-)
<sb0> I actually cut the 5V pins of my M1 so that I can't inadvertently plug the HDMI board into them
<sb0> also used cardboard and double-sided tape on VGA/audio connectors to hold it in place during HDMI connections/disconnections
mumptai has joined #milkymist
<wpwrak> (cut 5 V) nice :)
<wpwrak> lemme see how it fits ..
<sb0> the 5V pins are those closest to the VGA/audio side
<sb0> they should match the two unsoldered pads on the HDMI board
<wpwrak> looks good. lemme check the schematics, just to be sure
<wpwrak> it's actually kinda funny that the board says "Not 5V tolerant" right next to the connector that provides 5 V
<wpwrak> okay. all looks well regarding 5 V
<wpwrak> the HDMI connectors face towards LED/buttons/USB
<sb0> yes
<wpwrak> perfect. where do you keep the schematics, gerbers, etc. of the mider board ?
<wpwrak> s/mider/mixer/
<wpwrak> i'll also need to install migen and the rest of the development environment
<sb0> python3 + mibuild + migen + ISE
<sb0> yes
<sb0> and milkymist-ng
<wpwrak> any preferred version of ISE ?
<sb0> if you have one that worked for the old soc, it should still be fine
<sb0> otherwise take the latest
<wpwrak> lost the old environment in one of those disk failures, so it'll all be fresh
<wpwrak> okay, layout is clear. ah, do you already decode HDMI and produce an image (on VGA) ?
<sb0> no, the series of bugs irritated me beyond reasonable levels so I did something else for a while
<sb0> will get back to it in a short while...
<wpwrak> so there are more bugs ? :)
<sb0> I didn't touch the data interface since last time...
<sb0> next step is to throw the raw data into the DRAM and see if I get something else than garbage
<sb0> almost everything has semi-random behaviour ...
<wpwrak> kewl. if all else fails, you can sell it to the military as a high-entropy random number generator ;-)
kyak has quit [Read error: Connection reset by peer]
<wpwrak> after all, if it's only sometimes random, that makes it more random, right ? :)
kyak has joined #milkymist
kyak has quit [Changing host]
kyak has joined #milkymist
Martoni has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0/20130329043827]]
<wpwrak> ISE download, first stage, 2 hours left :-(
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
jimmythehorn has joined #milkymist
<larsc> 14.5?
Padawan- has quit [Ping timeout: 248 seconds]
<wpwrak> yup
<larsc> we couldn't get it to work so far
<larsc> I think they just break more and more things on purpose so everybody switches to vivado
<sb0> only tried 14.4 ...
<wpwrak> vivado is non-free ? i actually ended up beginning to download vivado. it somehow appeared en route to webpack.
<sb0> larsc, what's broken?
<wpwrak> okay, let's switch to 14.4 then. new download, new luck
<sb0> vivado is free of charge, but when I tried it it was ludicrously slow
<sb0> 'ludicrously' as in '15min compilation for a LED blinker'
<larsc> sb0: I only heard my college cursing, I think it was aborting with some obscure error when building the bistream
<wpwrak> larsc: your colleagues in germany ?
lekernel has joined #milkymist
<larsc> well there is only one
<larsc> or did you mean colleague's
<wpwrak> ah. Mr. Macleod then :)
<larsc> who?
<wpwrak> hmm, he's been with you to romania then. so i can't make the joke that you heard the curses across hundreds of kilometers
<larsc> nope
<larsc> ah, the highlander
<wpwrak> "There can be only one" :)
Padawan- has joined #milkymist
robmyers has quit [Quit: -*- mode: irl -*-]
Padawan- has quit [Changing host]
Padawan- has joined #milkymist
hypermodern_ has joined #milkymist
robmyers has joined #milkymist
qwebirc99730 has quit [Ping timeout: 245 seconds]
robmyers has quit [Quit: -*- mode: irl -*-]
robmyers has joined #milkymist
<lekernel> wpwrak, emailed you the EDID tester source + a bitstream
<lekernel> (compatible with the new migen api)
<lekernel> it also blinks a LED on the pixel clock, you should be able to control the frequency with xrandr
<lekernel> the HDMI port is the one close to VGA/audio (left side when facing the connectors)
<wpwrak> thanks ! setting up the test PC ...
lekernel has quit [Quit: Leaving]
<wpwrak> ah, ubuntu is not happy with my streamlined system. well, that's not entirely unexpected. plan B then ...
<sb0> tried archlinux?
<wpwrak> naw, it didn't come to that yet :)
<Hawk777> Anyone else get a page not found just going to xilinx.com, hovering Products, and clicking Development Tools?
<Hawk777> Or for that matter just clicking Products?
<sb0> yes, same here
<sb0> seems wpwrak started his download just in time :)
<wpwrak> whee, the autocrap family has a new member: autopoint
bhamilton has joined #milkymist
<wpwrak> the download still seems to be going well. except that it slowed down. now it's "7 hours left" :-(
<GitHub152> [migen] sbourdeauducq pushed 3 new commits to master: http://git.io/HZ_YTQ
<GitHub152> migen/master df1ed32 Sebastien Bourdeauducq: genlib/record/connect: add match_by_position
<GitHub152> migen/master 6ce8562 Sebastien Bourdeauducq: flow: match record fields by position
<GitHub152> migen/master 692794a Sebastien Bourdeauducq: flow: use Module and new Record APIs
<wpwrak> to load top.bit ... pld load top.bit and then is it ready or do i need to do something else ?
<GitHub46> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/92lMug
<GitHub46> milkymist-ng/master 950d3a4 Sebastien Bourdeauducq: framebuffer: use new flow API
<sb0> then it's ready... plug the HDMI cable and it should show in xrandr
<wpwrak> drums ...
<sb0> note that there might be problems if you plug it before the bitstream is loaded - the HPD pin is held permanently asserted due to lack of IO pins
<sb0> it didn't cause major issues on my two nvidia cards - it keeps retrying EDID reads, but does not give up
<wpwrak> xrandr sees it
<sb0> ok. now set a mode and the LED should be blinking, and I2C not working anymore.
<wpwrak> let's see ...
<sb0> looks good
<wpwrak> LED blinks happily
<wpwrak> after xrandr --output DVI-1 --mode 640x480
<sb0> is xrandr --verbose capable of displaying the EDID?
<sb0> with the bug that would fail
<wpwrak> "DVI-1 disconnected" suggests that it may not ...
<sb0> ok. so you can reproduce it.
<wpwrak> an no, no EDID in sight. only one from the other screen
bhamilton has left #milkymist [#milkymist]
<wpwrak> that much about "it only happens in the northern hemisphere" :)
<wpwrak> one signal looks pretty good on the M1 side, with bursts of ~4 x 10 cycles every few seconds. 4 Vpp, says my scope. to be verified. the other sits at 2 V, apparently without activity.
<wpwrak> lemme verify that i got the right ones ...
<sb0> 4Vpp?
<sb0> should be 3.3V ...
<sb0> I got both SCL and SDA nicely with the saelae
<wpwrak> scope thinks it's 4 V. will check with a voltmeter in a moment. the HDMI connectors are good grounds, right ?
<sb0> no, they aren't
<sb0> the shells are connected to ground with a parallel RC circuit
<wpwrak> ah, i see. let's see what else i can use that's not too fragile ...
<wpwrak> USB looks good :)
<sb0> soldering a row of 3 pins on top of the connector that goes to M1 works nicely
<sb0> USB is also not a good ground
<wpwrak> ah, damn. the shield is RC'ed too
<wpwrak> ah, and the "4 V" was actually ~3.3 V. so far, so good.
<wpwrak> now let's see what's up with the other signal
<wpwrak> that was the wrong pin. makes sense then, too. now i see a nice and clean signal on the M1 side
<wpwrak> xrandr still thinks it's disconnected
mumptai has quit [Quit: Verlassend]
<GitHub103> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/4xeOOg
<GitHub103> migen/master 746acda Sebastien Bourdeauducq: ioo: move to genlib
<GitHub103> migen/master 1cc4c8e Sebastien Bourdeauducq: uio: remove Trampoline (Python 3.3 provides generator delegation instead)
<wpwrak> if i reload the bitstream, there's a rather extensive dialog, with signals that look just as nice
<larsc> does it look any different with and without hdmi on?
<wpwrak> how would the two states differ ?
<larsc> the amount noise supposedly
<wpwrak> no, i mean: what would i change in the system to be "without hdmi on" ?
<wpwrak> i think before the xrandr --mode, no video signal is output, if you mean that
<sb0> xrandr --output xxx --off
<sb0> yes
<sb0> I think so
<wpwrak> let's try --off and a reconfiguration
<wpwrak> oh, now it came back. just with the --off
<wpwrak> before, i once tried and it stayed "disconnected"
<wpwrak> yeah, --off seems to work
<wpwrak> even without touching the fpga
antgreen has joined #milkymist
<sb0> same here
<wpwrak> the signals also look clean on the other side of the level converters
<wpwrak> not quite as lovely, but should be sufficiently good
<wpwrak> let's see what's happening with the pixel data
<wpwrak> the video side looks pretty dead
<wpwrak> i wonder if it could simply be an I2C/DDC request the M1 doesn't understand
mumptai has joined #milkymist
<larsc> it's all the same
<larsc> or at least should be
<larsc> i2c read on address 0x50
<sb0> I remember seeing the M1 failing to ack the 0x50 address when the video is on
<wpwrak> here's a numeric dump at 100 ns/Sa, suitable for viewing with gnuplot: http://downloads.qi-hardware.com/people/werner/ming/edid/unanswered-scl-sda-100ns.gp.bz2
<wpwrak> to visualize, plot "foo.gp" using 1:($2+4.5) with lines, "foo.gp" using 1:3 with lines
<wpwrak> now, let's decode it ...
<larsc> a couple of reads for 0x50 without an ack
<GitHub109> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/y4Mzqg
<GitHub109> migen/master 72ef4b9 Sebastien Bourdeauducq: ioo+pytholite: use new Module API
<GitHub109> migen/master 4c9018e Sebastien Bourdeauducq: fhdl/visit: add TransformModule
<sb0> gn8
sb0 has quit [Quit: Leaving]
<wpwrak> my decoder says S50WN. i think that means it agrees :)
<wpwrak> actually no. it's a write, according to my decoder.
<larsc> uhm yes
<larsc> it might want to read a certain subpage
<wpwrak> now, as i know sebastien, he probably didn't implement writes ... :) let's see ...
<larsc> it looks it if it ignores the read/write bit
<larsc> but always responds
<wpwrak> milkymist-ng/milkymist/dvisampler/edid.py:179 does indeed look a little suspicious
<wpwrak> i seems to consider the bit, but doesn't know what to do with a write
<larsc> hm, am I missing something or is the WAIT_START state not implemented?
<wpwrak> and 0x50 is indeed the EDID
<wpwrak> yeah, looks like it
<wpwrak> or maybe there's some default or such. can't quite make sense of it yet
<larsc> might be the for state in states at the bottom
<wpwrak> anyway, i think we have an explanation :)
<wpwrak> yeah, that could be some default clause. or maybe not ;)
<larsc> actually the code looks as if it should handle writes propertly
<larsc> but I think it is possible that it never leaves the READ, ACK_READ cycle
<wpwrak> isn't WAIT_START the wait for a start bit ?
<wpwrak> for a write, it would still have to receive the value
<larsc> it does
<larsc> RCV_OFFSET
<wpwrak> ah yes, line 134
<larsc> but a stop condition should reset the fsm
<larsc> and there does not seem to be stop support
<larsc> basically
<larsc> stop = Signal()
<larsc> self.comb += stop.eq(scl_i & sda_rising)
<larsc> and then If(stop, fsm.next_state(fsm.WAIT_START)).Else(... for each state
<wpwrak> but doesn't a start the FSM as well ?
jimmythehorn has quit [Quit: jimmythehorn]
<larsc> ah, ok
<larsc> thats why it adds it to each state
<wpwrak> it should output the state on some unused pins. then it would be easy to monitor what's going on.
mumptai has quit [Read error: Operation timed out]
<wpwrak> hmm, since sebastien isn't around, i'll just post a summary of what we have so far on the list. maybe it already rings a bell.
jimmythehorn has joined #milkymist
<larsc> hm, if I simulate things, start is set whenever sda is falling, even if scl is low
<wpwrak> hmm. i think i should be able to see the pixel clock. let's look for it again ...
<larsc> ah, that was the 20 cycle delay line
<wpwrak> maybe it's the clock input cross-talking somewhere in the logic. the clock is very fast in comparison, 30+ MHz vs. ~40 kHz I2C clock
<wpwrak> 31.502 MHz, to be exact
jevin has quit [Ping timeout: 252 seconds]
jevin has joined #milkymist