On-demand Tool and IP Grid: Examining the Merits of
Fully Leasable On-demand Engineering Utility Resourcing
Camille Kokozaki, President, Design Rivers
In the early days of electricity and before power grids were
available for business and home uses, generators were used
locally by enterprises to create energy needed for the size or
type of application or product offered. This created additional costs
and logistics constraints that detracted from the business at hand.
Then someone came up with the concept of pooling the needs of city
blocks, followed by entire cities and finally regions, and delivering
power to them by building enormous electricity generating plants
that leveraged resources such that the net effect was a tremendous
economy of scale, significant cost savings and an increase in
productivity for all consumers of those resources. The concept
of power grid and utility was born with a fixed-rate fee (adjusted
periodically) that, when coupled with actual usage, set the variable
operating cost of energy for the consumer.1
Fast forwarding in time and looking at a different industry
and ecosystem, namely the semiconductor industry comprised of
foundries, integrated device manufacturers (IDMs), and electronic
design automation (EDA) and intellectual property (IP) providers,
one finds a resource provisioning very much like in the early days
of electricity. The ecosystem shows a fragmented supply and build-your-own tool procurement with complicated pricing and support
structures—business models that sometimes inefficiently pile all-you-can-eat unneeded software on top of the few requested in
exchange for a minimum size software order, which usually is a
substantial amount of the committed tool budget. In other cases, one
sees start-ups making do without needed tools, struggling to develop
products with the smallest financial impact. The inefficiencies of
developing potentially redundant tools; the struggle of software startups
to compete with established vendors; the logistics of evaluating,
procuring, deploying and supporting tools to develop end products;
and the constant drive for EDA cost controls all contribute to sub-optimize
the supply and the demand potential for EDA productivity
tools.
Contributing to the emergence of the need for new transactional
models is the fast evolution of information technology (IT) migrating
from location-based, traditional server environments to virtualization
of location leading up to full deployment in what is now identified
as cloud computing. This is a dynamic, new paradigm that is seeing
rapid shifts and includes many overlapping fields, unique definitions,
interpretations, use cases and incarnations. The IT and software
enterprise industries are attempting to put some formalism in the
various definitions, and the U.S. National Institute of Standards
and Technology (NIST) has weighed in on the definition of cloud
computing. Figure 1 outlines the essential characteristics and the
service and deployment models while providing a definition and
classification. The driving forces behind cloud computing intend
to provide optimizations to the capital and operational expenses in
infrastructure resourcing by injecting efficiencies in deployment,
maintenance and scaling to increased usage. The idea is to also improve
user productivity and flexibility. In this definition, Infrastructure-as-a-Service (IaaS) provides the servers, storage and network for the user
to provision/deploy operating systems and applications. Platform-as-a-Service (PaaS) is layered on top of the custom applications created
and supported by the provider, and allows the user some control over
the deployed applications and hosted environment configurations.
Software-as-a-Service (SaaS) notches that up by providing a browser-driven
thin-client connection to the whole environment being
fully deployed in the cloud infrastructure, leaving only limited
user-specific application configuration settings. The deployment
types beyond the traditional private cloud (which most companies
have been known to use) are (1) the community cloud shared by
multiple organizations that have common needs or affinities, (2) the
public cloud that provides access to the general public by a third-party
organization that can support securely multiple tenants, and
(3) the hybrid cloud which is a combination of any of the above
but has standardized protocols, data and application portability, and
a common taxonomy of procedures and methods. This last hybrid
cloud is where the opportunity lies for the semiconductor/EDA/IP
ecosystem.
Figure 1. NIST Definition of Cloud Computing
The proposition here (Figure 2) is to lay a blueprint for improved
EDA/IP synergies with the semiconductor user through the creation
of support layers for:
- Transacting via a cloud-hosted standardized protocol sharing
common taxonomy and procedures.
- Service and delivery with tiered service levels and volume usage/pay-per-use/per feature.
- Content management through maintained and updated
analytics dashboards, standardized usage and activity reports.
Figure 2. Fully Leasable On-demand Engineering Utility
Resourcing (FLOEUR) Support Layers
If one takes a radical approach at re-architecting the entire
semiconductor ecosystem with a different business model that
changes the format of the supply and custom tailors usage by pay-per-use and all-you-do-need tools, this radical approach would look
like the following:
- A flat rate usage fee per user, plan or type of tool.
- Year-over-year rate discounts based on any exceeded target
usage volume for some of the tools.
- All EDA tools and IP offerings are bundled through a unified
clearinghouse. IT and server access can also be optionally
bundled into a full turnkey provisioning with everything
delivered through one access point to multiple products from
disparate vendors.
- Any existing contracts get transferred in terms of remaining
monetary value and get depleted at the established yearly rate
year-over-year if a lease model was in place or a permanent
license re-buy credit occurs if tools were bought instead of
leased.
- There is no concept of local area network (LAN)/wide area
network (WAN)/maintenance support. One gets instant-on
access.
- IP tools get exercised through the flat fee model (for verifying
the IP), and the actual IP usage calls for a manufacturing usage
fee per chip that can allow unlimited instances on-chip. This
last portion could also be administered by the foundry.
- The flat rate fee will reflect actual usage by the user community
and will not be some arbitrary number set to meet some desired
margin, nor will it be influenced by an arbitrary discount solely
set by quarter-end driven deal making. Warming up to even the
concept of this transacting model could be challenging to the
traditional way of selling in this ecosystem. On the other hand,
many are questioning the viability of never-ending price wars,
making it difficult to make any profit if users are complaining
about expensive tool costs. Something is wrong when no one is
happy in this transacting process.
- Customers will be able to have predictable computer-aided
design (CAD) budgets that are optimized for usage through a
timely review of tool usage based on projected internal demand.
Customers will be able to have real-time usage tracking abilities.
- The playing field will be leveled for suppliers and customers
alike in the sense that EDA start-ups and small-sized companies
will be able to compete with their respective bigger competitors.
- Key metrics can be culled from usage patterns as it will become
easier to quantify actual demand for design and manufacturing,
allowing for increased investments in popular, needed products
and features.
Flat rate fee tiered structures and options can be as follows:
- Flat corporate fee per month or quarter.
- Flat site fee per month or quarter.
- Flat rate pay-per-use fee per month or quarter.
- Cost=ÎŁ(monthly/quarterly module or feature rate)x(actual
module or feature usage).
The key item to note here is that all EDA tools from separate
vendors are being bundled as a package, enormously simplifying the
administration and maintenance of the design environment on the
supply and the demand side. The default settings would always have
the latest released version from every supplier with the option to
revert to any version a user requires.
The enabling of so many features with such a sweeping business
model may raise concerns or objections: Will this bring down the
growth, profitability and desirability of the EDA and IP space by commoditizing, in a way, all the distinguishing features of the tools
and IP? The counterintuitive outcome could, in fact, re-energize and
revitalize these two segments by unleashing an untapped source of
revenue caused by users who may have shied away from using what
they really wanted to use if they could afford it, or even simply
manage their access to this new resource without significant effort.
The assumption here is that the applications can still run using
the local infrastructure (private cloud), but there is nothing to
prevent the bundling of even the servers as part of a full turnkey
experience where the service, tools, server and storage are aggregated
as a one-stop utility through a SaaS deployment. This would truly be
like plugging in the appliance and worrying only about the design
aspects and not the infrastructure or tool. The base service model is
characterized as SaaS and what one can extrapolate to as IaaS if one
wants full flexibility in managing the deployment. If one wants to
manage the application development then one can graduate to a PaaS
(Figure 3).
Figure 3. FLOEUR Model
Pricing for the various features needs to be carefully calibrated to
optimize use/value received from the tool capability and productivity
enablement. The recommended next step is to pull together a
committee representing the EDA, IP, IDM and foundry industries
along with academia and industry associations, such as GSA or
Accellera, and to carefully review the mechanisms needed to bring
about this transacting model. The IT and business analytics enterprise
industries already have the necessary applications and infrastructure
to implement and provision deployment in a cost-effective way. One
can think of this as expanding the user space by increasing demand
unfettered by an expensive access fee that slows down the velocity
of development. What would be changing is the vendor-customer
relationship, whereby the EDA industry works with larger providers,
and customers have expanded access to all the available tool and IP
space through a mega-channel with micro-access to a plethora of
tools and resources. The idea of selling the tools would move from
the obsession of closing the elusive large deal to better understanding
what tool/IP solutions the customers are really after and feeding back
improved feature requirements to the development team. Finally,
there is no restriction in having only a select number of FLOEUR
providers. Initially, these services could be offered and bundled by
additional aggregators, including the foundries themselves who could
bundle this along with their manufacturing services into a one-stop
design service/tool/IP/silicon provisioning. If this leads to foundries
acquiring EDA or IP as part of the vertical integration, all this would
do is take the industry back to how it actually started with an all-in-one technology offering. Wouldn't it be nice to restart the rate of
growth this ecosystem used to depend on?
About the Author
Camille Kokozaki is president of Design Rivers. He most recently was with IDT
as director of design automation services. During his 29 years of technology
experience, Camille has held various management and engineering positions at
Mostek and VLSI, including director of technology center operations. He was
director of marketing at Philips Semiconductors and president of his own design
services company. Camille holds a B.S.E.E. and M.S.E.E. from the University of
Illinois at Urbana-Champaign and an MBA from Florida Atlantic University in
Boca Raton, Florida. You can reach Camille Kokozaki at camille@designrivers.com or 408-705-7412.
References
1The Big Switch Rewiring the World, From Edison to Google by
Nicholas Carr, WW Norton & Company, Inc, 2008.
Back to Articles Home
