#milkymist IRC log for Friday, 2013-05-17

wpwrakTIMESPEC "TSise_sucks1" = FROM [...] ;-))00:12
Fallenou_23:35 < lekernel> ah, mpeg4 at 640*360 without audio is not too much for the rpi's little cpu ... < use mpeg-2 it's even less cpu griddy08:43
wpwrakbtw, this is what my scope sees on chA: http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/10:14
wpwrakresistive probe, -eq is equivalent time with a nominal sample rate of 10 GSa/s. -rq is real time, 400 MSa/s.10:15
lekernelwithout the 24 ohm resistors?10:21
wpwrakwithout 24 ohm10:21
lekernelcan you do eye diagrams?10:22
lekernelif you trigger on the clock you should be able to get 10 eyes on the screen. but not sure if you'd see much then.10:22
lekerneloutputting the 10x clock on some SD card pin is also an option10:23
wpwrakah, let's try10:23
lekernelyou want to output the 10x clock?10:24
lekernelit's a painful mess with the S6 clock routing system but I can help10:24
wpwraki actually tried to output the clock input. for that, i for the platform data inside clocking.py and send it to an MMC pin. strangely, this didn't work.10:25
wpwrakis it that such things that deep in the hierarchy would be ignored ? (i.e., picking an I/O pin)10:26
lekernelyou can pick IO pins from anywhere in the hierarchy10:26
lekernelit was a different problem10:26
wpwrakfor syncing with the clock, i'll try my luck with the 10 eyes10:27
lekernelso you used the full milkymist-ng clock?10:27
lekernelclock routing is one of the most horrible features of the S6, when you start using PLLs etc. it takes weeks to get things right if you're not used to it10:28
lekerneleg just "assign io_output = clock" in Verilog *never* works, you need to use a DDR register10:29
lekernelwhich in turn has restrictions on what you can connect to its *two* inputs (yes, you need an inverted clock as well to drive it)10:29
wpwraksweet :)10:30
lekernelfor example you can't connect the output of a BUFPLL, etc. etc. etc.10:30
lekerneland then there are restrictions on how many clock signals can enter some IO region10:30
wpwraki guess i would have been foolish to expect that could work ;-)10:30
lekernelsometimes depending on where they come from10:31
wpwrak(actually, that was the next item on my list - compare clock in with pll clock out)10:31
wpwrakfor the eye test, what would be a useful pattern to put on the screen ?10:31
lekerneland this silicon-level mess, of course, is seasoned with a hefty dose of the ISE bug sauce10:32
wpwrakso that data0n doesn't show too much chaos10:32
lekernelhmm, there will be chaos - 8b10b encoding picks different codes every time to achieve DC balance10:33
wpwrak:-(10:33
lekernelthat was why there was analog-looking noise on the pictures when the shift register was wrong10:33
wpwrakone problem is of course that clock trigger jitter is close to of the pixel bit time ...10:35
lekernelcould be why I had to add some jitter filtering in the FPGA ...10:36
lekernelmaybe I can try to build you a demo bitstream with just the jitter filter + 10x multiplier?10:36
lekernelor one way to forward the clock in -ng is to use OSERDES with a 1010 pattern and the 20x IO clock10:38
lekernelthere are already SERDESSTROBE and IOCLK for the sampling 20x ISERDES, so it should work without creating a clock routing mess10:39
wpwrakfirst result: nice uniform distribution, http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/chA-data0n-10eyes-try1-rt.png10:39
lekernelwow10:39
lekernelthat looks bad10:39
wpwrakthe probe on clock is far from optimal. it's the normal scope probe, not a resistive one. that explains some of the noise.10:42
wpwrakof course, i need the R probe on data. i have another one but it's been acting up. need to debug it first.10:42
wpwrakthis looks a little better: http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/chA-data0n-10eyes-try2-rt.png10:43
wpwraktime and voltage magnified, no longer sampling the clock, so i get 2x the sample rate10:43
wpwraktry1 only had 200 MSa/s10:43
wpwraknyquist frowns upon such experiments10:44
lekernelhm :)10:45
lekerneland that's 800x600 no?10:46
lekernel--mode 640x480 --refresh 6010:46
wpwrakheaven, no ! 640x48010:46
lekernel31.5MHz?10:47
wpwrak60 Hz, good point10:47
wpwrakwas 72.8 Hz10:47
kyaknetbsd is going to run on MM - that's a good news11:00
kyaki was just wondering - why netbsd?11:00
kyakdon't get me wrong, i'm not objecting, just asking :)11:01
wpwrakprobably a difficult childhood11:02
kyakwpwrak: are you saying, you wouldn't choose netbsd ?11:05
wpwraki think it would take me much longer to find my way around there than in linux11:06
kyakbut do i remember correctly that linux is already ported to MM?11:07
wpwrakwithout mmu and i'm not sure how good the drivers are11:18
wpwraki vaguely remember having heard of issues11:18
kyaki see11:20
lekernelFallenou_, you're porting to legacy SoC, not ng?11:30
lekernelMixxeo is ng only, and Wolfgang is MIA selling M 1, so...11:31
wpwrakdoes he have M1 orders queued up ?11:35
wpwrakbtw, do you have the exact clock period for 640x480@60Hz ? i.e., is it precisely 1/25200000 s ?11:41
lekernel25.175MHz11:44
lekernel+/- imprecisions of your GPU11:44
wpwrakblargh. dot soup :-(11:46
wpwrakhmm. and of course,. since 400 MSa/s is not a multiple of a pixel on the scope screen, i get a bit of a sampling error when downloading. ah well ...12:01
Fallenou_lekernel: for now, yes. But porting to -ng will be trivial once legacy works12:04
Fallenou_so if I manage to get the first one working, I will definetely do both12:04
Fallenou_kyak: well, NetBSD is well known for being "super portable" and "running on toasters" etc. so why not trying to add another arch :)12:05
Fallenou_"it should be easy"12:05
Fallenou_I must say, I am very pleased by the fact that NetBSD (kernel) internals are really well documented12:06
Fallenou_you have man pages for kernel functions ... what a beauty :)12:06
Fallenou_so far I'm pleased with what I am discovering about NetBSD internals12:06
Fallenou_and since I'm not a hardcore linux kernel hacker, it was not "easier" for me to do a Linux port like wpwrak said12:07
Fallenou_so for now either Linux or something else, I don't care12:07
Fallenou_so that's just it, NetBSD (and BSD world in general) has a very good reputation about being clean and proper and well documented (not like GNU stuff) so I decided to give it a try :)12:08
Fallenou_bbl12:09
kyakFallenou_: cool, thanks for explanation12:19
kyakand good luck, too :)12:20
wpwrakFallenou_: yeah, already knowing linux internals rather well makes a decision for linux easier, of course :)12:28
wpwrakhmm, it's interesting how the image badness varies. a short while ago, it was just a stream of noise. now it's stable enough that i can read what's on the screen.12:29
kyakwpwrak: are you sure it doesn't depend on observer? :)12:32
wpwrakhmm, i'm a relatively constant factor. but perhaps an imaginary invisible observer. kinda hard to track what these are doing.12:34
kyaka constant factor you say? get yourself a couple of beers and see if the image gets any better :)12:38
wpwrakthere an idea !12:41
Action: wpwrak puts a few bottles in the fridge12:41
lekernelwpwrak, why not put those 22 ohm 0603 resistors in series?12:43
lekernelyou can cut the traces near the connector, and solder one pin of the resistor on the connector pad and the other on the trace12:44
lekernelthat's what I did, but with 0402 resistors (after unsucessfully inserting them on the other side between the pads and the connector pins - resistors broke after a few connector manipulations)12:46
lekernelthe mystery is why the image looked good with the python script decoder and without the resistors12:47
lekernelmaybe it's just more tolerant to errors than the gateware implementation, or there is some weird shit going on again (like FPGA tolerance to bad SI depending on the bitstream content ...)12:48
wpwrakhmm :)12:48
wpwrakadding termination may be a good idea, yes. but lemme see this in a simulation first. could also be that you're just shifting around another sort of problem.12:49
Fallenou_kyak: you're welcome :) if you want to help, the code is public (GitHub hosted)13:47
Fallenou_my e-mail already has a nice outcome: someone from the NetBSD community just offered me to help with the port !13:47
Fallenou_this re-enforces my feeling about how cool this community is :)13:48
Fallenou_lekernel: I talked a lot with khorben at EHSM, he really is a cool and smart guy!13:48
Fallenou_and he likes getting his hands dirty :)13:48
wpwrak"eye diagram": http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/eye-25.20072MHz-1200kSa.png14:00
lekernel1200kSa ?14:00
wpwrakthat's over two clock periods14:00
wpwraktjat14:00
wpwrakblargh14:00
wpwrakthat's the number of samples that went into the graph14:00
lekernelbut what is the sample rate?14:01
wpwraksamping rate 400 MSa/s, converted to 500 MSa/s by an unknown algorithm in the scope14:01
lekernelmeh :)14:01
wpwrakyeah :)14:01
wpwrakthe clock frequency is that where i get the least blur. with so many samples, you can "zoom in" quite nicely. that's of course to be corrected for the accuracy of my scope.14:03
wpwraklemme draw it with fewer samples ...14:04
wpwrak100 kSa, less blur: http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/eye-25.20072MHz-100kSa.png14:05
wpwrakoh, and all this is data0n14:06
wpwrakthe pixels are 10x1 screen pixels to stretch things a little. the problem of not having a lot of samples per period.14:08
larscso every second clock cycle is not ok?14:11
wpwrakoh, that was with logarithmic mapping. here's linear mapping. better contrasts: http://downloads.qi-hardware.com/people/werner/ming/hdmi-si/eye-25.20072MHz-1200kSa-lin.png14:12
wpwrakit would seem that the patter is fairly stable. the resolution is too low to really say anything about the signal shape. it's barely high enough to identify individual bits.14:16
wpwrakah, wait. each bit time should be ~2 pixels even. 25 MHz -> 40 ns per pixel -> 4 ns per bit -> 2 samples14:20
wpwrakso that pattern would be ... something like 111-00-1-0-1-0014:21
wpwraknow, is that a valid symbol ? :)14:22
larscno14:24
larscbut you might be starting in the middle of the symbol14:26
wpwrakyes, there may be a slight offset14:27
larsceg 1-0-1-00-111-00 is valid14:28
wpwrakah, actually an unknown offset. lemme find out more about it ...14:28
wpwrak(i have the origin at the beginning of the scope's memory, many microseconds before the edge i triggered to)14:28
larscI'd expect the symbol to start with a zero though14:31
wpwrakmmh, everything around the trigger looks different :-(14:34
larscwell what are you sending?14:35
larscwhat's the pixel color?14:35
wpwraki think that was mainly black14:36
larscblack would be 10000000014:37
larscbut would toggle very other pixel between 100000000 and 101111111114:38
wpwrakhmm14:38
wpwrakgathering another sample. certainly all black now14:40
lekernelbe careful of gamma/color/contrast/brightness adjustements your GPU may make14:43
wpwrakxsetroot -solid black ... after that, it's out of my hands :)14:51
lekernelyes. that's the problem14:52
larsc0100111001 is 7515:03
wpwraki don't see a common pattern of alternation. there is a certain high-low-high-low-... sequence, but there is frequently a high-high-low-... segment. thus, the high/low alternate15:14
larschigh-low-high-low-... is vsync/hsync15:17
wpwraki mean just general pattern composition, i.e., predominantly high [00:00] --- Sat May 18 201315:20

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