Hey tony! 好朋友
Glad to see your comments. Neng-Yu Tu (Tony Tu) wrote: > Steve Mosher wrote: >> Good comments All. >> >> Let me inline some answers/explanations. >> >> Lothar Behrens wrote: >>> Hi, >> I use this analogy. You write your code in a series of units. >> you unit test them. Then you do your first integration. >> You set up your make files and I charge you 50K to hit return. would you >> hit the compile button? > > Yes, this pretty much true, and you have to hit the button in time, or > so some the package in that make might phase out (like GTA01 PMU > PCF50606), and then you have spent another run of money to enable the > make button hit-able till mass production again. > >> So what's the result if you don't use a waterfall model in >> hardware development. Whats the cost if you find a requirements defect >> or a design defect ( glamo? )when you do that prototype run? 50K >> minimum, plus a redesign. Take the appendix out--perform a glamoectomy? >> ask Werner about the design implications of that on WIFI. And >> see my comments below about design and diving into peanut butter. >> > > Werner just replied, maybe he could share more about his painful direct > contact experience with chip vendor ;) > > In hardware, specification/datasheet is not always correct (or always > not correct). People may found a lot interesting component datasheet > with powerful function (the "dream chip") could solve specific design > problem, but when OM direct contact local distributor, following > scenario always happens: > > * the chip never put mass production before, or we are the only user > interested that chip, need bare with long lead-time and bad payment deal > > * the chip specific model we want not manufactured yet > > * the chip specific function not work, or could not work stability, even > the datasheet > > * Our quantities (market size) too small, ignore us (this is better > case, we sometimes got already married with some solution then after a > while, vendor ask for divorce ;) ) > > OM might have other internal issues, but external hardware game rules > tough as well. I don't think other company could really open hardware > not only legal issue (design specification with customer/contract with > telcom) but they got Open mind set to solve open hardware related > process issue like OM done before. Yes. I think one of the challenges that some people really dont understand very well are all these little nagging details.having worked for a big company I'm just used to going in and getting the parts I needed when I needed them. In 11 years there were only a few cases were I had to go begging for parts.. RAM on the VoodooII from silcon magic, and DDR memory on the Nv10 I think from infineon.. oh and 1.8 toshiba drives after the ipod shipped, bastards.. ah and tantalum caps once or twice. >> or capacitive, keyboard or touch.-- ALL signs to me of a lack of >> appreciation for the complexity and cost involved in doing hardware. I >> got a hammer your problem must be a nail. I'll give you > > And each component we have to verify it's hardware functionality and > compatibility with Open source, and most of time we have to spent extra > resource to build a full GPL'ed driver if vendor only have proprietary > Windows or some binary vendor version. > > This also cause the difficulty when verification hardware in time, > because we need build our own driver to test vendor's hardware. Usually > only hardware vendor could have 1 or 2 FAE port driver for us, and with > our latest kernel and open policy (release driver early even before > product manufactured). > >> and energy is spent on this "solution" In the end, marketing looks at >> that and says "who took the fucking camera out!" that's not an actual >> example, but you get the idea. > > Yes, freeze idea and snapshot it in time is art of products ;) > >>> Isn't it possible to also develop hardware collaboratively? >> In one sense this is trivally true. hardware development is >> inherently collaborative. But I suppose you mean is it possible >> to do it in an open fashion. It maybe. But if the requirements process >> and design process is not rigorous and well defined you end up >> with expensive implementation problems. And if you don't have team >> consensus, then it's very problematic. Forking software is easy. >> Forking hardware is forking hard. The best example I can use is >> forking ASIC design. You can do a big chip with lots of functionality >> and then fork off 'defeatured' versions, but that forking needs to >> be designed in.and it may come with a cost. the same holds true >> for modular hardware designs. what's easy with lego blocks aint so >> trivial when it comes to EE design. >> > > As describe above, some of the chip/module may not look pretty real > world as pdf does. And component have supply issue, you never knows you > are the only one buying the really crap or not until you put into mass > production. > > Using S3C6410 as example, you never sure which version will put into > mass production for sure or which version will phase out in next 6 > months, unless you direct contact with the vendor/distributor, and got > the update in time. It's hard to explain: sorry, your last 6 months > software plan won't work because vendor's business plan suddenly > canceled due to another their BIG customer want go another direction. > > Neng-Yu Tu (Tony Tu) _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community