#milkymist IRC log for Thursday, 2011-12-29

azonenbergSo i'm looking at a bit of code for XC6SLX45 that's failing timing01:37
azonenbergin planahead it looks to be ff -> lut -> ff01:37
azonenbergin the path report i see 2.25ns of delay in a FD01:37
azonenberghow does that make sense?01:37
cladamw( ultrasonic cleaner ) http://en.qi-hardware.com/wiki/File:Delta-D80_ultrasonic_cleaner_M1rc3_0x6d.ogv01:38
cladamwhttp://en.qi-hardware.com/wiki/File:Delta-D80_ultrasonic_cleaner_M1rc3_0x6d.JPG01:39
cladamwwill ask what brand & p/n of that liquid.01:40
wpwrakinteresting. that basin is too small :)01:42
cladamwthe video & picture weren't took by me though. :)01:43
cladamwwpwrak, what's liquid when you're using?01:54
wpwraknormally just demineralized water02:00
wpwrak(car supply :)02:00
cladamwwpwrak, ah. you used that? hehe. okay... once I know what they used, I'll tell you. :)02:14
wpwrakisopropyl alcohol should also be safe02:15
wpwrakwith other solvents, you have to be careful that they don't eat your PCBA ;)02:16
wpwrake.g., i wouldn't try paint thinner :)02:16
n0carri3revening all03:16
stekernthe mvu pseudo-instruction (ori rX, r0, I) doesn't seem to be mentioned in the lm32 reference manual, is this something that has been added afterwards?05:54
wolfspraulcladamw: so... :-)08:58
wolfspraulit seems the rc3 production effort is completed?08:59
cladamwyes, the remaining two I'll let minbo to help.09:05
wpwrakcladamw: s/darn/curse/ ? :)09:53
cladamwwpwrak, darn not curse. :) I copied it.09:56
cladamwwpwrak, hmm...just found I typed another word wrong: since an unqualified and unverified with strict reviews after rc2 run we made.09:57
cladamws/with/without :)09:57
cladamwheart and hand were not synced.09:58
wpwrakah ;-) well, most people would just call it "an oversight" :-)09:59
cladamwwpwrak, I'll draw rc4 schematic firstly and include 2*2 usb connector and another usb power switch to let house see if have enough space to placement.09:59
cladamwmmm...that's good word of "oversight".10:00
wpwrak(4 x USB) great ! the more, the merrier :)10:01
wpwrakinteresting. didn't realize you had more than one type of chips that was fake. so it was schmitt-triggers and USB transceivers. or were the usb transceivers just broken, but from the correct source ?10:03
wpwraki don't understand the VGA DCC issue. are you saying the cable was defective ?10:05
cladamwunqualified usb transceiver caused impedance short from TP1(3.3V) to GND. the source of it is the same as schmitt-trigger.10:06
wpwrakor was it a software problem ?10:06
wpwrak(transceivers) ugly :-(10:06
cladamwVGA DDC issue was just expendables (cable problems): http://en.qi-hardware.com/wiki/File:Vga_cables.png10:07
cladamwjust replugged it or switch to another expendable cable will be also pass. not s/w problem.10:08
wpwrakheh. now we know what they don't test when making those cables :)10:08
cladamwwpwrak, but if you found VGA DDC issue could be caused by s/w then I might be wrong.10:09
cladamwbut i just surely a 'replug' or 'exchange' cable will pass it. :-)10:10
wolfspraulrc3 yield is now 88/90? :-)10:10
wpwrak"exchange" sounds like hardware. "replug" could be software. dunno, haven't looked at that at all10:10
wpwrakwolfspraul: if adam makes three more boards work, it's time to get suspicious ;-)10:12
cladamwwpwrak, the correct usb transceiver I soldered now is from Digikey.10:14
cladamwwpwrak, oah...really? so 'exchange' and 'replug' could be different at all?10:15
wpwrakmaybe ... or maybe it's the same. some of those statistical errors can be hard to pinpoint.10:16
cladamwi only exchanged one cable once and kept to use it if I found DDC fail then I just 'replug' then pass.10:16
cladamwso from your words: "exchange" >> hardware, "replug" >> s/w, if it does, then it can be s/w.10:17
cladamwAlthough I bought 3 expendables but only kept to use one cable to test all whole rc3 boards, let's hope not the hardware. :(10:19
wpwrak;-)10:21
cladamwwolfspraul, now yes is 88/90.10:21
wolfspraulgood10:21
wolfspraula little too high but we are not under 'sales pressure' so that's the best use of our time on the manufacturing side10:21
wolfspraulmaybe I should say 'demand pressure' :-)10:22
wolfspraulbut it's good that we made so many valuable findings in rc310:22
wolfspraul2 more boards to find out about, right?10:23
wolfspraulso our rc4 target yield rate will be a cool 100% :-)10:23
cladamwyes, two more. let's hope that. M1pre-rc4 already has had big routing there.10:26
wolfspraulwpwrak: how about mechanical stability of the daughterboard which you mentioned several times?10:28
wolfspraulshould we do something about that in rc4?10:29
wpwraki think it would be nice to have a second connector, like J21, but as far as possible from it, with no tall components in between, and Jnew and J21 parallel and aligned with each other. so that you can make a "U"-shaped board. kinda like the arduino shields10:31
wpwrakwe still have a bunch of unassigned FPGA pins. maybe we could route them there10:32
sb0azonenberg, use fpga editor to get a lower level view10:32
cladamwwpwrak, hmm..."U"-shaped10:37
wpwrakwell, inversed U :)10:40
wpwrakso that, if you make a PCB, J21 is on one side, Jnew on the other -> great mechanical stability10:40
wolfspraulok10:49
wolfspraulcladamw: does that make sense?10:49
cladamwwolfspraul, what would you try to say?10:52
wolfspraulwerner just described some ideas for an improved expansion connector10:53
wolfspraulor rather 2, to be both backward compatible and also add mechanical stability to daughterboards10:53
cladamwwpwrak, are you trying to strengthen the mechanical stability between top and bottom case or given an option of arduino shield-alike?10:54
wpwrakthe latter. it's not connected to the case. it's just a companion for J2110:55
cladamwwolfspraul, when you said a "daughterboard", did you mean that JTAG/Serial daughter board or the one can plug into this new idea of "U"-shaped?10:55
wpwrakuse case: you want to make a small DIY board, say, with some adapter or a small circuit10:56
wpwrak(daughterboard) the latter10:56
wolfspraulno definitely I don't mean the jtag-serial daughterboard10:56
wolfspraulI mean the expansion header10:56
cladamwi see now. phew~ sorry10:56
wolfspraulbbiab10:57
cladamwthe idea of "U"-shaped should be placed as close as one of four corner as possible, otherwise if one can bend pcb when he plug a daughter board.10:58
wpwrakgood point. or we could add a space in the main pcb near the connector. or at least provide a hole for such a spacer, so that people who need this can add one10:59
cladamwthe J21 now is close to fpga,11:00
cladamwbut i think we could arrange audio rounte a bit11:00
cladamwthe J21 moves to MIC a bit and Jnew placed to C23 C25 area then we have this feature.11:01
wpwraks/space/spacer/11:01
wpwrakyes, sounds good. J21 can't move a lot, because you need a bit of clearance for connector, pcb border, etc. maybe 1-2 mm.11:02
cladamwwpwrak, yes, also good point either a spacer or a hole, otherwise oneday someone will lose his M1 when plug daughter board.11:02
cladamwyes, may just 1-2 mm.11:03
cladamwwpwrak, btw, so you said that we still use 2-rows connector like J21 now, and the other surely is also 2-rows one? or your minds is like arduino? theirs is 1-row only in one side.11:04
cladamwthe more the better I read your minds now. :-) so it's 2-rows(the same).11:06
cladamwwpwrak, wolfspraul just added into wiki: http://en.qi-hardware.com/wiki/Milkymist_One_RC3_Known_Issues#Minor_errors_and_improvements11:22
wpwrakyes, 2 rows. i also wouldn't change the pin assignment on J21, so that we can be compatible11:24
cladamwwpwrak, I'll add them into sch. We need 3.3V/GND/other un-used fpga pins, do you think that we need 5V?11:24
wpwrakthat's mainly of interest for people like us, who have some "old" M1s ;-)11:24
cladamwi see.11:24
cladamwthink about if need 5V?11:25
wpwrak(5 V) hmm, not sure. probably not. if someone really needs 5 V, they can get it from J21 anyway11:25
cladamweven J21 now has two 5V already.11:25
cladamwhmm...so another Jnew: another two GNDs and all others are un-used fpga pins. How do you think?11:26
wpwrakmaybe also put 3.3 V there11:27
wpwrakthe rest sounds good11:28
wpwrakoh, and regarding USB, need to check if our DC input path is good to handle at least continuous ~ 3 A. (1 A for the M1, 4 x 500 mA for USB)11:29
wpwrakmost HID and USB-MIDI devices consume far less, but better safe than sorry11:30
cladamwyup...this is must. btw, we can do this after i go to house and to see the placement then we can discuss then.11:30
sb0I guess this will cause issues with the polyswitch fuse, and the zeners which should trip it when the polarity is reversed ...11:30
wpwraksb0: a "make valgrind" after the last set of patches may be interesting. i'm still not sure what causes all the parser weirdness on your side. it almost seems as if your lemon created parsers that are quite different from the ones mine makes.11:31
sb0or worse, during an overvoltage - because in this case, the zeners dissipate11:31
cladamwif we sure that we go for this, then we need to ask DC adapter vendor to provide 1-2 samples to try.11:31
wpwraksb0: you mean that the fuse needs to get bigger and then the zeners need to grow too, to still trip the fuse ?11:32
sb0yes11:32
sb0quite messy11:32
wpwrak;-)11:32
cladamwwpwrak, if we sure go for 4 x usb, then we need to do experiment about fuse/zener again. :)11:33
wpwrakmaybe for rc5, we can have a local DC-DC frontend. then a lot of problems will disappear :) (and hopefully, not too many new ones will make their appearance)11:33
cladamwthis is to decide the trip/hold current of PTC fuse. :)11:34
sb0alternatively, connect the USB ports directly to the power supply, with their own zener and polyswitch11:34
sb0this should alleviate the voltage drop issues, too11:34
wpwrakah yes, that would be an option. also spreads out the current. i like that idea.11:35
wpwrakyup11:35
GitHub0[flickernoise] sbourdeauducq pushed 3 new commits to master: http://git.io/_iRnxw11:59
GitHub0[flickernoise/master] compiler/compiler.h: include fpvm/fpvm.h for FPVM_MAXSYMLEN - Werner Almesberger11:59
GitHub0[flickernoise/master] compiler: added sanity checks for scanner - Werner Almesberger11:59
GitHub0[flickernoise/master] parser_helper.c: provide valid context with EOF; cleanup - Werner Almesberger11:59
wpwrakbtw, would you expect anything nasty to happen if we increase FPVM_MAXERRLEN ?12:02
sb0no12:03
sb0btw - do you want commit access?12:03
GitHub150[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/5645389079d6bbc9061bc18f07e0faaaeb2792b012:03
GitHub150[milkymist/master] milkymist: declare "code" argument of pfpu_dump "const" - Werner Almesberger12:03
sb0the only problem will be that long messages will not fit anymore in the status bar of the patch editor12:04
wpwrakthat may be a good idea. i feel a bit sorry for you each time i send off one of these patch collections :)12:04
sb0ok, do you have a github account?12:05
wpwrakyes, the status bar is a bit of a problem. we could perhaps make things a bit more structured there, and let the editor simply jump to the error location, reducing the amount of information to display as text12:05
wpwraknot yet. creating one ...12:05
wpwrakshould work now. username: wpwrak12:11
sb0wpwrak, it is legal to call pixbuf_dec_ref() on a NULL pointer. it just does nothing.12:32
sb0or maybe you just don't want to pull the pixbuf_* functions in the standalone build?12:33
wpwrakyup, that's the main issue12:33
wpwraki could of course provide my own pixbuf_dec_ref dummy12:33
sb0well... both are ugly. and it's just a small detail...12:35
wpwrakyeah, i wasn't quite sure which of the two would really be the lesser evil in the end :)12:36
GitHub116[flickernoise] sbourdeauducq pushed 13 new commits to master: http://git.io/MuKODw12:44
GitHub116[flickernoise/master] parser.y: use <...> instead of "..." for external includes (by Xiangfu Liu) - Werner Almesberger12:44
GitHub116[flickernoise/master] parser_helper.c: don't leak last "struct id" - Werner Almesberger12:44
GitHub116[flickernoise/master] parser.y: plug various memory leaks in the parser - Werner Almesberger12:44
wpwrak(github additions) thanks a lot !12:46
sb0wpwrak, btw, the tests are passing now13:16
sb0(without valgrind)13:16
sb0trying valgrind now ...13:16
wpwrakfunny. the additional freeing should have made things worse if anything :)13:17
sb0passes with valgrind too13:23
wpwrakkewl. how does it look on the M1 then ?13:24
sb0dunno... I'm not at home atm, and my eeepc takes some time to compile rtems ;)13:24
wpwrakaah :)13:25
wpwrakwell, let's hope for the best then :)13:25
wpwraki wouldn't be overly disappointed if that mystery bug just vanished without explanation ;-)13:25
sb0grmbl... rtems head breaks FN14:39
sb0thanks to ralf, of course. so this may be difficult ...14:45
sb0ah, and he also broke the DHCP server14:45
sb0s/server/client14:46
Action: sb0 wishes ralf would take care of things like race conditions instead of being anal retentive about coding standards. alas, it takes more effort and it's easier to be wrong...15:02
lars_who is ralf?15:04
sb0one of the RTEMS developers who's always questioning the slightest bit of change or of standard-noncompliance15:06
sb0there was recently a nice ralf-fueled bikeshed thread on the RTEMS ML if you're interested in this sort of things15:07
sb0so, what just happened is ralf declared some non-standard functions that we use static15:08
sb0the problem is it cannot be done otherwise without introducing bugs or duplicating large amounts of code15:08
sb0I'm sure I'll get a flame message telling me this stuff isn't in POSIX and I should not use it15:09
sb0100% certain15:09
sb0http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality15:10
azonenbergsb0: Good one, i'll have to try that15:34
azonenbergIn planahead everything looked fine15:34
azonenbergthe strange thign is, it shows up in the analysis as logic delay and not routing15:35
azonenbergin planahead15:36
azonenbergBut in the ISE timing nalysis tool there are a couple of additional LUTs that i dont see in planahead... wtf15:36
azonenbergand in that case it shows up mostly as routing delay... which still leaves me needing to add another FF level to this pipeline in order to make timing15:37
sb0maybe it's a route-thru LUT to enable you to reach the first FF?16:13
sb0though the S6 architecture is supposed to have bypass lines that let you reach directly into half of the slice FFs without going through the LUTs...16:14
sb0note that route-thru LUTs are added by MAP or PAR (can't remember which one) and do not show up in the netlist16:15
sb0you need to use XDL or FPGA Editor to see them. not sure how Planahead handles them, apparently not so nicely maybe ;)16:17
hervebonsoir17:23
sb0hi herve17:34
sb0wpwrak, how do you omit per-frame at each equation? does having a line with just 'per-frame' on it make the compiler treat all subsequent equations as per-frame?17:34
sb0or does it have to be 'per_frame=eqn1\n eqn2 ...'?17:35
sb0I prefer the first solution17:35
sb0wow, Ralf didn't bitch this time. unbelievable :) so I can only swallow my harsh words...17:58
Fallenounice HDCP man in the middle (overlay on hdmi link)  attack using FPGA (spartan 6) at 28c318:08
sb0this isn't really an attack, and the HDCP master key is known anyway18:10
wpwraksb0: yes, per_frame= is "sticky". this causes a minor divergence in semantics, i.e., if you had something like   per_frame=foo=bar\nglobal=blah  it would now behave as if it was18:13
wpwrakper_frame=foo=bar;global=blah  but i guess few people will notice and even fewer will actually depend on such things working ;)18:14
Fallenousb0: well it's man in the middle, to me it sounds like an attack18:14
Fallenouand indeed master key is known18:14
Fallenouit's just nice that they implemented such a thing (overlay)18:15
sb0well, a legal attack then18:15
sb0a DMCA trolling device18:15
Fallenouyes basically18:15
wpwraksb0: the new parser doesn't care about whether assignment and per_frame= are on the same line. \n has basically become just another space now18:16
wpwraksb0: i was thinking of maybe making per_frame= and such act exactly like they did before, and then introducing a per_frame: that would act like a switch. not sure if it's worth the effort, though18:17
wpwraksb0: even as a 100% alias of per_frame=, the per_frame: syntax may be useful, though, just to set it apart from assignments18:17
sb0hmm... imo the 'switch' is clearer, too18:18
sb0yes18:18
Fallenou(off topic) if someone can tell me why I don't see the same thing in gtkwave and in vvp simulator it would make my headache stop : http://pastebin.com/KDi11THZ :)18:39
Fallenouabout the devices_do_ack[] wire18:40
Fallenou-wire/bus18:40
lars_race in your memory controller? bug in vpp? i guess it could be pretty much anything19:11
Fallenouweird thing is that the gtkwave file is generated by vvp19:13
FallenouI find it strange that vvp $displays() something different than what gtkwave does19:13
lars_one way to track down the problem would be to try another waveform viewer and another simulator19:15
lars_cause right now you don't really know whether it is a problem with gtkwave or vvp19:16
FallenouOK I just added a $monitor("devices_do_ack == %b at %0d", devices_do_ack, $time); as second statement of initial block19:17
Fallenoumonitor displays 100 / 001 etc (like gtkwave)19:17
FallenouI think I will just stop using $display() as a debug feature :)19:20
sb0Fallenou, try using non blocking assignment e.g. on the clock generation19:21
sb0this sounds like a delta delay problem19:21
sb0well ... I guess a migen simulator would be cool. would get rid of such issues as well :)19:22
sb0delta delays are just free headaches when you're doing synchronous design19:23
Fallenouoh yes I just noticed I'm using '=' instead of '<=' for this particular array of wires19:23
Fallenouthanks19:23
Fallenousb0: you just solved my problem !19:24
Fallenouthanks!19:24
--- Fri Dec 30 201100:00

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