#milkymist IRC log for Friday, 2013-04-12

wpwrakhmm, why can't i slice a Cat object ? :-(04:37
wpwrakand 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];04:39
larscI think I have a patch for that somewhere06:27
larscwpwrak: http://pastebin.com/ULgHckVY07:07
larscI wonder could we instead of triggering on rising edge trigger on the falling edge, which should be more or less straight?07:26
larscnah I guess not07:27
larscsince data is only valid between rising and falling edge07:27
larscalthough you could delay sda07:30
lekernelwpwrak, you should also remove the 100pF from your board if not already done07:30
GitHub75[mibuild] sbourdeauducq pushed 1 new commit to master: http://git.io/GyU8Dw07:53
GitHub75mibuild/master 59d64e9 Werner Almesberger: mibuild: define memory card pins of the Milkymist One platorm...07:53
larscdon't you hate it when you get an timing error by 0.001 ns?08:37
lekerneljust ignore... it's not like xilinx's model is that accurate anyway08:39
lekernelsometimes it tells you timing is met when it actually isn't08:39
larscI tried, it didn't work08:41
larscwell or my logic is wrong08:41
lekerneltry a shot of freeze spray... makes the fpga go faster :)08:42
larscah the joys of p&r, added some more logic now the timings are met and everything works09:51
lekernelsounds like my usual experience with the xilinx software. and have this problem in the middle of horrid, time-sinking bug-hunting for maximum frustration.09:53
lekernelthis is actually one of the problems that should be fixed for good with FPGAs09:57
lekernelthat and a good in-chip logic analyzer (which would not require complete recompilation)09:57
wpwraklekernel: 100 pF ? where ?10:25
wpwrakoh .. on top of some of the resistors ?10:26
lekernelwpwrak, on top of the pull-ups10:26
wpwrakvery clean work. i had noticed that those "caps" were a bit tall but didn't realize they were stacks10:28
wpwrakso all four of them can go, i guess ?10:28
wpwraklekernel: btw, mibuild doesn't have a setup.py, even though the tutorial suggests it does ("by running their respective setuptools script")10:32
wpwrakerr yes, all four, obviously. morning caffeine is beginning to kick in :)10:38
Action: 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 ...10:39
lekernelyes, remove all 4 caps10:46
lekernelI sent you some replacement 4.7K resistors if removing the whole stack is easier for you10:46
lekernelI've been called "crazy" more than once for stacking 0402 components, but it's actually not that hard, you should try ;)10:47
lekernelwhat 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 make10:53
wpwraklekernel: btw, good idea about adding some support under the board. i started to worry as well. now there's a piece of acrylic under it10:53
wpwrakremoving the caps does indeed help10:54
lekernelbut still a glitch, right?10:55
wpwrakno it's getting a little painful to still find a glitch. about 1:10-1:12, i'd say10:55
lekernelinteresting behaviour...10:55
lekernelI wouldn't expect a steady ramp to produce so many problems10:56
wpwrakwith my stronger pull-up and the caps removal, we dropped the glitchiness by about an order of magnitude10:56
lekernelnice catch btw! thanks Werner10:56
lekerneland there are no glitches when there is no video signal?10:56
wpwrakah, lemme try that10:57
wpwrak0 in 50 tries (only a number of very short ones from crosstalk in my crappy LA)11:00
lekernelso it sounds like some sort of internal FPGA crosstalk when the IO voltage stays in the forbidden zone11:01
lekernelgood to know11:01
wpwrakdoesn't have to be in the FPGA. it's more likely on the unshielded and very long paths you have between board and FPGA11:03
lekernelwouldn't that show on the scope?11:04
wpwrakmaybe if it was faster :)11:04
wpwrakalso 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.11:05
wpwraki have resistive probes, with nearly infinite bandwidth, but they're a bit messy to deploy11:06
wpwrakmy 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 invisible11:07
wpwrakand to properly catch a HF glitch, i'd need even more samples. so we're in the > 20 ns domain. almost at the pixel clock11:08
wpwrakmaybe i should try the lottery. a good 500 MHz scope has been on my wish list for a very long time ;-)11:08
lekernelhow do you plan to implement digital deglitching?11:09
wpwrakmaybe just sum over the scl buffer. may be heavy on the fpga but should give us an idea of what works11:10
lekernelmake sda + sdl go through a flip-flop, and only pulse its clock-enable pin once every 2**n cycles11:10
lekernelonly takes a n-bit counter and 2 flip-flops11:11
wpwraklars proposed a counter for a minimum stable time. not sure which is simpler11:11
lekerneldownsampling should do the trick with very little resources I think11:11
wpwrakwe can optimize later :) let's first see if the problem can be killed11:11
larscmy proposal was basically a digital schmitt trigger11:12
lekernelif the downsampled period is longer than the duration of glitching, it should fix it11:12
wpwraki set a duration trigger and either my scope is missing a lot of things or the glitches are fairly infrequent11:26
wpwraki also noticed that DDC often doesn't recover even after xrandr --off11:27
wpwrakan FPGA reset cures that. so maybe something else gets messed up when there are too many problems11:28
wpwraklet's see if i can get a mugshot without pixel data11:31
wpwrak(getting out of DDC hell) and sometimes i have to unplug. so the problem may well be on the PC side11:34
wpwraklekernel: btw, shouldn't things like this work ? self.comb += dbg_pads[0].eq(dbg[0])11:51
wpwrakthis works: self.comb += dbg_pads.eq(dbg[0:3] + 8*scl_i)11:52
wpwraklarsc: thanks for the "len" patch ! seems to work, but then i run into the bad verilog migen generates for it :-(11:53
lekernel dbg_pads[0].eq(dbg[0]) doesn't work?11:53
wpwrakscope doesn't seem to see trouble without pixel data. had it searching for something like half an hour now11:54
lekernelslices are incompletely implemented, ENOTIME etc.11:54
lekernelbut that case should work11:54
wpwraki created them with this: dbg_pads = Cat(*(mmc.dat[2], mmc.cmd, mmc.clk, mmc.dat[1]))11:55
lekernelah, 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)11:55
lekernelbut it should be ...11:56
wpwrakmigen produces something a human would understand:  {mmc_dat[1], mmc_clk, mmc_cmd, mmc_dat[2]}[0] <= dbg[0];11:56
wpwrakalas, the verilog parser doesn't11:56
lekernelyeh, I know11:56
lekernelverilog crap11:56
lekernelthat case is rare enough that I found it unworthy of my time11:57
wpwrakreminds 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.11:57
wpwrakwell, 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.11:58
wpwrakactually, why can't these things just be like arrays ? instead of Cat(*(A, B, C)) have [A, B, C] ?11:59
lekernelbecause you can, however, assign to Cat()12:00
lekernelCat(...).eq() works12:00
lekerneland you can't make that work with a pure Python list12:00
wpwrakhmm. no way to override the assignment and add a test for array-of-signals ?12:01
lekernelI don't think you can easily override the built-in types12:02
lekernelotherwise I'd have fixed the dictionary and set non-determinism problem too12:02
wpwrakwhile 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.12:04
wpwrak(surprisingly many) e.g., you can have variable reads with complex side-effects12:05
lekernel>>> list.x = 812:05
lekernelTraceback (most recent call last):12:05
lekernel  File "<stdin>", line 1, in <module>12:05
lekernelTypeError: can't set attributes of built-in/extension type 'list'12:05
larscyou can overwrite __builtins__.list with your own wrapper thogh12:05
larscbut that doesn't work for [] and friends12:06
wpwrakwhat if you override __setattr__ ? would that still go to "list" instead of your wrapper ?12:07
larsc__setattr__ of what?12:08
lekernelI'm also a bit hesistant to alter the behaviour of all possibly third-party modules that run in conjunction with the migen stuff12:08
wpwrakif your list wrapper12:08
wpwrakcoward ;-)12:08
lekernelbeing able to use python libraries in test benches is a plus and I don't want to break it12:09
wpwraklooking at my old code, there i had my own class. so i didn't have to fight built-ins12:09
lekernelwhich is exactly what Cat() is12:10
lekernelwith the added semantics that it should represent bit-concatenated values12:10
wpwrakappears 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 twists12:17
lekernelI suppose you have seen the "wat?" video?12:18
wpwrakoh dear ;-)12:24
Action: wpwrak hurries back to the safety of C :)12:25
wpwraklekernel: your delay line with "FIXME: understand what is really going on here" ... was that an attempt to escape the glitches ?12:36
larscit fixed some brokenes12:37
lekernelyes, you should be able to remove it12:37
wpwrakhmm, if assigning from a "variable", wouldn't it be more intuitive if that yielded a blocking assignment, no matter what the target is ?14:12
wpwraka bit like having "volatile" anywhere in an assignment in C14:13
lekernelno, you need to stop using blocking assignments at some point14:16
lekernelwhat do you need variables for?14:16
wpwrakfor summing the buffer - because i'm too lazy to find out how to assemble a big sum operation :)14:17
lekernelactually a better API for variables would be to associate them to some non-variable backing signal14:18
wpwrakso no, i don't really "need" it. just using it now for convenience.14:18
lekernelbut again, I'm only using variables in a couple places, so ...14:18
wpwrakthink you;ll like this: http://downloads.qi-hardware.com/people/werner/ming/edid/debounce-thresh-7-count-overview.png15:03
wpwrakmail with details is on the way15:03
larscwpwrak: the problem is, that this wont work if the glitch happens on the 7th bit15:05
larscafter the 7th15:06
larsce.g. 0111111101111...15:06
larscimo having a upper and a lower threshold is better15:06
lekerneljust oversample15:07
lekernelit's just a flip flop and a counter ...15:07
lekernelI'm actually surprised your design met timing15:07
wpwrakyeah, it ain't pretty ;-)15:08
wpwrakmaybe the synthesizer figured out what it actually does and got rid of all the unnecessary stops15:08
larsclekernel: how does that downsampler work?15:09
wpwrakand yes, you're right, i'd still need a hysteresis for this to be stable.15:10
lekerneljust load the flip flop once in 2**n cycles15:11
larscbut why does that work? wouldn't it sample the value that's present at the D input at that point?15:11
lekernelif clock_period*2**n > total duration of glitches, then you can't have two consecutive samples in the glitched region15:12
wpwrakyou probably have to reset the counter, too15:12
lekernelon 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 glitches15:13
wpwrakhmm, sounds right. why does it feel wrong ?15:13
lekernelso this adds a clock_period*2**n jitter, which is a lot, but I2C should be slow enough that it won't be a problem15:14
wpwrakprobably just poor intuition :)15:14
wpwrakyeah, I2C is slowness incarnate15:14
wpwrakand it's fairly unconcerned with timing. actually, lemme check that ...15:15
lekerneldownsampling also works for debouncing switches... you sample them at around 100Hz, and done15:16
wpwrakyeah, you have half a clock cycle for things like ACK. plenty of time.15:18
lekernelwpwrak, little trick: Cat(carry, counter).eq(counter + 1) works15:20
lekernelbut the other way around15:20
lekernelCat(counter, carry).eq(counter + 1)15:20
wpwrakneat :)15:22
wpwrak32 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.15:25
wpwraks/460 us/460 ns/15:25
lekernelclock frequency is 83MHz on milkymist-ng and 50MHz on the EDID tester15:26
wpwrakseems about right then. 400-650 ns.15:28
lekernelmaybe take something like twice the time the voltage is in the forbidden zone, to be sure?15:29
lekernelunless that becomes non-negligible compared to the nominal 100kHz of I2C15:30
wpwrakah, 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)15:30
wpwrakyeah, 1 us ought to work, too. that's longer than the very worst-case rise time seen so far15:31
wpwrakof course, i don't know what happens with other equipment. e.g., my HDMI cable is relatively shows.15:31
lekernelyeh, so let's take some safety margin15:32
wpwrakseems to work quite well. mail is coming.16:09
larscI 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 glitch16:16
lekernelyes, but not at the next sample16:16
lekernelso all the glitches do now is increase jitter, not make counters etc. go too fast16:17
wpwraklarsc: if you sample the glitch, then this simply delays you by one sample period16:17
lekernellarsc, there are only glitches during a transition. maybe that's what you did not understand?16:18
wpwraklarsc: since the signal only glitches at an edge, you're guaranteed to have a glitch-free signal the next time16:18
lekernelwhen the signal is hard-0 or hard-1, there are no glitches16:18
wpwrakstereo :)16:18
larscok, I understand now16:18
larscI hope16:18
larscfor the glitch to still manifest it basically has to happen at x+n, and x+3*n16:19
wpwrakworks also with the pull-up gone. as expected.16:19
larscwell x and x+2*n16:19
lekernelyes but it won't, because the sample period is low enough that signal has reached a stable state by then16:20
larscthat's what I was missing in my mental image16:20
larscbut it's not exactly downsampling, is it?16:23
wpwrakyeah, it's just sampling16:23
lekernelwell, we are sampling first at the system clock frequency16:24
lekernelwith a double-FF synchronizer16:25
lekerneland then only consider 1 out of 64 of those samples16:25
wpwraknice example for how discarding information improves its quality :)16:28
lekernelhttp://arstechnica.com/science/2013/03/flash-memory-issue-forces-curiosity-rover-into-safe-mode/ why can't I help thinking about the RTEMS filesystem API when reading news like this ...16:31
wpwrakyeah, we found interesting bugs there ...16:32
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 ...16:33
larscor nuclear missile silo control16:37
wpwrakyeah, silo safety protocol16:38
wpwraklike in "twilight's last gleaming": "they can't open the doors". and right then they open :)16:39
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.18:18
wpwrakyou mean, it's enough if you wake up five times per night, drenched in sweat ?18:20
lekernelwpwrak, excellent job with the i2c! can you just send a patch against milkymist-ng?18:34
wpwrakthanks ! :) 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 limited19:25
wpwrakchannel 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 :)20:08
wpwraklekernel: do you have any use for the debugging stuff ?20:18
lekernelor well, hopefully not ;) will p20:20
lekernelull it from your repos if I end up needing it ...20:20
wpwrakheh ;-)20:20
wpwrakit's kinda disappointing, once the debug code is cleaned out, there's just a few lines left20:23
wpwraknow lets see if i got them right ...20:23
wpwrakpatch is on its way20:39
lekernelwpwrak, do both ports work for you?20:56
lekernelport A is fine, port B isn't... but it could be a different problem, I never got port B to work20:56
lekernel(like poor solders)20:57
wpwraki'll give it a try in a bit. food first :)21:03
wpwrakdid it fail at the I2C/DDC/EDID level ?21:04
lekernelno detection at all by xrandr21:05
wpwraknice. if it looks so bad, it must be something simple :-)21:06
GitHub30[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/tsz4ng21:08
GitHub30milkymist-ng/master 7a6e564 Werner Almesberger: edid.py: sample SCL only every 64 clock cycles, to avoid bouncing...21:08
mw1Fallenou: how is netbsd doing?21:24
wpwrakmaybe a bit more glitches than on CH A, but that's all. and of course, they all get eaten by the downsampling22:30
wpwrakalso the pixel clock blinking is like on CH A22:31
wpwrakmaybe you ran into the PC giving up for good. i've seen that happen a few times. only a HDMI disconnect cured that.22:32
--- Sat Apr 13 201300:00

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