steve at openmoko.com
Tue Apr 14 05:16:05 CEST 2009
Werner Almesberger wrote:
> Steve Mosher wrote:
>> 1. Target market selection ( who is the customer)
>> 2. MRD ( what are their needs)
>> 3. Engineering Spec. ( designs a-n that meet the MRD)
>> 4. Business plan review. (budgets and ROI)
>> 5. Operations review. ( can we produce it)
>> 6. Continue or return to step 1,2,3,4 depending on failure mode.
>> ha I just turned it into software. GTA03 was stuck in an endless loop
> Hehe ;-) There are some feedback loops there, though. Also, you
> sometimes can't close an issue before later, simply because the
> negotiations or some tricky engineering problem take more time
> than the schedule would like. It's all calculated risks ...
Ya, I think rapid convergence in 1-5 is one aspect of operational
effiency that is underated. How quickly can a team CLOSE on a design
>> 7. archetecture and implementation spec
>> 8. theory of operations.
>> 9. Design.
>> 10. Layout.
>> 11. Prototype
>> 12. EVT
>> 13. DVT
> I wouldn't break it down like this - there are several prototypes in
> EVT and generally also in DVT, all of them at least with schematics,
> BOM, and layout changes.
yes I know that werner. I'm just trying to characterize it at my high
level. you can get stuck on step 11 for weeks.. even have to resort to
CNT/ALT/DEL. But I would always start with a Nominal plan.. eg 2-3
protos, Same in EVT, and 2 in DVT, 2 in DVT.
> Hmm, Wikipedia for once lets us down on a useful definition for those
> TLAs. Here's something that's not so bad:
> It's basically:
> - EVT: "Is it possible ?"
> Make prototypes until at least one of them works in the lab.
> - DVT: "Can it be made into a product ?"
> Make it work legally also outside the lab.
> - PVT: "Can we produce it ?"
> Bring the production process to a factory.
Ya.. In PVT you have some slop. Its basically a yeild/cost question.
I've shipped product with a 50% yeild ( first batch) because
1. I knew a second design was coming in 2-3 weeks
2. Some of the failures were suspected to be a false negative
3. The bonepile could be reworked, or repeced. ( frequency limits)
4. The chip guy who provided the reference design, agreed to
eat some of the yeild loss.
( and no, I won't tell you who it was, but their name starts with Nv.. hehe)
>> when starting down the path. Werner is rather bottoms ups, or rather
>> he like to have all the details known before starting down a path.
>> Is that about right werner?
> Yeah, I like to have both the "big picture" and to have it mapped out
> in sufficient detail that I can see where the unexpected problems are.
> In my mind, a project is composed of things that are hard to do (which
> take an indeterminate amount of time) and things that are easy to do
> (which take a negligible amount of time). So my approach is always to
> reduce the number of the hard or not completely understood problems.
> Naturally, as you may expect from a sum of epsilons and potential
> infinites, my forecasts at how long something will actually take just
> suck :-)
>> This, coupled with my impatience, makes
>> for spirited discussions between us, but our mutual rspect for each
>> other keeps the discussion civil. Plus werner plays great tunes.
> Hehe, thanks :-) I must say that I also find it very enlightening to
> better understand the marketing angle of things. Even as engineers,
> there are a lot of implicit marketing assumptions we just make, and
> and we don't even realize that they may actually be questionable or
> even wrong.
I appreciate that. I readily admit to some classic bone head moves. For
people's edification I can detail them... I did a bit in the writing
about chasm theory. I would definitely do things differently.
>> The next Phone:
>> 1. GTA02 cost down
> Hmm, that would be
> - move BT to the PCB (yield goes up)
> - NOR removal (hard to source and eats space)
> Need to find a plan B for unbrickability then. Some possibilities:
> - do as we did in GTA01 and depend on the debug board
Yes I love selling that.
> - add a NAND trap-door circuit
> - integrate IDBG
HA. ok I'll look at it again. I'm more amenable this time around
since I have attach rates for debug and better cost data and Some
anecdotal info on the failure rates of the flex cable. You don't
give up. I like that.. sometimes. So A fresh look.
> - remove one of the acceleration meters (useless)
yes. I puzzled over having two to begin with. The stated purpose
was just plain math BS.
> anything else ?
>> 2. GTA02 Glamoectomy - G
> The moment of great liberation :-)
be gone dreaded glamo
>> 3. GTA02 -G+E Glamoecyomy, new Edge +E
> I'd very much like to see the demise of the Calypso. It's been EOL
> for as long as I remember, and while the consequences of working
> with a hopelessly obsolete chipset were still surprisingly mild, they
> are adding up.
> We should also review WLAN. AR6001 is about as dead-ended as the
> Calypso, so the least we would have to do is to replace it with an
> AR6002. I don't know how bad the driver situation would be, though.
> Atheros are working on a "lean" firmware for the AR6002, but that
> won't be ready for some more months.
> Switching to Marvell would mean that we'd either have to find a
> different module than the USI we have right now (because we don't
> have a UART for BT), accept that we have a useless BT component on
> that module, or upgrade to a CPU with one more SDIO port.
ha slippery slope
>> 4. GTA02 -G+E+P add 6410
> The 6410 would give us more connectivity choices (more SDIO, more
> UARTs, High-Speed USB, etc.), better overall performance (FPU and
> all that), and more flexible clock management.
> Drawbacks of the 6410 include relatively new kernel support, more
> difficult SMT, and more difficult thermal management.
>> then options of camera, 3g etc etc etc.
> With the design we have for GTA03, the camera interface works. I
> just have to figure out how to get the camera to make good
> pictures :-)
> 3G is the great unknown.
> For a community-centric approach, I think one important requirement
> would be to have a common set of tools, so that everyone can go
> through the schematics or layout, look at the CAD data, etc.
> In Openmoko, we always had that distinction of engineers with access
> to the proprietary EDA and CAD tools and the second-class citizen who
> depended on others to provide them with PDFs. This was always
> extremely dissatisfying, yielded a disconnected development process,
> and eventually caused problems to get overlooked.
> I'm not sure how feasible it would be to convert the existing material
> into something sufficiently free tools can use. PADS to KiCad, Pro/E
> to HeeksCAD ? :)
> Another issue is access to vendor documentation. There's a lot of
> material that is under some form of NDA and that would have to be made
> accessible to the community in order to allow people to understand how
> things work.
> - Werner
More information about the Gta03