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>
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?
<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
<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.
<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>
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>
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)