Providing completely reusable IP that needs no modifications from design to design without overly constraining the IP integrator is not feasible, so IP developers use strategies to maximize "painless" IP reuse. These techniques include making the central IP cores as configurable as possible and providing multiple bus interfaces or easily modified system interfaces; standardizing specific IP feature sets, aiming for a high degree of direct reusability (80% to 90%); and providing well defined and documented source code, with the appropriate reusable testbenches, to allow IP integrators to modify the core as needed. A few examples demonstrate the effectiveness of these techniques.
For instance, a triple-speed Ethernet media access controller (MAC) core comprises a 10/100/1000-Mbit/s Ethernet MAC with a Gigabit media independent interface (GMII) and media independent interface (MII). The GMII can be modified to support several other physical-layer (PHY) interfaces.
The soft core comprises seven submodules implementing transmit, receive, host interface, clock and reset, and MII management functions. The various submodules assist the IP integrator in interfacing the Ethernet MAC between a host CPU and a selected PHY device.
Implementing a bus interface requires detailed knowledge of the overall system, but less knowledge of the inner workings of the IP, making it a simple task for an experienced hardware designer. A high-level macro model provided with the core, along with parameterized submodules for selecting memory size, bus interfaces, management options, and other attributes, covers more than 95% of the modifications that an IP integrator needs to reuse the MAC core in different designs. Source-code modification is thus needed only for around 5% or less of a redesign effort, and it is typically limited to implementing custom features or nonstandard interfaces.
If modifications are needed at the RTL level, this submodule approach makes it easy for a chip designer to change only the area that requires modification. By breaking the Ethernet MAC core into blocks that are intuitive to the system designer, changes in the code in one area will have minimal to no impact on the other blocks. This "change containment" also applies to core verification—changing the functionality of one subsystem limits the required modifications to the core's testbench to verify proper operation.
Greater complexity in the core's functionality means it will need more minor source-code modifications when integrated into a design. The more core features that are configurable, the easier the integration. Finally, the longer the development efforts by the IP provider, the less dependent the core becomes on source-code changes by the integrator. In terms of reuse, more core tweaks are possible on a system level through core modularity and module parameterization.
Another example is a high-speed USB controller that's a USB 2.0-compliant core that fully supports USB On-The-Go (OTG) at both full and high speed. The key to this core's reusability with little or no source-code modification is user configurability through an easy-to-use GUI. The core is user-configurable for up to 15 transmit and 15 receive end points in addition to end point 0. Other configurable parameters include data-width choice, number of DMA channels, and a choice of external end point FIFO size. Full regression testing along all configuration axes ensures that a specific core implemented by the IP integrator meets all the core's specifications. If the vendor offers a system-level solution that extends beyond source code, documentation, testbenches, synthesis scripts, and various IP models, it minimizes an integrator's need to modify source code.
Aside from these deliverables and the GUI for core configurability, integrators can access an embedded USB software stack optimized for this controller interface. To account for changes in testbench requirements with different core configurations, the integrator also gets a testbench that is configuration-specific. It matches the configuration chosen by the integrator.
In short, minimizing an IP integrator's need to modify source code requires a mix of IP developer techniques that are core-dependent.
Reprints
