#milkymist IRC log for Friday, 2012-01-20

wolfspraulwhat memory bandwidth can the Milkymist SoC achieve right now?08:16
cladamwwolfspraul, , hi good morning !08:18
cladamwIs qi server down now?08:18
cladamwI need to upload files. ;-)08:19
wolfspraulcladamw: it was down earlier, but how about now?08:20
cladamwmmm...good now it's okay08:20
wolfspraulgood morning08:20
wolfspraullast day before holiday? :-)08:20
wolfspraulyou deserve your holiday!08:20
cladamwoah...yes, i just revised R4 about LEDs multiplexing matrix from Werner.08:21
cladamwso moments...08:21
wolfspraulcladamw: we plan to make it possible to disable the power led from software08:22
wolfsprauldo you have that already?08:22
wolfspraulthe proposal is somewhere in the backlog08:23
wolfspraulI mean the technical proposal08:23
cladamwyes. i saw that keeping D1 ~ D3 but maybe move D1 to power supply source.08:24
wolfspraulnot just 'move', but the idea is that software can disable it08:24
wolfspraulfor that we need to do some extra electric circuitry08:25
cladamwand Werner thought current D2 and D3 are good to be as indicator of status of booting or reconfiguration.08:25
wolfspraulif in a totally dark room, someone wants to turn *off* all leds08:25
cladamwyeah...08:25
wolfspraulI think we can remove one of the two (D2/D3), but let's wait for Werner on this08:25
wolfspraulWerner is making experiments, we should follow the results of those, I think08:26
cladamwso I currently doesn't touch exsiting D1 ~ D3.08:26
wolfspraulD1 is special08:26
wolfspraulD1 cannot be software controlled right now08:26
wolfspraulcorrect?08:26
cladamwwe can surely move which one is to somewhere easily later. ;-)08:26
wolfsprauland we want to keep D1, 'power' led - it's good08:26
wolfspraulI am not talking about 'moving'08:26
wolfspraulI am talking about making it possible for software to disable D108:27
cladamwyes, D1 is not controlled by s/w now.08:27
wolfspraulyes but we want to make that possible08:27
wolfspraulat least to turn it off, override it's natural state08:27
wolfspraullet me see whether I can extract the technical proposal from the log08:27
cladamwyeah....okay..do you want me to revise it again now. hehe... should be no problem08:27
wolfspraulthat's unrelated to the other leds08:28
cladamwsince D1 is directly driven by 3V308:28
wolfspraulD1 is a special case08:28
cladamwyes, i know08:28
wolfspraulso I think we can settle that one first08:28
wolfsprauland yes, make it possible for software to disable it08:28
wolfspraulI have yet to hear someone who says that that is a bad idea08:28
wolfspraulso let's do it (cause I think it's a good idea :-))08:28
cladamwin order to give a remotely control also as indicator, so I have to pull one un-used fpga pin to that D1 then we have s/w control and indication feature08:29
wolfspraulwait Werner wrote something, I'm searching it08:30
cladamwbut don't know if Werner still want a hardware indicator from direct from 5V or 3.3V. ;-)08:30
wolfspraulwe want a hardware indicator08:30
wolfspraulbut we want to make it possible to override the on status08:30
wolfspraulif m1 is a box for video artists, they surely may want to control what kind of light it emits08:31
cladamwyeah08:31
wolfsprauland not have a bright green forcefully shining upon them - that may be annoying in *certain* (rare or not) situations08:32
wolfspraulso since we work in leds now, let's make it possible for software to turn off D1 manually (overriding it's natural power function)08:32
cladamwokay...overriding needs think a little...;-)08:35
wolfspraulcladamw: not sure now. reading about pullups/npn or equivalent fet08:35
wolfspraulconfirm with Werner08:35
cladamwbtw, multiplexing matrix: Those are for connectors:08:36
wolfspraulthe idea now is that D1 stays the way it is directly from 3V3 power, but in addition it's possible for software to disable it08:36
cladamw 08:36
cladamwDMX TX/RX, MIDI TX/RX, IR, DVI-I, LINE IN/OUT, VIDEO-IN R/G/B, MEMORY CARD, USB A~F, didn't include MIC now.08:36
wolfsprauloh MIC - good point08:36
cladamwwolfspraul, okay08:36
wolfsprauldid we forget about mic before?08:36
cladamwyes, i didn't add MIC before. ;-) just add this morning.08:37
cladamwalso included LINE-IN/OUT.08:37
cladamwso maybe we now think more to if needs MIC from saving other.08:38
wolfspraulwe wait for Werner on this08:38
wolfspraulI know it's your last day before the holidays, but then next week we have time to review and think, usb, leds, expansion08:38
wolfspraulso maybe the best you can do is if you post a complete schematic PDF, then we have one reference point next week?08:39
cladamwlet's uploading newest sch one. so can easily communicate08:39
wolfspraulyes08:39
wolfspraulbtw for this type of draft schematic, it would be good if there was a datecode clearly visible on each page08:40
wolfspraulthen we have some hope that even later we can still reference discussion and PDF together08:40
cladamwyes, there's date on it.08:41
cladamwdraft folder: http://downloads.qi-hardware.com/hardware/milkymist_one/sch/tmp/08:46
cladamwnewest one: http://downloads.qi-hardware.com/hardware/milkymist_one/sch/tmp/Milkymist%20One%20R4%20-%2020120120.pdf08:46
cladamwthe newest one has not fixed D1 with overriding feature.08:47
cladamwletme see pullups/npn/fet idea...;-)08:49
wolfspraulno rush on the leds, I think the entire led thing is not settled yet08:54
wolfspraulwhat is still open right now? 1. expansion 2. led08:55
wolfsprauleverything else is clear?08:55
cladamwyes, i think so. like wish to change Y1, find other candidate DVI-I connector, F2 PTC new p/n to determine, etc...08:57
cladamwi all record in email firstly.08:57
cladamwthe F2 spec needs to be changed since 6 usb ports now ( 6* 0.5mA + 1.0A = 4.0A)08:59
wolfspraulyes, F2 - understood09:02
wolfspraulalthough werner thinks that 2.0A for all USB is enough, he can tell you more about this09:03
wolfspraulwe don't want to overload and overengineer the board09:03
wolfspraulsmaller Y1 - always good. in general I always prefer smaller, we just have to watch that we are still sourcing easily available parts, and price doesn't go up too much09:04
wolfsprauland our time to find that smaller Y1 and test it also needs to be considered09:04
wolfspraulcladamw: btw, whenever Werner has finalized the led proposal, do you think we should test the design? or can we directly test in the run?09:05
cladamwyeah. such things as task to test/verify later we pick a real p/n.09:05
wolfspraulalso remember that we plan to use boom more for R4 sourcing, not sure to which degree we want to or will automate the selection of crystals...09:06
cladamwwolfspraul, good question on this. I also thought up this. even it's simply implemented by passive parts(led and resitors).09:06
cladamwin M1preR4 we have now two can do this experiment via J21 header firstly. ;-)09:07
cladamw3 column plus 3 row pins can do this multiplexing matrix idea.09:09
wolfspraulI think it also depends on Werner's testing09:09
wolfspraulremember that Werner is testing already09:10
wolfspraulso if he says he is sure it works, we can skip a second verification09:10
cladamwI think that we have to do this experiments firstly by s/w through M1preR4.09:10
wolfspraullet Werner make the first step, then we find out what we have to add09:10
cladamwmm.. don't know how he soldering wire or test each led step-by-step?09:10
cladamwokay09:10
wolfspraulwe don't need to test the same simple idea several times either09:10
wolfspraulonly because we are working remotely...09:11
wolfspraulbut it probably should have been tested somewhere, once09:11
cladamwsince the matrix routing in R4 will broadcast in everywhere corner on pcb. hope I don't get surprise in real R4. ;-)09:12
wolfspraulwhat specifically are you worried about?09:12
cladamwsince the matrix idea could be implemented by s/w like scan codes methods, in other words it's not purely DC level, so means variant frequency may on each net of 6 wires.09:15
cladamwi don't know if it will use scanning codes or PWM method to give "Persistence of vision09:17
cladamw" on light.09:17
cladamwshould be alright.09:17
cladamwI'll ask wpwrak ;-)09:20
wolfspraulcladamw: reading through your mail09:44
wolfspraulabout USB test points - yes, not too many test points09:44
wolfsprauladding test points is nice, but we should also remove once in a while09:45
wolfspraulask yourself: which ones have you really been using? can we remove some of the others?09:45
wolfspraulremoving is harder than adding...09:45
wolfspraulbut more worthwhile, often09:45
cladamwthis time when surely we have unqualified chip then I always used to meauring TP then i know directly if chip failed. it's easy for me. so surely i'd like they are still there ! but now usb circuit in m1 have already matured. so _IF_ house they 'feel' not good, then we directly remove all TPs but still reserve only ONE set of test points.09:50
wolfspraulwait wait ;-)09:50
wolfspraulmy point was: there is an action/thought that triggers adding a particular TP09:50
wolfspraulbut which action or thought triggers removing a particular one?09:50
wolfspraulso periodically we should review the ones we have, and quite simply if you remember not having used a TP for a long time, maybe it's a good idea to remove that one?09:51
wolfspraulbut don't wait until the board is totally crowded and then suddenly remove all. that doesn't sound too good either.09:51
wolfspraulthis is just my thinking reading what you say about USB test points09:52
wolfspraulwhich I agree with - not too many in advance, not good09:52
wolfspraulwasteful, and can cause problems09:52
cladamwfour TPs in one usb port is all good for me: OE_N, _RCV, VP, VM which is better than I probe directly on pins of chip.09:56
wolfspraulsure, I'm just explaining my thinking09:57
wolfspraulwe are working on a product, not a devel board09:57
wolfspraulso integrate integrate integrate09:57
wolfspraulTPs are good, they come and go, as the product matures09:57
wolfspraulif there is a thought behind a TP, it's a good TP09:58
wolfspraulbut if they are sprinkled all over without any use or idea behind them - not good - remove09:58
cladamwAll impedance to four TPs nearby usb transceiver are M ohm level. If it's not reachable, then usb port would not work well. i recorded there was to remind myself to cancel them except reserve one set when cowork with house.10:00
cladamwi surely already guessed that high potential possibility will remove out them when thinking them totally crowed. ;-)10:02
cladamwno problem, i just recored actually for myself. ;-) But your points are also good inputs. :-)10:03
wolfspraulcladamw: I think the current consensus is that we want to keep at least one switch of SW1-310:11
wolfspraulone is minimum10:11
cladamwokay ;-)10:14
cladamwnow i realized that overriding by fet, letme draw a draft Misc.SchDoc, then confirm Werner. ;-)10:15
wolfspraulgood10:15
wolfsprauldvi-i hotplug - quite important to get it right imho10:15
wolfspraulin fact, talking about hotplugging - if we can do anything to enable the detection of plug-in events on other connectors - great10:16
wolfspraulso in software right now, can we detect cable insertion or removal of: line in/out, vga, ethernet, video-in, midi, dmx, usb?10:16
wolfspraulif not - we should10:16
cladamw(dvi-i hot plug) sure, now I don't know. ;-)10:16
wolfspraulyes, I just give feedback saying that to do insert/removal detection right may be very valuable later on10:17
wolfspraulhow about the others - can we detect in sw?10:17
wolfspraulethernet - probably can10:17
wolfspraulusb - probably can10:17
wolfspraulline in/out, vga, video-in, midi, dmx ?10:18
wolfsprauldon't know10:18
wolfspraulwe should have a barcode sticker with the serial number glued on each board10:22
cladamw(insert or removal detected by connector) yes, but connector type needs to be different one not the one we have now. or needs to add parts to get function works. then becomes overload and overengineer the board again. ;-)10:22
wolfspraulno overengineer10:22
wolfspraulthe ability to detect insertion/removal can make a dramatic difference on later product behavior10:22
cladamwi was thought the led functions are: states: 0) unused (off), 1) ready for use (e.g., permanently on), 2) error (fast regular blink), 3) in use (activity blink)10:23
wolfspraulyes let's work on led first10:23
cladamwdo all these trying to 'react' current led work and show them. but yours (auto detect on inserting/removing) relying on h/w itself. ;-) like smart Werner solved in matrix way through very few parts.10:25
wolfspraullet's worry about insertion detection later10:27
wolfspraulit may already work on some ports, and even on the others, if we feel worthwhile, let's finish led work first now10:27
wolfsprauland expansion system10:27
wpwrakwolfspraul: (45 mm) that's roughly the distance i get when assuming a reasonable placement for J2211:03
wpwrakwolfspraul: (stacking) we'll specify the maximum height of the expansion board. what you do with this height is your choice :)11:04
wpwrak(ptc) there a is a better proposal, i think from lekernel: just duplicate the input protection circuit. so after J11, you would have (F2, D14, etc.) and (F2b, D14b, etc.)11:11
wpwrak(ptc) the F2 branch would be as it is now: supply the internal circuit and two USB ports11:11
wpwrak(ptc) the F2b branch would supply for more ports. that way, each branch is <= 2 A11:11
wpwrak(led matrix testing) ah, lemme commit what i did yesterday ...11:13
wpwrakhttp://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/ledravaganza/11:15
wpwrakhaven't built one yet, though11:15
wpwrak(usb test points) fwiw, i used pretty much all of them on one port and some of them from the other11:18
wpwrak(usb tps) so i think that, for debugging, we'd want at least two full sets on external ports11:18
wpwrakLEDs: i took some pictures yesterday. lemme prepare them for upload ...11:24
wpwrakin general, there are many difficult placements where it may not be very clear where a led belongs. and we can't use case markings to help to make this clearer (the inscriptions on the case are already basically invisible)11:25
wolfsprauloh, a lot of stuff. lunch first...11:28
wpwrak;-)11:29
wolfspraulback12:13
wolfspraulI think we are all on the same page about test points12:13
wolfspraulI just tried to formulate our policies a little, maybe one day we can write this up properly somewhere12:13
wolfspraulTPs shouldn't be added frivorously, the ones that are there should be useful etc.12:14
wolfspraulonce in a while we should review old TPs to see whether they are still needed12:14
wolfspraulI think we are all in agreements about tps anyway...12:14
wolfspraulleds, yes. awaiting your test results, but no rush. Adam is going into his 1-week vacation anway.12:15
wolfspraulwouldn't write more on case either, yes12:15
wolfspraulexpansion stacking was again more about documenting/FAQ12:16
wolfspraulsomeone asks: Can I stack multiple expansion boards on top of each other?12:16
wolfspraulright now the answer is: We've never thought about that, let us know how it goes :-)12:17
wolfspraulwhat do we know? if people want to stay inside the case, with normal 100mil headers, I'd say 2 vertically stacked expansion boards won't even fit12:18
wolfspraulmaybe barely12:18
wpwrakthe (non-)answer is: as long as you meet the height limitation, you can do whatever you please :)12:19
wolfspraulin order to make a stackable expansion board, someone would need to replicate the male/female headers on the top and bottom of their board? that's all?12:19
wpwrakthe problem would indeed be the total height, though. those critters add .. checking ...12:19
wolfspraullike I said it's just about thinking ahead12:19
wolfsprauldocumenting12:19
wolfspraulotherwise 2 years later someone wants to stack and we realize "oh, if we would have made that one little change 2 years earlier, we ..."12:20
wpwrakabout 10.5 mm between boards. add 1.6 mm for the board. now, our vertical clearance above main pcb is roughly ...12:21
wolfspraulbut someone may a) be willing to keep the case open, developer, etc. or b) use expansion boards that were first developed for m1 on some other milkymist-based board later or c) make a higher case12:21
wpwrak.. 30 mm. so well yes, maybe two layers12:21
wpwrakyes, if you remove the case, anything goes :)12:22
wolfspraulso stacking of exp boards is something that remains an option later on?12:23
wolfspraulanything we can do now to make that easier, or not accidentally make it harder?12:23
wpwrakwe also can't pre-specify each possible variation. i also kept the left side a bit on the simple side. we could squeeze out a few cm2 there. but then, that may come back to haunt us later.12:23
wolfspraulfully agree12:24
wpwrakbesides, few people will follow an overly complicated outline12:24
wolfspraulwhat's our 'official' take on stacking? supported? unsupported? recommended? crazy?12:24
wpwrakthat;s also why i want a single maximum vertical clearance per side. not regions. that's already giving pilots enough trouble ;-)12:24
wpwrak(stacking) nothing e need to specify. but yes, it seems that it's possible within reason12:25
wolfspraulsomeone would have to repeat a female header on the top side of their board?12:26
wolfsprauland route the signals upwards?12:26
wpwrakof course, it all depends on what components you use12:26
lekernelunsupported12:26
wpwrakif they want to do 1:1 stacking, yes12:26
wpwrakif they want to do anything else, well, they have to decide :)12:26
lekernelI doubt there will be any serious expansion board within a year, anyway.12:26
wpwrakone issue of stacking is that the stack as a whole has to comply12:27
wpwrakso you can't make stackable modules that will comply when added underneath any other compliant board12:28
wpwrakbut you're free to make modules that, when combined with each other in a way you define, will result in a compliant stack12:28
wolfspraulI kinda knew Sebastien's reaction :-)12:29
wpwraki think "unsupported" is too strong. it should just be "not our problem" ;-)12:30
wolfspraulour message should be much friendlier, and will be12:30
wolfspraulbut of course, the first board must come before the second one12:30
wolfspraulthe likelihood of the first one appearing may depend on the seriousness of the whole endeavor however, including whether anyone is willing to think ahead or not12:31
wolfspraulbut I think we are clear already12:31
wolfspraulfirst - we define vertical clearance12:31
wolfspraulwe are not aware of anything right now that would stop someone from making stackable expansion boards12:32
wolfspraulright?12:32
wolfsprauland we are trying to not do anything to make that harder12:32
wolfspraulaccidentally12:32
cladamwwpwrak, the D1 overriding, do you meant like this: http://downloads.qi-hardware.com/people/adam/m1/tmp/m1r4/Misc_D1_20120120.pdf12:32
wolfspraullekernel: what type of expansion board would you find interesting or helpful for the milkymist platform?12:33
wpwrakone of these days i have to learn how FETs work ... :)12:34
lekernelsecond video output12:34
wpwrakcladamw: lemme draw what i had in mind (with a BJT). you can then tell me if it's equivalent :)12:34
lekernelor built-in LCD12:34
wolfspraulanalog or digital video output?12:35
lekerneldoesn't matter - as long as there's some 2nd screen12:36
cladamwwpwrak, okay. i just used existing part 2N7002 we have had now. But I've not calculated limited resistance and intput resistance, i just added roughly firstly. ;-)12:36
wpwrakhttp://downloads.qi-hardware.com/people/werner/tmp/d1.ps12:39
Action: wpwrak lusts after a build-in lcd :-)12:40
wolfspraulwpwrak: the above is our stacking answer?12:40
wpwraks/build/built/12:40
wolfspraulI just want to put that aside with something a bit friendlier than "unsupported"12:40
wpwrakwolfspraul: "not our problem" ? yes12:40
wolfspraulyes, but we are not doing anything right now on purpose or accidentally that would make it harder, right?12:41
wpwrakwolfspraul: it's something we don't specify. someone else if cordially invited to specify some stacking architecture12:41
wolfsprauland if someone sees something that we could do to make it easier, we would like to hear that, right?12:41
wolfspraulthe difference whether someone feels invited or excluded can be very subtle :-)12:41
wolfsprauljust think how you go around when you compare options...12:41
lekernelif that person has a genuine intent to make good stacked boards and isn't just throwing random ideas into the air, yes12:42
wpwrakwolfspraul: it's like an airline telling you you can have 20 kg of luggage. but whether it's in bags, suitcases, or skis, they don't care. (well, nowadays they increasingly do, but they're a few decades of bureaucratic evolution ahead of us :)12:43
wpwrakcladamw: (d1 switch) untested, of course :)12:43
wpwrakcladamw: would have to check if the pull-up lets through enough current. R2 isn't strictly necessary if we operate only with pull-up vs. "0". it would be necessary if we also want to output a strong "1".12:44
wpwrakcladamw: similarly, don't need a bias resistor unless we output "Z", which , afaik, should never happen12:45
cladamw_wpwrak, hmm? let us sync in same picture firstly: Power On --> (D1 ON), fpga pin normal high --> (D1 ON), fpga pin active low --> (D1 OFF)12:46
wpwrakwolfspraul: a stacking specification would necessarily restrict the choices available to boards that conform to it. restrict beyond what the basic extension board spec specified.12:46
wpwrakcladamw: no, it's active high12:47
cladamw_wpwrak, yes, yours is active high( i know ). hehe...i'm thinking that ours m1 behaviour. ;-)12:48
wpwrakcladamw: possible outputs: "0" = LED off, Z with pull-up = LED on, Z without pull-up = forbidden, "1" = either LED on or forbidden, depending on whether we have R2 (i would place R2, for peace of mind)12:49
wolfspraulI just imagine an FAQ with 'Can expansion boards be stacked?", and I want to give a good answer that shows that we care12:49
wolfspraulbut I think we have enough data points for that answer now12:49
wolfsprauldone :-)12:49
cladamw_wpwrak, mmm...my answer is we are getting same actions both ways. ;-)12:50
wpwrakwolfspraul: there is a lot you have to take into account when stacking. also how you keep non-shared signals from overlapping, how you manage the current budget of shared signals, etc.12:51
cladamw_wpwrak, yours is also work in theory. alright ! cool.12:52
wpwrak(stacking) i think we can safely leave this work to the XBRD Implementer's Forum, Committee of Stacking and the various workgroups it will spawn ;-)12:53
wpwrakcladamw: (same action) perfect then :) i think a FET may a bit more robust, because it doesn't care so much about the pull-up current. so that's good. i'm not entirely happy about burning 27.5 mA with the LED is off, though.12:55
wpwrakalmost 100 mW. at some point, you have to specify the current rating of R41 :)12:55
cladamw_wpwrak, mmm... wait... i forgot Z-input condition, ;-O but my fet with Z-input, the D1 must be still ON unless you send low-input. ;-)12:56
wpwraki'm not sure we need to consider Z12:57
cladamw_yes, R41 may change to 0603. ;-)12:57
wpwrakthe FPGA should reset into pull-up. after that, software has to do the right thing12:58
cladamw_Z-input while only quickly shows after power up, but yes, it doesn't matter though. ;-)12:58
wpwrakone bug in 201201119:12:59
wpwrakSW_RESET_N shouldn't exist. or, rather, it should replace the FLASH_RESET_N on P2213:00
cladamw_good, when you find somethings while i'm in vacation, just sum up in replying email, tks.13:00
wpwrakah, you're about to run. a wise decision :)13:00
cladamw_the newest one now is 20120120.13:02
wpwrakah, here it is ... http://downloads.qi-hardware.com/hardware/milkymist_one/sch/tmp/20120120/Milkymist One R4 - 20120120.pdf13:04
cladamw_we can use IO_L18P_2 or IO_L30N_GCLK0_USERCCLK_213:05
wpwrakfor D1 ?13:06
cladamw_still no SW_RESET_N, good catch ! ;-)13:06
cladamw_no, can for SW_RESET_N. ;-)13:06
wpwrakoh .. no. SW_RESET_N doens't need a new pin13:06
wpwrakand you already have it, on P2113:07
cladamw_for D1's s/w control , haven't been assigned in 20120120.13:07
wpwrak(U22B)13:07
wpwrakthe problem is that what you call SW_RESET_N should replace the old FLASH_RESET_N on the FPGA side13:07
wpwrakso if you delete FLASH_RESET_N on U22B.P22 and move SW_RESET_N up from U22B.P21 to U22B.P22, it'll be right13:08
wpwraki.e., U25 divides the FPGA and the NOR side of the reset signal (and mixes it with the output of the reset chip)13:09
cladamw_oah..yah...already there i added. ;-)13:10
wolfspraulcladamw_: maybe you make a note on the wiki somewhere about SW_RESET_N13:10
cladamw_yeah13:10
wolfsprauljust so we don't forget13:10
wpwrakor just edit it. shold tkae < 5 seconds ;-)13:11
wolfspraulme? sure I always edit but I may get the tech details wrong or link to the irc log instead. so if adam is around that's better...13:12
wpwrakwolfspraul: i mean that it would be considerably faster for adam to edit the schematics than to wiki-document what needs editing :)13:12
wolfspraultrue, but the wiki also serves as long-term documentation, which is difficult to do with the Altium files13:13
wolfsprauland we have no kicad/schhist...13:13
wpwrakyeah, kinda sucks. didn't excpect to miss it that much that quickly13:13
wolfspraulonce we have it in kicad/schhist, we can retire the wiki, but until then the wiki complements altium, that's better than just having a big altium black box13:13
cladamw_(wiki R4 feedbacks) http://en.qi-hardware.com/wiki/Milkymist_One_RC3_Known_Issues#R4_draft_feedback13:14
wpwrakkewl. thanks !13:14
cladamw_hehe...must my brain got stuck then ! hehe .... ;-O13:15
wpwraki'll be afk for a few minutes. adam, you'll probably be heading out already. happy new year and enjoy the holiday !13:15
wolfspraulwpwrak: Adam's note about dvi-i hotplug detection made me think about hotplug detection across the board13:15
wolfspraulah, then when u r back13:15
wolfspraulyes Adam, happy new year!13:16
wolfspraulI hope we can party in Taipei again one day!13:16
wolfspraulall of us13:16
cladamw_so pls either reply in email or edit that wiki link, then when I'm back, i read them. ;-)13:16
cladamw_wolfspraul, ah. thanks.13:17
cladamw_wpwrak, wolfspraul thanks and all guys here.13:18
cladamw_i'll off now, cu.13:18
wolfspraulcu13:20
wpwrakwolfspraul: (hotplug) hmm, are the DMX and MIDI connectors with built-in switches ?13:41
wolfspraulwell, let's first see where it works already13:41
wolfspraulI think for ethernet and usb, it's supported by default, no/13:41
wolfspraul?13:41
wolfspraulI think I asked lekernel once about Ethernet, and he said the wires are there, just sw missing13:42
wolfsprauland for usb I think it always was there, must be in right in the standard?13:42
wolfspraulis that true?13:42
wpwrakusb has a detection, yes. not sure if the transceiver passes that on, though.13:43
wolfspraullekernel: do you know off the top of your mind which ports on m1 can detect insertion in software, and which cannot?13:44
wolfspraulthen we can zoom in faster :-)13:44
wpwrak(usb) well, it should be able to signal that. just via VP/VM going from SE0 to differential while OE_N is inactive.13:45
wolfspraullekernel: oh, another question: what memory bandwidth does the Milkymist SoC achieve right now on m1 ?13:46
FallenouI think you can detect ethernet link via mii, just needs soft13:47
wpwrakaudio seems to need some circuit change for hotplug detection. thw switches currently simply seem shorted13:48
Fallenoumdio stuff13:48
wolfspraulok, interesting [audio]13:48
wpwrakVGA/DVI: no idea. maybe with DDC ?13:48
wpwrakJ21/J22: i don't think we care ;-)13:49
wolfspraulyou would wnat to be able to detect insertion or removal without polling all the time13:49
wolfspraulso audio may be one target13:49
wolfspraulvideo-in, midi, dmx ?13:49
wpwrakMMC: has a detection pin (DAT3/CD)13:49
wpwrakDMX: no idea. one bug: U5 doesn't say what chip it is13:51
wpwrak(in the schematics. neither rc3 nor r4)13:51
wpwrakMIDI: dunno either13:51
wpwrakperhaps topic for the list. there may be people who know that stuff a lot better than we do :)13:52
wpwrakDC: implicit :)13:52
wolfspraulyes :-)13:52
wolfspraulwe can ask on the list, but let's see what sebastien knows, he designed the board initially and may remember details like those13:52
wpwrakvideo in: via sync detection perhaps. we do have some auto-detection of the signal. but i don't know how far it goes.13:54
wpwrakthat should be all the connectors13:54
wolfspraulgood13:55
wolfspraulsounds like we can improve in a few cases13:55
wpwrakyup. at least audio13:57
wolfspraulyes13:57
larscDVI should have a HDP (hotplug detect pin) which is pulled high if a connector is inserted13:59
wolfspraulthat's what got the discussion started, we ran into this pin and didn't know right away what to do with it13:59
wpwrakah yes, Hot Plug Det, pin 16. currently NC.14:00
wolfspraulI personally think software should be able to detect any sort of cable insertion or removal into the board, some kind of 'self awareness'14:00
wolfspraulwe want to put software in control...14:00
wolfspraulbut let's see one by one where that is easy and makes the most sense14:00
wpwrak(self awareness) now we know how all that skynet business began ..14:01
wolfspraulwpwrak: yes, and Adam wrote he didn't know yet what we wanted to do with that pin14:01
Fallenouthe general purpose output register (05) of the video-in chip seems to have an HL_EN bit to enable the GPO[0] pin to output HLOCK status14:07
Fallenoumaybe it's interesting14:07
wolfspraulI am upgrading my unit to RC3 today - yuhuuu. my chinese new year gift :-)14:48
wolfspraulwill send some more rc2 to Adam later for hw upgrading...14:48
wolfsprauleasy 23 steps14:48
Fallenouhappy chinese new year btw !15:01
wpwrak(easy 23 steps) oh dear. i hope you have a few spares ;-)15:49
lekernelwolfspraul: ethernet detection needs MDIO, which currently has only incomplete and buggy software to drive it15:55
lekernelwolfspraul: memory bw is explained http://milkymist.org/thesis/thesis.pdf p 29-3215:57
wpwrakspeaking of which, it's a little hard to find. how about having a box/page with useful links ? perhaps similar to what you had on the old site, but without the stubs15:59
wpwrakor maybe add an item list at the bottom of http://milkymist.org/wp/for-developers/16:00
wpwrak(for thesis and hw links)16:00
wolfspraulthanks [lekernel]16:36
wolfsprauland yes, I haven't read the entire thesis yet but I should and will16:36
rohi am missing the big pics on that page17:07
rohhad people asking and me not finding them on the new page... highres-pcb shots17:08
lekernelwtf? 6x USB and a LED for each port?17:09
lekernelwhat's the use for that?17:09
wpwraki have my doubt about those usb leds. they certainly have no "port is waiting" role. they could work as error indicators, though17:11
wpwrakthe 6 x usb is simply to have a sufficient number of placement choices. besides, you can never have to many usb ports :)17:14
lekernelbut they're not free. they have a cost in PCB routing effort, mech design, parts, testing and software development.17:16
lekerneland we have that very nice expansion connector, for niche users needing more USB ports ...17:17
wpwrakit's not so much about needing 6 ports at the same time but about needing a few external and then some more internal-or-external ports. but trying to limit the sum < 6 doesn't make things easier17:22
lekernelinternal stuff should use the expansion connector17:22
wpwrakyes, it could. but that's probably even more expensive :)17:23
lekernel?17:23
wpwrakmaking yet another pcb17:23
wpwrakwith active components etc.17:23
lekernelI'm not sure many people will need it17:23
wolfspraulwe could layout some pins on the new J22 so that the normal 5*1 or 5*2 USB connectors fit right there17:23
wpwrakplus, people would lose the standard keyboard (in case we switch to rf)17:23
wolfspraulbut then there would stlil be the problem of transceiver17:23
lekernelactually, right now our problem seems to be more about people using none of the USB connectors than anything else17:24
wolfspraulI think a ready-made USB header including transeiver is better17:24
wpwrakoh, they're trying :)17:24
lekernelbut why? who needs that?17:24
wolfspraulpeople have to believe in the future before they make the first step17:24
wpwrakwe're still behind on a few fronts with usb. 1) stack still has issues. 2) official build lightyears behind. 3) new marketing emphasizing on midi(-usb) controls still hasn't really started. 4) the plan to switch to an rf keyboard hasn't led to results yet either.17:26
wpwrakbut give it time and the demand will increase17:26
wpwrakand then we'll be very happy if we don't have people banging on the door, desperate for more ports17:27
lekernelonly then it'll be appropriate to think about more USB ports17:27
wpwrakpatience ;-)17:27
wpwrakif i know i'll want to eat tomorrow and i go shopping today, i usually also buy the stuff for tomorrow ;)17:28
wpwrakeven if i could decide to go hungry tomorrow, or eat out ;-)17:28
lekernelI still have trouble understanding what those 3 extra USB ports will be used for17:28
lekernelatm a very small number of people use <10% of the current platform ...17:29
lekernelit seems counter intuitive to me to simply throw in more features without a clear use case17:30
wpwrakwe may have 2 x usb-midi + kbd (ext) + mouse (ext)17:30
lekernelthat's 417:31
lekernelnot 617:31
wpwrakor kbd/mouse (int) + external stuff (e.g., usb-midi)17:31
wpwrakyes, it's 4 x external17:31
wpwraknow add one internal17:31
lekernelbut why the heck would we want internal USB ports?17:31
lekernellet's say - rather than Firewire, or ...17:32
wpwrakand you're right. i don't see an immediate use case for the 2nd internal port. of course, people will want wlan. but that's a bit further down the road17:32
wpwrakgot an rf keyboard. the dongle needs to go somewhere17:32
wpwraks/got/for/17:32
lekernelthe answer seems straightforward to me: into that external USB port freed by the non-RF keyboard17:33
wpwrakrisky and inconvenient17:33
lekerneldo you see many laptops with an internal USB port for a particular RF keyboard?17:33
lekernelit's similarly "risky and inconvenient" to use the dongle :)17:34
wpwrakrisky because dongles have a big lever. often worse than cables. inconvenient since, if it's your main keyboard, you need to unplug, stow, transport, unstow, plug all the time. andhope you never lose it.17:34
lekernelthat's not our problem17:34
wpwraklaptops already have a keyboard :) and they have do have internal ports for, say, wlan cards :)17:34
lekernelthey have internal PCI-express slots too. want one?17:35
wpwrakcould we make it fit ? ;)17:36
wpwrakbtw, if you think 6 is excessive (alas, power only): http://www.geekstuff4u.com/80-port-usb-charger-board.html17:38
wpwrakin any case, going from 4 external to 6 (4 ext + 2 int) seems a pretty minor hassle. you get one more pair of transceivers, and that's all. you already want to split DC for > 2, so that's no extra cost.17:40
lekernelhow will they be tested?17:41
lekernelwhat if the extra tracks cause SI/EMI regressions?17:41
lekerneland do we really want to increase the BOM cost further?17:42
wpwrakSI/EMI is something we have to test. also when combined with RF.17:42
lekernel"no extra cost" heh :)17:42
wpwrakno extra cost on the DC path. we already swallow that when adding two more external ports17:43
wpwrakthe internal ones are cheap :)17:43
wpwrakspeaking of elephants in the room. we still have those audio path problems. with apparently quite wrong levels. and some things coming from MilkDrop being poorly defined17:55
wpwrakif we have someone with a good background in signal processing, bringing all this under control should be worthwhile challenge :-)17:55
wolfspraul(true) bom cost next step: boom18:14
wolfspraulEMI regressions - I'd like to hear but needs to be a somewhat educated guess not just total fear that any new anything will cause a regression. then we cannot operate anymore.18:15
wolfspraulplus remember we still do work with an experience layout house18:15
wolfspraulexperienced18:15
wolfspraulthere is a reason I keep paying these guys, and we can push them a little harder to dig out the last bit of their experience to help us avoid EMI/signal integrity etc. issues18:16
wolfspraulthe only thing I regret is that we don't really get their feedback 'unrolled', we only see the result like a black box18:16
wolfspraulthat's unfortunate. we'll address that in the future.18:16
mumptaimoin18:53
wolfspraulgood morning!18:54
wolfspraul:-)18:55
GitHub199[migen] sbourdeauducq pushed 2 new commits to newnamer: https://github.com/milkymist/migen/compare/05b20d4...e4f531a21:26
GitHub199[migen/newnamer] Remove NoContext - Sebastien Bourdeauducq21:26
GitHub199[migen/newnamer] Include unused I/Os in pre-naming dictionary and register signals with name_override - Sebastien Bourdeauducq21:26
GitHub55[migen] sbourdeauducq pushed 1 new commit to newnamer: https://github.com/milkymist/migen/commit/e9be3241f63cfe895abe3038264e14d02b310a8121:41
GitHub55[migen/newnamer] Fix instance support - Sebastien Bourdeauducq21:41
wpwrakleds sneak preview: http://downloads.qi-hardware.com/people/werner/tmp/collage-vga.jpg21:41
lekernellooks nerdy21:42
wpwrakthe red leds are a bit dimmed, to give a better view of their position. at maximum duty cycle (~12-16%), they're brighter21:43
wpwraknerdy = good or bad ? :)21:43
wpwrakthe green dots on the top are from my function generator that provided the PWM signal (sits on top of the power supply, outside the image)21:46
wpwrakargh. gimp doesn't save the undo history even in .xcf :-((21:50
wolfspraulI think it's nice, plus such a picture will never get the real impression across21:57
wpwrakokay, this is from the best-case side :)21:57
wolfspraulwhen m1 is in a darker environment without lab power supply etc. around it21:58
wpwraklet me try another one21:58
wolfspraulalso I think if all are red (rather than some green and some red), it'll look good21:59
wolfspraulfunctionality-wise I'm not worried, it's easy to teach users meanings of a led21:59
wpwraki'd be more concerned with associating LED and connector. e.g., if it's between X and Y, which one does it apply to ? always the one on the left side ? varies ? "see engraving" ?22:01
wolfspraultrue22:01
wolfspraulon that picture, I'd say left side of the connectors might be better22:02
wolfspraul(and I know, it was me who said right side before :-))22:02
GitHub73[migen] sbourdeauducq pushed 2 new commits to newnamer: https://github.com/milkymist/migen/compare/e9be324...d3d5b4822:04
GitHub73[migen/newnamer] namer/trace_back: behave on None code_context - Sebastien Bourdeauducq22:04
GitHub73[migen/newnamer] Include fragment pads in pre-naming dictionary - Sebastien Bourdeauducq22:04
GitHub190[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/y5BnbA22:05
GitHub190[milkymist-ng/master] Use new verilog.convert API - Sebastien Bourdeauducq22:05
wpwrakthe MIDI/DMX side: http://downloads.qi-hardware.com/people/werner/tmp/collage-midi.jpg22:11
GitHub176[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/076c171c7b0aeebd830730842672c9b389a2fa5e22:12
GitHub176[migen/master] Use meaningful class names - Sebastien Bourdeauducq22:12
wpwrakcouldn't sneak the LED under the right side of the DMX TX connector, though that may be possible if the LED is placed first22:12
wolfspraulnow I prefer left side, always left side22:13
wpwrak;-))22:13
wolfspraul:-)22:14
wolfspraulyou ask, I answer22:14
wolfspraulfeel free to ignore :-)22:14
wpwrakafter all, it's copyLeft ;-)22:14
wpwrakone more: http://downloads.qi-hardware.com/people/werner/tmp/collage-dc.jpg22:40
wpwrakether was dark because no cable was inserted22:41
wpwraki put the led under each R/G/B connector, plus once on the left side22:41
wpwrakagain, sometimes it crawled in easily, other times not22:41
wolfspraulhow many are under the video-in? I cannot really see. is there one to the left of the entire connector? or all underneath?22:47
wpwrakone on the left and one under each RCA22:54
wpwrakjust to illustrate the one for each and one for all alternative22:54
wpwrakand before i wrote: one on the left and one under each RCA22:54
wolfspraulah ok. I think under is better22:55
wpwrakactually, perhaps the LEDs should go to the bottom of the PCB. that would avoid all the crazy mechanical stacking22:55
wpwraklet's see what the choices for sideways-facing LEDs are ..22:56
wpwrak(stacking) plus they could be perfectly centered, avoiding ambiguities22:56
wpwrakhmm, LTST-S270KRKT22:58
wpwrakUSD 67.50 for 1000. about 10% more expensive than the top-facing LEDs.22:59
wolfspraulI think the price is OK23:02
wolfspraulthere would still be some on top, like mmc?23:02
wpwrakyes, MMC (if we want one there)23:02
wpwraknot sure if anything else would make sense, though23:02
wolfspraulI'm not sure I do23:02
wolfspraullemme think :-)23:02
wpwrakMMC is kinda poorly supported anyway :)23:03
wolfsprauldon't mention that23:03
wpwraksw, physical access, ...23:03
wolfspraulif Sebastien is in a very good mood one day, I planned to propose a second - or third (?) mmc?23:03
wolfspraul(JUST KIDDING!!! :-))23:03
wolfspraulyeah, for the mmc one I don't have an opinion just now in chat. I would need to think about it.23:04
wolfspraulwe could add one 'just in case', and then if nobody enables it remove in later spins23:04
wpwrakah, i was thinking of a SIMM slots, so that we can have more memory, with whatever characteristics you find on the market (-:C23:04
wolfspraulI don't know, maybe not strong enough logic.23:04
wolfspraulwith that same logic we could add many more, 'just in case'23:04
wolfspraulso maybe not23:05
wolfspraulup to you23:05
wolfspraulon the bottom side is kinda interesting I think23:05
Action: wpwrak looks for a coin23:05
wolfspraulI cannot imagine how that looks like23:05
wolfspraulI am worried about the ESD test failing because of that though23:05
wpwrak(bottom) it would eliminate my two main worries: ambiguous location and complicated mechanical stacking23:06
wpwrakhmm. we already have components at the bottom ...23:06
wolfspraulyes but who knows, more parts, more wires, more vias23:07
wolfspraulin some other school of thought I was hoping we could completely clean out the bottom side23:09
wolfspraulbut that's difficult because of those caps I think that have to be close to the fpga23:09
wolfspraulplus it all works now...23:09
wpwrakone drawback of sideways facing is that, if you want to go for a retina-engraving ultra-bright LED, the price step is larger than with top-facing. ~USD 94 per 1000.23:10
wpwrakthat would be this sort of critter: http://search.digikey.com/us/en/products/APA1606SURCK/754-1054-1-ND/174777123:11
wpwraknote: 0605 footprint. and 250 mcd (instead of 54 mcd)23:11
wolfspraulbut you can still control the brightness?23:11
wpwraksure23:11
wpwrakmaking it darker is easy :)23:12
wolfspraulI don't think a price difference between 5 or 10 cents makes any difference to us23:12
wolfsprauleven if that's 1-2 USD in total, so what23:12
wolfspraulthey are easily removed later23:12
wpwrakwell, at some point, you see the PWM at work when you move quickly :)23:12
wolfspraulbut we add them now and then find out whether they catch on or not23:12
wolfspraulback to the ESD test - with metal sheet, they would be above the metal23:13
wolfspraulwithout metal sheet, using joerg's aluminum X stripe (which we haven't tested yet), they would be kinda outside the safe zone, no?23:13
wolfspraulI don't know how effective the 5mm aluminum 'X' idea is if there are lots of components with vias going to the other side23:14
wpwrak(safe zone) hmm, hard to tell23:15
wpwraki think the idea is that, if you're in an electrostatic field, you want to short out the gradient23:15
wpwrakso it would depend on the shape of your field ...23:16
wpwrakor maybe EM field ... never quite sure which applies in such cases23:17
wpwrakperhaps making sure there's ground around the LEDS would protect them sufficiently. ground would have a reasonably direct connection the the "X", which the takes care of the rest23:18
wolfspraulalright :-)23:18
wolfspraulI am willing to take risks, no worries23:18
wpwraki.e., in my theory, the upset would be caused by a transient passing the board. much like the L3/L9 issue23:18
wpwrakagain, there the problem vanishes if you just short all the places the transient crosses together23:19
wolfspraulabout brightness - if we go for this entire idea I vote for the brighter ones, because I understand they are dimmable anyway, and we can cut down later if we find no use for the light23:20
wolfspraulfor the amount of light23:20
wpwraksounds good to me23:20
wpwrakthey KRKTs I use are okay but a bit less bright than the green ones we have now23:20
wpwrakthat is, at 15% duty cycle23:21
wpwrakthe green ones don't stand a chance if i increase the duty cycle :)23:21
wpwrakah, if we keep the LEDs-for-USB idea, then there would be two more on the top, for ports E and F23:22
wpwrakif we need 18 or less LEDs, then we could do with a 3x3(x2) matrix and increase the LED current from 6 mA to 8 mA23:24
wpwrakif we need 16 or less LEDS, we could go to a 2x4(x2) matrix, leave the current at 6 mA, but increase the duty cycle from ~16% to ~25%23:25
wolfspraulI don't need leds for the internal usb23:26
wolfspraultoo hypothetical23:26
wpwrakgreat23:26
wolfspraulwell that's just my opinion23:27
wpwrakwe can also write some software for a system status display that shows us what all the peripherlas are doing23:27
wolfspraulit's too many steps out for me, can't see them being used23:27
wolfspraulsystem status display?23:27
wpwrakthey have it in any decent sci-fi movie: spaceship takes a beating. then then bring up an image showing a wire model with all the damaged zones conveniently highlighted23:28
wpwrakyou don't have that on PCs because nobody knows where the things are physically located. but in M1, we know _exactly_ where they are :)23:29
wpwrakbtw, that's also my plan B: if we should decide against LEDs, then a status display. of course, that would be much more effective with a built-in panel, so it would be an awkward compromise for M123:30
wolfspraulcannot follow now, too many ifs23:31
wpwrak;-))23:31
wolfspraulleds for ports is an idea I understand, and you see Nate's mail for example, he immediately got it23:32
wpwrakwas the "system status" idea clear ?23:32
wolfspraulsort of, but I feel it's quite indirect23:32
wpwrakyes, that's true23:32
wolfspraulit maybe cool in a movie, but to actually operate a device?23:32
wpwrakLEDs are more immediate23:32
wpwrak;-)23:32
wolfspraulnowadays people want to touch everything23:32
wolfspraulthe question for me is not how many lights we find funny or can stare at for an extended period of time, but which idea we can communicate to users23:33
wpwrakwith M1, it the "ship status" display may work (with an integrated panel), because you a) know exactly where things are, and b) the display also has a well-defined orientation to them23:33
wolfspraulif a led is connected to a port, I can see software making good use of that23:33
wolfspraulso it becomes something the user can easily be trained for, and will like to be trained for23:33
wpwrak:)23:34
wolfspraulyes I think it can easily become very fun to use, with a little logic in software23:35
wolfspraulthat's why I'm hesitating with led for mmc or internal usb - can't really connect to that right now23:36
wolfspraulbut if you want to dismiss the entire idea and stay with the 3 leds we have, also fine by me23:36
wpwrakMMC is a fumbly mess anyway23:36
wolfspraulit's totally off-limits for users23:37
wolfsprauljust internal storage, like a NAND chip23:37
wolfspraulthat's how I see it23:37
wolfsprauland that's why I have a 100% tested and working 2 GB chip in every rc323:37
wpwrakinternal USB ... well, there could be a logic: dark if not in use. always on if it enumerates and we have a driver for it. blink if it doesn't enumerate or we don't know what it does.23:37
wpwraksame as for external USB23:37
wolfspraulbecause I never once want to tell a user how to access that...23:37
wpwrak;-))23:37
wolfspraulfine fine, please feel free23:38
wolfspraulthe led idea is your playground, I trust your judgment23:38
wolfspraulsomething may grow out of it, maybe not on all ports, but maybe on some23:38
wolfspraulit's worth trying!23:38
wolfspraulthat's my opinion23:38
wolfspraulanother thing - I'm just looking at the mmc under jtag-serial, and wondering whether we can move this slightly in R423:41
wolfspraulso that a) the mmc can be fully opened without getting in conflict with the jtag-serial daughterboard and b) the jtag-serial daughterboard doesn't need this little cut-off corner (maybe the newer types already don't need that anymore)23:42
wpwraki'd almost say "any other place would be better" :)23:42
wpwrakjust as long as it stay's out of the hair of the expansion connector :)23:43
wolfspraulyeah but I don't feel like moving things around just like that23:43
wolfspraulmaybe we just leave as-is23:43
wpwrakdo humans with fingers shaped in a way that allows them to open the MMC critter without unconditionally removing the JTAG board exist yet ? ;-)23:44
wpwraklemme conclude the LED collages, for completeness. then i'll think about how to sneak them under the PCB (for demonstration purposes)...23:47
wpwraki think it'll be a lot of work. so perhaps only one side23:47
--- Sat Jan 21 201200:00

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