Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
lekernel_ [lekernel_!~lekernel@g225039107.adsl.alicedsl.de] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wpwrak> lekernel_: did you see wolfgang's question about kicad ?
<wpwrak> (and the clarifications following it)
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wpwrak> phew. introduction of a symbol table will tighten up so many loose ends ... and hardly leave any line unchanged :-(
<wpwrak> tie up, even :)
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
pablojavier [pablojavier!~pablo@186.19.202.221] has joined #milkymist
pablojavier [pablojavier!~pablo@186.19.202.221] has quit [#milkymist]
Gurty` [Gurty`!~princess@ALyon-256-1-110-187.w90-9.abo.wanadoo.fr] has joined #milkymist
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<roh> ~.
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
cjdavis1 [cjdavis1!~cjdavis@cpe-71-67-99-208.cinci.res.rr.com] has joined #milkymist
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
cocoadaemon [cocoadaemon!~cocoadaem@cho94-7-88-169-144-233.fbx.proxad.net] has joined #milkymist
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<lekernel_> wolfspraul: sounds like a lot of work and will do nothing to solve M1's biggest problem - unpopularity
<wolfspraul> the popularity will come, I think
<wolfspraul> Milkymist as of today has a number of experienced quality people that believe in the inner values (!) of this approach
<wolfspraul> that's not a guarantee for success, but I'd say that raises the probability above 50% :-)
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
<wolfspraul> now, we do need to find the magic mix, magic product, magic message, for this to catch on
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<wolfspraul> here's something I like: behind every failure there is a reason, behind sucess there is a secret
<wolfspraul> :-)
<wolfspraul> xiangfu: good morning!
<xiangfu> Hi
<wpwrak> lekernel_: 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.
<wpwrak> lekernel_: i don't know if we have such a base of potential volunteers yet. but there's only one way to find out :)
<[florian]> lekernel_: thanks!
<wpwrak> lekernel_: 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)
<lekernel_> phew. there are tons of geeks who happily buy $1k makerbots ...
<wpwrak> lekernel_: hmm yes, but makerbots have of course a different kind of appeal ... :)
<wpwrak> lekernel_: M1 has the disadvantage of the intangible. at least it has rapidly moving pictures. that pleases our instincts, too :)
<wpwrak> lekernel_: and since you've added image support, it can even have naked girls. sex sells, right ? maybe we should market to strip clubs.
<wpwrak> anyway, 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. ?
<wpwrak> of course, the long-term goal would be to get rid of altium completely and do everything in kicad
<wpwrak> but i don't see that happen for rc4
<wpwrak> for a number of reasons. e.g., the external layout house that still plays a key role
<lekernel_> no, I do not love altium. kicad is ok, but I don't see much point in converting the existing design...
<wpwrak> three 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.
wolfspraul [wolfspraul!~wolfsprau@p5B0AA714.dip.t-dialin.net] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
cladamw_ [cladamw_!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AA714.dip.t-dialin.net] has joined #milkymist
<wolfspraul> one 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 products
<wolfspraul> the Altium files are quite a black-box/blocker in that regard, imho
<wolfspraul> by opening the process more and moving to free tools, we lower risks and costs
<wolfspraul> for ourselves, and others
<wolfspraul> that can also get excitement for today's m1 (even rc3) up, because the future becomes brighter :-)
<wolfspraul> now... 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 board
<wolfspraul> if those win anyway, then it makes no difference what format and tools are used for m1
<wolfspraul> bottom 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)
<wolfspraul> I am fairly relaxed about this btw, I can go either way. I just want to manufacture and sell high-quality open products.
<lekernel_> people use devboards instead of M1 because they're cheaper or because they haven't heard of M1
<lekernel_> no need to look further
<wolfspraul> sorry I think you misunderstood me
<wolfspraul> I meant as the basis of a future *product*
<wolfspraul> I am aware of various devel board activities, but from what I can see, they all lead nowhere (not to a product at least)
<wolfspraul> if I overlook something, please let me know the link
<wolfspraul> the 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 in
<lekernel_> well... if you want to reroute everything, use a artix-7 and ddr3 :-)
<wolfspraul> the ones happening inside companies lead to closed products
<wolfspraul> no no, you think too radical
<wolfspraul> well, we are the 'radical tech coalition', I guess
<wolfspraul> I don't want to break compatibility, in general. i want to deliver updates to our existing customers, and improve the product incrementally.
<wolfspraul> and *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.
<wolfspraul> what I meant above is a different case
<wolfspraul> imagine someone wants to make a new Milkymist-based product
<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 specs
<wolfspraul> what will they take as their starting point?
<wolfspraul> right now most likely they would take EDA files that are released as part of the devel board closest to their planned product
<lekernel_> otherwise it's just running in circles. M1 isn't popular with those specs, no matter whatever PCB design tool we use.
<wolfspraul> wait. I only made an argument about 'why' for the KiCad files, since you asked.
<wolfspraul> it's to make *future* products easier
<wpwrak> lekernel_: you're already working on improving the specs :)
<lekernel_> alright, for a future product, use kicad
<lekernel_> I'm perfectly fine with that
<wolfspraul> let's assume you would want to make that artix/ddr3 board, ok?
<wolfspraul> how would you do it?
<lekernel_> but switching the current M1 design to kicad without major changes sounds like a waste of time
<wolfspraul> plus, the main thing we are discussing now is schematics and bom
<wolfspraul> we are aware of the costs and limited future reuse value of moving the layout today
<wpwrak> i 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.
<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?
<wolfspraul> unfortunately we know little about layout
<wolfspraul> 'know' in the sense of costs, risks, exact criteria to watch, things to avoid, etc.
<wolfspraul> so yeah, probably moving layout to KiCad now, don't know
<wolfspraul> sounds like asking for trouble with little value
<wpwrak> converting 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.
<wolfspraul> yes, definitely
<lekernel_> yeah, and then keep it in sync with altium for layout?
<lekernel_> why?
<wolfspraul> a large part of which will benefit any future Milkymist-based product, or rather that's the goal
<lekernel_> lots of work, almost zero return
<wpwrak> i wouldn't duplicate the layout. schematics are more static
<lekernel_> so, design that future product from scratch using kicad?
<wolfspraul> the truth is also that we know little about layout
<wolfspraul> from what I can tel
<wolfspraul> tell
<wolfspraul> that makes us extra worried to make any decisions about layout, how to reuse, how to move
<lekernel_> ?
<wpwrak> for 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 moment
<lekernel_> I'm not worried about layout changes
<wolfspraul> lekernel_: well, maybe you are most clear :-) don't know
<lekernel_> but yeah signal integrity can be a pain
<wolfspraul> I am very careful about such things until I have a good feeling that I understand the risks. [layout]
<wolfspraul> need to have made a few 'bad' pcbs first
<wolfspraul> :-)
<lekernel_> this has little to do with kicad vs. altium though
<wolfspraul> yes, it only has to do with how we make layout-related decisions
<wolfspraul> but if we would use kicad as the basis for a future milkymist-based product, why not move it now?
<wpwrak> one 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 one
<lekernel_> because it's only duplicating existing altium work
<lekernel_> zero return in the end
<lekernel_> it's about as much work as switching to artix/ddr3 without any of the benefits
<wpwrak> it'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.
<wolfspraul> I'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 available
<wolfspraul> how much of the current m1 schematics are reusable I don't know
<wolfspraul> how much such an increase in specs would help m1 sales I don't know
<lekernel_> depends who you ask... FAEs are sometimes happy to hand out "early engineering samples" of upcoming FPGAs
<lekernel_> ridden with bugs of course :-)
<wolfspraul> almost feels like we are better off with a new, second Milkymist-based product, maybe something mobile to differ from m1
<wpwrak> plus, 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.
<wolfspraul> but 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) discussion
<wolfspraul> I don't think increased specs would sell more m1
<wpwrak> we're not using what the current hw can do anyway :)
<wolfspraul> unless we move away from open tech, but then it quickly becomes a lost cause
<wolfspraul> then the Raspberry Pi is better :-)
<wolfspraul> I think m1 the product is great and has big potential to improve and sales to pickup. without the need for artix-7 or ddr3.
<wpwrak> lekernel_: 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.
<wolfspraul> of course upgrading that is stlil good, but I don't see a direct connection to sales
<wpwrak> lekernel_: alas, that project then died of other causes, but the schematics went rather well
<wpwrak> lekernel_: and i'm reusing a number of things from there in ben-wpan and other qi-hw projects :)
<wpwrak> a clone also has the advantage that you have a known reference. makes it easier to spot bugs.
<wpwrak> think of it like training wheels :)
<lekernel_> my vision of Milkymist is specs better than proprietary devices, and minority report style user interfaces
<lekernel_> that's the only way we'll get noticed, and it's an interesting technical challenge
<wolfspraul> I couldn't agree more with you, but...
<wolfspraul> there is a problem :-)
<wolfspraul> 'specs' depends on the definition of product (and category) we make
<wolfspraul> for example if you make a 'tablet', then the screen resolution will be compare to A, B, C
<lekernel_> then we use screen resolution >= max(A, B, C)
<lekernel_> simple
<wolfspraul> if you make a camera, the resolution will be compared to X, Y, Z
<wolfspraul> the 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 use
<wolfspraul> so I think M1 is a good shot, because it cannot easily be categorized into existing categories
<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 chips
<wpwrak> i 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.
<wolfspraul> that 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 cases
<lekernel_> it then takes care of many "details"
<wolfspraul> yes, perfect
<wolfspraul> [migen]
<wolfspraul> I just want to say with 'specs better than proprietary' you have to be careful
<wpwrak> it's the GHz race all over again
<wolfspraul> you have no chance running a softcore in an fpga against a gpu made in a 28nm process
<wolfspraul> so you are comparing apples and oranges then, makes no sense
<wolfspraul> Milkymist is far better than that!
<wpwrak> recommendation for all small mammals: don't try to bear the dinosaurs at being a dinosaur. outfit them ;-)
<wpwrak> s/bear/beat/
<wolfspraul> I do like the 'world-class specs' goal, absolutely
<wolfspraul> but we need to be in control about what they are compared with
<wolfspraul> otherwise we will always loose, that simple
<lekernel_> yes, of course
<lekernel_> but there are some tasks at which FPGAs beat 28nm GPUs. I didn't say "softcore", we have dedicated hardware accell...
<wpwrak> the 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 :)
<wolfspraul> yes sure, they want to control what they are being compared with as well
<wolfspraul> anyway, I agree on ramping up specs
<wpwrak> lekernel_: 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.
<wpwrak> lekernel_: 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 ?
<lekernel_> some areas like CPU architecture haven't moved much since the last decade :)
<lekernel_> or even two decades
<lekernel_> of course, we have RISC laptops/tablets and multicores. but those have been around for ages, simply not marketed so widely...
<wpwrak> if 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 ? ;-)
<wpwrak> if there's no potential anyway, then M1 is state of the art and we don't have to worry about that aspect :)
<wolfspraul> that's migen
<lekernel_> yes
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
Gurty [Gurty!~princess@ALyon-256-1-183-204.w109-213.abo.wanadoo.fr] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<GitHub1> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/14zFkA
<GitHub1> [milkymist-ng/master] Convert -> convert - Sebastien Bourdeauducq
<GitHub164> [migen] sbourdeauducq pushed 2 new commits to master: https://github.com/milkymist/migen/compare/6bd8566...4c04081
<GitHub164> [migen/master] Convert -> convert - Sebastien Bourdeauducq
<GitHub164> [migen/master] Merge branch 'master' of github.com:milkymist/migen - Sebastien Bourdeauducq
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<wolfspraul> too bad, my m1 rubber keyboard broke, some characters don't work anymore (esc, tab, q, a - seems that region there)
<wolfspraul> I 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...
<lekernel_> thanks to Werner's USB fixes more keyboards should work now :)
<wpwrak> that rubber keyboard seems to be quite ubiquitous. but indeed, who knows how durable :)
wolfspra1l [wolfspra1l!~wolfsprau@p5B0AA714.dip.t-dialin.net] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AA714.dip.t-dialin.net] has joined #milkymist
proppy [proppy!u1692@gateway/web/irccloud.com/x-dznjmuxgoxahsasz] has joined #milkymist