Welcome

[Steve Mosher]

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
>> Cnt-alt-del.
> 
> 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
that is

    A) buildable
    B) supportable
    C) sellable
    D) profitable.

> 
>>  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:
> http://www.percept.com/dvt-evt.php
> 
> 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) 
     yes.
> - NOR removal (hard to source and eats space)
     yes
>   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
       Explain please.
>   - 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