Standard socket interface tapped

These needs have led our engineers to develop a platform architecture with a standard socket interface. The development has been an evolution based on a decade of wireless experience and on innovations in open-socket thinking.

An example of this platform, the Open Multimedia Applications Platform (OMAP1510), meets multimedia design requirements optimally through a two-core approach.

The defi nition and development of the first-generation OMAP products were based on more than 10 years of wireless-system expertise. Devices prior to the current OMAP products had the same power, area and time-to-market constraints we see today, and we developed IP and interface standards to support these goals. In particular, we used in-house bus standards. We refer to Level 3, or L3, in contrast to a Level 2 cache and peripheral (Level 4, or L4) levels of the bus hierarchy.

First-generation OMAP devices successfully reused much of the technology from these previous designs and were based almost exclusively on TI-developed components. However, it is natural that we changed how we build OMAP devices as silicon capability, design methodologies and the IP market matured.

Our first-generation bus standard, known as Rhea or TIPB, epitomizes the bespoke, bus-based approach that was common in first-generation system-on-chip (SoC) designs. We developed a bus that made use of extensive clock gating an d variable data widths to minimize power and area. The approach was successful in these goals, and a library of standard components supported asynchronous peripherals. This approach, however, had a number of problems that became more serious as we designed more peripherals, performed more integrations and wanted to use more advanced electronic design-automation tools and methodologies.

Additionally, using an in-house standard made it hard for us to exchange IP with our customers- importing modules from them was difficult and providing modules for their ASICs was equally difficult, except when they made use of our bus. Finally, there were some modules that we wanted to use as L4 components in some devices and as L3 components in others, while other modules such as bridges and DMA had to talk to both. The lack of synergy in the two bus/interface standards made this difficult.

To deal with these issues, we introduced the Open Core Protocol initially as a standard for the design of IP (s ee www.ocpip.org for the OCP specification). Our team chose OCP after a lengthy evaluation of the available options and after making our choice, we assigned experienced engineers to ensure the adoption was successful throughout the TI peripheral design community.

The first step in adoption was to use OCP modules in a legacy environment. Despite the fact that we did this first in a complex device designed under significant schedule pressure, it was a relatively painless process. Subsequent devices are native OCP throughout and this has allowed us to significantly simplify the peripheral architecture of OMAP devices. Integrating modules with legacy interfaces into this native environment is also possible, although modules are being migrated quickly, so that this is not a major part of our next-generation designs.

Adopting an industry-standard interface has made integration of customer-provided modules much more straightforward. Even those modules designed with legacy interfaces can be e asily integrated by bridging to OCP and connecting to a standard socket. Similarly, our customers-whether or not they have adopted OCP themselves-find it convenient to receive OCP modules from us since we or they can easily provide a gasket to their chosen interconnect.

Our initial designs were based on an optimized "traffic controller" that included critical memory controllers (static DRAM, execute-in-place NOR flash) as well as the interconnect network. This interfaced to the ARM processor and DSP via the processor's own interfaces and to other initiators such as direct memory access (DMA) through a simple 32-bit in-house interface.

We built the first OMAP devices around a core hard macro-known in TI's ASIC flow as a subchip-so as to reuse the investment in the traffic controller and its related components. The subchip included various expansion ports intended for on- or off-chip devices. Again, these ports used in-house interfaces intended to match the intended uses.

O ver the various generations of OMAP development, we have found that some of the clock-cycle constraints have become less severe since memory speed has not kept up with our digital process development. In addition, the expansion ports have been used for applications other than those that we intended.

This has led to a gradual migration of the design style so that today we are in a position to standardize on the OCP socket interface. We are using this socket not only for interfaces to the core of processors and memory interfaces, but also within it.

Unfortunately, we cannot move entirely to native interfaces since some IP is not yet available with our chosen interface. However, knowing that this would probably be the case, we chose our socket standard to allow maximum cooperation with other standards in order to bridge devices to our OCP environment .

The c55x DSP core has to support an in-house bus interface in addition to OCP. After some investigation, it became clear that bridging from the data-flow segment of our OCP socket to this other interface was so simple that we could include the bridge in the interface design at no extra cost. This was an encouraging confirmation of our belief that it would be easy to bridge OCP to other interfaces.

As the design progressed, it became clear that using Open Core Protocol would actually save cycles compared with the original interface. This was in part because some of the constraints were removed from the OCP design, but did show that choosing OCP allowed designers to design interfaces that fitted naturally into their blocks.

The adoption of OCP has made it significantly easier for us to use external IP in the core engine. Whereas before it would have been a challenge to integrate a memory controller from a third party and unthinkable to use one of the emerging interconnect generators, these options are now possible. One interesting possibility in this area is to make use of OCP's flexible burst protocol to red uce some of our FIFO requirements and improve performance by using a memory scheduler.

See related chart