#milkymist IRC log for Thursday, 2012-01-05

wpwraklekernel_: did you see wolfgang's question about kicad ?01:30
wpwrak(and the clarifications following it)01:30
wpwrakphew. introduction of a symbol table will tighten up so many loose ends ... and hardly leave any line unchanged :-(02:19
wpwraktie up, even :)03:02
lekernel_wolfspraul: sounds like a lot of work and will do nothing to solve M1's biggest problem - unpopularity09:37
wolfspraulthe popularity will come, I think09:40
wolfspraulMilkymist as of today has a number of experienced quality people that believe in the inner values (!) of this approach09:40
wolfspraulthat's not a guarantee for success, but I'd say that raises the probability above 50% :-)09:40
wolfspraulnow, we do need to find the magic mix, magic product, magic message, for this to catch on09:41
wolfspraulhere's something I like: behind every failure there is a reason, behind sucess there is a secret09:42
wolfspraulxiangfu: good morning!09:42
wpwraklekernel_: it may be an opportunity to try to involve more people. converting schematics is something someone without top-notch skills can do. so it may appeal to a larger group of people, who haven't seen an opportunity to get involved just yet.10:11
wpwraklekernel_: i don't know if we have such a base of potential volunteers yet. but there's only one way to find out :)10:12
[florian]lekernel_: thanks!10:19
wpwraklekernel_: also the technical prerequisites are lower: all you need to participate is a PC with kicad. no USD 500 milkymist ;-) (which is of course good and bad at the same time)10:32
lekernel_phew. there are tons of geeks who happily buy $1k makerbots ...10:34
wpwraklekernel_: hmm yes, but makerbots have of course a different kind of appeal ... :)10:37
wpwraklekernel_: M1 has the disadvantage of the intangible. at least it has rapidly moving pictures. that pleases our instincts, too :)10:38
wpwraklekernel_: and since you've added image support, it can even have naked girls. sex sells, right ? maybe we should market to strip clubs.10:40
wpwrakanyway, would you see any other problems - for the project, you, or others - in converting to kicad ? would it bother you if we did that ? (e.g., in case you really love altium but hate kicad). etc. ?10:47
wpwrakof course, the long-term goal would be to get rid of altium completely and do everything in kicad10:47
wpwrakbut i don't see that happen for rc410:48
wpwrakfor a number of reasons. e.g., the external layout house that still plays a key role10:48
lekernel_no, I do not love altium. kicad is ok, but I don't see much point in converting the existing design...10:59
wpwrakthree reasons: 1) more compatible with our general philosophy of openness. 2) we already have a number of EDA tools (schhist, boom) that are work around kicad. 3) with the switch to boom for sourcing, there'll be more work, both on the schematics (tightening the specs, etc.), and also on tool integration.11:04
wolfspraulone advantage of KiCad (and schhist/boom/dsv/etc) I see is that it lowers the costs to make future improved products, or derivative/new Milkymist-based products14:32
wolfspraulthe Altium files are quite a black-box/blocker in that regard, imho14:32
wolfspraulby opening the process more and moving to free tools, we lower risks and costs14:33
wolfspraulfor ourselves, and others14:33
wolfspraulthat can also get excitement for today's m1 (even rc3) up, because the future becomes brighter :-)14:33
wolfspraulnow... this assumes that we gain enough critical mass that when starting a new improved or different Milkymist-based product, one is better off to start with the KiCad/boom/dsv files, than with the Altium files, or the PADS/Altium/etc. files released with a devel board14:34
wolfspraulif those win anyway, then it makes no difference what format and tools are used for m114:34
wolfspraulbottom line: we either believe in this stuff or not. If we don't believe in it ourselves, then of course we can ask noone else to follow us either, and the next round will start with proprietary devel board tools again (inevitably, since we don't even try to start an open alternative)14:35
wolfspraulI am fairly relaxed about this btw, I can go either way. I just want to manufacture and sell high-quality open products.14:36
lekernel_people use devboards instead of M1 because they're cheaper or because they haven't heard of M114:37
lekernel_no need to look further14:37
wolfspraulsorry I think you misunderstood me14:38
wolfspraulI meant as the basis of a future *product*14:38
wolfspraulI am aware of various devel board activities, but from what I can see, they all lead nowhere (not to a product at least)14:39
wolfspraulif I overlook something, please let me know the link14:39
wolfspraulthe devel board activites I see are mostly the need of a little hobby hacking until one looses interest, or something study-related, which will be dropped the day the exam is handed in14:39
lekernel_well... if you want to reroute everything, use a artix-7 and ddr3 :-)14:41
wolfspraulthe ones happening inside companies lead to closed products14:41
wolfspraulno no, you think too radical14:41
wolfspraulwell, we are the 'radical tech coalition', I guess14:41
wolfspraulI don't want to break compatibility, in general. i want to deliver updates to our existing customers, and improve the product incrementally.14:41
wolfsprauland *increase* the degree to which we control the underlying technology, so we are free to move whereever we want later. or anybody is, in fact. it's all open.14:42
wolfspraulwhat I meant above is a different case14:42
wolfspraulimagine someone wants to make a new Milkymist-based product14:42
lekernel_if you're going to expend the work of a complete board redesign with a new tool, then take the opportunity to make something with more competitive specs14:42
wolfspraulwhat will they take as their starting point?14:42
wolfspraulright now most likely they would take EDA files that are released as part of the devel board closest to their planned product14:43
lekernel_otherwise it's just running in circles. M1 isn't popular with those specs, no matter whatever PCB design tool we use.14:43
wolfspraulwait. I only made an argument about 'why' for the KiCad files, since you asked.14:44
wolfspraulit's to make *future* products easier14:44
wpwraklekernel_: you're already working on improving the specs :)14:44
lekernel_alright, for a future product, use kicad14:44
lekernel_I'm perfectly fine with that14:44
wolfspraullet's assume you would want to make that artix/ddr3 board, ok?14:44
wolfspraulhow would you do it?14:44
lekernel_but switching the current M1 design to kicad without major changes sounds like a waste of time14:44
wolfspraulplus, the main thing we are discussing now is schematics and bom14:45
wolfspraulwe are aware of the costs and limited future reuse value of moving the layout today14:45
wpwraki think the idea it to only have the schematics in kicad for now, not yet the layout. getting the schematics converted at all is one of those "big obstacles" that scare people. once that is done, making incremental improvements won't be so hard.14:45
lekernel_so, that incremental improvement would have to be done twice? once in kicad, and once in altium, being very careful the two are in sync?14:46
wolfspraulunfortunately we know little about layout14:47
wolfspraul'know' in the sense of costs, risks, exact criteria to watch, things to avoid, etc.14:47
wolfspraulso yeah, probably moving layout to KiCad now, don't know14:48
wolfspraulsounds like asking for trouble with little value14:48
wpwrakconverting the schematics isn't just the task of redrawing them, but also making the symbols, establishing conventions, tightening the component specs in the schematics, setting up a workflow (with things like schhist), and so on. it's a lot of things.14:48
wolfspraulyes, definitely14:48
lekernel_yeah, and then keep it in sync with altium for layout?14:49
wolfspraula large part of which will benefit any future Milkymist-based product, or rather that's the goal14:49
lekernel_lots of work, almost zero return14:49
wpwraki wouldn't duplicate the layout. schematics are more static14:49
lekernel_so, design that future product from scratch using kicad?14:49
wolfspraulthe truth is also that we know little about layout14:49
wolfspraulfrom what I can tel14:50
wolfspraulthat makes us extra worried to make any decisions about layout, how to reuse, how to move14:50
wpwrakfor now, it would be just duplication of the schematics. we can probe into doing the layout in the kicad world, but i don't know if we have the resources to accomplish this at the moment14:50
lekernel_I'm not worried about layout changes14:50
wolfspraullekernel_: well, maybe you are most clear :-) don't know14:50
lekernel_but yeah signal integrity can be a pain14:51
wolfspraulI am very careful about such things until I have a good feeling that I understand the risks. [layout]14:51
wolfspraulneed to have made a few 'bad' pcbs first14:51
lekernel_this has little to do with kicad vs. altium though14:51
wolfspraulyes, it only has to do with how we make layout-related decisions14:51
wolfspraulbut if we would use kicad as the basis for a future milkymist-based product, why not move it now?14:52
wpwrakone problem with kicad is that there's no free router. there is a gratis-to-use one, web-based, but i'm not sure we want to use that one14:52
lekernel_because it's only duplicating existing altium work14:52
lekernel_zero return in the end14:52
lekernel_it's about as much work as switching to artix/ddr3 without any of the benefits14:53
wpwrakit's not just duplicating. there's a certain amount of kicad-specific work that has to be done either way. so that is done then.14:53
wolfspraulI'd love to start looking into such a board, though from what I hear it will be another 6-12 months or more until artix becomes available14:53
wolfspraulhow much of the current m1 schematics are reusable I don't know14:53
wolfspraulhow much such an increase in specs would help m1 sales I don't know14:54
lekernel_depends who you ask... FAEs are sometimes happy to hand out "early engineering samples" of upcoming FPGAs14:54
lekernel_ridden with bugs of course :-)14:54
wolfspraulalmost feels like we are better off with a new, second Milkymist-based product, maybe something mobile to differ from m114:54
wpwrakplus, we'd avoid putting more things into altium-specific features. i.e., if we don't have the schematics in kicad, the bom-related work has to center altium. that would be a 100% loss in the end.14:54
wolfspraulbut I'd rather focus on polishing m1 for a while, especially if we do things that apply to future products as well, hence the KiCad (schematics&bom) discussion14:55
wolfspraulI don't think increased specs would sell more m114:55
wpwrakwe're not using what the current hw can do anyway :)14:55
wolfspraulunless we move away from open tech, but then it quickly becomes a lost cause14:55
wolfspraulthen the Raspberry Pi is better :-)14:56
wolfspraulI think m1 the product is great and has big potential to improve and sales to pickup. without the need for artix-7 or ddr3.14:56
wpwraklekernel_: we once did a "clone" of the openmoko gta02 phone from openmoko's PADS-based design into kicad (schematics only). and that was a good experience. also got lots of people to participate.14:57
wolfspraulof course upgrading that is stlil good, but I don't see a direct connection to sales14:57
wpwraklekernel_: alas, that project then died of other causes, but the schematics went rather well14:57
wpwraklekernel_: and i'm reusing a number of things from there in ben-wpan and other qi-hw projects :)14:57
wpwraka clone also has the advantage that you have a known reference. makes it easier to spot bugs.14:58
wpwrakthink of it like training wheels :)14:58
lekernel_my vision of Milkymist is specs better than proprietary devices, and minority report style user interfaces15:03
lekernel_that's the only way we'll get noticed, and it's an interesting technical challenge15:04
wolfspraulI couldn't agree more with you, but...15:04
wolfspraulthere is a problem :-)15:04
wolfspraul'specs' depends on the definition of product (and category) we make15:05
wolfspraulfor example if you make a 'tablet', then the screen resolution will be compare to A, B, C15:05
lekernel_then we use screen resolution >= max(A, B, C)15:05
wolfspraulif you make a camera, the resolution will be compared to X, Y, Z15:05
wolfspraulthe only way for us to have competitive specs is to focus on entirely new use cases and then optimize the hell out of them and make them very easy to use15:06
wolfspraulso I think M1 is a good shot, because it cannot easily be categorized into existing categories15:07
lekernel_one of the points of migen is that increasing things like resolutions is merely a matter of throwing in a bigger FPGA and more DDR3 chips15:07
wpwraki would see the "higher specs" target more for a M2 device. you'd also have to improve the mechanical appearance, etc. all this costs money. so it would depend on either how well M1 sells or how much we can get in terms of external investment.15:07
wolfspraulthat doesn't mean we can be lazy and get away with any specs, but it means you don't have to compete with nvidia and many others who are optimizing (by using hundreds of millions of USD) for certain use cases15:08
lekernel_it then takes care of many "details"15:08
wolfspraulyes, perfect15:08
wolfspraulI just want to say with 'specs better than proprietary' you have to be careful15:08
wpwrakit's the GHz race all over again15:08
wolfspraulyou have no chance running a softcore in an fpga against a gpu made in a 28nm process15:08
wolfspraulso you are comparing apples and oranges then, makes no sense15:09
wolfspraulMilkymist is far better than that!15:09
wpwrakrecommendation for all small mammals: don't try to bear the dinosaurs at being a dinosaur. outfit them ;-)15:09
wolfspraulI do like the 'world-class specs' goal, absolutely15:09
wolfspraulbut we need to be in control about what they are compared with15:10
wolfspraulotherwise we will always loose, that simple15:10
lekernel_yes, of course15:10
lekernel_but there are some tasks at which FPGAs beat 28nm GPUs. I didn't say "softcore", we have dedicated hardware accell...15:11
wpwrakthe big corps spend a lot of marketing effort on making everyone believe the only things wort competing are those where they are strong. if you get sucked into this, this only speaks of the quality of their marketing :)15:11
wolfspraulyes sure, they want to control what they are being compared with as well15:12
wolfspraulanyway, I agree on ramping up specs15:12
wpwraklekernel_: please remember that one problem we have is that we can't just keep on not making products. that's another fallacy: invariably, anything that looks cool when you begin will be less cool when you're ready to market it. even mroe so if you're slow, like we still are.15:13
wpwraklekernel_: but if you then abandon it and try to catch up again, you'll never finish. you can make a living out of this approach if yuo have a completely independent source of financing. but where is that in our case ?15:14
lekernel_some areas like CPU architecture haven't moved much since the last decade :)15:14
lekernel_or even two decades15:15
lekernel_of course, we have RISC laptops/tablets and multicores. but those have been around for ages, simply not marketed so widely...15:15
wpwrakif you see a potential for improvement over what we have now there, what's stopping you from implementing a more efficient core with M1 then ? ;-)15:16
wpwrakif there's no potential anyway, then M1 is state of the art and we don't have to worry about that aspect :)15:16
wolfspraulthat's migen15:16
GitHub1[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/14zFkA18:32
GitHub1[milkymist-ng/master] Convert -> convert - Sebastien Bourdeauducq18:32
GitHub164[migen] sbourdeauducq pushed 2 new commits to master: https://github.com/milkymist/migen/compare/6bd8566...4c0408118:32
GitHub164[migen/master] Convert -> convert - Sebastien Bourdeauducq18:32
GitHub164[migen/master] Merge branch 'master' of github.com:milkymist/migen - Sebastien Bourdeauducq18:32
wolfspraultoo bad, my m1 rubber keyboard broke, some characters don't work anymore (esc, tab, q, a - seems that region there)19:47
wolfspraulI am not sure whether that's the final one we picked after all the comparisons, but it does make me wonder about durability of the keyboard we include...19:47
lekernel_thanks to Werner's USB fixes more keyboards should work now :)19:53
wpwrakthat rubber keyboard seems to be quite ubiquitous. but indeed, who knows how durable :)21:36
--- Fri Jan 6 201200:00

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