On 5/13/05, Jack Carroll <[EMAIL PROTECTED]> wrote: > > I'm not dissatisfied by this idea. Maybe there's something wrong with it. > > :) > > I got the impression that investors would be somewhat dissatisfied > at open-sourcing the complete RTL at all, but probably not dissatisfied > enough to opt out if the time horizon is long enough to encompass most of > the potentially available revenue. The argument here is that minimal > revenue can be expected from the far end of the exponential tail-off, and > that can rationally be sacrificed to achieve up-front savings by attracting > volunteer support. > Most of the open source contributors, on the other hand, are > somewhat dissatisfied at the idea of not securing permanent availability of > the complete design when the first boards ship, but not to the point of > refusing to participate. The argument here is that a firm commitment to > open-source the full design at a specific date after the company has made > its money will protect the investment that board purchasers make in > hardware, and project contributors make in code and support. That is, no > unilateral decision can yank the OGP board off the market and leave us back > where we started. > There appears to be a large middle ground in terms of release date, > that should be acceptable to all parties, even if not perfectly satisfactory > to all. > I think this discussion, as long as it's been, was necessary to > explain the various costs, why a period of trade secret protection is > essential to obtain investor participation, and why investor involvement is > necessary to the success of the project. Those points no longer seem > debatable.
Sounds really good. > > The time you have to be patient could be measured in months. Lead > > time for parts can be longer than that sometimes. :) > > If the time is as short as that, it changes things somewhat. I was > envisioning 2 to 5 years to give the company adequate time for all the > things that have to happen before the product has made the bulk of its sales > revenue. You make a good point, and I should point out that I haven't discussed this with my partners or any investors. Perhaps I'm being too optimistic. This really does need a lot of thought, and as soon as it's settled HOW we're going to do this, we need to move on to WHEN. > A few months should be an acceptable length of time for anybody to > wait before being able to hack on the FPGA load. It might even reduce the > pressure for some form of code escrow or trusteeship -- especially from > embedded customers who take a long time to get product safety approvals and > begin production buys. > But, you say the bitfile can be reverse-engineered if somebody is > willing to work hard enough? Are you talking about the binary load image > for the FPGA? Yeah, and well, I wouldn't say they would get a lot out of it. Have you ever reverse engineered machine code and tried to get some meaning out of it? It's very difficult, and reverse engineering a bitfile is orders of magnitude more difficult. > If that's the case, you can't afford to make the closed part > of the design available for execution to any board owner who isn't under > NDA, until the open-source date. Or are we talking about a non-volatile > FPGA, with a security feature to prevent the load image from being read out? > (That could be programmed at the factory, so the board owner wouldn't need > to load it from EEPROM at each power-up, and thereby have a copy of the load > image accessible for reverse engineering.) I don't think anyone's going to think the "binaries" are unsafe to release. During driver development, I'm going to want to put the latest cores on a web page for people to download. Even here, someone could build a compatible board and use our bitfile. There are limits to how much we can worry about and stay sane and productive. What I want to do is take away the EASY ways to rip us off. Trying to reverse engineer what we did would be harder than just designing a new one from freely available specs. > Ok, having taken the 10,000 foot view, and feeling pretty confident > that under the proposed approach nobody who's essential to project success > will be dissatisfied to the point of taking their marbles and going home, > I'll say a few words from my own viewpoint. > What I want is a board that will show me good, sharp images on a big > monitor, and will remain usable for many years to come under whatever > direction open source operating systems and graphics libraries take. If the > board dies a natural death, I want to be able to get another one someplace > so I'm not left with a dead system that I've put a lot of time and money > into. I'd also like to be able to reproduce a working system later on, > simply because I know it works and have a tested set of config files. Being > able to upgrade the logic in the field without buying a new board is an > attractive plus, though not an absolute necessity. But I'd probably spring > for an FPGA board, to gain that obsolescence-proofing. Remember, the ASIC will PERFORM a lot better. If the FPGA board serves your needs, though, have at it. > The way things are shaping up, I'll get what I want at a price I'm > willing to pay. I'm willing to put some of my own effort into getting > there, because the long-term viability is valuable and can't be obtained > just by paying money for an off-the-shelf product. > So: it's necessary to satisfy the differing key objectives of the > various people needed to reach the common goal. How to do that has now been > fully explored. I'm convinced that the approach Tim describes is the only > way that offers good prospects of success. It's time to accept some > realities and charge ahead. Thank you for supporting this effort. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
