Standard Interfaces for FPGA Components Joshua Noseworthy Mercury Computer Systems Inc.

Presentation Takeaways FPGA Interface Techniques Standard Interfaces Facilitate: –Reusability –Portability –Improved Verification –Better Automation

Why Use Standardized Interfaces? FPGAs play critical roles in modern communication systems –Highly configurable –High performance –Intimate logic I/O interactions –Application-pecific memory hierarchies Increasing system complexity –Increasing heterogeneity FPGAs interacting with DSPs, GPPs, Cell, ASICs –Board-level complexities –Higher I/O demands –Time to market Development methodologies are lagging! –Little or no standardization Minimal reuse, portability

What is a Component? For purpose of this presentation, the characteristic properties of a component are that it: –Is a independent unit of deployment; Separable from its environment, as well as other components –Is a unit of third-party composition; Encapsulates it implementation Clear specification of provisions and requirements Interacts with environment through well-defined interface

FPGA Components FPGA applications are often inherently component-like Simple receiver example DDC, DeMod, and Decode functionality can be independently implemented and deployed in a single processing unit Processing units are completely independent with respect to each other and surrounding environment Provisions and requirements are specifiable for each processing unit Functionality of each unit can be clearly defined

Traditional Techniques for Creating FPGA Components Describe component functionality in an HDL –Behavioral Best chances of producing reusable and portable components –Structural Use of vendor-specific macros limits portability and/or reusability Using third-party IP –Xilinx’s CoreGenerator –Altera’s SOPC Builder –Annapolis MicroSystems CoreFire TM

Standards-Based Component Specification Component interfaces specified according to a common standard Key facet of modern-day component models Constrains solution space –Design to standard interfaces as opposed to inventing your own Improved reuse and portability Facilitates a higher degree of automation Verification assets leveraged across multiple projects Examples: –SPIRIT IP configurability Application composition –Open Core Protocol (OCP) Interface specification

SPIRIT Gear toward configuring and/or generating components and component assemblies Goals: –Increased automation for IP selection, configuration, and integration (side effect of provision of metadata) –Facilitate a multi-vendor IP and design tool flow Metadata (XML) provides a tool interpretable way of describing: –Design history –Object association –Configuration options –Integration requirements Interface agnostic –User defines interface using a schema

Open Core Protocol (OCP) Provides mechanisms to specify high-performance, bus-independent interfaces –Point to point Reduces risk, design time, and cost Increases reusability and portability –Design reuse: OCP helps make components independent of application being used in –Optimize die area: specify bare number of signals required to operate interface –System verification: provides firm boundary around each IP core that can be observed, controlled, and validated Facilitates use of machine automation for purpose of generating higher-level HDL files automatically

OCP Profiles Completely describes an OCP interface A collection of OCP parameters and associated values Limits solution space to a finite number of interfaces An interface’s definition and behavior can be reconstructed using information contained in associated profile Compatibility issues known ahead of time Interface Configuration File –Captures description of a profile as a text file –Legacy format may give way to a more machine-friendly schema (XML) in the future

Overhead Introduced by OCP OCP –Interface definition language –Does not specify how interface behavior is implemented –Provides approximately 92 parameters –Enables a configuration to support almost any type of communication interface Minimizing overhead –Understanding communication requirements Signal widths Reactive/proactive flow control DataHandShake requirements –Choosing correct parameter values –Unnecessary overhead consequence of making poor choices –Making good choices is harder when attempting to leverage profiles across multiple spaces

How OCP Choices Effect Implementation A Case Study: Overview Proactive versus reactive acceptance policies –Cost of implementation depends on application –Proactive Slave advertises its ability to accept requests through asserting/ de-asserting the XThreadBusy signal Master knows ahead of time if requests will be accepted –Stages next cycle of data values accordingly –Reactive Slave asserts the XAccept signal reactively to request Master asserts next request only after observing the assertion of appropriate XAccept signal

How Choices Effect Implementation A Case Study: Design Summary Proactive Accept –Requires storage device to buffer requests presented on same cycle SThreadBusy is asserted In some cases this storage can be significant –Inherently supports best-case throughput Reactive Accept –Doesn’t require buffering –Increases state machine complexity Especially if best case throughput is desired Conclusion –Understand implications of profile choices –Understand design requirements –Make right profile choices given design requirements Command Assertion Command Acceptance Mdata Push Pop SThreadBusy

Automation: Facilitated by Standardization Finite number of interfaces Interface behavior and configuration –Described independently of IP Meta-languages –Extensible Markup Language (XML) –Easily understood by machines Infrastructure providers provide standard interfaces to which components can connect Applications are specified independently of IP using same meta-language Tool parses meta-data Tool instantiates appropriate application and infrastructure components Connections made based on meta-data provided

Improved Verification Through Standardization Verification assets are expensive to develop Using application-specific interfaces results in poorly leveraged verification assets –Each application uses it own unique set of interfaces –New verification assets created for each new project Architect verification assets to support standard interfaces Verifications assets become leveragable across multiple areas –Initial development can be more costly –Costs are recovered quickly

Conclusions Standardized FPGA interfaces facilitate: –Reusability –Portability –Automatibility –Verification Leveraging –SCA Compliance Overhead is predictable –Minimized by making the right choices

Questions?