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]
kristianpaul has joined #milkymist
kristianpaul has quit [Changing host]
kristianpaul has joined #milkymist
Gurty has quit [Ping timeout: 260 seconds]
Gurty has joined #milkymist
<wpwrak> checked the parameters of the level shifters. according to NXP AN97055, they're perfect. ics.nxp.com/support/documents/interface/pdf/an97055.pdf
<wpwrak> nxp get better rise times, though. more like 200 ns than our 700-800 ns
<wpwrak> but the FET looks okay
kilae has joined #milkymist
lekernel has joined #milkymist
<wpwrak> btw, edid-decode complains: EDID block does NOT conform to EDID 1.3!
<wpwrak> parse-edid doesn't complain, though
<wpwrak> VendorName "OHW", ModelName "M1 DVI mixer". nice :)
<wpwrak> is there some place one could sneak in the port name/number ?
<lekernel> the string length is very limited, but other than that yes, lm32 can even modify the edid
<lekernel> the block is from phoenix edid designer... what is edid-decode complaining about exactly?
<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
<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.
<wpwrak> maybe it already dislikes the "dummy blocks"
<wpwrak> and here's the competition: http://pastebin.com/EvMRjW2W
<wpwrak> port B looks just as good as port A here. must be something they got wrong at the factory then :)
<wpwrak> from the read-edid page: "By nature [sic!], certain cards/monitors do not work or work very badly" ;-))
<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)
<larsc> just claim to be edid 1.2
<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.
<wpwrak> but that's just instrument inadequacies pulling my leg
<wpwrak> hmm, scope registers some jumpiness on the pixel clock. may be a bad trigger, though.
<wpwrak> let's set up a more systematic test ...
<lekernel> there can be more jitter introduced by the slowtan6 - the internal route is more than 8ns
<wpwrak> at those speeds, that's a lot
<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
<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
<lekernel> how clean is the signal? does the TMDS -> LVCMOS conversion hack work all OK?
Alarm has joined #milkymist
Alarm has quit [Client Quit]
<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
<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
<wpwrak> the outer dark yellow / brown area is the envelope. when the waveform enters the envelope, it's considered a failure
<wpwrak> the t=0 setup is of course intended to produce 0 failures
<wpwrak> i'll know whether this signal shape is "good" or "bad" when comparing with an echo generated by the FPGA
mumptai has joined #milkymist
<lekernel> urgh, doesn't look too good
<lekernel> that's with the resistive probe?
<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
<wpwrak> no, with the regular probes. the resistive probe will need an adapter.
<wpwrak> at 300 MHz, my scope should show nice clean DC ;-)
<lekernel> you can reduce to 251.75Mhz
<lekernel> xrandr --mode 640x480 --refresh 60
<wpwrak> 320x200 would be more like it :)
<wpwrak> 160x200 even better ;-)
<lekernel> if you can hack your GPU to do that...
<lekernel> maybe with some GPU/drivers it's as simple as a custom timing EDID entry, I don't know
<wpwrak> sounds like a plan
<wpwrak> at 100 MHz, i'd already see only sinus waves
<wpwrak> to actually debug such a signal, it should be 5-10 times slower than the scope's bandwidth
mumptai has quit [Remote host closed the connection]
<lekernel> meh, you'll only go that far - the minimum input frequency for the S6 PLL is 19MHz
<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
<lekernel> so that's 190Mbps data
<wpwrak> emulate the PLL then :)
Gurty has quit [Ping timeout: 252 seconds]
<lekernel> and there's a maximum period jitter of 1ns
<lekernel> or 20% of the input clock period, whichever is shorter
<wpwrak> why couldn't they keep it simple and just stay with VGA ? :)
<lekernel> I suspect we have more than 1 ns jitter...
<lekernel> the signal transitions don't look too good, then add a bit of noise to that...
<lekernel> ...
<lekernel> http://www.xilinx.com/training/downloads/spartan-6-clocking-resources.pptx also says DCM_CLKGEN has "improved" jitter tolerance, without saying how much ...
<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...
<wpwrak> hmm,the clock excursion may have been scope self-calibration. turning it off now.
Gurty has joined #milkymist
<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
<wpwrak> let's do t=0 again, to see if it really isn't just bad triggers
<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.
<lekernel> works for me
<lekernel> do you have code that shows the problem?
<Fallenou> mwalle: hi! it's going well, I am still in my "while (doesnt compile) { make ; fix compilation error } " loop :)
<Fallenou> I am doing the low level stuff
<Fallenou> for instance I need to implement those functions: http://www.daemon-systems.org/man/copyin.9.html
<Fallenou> for lm32 arch
<wpwrak> in a moment
<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
<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 :)
<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
<wpwrak> they're both about equally ugly :)
<wpwrak> lemme try the resistive probe ...
<wpwrak> ah yes, the unused pad issue. it wasn't just requesting, sorry. partial use, though. lemme make a simple example ...
<wpwrak> here it happens (at the very end, in bitgen): http://pastebin.ca/2358213
<wpwrak> and the it complains about everything but the one we use, mmc.dat[1] : http://pastebin.ca/2358217
<lekernel> yes, you are only assigning to one bit of a vectored signal
<lekernel> what should it do instead? analyze the code, split the vector, remove unused pins ...? lots of work for little results...
<lekernel> you have exactly the same problem with verilog btw
<lekernel> or vhdl
<lekernel> driving the unused parts is a bit simpler though... but still some work
<Fallenou> nice debugging session :)
<lekernel> in all cases you need to track, with all possible combinations of Cat/Slice, which bits of each signal gets assigned or not...
<lekernel> can be done, but not sure if worth the effort
<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
<lekernel> since you'd do that for all signals
<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)
<lekernel> when you 'structure', signals become like integers... and you're only setting one bit of that integer
<lekernel> well, the always @* form is already selected for those signals that are inside conditional statements...
<lekernel> it could be done as well whenever you slice a signal before assigning to it
<lekernel> that would solve the problem with few lines of code
<wpwrak> with the resistive probe, it looks similar to a capacitative probe. so probe effects seem to be negligible.
<lekernel> and then the unused bits are set to the reset value of the signal (default 0)
<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
<wpwrak> 400 MSa/s
<wpwrak> the one that showed clock in and out was only 200 MSa/s (scope halves sample rate if using both channels)
<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
jimmythehorn has joined #milkymist
cb88 has joined #milkymist
Gurty has quit [Ping timeout: 256 seconds]
Gurty has joined #milkymist
Gurty has quit [Max SendQ exceeded]
Gurty has joined #milkymist
cb88 has left #milkymist [#milkymist]
Gurty has quit [Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number]
lekernel has quit [Quit: Leaving]
mumptai has joined #milkymist
mumptai has quit [Ping timeout: 264 seconds]
mumptai has joined #milkymist