#milkymist IRC log for Saturday, 2013-04-13

wpwrakchecked the parameters of the level shifters. according to NXP AN97055, they're perfect. ics.nxp.com/support/documents/interface/pdf/an97055.pdf08:28
wpwraknxp get better rise times, though. more like 200 ns than our 700-800 ns08:30
wpwrakbut the FET looks okay08:30
wpwrakbtw, edid-decode complains: EDID block does NOT conform to EDID 1.3!09:30
wpwrakparse-edid doesn't complain, though09:31
wpwrakVendorName "OHW", ModelName "M1 DVI mixer". nice :)09:31
wpwrakis there some place one could sneak in the port name/number ?09:32
lekernelthe string length is very limited, but other than that yes, lm32 can even modify the edid09:33
lekernelthe block is from phoenix edid designer... what is edid-decode complaining about exactly?09:34
lekernel(port B) reliably fails here with 2 different computers and immediately after FPGA reconfiguration... well maybe it's just a faulty connection... will check that09:36
wpwraki soldered a 6 pin header on the connector to attach the probes. this improves a number of probe characteristics compared to my previous setup. but i still don't see any major interference. so if there is anything bad, it may be beyond my scope's range.09:38
wpwrakhttp://pastebin.com/tRTWYHYX09:39
wpwrakmaybe it already dislikes the "dummy blocks"09:39
wpwrakand here's the competition: http://pastebin.com/EvMRjW2W09:40
wpwrakport B looks just as good as port A here. must be something they got wrong at the factory then :)09:41
wpwrakfrom the read-edid page: "By nature [sic!], certain cards/monitors do not work or work very badly" ;-))09:48
wpwrakmy resistive probe (5 kOhm) sees a very clean signal on SCL. no high-frequency interference. (on my 60 MHz scope with 1 GSa/s)09:57
larscjust claim to be edid 1.210:00
wpwrakon the rigol (100 MHz, 400 MSa/s), i see a bit of noise that looks like RF. in the order of 500-700 mVpp. not sure if this is real. the picture changes quite a lot depending on sample rate. e.g., the RF bursts "become" fairly regular oscillations at lower sample rates.10:04
wpwrakbut that's just instrument inadequacies pulling my leg10:04
wpwrakhmm, scope registers some jumpiness on the pixel clock. may be a bad trigger, though.10:50
wpwraklet's set up a more systematic test ...10:50
lekernelthere can be more jitter introduced by the slowtan6 - the internal route is more than 8ns10:54
wpwrakat those speeds, that's a lot10:55
wpwrakwell, later on, i can have a peek at the internal signal(s), too. right now i'm running a signal shape test, where the scope checks that the signal stays within a certain envelope10:59
wpwrakfirst at t = 0, to see how bad the trigger errors get, then t = 1000*T, then see how far i can take this11:00
lekernelhow clean is the signal? does the TMDS -> LVCMOS conversion hack work all OK?11:16
wpwrakhmm, can't really tell yet how clean it is. this is what I see at t=0: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-A-board-0T.png11:39
wpwrakthis area surrounding the waveform is persistence. the signal dances and bounces quite a lot. also the period measuremnt hops around, in a range of ~ 1 V, sometimes almost 2 V11:41
wpwrakthe outer dark yellow / brown area is the envelope. when the waveform enters the envelope, it's considered a failure11:42
wpwrakthe t=0 setup is of course intended to produce 0 failures11:42
wpwraki'll know whether this signal shape is "good" or "bad" when comparing with an echo generated by the FPGA11:49
lekernelurgh, doesn't look too good12:05
lekernelthat's with the resistive probe?12:05
lekernelI can easily imagine problems with the data signals which switch at 10 times the frequency... also the PLL lock isn't stable at high frequencies, that could explain why12:06
wpwrakno, with the regular probes. the resistive probe will need an adapter.12:15
wpwrakat 300 MHz, my scope should show nice clean DC ;-)12:16
lekernelyou can reduce to 251.75Mhz12:17
lekernelxrandr --mode 640x480 --refresh 6012:17
wpwrak320x200 would be more like it :)12:17
wpwrak160x200 even better ;-)12:18
lekernelif you can hack your GPU to do that...12:18
lekernelmaybe with some GPU/drivers it's as simple as a custom timing EDID entry, I don't know12:19
wpwraksounds like a plan12:20
wpwrakat 100 MHz, i'd already see only sinus waves12:21
wpwrakto actually debug such a signal, it should be 5-10 times slower than the scope's bandwidth12:21
lekernelmeh, you'll only go that far - the minimum input frequency for the S6 PLL is 19MHz12:23
wpwrakanyway, running clock monitoring now. i got one failure, but i'm not sure whether this happened during a change of mode of operation (screen saver and such): http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-A-board-1kT.png12:23
lekernelso that's 190Mbps data12:24
wpwrakemulate the PLL then :)12:24
lekerneland there's a maximum period jitter of 1ns12:26
lekernelor 20% of the input clock period, whichever is shorter12:27
wpwrakwhy couldn't they keep it simple and just stay with VGA ? :)12:29
lekernelI suspect we have more than 1 ns jitter...12:30
lekernelthe signal transitions don't look too good, then add a bit of noise to that...12:31
lekernelhttp://forums.xilinx.com/t5/Spartan-Family-FPGAs/Spartan-6-DCM-CLKGEN-input-jitter-spec/td-p/18296212:35
lekernel...12:35
lekernelhttp://www.xilinx.com/training/downloads/spartan-6-clocking-resources.pptx also says DCM_CLKGEN has "improved" jitter tolerance, without saying how much ...12:38
lekerneloh, and the authors of this powerpoint also think that 1GHz switching is "ultra fast". this explains a number of things regarding the slowtan6 performance...12:39
wpwrakhmm,the clock excursion may have been scope self-calibration. turning it off now.12:42
wpwrakupdated clock weirdness. some 0.01% seem to be outliers: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-A-board-1kT.png13:13
wpwraklet's do t=0 again, to see if it really isn't just bad triggers13:14
wpwrakbtw, another misfeature: if you get a group of pins but use only some of them, ISE complains bitterly about the unused ones. not sure if there's already a way to avoid this.13:16
lekernelworks for me14:02
lekerneldo you have code that shows the problem?14:02
Fallenoumwalle: hi! it's going well, I am still in my "while (doesnt compile) { make ; fix compilation error } " loop :)14:14
FallenouI am doing the low level stuff14:15
Fallenoufor instance I need to implement those functions: http://www.daemon-systems.org/man/copyin.9.html14:15
Fallenoufor lm32 arch14:15
wpwrakin a moment14:15
wpwrakat t=0, there don't seem to be any issues. let it run for a good while now: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-A-board-0T-2.png14:16
Fallenoumwalle: all other arch are implementing it in asm ... so I just translated copyout() from x86 asm to pseudo C , now I can implement it for lm32 :)14:16
wpwrakhere are clock in (taken at the board) and the echo from the FPGA: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-A-brd-fpga-0T.png14:17
wpwrakthis is how my scope is connected: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-scope-setup.jpg14:17
wpwrakthey're both about equally ugly :)14:18
wpwraklemme try the resistive probe ...14:18
wpwrakah yes, the unused pad issue. it wasn't just requesting, sorry. partial use, though. lemme make a simple example ...14:20
wpwrakhere it happens (at the very end, in bitgen): http://pastebin.ca/235821314:25
wpwrakand the it complains about everything but the one we use, mmc.dat[1] : http://pastebin.ca/235821714:26
lekernelyes, you are only assigning to one bit of a vectored signal14:29
lekernelwhat should it do instead? analyze the code, split the vector, remove unused pins ...? lots of work for little results...14:30
lekernelyou have exactly the same problem with verilog btw14:30
lekernelor vhdl14:30
lekerneldriving the unused parts is a bit simpler though... but still some work14:32
Fallenounice debugging session :)14:35
lekernelin all cases you need to track, with all possible combinations of Cat/Slice, which bits of each signal gets assigned or not...14:36
lekernelcan be done, but not sure if worth the effort14:36
lekernelor you can use "always @(*) begin signal = 0; <rest of the code here> end" and let the synthesizer do that work, but then the generated verilog becomes a bit ugly14:39
lekernelsince you'd do that for all signals14:39
wpwrakwell, i'm selecting the one pin i want to use. if that's not allowed, you either have to circuitously work around it, or you can't structure pin definitions at the origin (m1.py)14:40
lekernelwhen you 'structure', signals become like integers... and you're only setting one bit of that integer14:42
lekernelwell, the always @* form is already selected for those signals that are inside conditional statements...14:43
lekernelit could be done as well whenever you slice a signal before assigning to it14:44
lekernelthat would solve the problem with few lines of code14:44
wpwrakwith the resistive probe, it looks similar to a capacitative probe. so probe effects seem to be negligible.14:44
lekerneland then the unused bits are set to the reset value of the signal (default 0)14:45
wpwrakthis is with a 100x 5 kOhm resistive probe on the board: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-brd-res-real-time.png14:47
wpwrakthe same setup, equivalent time: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-brd-res-eqv-time.png14:47
wpwrak400 MSa/s14:48
wpwrakthe one that showed clock in and out was only 200 MSa/s (scope halves sample rate if using both channels)14:48
wpwrakon my tek, it looks even cleaner. but then the tek has an analog BW of 60 Hz, so this already gets suspiciously close to a sinus14:53
--- Sun Apr 14 201300:00

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