When considering the challenges posed by IP integration, it's not all about
IP packaging standards, bus protocols, clock and frequency domains, and imposition
of an interconnect fabric. It's also critical to look at the issues that IP
poses in the context of physical design and implementation.
From an implementation standpoint, most IP is not fixed. That's to say that
many features of a given IP block often can be implemented in various configurations.
It's important that these options for selecting the functionality be carried
through the entire implementation flow. If it's claimed that a particular IP
block runs at 250 MHz, is that in all modes, or just some modes? Is 250 MHz
its fastest speed in the fastest mode, or in the slowest mode? If there are
seven different clock domains, are three of them actually merged into one so
that there are really only four clock domains? These questions must be answered
in implementation, or you can find yourself in hot water.
It's also critical to understand where IP is mapped among the fabrication
processes, technologies, and libraries. So if you're using the Artisan physical
IP library from ARM and mapping it to TSMC's 130- or 90-nm process, it's important
to verify the physical characteristics of the IP. Is it really running at 250
MHz? Could it run at 300 MHz if you're willing to trade off area? It's also
important that the provider of your RTL-to-GDSII implementation flow have very
close relationships with IP vendors so that the quality of physical design results
can be adequately characterized.
A related aspect is test strategy or design for manufacturing (DFM). It's
one thing to purchase a piece of standards-based IP, such as a USB core, and
be able to understand its pin-level functionality. You can synthesize the core
and perform timing analysis, and perhaps it looks good at gate level. But what
about inserting test structures? You'll need to insert scan or memory built-in
self-test (BIST) for embedded memories, or perhaps compression logic or the
logic BIST with test points. All of these considerations must be part of the
IP selection process.
The IP itself may be memory intensive, which raises the question of how many
memory-BIST controllers are required. Or, perhaps the IP has very little memory
but the rest of the design is memory intensive. It's tempting in such cases
to attempt to share memory-BIST controllers with the rest of the design. Such
schemes may or may not work out because of differing clock domains and certain
power requirements.
Yet another aspect is power. Suppose you wish to create a voltage domain for
a given IP block, or use the vendor's multi-Vt libraries for leakage-power optimization.
If the chip goes to sleep, what happens to this IP block? How many registers
really need to be retained, and, therefore, should you use retention flops?
Unfortunately, these and other implementations often aren't considered by
IP providers, because they're not taking their cores through to implementation.
This doesn't apply so much to hard IP, such as from an analog-IP vendor, because
that vendor will supply a piece of IP that will function at a specific frequency
for a specific process. (On the other hand, that's also why analog IP is generally
not reusable.)
Yet for the soft, synthesizable IP cores, Magma tries to work with IP vendors
to educate them on the complexity of the overall implementation that they need
to address for all customers. We also try to help them build flows that are
a lot more flexible so that they can verify their IP under multiple conditions
and for multiple processes, and for all combinations with and without multiple
Vt libraries. The objective for them is to build the entire flow as a single
script. In our Magma-ready IP program, we work at that level with our IP partners.
Often, we build them the initial script or template, and they would keep enhancing
that for several of their IP cores.
Another critical issue for implementation with IP is the qualification of
floorplanning and placement in the context of the larger design. Generally speaking,
the IP vendor can implement its IP in a square or rectangular shape. But the
reality is that when you look at this IP in the larger context of the design,
not all IP blocks are made hierarchically. Obviously, hard IP must be maintained
as a separate box. But soft IP does not have to be maintained as a separate
hierarchy. Even if you manage to do so, in a given design, that IP may not be
on the square floorplan. It may be a C or E shape, or a rectilinear shape. In
other words, it ends up having more than four sides.
Not only that, but in physical design, a given IP block could be merged with
the rest of the design and be floorplanned on a flat level as opposed to maintaining
the hierarchies. Some soft macros could end up in physical partitions that are
implemented separately. Therefore, as the shape of the floorplan or the shape
of the physical block varies, the overall characteristicsóparticularly
the timing characteristics of that IPówould change. Some signal paths
suddenly become longer, or elements that you assumed would be kept together
are not.
It's important for IP vendors to supply physical constraints with their IP.
It doesn't have to be an actual floorplan, but it can be instructions to keep
certain registers or logic together from a physical perspective. Or, it might
be instructions stipulating that clock gating is required on this path, or that
multiplexing is not possible on that path. The more physical constraints provided
by the IP vendor, the more likely you'll be to get the performance you expect
from their core when you use those constraints in implementation.