Standard Interfaces for FPGA Components

1
Standard Interfaces for FPGA Components

• Joshua Noseworthy
• Mercury Computer Systems Inc.

2
Presentation Takeaways

• FPGA Interface Techniques
• Standard Interfaces Facilitate
• Reusability
• Portability
• Improved Verification
• Better Automation

3
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

4
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

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
Traditional Techniques for CreatingFPGA
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
• Xilinxs CoreGenerator
• Alteras SOPC Builder
• Annapolis MicroSystems CoreFireTM

7
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

8
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

9
Open Core Protocol (OCP)

• Provides mechanisms to specify high-performance,b
  us-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

10
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 interfaces 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

11
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

12
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

13
How Choices Effect Implementation A Case Study
Design Summary
Mdata

• 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
• Doesnt 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

Pop
Push
SThreadBusy
14
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

15
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

16
Conclusions

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

17

• Questions?