Know the Key Aspects of IP Integration
The use of intellectual property (IP) in a 130-nm or below system-on-a-chip (SoC) is a common and required practice. Current process technology requires hierarchical
construction methodologies. In addition, design flows demand the structured
characterization
of components in order to perform and complete the logic design. Prior process nodes were
able to utilize IP components
that were limited to I/O cells and primitive logic cells. These cells were hard physical
implementations of fixed fanouts. Generally, they only included a GDSII and LEF
representation with a vendor-supplied, three-corner .lib view.
IP—both third-party and in-house created— has a number of manifestations. These manifestations include but aren’t limited to the
following: place-and-route-created dynamic cells; clock and analog specialty cells; memory
subsystems including I/Os; standard processor cores; and application-specific macro/mega
cells and function blocks. Such variety in IP types has resulted in a major shift in both
the technical and the business challenges of using IP in designs. IP quality is another
issue that’s being addressed by the industry. Yet the quality metric standards that are
being proposed and promoted by both the FSA and the VSIA have little practical acceptance.
Figure 1 highlights the current IP-integration cost model for DSM design.
Regarding the integration of IP, one must first and foremost realize that most of the
available IP does not work in sub-130-nm designs. This isn’t due to an inherent deficiency
in the design process or the capability of the providers. Rather, it has to do with
process and performance variation based on where the cell is placed in the layout, what
it’s connected to, and to what and where the output is going. One of the major areas of
development in the EDA marketplace is on critical-area analysis and repair to specifically
address this issue. Until these tools have enough background information available from
the foundries, using third-party IP takes pretty much the same effort as designing it
in-house.
As a result of this shift, the only standard, licensable IP modules with a standalone
physical-implementation-layer (PHY) view are analog in nature (amps, level shifters,
transceivers, data converters, references, cable and sensor drivers, RF, and memory
cores). These analog blocks are generally isolated blocks that have their own supplies.
They’re separated from adjacent circuitry by multiple guard rings. The specialized skills
required to develop and support such cells is in very short supply in the industry. In
fact, these skills represent a regionally located skill.
The primitive core cells, which were one of the mainstays of the IP industry in the
form of standard cell libraries, have all but disappeared as a business model. Current
place-and-route tools have employed physical synthesis into their design flow. As a result
of performing timing, power, and logic optimization, a much larger group of core cells is
required. The large number of output drive strengths (normally 1X, 2X, 4X, 8X, 16X and now
1.5X, 3X, 6.5X, etc.) has moved the primitive cell creation to an automated task with
automated characterization.
Automated creation has been around for a while. The area of automated characterization for
new timing models is growing with the addition of vendors like Altos Design, Nangate, and
Simucad.
These shifts in base cell development have caused a shift in the direction of the IP
being made. Mentor is one of the leaders in this new area of “subsystem IP.” The other
EDA/IP providers (Cadence, Synopsys) and the traditional high-level IP providers (ARM,
ARC, Denali, MOSAID, etc.) are shifting to this model. This new direction includes the
addressing and solving of problems encountered
with the integration of the digital IP, analog PHY, and embedded-software IP. Typically,
these issues stem from various IP providers. A solution from Mentor Graphics shows its new
USB Subsystem IP solution (see Figure 2). This solution represents the new direction for
addressing the technical needs of the SoC designer.
As can be seen in the figure, the IP has expanded from a simple device-level PHY
(typically analog) and now includes a location and association-specific digital PHY. This
digital
PHY is custom designed to accommodate manufacturability as well as performance in the
target process. In the past, most designs would’ve called the combination of these two PHY
blocks a “macro” cell that is just placed in the design. The rest of the performance
aspects would be handled by the place and route. DSM designs cannot tolerate this level of
interconnect, as the constraints provided to the place-and-route tool aren’t sufficient to
provide for a low risk on the correct operation of the two blocks.
Once these blocks are available in a design, the next task is to assign a
processor/controller
to coordinate the data that’s reaching them. Most companies have targeted general-purpose
controllers for this function. Their operating code is programmed on a standalone
basis and then applied to the joint task of controller and PHY. The new subsystem solution
handles the process required, context-
aware programming development of the controller as well as verification IP and validation
of the interface between the blocks. With this completed, end users can simply drop in the
block as a “Mega cell” as they did with past process geometries.
Unfortunately, this savvy technical solution is just one of many for the IP market that
doesn’t have a firm business model behind it. The policy and pricing varies from provider
to provider and application to application. For this reason, users of these IP solutions
should be very aggressive in negotiating with the IP providers for a combo-pricing model
that includes a fixed portion, production profit portion, and support portion in the
license.
Past business models for the IP industry included the following: the contract
development
model; a one-time-use fixed charge; a multi-use fixed charge; a fixed charge for being a
reference design that can and will be modified;
a cost for just a soft register-transfer-level (RTL) model rather than a full PHY plus
verification/validation code; a royalty-based model from the fab on wafers; a
royalty-based model on die produced/sold; and fixed and royalty models plus a support
program. There is debate about what the new direction for the business of IP will be and
how customers contract for use. It appears that a multitude of models will emerge based on
whether the customer is a large IDM, joint-development partner, or small startup
company.
The general understanding is that IP integration isn’t an easy game anymore. Yet it is a required part of the SoC development cycle. As a
result, a change is taking place for engineering and the implementation plans between the
automation for traditional IP development and the new “subsystem” or “application
solution” -based IP that’s available.
The new forms of IP also are impacting the business aspects of including these IP blocks
in the design. Variability already exists amongst vendors on how to profitably price and
support the customers.
Pallab Chatterjee is the Founder/CTO od SiliconMap, LLC. He has been an independent design consultant since 1985 in mixed signal design and EDA tool flows. He has participated in over 400 design tapeouts. He has participated on the TAB of several software and semiconductor companies and teaches classes at several institutions.pallabc@siliconmap.net
Diane Chatterjee is the President/COO of SiliconMap, LLC. She has over 20 years experience in project management, information management and product marketing. Her recent specialization is in graphics, audio and video products and software. She currently focuses on product marketing and promotion in addition to business model/financial analysis. diane@siliconmap.net
