FPGA IP business model redux
In the short term, all these free cores are great news for the
FPGA SoC designer.
However, these same welcome developments may well conspire to make
for a challenging market for me-too third-party FPGA
soft cores IP vendors, and IP vendors who don't "get with the program"
and embrace the coming System Builder IDE products.
Unless FPGA vendors play their cards skillfully, they risk suffocating
their nascent third-party FPGA IP ecologies.
In the long term, there may be a less healthy, less diverse
ecology than had the FPGA vendors not "given away the store".
On the other hand, by making it easy to use/reuse/integrate unique IP,
FPGA vendors' System Builder products might arguably
grow the reusable IP market, from the current
dozens of potential customers, to many thousands of potential customers,
by making it fiendishly easy to don the system architect hat --
or so it seems...
This all harkens back to my now-two-year-old essay on FPGA
IP business models.
"If FPGA vendors give away enough free cores, the end effect could be
to discourage pure IP vendors from contributing to that device vendor's
value chain, reducing the supply of device optimized cores, hence design
wins, hence device sales."
The Challenge for third-party IP vendors
Who will pay a thousand dollars for a "me-too" third party
memory interface core when the FPGA vendor gives one away for free?
Particularly when the FPGA vendor's core is wrapped up with a bow,
packaged, integrated, and plugged into their "System Builder"
integrated development environment? When their core ...
- Is already there on the modules menu?
- Is already there in the preinstalled "verified plug-and-play cores catalog" documentation?
- Is already integrated into the system bus configurator?
- Is already integrated into the firmware configurator?
- Is already integrated into the system test bench generator?
- Is already available for instant download or free-upgrade-to-latest-version
from the vendor's site?
- Is already tried, cursed at, shook out, debugged, fixed, proven, vouched-for,
by dozens of other customers?
- Is already known to correctly interoperate with the other cores
in the target system?
(Note, I am not stating that such facilities are provided by any current
System Builder IDE product, but it's just a matter of time.
"A simple matter of programming." Almost a foregone conclusion.)
Can you say network effects? I knew you could.
What to do?
What should third party IP vendors take away from this development?
- Because FPGA vendors stand to profit from giving away high quality
IP, the rules of the The FPGA IP Game are quite different from The ASIC
IP Game;
- Most "Me-too" IP is worthless;
- "Me-too" on-chip buses are worthless;
- "Me-too" design environments are worthless;
- Your cores must ship, must shine, as plug-ins to System Builder IDEs;
- FPGA vendors can't do everything well; therefore, there is still
opportunity for:
- special, high-value, domain-specific IP; and
- vastly superior, highly crafted, higher-speed, LUT-miserly, "me-too" IP;
- Think system, think platform, (think reference platform),
think integrated, think solution, think works right out of the box;
I believe there are opportunities for third parties to sell preconfigured
FPGA SoC reference platforms for specific problem domains. Here the value-add
is as likely to be in the software and business domains as in the
hardware domain.
Your customers might be end-user engineers. Or they might be the
FPGA vendors themselves, eager to acquire IP that enables them
to establish volume design wins in new markets.
I used to think "the two on-chip bus interfaces (to processor, to peripherals)
define the platform" -- I was wrong.
Repeat after me:
The System Builder is the Platform.
The System Builder is the Platform.
The System Builder is the Platform.
And EDA companies, if you have aspirations to launch a
system-designer-canvas-IDE-type product in the FPGA space, you'd better
act fast, because it looks like the train is leaving the station.
Climate change and an ecology on the decline
In my earlier comments on Altera's
SOPC Builder,
I noted how it reminded me of Visual C++ 1.0. How that product
changed the subject, from compiler superiority/code quality,
to integration/programmer productivity/rapid application development.
Over the years, Visual C++ (and yes, Visual Basic)
evolved into the present, sprawling, stunningly all-encompassing,
Visual Studio.NET. A magnificent edifice, a cathedral
-- no, switch metaphors -- a Las Vegas of development environments,
catering to almost every whim and appetite.
This past April, following FCCM'02,
I stopped by the spring Software Development Expo, in San Jose, CA.
I remembered the glory days of SD Expo, ten years ago, when Microsoft
and Borland were having it out. The palpable excitement,
the buzzing bazaar of the exhibitor halls, with hundreds of
little companies with various specialty tools. Here a half dozen
programmer's editor companies, there a half dozen version control
companies, over there several debugger companies, linker vendors,
class library vendors, CASE tools vendors, and so forth.
What a difference a decade makes. This year, the exhibit hall
seemed maybe a quarter of its old size, and none of its old energy.
Maybe this is what the (mythical) COBOL Expo used to look like
before they packed it up for good.
What changed?
One factor is the poor business climate.
Another is on the open source movement, and the rise
of pretty damn good free tools.
Other factors include the fractured development landscape, the somewhat
stagnant PC software market, the developers who moved on to Internet
development, or those who moved on to (e.g.) Java development and better
targeted Java developer's conferences.
But there's probably another factor. As VC++ evolved and acquired
editing, debugging, class libraries, version control, CASE tools,
etc., this "platform climate warming" challenged the third-party
value-chain/add-in ecology.
Companies that zigged to Microsoft's zag, or companies like Rational,
with key complementary "star IP" (if you will), still live and thrive in this
ecosystem. But in the context of bundled, well integrated features,
"me-too" third-party products will be on the decline.
So the lesson for third-party IP vendors is to zig to the FPGA vendor's zag,
and you can do (very) well.
(Thanks to Dave Winer
for the zig/zag concept.)
The good news
Personally, I find this System Builder IDE development liberating
and empowering.
In the past, if you wanted to pursue your specialty, be it
specialty interfaces, specialty signal processing,
or specialty processor architecture, your (not standalone)
part of a larger system-on-a-chip solution was a difficult sell.
To make your core available and usable for evaluation by potential customers,
you would have little choice but wrap it up in a reference platform.
Maybe you'd have to build or acquire memory and peripheral interface
cores. Maybe you'd have to build yourself a reference system PCB.
All that packaging could well be more work (and in the universe
of cores' reference design packaging, useless, valueless, redundant work)
than went into your specialty core in the first place.
In my company's case, our processor cores were uninteresting
absent complementary glueless on-chip buses, glueless peripherals, and
absent a reference system PCB.
The coming System Builder era washes away much of that waste.
Now a specialty core vendor, provided they go to the effort
of packing up their product as a plug-in module, can be spared much
of that zero-value reference system packaging effort.
Takeaways for System Builder designers
- Take care of your nascent ecology;
- Go out of your way to help third parties integrate their
wares into your IDEs. Strive to keep a level playing field --
in particular, expose and document software and hardware
integration interfaces, and maybe even share market research --
such that a third party plug-in has the same opportunities
for integration, polish, and customer-interaction as your
in-house modules;
- If a partner is serving a niche well, think twice before
giving away an equivalent product...