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.
Reprints
