login
Search
Good comments All. Let me inline some answers/explanations. Lothar Behrens wrote:At the begining of Sean's presentation you will see two slides: 1. a picture of Steve Ballmer ( the evil empire) 2. A picture of paul Otilinni ( intel) And the point sean made about this was as follows; If a 15 year old kid tells ballmer that he has developed a technology that will disrupt microsofts business, Ballmer would do well to listen to him. Why? because with a computer and a compiler it is possible to disrupt their business or at least make there lives uncomfortable. Long ago back in 1994 before MS had any 3D api in windows there were three small UK companies that had 3D apis for the desktop: argonaut; Rendermorphics; and Criterion ( i worked there). These were really very small companies and what we did was keep gamers in DOS, while MS wanted to move gaming to windows. We disrupted their plans to move important apps into DOS. So they paid attention to us. I remember sitting with Alex st John and eric engstrom as they discussed what was originally called the "manhatten project" later to be directX. And the phrase disruptive technologies came up over and over again. One guy even had a folder on his desktop labeled disruptive technologies. In the end, MS aquired rendermorphics and it became Direct3D The point: in the software world, a kid and an idea is potentially a powerful force. The history of this is covered in this book: Drummond, Michael (November 2000). Renegades of the Empire: How Three Software Warriors Started a Revolution Behind the Walls of Fortress Microsoft. California: Three Rivers Press. ISBN 978-0609807453. Covers the early years of DirectX development within Microsoft, including the acquisition of RenderMorphics. The bottom line on software is this: the business of software is easy to disrupt because the barriers to entry ( the cost of tools) is comparatively low. Now, lets look at hardware. If that same 15 year kid came to Paul Otillini and said he had technology that would disrupt Intels business what would paul do. He'd ask the kid who his investors were? ask what EDA tools did he use? Synopsis? did he have a cycle accurate C-SIM of the chip? Who was his fab? was he planning an ASIC flow or COT flow for the chip, what tools did they use for floor planning, routing etc. The cost of these tools and the cost of proving something in silicon are in the millions of dollars. Hardware is hard. The barriers to entry are huge, not only IP barriers but sheer cost. So, Sean's basic point in those first two slides is that entering/disrupting the software business is orders of magnitude easier than entering the hardware business. This of course is an extreme comparison, used however to make a point. We should be on guard against notions and attitudes that characterize the hardware business as easy. At OM we entered the hardware business at the system level. Not designing chips of course, but one level up from that: designing hardware systems. Here too, however, you see costs and risks that form barriers to entry. For example, the test lab we maintain for testing phones has 5Million dollars of equipment. A prototype run of an evaluation board can cost 50K USD. 20 phones: 50K. 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? We've all sat there and said, just compile it, see if works. That's easy in software. In Sean's presentation you'll see a slide. "gcc GTA02v5 doesnt work" what that means is this. There are perhaps some unconcious attitudes people have carried over from the software world that will jump up and bite them when they start to work in the hardware world. I'll use another metaphor. Building hardware requires a "waterfall" design process, at least in my experience. In the software world, outside of DOD and NASA, we'd be hard pressed to find projects that followed a strict waterfall model. In a waterfall model you start with requirements. And you don't write a line of code until requirements are 100% done and complete and signed off. Once the requirements are done. They don't change. Then, and only then you get to do design. You are still not writing any code. when design is 100% complete, you move to implementation. If you're not familiar with this approach I can tell you it's a PITA. But it has its advantages: a requirements defect found late in the game ( in verification for example ) can cost 50-200X more to fix than if it was fixed in the requirements phase. This holds especially true for embedded software. 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. That means this: if you are designing hardware or doing hardware system integration you would be well advised to follow a waterfall model. Any other approach is prone to excessive delays and costly recamps. Just read the list and see the number of people who are suggesting implementations for a new GTA03 design. The rush to implementation-- use this processor.. no use that processor, camera or no camera, resistive 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 another example. During the course of many discussion about GTA03 and GTA04 both here and inside OM, both before and after the demise of GTA03 I see a pattern of discussion and problem solving that is, in my mind, part of the problem. Those discussions go like this: "what if we take the GTA03 and stick it in the 02 case?" which leads to "but where will the camera go?" which leads to "do we really need a camera?" and so time 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. The bottom line is this. To do a GTA03 right means starting with requirements. 100% complete requirements. set in stone... or quick setting cement. We had a couple of sayings in the jet fighter business. Design is like diving into a swimming pool of peanut butter. You better pick your landing zone right because there not much ability to swim around after you hit. And also, this: "engineers almost never make mistakes, the guys who set requirements do." 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. The OM designs all used "modules" for GSM and modules for things like WIFI and BT as opposed to "down" designs or chips on PCBs. The diffculty is not in finding components or modules and system level design is fairly straight forward. The real difficulties come in areas like RF design ( a black art of sorts) and in the marriage of mechanical and EE. 3G dongle Well, we are looking at making the gerbers available under a licencing program. Stay tuned. No, we designed DASH electronics using Our existing design. As Sean points out in his presentation, this project proved to be a distraction from our main goals in that time period. Why? here's a solution for Dash, just take the existing design and make a few changes and recompile the hardware! I'm in the process of exploring this with a new list. However, you need to understand the process: 1. requirements: the community can help here. 2. Design: the community can help here: 3. Implementation: Build EVT boards. This is where you need money and infrastructure. So, if the community wanted to Build and buy EVT boards ( I actually suggested this to Sean) then that could happen. But an EVT board costs about 2 grand. I suppose if we had 20+ volunteers who wanted to do this, it could be done. But remember EVT boards often end up not working. Build 20, get 15. I'm not saying that it's impossible, but everyone who gets involved needs to know the mountain in front of them. And we havent even discussed ID. ID could be developed by the community. In fact, we had planned a design contest for alternative cases for the GTA03. With volunteer efforts you could probably make it through a first pass at ID and mech. here again samples are costly. early samples are done on CNC machines, later rapid prototypes (25K) and hard tooling is well over 100K. I'm looking into that. There is no fundamental objection to that. the terms and conditions are what I need to examine. Also, many people question the importance of gerbers. If you just want to copy the design as is and send those files out to have a PCB built, then having the gerbers saves you the time of reverse engineering from the schematics or reverse engineering from the actual board ( seen that done) but gerbers dont give you a theory of operations and design changes to a design you dont understand can have knock on effects: see the glamoectomy. without looking at actual numbers I would say 20% of the cost is in requirements and design and 80% in implementation, verification, production, test, and maintennce. Again, we are thinking down some similar paths, so your comments are welcomed. Ya I love werners stuff. Now, for a while, the GTA03 was going to have an internal debug board. The words flew kinda hot and heavy on that one. less than 50% of all buyers get a debug board. Should we include internal debug capability on every GTA03? I won't revisit that debate here. That's what were are going to try to do. Ok.. here comes a question. What layout tools? are there open source layout tools ( one hopes) and if not then what tool do we pick? Essentially, you are pitching the idea I'm going to try to get going. I'll make an announcement about it shortly, but my plate is pretty full and I can only volunteer a couple hours a day to help organize and guide it. I think so. no harm in trying. The voting approach will be discussed. Basically I dont believe in letting idiots vote. You dont want me voting on your layout and convincing everyone with my superb rhetoric that your 8 layer design can be accomplished in 2 layers.. you get my drift. The community will have to have SME ( subject matter experts) They will have to have some undemocratic powers. my view at least. I asked sean the same. We are going to set up a mailing list at openmoko.org to get this started. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
