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]
dvdk has joined #milkymist
dvdk has quit [Remote host closed the connection]
kristianpaul has quit [Read error: Operation timed out]
kristianpaul has joined #milkymist
wpwrak has quit [Ping timeout: 258 seconds]
wpwrak has joined #milkymist
antgreen has joined #milkymist
<wpwrak>
hmm, why can't i slice a Cat object ? :-(
<wpwrak>
and indexing doesn't go so well either. migen accepts it but the verilog it produces doesn't find the approval of the HDL parser: {mmc_dat[1], mmc_clk, mmc_cmd, mmc_dat[2]}[0] <= dbg[0];
<larsc>
I wonder could we instead of triggering on rising edge trigger on the falling edge, which should be more or less straight?
<larsc>
nah I guess not
<larsc>
since data is only valid between rising and falling edge
lekernel has joined #milkymist
<larsc>
although you could delay sda
<lekernel>
wpwrak, you should also remove the 100pF from your board if not already done
<GitHub75>
[mibuild] sbourdeauducq pushed 1 new commit to master: http://git.io/GyU8Dw
<GitHub75>
mibuild/master 59d64e9 Werner Almesberger: mibuild: define memory card pins of the Milkymist One platorm...
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
bhamilton has joined #milkymist
<larsc>
don't you hate it when you get an timing error by 0.001 ns?
<lekernel>
just ignore... it's not like xilinx's model is that accurate anyway
<lekernel>
sometimes it tells you timing is met when it actually isn't
<larsc>
I tried, it didn't work
<larsc>
well or my logic is wrong
<lekernel>
try a shot of freeze spray... makes the fpga go faster :)
<larsc>
hehe
bhamilton has left #milkymist [#milkymist]
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
bhamilton1 has joined #milkymist
bhamilton1 has left #milkymist [#milkymist]
<larsc>
ah the joys of p&r, added some more logic now the timings are met and everything works
<lekernel>
sounds like my usual experience with the xilinx software. and have this problem in the middle of horrid, time-sinking bug-hunting for maximum frustration.
<lekernel>
this is actually one of the problems that should be fixed for good with FPGAs
<lekernel>
that and a good in-chip logic analyzer (which would not require complete recompilation)
Martoni_ has joined #milkymist
Martoni has quit [Ping timeout: 248 seconds]
Martoni_ is now known as Martoni
<larsc>
yes
<wpwrak>
lekernel: 100 pF ? where ?
<wpwrak>
oh .. on top of some of the resistors ?
<lekernel>
wpwrak, on top of the pull-ups
<lekernel>
yes
<wpwrak>
very clean work. i had noticed that those "caps" were a bit tall but didn't realize they were stacks
<wpwrak>
so all four of them can go, i guess ?
<wpwrak>
lekernel: btw, mibuild doesn't have a setup.py, even though the tutorial suggests it does ("by running their respective setuptools script")
<wpwrak>
err yes, all four, obviously. morning caffeine is beginning to kick in :)
* wpwrak
is beginning to wonder if brain size and such aren't overrated and the true secret behind human intelligence is the use of stimulants ...
<lekernel>
yes, remove all 4 caps
<lekernel>
I sent you some replacement 4.7K resistors if removing the whole stack is easier for you
<lekernel>
I've been called "crazy" more than once for stacking 0402 components, but it's actually not that hard, you should try ;)
bhamilton has joined #milkymist
<lekernel>
what I find hard, however, is using just the right amount of solder like professionals in assembly factories do... so the solders look beautiful and equal instead of the blobs that I make
<wpwrak>
lekernel: btw, good idea about adding some support under the board. i started to worry as well. now there's a piece of acrylic under it
<wpwrak>
no it's getting a little painful to still find a glitch. about 1:10-1:12, i'd say
<wpwrak>
yes
<lekernel>
interesting behaviour...
<lekernel>
I wouldn't expect a steady ramp to produce so many problems
<wpwrak>
with my stronger pull-up and the caps removal, we dropped the glitchiness by about an order of magnitude
<lekernel>
nice catch btw! thanks Werner
<lekernel>
and there are no glitches when there is no video signal?
<wpwrak>
ah, lemme try that
<wpwrak>
0 in 50 tries (only a number of very short ones from crosstalk in my crappy LA)
<lekernel>
so it sounds like some sort of internal FPGA crosstalk when the IO voltage stays in the forbidden zone
<lekernel>
good to know
<wpwrak>
doesn't have to be in the FPGA. it's more likely on the unshielded and very long paths you have between board and FPGA
<lekernel>
wouldn't that show on the scope?
<wpwrak>
maybe if it was faster :)
<wpwrak>
also my probe setup isn't optimal. long loops between ground and signal. for best results, i'd have to expose some ground next to the signal and hold the probe to it. but even then the capacitative probe may not catch it.
<wpwrak>
i have resistive probes, with nearly infinite bandwidth, but they're a bit messy to deploy
<wpwrak>
my rigol has a sample rate of 200 MSa/s with multiple channels, 400 MSa/s with one. so anything that's faster than 5-10 ns is just invisible
<wpwrak>
and to properly catch a HF glitch, i'd need even more samples. so we're in the > 20 ns domain. almost at the pixel clock
<wpwrak>
maybe i should try the lottery. a good 500 MHz scope has been on my wish list for a very long time ;-)
<lekernel>
how do you plan to implement digital deglitching?
<lekernel>
downsample?
<wpwrak>
maybe just sum over the scl buffer. may be heavy on the fpga but should give us an idea of what works
<lekernel>
make sda + sdl go through a flip-flop, and only pulse its clock-enable pin once every 2**n cycles
<lekernel>
only takes a n-bit counter and 2 flip-flops
<wpwrak>
lars proposed a counter for a minimum stable time. not sure which is simpler
<lekernel>
downsampling should do the trick with very little resources I think
<wpwrak>
we can optimize later :) let's first see if the problem can be killed
<larsc>
my proposal was basically a digital schmitt trigger
<lekernel>
if the downsampled period is longer than the duration of glitching, it should fix it
<wpwrak>
i set a duration trigger and either my scope is missing a lot of things or the glitches are fairly infrequent
<wpwrak>
i also noticed that DDC often doesn't recover even after xrandr --off
<wpwrak>
an FPGA reset cures that. so maybe something else gets messed up when there are too many problems
<wpwrak>
let's see if i can get a mugshot without pixel data
<wpwrak>
(getting out of DDC hell) and sometimes i have to unplug. so the problem may well be on the PC side
<wpwrak>
lekernel: btw, shouldn't things like this work ? self.comb += dbg_pads[0].eq(dbg[0])
<wpwrak>
this works: self.comb += dbg_pads.eq(dbg[0:3] + 8*scl_i)
<wpwrak>
larsc: thanks for the "len" patch ! seems to work, but then i run into the bad verilog migen generates for it :-(
<larsc>
meh
<lekernel>
dbg_pads[0].eq(dbg[0]) doesn't work?
<wpwrak>
scope doesn't seem to see trouble without pixel data. had it searching for something like half an hour now
<lekernel>
slices are incompletely implemented, ENOTIME etc.
<lekernel>
but that case should work
<wpwrak>
i created them with this: dbg_pads = Cat(*(mmc.dat[2], mmc.cmd, mmc.clk, mmc.dat[1]))
<lekernel>
ah, yes, slicing Cat isn't implemented (because it's not implemented in Verilog either and I'm tired of having to write workarounds for shit like that)
<lekernel>
but it should be ...
<wpwrak>
migen produces something a human would understand: {mmc_dat[1], mmc_clk, mmc_cmd, mmc_dat[2]}[0] <= dbg[0];
<wpwrak>
alas, the verilog parser doesn't
<lekernel>
yeh, I know
<lekernel>
verilog crap
<lekernel>
that case is rare enough that I found it unworthy of my time
<wpwrak>
reminds me of early C++ pre-compilers, which took C++ and generated C from it. every once in a while, you had to fish a problem from the generated C. with C++ mangled names and all, not the nice heuristics migen uses.
<wpwrak>
well, if you have something that's an aggregate, this case of slicing seems to be the most sane way to use bits of it. luckily, the algorithmic approach works as well.
<wpwrak>
actually, why can't these things just be like arrays ? instead of Cat(*(A, B, C)) have [A, B, C] ?
<lekernel>
because you can, however, assign to Cat()
<lekernel>
Cat(...).eq() works
<lekernel>
and you can't make that work with a pure Python list
<wpwrak>
hmm. no way to override the assignment and add a test for array-of-signals ?
<larsc>
hm?
<lekernel>
I don't think you can easily override the built-in types
<lekernel>
otherwise I'd have fixed the dictionary and set non-determinism problem too
<wpwrak>
while trying to turn python into a domain-specific language for my TMC tools, i found that there are surprisingly many things you can override. but yes, could be that this one is tougher. would have to explore a bit.
<wpwrak>
(surprisingly many) e.g., you can have variable reads with complex side-effects
<lekernel>
>>> list.x = 8
<lekernel>
Traceback (most recent call last):
<lekernel>
File "<stdin>", line 1, in <module>
<lekernel>
TypeError: can't set attributes of built-in/extension type 'list'
<larsc>
you can overwrite __builtins__.list with your own wrapper thogh
<larsc>
but that doesn't work for [] and friends
<wpwrak>
what if you override __setattr__ ? would that still go to "list" instead of your wrapper ?
<larsc>
__setattr__ of what?
<lekernel>
I'm also a bit hesistant to alter the behaviour of all possibly third-party modules that run in conjunction with the migen stuff
<wpwrak>
if your list wrapper
<wpwrak>
coward ;-)
<wpwrak>
s/if/of/
<lekernel>
being able to use python libraries in test benches is a plus and I don't want to break it
<wpwrak>
looking at my old code, there i had my own class. so i didn't have to fight built-ins
<lekernel>
which is exactly what Cat() is
<lekernel>
with the added semantics that it should represent bit-concatenated values
<wpwrak>
appears that you need ruby for such dirty things. i'm beginning to understand why whitequark loves it so much. create a parallel universe, almost identical to ours, just with a few almost unnoticeable twists
<lekernel>
I suppose you have seen the "wat?" video?
<larsc>
wpwrak: the problem is, that this wont work if the glitch happens on the 7th bit
<larsc>
after the 7th
<larsc>
e.g. 0111111101111...
<larsc>
imo having a upper and a lower threshold is better
<lekernel>
just oversample
<lekernel>
s/oversample/downsample
<lekernel>
it's just a flip flop and a counter ...
<lekernel>
I'm actually surprised your design met timing
<wpwrak>
yeah, it ain't pretty ;-)
<wpwrak>
maybe the synthesizer figured out what it actually does and got rid of all the unnecessary stops
<larsc>
lekernel: how does that downsampler work?
<wpwrak>
and yes, you're right, i'd still need a hysteresis for this to be stable.
<lekernel>
just load the flip flop once in 2**n cycles
<larsc>
but why does that work? wouldn't it sample the value that's present at the D input at that point?
<lekernel>
if clock_period*2**n > total duration of glitches, then you can't have two consecutive samples in the glitched region
<wpwrak>
you probably have to reset the counter, too
<lekernel>
on a low to high transition, the second sample will always be right. the first one can be high or low, and can end up in the middle of glitches
<wpwrak>
hmm, sounds right. why does it feel wrong ?
<lekernel>
so this adds a clock_period*2**n jitter, which is a lot, but I2C should be slow enough that it won't be a problem
<wpwrak>
probably just poor intuition :)
<wpwrak>
yeah, I2C is slowness incarnate
<wpwrak>
and it's fairly unconcerned with timing. actually, lemme check that ...
<lekernel>
downsampling also works for debouncing switches... you sample them at around 100Hz, and done
<wpwrak>
yeah, you have half a clock cycle for things like ACK. plenty of time.
<lekernel>
wpwrak, little trick: Cat(carry, counter).eq(counter + 1) works
<lekernel>
but the other way around
<lekernel>
Cat(counter, carry).eq(counter + 1)
<wpwrak>
neat :)
<wpwrak>
32 should be sufficient. the 20 cycles delay line was ~460 us. half a clock cycle takes about 12 us. the glitch events seem to take around 100 ns.
<wpwrak>
s/460 us/460 ns/
<lekernel>
clock frequency is 83MHz on milkymist-ng and 50MHz on the EDID tester
<wpwrak>
seems about right then. 400-650 ns.
<lekernel>
maybe take something like twice the time the voltage is in the forbidden zone, to be sure?
<lekernel>
unless that becomes non-negligible compared to the nominal 100kHz of I2C
<wpwrak>
ah, and i think my sum deglitcher should actually be stable even if the upset is on the 7th or 8th bit, as long as the glitching interveal isn't larger than the delay buffer (if it is, you have noise entering and leaving, and the sum can dance around the threshold)
<wpwrak>
yeah, 1 us ought to work, too. that's longer than the very worst-case rise time seen so far
<wpwrak>
of course, i don't know what happens with other equipment. e.g., my HDMI cable is relatively shows.
<lekernel>
yeh, so let's take some safety margin
<wpwrak>
seems to work quite well. mail is coming.
<larsc>
I still don't see why this will work. You sample the signal every n cycles, if the glitch happens at exact that moment you'll still see the glitch
<lekernel>
yes, but not at the next sample
<lekernel>
so all the glitches do now is increase jitter, not make counters etc. go too fast
Martoni has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0/20130329043827]]
<wpwrak>
larsc: if you sample the glitch, then this simply delays you by one sample period
<lekernel>
larsc, there are only glitches during a transition. maybe that's what you did not understand?
<larsc>
maybe
<wpwrak>
larsc: since the signal only glitches at an edge, you're guaranteed to have a glitch-free signal the next time
<lekernel>
when the signal is hard-0 or hard-1, there are no glitches
<wpwrak>
stereo :)
<larsc>
ok, I understand now
<larsc>
I hope
<larsc>
for the glitch to still manifest it basically has to happen at x+n, and x+3*n
<wpwrak>
works also with the pull-up gone. as expected.
<larsc>
well x and x+2*n
<lekernel>
yes but it won't, because the sample period is low enough that signal has reached a stable state by then
<larsc>
yes
<larsc>
that's what I was missing in my mental image
<lekernel>
s/low/long
<larsc>
but it's not exactly downsampling, is it?
<wpwrak>
yeah, it's just sampling
<lekernel>
well, we are sampling first at the system clock frequency
<lekernel>
with a double-FF synchronizer
<lekernel>
and then only consider 1 out of 64 of those samples
<wpwrak>
nice example for how discarding information improves its quality :)
<wpwrak>
yeah, we found interesting bugs there ...
<wpwrak>
... i still find the message queue crash rather baffling. let's just hope RTEMS only goes into satellites who can peacefully explode in space at a safe distance from everyone, not into, say, nuclear power plant control ...
ohama has joined #milkymist
<larsc>
or nuclear missile silo control
<wpwrak>
yeah, silo safety protocol
<wpwrak>
like in "twilight's last gleaming": "they can't open the doors". and right then they open :)
jimmythehorn has joined #milkymist
bhamilton has quit [Quit: Leaving.]
<davidc__>
wpwrak: In my day job I work on SCADA/smartgrid/etc security. Lets just say people sleep better at night before they see the source of some of those devices.
<wpwrak>
you mean, it's enough if you wake up five times per night, drenched in sweat ?
<lekernel>
wpwrak, excellent job with the i2c! can you just send a patch against milkymist-ng?
<wpwrak>
thanks ! :) need to do some shopping first, then i'll make the patch. also have to check some more systems, see if they have any interesting new perversions. all of them linux, though, so the level of perversity should be limited
<wpwrak>
channel B will also want looking at. there, we have the HDMI clock right next to SCL. if anything can go wrong, it ought to be there :)
<wpwrak>
lekernel: do you have any use for the debugging stuff ?
<lekernel>
no
<lekernel>
or well, hopefully not ;) will p
<lekernel>
ull it from your repos if I end up needing it ...
<wpwrak>
heh ;-)
<wpwrak>
it's kinda disappointing, once the debug code is cleaned out, there's just a few lines left
<wpwrak>
now lets see if i got them right ...
<wpwrak>
patch is on its way
<lekernel>
wpwrak, do both ports work for you?
<lekernel>
port A is fine, port B isn't... but it could be a different problem, I never got port B to work
<lekernel>
(like poor solders)
<wpwrak>
i'll give it a try in a bit. food first :)
<wpwrak>
did it fail at the I2C/DDC/EDID level ?
<lekernel>
no detection at all by xrandr
<wpwrak>
nice. if it looks so bad, it must be something simple :-)
<GitHub30>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/tsz4ng
<GitHub30>
milkymist-ng/master 7a6e564 Werner Almesberger: edid.py: sample SCL only every 64 clock cycles, to avoid bouncing...
<mw1>
hi
<mw1>
Fallenou: how is netbsd doing?
mw1 is now known as mwalle
lekernel has quit [Quit: Leaving]
qi-bot has quit [Ping timeout: 245 seconds]
<wpwrak>
connectivity on the board looks good. pin definitions in m1.py look correct. ergo it must work. let's see if it does ...
<wpwrak>
but .. nothing happens indeed
<wpwrak>
is it the same on all boards ? or do some work ?
<wpwrak>
bah. now it works
<wpwrak>
sorry, no problem in sight :) just had to disconnect and reconnect
qi-bot has joined #milkymist
<wpwrak>
maybe a bit more glitches than on CH A, but that's all. and of course, they all get eaten by the downsampling
<wpwrak>
also the pixel clock blinking is like on CH A
<wpwrak>
maybe you ran into the PC giving up for good. i've seen that happen a few times. only a HDMI disconnect cured that.
kristianpaul has quit [Remote host closed the connection]