On Thu, May 12, 2005 at 10:42:33PM -0400, Timothy Miller wrote:
> On 5/12/05, Jack Carroll <[EMAIL PROTECTED]> wrote:
> > On Thu, May 12, 2005 at 04:13:49PM -0400, Timothy Miller wrote:
> > > On 5/12/05, Jack Carroll <[EMAIL PROTECTED]> wrote:
> >
> > [snip]
> >
> >
> > > > But I still don't see how trade secret protection is compatible
> > > > with
> > > > FPGA development in the field. Is it possible to add compiled logic to
> > > > an
> > > > FPGA load image without revealing the HDL source code?
> >
> > [snip]
> >
> > > As for VGA, it's a noncritical part of the design that nevertheless
> > > requires a ton of work. In the spirit of really wanting to GPL the
> > > whole thing, I though it would be nice to just share it from the
> > > start. I got tons of help with the 3D renderer but won't be releasing
> > > the code for a while, but people who helped knew that from the start.
> > > If someone else fabs the VGA emulator, it won't hurt us. If someone
> > > else fabs the 3D engine, it could put us out of business.
> >
> > It sounds like this is starting to converge.
> > If the 3D engine is kept under trade secret protection for an
> > agreed-on length of time, and the length of time is known to all, that
> > should meet everybody's minimum needs so the project can continue. As some
> > politician once said, when all parties are equally dissatisfied, the deal is
> > probably fair.
>
> 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.
> > OK, I think this just leaves one technical question: during the time
> > some of the HDL is still under trade secret protection, is there any way a
> > non-privileged owner of an FPGA board can hack and synthesize the open
> > portions of the code, and then link it into a complete FPGA load image? I
> > probably ought to know the answer to that, but my VHDL experience is limited
> > to a few months, and that was almost 4 years ago. The interface to the
> > closed-source modules could be described in a specification, so if the
> > synthesized code can be delivered in a linkable format, it should be
> > possible.
>
> The RTL that will come with the FPGA board will include things like
> the PCI controller, a pad-ring for the Xilinx, a memory controller, a
> simple video controller, and probably a few other things that would
> make a useful starting point for any random project that someone would
> like to come up with.
>
> Also, it might be possible to provide a post-synthesis netlist of the
> closed part of the design for linking against. I know there are
> drop-in cores for FPGAs. But we'll have to figure out if the netlist
> is impenetrable enough. The bitfile will already be hackable to the
> most industrious of reverse engineer. The point is to protect the IP
> very well for a period of time to ensure the project's success, THEN
> release it completely, making cracking it pointless.
>
> 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.
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? 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.)
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.
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.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
