| wpwrak | checked the parameters of the level shifters. according to NXP AN97055, they're perfect. ics.nxp.com/support/documents/interface/pdf/an97055.pdf | 08:28 |
|---|---|---|
| wpwrak | nxp get better rise times, though. more like 200 ns than our 700-800 ns | 08:30 |
| wpwrak | but the FET looks okay | 08:30 |
| wpwrak | btw, edid-decode complains: EDID block does NOT conform to EDID 1.3! | 09:30 |
| wpwrak | parse-edid doesn't complain, though | 09:31 |
| wpwrak | VendorName "OHW", ModelName "M1 DVI mixer". nice :) | 09:31 |
| wpwrak | is there some place one could sneak in the port name/number ? | 09:32 |
| lekernel | the string length is very limited, but other than that yes, lm32 can even modify the edid | 09:33 |
| lekernel | the 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 that | 09:36 |
| wpwrak | i 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 |
| wpwrak | http://pastebin.com/tRTWYHYX | 09:39 |
| wpwrak | maybe it already dislikes the "dummy blocks" | 09:39 |
| wpwrak | and here's the competition: http://pastebin.com/EvMRjW2W | 09:40 |
| wpwrak | port B looks just as good as port A here. must be something they got wrong at the factory then :) | 09:41 |
| wpwrak | from the read-edid page: "By nature [sic!], certain cards/monitors do not work or work very badly" ;-)) | 09:48 |
| wpwrak | my 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 |
| larsc | just claim to be edid 1.2 | 10:00 |
| wpwrak | on 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 |
| wpwrak | but that's just instrument inadequacies pulling my leg | 10:04 |
| wpwrak | hmm, scope registers some jumpiness on the pixel clock. may be a bad trigger, though. | 10:50 |
| wpwrak | let's set up a more systematic test ... | 10:50 |
| lekernel | there can be more jitter introduced by the slowtan6 - the internal route is more than 8ns | 10:54 |
| wpwrak | at those speeds, that's a lot | 10:55 |
| wpwrak | well, 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 envelope | 10:59 |
| wpwrak | first at t = 0, to see how bad the trigger errors get, then t = 1000*T, then see how far i can take this | 11:00 |
| lekernel | how clean is the signal? does the TMDS -> LVCMOS conversion hack work all OK? | 11:16 |
| wpwrak | hmm, 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.png | 11:39 |
| wpwrak | this 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 V | 11:41 |
| wpwrak | the outer dark yellow / brown area is the envelope. when the waveform enters the envelope, it's considered a failure | 11:42 |
| wpwrak | the t=0 setup is of course intended to produce 0 failures | 11:42 |
| wpwrak | i'll know whether this signal shape is "good" or "bad" when comparing with an echo generated by the FPGA | 11:49 |
| lekernel | urgh, doesn't look too good | 12:05 |
| lekernel | that's with the resistive probe? | 12:05 |
| lekernel | I 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 why | 12:06 |
| wpwrak | no, with the regular probes. the resistive probe will need an adapter. | 12:15 |
| wpwrak | at 300 MHz, my scope should show nice clean DC ;-) | 12:16 |
| lekernel | you can reduce to 251.75Mhz | 12:17 |
| lekernel | xrandr --mode 640x480 --refresh 60 | 12:17 |
| wpwrak | 320x200 would be more like it :) | 12:17 |
| wpwrak | 160x200 even better ;-) | 12:18 |
| lekernel | if you can hack your GPU to do that... | 12:18 |
| lekernel | maybe with some GPU/drivers it's as simple as a custom timing EDID entry, I don't know | 12:19 |
| wpwrak | sounds like a plan | 12:20 |
| wpwrak | at 100 MHz, i'd already see only sinus waves | 12:21 |
| wpwrak | to actually debug such a signal, it should be 5-10 times slower than the scope's bandwidth | 12:21 |
| lekernel | meh, you'll only go that far - the minimum input frequency for the S6 PLL is 19MHz | 12:23 |
| wpwrak | anyway, 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.png | 12:23 |
| lekernel | so that's 190Mbps data | 12:24 |
| wpwrak | emulate the PLL then :) | 12:24 |
| lekernel | and there's a maximum period jitter of 1ns | 12:26 |
| lekernel | or 20% of the input clock period, whichever is shorter | 12:27 |
| wpwrak | why couldn't they keep it simple and just stay with VGA ? :) | 12:29 |
| lekernel | I suspect we have more than 1 ns jitter... | 12:30 |
| lekernel | the signal transitions don't look too good, then add a bit of noise to that... | 12:31 |
| lekernel | http://forums.xilinx.com/t5/Spartan-Family-FPGAs/Spartan-6-DCM-CLKGEN-input-jitter-spec/td-p/182962 | 12:35 |
| lekernel | ... | 12:35 |
| lekernel | http://www.xilinx.com/training/downloads/spartan-6-clocking-resources.pptx also says DCM_CLKGEN has "improved" jitter tolerance, without saying how much ... | 12:38 |
| lekernel | oh, 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 |
| wpwrak | hmm,the clock excursion may have been scope self-calibration. turning it off now. | 12:42 |
| wpwrak | updated clock weirdness. some 0.01% seem to be outliers: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-A-board-1kT.png | 13:13 |
| wpwrak | let's do t=0 again, to see if it really isn't just bad triggers | 13:14 |
| wpwrak | btw, 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 |
| lekernel | works for me | 14:02 |
| lekernel | do you have code that shows the problem? | 14:02 |
| Fallenou | mwalle: hi! it's going well, I am still in my "while (doesnt compile) { make ; fix compilation error } " loop :) | 14:14 |
| Fallenou | I am doing the low level stuff | 14:15 |
| Fallenou | for instance I need to implement those functions: http://www.daemon-systems.org/man/copyin.9.html | 14:15 |
| Fallenou | for lm32 arch | 14:15 |
| wpwrak | in a moment | 14:15 |
| wpwrak | at 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.png | 14:16 |
| Fallenou | mwalle: 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 |
| wpwrak | here 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.png | 14:17 |
| wpwrak | this is how my scope is connected: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-scope-setup.jpg | 14:17 |
| wpwrak | they're both about equally ugly :) | 14:18 |
| wpwrak | lemme try the resistive probe ... | 14:18 |
| wpwrak | ah yes, the unused pad issue. it wasn't just requesting, sorry. partial use, though. lemme make a simple example ... | 14:20 |
| wpwrak | here it happens (at the very end, in bitgen): http://pastebin.ca/2358213 | 14:25 |
| wpwrak | and the it complains about everything but the one we use, mmc.dat[1] : http://pastebin.ca/2358217 | 14:26 |
| lekernel | yes, you are only assigning to one bit of a vectored signal | 14:29 |
| lekernel | what should it do instead? analyze the code, split the vector, remove unused pins ...? lots of work for little results... | 14:30 |
| lekernel | you have exactly the same problem with verilog btw | 14:30 |
| lekernel | or vhdl | 14:30 |
| lekernel | driving the unused parts is a bit simpler though... but still some work | 14:32 |
| Fallenou | nice debugging session :) | 14:35 |
| lekernel | in all cases you need to track, with all possible combinations of Cat/Slice, which bits of each signal gets assigned or not... | 14:36 |
| lekernel | can be done, but not sure if worth the effort | 14:36 |
| lekernel | or 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 ugly | 14:39 |
| lekernel | since you'd do that for all signals | 14:39 |
| wpwrak | well, 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 |
| lekernel | when you 'structure', signals become like integers... and you're only setting one bit of that integer | 14:42 |
| lekernel | well, the always @* form is already selected for those signals that are inside conditional statements... | 14:43 |
| lekernel | it could be done as well whenever you slice a signal before assigning to it | 14:44 |
| lekernel | that would solve the problem with few lines of code | 14:44 |
| wpwrak | with the resistive probe, it looks similar to a capacitative probe. so probe effects seem to be negligible. | 14:44 |
| lekernel | and then the unused bits are set to the reset value of the signal (default 0) | 14:45 |
| wpwrak | this 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.png | 14:47 |
| wpwrak | the same setup, equivalent time: http://downloads.qi-hardware.com/people/werner/ming/hdmi-clk/clk-brd-res-eqv-time.png | 14:47 |
| wpwrak | 400 MSa/s | 14:48 |
| wpwrak | the one that showed clock in and out was only 200 MSa/s (scope halves sample rate if using both channels) | 14:48 |
| wpwrak | on 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 sinus | 14:53 |
| --- Sun Apr 14 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
