#milkymist IRC log for Wednesday, 2012-01-18

cladamwakristianpaul, in your edk version, IO_L29P_GCLK3_2 (pin: W12) or IO_L30N_GCLK0_USERCCLK_2 (pin: AB13) are still un-used pins. so if we add these two to be as clk-in/clk-out would be good idea. ;-)02:19
kristianpaulgood !02:21
wpwraki would bring out two, e.g., L40P/L40N (differential pair)02:21
kristianpaulwhat about bufg connectibity check so avoid later conflict02:24
kristianpaulback in some minutes02:24
kristianpaulahh, i'm confusing BUFIO2 with BUFG02:38
kristianpaulhow many clk signal are been used right now in bank2?02:58
cladamwwpwrak, kristianpaul http://downloads.qi-hardware.com/hardware/milkymist_one/sch/tmp/Milkymist%20One%20R4%20-%2020120118.pdf03:07
cladamwtemporarily current sch, see fpga page, the names of each pins of J22, we can rename them later. ;-)03:08
cladamwalthough No L40P/L40N, but just added other few differential pairs.03:09
cladamwwpwrak, kristianpaul I'll run out in 20 minutes, if you both have good idea or different thinkings, or else etc. just let me know, and i can modify them later. ;-)03:11
cladamwthe hot plug pin (pin-16) of the dvi-i connector has not been added. ;-)03:12
cladamwthe L40P/L40N in bank 1 I also added. ;-)03:14
cladamwlet's think more about the arrangements of J22. tks !03:15
cladamwbtw, the 9*2 pins sockets may be hard to source.  the 8*2 pins sockets seems that more easy to source. but I still temporarily added 9*2 pins for J22/J2103:16
wpwrakhow about 10*2 ?03:19
cladamw10*2 i checked , it's seems to be likely as 9*2.03:22
kristianpaulJ22, oh well, wpwrak ? :)03:22
cladamwso 6*2 seems more easy.03:22
kristianpauldvi-i yeah... that will go two bank to as well?03:23
wpwrakmaybe we can reassign HW_VER_3 and then use L29N instead of L30N ?03:23
cladamwbut i've not checked more vendors from webs. so we can determine later.03:23
wpwrakmaking it smaller than 9*2 would further reduce compatibility with rc2/rc303:24
cladamwwpwrak, are you meaning that wanting to use L29P/L29N in bank 2?03:24
wpwraki think having all signals from differential pairs would be nicer than having a mix03:24
cladamwwpwrak, yeah...reduce compatibility. we can still use 9*2 or 10*2.03:25
cladamwokay...but I don't know in s/w sides if easy to make confused to identify r2/r3/r4?03:25
cladamwalthough HW_VER_3 is currently no actually impact to the 8th time version. ;-)03:26
wpwrakwe could use HW_VER_2 as a "switch" than enabled some further HW_VER_n pins. seems that we have quite a few spares on U22D. shouldn't matter in this case that they're in the 2V5 domain03:27
wpwrak(HW_VER_3) yup :)03:27
cladamwhmm....but i got your ideas on all let them differential pairs as must.03:27
wpwrakit's not "must". just "would seem nice" :)03:28
cladamwi don't know if using U22D is good or not. yeah..it's 2.5V03:28
kristianpaulalso hope route nice ;)03:28
cladamwi run out now...03:29
cladamwlater I see backlog.03:29
cladamwyou both can just give me more feedbacks then i change them directly if things are easy to make sure. ;-)03:30
cladamwif not sure , then we ask lekernel . ;-)03:30
kristianpaulpairs indeed04:53
kyakguys, just wondering, why did you decide on lm32 and not microblaze? Are there reasons other than microblaze is not free?05:53
kyakdo you think that having an MMU (in microblaze) is worth it?05:53
kyaklol, russian wikipedia works while the english one doesn't :)05:56
kyakinvestigating it further, there are LEON and OpenCores - both free. So why lm32?06:16
kyaklekernel: the evaluation results seem to be obvious, don't they?06:39
kyakthough it's probably not quite fair to compare MMU and MMU-less configurations...06:41
wolfspra1lkyak: thanks for starting to wrap you head around it. I'm a learner too on those things, please also check the IRC and mailing list backlog if it's easy, sometimes Sebastien is a little tired repeating the same questions many times :-)07:28
wolfspra1lfrom what I understand, one big advantage of lm32 is that it's so small07:29
wolfspra1lMilkymist SoC is not eternally bound to LM32, whether the core (or cores) is LM32 or something else is (theoretically) open07:30
wolfspra1lif you look at size of code, the Milkymist SoC is about 45,000 lines of code, the LM32 core about 8,000, that is 20-20% of the total, and sinking.07:31
wolfspra1lso the key achievement of the Milkymist SoC is not the core, but architecting an entire functioning SoC07:31
kyakwolfspra1l: ok, thanks for information! yeah, the mailing list archive is a good source of information, and i found previous discussions about MMU as well07:53
wolfspra1lfrom the cores you listed, with the little I know I think LEON is the most interesting07:54
wolfspra1lah great, I cannot check wikipedia real quick about microblaze :-)07:55
kyaki tricked the wikipedia by the way07:56
wolfspra1lkyak: but you can be sure that Sebastien and others are aware of and compared all of those you listed (and more), and so far everybody is still happy with the LM32 core07:56
kyakyou noticed that it actually loads the page and then forwards you to this blackout page? i can press "stop" button in your browser at the right moment :)07:56
kyaki mean, you can press07:57
kyakwolfspra1l: don't get me wrong, i'm not even thinking about changing the core :) just trying to get information07:58
wolfspra1loh sure, I understand. everybody who starts to think about Milkymist runs into these questions.07:58
wolfspra1lliterally, *everybody*07:58
wolfspra1l"why don't you use openrisc?"07:58
wolfspra1lI must have been asked dozens of times by now :-)07:59
wolfspra1land that's perfectly fine because someone comes from outside and starts thinking. and I knew about openrisc before I knew about milkymist (and lm32) as well.07:59
cladamw( R4 - 20120118) dvi-i, LEDs in Misc. sch page, new J21 fpga pins arrangments followed by wpwrak ideas using differential pairs. includes clk pairs for like clk-in /or clk-out. http://downloads.qi-hardware.com/hardware/milkymist_one/sch/tmp/Milkymist%20One%20R4%20-%2020120118.pdf08:10
cladamwwolfspra1l, I'll copy usb sch for intenal board in hour maybe.08:13
cladamwthere's still some details like will be openly discuss later after I send email to list:08:14
cladamw1) specify how consumption for U-Shape daughter board08:15
cladamw2) if need to add current limit protection for U-Shape08:16
cladamw3) if need to add varistors for U-Shape fpga pins and decoupling cap. on M1 instead of daughter board design on user-side.08:18
cladamw4) if using dvi-i hot plug detect08:19
cladamwwolfspra1l, above I think let's to be as discussions after email, how do you think?08:20
wpwrak2) hmm, what happens if we short 3V3 to GND ?08:20
cladamwwpwrak, wow...you still here. ;-)08:20
wpwrak3) i'd keep things simple :) an extension board should be considered an "internal" device. at some point, you just have to be careful08:21
wolfspra1lhot-plugging is not needed imho08:22
cladamwwpwrak, upon you just said then the question now will be then we must to add protection. ;-)08:22
wpwrakfor 3), something we could perhaps consider is a jumper for the 5V supply on J21. that way, one can keep away the "dangerous" 5V (and avoid frying the FPGA's clamping diodes by accident)08:22
wolfspra1lbut if it's easy, sure why not. maybe useful at some point in the future.08:22
wolfspra1lI trust werner in making some good balanced proposals there.08:23
Fallenoukyak: the choice of the cpu is described in lekernel masters thesis08:23
wpwrak("upon ....") hmm, can't parse that :) what do you mean ?08:23
Fallenouit compares leon/lm32 and others08:23
Fallenouand why he chosed lm3208:23
wpwraki don't know DVI hot-plug yet. is this something you need to be able to connect DVI while M1 is running ? or something more exotic ?08:24
wpwrakcladamw: (still here_ i actually slept for a few hours :)08:25
cladamw(DVI hot-plug) I've not found very clear specified details on actions while hot-plug.08:25
wpwrakhmm :)08:26
wpwrakwhat does it mean on the hardware side ?08:26
kyakFallenou: ok, thanks.. i'll read it08:26
cladamwso this(hot-plug) is opening now... I tried to search from webs. not fully understood its behaviour now.08:26
cladamwwpwrak, the current all LEDs I used pins in bank 3 (i.e. 2.5V) and active low from driving by 2.5V.08:31
FallenouI can't find anymore lekernel thesis on the wiki or milkymist website, I don't know where it is hosted biw08:32
cladamwsince some un-used pins in bank2 I'll use them as another two internal usb ports supported.08:32
wolfspra1lFallenou: kyak let's see. this is the 6-page intro I know http://www.milkymist.org/socdoc/paper_overview.pdf08:38
wolfspra1la bunch of other docs in there08:39
wolfspra1lbut where's the thesis...?08:39
Fallenoukyak: fyi there is aemb as well which is a free clone of microblaze08:40
Fallenouwolfspra1l: don't know, and it's a really really good paper, too bad it's not linked on the website !08:40
FallenouI must have it on my laptop somwhere08:40
wolfspra1lhere http://milkymist.org/thesis/thesis.pdf08:40
Fallenouoh ! great thanks08:40
wolfspra1lwell we start linking now :-)08:40
cladamw(dvi hot plug detect) to know its meanings on hardware side, I think here can be found. but cant be downloaded. :(08:43
cladamwI think had better to fully understand it first. and no get surprises later when R4 came out. ;-).08:45
wolfspra1lthis is a source for the links I already posted http://milkymist.org/mmsoc.html08:46
cladamwyou meant the dvi_10.pdf link? I can't download it. maybe I try after re-turn on web brower.08:48
wolfspra1lworks for me, 1.3 megabyte file08:52
wolfspra1lI can email you but you should be able to download it08:52
cladamwwolfspra1l, received, tks!08:54
cladamwwolfspra1l, http://images.bit-tech.net/news_images/2008/10/gigabyte-shows-bit-tech-its-final-x58s/Gigabyte-X58-UD5P.jpg09:04
cladamwyou mentioned this with Werner, so is that usb shrouded socket for use? right?09:06
wolfspra1lwe don't want that09:09
wolfspra1lI just posted it for comparison09:09
wolfspra1lI think we still want the totally old-school 100mil 2*5 male header09:09
wolfspra1lbut let's see. which one do you like better?09:09
cladamwi'd like shrouded one but problem is not this. Problem is the user or we can easiler to get usb cable to connect to M1 firstly. then see how much it will be or popular in markets.09:11
cladamwbut it's okay that i go for drawing 2*5 firstly. ;-)09:12
wpwraki think what we want the most is keyed. shrouded would be a further feature.09:12
wpwrakkeyed = pin 9 is cut/removed. you can also do this with a wire cutter. takes something like half a second :)09:13
cladamwyeah...the shrouded can against user to connect reversely.09:14
wpwrakso do keyed connectors :)09:14
cladamwwpwrak, sorry , don't understood. pin 9?09:14
wpwrakand the shrouds sometimes can get in the way09:14
wpwrakif you look at the shrouded connector carefully, you'll see there's a black hole where one of the pins should be09:15
wpwrakthis is because the pin is not equipped. the matching connector has plastic at that position. so it's also protected against reversing (but not against shifting)09:16
wpwrakand of course, if you connect a single cable with a 4x1 connector, you have no protection at all09:17
cladamwaha...understood now. tks ! pin 9 is not wquipped there. ;-)09:17
kyakFallenou: (aemb) - interesting!09:20
cladamwlekernel_, i'd like move HW_VER0~3 pins from bank2 to bank3, will this influence codes management a lot?12:31
wpwrakif we already use them, then we shouldn't move all of them. if we don't use them yet, we could move the whole gang to some previously unused pins12:32
cladamwi already can imagine added usb c/d/e/f ports parallel routes needs that area. ;-)12:35
cladamwwpwrak, do you mean that this intended 'moves' will influencely unbelivable tasks in codes managements?12:37
wpwrakwell, it all depends on whether we already use those pins. if yes, we need some algorithm that still produces correct results12:39
wpwrakbut yes, maybe you can move them all. e.g., if HW_NEW_x = { 0, Z, Z, ... }   -> use old HW_VER_y12:39
wpwrakassuming HW_NEW_x is unconnected in rc2, rc312:40
wpwrakit would mean that software written for rc2/rc3 may get the version wrong on rc4 or later, but i wouldn't see this as a bit issue. i mean, who would try to run the 2010-07 binary on, say, M1r4 ? :)12:41
cladamwhmm...since those four pins are to recognize Rn, so seems that I'd better not to move them after your explanations.12:42
wpwraka new firmware could just tests the new ones first. then ignore the old ones if the new ones are not all Z.12:43
wpwrakor you could have a mixed approach. keep some, move others.12:43
cladamwlikes you suggested me like HW_VER_3 from L29N to L30N once let HW_VER_2 be as a 'switch' to check?12:46
wpwrakyes, that's one possibility. but now that i've been thinking a bit about it, there may be easier solutions. even moving everything, as you suggested, may be okay.12:49
cladamwsince we've not been reached (0x04, HW_VER_3:0)?12:49
wpwrakyup. that was my reasoning :)12:49
wpwrakactually no, the limit would be 0x02 :)12:50
wpwrakif we use HW_VER_2 as a switch, the logic would be like this12:50
cladamwso then under this conditions, f/w will just added very few tasks, right?12:50
wpwrakversion = HW_VER_[0...2];12:50
cladamwoah. i see12:51
wpwrakif (version >= 0x2) version |= HW_NEW_[0...whatever] * 4;12:51
cladamwi tried to move HW_VER_3 is because to get differential pairs, okay.12:52
wpwrakdifferential seems to get more and more popular, so i think it's good if we have as many of them as possible12:53
lekernel_cladamw: _any_ pin change breaks bitstream compatibilityt12:53
cladamwwell...now I know your algorithm. ;-) so at best I shouldn't move them then reducing user to read sch though. phew~12:53
lekernel_moving only HW_VER_3, or removing it entirely, is OK12:54
lekernel_because we're not using it atm12:54
cladamwwow~ break bitstream compatibility. get worse not only f/w. :(12:54
cladamwaha...okay...great answers for me. this may be an important option if house want me to move. then I'd best to move them entirely to bank3 then.12:56
wpwrakwell, if you use them as anything but GPIOs, you'll have a custom bistream anyway12:57
wpwrakso you can just add a few switches, if compatibility matters at all in the respective use case12:57
lekernel_cladamw: you have a problem with HW_VER_3 alone, right?12:58
cladamwi currently just 'moved' HW_VER_3 pin ONLY, all others are just added. ;-)12:58
wpwraklekernel_: do we do anything with the hw version pins at the moment, besides printing their values ?12:59
cladamwlekernel_, yes, currently i think this pin only. but as your words above, I'll directly change myself if 'entirely' move them to bank3 when I cowork with house later.12:59
cladamwbut I just need to know the worse case I must have to know.13:00
lekernel_wpwrak: no13:01
wpwrakcladamw: okay, so we could even (re)move all of them without major loss of functionality, if really necessary13:02
wpwraklots of choices ;-)13:03
lekernel_yes, but what happens if the new bitstream tries to use them?13:06
cladamwalright, as long as house tell me for routing usb c~f ports, they indeedly want to move HW_VER_x resistors/fpga pins, then I know the best place now is bank3. (i.e. nearby C73 )13:07
lekernel_c~f ?13:08
wpwraklekernel_: then it/the sw should first check the hw revision, and only then enable the new feature13:08
lekernel_wpwrak: you can't change I/O standards dynamically13:08
wpwraklekernel_: and the bitsteam may well be something customized. e.g., kristianpaul's GPS critter13:09
cladamwlekernel_, i currently named extra usb ports as C/D...etc.13:09
wpwrakhmm, but the worst case would be that you drive the existing pins with something that doesn't make sense13:09
lekernel_cladamw: so we have 6 USB ports?!?13:09
lekernel_wpwrak: yes, and no problem with the 1K resistors?13:10
wpwrak(changing I/O standard) taht's actually a bit suckish. e.g., if we had multiple modules, using different I/O standards. ah well, something to worry about when it happens, i guess13:10
cladamwlekernel_, yes, firstly added 6 USB ports, if house tell me a strong said "NO", then I give up. ;-) And down to 4 ports.13:10
lekernel_wpwrak: you can change it at bitstream build time, or experimentally with partial reconfiguration - but I don't feel like working on the second option13:11
lekernel_especially since it has an appreciable Murphy potential13:11
lekernel_6 USB ports is too many13:11
wpwraklekernel_: the only problem would be if the bitstream uses things as input and gets hopelessly confused about the levels it find, crashing the whole system. i think the correct answer to this is "don't do that" ;-)13:11
lekernel_4 is already on the 'high count' side. 3 is the maximum for the regular use case 'midi+keyboard+mouse'13:12
wpwraklekernel_: 6 USB = 4 external + 2 internal13:12
lekernel_use the expansion connector for all internal stuff13:12
lekernel_that's what it's for13:12
wpwraklekernel_: it's unlikely that all will be populated13:12
lekernel_no need to mess with additional USB transceivers13:13
wpwraknaw, internal could be RF keyboard -> you'd want this in parallel to any extension boards13:13
lekernel_there aren't any extension boards13:13
wpwraki mean once someone makes a board :)13:13
lekernel_cladamw: what do you need the HW_VER pins for?13:14
wpwraki don't think we want to see, say, GPS boards that also have a USB pass-through connector :)13:14
lekernel_no no13:15
lekernel_4 USB is already a lot13:15
cladamwlekernel_, i see the routes for USB C/D ports will use current those four H/W control resistors. so I ask if I can move HW_VER with less codes managments.13:16
lekernel_cladamw: alright13:18
lekernel_cladamw: so far we're using only HW_VER_0 and HW_VER_1, right?13:18
wpwrak4 USB in total is probably quite sufficient. but since we can't turn internal into external or vice versa (well, unless we get into jumper games), we may have cases with all 4 external ones populated (and no internal) or 1-2 external plus 1-2 internal13:18
cladamwlekernel_, yes. from R1 ~ R3 now, we only used HW_VER_0~113:19
lekernel_cladamw: then move all HW_VER_* pins to currently unused pins possibly on another bank, and connect stuff to the current HW_VER_0,1 pins that go in the FPGA->USB direction13:20
lekernel_and hopefully which is driven high most of the time, so we do not dissipate power for nothing in the resistors that might already be there13:20
cladamwlekernel_ wpwrak , good. so now I can move all HW_VER_* pins to bank3 and make note to request move four resistors to other area. tks !13:25
lekernel_cladamw: also connect FPGA _outputs_ to HW_VER0,113:26
lekernel_and possibly those driven high most of the time... what about the power switches for example? (I don't remember if we used the active-high or active-low version?)13:27
lekernel_hmm active-low, no?13:27
cladamwnow, active-low for usb power switch.13:28
lekernel_so I quite don't know what to connect to HW_VER0,113:28
lekernel_cladamw: connect SPD of USB C/D. then we can easily modify the code to set SPD high when no peripheral is detected.13:29
cladamwseems the best routes on pins of HW_VER0~2 can be used for extra USB ports. And I don't want the routes to cross like dram and flash routes, that's why i asked to if move HW_VER_* pins away.13:30
lekernel_cladamw: summary: use the current locations for HW_VER0,1 for SPD of USB C/D, and then move HW_VER_* wherever you want13:31
lekernel_cladamw: or better - OE#. no code change then13:31
cladamwlekernel_, ha... great hint on SPD of USB C/D. or OE#.13:32
lekernel_scratch SPD13:32
lekernel_we use OE#13:32
lekernel_OE# is always high (transceiver in receive mode) when no USB device is detected - so there will be no current through the resistors to 3.3V which are there on R2/R3 boards13:33
cladamw(OE#) good. okay13:34
lekernel_and we use the same bitstream on all boards. only it'll display "pre-R4" on R2/R3 boards ...13:34
wpwrak(what to do with old HW_VER_{0,1}) maybe we could connect LEDs. they would be active-low13:37
cladamwanother task: for 14 * LEDs near to each connector. I currently used also bank3 (i.e. 2.5V for all common anode to LEDs), i'd like to act all LEDs in active-low, is that okay to you?13:38
lekernel_wpwrak: I thought those pins were needed for USB? not LEDs...13:38
lekernel_cladamw: it doesn't matter if LEDs are active low or high13:38
wpwraklekernel_: the only pin we really want is HW_VER_3, for the expansion header13:38
lekernel_wpwrak: adam said USB?13:39
Fallenouis it not difficult to respect usb timings at the moment with navre with only 2 usb ports ? I guess it will be even more difficult with 4 ports isn't it ?13:39
wpwraklekernel_: Ron(L) is often a little lower than Ron(H). also, Imax(GND) is often higher than Imax(VDD). so active-low is a safe choice13:39
lekernel_cladamw: to be consistent with the existing LEDs, make them active high13:39
wpwraklekernel_: (usb)we're talking about many things in parallel ;-)13:40
lekernel_wpwrak: the FPGA has a tunable drive strength whose maximum is superior to the LED current, so it really doesn't matter13:40
lekernel_it's not regular CMOS I/Os13:40
wpwrakFallenou: the whole USB subsystem needs a massive overhaul anyway. it's tricky because the host CPU is so slow, but we'd still want more flexibility13:41
lekernel_cladamw: if you only want HW_VER_3, then simply remove that pin altogether13:41
wpwraklekernel_: how about per-bank or per-device Imax ?13:41
cladamwlekernel_, okay, I'll change all added LEDs to be active high with 2.5V in bank3.13:42
lekernel_wpwrak: if you have many LEDs you should check the datasheet... but iirc it's not specified to depend on current direction13:42
lekernel_cladamw: I'd rather not touch bank3, because that's where the quite timing sensitive SDRAM is13:44
lekernel_cladamw: I'd skip adding the LEDs altogether13:44
lekernel_cladamw: and if you can only remove HW_VER_3 instead of moving HW_VER_*, it's much better13:45
wpwraklekernel_: do you foresee needing more 2.5 V pins in the future ?13:45
lekernel_wpwrak: no13:45
lekernel_I told you the only big thing I foresee for Milkymist is a major performance improvement and minority report style UI :)13:46
lekernel_this won't happen on M113:46
wpwrakokay :)13:46
lekernel_though it's a nice platform for prototyping things like migen13:46
wpwrakone step after the other :)13:46
lekernel_or render algos13:47
wpwraksee, it has its uses ;-)13:47
cladamwMoving ONLY HW_VER_3 instead of moving all HW_VER_* is that I don't know yet. But now I know this rule now. ;-)13:47
lekernel_cladamw: I said remove, not move13:47
lekernel_you simply delete HW_VER_313:48
wpwrakif we envision needing versions > 7, then you could also allocate a new pin. and make that the new HW_VER_3. even easier than the algorithm i described before13:49
wpwraka pin that's NC in rc2rc313:50
lekernelchances are either version 8 will not happen or we'll have moved those pins again before then13:50
lekerneland yes13:50
cladamwlekernel, oah...sorry that I confused. yeah...I remove HW_VER_3 to different pin now. But I'll eventually know result if entirely moving all to bank3 when after coworking with house.13:50
cladamwRegarding to not touch bank 3 about SDRAM, I'll reallocate LEDs to un-used pins on other banks. phew~ now I'd leave these LEDs to be the last. :)13:54
wpwrakyeah, version 8 seems a very long way out. too long for expecting nothing major will have to change.13:54
lekerneland yes, as wpwrak pointed out, there are per-bank current and dissipation limits13:55
wolfspraulwow there's a lot of things mixed14:19
wolfspraulusb, hwver, leds, m214:19
wolfspraulis it all settled now?14:19
wolfspraulif we are moving hwver pins, I agree it is not necessary that older firmwares can detect newer board revisions14:20
wolfspraulso if we can overlap them with other pins in smart ways - go for it14:21
wolfspraulas long as the revisioning still works, that is our latest firmware can detect and run on all hw revisions14:21
wolfspraullekernel: about the major speed improvements - can you tell us what you think might get us there?14:24
wolfspraulbecause even if something will not happen in an m1 revision, we should try to prepare m1 for maximum reusability towards m214:24
lekernelmore memory bandwidth, better memory architecture, ddr3, more graphics acceleration (like several TMU's), faster FPGA14:25
lekernelhaving an ASIC CPU, too, as far as software alone is concerned14:27
wolfspraulyou mean combine the fpga with an asic cpu, or those new fpga+asic combo chips?14:29
wolfspraulhe, that's what I hear for 2 years from others, but so far you always dismissed it :-)14:30
lekernelI don't know. it depends if we actually need fast execution of pure software to make a popular product or not.14:32
wolfspraulthere's a lot of value in a cheap high-performance chip14:32
lekernelwe don't need that for FN, but FN is a commercial failure14:32
wpwraki think also FN could benefit from a faster CPU14:33
wpwrakand i think it's way too early to call FN a failure. we haven't even really started yet :)14:33
wolfspraulsure, totally not a failure.14:33
wolfspraulit's not driven by marketing needs, but that was the case since day 114:34
wolfspraulbut thinking about a high-performance asic cpu is definitely good14:34
wolfspraulin fact I did that all along, because I was told often enough that that's completely wrong with Milkymist/M114:35
wolfsprauland until today I only heard sebastien dismissing asic cpus, but now seems not :-)14:35
lekernelit's not wrong, it's just relatively slower14:35
lekernelbut then they're proprietary, we depend on a single supplier, we are subject to part obsolescence14:35
lekernelthey increase board cost14:35
lekernelthey have tons of disadvantages14:36
lekernelI won't consider this option unless we do need fast execution of pure software14:36
wolfspraulyes, I personally think the all-fpga approach is right, especially if we include our own capability later to tape-out chips14:36
wolfspraulwithout which I would never think for 1 minute that any fpga activity can be commercially viable14:36
wolfspraulon the other hand we need to acknowledge just *HOW MUCH* value there is in a high-performance low-cost chip14:37
wolfspraulit's scary14:37
wolfspraulso Milkymist SoC has an uphill battle against that value14:37
wolfspraulI don't currently think we need an asic cpu, or those fpga-arm combo chips14:38
wolfspraulthey won't make a big difference in improving the product14:38
lekernelnew memory architecture + faster fpga + migen-flow will likely outperform those chips if there are hw-accelerable tasks14:39
wolfspraulinstead, they would be a multi-year distraction that simply you won't find anybody investing for14:39
wolfspraulmy current thinking (and I am really trying to listen, because everybody else seems to know more) is that we are on the right path with the fpga-only solution14:39
wolfsprauland migen, and llhdl14:39
wolfspraulddr3, artix or other fpgas14:39
wolfspraulfind 10 million USD investment14:39
wolfspraulthat path14:39
wolfspraulcrank up M1 and support the m1 users14:40
wolfsprauldo not tell our m1 userbase that they are a 'failure' :-)14:40
wpwraki sometimes notice small delays that look like the CPU falling behind. they're not a problem now. but systems always grow more complex, never simpler, so ... :)14:40
wolfspraulyes, same. I see those delays too.14:40
wolfspraulI think our strategy (for the long-term, any serious investor) must include fabbing.14:41
wolfsprauland that's why the arm-fpga combos or combining with asics is a costly detour, not much more14:41
wolfsprauland I personally don't even believe that detour will increase sales, it's just a desperate catch-up move that will not work (fail to catch up)14:41
wolfspraulbut keep thinking...14:41
lekernelyes, definitely not in the current state14:42
wolfspraulI think our path is correct14:42
lekernelbut I do not have a clear picture of what would make a popular Milkymist product, so I cannot think yet about precise technical choices14:42
wolfspraulbut it must include tape-out of non-fpga chips later, whcih is something we always had in mind, when making technology decisions14:42
wolfspraullekernel: yes, I understand and feel the same14:43
wolfspraulso for the time being we have to be patient and invest in the base until we have something that truly can scale14:43
wolfsprauland then we need to be in a position technically that we can in fact scale14:43
wolfsprauland with 'scale' I mean making a product in 10k, 100k or more units14:43
wolfsprauland you will not pay 100k*40 = 4 million USD to Xilinx14:43
lekernelnaw, FPGAs are cheaper in such volumes14:44
lekernelbut anyway, I see your point14:44
wolfspraulsure, but my point is that you need to decide first which IP value you believe in14:44
wolfsprauleither the Milkymist SoC as such is valuable or not14:44
wolfspraulso when you scale, you know which part you want to invest in, and which part you want to outsource14:45
wolfspraulyou better be very clear about that14:45
lekerneloh, it certainly is. at least in a few big science labs *g*14:45
wolfspraulwhat I have heard several times is people saying we should outsource the CPU to an existing asic14:45
wolfsprauland move only 'special' tasks into the fpga14:46
wolfspraullike most everybody else does14:46
lekernelbut regarding the open source community (again I'm talking about the people who are _not_ here) or making a popular product... er...14:46
wolfsprauldon't be too impatient14:46
wolfspraulMilkymist is really treated very fairly14:46
wolfspraulif you can zoom out your mind and look at it from the distance, you will see what a stretch it is to ask someone to be excited and jump in today14:47
wolfspraulit's really exotic stuff, really really exotic. Maybe just some geeky nonsense that will go away when the geeks get kids.14:47
wolfspraul9x% of people will see it like that without a chance to get them to think more.14:47
wolfspraulI cannot complain or ask for more, just need to slowly make the Milkymist case stronger.14:48
wolfspraulabout those upcoming wave of fpga-asic combo chips, it will be very interesting to see how many products start using them, and their pricepoint14:49
wolfspraulif some really take off, we shouldn't be too proud to accept that it is better to bite into a large part of proprietary IP, if we cannot get the free IP (running in pure FPGA fabric) to do any good, even by our own measurement14:50
wolfspraulthat's a problem though, it will essentially devalue to an expensive overhyped devel board14:50
wolfsprauldevalue M1 to...14:50
wolfspraulwe see :-)14:50
wpwraki think the cave owners must have felt pretty much the same when some early humans started to build houses ;-)14:52
wolfsprauldon't get it :-)14:52
wpwrak"damn, if this catches on, it'll devalue our caves" :)14:52
wolfspraulit's all just products14:53
wolfspraulthe fpga-arm combo chips are at least 1 year out I think14:53
wolfsprauland there has been a wave/hype for such chips about 10 years ago, which faded out a few years later14:53
wolfspraulso we have to see how volume and pricepoint develop, whether this combination does make sense economically or not14:53
lekernelyeah, altera even no longer manufactures their first ARM/FPGA chip afaik14:54
wolfspraulthere's absolutely no need for us to accelerate adoption of such chips today, for the same reason that we have no strong forecasts either way14:54
wpwrakmaybe it's just a recurring fad. like video telephony. (well, at least that exists to some extent now.)14:54
wolfspraulyeah, and now they try again, why not14:54
wolfspraulthis time they want to make them look like arm, boot like arm and all, and have the fpga fabric around for 'acceleration'14:55
wolfspraulI think it's good that they try14:55
wpwrakand then xi-lin.cn will make a super low-cost MIPS plus FPGA ? :-)14:56
wolfspraulwhat I believe in for the future of Milkymist right now I listed above: migen, ddr3, artix/other latest-gen fpgas, include tape-out/asic in our forecast and business plan14:57
wolfspraulno need for the new combo chips or putting a separate asic cpu next to an fpga14:57
wolfspraulthose paths look messy to me, I don't understand where the valuable IP is, so wouldn't know how to invest or how to tell an investment story to a 3rd party14:58
wolfspraulbut if those paths lead to better products in shorter time-to-market, we may have to compromise14:58
lekernelyup. it's an option to keep if we can't have enough investment for an ASIC, and if we are strongly convinced that having fast traditional software capability will make the product successful.14:58
wolfspraulyou have to decide first what you believe someone should invest into14:59
wpwraki see this as a more viable path mid-term than making our own chips14:59
wolfspraulif you tell an investor you are not sure, that won't work14:59
wolfspraulwpwrak: you mean we should try fpga-arm combo chips or putting a separate asic cpu on m1/m2 ?14:59
lekernelwpwrak: but on the long term, it increases a lot the work to make those chips14:59
wpwrakit's not as if you'd just have to call up the guys in the asic building on the qi-hw campus ;-)14:59
lekernelyou could probably put the current MM SoC design in a few months if you had the money15:00
lekernelsoftware compatible and everything15:00
wolfspraulfrom what I've learnt so far asic is easy, relatively easy15:00
wolfspraulgive me 1 million USD and I am pretty sure I can pull it off15:00
wpwrakwolfspraul: dunno what's better. would depend on how well they're integrated, etc. in general, integration should help. but depends on what they have to offer and how deep this would get us into proprietary land15:00
wolfsprauleven less, but the point is that I don't see any 'impossible' barriers right now15:00
lekernelwpwrak: then you'd have to either buy licenses from ARM or switch back to LM3215:01
wolfsprauland I do believe the Milkymist SoC as a tape-out candidate gets stronger every month15:01
lekernelwith the risks of doing errors, in both cases15:01
wolfspraulI think the all-fpga approach right now, even if a bit radical, will open the doors to the best integration and optimization for future products, for ourselves and others15:02
wpwraklekernel: i would be more worried about the fpga-to-cpu "glue". wouldn't be nice to have to use deeply proprietary IP blocks for that15:02
wolfspraulthe fpga-arm combo guys will not integrate any interesting chips either, there are too many things you can do with electronics and they cannot make a swiss-army-knife chip15:02
wpwraklekernel: i.e., it would undermine your llhdl work15:02
wolfspraulI remember senior HP people telling me years ago how worried they are about the whole 'feature guessing game'15:03
wolfspraulsorry TI15:03
wpwrakit's their job ;-)15:03
wolfspraulyeah but they may not feel comfortable that a decision about which feature the market wants x years later is something they can be good at15:03
wolfspraulmaybe ask the fortune teller on the way to the office?15:03
wolfsprauldo you really want to bet a large sum on that?15:04
wolfspraulthe fpga-arm guys will have terrible trouble deciding which features to include in their chips and which to keep out15:04
FallenouIf there is a free verilog 32-bits MIPS clone with good (better than lm32) performance and not too much LUT (fpga occupation) would it be candidate to replace LM32 ?15:05
wolfspraulfor one MIPS is a patent minefield15:06
wolfsprauljust saying15:06
Fallenoubut not MIPS, just a few instructions15:06
wolfspraulat the very least you would *never* want to say MIPS anywhere15:06
Fallenounon-aligned store/load15:06
Fallenouwould be called MINM ? MINM Is Not a MIPS :)15:07
lekernelI can't see much point in switching to MIPS from LM3215:08
wolfspraulso why can't we upgrade m1 to ddr3+artix ? that looks like the way to go. we should make one small increment after another, without giving up control in any of the key technologies that define our destiny (which in our case is open because it's open tech :-))15:08
wolfspraulnot upgrade now, maybe call it m2, but that's the cheapest and most immediate path I see right now15:08
Fallenoujust if it has better performances15:08
wolfsprauland carry forward as much as possible from what we have now15:08
lekernelit won't15:08
Fallenouthe point would be a better toolchain and easier linux support15:08
lekernelat least not by more than 10%15:08
lekernelthe lack of linux support is a mere consequence of the M1 unpopularity. people are _rushing_ to port their stuff to more successful projects like rpi ...15:10
wolfspraulbut yeah, the cpu in m1 needs to get faster ;-)15:10
lekerneldoes it? I'm not sure.15:10
wolfspraulseems that sentiment comes up once in a while15:10
wolfspraulwell I don't want to add confusion, I love our priorities. migen, memory controller, all that.15:11
Action: Fallenou just talking about mips because of his recent experiments in making a mips core, too early to tell how good performances will be, it will end up as a toy or a lawsuite I guess15:12
wolfspraulI am loaded with work that I feel very good about, so I don't need a faster CPU now.15:12
lekernelFallenou: why don't you design a LM32 MMU instead?15:12
wolfspraulwhy don't you join m1 full power? :-) lots of great tasks there to help with our big goals.15:12
lekernelyes :)15:12
lekerneldon't reinvent the wheel, we already got this part right15:12
Fallenoulekernel: well maybe afterward, I am doing the mips core to learn about cpu design and verilog and so on, maybe after this is done or more advanced I will switch to something else :)15:13
wolfspraulcome on switch now! you are already part of this community15:13
wpwraklekernel: btw, have you seen this ? http://www.freesoftwaremagazine.com/articles/allwinner_a10_gplcompliant_computer_1515:13
wpwraklekernel: rpi will have its problems, too ;-)15:13
lekerneldesigning a LM32 MMU is both useful per se and will make you learn CPU design just as well15:13
wolfspraulyeah, some people now say the raspberry pi is not cheap enough! :-)15:13
wolfspraullet them talk15:14
wpwrak"thank you for starting the race to the bottom. now, let's accelerate" ;-))15:14
wolfspraulit is a fact that m1 is expensive, we should be humble about that.15:14
Fallenouwell the benefit is that after a month working on my mips core I now understand when I read lm32 source code15:14
lekerneldoesn't seem like they have much of a problem so far15:14
Fallenouso if I want to add an MMU to lm32 I would need to understand lm32 source code :)15:14
wolfsprauland the way to get it cheap is to radically invest and integrate, including tape-out and bypassing the fpga tax.15:14
FallenouSo I guess my start with this project is not that wrong15:15
wolfspraulFallenou: jump jump!15:15
Fallenoubut I get your point15:15
wolfsprauljump into the cold water, join m1 now15:15
wolfspraulyou even talked about it what, 1 year ago now? :-)15:15
wolfspraulI mean you gave a presentation15:15
wolfspraulwe need you15:15
Fallenouyep in London on april15:15
wolfspraulmaybe one day you will enjoy talking about our death15:15
Fallenouahah no I really like this project15:16
Fallenoudon't want it to die :)15:16
wolfspraulthen join15:16
wolfspraulhelp contribute back15:16
FallenouI read every conversation here even if I don't write15:16
wolfspraulevery little thing helps and matters15:16
wolfspraulbetter documentation15:16
wpwraklekernel: (no problem so far) yeah, that's what the Neanderthals must have thought about those little groups of skinny homo sapiens, too ;-)15:16
Fallenouwolfspraul: if I feel like I have the time/skill for a contribution I will not hesitate one second15:16
wolfspraulsounds like an excuse :-)15:17
FallenouI feel really much moreconfident now about verilog/fpga dev15:17
wolfspraulnobody could be less qualified than I am15:17
Fallenouso maybe I will start mmu project :)15:17
lekernelFallenou: so, you have time to reinvent the softcore CPU wheel, but not design a MMU?15:17
wolfspraulso what the heck do I do here?15:17
Fallenoulekernel: well for example I knew where to start for the cpu, for the MMU I didn't know15:17
lekernelthen ask15:17
Fallenounow I know a little bit better, but need to document more as well15:17
wolfspraulFallenou: seriously, let me tell you this. By joining m1 now, and contributing now, no matter how immature you think your knowledge is, you help the project the most.15:18
Fallenouand anyway I reall wanted to understand better cpu design for me, I did it to understand better, don't make me feel guilty of working on things to improve my skills ;)15:18
Fallenouwolfspraul: I know i know15:19
lekernelbut designing that MMU _will_ improve your skills15:19
wolfspraulthat's because you will ask the typical type of newbie questions that will pave the way for so many other newbies to follow you15:19
FallenouI started by what I feeled would be a nice start15:19
Fallenoumaybe I was wrong15:19
lekernelbesides, you will get the right to ask me questions about it. but those regarding MIPS design I won't answer.15:19
Fallenounotice I didn't asked one yet :p15:20
Fallenoubut ok, I will seriously think about it15:20
Fallenouprepare for some questions :)15:21
FallenouMMU will surely help having a nice Linux up and running, but for FN, what's the benefit ?15:45
wpwrakmaybe FN2 will run under linux, enjoying all the drivers you can find there ? :)15:46
Fallenouoh ok :)15:46
larscall the drivers?15:46
wpwrakwell, allowing some poetic liberty :)15:48
larschttp://e.static.memegenerator.net/cache/instances/400x/12/13039/13351966.jpg ;)15:57
wolfspraulhey not bad16:09
kristianpaullarsc: drivers days? :)16:40
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01182012-1556/16:43
larsckristianpaul: wpwrak wants to enjoy all the drivers16:51
wolfspraullekernel: are you aware of anything specific you do right now in the Milkymist SoC that makes fabbing them later difficult?17:51
wolfspraul(just asking out of curiosity so we are clear, not that I plan something along that soon)17:51
wpwrak(meme generator) ah, now i get it ! first, i thought someone had actually drawn that thing before, for some perplexingly unfathomable reason ;-)17:53
lekernelno, everything is pretty much portable18:00
lekernelexcept things like DDR I/O and clock generators18:00
lekernelbut Synopsys is always happy to sell layouts for these things18:01
lekernel(those are generally designed at the transistor level, i.e. no Verilog)18:01
wolfspraulok, good! we should keep that perspective open and well documented18:35
wolfspraulI think the only reason to justify the existance of a product-quality free Milkymist SoC is if you at least have fabbing in your roadmap/future plans18:35
wolfspraulif we exclude that for good, it would be better to get an ASIC CPU and focus our energy on those parts we really believe in18:37
wolfspraulbut I think we should keep that open, definitely18:37
Fallenouhow many products manufactured is it worth it to spend a lot of money in an ASIC ?18:44
Fallenouwhen does it become profitable ? asic cost vs fpga cost18:44
wolfspraulI think that's very difficult to answer because the two technologies are so different18:46
wolfspraulin some cases the reprogrammability of an fpga may be a feature you really want on some product18:46
wolfspraulespecially if you imagine that things like reconfigurability become really easy and useful18:47
wolfspraulthen there are options on the side of the fpga vendors, for example Xilinx and Lattice supposedly have programs that allow you to buy chips at 50-80% discounts, where those chips are guaranteed only to work with a specific bitstream that you give them in advance18:47
wolfspraulAltera had or has something called HardCopy18:47
wolfspraulthen there are structured ASIC vendors, basically piles of proprietary tools and technologies to reduce the need for custom masks18:48
wolfspraulon the ASIC side, there are huge differences between making something in a 500um process, or a 90nm, or a 28nm process18:48
wolfsprauland so on18:48
wolfsprauleach of those paths has different economical dynamics18:48
wolfspraulI believe the ability to integrate and optimize is what makes a great product, so we need to keep those parts open (that is, under our control) that are relevant towards that goal.18:50
wolfspraulas a rule of thumb, in China they say "do asic above 10k units"18:51
wolfspraulbut that's a very very rough rule of thumb, and like this only really applies to china where IP is always just simplified to 0 cost, because you can just steal it if you like18:51
wolfspraulbut if we do the math for milkymist one, for example, the 10k number prooves to be not too far off18:52
wolfspraul10k slx45 chips at 40 USD = 400,000 USD18:52
wolfspraulat 10k you can expect bigger discounts, don't ask me how much18:52
wolfspraullet's say 30 USD, so 300,000 USD18:52
wolfspraulif you are willing to loose reprogrammability, maybe xilinx can sell you chips at a discount that are tested only against one specific bitstream18:53
wolfspraulthat might bring the costs of those chips to 150,000 USD, if such a program is already available at 10k units (I doubt it)18:53
wolfspraulnow, on the other side. If you try to tape-out the Milkymist One SoC in M1 in a 180nm process, could it compete performance-wise with the fpga? probably18:54
wolfspraulhow much would you need to see it all through the 180nm process? again a bit hard to say, but 150,000 USD is a lot of money at that size18:54
wolfspraulthe masks are expensive18:54
wolfspraulif you make mistakes and need several go-arounds, that's expensive18:54
wolfspraulMilkymist One is 'unproven' on the asic side, that's the biggest problem18:55
wolfspraulunproven = risk = cost18:55
wpwraki don't see so much of a point in going to an ASIC for lowering cost. much more for gaining speed. now, we know our core is very slow. but how are we doing on the graphics ?18:55
wolfspraulyes yes, me neither18:55
wolfspraulI just try to describe what I've learnt so far18:55
wpwrakthere, the bottleneck seems to be memory bandwidth. but is that limited by the memory technology we have or the fpga ?18:55
wolfspraulsince Fallenou asked18:55
wolfspraulI believe we should maximize the reprogrammability18:56
wolfsprauldo that first18:56
wolfspraulfirst get volume up, then think about cost (and the consequences)18:56
wpwrakfrom the geek side, i see reprogrammability as the M1's main feature18:56
wolfspraulI do want to learn more about the practical steps, risks and costs of > 130nm fabbing though18:57
wolfspraulnot because I want to do that now, or because I think that's what will drive M1 volume up18:57
wolfspraulbut so that we have a clearer long-term roadmap, a realistic and thoughtful one18:57
wolfspraulI think the hardware we have on m1 right now is just lovely. We can make our free tech shine on that.18:58
wolfspraulbig time18:58
wolfsprauland if it doesn't shine, we fix that first18:58
wpwrakokay, knowledge is power :)19:01
wolfspraulFallenou: did the above text block answer your question somewhat?19:01
wpwrakbtw, is http://downloads.qi-hardware.com/people/werner/tmp/xbrd-top.pdf comprehensible ?19:01
wolfspraulI was hoping some reflection time would help ;-)19:02
wpwrakyou need to zoom a little because fped auto-scales the labels19:02
wolfspraulthere are many options post-fpga, but all of those options have pros and cons. everything else would be a surprise of course, since we are not the first ones thinking about this...19:03
wolfspraulwpwrak: knowledge is power, but the question is which knowledge :-)19:04
wolfspraulsometimes a very small piece of knowledge can be very powerful, sometimes a very large piece of knowledge almost worthless19:04
wolfspraulwelcome to real life19:05
Action: Fallenou reading19:05
Fallenou(50-80% discount on Xilinx/Lattice fpga for single design chip) wooow nice, I didn't know about it !19:07
wolfspraulI've only read about it, no specifics. Maybe such programs are only available to select customers, though I can imagine yield being a major issue in fpga making, so it depends on how many non-100% chips they have...19:08
wolfsprauland the customer looses reprogrammability19:08
wpwrakalmost a faustian deal :)19:09
wolfspraulcome on this is manufacturing, everybody tries to find use for every last breadcrumb :-)19:12
wolfspraulno waste!19:12
wolfspraula customer who doesn't value reprogrammability is at high-risk to be lost to direct asic fabbing anyway19:13
wpwrakyeah, save a cent on every unit but spend millions on making one that's 1% different because nothing can be reused ;-)19:13
wolfspraulso it may not even cannibalize their 100% working fpga sales19:13
wpwrakoh, sure. for fpga makers it makes a lot of sense19:13
wolfspraulAltera has a program called HardCopy, I don't know much about it either. Some similar deal for Altera to avoid loosing customers to asic.19:15
wolfspraulall the way to 28nm, at least on the website :-)19:17
wolfspraulthey won't stop you trying :-)19:17
wolfspraulI would like to try fab something interesting, at some point in the future, on a cheap 180nm or so process in China. but the actual product opportunity needs to emerge first, i.e. volume.19:18
wolfspraulcould be Taiwan or so as well of course, wherever the fab is.19:19
wpwrakokay, ffs ;-)19:19
wolfsprauli don't see milkymist suddenly jumping into a very high-end process though, nobody will take the multi-million USD risk19:19
wolfspraulso that means we may be better off on high-end fpgas for the time being19:19
wpwrakhow about the board draft. can you make sense of what i drew ? http://downloads.qi-hardware.com/people/werner/tmp/xbrd-top.pdf19:19
wpwrakit's still incomplete. need to draw a side view, too.19:20
wolfspraulnot really yet, no19:20
wolfspraulbut it's on my screen here19:20
wpwrakgood :)19:20
wolfspraulon the right side is the acrylic?19:20
wolfsprauldinner, bbiab then I look at it more19:22
wpwrakenjoy ! (the dinner :)19:23
Fallenou20:06 < wolfspraul> Fallenou: did the above text block answer your question somewhat? < it gives me some clues I didn't have, thanks :)19:26
FallenouI wanted an approx about N when this equation becomes true : Making_mask_price + N*asic_unit_price < N*fpga_unit_price19:33
wolfspraulok but any serious calculation will need to include many more numbers19:48
wolfspraulthere are IP licensing cost, past and future investments into IP, sales forecast, price elasticity of the product you are selling, and so on19:50
wolfspraulthen there are different degrees of risk that a particular run (or mask) needs to be discarded19:50
wolfspraulsay the masks cost 1 million USD :-) so if the throw-away risk is 5%, that's 50k USD, if it's 80%, it's 800k USD19:51
wolfspraulwhy is the clearance to the wall specified?19:54
wolfspraulit would be good if the legend you have in the email could be in the ps/pdf19:54
wolfspraulhow about tolerances?19:54
wolfspraulare the outer dimensions of the pcb designed in such a way that they easily multiply to some larger panel? maybe compatible with some popular online pcb makers?19:55
wolfspraulare components on the bottom of the daughterboard pcb allowed?19:55
wpwrak(wall) you mean FB ? or the 2.46 mm between board edge and wall ?19:56
wolfspraulI'm just looking and thinking and writing19:56
wolfspraulso the male headers are at the bottom side, hmm19:56
wolfspraulwhat if someone wants to make a 1-layer pcb?19:56
wpwrak(legend) i'll probably have to redraw the whole thing with xfig, to make it look right. fped isn't good at handling text19:56
wolfspraulthen the other components would need to be on the bottom side as well19:57
wolfsprauland then we would need to specify a maximum height for that19:57
Fallenouok thanks for the intel wolfspraul :)19:57
wpwrak(tolerances) yes, the wall has some tolerances. that still needs doing19:57
wolfspraulright now you say the pcb max size is 42.86 by 85.0819:58
wpwrak(bottom side) yes. bottom clearance would be in the side view/19:58
wolfspraulhow do we come up with these numbers?19:58
wpwrak(wall) the acrylic front wall of M119:58
wolfsprauland there are no tolerances19:58
wolfspraulyou don't say 42.86 +-.5mm19:58
wpwrakthese are maxima. they have no tolerance19:58
wolfspraulthat's not very practical or usual, no?19:59
wpwrakif you process is +/- 0.5 mm, design for 42.36 mm ;-)19:59
wolfspraulwhenever you do anything in physical reality, there will be tolerances19:59
wolfspraulsure but we want the spec to be easily readable19:59
wolfspraulI'm giving feedback...19:59
wpwrakagain, it's a maximum. you can invent a tolerance but it does not correspond to reality19:59
wpwrake.g., if you write 42.76 +/- 0.1, you imply that an accuracy of 0.1 mm is needed, but we don't care. you can be off by 1 mm as long as you respect the maximum20:00
wolfspraulare the sizes designed such that they multiply easily into panels or some 'standard' maybe at batchpcb or whereever?20:00
wpwrakno. they reflect the internal spaces of M120:00
wpwraki don't think you can usefully optimize for panels20:01
wolfspraulwell yes, ok. my mechanical experience is less than yours. I think everything has tolerances. so you are better off defining the middle point and giving a 'tolerance' as a criteria for QA20:01
wpwrakeach pcb fab will have a set of board sizes, the distance between boards will vary, and so on20:01
wpwrakalso, this is a maximum size. if you want to optimize in general, you make it as small as you can. and if you want to optimize for a given fab, you pick a size that corresponds to their process and that stays below the maxima20:02
wpwrak(tolerance) there is no "middle point" :)20:03
wpwrakyou're not obliged to make the board that big20:03
wpwrakthe only things that can have meaningful tolerances are: B, FB, and FW.20:05
wpwrakHL and HW specify characteristics of the header in general. but the tolerances you see would come from the header you buy (and they will be very small anyway)20:06
wpwrakthere's also an implicit tolerance, the vertical offset between the headers. it's zero by design, but you could of course shift the header by a few um, even intentionally :)20:07
wpwrakyou're also not obliged to make a rectangular board. it just has to fit into the maximum area20:08
wolfspraulok, I think in most mechanical drawings you have tolerances20:09
wolfspraulso you have a dimension, and a tolerance. the dimension is what you tell your tool, and the tolerance defines the yield20:09
wolfspraul'maximum' is not something we can even provide on the other, m1, side20:10
wolfspraulbut my thinking may be wrong, you are making the most mechanical stuff ;-)20:10
wpwrakbut of course we can provide the maximum !20:10
wolfspraulnot very organic...20:11
wolfspraulbut it doesn't matter, it's a detail20:11
wpwrakwe can design M1 such that there is no obstacle within this area (taking into account the tolerances of out own process)20:11
wolfsprauloverall it looks great20:12
wolfspraulso a 1-layer pcb with components on the bottom side would be supported?20:12
wolfspraulnot sure how many people would want that...20:12
wolfspraulcan we explain the genesis of those numbers a little?20:13
wolfspraulit would make people who are doing derivative work feel more comfortable in making changes20:13
wpwrak1 layer should be possible. you have a certain clearance20:13
wpwrak(genesis) it's basically guesses of when you start hitting other components :)20:14
wpwrakalso not that the maximum board is not centered. that's in part because the VGA connector is in the way. that'll change anyway, but it'll probably get worse (DVI being larger than VGA)20:15
wpwrakthese maximum values are basically an assurance: we make sure that this area is clear for you, and we'll continue to make sure it stays clear.20:16
wpwraksomeone who chooses to exceed the limits may be able to get away with it, but at the risk of, say, M1r5 putting a conflicting obstacle20:17
wolfspraulbut we should explain those things along with the numbers20:17
wolfspraulthat's my point20:17
wolfspraulthat will make it much easier in the future, rather than carrying unknown golden values around20:17
wolfsprauljust the way you answer here is perfect, that's the missing bit for me when I look at the numbers20:18
wolfspraulsome values are rounded to 1mm, some not. why?20:19
wpwrakoh sure, this needs explanatory text. also needs electrical parameters, and so on20:19
wpwraki picked design values of multiples of 1 mm. the exception being the headers with a 100 mil raster20:20
wpwrakso the "odd" values are just combinations of my 1 mm values plus something the headers add20:21
wolfspraulah ok, yes20:22
wolfspraulthe golden numbers are coming from the golden connector20:23
wolfspraulok those are all questions I can come up with right now20:24
wolfspraulyes it all makes sense20:25
wpwrakso all documentation issues. the physical properties look reasonable then ?20:25
wolfspraul4x8 seems like a nice size20:25
wolfspraulphysical properties, huh20:26
wolfspraulthat's tough20:26
wpwraksome people will find it small, but there's no pleasing everybody :)20:26
wolfspraulI cannot really predict layout preferences, chip sizes, pcb antennae, etc.20:26
wolfspraulnot small20:26
wpwrakwe should make a dummy circuit, though. to see if any of the clearances cause layout issues20:26
wolfspraulI like it because it's squarely in the hand-held/mobile size range20:27
wpwrakah, what was the thickness tolerance for the acrylic again ?20:28
wolfspraulneed to search irclogs, I think it was 10 or even 20%20:28
wolfspraultolerance = cost20:28
wolfspraulI can get you any tolerance you want if you let me throw away (but still pay for) all the ones that don't meet your tolerance20:28
wolfspraulassuming we are not down to where measuring becomes difficult20:29
wpwrak(any tolerance i want) heh ;-)20:29
wolfspraulthat's why I think talking about tolerances is important, so people get a quick feeling where expensive/wasteful precision is needed20:32
wolfspraulit's like in math, the difference between 1 and 1.0020:32
wolfspraulotherwise someone may take a quick look at such a drawing and automatically assume the worst20:33
wpwraksure. but you have to understand that many of the values have no tolerances. they already are extremes. it's like a bridge. when it says that your car's maximum height can be 2.00 m, and your car is 2.10 m, the risk is all yours20:34
wolfspraulunderstood, but that doesn't come across on the drawing at first sight20:35
wolfsprauland you are asking for feedback, so there it is :-)20:35
wpwrakon the other hand, if you car is exactly 2.00 m, and you still get stuck, then you have a good chance of being able to get a bit of money from whoever mis-labeled that bridge20:35
wpwrakthat's in the text of the mail :)20:35
wolfspraulI have seen enough mechanical people and when they see a number without tolerance, they worry20:35
wpwrakoh yes. if it's a "typical" value, you wonder what the extremes are20:36
wpwrakbecause you need to design with them. same for, say, resistors in electronics20:36
wpwrakbut these are already the extremes. there's no tolerance on top of them. there's a bit of safety margin we allocate for ourselves, but that's not part of the "published spec" (we should still write it down, of course. but it's a different part of the document)20:37
wpwrake.g., the "M1 main PCB design" section could say to keep an area of 50 x 90 free from major obstructions20:38
wpwrak50 x 90 mm20:38
wolfspraulespecially if it's adjacent to large connectors20:38
wpwrakagain, that would be an extremal value. so no tolerance20:38
wolfspraulthe pcb itself is quite tight, but connectors are like skyscrapers standing on the 5mil structures20:39
wpwrakyeah. the main troublemaker there would be VGA. we also have a few other tall components, but some of them should vanish.20:41
wpwraki don't know how the DVI connector will change things. have we already selected a part ?20:41
wolfspraulnot to my knowledge20:41
wolfspraullet's ask Adam tomorrow, maybe he can squeeze it in before his vacation20:41
wolfsprauland maybe not20:41
wpwrakheh :) well, also a rough idea would be useful. then i could check the parameters more closely20:43
wolfspraulrough idea is - let's look whether molex has a dvi-i20:44
wolfspraulthey have the most oustanding mechanical drawings20:44
wolfspraulso they become the source of a lot of copying :-)20:44
wpwrakheh ;-)20:46
wpwraklet's see what our mounting choices are20:47
wolfspraulwow they are expensive, 4-5 USD at digikey20:49
wolfspraulbut there's a good chance to find a clone with very similar mechanical size20:50
wpwrakbuy more than one ;-)20:50
wolfspraulmost common one seems to be this http://search.digikey.com/us/en/products/74320-1004/WM5600-ND/35606620:54
wolfspraulabout 3 USD in qty 5020:54
wpwrakseems that vga goes a little bit deeper. that's good. maybe a few more mm for out board :)20:54
wpwrakyeah, this one looks quite reasonable20:54
wpwrakthere doesn't seem to be much variation anyway20:54
wolfspraulmolex series is 7432020:54
wpwraki.e., no "sunken" versions (with board cut-out)20:55
wolfspraulok but let's confirm with Adam tomorrow20:57
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01182012-2015/21:02
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01182012-2212/22:59
--- Thu Jan 19 201200:00

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