Slashdotted

[Steve Mosher]

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)