04:05 <wpwrak> grrr

04:07 <wpwrak> fir the logs, the answer would have been: http://projects.qi-hardware.com/index.php/p/kicad-libs/source/tree/master/modules/stdpass.fpd

04:08 <wpwrak> and the *-M footprints exist only for historical reasons and should be ignored (they're identical to the non -M versions)

05:44 <mbuf> is there a RSS feed to track releases of milkymist software? in particular http://milkymist.org/socdist/

08:29 <cladamw> good, just made a book done on next Tuesday for using ultrasonic cleaner.

08:35 <wolfspraul> wpwrak: I didn't fully understand your usb power switch mail

08:35 <wolfspraul> last I unerstood was that connecting the i-creativ would reset your m1rc4 board

08:35 <wolfspraul> that doesn't sound good :-)

08:36 <wolfspraul> but that was without the power switch?

08:36 <wolfspraul> and the power switch works or doesn't work?

10:08 <lekernel> wpwrak: __set is only for object attributes, no?

10:56 <wpwrak> wolfspraul: the i-creativ was with my old M1rc3 reworked with the 4.0 V reset chip. (but without USB power switch)

10:58 <wpwrak> wolfspraul: the power switch in M1pre-rc4 seems to offer partial protection. i think the i-creativ will be fine with it. it's a bit difficult to make non-synthetic tests because the usb receptacles don't have a good connection. tilt them a little and they disconnect from VBUS.

10:59 <wpwrak> lekernel: should only be attributes - unless there's more evil going on underneath i haven't figured out yet :)

11:01 <wolfspraul> wpwrak: hmm

11:01 <wolfspraul> :-)

11:02 <wolfspraul> you know I'm a skeptic reader. what does 'partial' mean? :-)

11:02 <wolfspraul> I guess work is still ongoing...

11:02 <wolfspraul> no rush

11:02 <wolfspraul> thanks a lot for helping with this and testing and all! that is really great

11:05 <wpwrak> (partial) means that, it i create a worst-case scenario of a straight short, then there's no hope of escaping a reset

11:06 <wpwrak> s/it/if/

11:07 <wpwrak> however, if the USB thing is at least halfway civilized, it's probably okay. also excessive capacitative loads aren't as bad as a straight short

11:12 <wolfspraul> and what does that mean in the bottom line?

11:12 <wolfspraul> what is a 'good' design for m1?

11:13 <wolfspraul> you know it can never be perfect... we can just add more and more protection but make the actual design worse. have we find the perfect balance yet? or not sure yet?

11:25 <wpwrak> i think we'll find it "adequate"

11:26 <wpwrak> maybe we can move to monitoring the regulators derived from 5 V in the future. that would avoid spurious resets on USB upsets that don't affect internal operation of the M1.

11:28 <wpwrak> that would still leave the 5 V rail vulnerable to major upsets

11:29 <wpwrak> (adequate) i.e., even the worse-case overcurrent insult (shorting) will not cause damage. but it will reset the M1.

11:30 <wpwrak> (adequate) non-broken USB equipment, even if exceeding the specs in a bad way, will probably work. still need to check a few more things, though.

11:35 <wpwrak> (more things) i.e., see how real-life loads perform. also, check that we don't drop too much voltage on the switch

11:42 <cladamw> wpwrak, hi nice report ! one question about (over 3000 samples). how long does it take while measuring 3k samples? And time slot varies in reference to where?

11:52 <wpwrak> thanks ! :) hmm, never measured how long it takes. let's see ... about two minutes ...

11:54 <wpwrak> yeah, ~126 seconds

11:55 <wpwrak> and the averaging was 1 PLC, not 10. corrected.

11:55 <wpwrak> i did the whole set of tests spread over something like 12 hours, so there are also some environmental variations in there

11:56 <cladamw> mmm...so from the time happened of 'short' then started to count 3k in ~126 seconds? or count it but not include the period of 'short', right?

11:57 <cladamw> 40us vs 126 second, the result of samples should be still quite the same I guess. :)

11:59 <wpwrak> ah yes, the voltage measurements are in stable states. so either without short or permanently shorted

11:59 <wpwrak> my meter isn't fast enough to catch the drops in a short

12:01 <wpwrak> at the fastest setting, i could measure at maybe ~1.25 kHz

12:02 <cladamw> understood now. :)

12:03 <wpwrak> naw, even less. about 300 Hz. way too slow :) only the scope helps there

16:21 <lekernel> what does the verilog standard say for zero-length constants? e.g. $display("%b", {4'b1010, 0'b0});

16:21 <lekernel> gplcver => 101000000000000000000000000000000000

16:21 <lekernel> iverilog => 1010

16:21 <lekernel> ...

16:23 <lars_> interesting

16:24 <lars_> it's probably not even legal by the standard ;)

16:27 <lars_> or maybe it says undefined behaviour in which case the two implementations would be correct

18:41 <GitHub13> [migen] sbourdeauducq pushed 3 new commits to master: https://github.com/milkymist/migen/compare/8a394f9...f0aac4b

18:41 <GitHub13> [migen/master] corelogic: operator tree - Sebastien Bourdeauducq

18:41 <GitHub13> [migen/master] csr: use optree - Sebastien Bourdeauducq

18:41 <GitHub13> [migen/master] flow: actor class - Sebastien Bourdeauducq

23:40 <GitHub146> [migen] sbourdeauducq pushed 3 new commits to master: https://github.com/milkymist/migen/compare/f0aac4b...1ce4fbd

23:40 <GitHub146> [migen/master] fhdl: encapsulate replicated constants - Sebastien Bourdeauducq

23:40 <GitHub146> [migen/master] flow: sum and division actors - Sebastien Bourdeauducq

23:40 <GitHub146> [migen/master] example: flow conversion - Sebastien Bourdeauducq