Standard Interfaces for FPGA Components

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

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

3. 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 Why Use Standardized Interfaces?

4. 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 What is a Component?

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

6. 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 CoreFireTM Traditional Techniques for CreatingFPGA Components

7. 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 Standards-Based Component Specification

8. 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 SPIRIT

9. 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 Open Core Protocol (OCP)

10. 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 OCP Profiles

11. 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 Overhead Introduced by OCP

12. 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 OCP Choices Effect Implementation A Case Study: Overview

13. 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 0 1 1 Command Acceptance 0 How Choices Effect Implementation A Case Study: Design Summary Mdata Pop Push SThreadBusy

14. 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 Automation: Facilitated by Standardization

15. 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 Improved Verification Through Standardization

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

17. Questions?